Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: X310 + UBX-160 + UHD sink = (sometimes) error (Jimmy Chau)
2. Re: E310 Rfnoc clocking guidelines/ performance issues
(Jonathon Pendlum)
3. Re: x310 FPGA code (Jonathon Pendlum)
4. rfnoc-modtool cores (Jason Matusiak)
5. Re: E310 cross compilation issues (olivani)
6. creating USRP and tuning to different frequencies. (olivani)
7. X310 samples delay (Carlos Alberto Ruiz Naranjo)
8. Re: rfnoc-modtool cores (EJ Kreinar)
9. Re: E310 cross compilation issues (Michael West)
10. Phase sync multiple x310s (Vladica Sark)
11. Re: Phase sync multiple x310s (Julian Arnold)
12. Re: rfnoc-modtool cores (Jason Matusiak)
13. Re: Phase sync multiple x310s (Vladica Sark)
14. Re: Phase sync multiple x310s (Julian Arnold)
15. Re: Phase sync multiple x310s (Vladica Sark)
16. RFNoC: Time Share a CE (Richard Mcallister)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 May 2017 12:22:30 -0400
From: Jimmy Chau <[email protected]>
To: [email protected]
Cc: Haile Berhe <[email protected]>
Subject: Re: [USRP-users] X310 + UBX-160 + UHD sink = (sometimes)
error
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Haile,
I think you?re referring to my original thread "[USRP-users] USRP X310 with
UBX-160 - transmit freezes with certain GNURadio flowgraphs?:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-November/022570.html
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-November/022570.html>>.
Rich in the same thread
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023601.html
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023601.html>>
says that reverting UHD to release_003_009_006 worked for him. I have not
personally verified this yet, but I suggest trying it (and let the list know if
it works; that should help narrow down the cause of the problem).
My workaround was to split the flow-graph: first saving the pre-generated
signal without the UHD Sink to file, and then using a separate flow-graph to
replay the recording from a File Source to the UHD Sink. This workaround was
sufficient for our project (since the signals we were trying to transmit did
not depend on feedback from the radio).
Unfortunately, I haven?t had the opportunity to troubleshoot further.
Martin Braun from Ettus suggested that the problem is in GNU Radio, but I have
not followed-up on the GNU Radio mailing list yet because I wanted to narrow
down the cause first. I still suspect that at least part of the problem is in
UHD or the firmware though since:
Reverting to an older UHD release apparently solves/avoids the problem.
I?ve only seen reports of this problem with the USRP X310 and UBX-160 hardware
combination.
-Jimmy
> On May 18, 2017, at 9:39 AM, Haile Berhe <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hello Jimmy,
>
> While desperately searching for a solution, I came across your post which is
> exactly the kind of problem I facing right now. As you explained it in the
> usrp-users mailing list, some gnuradio blocks are throwing errors when X310
> and UBX-160 are used. Specifically, when UHD sink is used in a flowgraph. For
> example, my FM-transmission toy have been working very well in N200 but
> somehow it fails when X310 with UBX-160 daughter-board is used. I have posted
> this problem both on the discuss-gnuradio and usrp-users mailing lists but I
> have not yet got a reply with a solution. In case you have solved this
> problem, would you please share the solution?
>
> Regards,
> Haile
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/0ce20460/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 18 May 2017 13:28:05 -0400
From: Jonathon Pendlum <[email protected]>
To: Samuel Prager <[email protected]>
Cc: Ryan Marlow via USRP-users <[email protected]>
Subject: Re: [USRP-users] E310 Rfnoc clocking guidelines/ performance
issues
Message-ID:
<CAGdo0uSQ0KN5=w6szj_fhzkvizt8lzao3pybxraqhjgqxrc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sam,
> *Issue 1)*
>
> When I run the application, rfnoc appears to initialize correctly and I
> can sr_read sr_write. However, after receiving one pulse (4096 samples), I
> begin to see errors similar to:
>
> *Error: EnvironmentError: IOError: 0/Radio_0 user_reg_read64() failed:
> EnvironmentError: IOError: [0/Radio_0] sr_read64() failed:
> EnvironmentError: IOError: Block ctrl (CE_00_Port_10) packet parse error -
> EnvironmentError: IOError: Expected packet index: 0 Received index: 890*
>
> If I do not read/write any FPGA registers before sending another pulse, I
> see timeouts after a few thousand samples have been received.
>
> I have tried changing the rate (as low as 1 MHz) and increasing the wait
> time between pulses ? neither has any effect. After the first pulse, the
> usrp starts to freeze up. I have also tried adding a FIFO block between the
> Radio RX and host with no improvement.
>
When you receive a pulse, are you only calling recv() or are you doing
anything else? This looks like UHD expected the response packet to have a
sequence number of 0, but the radio replied with a sequence number of 890.
This could happen if the radio block got reset. You said this code works
fine when running on the X300 though right?
> *Issue 2)*
>
> The data I am receiving in the analog loopback configuration is
> essentially junk. However, if I set the ?loopback? register in the
> radio_core (SR_LOOPBACK = 132), I receive the exact samples that are being
> send by the AWG with the correct time coherence, etc. So the tx samples
> going out of the radio_core appear to be correct.
>
Can you do an external loopback with something simple like a tone? The
AD9361 is a fairly complicated device and starting off with a simpler test
case might give us a better clue.
> *Questions:*
>
> Are there additional uhd calls needed to setup the E310 RF frontend beyond
> what is necessary for the X300?
>
Not that I'm aware of.
> I am sort of scratching my head here because I have been using noc_block
> on the X300 successfully for a while and the E310 fpga image I built met
> timing, etc.
>
> Are there any obvious culprits for this sort of behavior? My noc_block
> uses a timekeeper (and the sync_in and pps signals on the X300). On the
> E310, however there is no sync_in signal and the pps generation is
> different. Could this be the source of the issues that I am seeing?
I wouldn't completely rule it out, but I doubt it. Have you tried sending
the pulse immediately / ignoring the timekeeper?
> What is the proper way to set the gpsdo as the time and clock source for a
> device3 based usrp? Is there anything analogous to what is used for
> multi_usrp in the sync_to_gps.cpp example?
>
I believe we expose what you need in the radio block controller
(radio_ctrl_impl.cpp). Take a look at
https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/examples/rfnoc_rx_to_file.cpp
And lastly, is it possible to use a dma_fifo block directly on the E310? Or
> does custom firmware have to be written in order to use the dram memory on
> board?
The DmaFIFO block would be compatible, but you need to generate a MIG with
an AXI4 interface. Luckily, we already have IP for the MIG that is built
when you run the 'E310_dram_test' make target. You could try starting with
that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/dff25bdd/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 18 May 2017 14:03:19 -0400
From: Jonathon Pendlum <[email protected]>
To: Lihua Ren <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] x310 FPGA code
Message-ID:
<cagdo0urc_wue-mq7ax6q2tesoctczwlzsbeg0_z9bbfqqlv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI Lihua,
Generating a 114.688 MHz clock is going to be very difficult. For instance,
the closest you'll achieve with a MMCM using bus_clk is 115.385 MHz. Can
you explain exactly why you need a 114.688 MHz clock and what you are
trying to achieve? That way, we might be able to come up with an easier
approach.
Jonathon
On Tue, May 16, 2017 at 9:02 PM, Lihua Ren via USRP-users <
[email protected]> wrote:
> hi?all
> I met the clock problem, hope to get your help.for instance ?in
> noc_block_xx.v?"ce_clk" signal through the DCM(digital clock manager) ip
> core output 114.688MHz, but there are timing error.
>
> 114.688 MHz is determined by the baseband processing algorithm in my
> RFnoc block,and 114.688 MHz is main clock in my FPGA code.( *114.688 MHz** is
> not a sampling rate*)
>
> Importantly?in X310 FPGA code ?all the modules' the main clock is
> 200MHz, but my block need is 114.688MHz, which can be achieved?
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/3b4ef14e/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 18 May 2017 14:22:41 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] rfnoc-modtool cores
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I wanted to create an RFNoC block that utilized some Xilinx cores. Where
do I need to put these cores in the rfnoc-modtool project created
directory structure, and how do I go about tying that into the Vivado
GUI so I can build them up (just use the GUI=1 CL argument and do the
save-as project approach?)?
------------------------------
Message: 5
Date: Thu, 18 May 2017 14:47:23 -0400
From: olivani <[email protected]>
To: Michael West <[email protected]>
Cc: deepa kumar <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 cross compilation issues
Message-ID:
<CABq0ViwFYAC0QfQ_+LgeWCdHqhjSCuTyV1RmfK_0R7fkKy=u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi ,
Yaa it does seems more difficult . I tried to create some functions in
E300_impl but unable to expose it to the application layer. and whatever
function I created in e300_impl.cpp , and try to invoke it to the
application or UHD level, the only error I always get is undefined
reference to function. I have been working on different ways to figure it
out but no successful yet.
if somebody has tried could you please throw some light on it .
Thanks and Regards,
Olivani Subbukutty
571-331-2481
On Mon, May 15, 2017 at 9:25 PM, Michael West <[email protected]>
wrote:
> Hi Olivani,
>
> If you are using RFNoC and have created a custom block, it is fairly
> simple to write and read the user registers in that block because the API
> exists. If you have just added your own registers somewhere in the FPGA
> fabric, it is far more complicated. You will have to identify to which
> core and address space the register has been added and find the appropriate
> peek/poke functions to use in UHD and then somehow expose those to your
> application.
>
> Regards,
> Michael
>
> On Mon, May 15, 2017 at 4:17 PM, olivani <[email protected]> wrote:
>
>> Hi ,
>> Thanks for the response.
>> I have overcome that issue.
>> Currently I have created a new reg and defined it in e310_reg.hpp.
>> But unfortunately I am confused on methods to do a read or write to
>> register defined.
>> I tried to access peek32 and poke32 using uhd::wb_iface but not sure if
>> that was the right way to do.
>> I then saw the user_reg_read32 function in rfnoc lib and tried to invoke
>> that , but got segmentation error.
>> Could somebody help me out with steps to perform read and write on user
>> defined register.
>>
>> Thanks and Regards,
>> Olivani
>>
>>
>> Thanks and Regards,
>> Olivani Subbukutty
>> 571-331-2481 <(571)%20331-2481>
>>
>> On Mon, May 15, 2017 at 6:47 PM, Michael West via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi Olivani,
>>>
>>> It appears you may have cross compiled using a different SDK than the
>>> the one with which the SD card image was built. You need to either change
>>> the SD card image or use the SDK that matches the SD card image. The rev 3
>>> and rev 4 SD card images and SDKs can be found here:
>>> http://files.ettus.com/e3xx_images/
>>>
>>> Regards,
>>> Michael
>>>
>>> On Fri, May 12, 2017 at 8:35 AM, deepa kumar via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi ,
>>>>
>>>> I am doing new development on UHD on a vm machine. I followed all steps
>>>> as mentioned in docs.
>>>> I downloaded and installed the cross compiler and built the UHD. I then
>>>> mounted the folder on to E310 board . I set the paths using set_env
>>>> file.
>>>> Now when I do a which uhd_find_devices , I get the mounted folder path
>>>>
>>>> But when I try to run uhd_find_devices , I get the error
>>>>
>>>> error while loading shared libraries: libboost_program_options.so.1.56.0:
>>>> cannot open shared object file: No such file or directory
>>>>
>>>>
>>>>
>>>> Has anybody come across this . I am stuck with this for a long while.
>>>> Please help to overcome this issue.
>>>>
>>>> Thanks and Regards,
>>>> Olivani
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/4ea47e28/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 18 May 2017 14:55:24 -0400
From: olivani <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] creating USRP and tuning to different
frequencies.
Message-ID:
<CABq0VixykmCwXRt77PxGTj4V6nrz1qMcs2UdspO1S3sUhuW=7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi ,
I have a very basic question of
after creating a USRP device configuration and tuning to a particular
frequency
when I try to just tune it to another frequency without invoking the create
USRP device function again , I run into error.
Error: AssertionError: _send_entries_in_use.at(which_stream) <= H2S_NUM_CMDS
in uhd::transport::zero_copy_if::sptr
e300_fifo_interface_impl::_make_xport(size_t, const
uhd::transport::zero_copy_xport_params&, bool)
at
/home/balister/release-4/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.9.2-r0/uhd-3.9.2/lib/usrp/e300/e300_fifo_config.cpp:395
I have also increased the size of H2S_NUM_CMDS from 5 to 50 . But nothing
seems to chag
I eventually had to call the make function again and then only I could set
it to another frequency.
Am I missing something over here. I was in the assumption that once the
device is configured I should be able to tune it to any frequency I want at
any point of time.
Thanks and Regards,
Olivani Subbukutty
571-331-2481
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/0933bcd6/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 18 May 2017 21:22:51 +0200
From: Carlos Alberto Ruiz Naranjo <[email protected]>
To: [email protected]
Subject: [USRP-users] X310 samples delay
Message-ID:
<CAP2eGPjVM=fjs=K2oEH=v54yfdajys+eztizz67vfegedfx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
we have an USRP-X310 and we want introduce a DDC,to commander it from the
PC, and a delay in the samples (about 50ms) to be sure of process the
correct DDC samples.
How could be the better way? FPGA shift register, USRP DDR3...?
Greetings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/a8a45956/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 18 May 2017 16:11:04 -0400
From: EJ Kreinar <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-modtool cores
Message-ID:
<CADRnH21toGQATM2O0fNeXHJp4NMvcfTTtrmWT-m+A5S=etj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jason,
I currently have a PR in to the fpga repo (https://github.com/EttusResea
rch/fpga/pull/12) that adds support for linking Makefile.inc files in OOT
repos. Your OOT Makefile can then build the Xilinx IP and append it to your
build as needed. I've been using this approach for some time now with
success for both Xilinx IP and HLS designs.
I have an action to provide a sample "dummy" OOT repo with the correct
Makefiles-- but I havent gotten to it yet, unfortunately-- Was waiting for
confirmation if this approach will be supported in-tree in the future. I
could put something together soon though if this would help.
I'd also be interested in other good solutions, if anyone has an alternate
approach :)
EJ
On Thu, May 18, 2017 at 2:22 PM, Jason Matusiak via USRP-users <
[email protected]> wrote:
> I wanted to create an RFNoC block that utilized some Xilinx cores. Where
> do I need to put these cores in the rfnoc-modtool project created directory
> structure, and how do I go about tying that into the Vivado GUI so I can
> build them up (just use the GUI=1 CL argument and do the save-as project
> approach?)?
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/32228502/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 18 May 2017 15:17:17 -0700
From: Michael West <[email protected]>
To: olivani <[email protected]>
Cc: deepa kumar <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 cross compilation issues
Message-ID:
<CAM4xKrrQujk0Fsxm=pwml1jvt4kcdr5owpxspb8gs6_+59y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Olivani,
The way I use to expose functions from the e300_impl object to the
application is to use the property tree. Create a property and set the
proper publisher and subscriber functions. Then you can call
usrp->get_device()->get_tree()->access<property_type>("path_to_property").set(value)/get();
to access the property.
Regards,
Michael
On Thu, May 18, 2017 at 11:47 AM, olivani <[email protected]> wrote:
> Hi ,
>
> Yaa it does seems more difficult . I tried to create some functions in
> E300_impl but unable to expose it to the application layer. and whatever
> function I created in e300_impl.cpp , and try to invoke it to the
> application or UHD level, the only error I always get is undefined
> reference to function. I have been working on different ways to figure it
> out but no successful yet.
> if somebody has tried could you please throw some light on it .
>
> Thanks and Regards,
> Olivani Subbukutty
> 571-331-2481 <(571)%20331-2481>
>
> On Mon, May 15, 2017 at 9:25 PM, Michael West <[email protected]>
> wrote:
>
>> Hi Olivani,
>>
>> If you are using RFNoC and have created a custom block, it is fairly
>> simple to write and read the user registers in that block because the API
>> exists. If you have just added your own registers somewhere in the FPGA
>> fabric, it is far more complicated. You will have to identify to which
>> core and address space the register has been added and find the appropriate
>> peek/poke functions to use in UHD and then somehow expose those to your
>> application.
>>
>> Regards,
>> Michael
>>
>> On Mon, May 15, 2017 at 4:17 PM, olivani <[email protected]> wrote:
>>
>>> Hi ,
>>> Thanks for the response.
>>> I have overcome that issue.
>>> Currently I have created a new reg and defined it in e310_reg.hpp.
>>> But unfortunately I am confused on methods to do a read or write to
>>> register defined.
>>> I tried to access peek32 and poke32 using uhd::wb_iface but not sure if
>>> that was the right way to do.
>>> I then saw the user_reg_read32 function in rfnoc lib and tried to invoke
>>> that , but got segmentation error.
>>> Could somebody help me out with steps to perform read and write on user
>>> defined register.
>>>
>>> Thanks and Regards,
>>> Olivani
>>>
>>>
>>> Thanks and Regards,
>>> Olivani Subbukutty
>>> 571-331-2481 <(571)%20331-2481>
>>>
>>> On Mon, May 15, 2017 at 6:47 PM, Michael West via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi Olivani,
>>>>
>>>> It appears you may have cross compiled using a different SDK than the
>>>> the one with which the SD card image was built. You need to either change
>>>> the SD card image or use the SDK that matches the SD card image. The rev 3
>>>> and rev 4 SD card images and SDKs can be found here:
>>>> http://files.ettus.com/e3xx_images/
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Fri, May 12, 2017 at 8:35 AM, deepa kumar via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi ,
>>>>>
>>>>> I am doing new development on UHD on a vm machine. I followed all
>>>>> steps as mentioned in docs.
>>>>> I downloaded and installed the cross compiler and built the UHD. I
>>>>> then
>>>>> mounted the folder on to E310 board . I set the paths using set_env
>>>>> file.
>>>>> Now when I do a which uhd_find_devices , I get the mounted folder path
>>>>>
>>>>> But when I try to run uhd_find_devices , I get the error
>>>>>
>>>>> error while loading shared libraries: libboost_program_options.so.1.56.0:
>>>>> cannot open shared object file: No such file or directory
>>>>>
>>>>>
>>>>>
>>>>> Has anybody come across this . I am stuck with this for a long while.
>>>>> Please help to overcome this issue.
>>>>>
>>>>> Thanks and Regards,
>>>>> Olivani
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/6c88db89/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 19 May 2017 13:50:08 +0200
From: Vladica Sark <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Phase sync multiple x310s
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I have two x310s with 2x UBX daughterboards in each. I bring 10MHz and 1
PPS from octoclock to the both of them. With tx_waveforms I transmit a
CONST and record the resulting waveforms on a scope. The carrier is 2.45
GHz.
The phase difference between the four available channels jumps for +-45
degrees randomly. Without these jumps, the phase difference would have
probably been constant. This is the same for all of the channels.
Is there a chance to phase sync the two x310s and the four transceivers?
BR,
Vladica
------------------------------
Message: 11
Date: Fri, 19 May 2017 14:05:02 +0200
From: Julian Arnold <[email protected]>
To: Vladica Sark <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Phase sync multiple x310s
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hey Vladica,
I recently ran the same experiment.
Once the LOs are properly locked to the reference, the time is synced to
the reference and you have tune the boards using timed commands at the
same time,
you should be left with a pretty stable output across all 4 TX channels.
There will, of course, be a fixed phase offset between the different
channels.
This offset will also depend on temperature.
Let me know if you have questions regarding the software implementation.
Cheers,
On 05/19/2017 01:50 PM, Vladica Sark via USRP-users wrote:
> Hi,
>
> I have two x310s with 2x UBX daughterboards in each. I bring 10MHz and
> 1 PPS from octoclock to the both of them. With tx_waveforms I transmit
> a CONST and record the resulting waveforms on a scope. The carrier is
> 2.45 GHz.
>
> The phase difference between the four available channels jumps for
> +-45 degrees randomly. Without these jumps, the phase difference would
> have probably been constant. This is the same for all of the channels.
>
> Is there a chance to phase sync the two x310s and the four transceivers?
>
> BR,
> Vladica
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 12
Date: Fri, 19 May 2017 08:38:15 -0400
From: Jason Matusiak <[email protected]>
To: EJ Kreinar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-modtool cores
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
EJ, that looks exactly like what I need to do. Is there a way for me to
patch in your changes so I can try to use them while we wait for Ettus
to (dis)approve your PR?
Thanks!
~Jason
On 05/18/2017 04:11 PM, EJ Kreinar wrote:
> Hi Jason,
>
> I currently have a PR in to the fpga repo
> (https://github.com/EttusResearch/fpga/pull/12
> <https://github.com/EttusResearch/fpga/pull/12>) that adds support for
> linking Makefile.inc files in OOT repos. Your OOT Makefile can then
> build the Xilinx IP and append it to your build as needed. I've been
> using this approach for some time now with success for both Xilinx IP
> and HLS designs.
>
> I have an action to provide a sample "dummy" OOT repo with the correct
> Makefiles-- but I havent gotten to it yet, unfortunately-- Was waiting
> for confirmation if this approach will be supported in-tree in the
> future. I could put something together soon though if this would help.
>
> I'd also be interested in other good solutions, if anyone has an
> alternate approach :)
>
> EJ
>
> On Thu, May 18, 2017 at 2:22 PM, Jason Matusiak via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> I wanted to create an RFNoC block that utilized some Xilinx cores.
> Where do I need to put these cores in the rfnoc-modtool project
> created directory structure, and how do I go about tying that into
> the Vivado GUI so I can build them up (just use the GUI=1 CL
> argument and do the save-as project approach?)?
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/acecbf9f/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 19 May 2017 15:09:57 +0200
From: Vladica Sark <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Phase sync multiple x310s
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Julian,
I think that I need to add something like
//we will tune the frontends in 100ms from now
uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
//sets command time on all devices
//the next commands are all timed
usrp->set_command_time(cmd_time);
//tune channel 0 and channel 1
usrp->set_rx_freq(1.03e9, 0); // Channel 0
usrp->set_rx_freq(1.03e9, 1); // Channel 1
//end timed commands
usrp->clear_command_time();
in the tx_waveforms but for the transmitter.
I would try this on Monday.
Anyway, in my case also the phase looks quite stable on the scope. The
45 degree jumps cannot be easily noticed. I acquire the data and with
post processing I come to these results.
BR,
Vladica
On 19.05.2017 14:05, Julian Arnold wrote:
> Hey Vladica,
>
> I recently ran the same experiment.
> Once the LOs are properly locked to the reference, the time is synced to
> the reference and you have tune the boards using timed commands at the
> same time,
> you should be left with a pretty stable output across all 4 TX channels.
> There will, of course, be a fixed phase offset between the different
> channels.
> This offset will also depend on temperature.
>
> Let me know if you have questions regarding the software implementation.
>
> Cheers,
>
> On 05/19/2017 01:50 PM, Vladica Sark via USRP-users wrote:
>> Hi,
>>
>> I have two x310s with 2x UBX daughterboards in each. I bring 10MHz and
>> 1 PPS from octoclock to the both of them. With tx_waveforms I transmit
>> a CONST and record the resulting waveforms on a scope. The carrier is
>> 2.45 GHz.
>>
>> The phase difference between the four available channels jumps for
>> +-45 degrees randomly. Without these jumps, the phase difference would
>> have probably been constant. This is the same for all of the channels.
>>
>> Is there a chance to phase sync the two x310s and the four transceivers?
>>
>> BR,
>> Vladica
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 14
Date: Fri, 19 May 2017 15:35:26 +0200
From: Julian Arnold <[email protected]>
To: Vladica Sark <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Phase sync multiple x310s
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hey Vladica,
> I think that I need to add something like
I haven't looked at tx_waveforms but here is a snipped from my code:
###############################################
this->usrp->set_clock_source("external"); //applies to all mboards
this->usrp->set_time_source("external"); //applies to all mboards
double tx_freq = 3.700010e9;
double rx_freq = 3.700000e9;
//Set time at next PPS to zero
this->usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
boost::this_thread::sleep(boost::posix_time::seconds(3));
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.3);
//sets command time on all devices
//the next commands are all timed
this->usrp->set_command_time(cmd_time);
this->usrp->set_tx_freq(tx_freq, 0);
this->usrp->set_tx_freq(tx_freq, 1);
this->usrp->set_tx_freq(tx_freq, 2);
uhd::tune_result_t freq_is = this->usrp->set_tx_freq(tx_freq, 3);
boost::this_thread::sleep(boost::posix_time::seconds(3));
//end timed commands
this->usrp->clear_command_time();
###############################################
What scope are you using? I was observing phase stability across the 4
channel on an DSO90804A and found it to be basically rock solid and
clearly visible
(As long as the temperature was constant. This meant to wait for
something like 10-30min after startup for the devices to reach final
operating temperature).
Also, which version of UHD are you running?
Cheers,
On 05/19/2017 03:09 PM, Vladica Sark via USRP-users wrote:
> Hi Julian,
>
> I think that I need to add something like
>
> //we will tune the frontends in 100ms from now
> uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
> //sets command time on all devices
> //the next commands are all timed
> usrp->set_command_time(cmd_time);
> //tune channel 0 and channel 1
> usrp->set_rx_freq(1.03e9, 0); // Channel 0
> usrp->set_rx_freq(1.03e9, 1); // Channel 1
> //end timed commands
> usrp->clear_command_time();
>
> in the tx_waveforms but for the transmitter.
> I would try this on Monday.
>
> Anyway, in my case also the phase looks quite stable on the scope. The
> 45 degree jumps cannot be easily noticed. I acquire the data and with
> post processing I come to these results.
>
> BR,
> Vladica
>
>
> On 19.05.2017 14:05, Julian Arnold wrote:
>> Hey Vladica,
>>
>> I recently ran the same experiment.
>> Once the LOs are properly locked to the reference, the time is synced to
>> the reference and you have tune the boards using timed commands at the
>> same time,
>> you should be left with a pretty stable output across all 4 TX channels.
>> There will, of course, be a fixed phase offset between the different
>> channels.
>> This offset will also depend on temperature.
>>
>> Let me know if you have questions regarding the software implementation.
>>
>> Cheers,
>>
>> On 05/19/2017 01:50 PM, Vladica Sark via USRP-users wrote:
>>> Hi,
>>>
>>> I have two x310s with 2x UBX daughterboards in each. I bring 10MHz and
>>> 1 PPS from octoclock to the both of them. With tx_waveforms I transmit
>>> a CONST and record the resulting waveforms on a scope. The carrier is
>>> 2.45 GHz.
>>>
>>> The phase difference between the four available channels jumps for
>>> +-45 degrees randomly. Without these jumps, the phase difference would
>>> have probably been constant. This is the same for all of the channels.
>>>
>>> Is there a chance to phase sync the two x310s and the four
>>> transceivers?
>>>
>>> BR,
>>> Vladica
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 15
Date: Fri, 19 May 2017 17:16:32 +0200
From: Vladica Sark <[email protected]>
To: Julian Arnold <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Phase sync multiple x310s
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Julian,
I am using Teledyne LeCroy HDO9404. I use UHD 3.10.1 which should be stable.
In my case, the signal on the scope also looks nice. Nevertheless, when
I precisely estimate the phase between the separate channels there are
these 45 degrees jumps. The phase offset itself is not a problem, if it
is constant, since it can be corrected.
I would try this with the timed commands to see if it helps, but on Monday.
BR,
Vladica
On 19.05.2017 15:35, Julian Arnold wrote:
> Hey Vladica,
>
>> I think that I need to add something like
> I haven't looked at tx_waveforms but here is a snipped from my code:
>
> ###############################################
>
> this->usrp->set_clock_source("external"); //applies to all mboards
> this->usrp->set_time_source("external"); //applies to all mboards
>
> double tx_freq = 3.700010e9;
> double rx_freq = 3.700000e9;
>
> //Set time at next PPS to zero
> this->usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
> boost::this_thread::sleep(boost::posix_time::seconds(3));
>
> uhd::time_spec_t cmd_time = usrp->get_time_now() +
> uhd::time_spec_t(0.3);
>
> //sets command time on all devices
> //the next commands are all timed
> this->usrp->set_command_time(cmd_time);
> this->usrp->set_tx_freq(tx_freq, 0);
> this->usrp->set_tx_freq(tx_freq, 1);
> this->usrp->set_tx_freq(tx_freq, 2);
> uhd::tune_result_t freq_is = this->usrp->set_tx_freq(tx_freq, 3);
>
> boost::this_thread::sleep(boost::posix_time::seconds(3));
> //end timed commands
> this->usrp->clear_command_time();
>
> ###############################################
>
> What scope are you using? I was observing phase stability across the 4
> channel on an DSO90804A and found it to be basically rock solid and
> clearly visible
> (As long as the temperature was constant. This meant to wait for
> something like 10-30min after startup for the devices to reach final
> operating temperature).
>
> Also, which version of UHD are you running?
>
> Cheers,
>
> On 05/19/2017 03:09 PM, Vladica Sark via USRP-users wrote:
>> Hi Julian,
>>
>> I think that I need to add something like
>>
>> //we will tune the frontends in 100ms from now
>> uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
>> //sets command time on all devices
>> //the next commands are all timed
>> usrp->set_command_time(cmd_time);
>> //tune channel 0 and channel 1
>> usrp->set_rx_freq(1.03e9, 0); // Channel 0
>> usrp->set_rx_freq(1.03e9, 1); // Channel 1
>> //end timed commands
>> usrp->clear_command_time();
>>
>> in the tx_waveforms but for the transmitter.
>> I would try this on Monday.
>>
>> Anyway, in my case also the phase looks quite stable on the scope. The
>> 45 degree jumps cannot be easily noticed. I acquire the data and with
>> post processing I come to these results.
>>
>> BR,
>> Vladica
>>
>>
>> On 19.05.2017 14:05, Julian Arnold wrote:
>>> Hey Vladica,
>>>
>>> I recently ran the same experiment.
>>> Once the LOs are properly locked to the reference, the time is synced to
>>> the reference and you have tune the boards using timed commands at the
>>> same time,
>>> you should be left with a pretty stable output across all 4 TX channels.
>>> There will, of course, be a fixed phase offset between the different
>>> channels.
>>> This offset will also depend on temperature.
>>>
>>> Let me know if you have questions regarding the software implementation.
>>>
>>> Cheers,
>>>
>>> On 05/19/2017 01:50 PM, Vladica Sark via USRP-users wrote:
>>>> Hi,
>>>>
>>>> I have two x310s with 2x UBX daughterboards in each. I bring 10MHz and
>>>> 1 PPS from octoclock to the both of them. With tx_waveforms I transmit
>>>> a CONST and record the resulting waveforms on a scope. The carrier is
>>>> 2.45 GHz.
>>>>
>>>> The phase difference between the four available channels jumps for
>>>> +-45 degrees randomly. Without these jumps, the phase difference would
>>>> have probably been constant. This is the same for all of the channels.
>>>>
>>>> Is there a chance to phase sync the two x310s and the four
>>>> transceivers?
>>>>
>>>> BR,
>>>> Vladica
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 16
Date: Fri, 19 May 2017 11:55:53 -0400
From: Richard Mcallister <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC: Time Share a CE
Message-ID:
<calng9qm+qs-uzqldnk9rm6yxkk9wqzn1jyas_v1kudmbq8x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I saw that on the presentation here on the Ettus site (
https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_FPGA.pdf), it
mentions you can timeshare functions between multiple streams. I can't find
any other documentation on that or examples, and I'm not exactly sure where
to start with this. Does anyone have experience in this and can point me
on the right direction?
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170519/879587a5/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 81, Issue 19
******************************************
