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. Overflows when doing repeated captures with X300
(Perelman, Nathan)
2. Re: X310/UBX Retuning Performance (Dave NotTelling)
3. Error at receiving end of usrp/2901 (Ozair Iqbal)
4. Re: No GPSDO found message (Roman Olesyuk)
5. Re: Two X310s synchronization and a phase drift (Roman Olesyuk)
6. Re: Two X310s synchronization and a phase drift (Marcus D. Leech)
7. Severe underruns with uhd_siggen on 3.10.1.1 UHD (Roman Olesyuk)
8. B200mini USB3 question (Jason Matusiak)
9. Re: B200mini USB3 question (Marcus D. Leech)
10. Re: Two X310s synchronization and a phase drift (Roman Olesyuk)
11. Re: Two X310s synchronization and a phase drift (Marcus D. Leech)
12. Re: Error at receiving end of usrp/2901 (Fernando)
13. Re: B200mini USB3 question (Jason Matusiak)
14. Re: Link LED blinking RED (El Ouni, Naceur (IntlAssoc))
15. Re: B200mini USB3 question (Marcus D. Leech)
16. fail to transmit a signal by USRP/2901 using
gnuradio-companion software (Ozair Iqbal)
17. Transmission of signal failure using USRP/2901 by
gnuradio-companion (Ozair Iqbal)
18. Re: Two X310s synchronization and a phase drift (Roman Olesyuk)
19. axi_wrapper with simple_mode=0... help me (Paolo Palana)
20. E312: Cannot find command 'git' (do ber)
21. Re: UBX-160: Receiver with 160MHz bandwidth (do ber)
22. Segmentation fault while accessing user registers (Philipp Rudnik)
23. Re: E312: Cannot find command 'git' (Jason Matusiak)
24. Re: Transmission of signal failure using USRP/2901 by
gnuradio-companion (Jason Matusiak)
25. Re: E312: Cannot find command 'git' (do ber)
26. Re: Transmission of signal failure using USRP/2901 by
gnuradio-companion (Marcus D. Leech)
27. Re: E312: Cannot find command 'git' (Jason Matusiak)
28. Re: B200mini USB3 question (Jason Matusiak)
29. USB 3 hub for B200/B200mini (Sean Nowlan)
30. Receiving Bursts Control Question (Xingjian Chen)
31. [USRP-Users]Promblems with realizing Feedback with two USRP
with XCVR2450 daughterboard (???)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Mar 2017 17:22:42 +0000
From: "Perelman, Nathan" <[email protected]>
To: Ben Hilburn via USRP-users <[email protected]>
Subject: [USRP-users] Overflows when doing repeated captures with X300
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
When using the same multiusrp object to do repeated captures with an X300, I'm
seeing the 2nd (and 3rd, 4th) captures fail with an overflow error (D printed
out). Is there an additional wait step or sensor to wait on for the X300? This
same code works fine for repeated captures with an N210 and B210. To
demonstrate this issue, I added a loop to rx_samples_to_file to have it do
multiple captures (starting at line 333):
for(int i = 0; i < 4; i++)
{
std::cout << "Capture " << i << std::endl;
//recv to file
if (type == "double") recv_to_file<std::complex<double>
>recv_to_file_args("fc64");
else if (type == "float") recv_to_file<std::complex<float>
>recv_to_file_args("fc32");
else if (type == "short") recv_to_file<std::complex<short>
>recv_to_file_args("sc16");
else throw std::runtime_error("Unknown type " + type);
}
The output is:
$ ./rx_samples_to_file --args type=x300 --rate 6250000 --duration 1 --freq
800000000 --null
linux; GNU C++ version 5.3.1 20160406 (Red Hat 5.3.1-6); Boost_106000;
UHD_003.010.001.001-0-unknown
Creating the usrp device with: type=x300...
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... Found an internal GPSDO: LC_XO, Firmware Rev
0.929a
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1183.9MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1186.0MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X300
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: UBX RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: UBX TX
Setting RX Rate: 6.250000 Msps...
Actual RX Rate: 6.250000 Msps...
Setting RX Freq: 800.000000 MHz...
Actual RX Freq: 800.000000 MHz...
Waiting for "lo_locked": ++++++++++ locked.
Press Ctrl + C to stop streaming...
Capture 0
Capture 1
DGot an overflow indication. Please consider the following:
Your write medium must sustain a rate of 25.000000MB/s.
Dropped samples will not be written to the file.
Please modify this example for your purposes.
This message will not appear again.
Capture 2
DGot an overflow indication. Please consider the following:
Your write medium must sustain a rate of 25.000000MB/s.
Dropped samples will not be written to the file.
Please modify this example for your purposes.
This message will not appear again.
Capture 3
DGot an overflow indication. Please consider the following:
Your write medium must sustain a rate of 25.000000MB/s.
Dropped samples will not be written to the file.
Please modify this example for your purposes.
This message will not appear again.
Done!
Any ideas on where I might be going wrong?
-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170308/17e328d6/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 8 Mar 2017 12:22:52 -0500
From: Dave NotTelling <[email protected]>
To: Michael West <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX Retuning Performance
Message-ID:
<CAK6GVuNu80=+WBrotvsXYtxf15=za4crymewqwuts0o7++a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Well poop. Thank you for the information!
On Wed, Mar 8, 2017 at 11:28 AM, Michael West <[email protected]>
wrote:
> Hi Dave,
>
> Sorry for the delay. Performance mode is the default mode and will not
> help speed up the transition. One option is to have a pair of UBX boards
> with one on the low band and one on the high band.
>
> Regards,
> Michael
>
> On Wed, Mar 8, 2017 at 4:54 AM, Dave NotTelling via USRP-users <
> [email protected]> wrote:
>
>> Anyone have any information about whether or not changing to performance
>> mode from power save will help speed up the transition between the two
>> bands?
>>
>> On Mon, Mar 6, 2017 at 12:37 PM, Dave NotTelling <[email protected]>
>> wrote:
>>
>>> *bump*
>>>
>>> On Fri, Mar 3, 2017 at 10:27 AM, Dave NotTelling <[email protected]>
>>> wrote:
>>>
>>>> Can performance mode help with the > 100ms tuning time between the two
>>>> bands? I seem to recall the performance mode setting relating to when the
>>>> unused PA is powered off. Also, is the long tuning time something that the
>>>> UHD code causes or is that just a number that the developer should keep in
>>>> mind when switching bands?
>>>>
>>>> Thanks!
>>>>
>>>> On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling <[email protected]>
>>>> wrote:
>>>>
>>>>> Thanks!
>>>>>
>>>>> On Fri, Feb 24, 2017 at 3:32 PM, Marcus M?ller via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Largely: Yes; the UBX160 and UBX40 only differ in their baseband
>>>>>> filters' passive component values (see the schematics).
>>>>>>
>>>>>> There's a bit of a difference on how you can clock the UBX on N210,
>>>>>> but that won't change behaviour all that much. Also, due to the 100 MHz
>>>>>> instead of X3xx's 200 MHz master clock rate, your timing granularity is
>>>>>> twice as bad :)
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Marcus
>>>>>> On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
>>>>>>
>>>>>> Do these tuning/settling times also hold true for the UBX-40 in an
>>>>>> N210?
>>>>>>
>>>>>> On Fri, Feb 24, 2017 at 2:47 PM, Derek Kozel via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi Jason,
>>>>>>>
>>>>>>> If you use the set_command_time function to cause the tune to occur
>>>>>>> at a specific time then you can use the in-band timestamps from the recv
>>>>>>> call to identify the sample when the tune action started. The 500us of
>>>>>>> samples following that timestamp are the ones you would want to discard.
>>>>>>>
>>>>>>> An example of setting the execution time for a command:
>>>>>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>>>>>> es/test_timed_commands.cpp#L96
>>>>>>>
>>>>>>> An example of starting streaming at a set time:
>>>>>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>>>>>> es/test_timed_commands.cpp#L129
>>>>>>>
>>>>>>> Regards,
>>>>>>> Derek
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Feb 24, 2017 at 11:27 AM, Jason Roehm via USRP-users <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> On 02/24/2017 01:24 PM, Michael West via USRP-users wrote:
>>>>>>>>
>>>>>>>>> Hi Devin,
>>>>>>>>>
>>>>>>>>> I have measured the UBX tune time. The SPI writes to tune the LO
>>>>>>>>> take ~30-60us and the LO lock time is 400us. I recommend discarding
>>>>>>>>> at
>>>>>>>>> least 500us of samples after the LO tune. I also recommend continuous
>>>>>>>>> streaming of samples so the frontend components are not switched on
>>>>>>>>> and
>>>>>>>>> off, which can cause long transients. For the UBX-160, set the
>>>>>>>>> dboard_clock_rate to 20e6 and tune the LO in steps of 160 MHz. If
>>>>>>>>> using a
>>>>>>>>> sample rate <200 Msps, use DSP tuning (which takes < 1us) for the
>>>>>>>>> frequencies between the 160MHz steps. With that, you should be able
>>>>>>>>> to
>>>>>>>>> tune across the full 6GHz in ~18ms in theory. There is one caveat.
>>>>>>>>> There
>>>>>>>>> are 2 LNAs on the UBX, one for <1.5 GHz and one for above. Only one
>>>>>>>>> can be
>>>>>>>>> powered on at a time and the warm up time is significant (in the 100s
>>>>>>>>> of
>>>>>>>>> milliseconds for the low band LNA and 10s of milliseconds for the
>>>>>>>>> high band
>>>>>>>>> LNA),, so you would be best suited using one daughterboard for the
>>>>>>>>> low band
>>>>>>>>> and one for the high band for the fastest sweep time.
>>>>>>>>>
>>>>>>>>> Unfortunately, I do not have the same experience with the TwinRX,
>>>>>>>>> so i cannot advise on it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Not to hijack this thread, but do you have any recommendations on
>>>>>>>> the most effective way to properly time the "discard 500us of samples
>>>>>>>> after
>>>>>>>> the LO tune?" One of the drawbacks of using the USRP family for
>>>>>>>> applications that require fast retuning is that there isn't (from what
>>>>>>>> I
>>>>>>>> can tell) any in-band indication of what center frequency the radio is
>>>>>>>> tuned to. The control interface (e.g. through
>>>>>>>> multi_usrp::set_rx_center_freq())
>>>>>>>> is completely separate from the data streaming interface, so if I call
>>>>>>>> set_rx_center_freq() at time T, I have no way of accurately estimating
>>>>>>>> when
>>>>>>>> the tune will actually be complete in the data stream.
>>>>>>>>
>>>>>>>> This seems to be a disadvantage of the CHDR protocol that
>>>>>>>> contemporary USRPs use; they seem to carry data samples and timetags,
>>>>>>>> but
>>>>>>>> nothing else. VITA 49 is nice in that it can provide full context in
>>>>>>>> timetagged packets, so you can get updates as to the radio state (e.g.
>>>>>>>> frequency, gain) that are aligned as closely as possible with the
>>>>>>>> associated samples from the SDR.
>>>>>>>>
>>>>>>>> Jason
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing
>>>>>> [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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/20170308/2e58dd85/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 8 Mar 2017 22:33:36 +0500
From: Ozair Iqbal <[email protected]>
To: [email protected]
Subject: [USRP-users] Error at receiving end of usrp/2901
Message-ID:
<camqc7dst4tp5facsarsjk9lwreqyjed3hrocqyzyrymnbza...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
I am using one USRP/2901 as transmitter of signal while on the other
end i am using other usrp/2901 as receiving the signal but at the
receiving end i am receiving following error
UHD Error:
USB open failed: insufficient permissions.
See the application notes for your device.
Traceback (most recent call last):
File "/home/uzair/top_block.py", line 95, in <module>
main()
File "/home/uzair/top_block.py", line 89, in main
tb = top_block_cls()
File "/home/uzair/top_block.py", line 66, in __init__
channels=range(1),
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2671, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: LookupError: KeyError: No devices found for ----->
Empty Device Address
Regards,
Ozair Iqbal (RA)
ITU,Lahore
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170308/9f9b19c4/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 8 Mar 2017 22:42:39 +0300
From: Roman Olesyuk <[email protected]>
To: Michael West <[email protected]>
Cc: Nikita Airee <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] No GPSDO found message
Message-ID:
<camzegnhmr3art42hxx3ysepdmytcqg7nwcs6k6n1jmjgock...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Sorry for the late reply and thank you very much for your suggestion.
Currently I am on UHD 3.10.1.1 from official Ubuntu PPA (with all GNU Radio
and friends framework depending on 3.10 API). So first I have tried to
build from sources 3.10.1.1 tag
https://github.com/EttusResearch/uhd/tree/release_003_010_001_001 with
different timeouts. So relative constant in this version
is GPS_COMM_TIMEOUT_MS used at
https://github.com/EttusResearch/uhd/blob/release_003_010_001_001/host/lib/usrp/gps_ctrl.cpp#L209
I
changed it's value from 1300 to 10000. I also tried
changing GPS_TIMEOUT_DELAY_MS and GPSDO_COMMAND_DELAY_MS from 200 ms to
1000 ms (just in case). It turns out that if GPS_COMM_TIMEOUT_MS value is
increased GPSDO is detected as "generic NMEA GPS device", but it does not
work:
$ ./sync_to_gps
...
-- Detecting internal GPSDO.... Found a generic NMEA GPS device
...
UHD Warning:
locked: ValueError: gps ctrl: No GPGGA message found
UHD Warning:
locked: ValueError: gps ctrl: No GPGGA message found
UHD Warning:
locked: ValueError: gps ctrl: No GPGGA message found
Error: ValueError: locked(): unable to determine GPS lock statusThis could
mean that you have
not installed the GPSDO correctly.
Then I have built UHD from the master branch (3.11). In this version in
gps_ctrl.cpp at 210 line the timeout is hardcoded to 650 ms which is twice
as less than GPS_COMM_TIMEOUT_MS = 1300 used in 3.10. But using the master
branch GPSDO is detected and works just OK without any modifications. I
have not done any code inspection of the differences between 3.10.1.1 and
3.11 master version. But it seems that the issue is fixed in the master
branch. I would appreciate (and may be others too) if the fix is backported
to the 3.10 branch as it is current stable release.
2017-03-01 22:24 GMT+03:00 Michael West <[email protected]>:
> When using PCIe, the FPGA image is reloaded. That causes a reset of the
> GPSDO. The changes in the commit attempted to wait long enough for the
> GPSDO firmware to initialize, but not so long as to slow down device
> initialization if no GPSDO was present. You can try increasing the timeout
> on this line to see if it fixes the issue: https://github.com/
> EttusResearch/uhd/blob/master/host/lib/usrp/gps_ctrl.cpp#L210
>
> Regards,
> Michael
>
> On Tue, Feb 28, 2017 at 1:57 AM, Roman Olesyuk <[email protected]>
> wrote:
>
>> Hi Michael,
>>
>> I use the latest UHD and FPGA image 3.10.1.1 and still experiece this
>> issue. My OS is Ubuntu 16.04.2, kernel 4.4.0-64-generic #85 x86_64, NI RIO
>> drivers 15.0.0. In addition I have unstable PPS/GPS LOCK behavior as
>> desribed in my previous email (e.g. stable PPS/GPS LOCK only when PC with
>> PCIe card is power off).
>>
>> --
>> ? ?????????, ????? ??????.
>> Yours sincerely, Roman Olesyuk.
>>
>>
>> 28 ????. 2017 ?. 10:33 ???????????? "Nikita Airee" <[email protected]>
>> ???????:
>>
>> No Roman, I don't see such a behaviour in my USRP. Because in my case the
>> GPS refuses to lock but the PPS works fine blinking every second. Did you
>> try the patch? Does it work for you?
>>
>> Michael, thanks for your suggestion! But it seems like it is not working
>> for me. It is entirely possible that I may be doing something wrong because
>> I have never patched a commit before. But the gps_ctrl.cpp file does change
>> at its location <working directory>/uhd/host/usrp/.
>>
>> Also for when the gpsdo does work, ie with Ethernet, how do I get this
>> gpsdo to lock? I suppose simply running sync_to_gps should time and
>> reference lock my gpsdo?
>>
>> Bests,
>> Nikita
>>
>>
>> On Tue, Feb 28, 2017 at 4:06 AM, Michael West <[email protected]>
>> wrote:
>>
>>> Hi Nikita,
>>>
>>> Sadly, we know what this issue is. We sped up the X300 initialization
>>> so much that the firmware on the GPSDO does not have time to finish
>>> initializing before the detection code runs. The problem was fixed in the
>>> 3.10.1.1 release, but for some reason the fix did not get applied to the
>>> 3.9.6 release. The specific commit that is needed is
>>> https://github.com/EttusResearch/uhd/commit/63fcfb9574d64797
>>> b807a0dd356f5d7bfc48f082
>>>
>>> You can try to patch with that commit until we get it properly fixed.
>>> We should have it fixed on the LTS branch soon.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Mon, Feb 27, 2017 at 12:27 PM, Roman Olesyuk via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi Nikita,
>>>>
>>>> I experience the same issue. In addition I observe the following
>>>> behavior. I checked LEDs on GPSDO board. Two green LEDs are on for
>>>> several seconds when I power on X310 and then they go off. If the PCIe
>>>> connector is plugged in, but PC is powered off, in about 30-60 seconds I
>>>> observe that PPS LED starts blinking once per seconds, and after about 10
>>>> minutes GPS LOCK LED (on GPSDO boards and on the front panel) goes on. This
>>>> is very stable behavior when PCIe IS PLUGGED IN, BUT PC IS OFF. I can get
>>>> very stable GPS lock (the LED is on as long as I can observe) and PPS is
>>>> always blinking. If I use 1Gbps network connection (with PCIe connector
>>>> unplugged) or if I use PCIe connection (just power on X310, then power on
>>>> PC), I do not see PPS blinking even after several minutes. Sometimes PPS
>>>> LED goes blinking and after 10-60 seconds it goes off again. Very rarely I
>>>> can see PPS blinking for several minutes and GPS LOCK LED is even rarer
>>>> (almost never see it). The behaviors are almost the same in PCIe and 1Gbps
>>>> modes. So it looks for me like some FPGA/GPSDO initialization problem.
>>>>
>>>> Can you confirm my observations?
>>>>
>>>> --
>>>> Yours sincerely, Roman Olesyuk.
>>>>
>>>> 2017-02-27 13:43 GMT+03:00 Nikita Airee via USRP-users <
>>>> [email protected]>:
>>>>
>>>>> Hi list,
>>>>>
>>>>> the information I had provided might not have been enough. So here is
>>>>> some more:
>>>>>
>>>>> My X310 has internal GPSDO. This is visible to UHD when I perform
>>>>> uhd_usrp_probe provided it is connected to my laptop using Gigabit
>>>>> ethernet:
>>>>>
>>>>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>>>>
>>>>> -- X300 initialization sequence...
>>>>> -- Determining maximum frame size... 1472 bytes.
>>>>> -- Setup basic communication...
>>>>> -- Loading values from EEPROM...
>>>>> -- Setup RF frontend clocking...
>>>>> -- Radio 1x clock:200
>>>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>>>> Firmware Rev 0.929a*
>>>>> -- Initialize Radio0 control...
>>>>> -- Performing register loopback test... pass
>>>>> -- Initialize Radio1 control...
>>>>> -- Performing register loopback test... pass
>>>>> ...
>>>>>
>>>>> However, when I use PCI Express for connection, it says:
>>>>>
>>>>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>>>>
>>>>> -- X300 initialization sequence...
>>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>>>> rp_x310_fpga_HGS.lvbitx...
>>>>> -- Setup basic communication...
>>>>> -- Loading values from EEPROM...
>>>>> -- Setup RF frontend clocking...
>>>>> -- Radio 1x clock:200
>>>>> --
>>>>>
>>>>>
>>>>> *Detecting internal GPSDO.... UHD Error: GPS invalid reply "",
>>>>> assuming none availableNo GPSDO found*
>>>>> -- Initialize Radio0 control...
>>>>> -- Performing register loopback test... pass
>>>>> -- Initialize Radio1 control...
>>>>> -- Performing register loopback test... pass
>>>>> ...
>>>>>
>>>>> When the same USRP is connected to a laptop with a different UHD
>>>>> version via PCIe, I get:
>>>>>
>>>>> linux; GNU C++ version 4.8.2; Boost_106000; UHD_3.11.0.git-28-gc66cb1ba
>>>>>
>>>>> -- X300 initialization sequence...
>>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>>>> rp_x310_fpga_HG.lvbitx...
>>>>> -- Setup basic communication...
>>>>> -- Loading values from EEPROM...
>>>>> -- Setup RF frontend clocking...
>>>>> -- Radio 1x clock:200
>>>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>>>> Firmware Rev 0.929a*
>>>>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1186.1MB/s)
>>>>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1189.4MB/s)
>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>> -- Performing timer loopback test... pass
>>>>> -- Performing timer loopback test... pass
>>>>> ...
>>>>>
>>>>> Also when I try sync_to_gps, it says:
>>>>> ...
>>>>> Waiting for reference lock...LOCKED
>>>>> *WARNING: GPS not locked - time will not be accurate until locked *
>>>>> USRP time: 1136078288.000000000
>>>>> GPSDO time: 1136078288.000000000
>>>>>
>>>>> SUCCESS: USRP time synchronized to GPS time
>>>>>
>>>>> On querying gpsdo sensors soon after, I find that :
>>>>>
>>>>> USRP Locked to GPSDO 10 MHz Reference.
>>>>>
>>>>> GPS and UHD Device time are NOT aligned;
>>>>> last_pps: 9 vs gps: 1136078227. Trying to set the device time to GPS
>>>>> time...
>>>>> -- 1) catch time transition at pps edge
>>>>> -- 2) set times next pps (synchronously)
>>>>> last_pps: 1136078231 vs gps: 1136078231.
>>>>> GPS and UHD Device time are aligned.
>>>>> Printing available NMEA strings:
>>>>> GPS_GPGGA: $GPGGA,011711.00,0000.0000,N,0
>>>>> 0000.0000,E,0,99,1.0,0.0,M,0.0,M,,*5B
>>>>> GPS_GPRMC: $GPRMC,011711.00,V,0000.0000,N
>>>>> ,00000.0000,E,0.0,0.0,010106,,*25
>>>>> GPS Epoch time at last PPS: 1136078232.00000 seconds
>>>>> UHD Device time last PPS: 1136078232.00000 seconds
>>>>> UHD Device time right now: 1136078232.27291 seconds
>>>>> PC Clock time: 1487756260 seconds
>>>>> ...
>>>>>
>>>>> Could anybody please help me with this? I suppose that when the gps is
>>>>> locked, it means that uhd is time aligned with gps? If so, I would also
>>>>> really like to know exactly how you permanently lock gps.
>>>>>
>>>>> Bests,
>>>>> Nikita Airee
>>>>>
>>>>>
>>>>> On Tue, Feb 21, 2017 at 8:20 PM, Nikita Airee <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi list,
>>>>>>
>>>>>> I have:
>>>>>>
>>>>>> Ubuntu 14.04
>>>>>>
>>>>>> UHD: 003.009.006-0-g122d5f8e
>>>>>>
>>>>>> USRP X310 with CBX20 + GPSDO
>>>>>>
>>>>>> I moved to UHD 3.9.6 very recently and since then have been facing the
>>>>>> following issue related to GPSDO:
>>>>>>
>>>>>> *UHD Error: GPS invalid reply "", assuming none available
>>>>>> No GPSDO found*
>>>>>>
>>>>>> UHD_3.11.0.git-28-gc66cb1ba would never throw up this message.
>>>>>>
>>>>>> Is this a known issue? If not, how do I use GPSDO?
>>>>>>
>>>>>> Bests,
>>>>>>
>>>>>> Nikita Airee
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ? ?????????, ????? ??????.
>>>> Yours sincerely, Roman Olesyuk.
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>>
>
--
? ?????????, ????? ??????.
Yours sincerely, Roman Olesyuk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170308/91599569/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 8 Mar 2017 23:04:09 +0300
From: Roman Olesyuk <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Two X310s synchronization and a phase drift
Message-ID:
<CAMZegnGH4oDEy9rv=i_rk9fngbfrjuayn-sjmd_hj0g1x9r...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi mleech,
Thank you very much for the clarification.
Actually I was trying to reproduce "Direction Finding with the USRP
X-Series and TwinRX"
https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
example but with two X310s with two SBX120 in each instead of one X310 with
two TwinRX. I can see that in this example LO is shared between two TwinRX
daughterboards using two coax cables which connect these daughterboards
directly. This effectively creates the same asymmetric layout as in my
case: LO is generated on the first daughterboard and then transferred to
the second one via cables. And according to the article such a system has
"constant repeatable relative phase offsets" between channels (which is
calibrated out). So it look like there is no (?) any thermal drift. Or at
least it can be interpreted as if there is "constant repeatable relative
phase offsets" in equilibrium state (e.g. after warm-up). But in my case
the phase difference between channels on different USRPs is not repeatable
even after the warm-up, but it is constant between channels on the same
USRP. So I think may be the problem is not only (if any) in asymmetrical
cable layout but also in some setup issues or clock
synchronization/distribution part...
2017-02-28 1:13 GMT+03:00 <[email protected]>:
> Roman:
>
> There will be a fixed phase-offset proportional to the length of your
> daisy-chaining cables, and the effective electrical length of the circuitry
> inside the "master" X310 that mirrors the 1PPS and 10MHz internal
> signals. BOTH of these can experience thermal drift, and there is almost
> *guaranteed* to be thermal drift between the internal 10MHz/1PPS signals
> inside the X310 and the cables that are carrying those signals to your 2nd
> X310.
>
>
>
> The best way to set up systems like this is with a common clock source,
> like the Octoclock or Octoclock-G, using equal-lengths of 10MHz and 1PPS
> cabling to each X310 (or other USRP) that is served by the Octoclock. The
> internal circuitry inside the Octoclock is designed to be phase-matched,
> and while it *will* thermal drift, it will all thermal drift at the same
> rate. Similarly, your external cables, if all the same type and length
> will provide good long-term phase coherence if they're all in the same type
> of thermal environment.
>
>
>
>
>
>
>
>
> On 2017-02-27 15:46, Roman Olesyuk via USRP-users wrote:
>
> Hi Everybody,
>
> I have an issue while trying to synchronize two X310s for MIMO
> application. I have the following setup.
>
> Two X310s with two SBX120 in each are connected to the same PC (using PCIe
> or 1Gbps connection). So in total I have four channels 0, 1, 2, 3. Master
> X310 has GPSDO, but currently I do not use it, only the internal clock is
> used. Master's PPS out and clock out are connected to slave's PPS in and
> clock in. On all 4 RF inputs I transmit 10kHz sine wave at 2.45 GHz @ 1MHz
> bandwidth from bladeRF via 4-way splitter. Then my workflow is as follows:
>
> 1. create multi_usrp interface
> 2. set_clock_source("internal", 0); // On master
> 3. set_time_source("internal", 0); // On master
> 4. set_clock_source("external", 1); // On slave
> 5. set_time_source("external", 1); // On slave
> 6. set_time_unknown_pps(uhd::time_spec_t(0.0));
> 7. set RX LO center frequency with a time spec synchronously on the
> master and on the slave
> 8. issue stream command to multi_usrp with the time spec in future for
> 10000 samples 1000 times with 1 second pause, write buffers to the file,
> thus the total timespan is about 20 minutes.
>
> When I calculate phase difference relative to channel 0 for channels 1, 2,
> 3, I get the following result. The phase of channel 1 (on the same X310 as
> channel 0, on the master) is stable over the whole timespan. The phases of
> channels 2, 3 have a slow drift about 1 radian per minute relative the
> channel 0. Channels 2, 3 (on the same X310, the slave) drift synchronously,
> that is no drift between channels 2 and 3. It looks like LO PLLs work fine
> (taking into account that there is no phase drift between two SBX120 in the
> same X310 and that SBX120s do not share the LO). Also the phase drift fades
> out (looks exponential). In some experiments I see more stable picture, in
> the rest the drift is as described above.
>
> What can be a problem here?
>
> --
> ? ?????????, ????? ??????.
> Yours sincerely, Roman Olesyuk.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
? ?????????, ????? ??????.
Yours sincerely, Roman Olesyuk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170308/2fe61718/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 08 Mar 2017 15:11:50 -0500
From: "Marcus D. Leech" <[email protected]>
To: Roman Olesyuk <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Two X310s synchronization and a phase drift
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 03/08/2017 03:04 PM, Roman Olesyuk wrote:
> Hi mleech,
>
> Thank you very much for the clarification.
>
> Actually I was trying to reproduce "Direction Finding with the USRP
> X-Series and TwinRX"
> https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
>
> example but with two X310s with two SBX120 in each instead of one X310
> with two TwinRX. I can see that in this example LO is shared between
> two TwinRX daughterboards using two coax cables which connect these
> daughterboards directly. This effectively creates the same asymmetric
> layout as in my case: LO is generated on the first daughterboard and
> then transferred to the second one via cables. And according to the
> article such a system has "constant repeatable relative phase offsets"
> between channels (which is calibrated out). So it look like there is
> no (?) any thermal drift. Or at least it can be interpreted as if
> there is "constant repeatable relative phase offsets" in equilibrium
> state (e.g. after warm-up). But in my case the phase difference
> between channels on different USRPs is not repeatable even after the
> warm-up, but it is constant between channels on the same USRP. So I
> think may be the problem is not only (if any) in asymmetrical cable
> layout but also in some setup issues or clock
> synchronization/distribution part...
>
>
> 2017-02-28 1:13 GMT+03:00 <[email protected] <mailto:[email protected]>>:
>
> Roman:
>
> There will be a fixed phase-offset proportional to the length of
> your daisy-chaining cables, and the effective electrical length of
> the circuitry inside the "master" X310 that mirrors the 1PPS and
> 10MHz internal signals. BOTH of these can experience thermal
> drift, and there is almost *guaranteed* to be thermal drift
> between the internal 10MHz/1PPS signals inside the X310 and the
> cables that are carrying those signals to your 2nd X310.
>
> The best way to set up systems like this is with a common clock
> source, like the Octoclock or Octoclock-G, using equal-lengths of
> 10MHz and 1PPS cabling to each X310 (or other USRP) that is served
> by the Octoclock. The internal circuitry inside the Octoclock is
> designed to be phase-matched, and while it *will* thermal drift,
> it will all thermal drift at the same rate. Similarly, your
> external cables, if all the same type and length will provide good
> long-term phase coherence if they're all in the same type of
> thermal environment.
>
> On 2017-02-27 15:46, Roman Olesyuk via USRP-users wrote:
>
>> Hi Everybody,
>> I have an issue while trying to synchronize two X310s for MIMO
>> application. I have the following setup.
>> Two X310s with two SBX120 in each are connected to the same PC
>> (using PCIe or 1Gbps connection). So in total I have four
>> channels 0, 1, 2, 3. Master X310 has GPSDO, but currently I do
>> not use it, only the internal clock is used. Master's PPS out and
>> clock out are connected to slave's PPS in and clock in. On all 4
>> RF inputs I transmit 10kHz sine wave at 2.45 GHz @ 1MHz bandwidth
>> from bladeRF via 4-way splitter. Then my workflow is as follows:
>>
>> 1. create multi_usrp interface
>> 2. set_clock_source("internal", 0); // On master
>> 3. set_time_source("internal", 0); // On master
>> 4. set_clock_source("external", 1); // On slave
>> 5. set_time_source("external", 1); // On slave
>> 6. set_time_unknown_pps(uhd::time_spec_t(0.0));
>> 7. set RX LO center frequency with a time spec synchronously on
>> the master and on the slave
>> 8. issue stream command to multi_usrp with the time spec in
>> future for 10000 samples 1000 times with 1 second pause,
>> write buffers to the file, thus the total timespan is about
>> 20 minutes.
>>
>> When I calculate phase difference relative to channel 0 for
>> channels 1, 2, 3, I get the following result. The phase of
>> channel 1 (on the same X310 as channel 0, on the master) is
>> stable over the whole timespan. The phases of channels 2, 3 have
>> a slow drift about 1 radian per minute relative the channel 0.
>> Channels 2, 3 (on the same X310, the slave) drift synchronously,
>> that is no drift between channels 2 and 3. It looks like LO PLLs
>> work fine (taking into account that there is no phase drift
>> between two SBX120 in the same X310 and that SBX120s do not share
>> the LO). Also the phase drift fades out (looks exponential). In
>> some experiments I see more stable picture, in the rest the drift
>> is as described above.
>> What can be a problem here?
>> --
>> ? ?????????, ????? ??????.
>> Yours sincerely, Roman Olesyuk.
>>
>> _______________________________________________
>> 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>
>
>
>
>
> --
> ? ?????????, ????? ??????.
> Yours sincerely, Roman Olesyuk.
There will NOT be a repeatable phase-offset between your TwinRX and SBX
modules. Because they have totally different PLL synthesizer
architectures--even though they share a reference clock. This will
have to be calibrated every time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170308/1af7eb5d/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 8 Mar 2017 23:23:25 +0300
From: Roman Olesyuk <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Severe underruns with uhd_siggen on 3.10.1.1 UHD
Message-ID:
<camzegnglqnhycdsku0eutnxesbj0kp3uesg__wh2c6iyogi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I experience severe underruns (a lot of UUU... messages) when trying
to uhd_siggen from 3.10.1.1 UHD with the following command:
$ uhd_siggen --args "resource=RIO0" --spec "A:0" --antenna "TX/RX"
--samp-rate 20e6 --gain 0 --freq 1152e6 --clock-source "internal" --const
My setup is the following:
ASUS Z170M-PLUS, Intel Core i7-6700K, 32Gb RAM, SSD,
Ubuntu 16.04 64 bit, 4.4 kernel, NI RIO 15.0.0 drivers,
Latest stable UHD 3.10.1.1 from official Ubuntu PPA ppa:ettusresearch/uhd +
GNU Radio 3.7.10 from ppa:myriadrf/gnuradio,
X310 with two SBX120 is connected via PCIe, PCIe interface card is in the
first x16 PCIe slot.
I also tried to run uhd_siggen with lower sample rates but still have a lot
of underruns. Is this behavior normal? It looks like this PC should be able
to produce constant samples at 20 Msps.
--
? ?????????, ????? ??????.
Yours sincerely, Roman Olesyuk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170308/90aba7c6/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 8 Mar 2017 15:24:43 -0500
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B200mini USB3 question
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I am playing with the mini and a Motorola Moto Z MotoMod and having a
weird issue. When in USB3 mode, the motoMod powers the mini and I can
see the microcontroller in the firmware recognizing that a device was
plugged in, but the mini doesn't enumerate with Android.
Someone pointed out that the MotoMod's "USB3 support is really just the
super speed lines only, i.e. there is no d+, d-."
I know that the d+/- are wired up for the USB2.1 protocol on the mini,
but is something needed for the mini on those lines when using it in
USB3 mode? (the MotoMod's USB3 mode is strictly a USB3 phy, so it does
not auto-negotiate to USB2.1 if needed)
------------------------------
Message: 9
Date: Wed, 08 Mar 2017 15:33:28 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200mini USB3 question
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 03/08/2017 03:24 PM, Jason Matusiak via USRP-users wrote:
> I am playing with the mini and a Motorola Moto Z MotoMod and having a
> weird issue. When in USB3 mode, the motoMod powers the mini and I can
> see the microcontroller in the firmware recognizing that a device was
> plugged in, but the mini doesn't enumerate with Android.
>
> Someone pointed out that the MotoMod's "USB3 support is really just
> the super speed lines only, i.e. there is no d+, d-."
>
> I know that the d+/- are wired up for the USB2.1 protocol on the mini,
> but is something needed for the mini on those lines when using it in
> USB3 mode? (the MotoMod's USB3 mode is strictly a USB3 phy, so it does
> not auto-negotiate to USB2.1 if needed)
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
The FX3 comes up in USB-2.0 mode, and switches later on in the process.
------------------------------
Message: 10
Date: Wed, 8 Mar 2017 23:44:34 +0300
From: Roman Olesyuk <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Two X310s synchronization and a phase drift
Message-ID:
<camzegnhrpaodcejmuqwx7yyqpfenlw-0ogj9voqed8hafhh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
Thank you for you reply!
May be I was not clear enough describing my setup. I do not own any
TwinRXs. I only looked at the example with TwinRXs written by Ettus
Research. And in this example the LO is shared between two TwinRX
daughterboards in the same X310 at
https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
In this article THEY CLAIM "constant repeatable relative phase offsets". At
least in the example they first calibrate the system, then save calibration
file to the disk, then load this calibration in the different program. This
procedure includes FPGA reinitialization, PLL retune and etc.
What I have is two X310s with two SBX120 in each. And I have repeatable
phase offset between two channels in the same X310. This is expected,
because SBX120 uses ADF4350 PLL synthesizer with "Phase Resync" feature
which should guarantee VCO phase alignment to the phase of the base 10 MHz
clock.
But also I observe the phase drift between channels on different X310 with
SBX120 modules (two X310 are daisy chained by two cables, PPS and REF
CLOCK). If the problem in my case is with cables (temperature drift), then
there also would be the drift in the setup described by Ettus guys at
https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
as they use cables too for LO sharing.
2017-03-08 23:11 GMT+03:00 Marcus D. Leech <[email protected]>:
> On 03/08/2017 03:04 PM, Roman Olesyuk wrote:
>
> Hi mleech,
>
> Thank you very much for the clarification.
>
> Actually I was trying to reproduce "Direction Finding with the USRP
> X-Series and TwinRX" https://kb.ettus.com/Direction_Finding_with_the_
> USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 example but with two X310s
> with two SBX120 in each instead of one X310 with two TwinRX. I can see that
> in this example LO is shared between two TwinRX daughterboards using two
> coax cables which connect these daughterboards directly. This effectively
> creates the same asymmetric layout as in my case: LO is generated on the
> first daughterboard and then transferred to the second one via cables. And
> according to the article such a system has "constant repeatable relative
> phase offsets" between channels (which is calibrated out). So it look like
> there is no (?) any thermal drift. Or at least it can be interpreted as if
> there is "constant repeatable relative phase offsets" in equilibrium state
> (e.g. after warm-up). But in my case the phase difference between channels
> on different USRPs is not repeatable even after the warm-up, but it is
> constant between channels on the same USRP. So I think may be the problem
> is not only (if any) in asymmetrical cable layout but also in some setup
> issues or clock synchronization/distribution part...
>
>
> 2017-02-28 1:13 GMT+03:00 <[email protected]>:
>
>> Roman:
>>
>> There will be a fixed phase-offset proportional to the length of your
>> daisy-chaining cables, and the effective electrical length of the circuitry
>> inside the "master" X310 that mirrors the 1PPS and 10MHz internal
>> signals. BOTH of these can experience thermal drift, and there is almost
>> *guaranteed* to be thermal drift between the internal 10MHz/1PPS signals
>> inside the X310 and the cables that are carrying those signals to your 2nd
>> X310.
>>
>>
>>
>> The best way to set up systems like this is with a common clock source,
>> like the Octoclock or Octoclock-G, using equal-lengths of 10MHz and 1PPS
>> cabling to each X310 (or other USRP) that is served by the Octoclock. The
>> internal circuitry inside the Octoclock is designed to be phase-matched,
>> and while it *will* thermal drift, it will all thermal drift at the same
>> rate. Similarly, your external cables, if all the same type and length
>> will provide good long-term phase coherence if they're all in the same type
>> of thermal environment.
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2017-02-27 15:46, Roman Olesyuk via USRP-users wrote:
>>
>> Hi Everybody,
>>
>> I have an issue while trying to synchronize two X310s for MIMO
>> application. I have the following setup.
>>
>> Two X310s with two SBX120 in each are connected to the same PC (using
>> PCIe or 1Gbps connection). So in total I have four channels 0, 1, 2, 3.
>> Master X310 has GPSDO, but currently I do not use it, only the internal
>> clock is used. Master's PPS out and clock out are connected to slave's PPS
>> in and clock in. On all 4 RF inputs I transmit 10kHz sine wave at 2.45 GHz
>> @ 1MHz bandwidth from bladeRF via 4-way splitter. Then my workflow is as
>> follows:
>>
>> 1. create multi_usrp interface
>> 2. set_clock_source("internal", 0); // On master
>> 3. set_time_source("internal", 0); // On master
>> 4. set_clock_source("external", 1); // On slave
>> 5. set_time_source("external", 1); // On slave
>> 6. set_time_unknown_pps(uhd::time_spec_t(0.0));
>> 7. set RX LO center frequency with a time spec synchronously on the
>> master and on the slave
>> 8. issue stream command to multi_usrp with the time spec in future
>> for 10000 samples 1000 times with 1 second pause, write buffers to the
>> file, thus the total timespan is about 20 minutes.
>>
>> When I calculate phase difference relative to channel 0 for channels 1,
>> 2, 3, I get the following result. The phase of channel 1 (on the same X310
>> as channel 0, on the master) is stable over the whole timespan. The phases
>> of channels 2, 3 have a slow drift about 1 radian per minute relative the
>> channel 0. Channels 2, 3 (on the same X310, the slave) drift synchronously,
>> that is no drift between channels 2 and 3. It looks like LO PLLs work fine
>> (taking into account that there is no phase drift between two SBX120 in the
>> same X310 and that SBX120s do not share the LO). Also the phase drift fades
>> out (looks exponential). In some experiments I see more stable picture, in
>> the rest the drift is as described above.
>>
>> What can be a problem here?
>>
>> --
>> ? ?????????, ????? ??????.
>> Yours sincerely, Roman Olesyuk.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> ? ?????????, ????? ??????.
> Yours sincerely, Roman Olesyuk.
>
> There will NOT be a repeatable phase-offset between your TwinRX and SBX
> modules. Because they have totally different PLL synthesizer
> architectures--even though they share a reference clock. This will
> have to be calibrated every time.
>
>
>
--
? ?????????, ????? ??????.
Yours sincerely, Roman Olesyuk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170308/c277a050/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 08 Mar 2017 15:51:43 -0500
From: "Marcus D. Leech" <[email protected]>
To: Roman Olesyuk <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Two X310s synchronization and a phase drift
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 03/08/2017 03:44 PM, Roman Olesyuk wrote:
> Hi Marcus,
>
> Thank you for you reply!
>
> May be I was not clear enough describing my setup. I do not own any
> TwinRXs. I only looked at the example with TwinRXs written by Ettus
> Research. And in this example the LO is shared between two TwinRX
> daughterboards in the same X310 at
> https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
>
> In this article THEY CLAIM "constant repeatable relative phase
> offsets". At least in the example they first calibrate the system,
> then save calibration file to the disk, then load this calibration in
> the different program. This procedure includes FPGA reinitialization,
> PLL retune and etc.
>
> What I have is two X310s with two SBX120 in each. And I have
> repeatable phase offset between two channels in the same X310. This is
> expected, because SBX120 uses ADF4350 PLL synthesizer with "Phase
> Resync" feature which should guarantee VCO phase alignment to the
> phase of the base 10 MHz clock.
>
> But also I observe the phase drift between channels on different X310
> with SBX120 modules (two X310 are daisy chained by two cables, PPS and
> REF CLOCK). If the problem in my case is with cables (temperature
> drift), then there also would be the drift in the setup described by
> Ettus guys at
> https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
>
> as they use cables too for LO sharing.
>
>
> 2017-03-08 23:11 GMT+03:00 Marcus D. Leech <[email protected]
> <mailto:[email protected]>>:
>
> On 03/08/2017 03:04 PM, Roman Olesyuk wrote:
>> Hi mleech,
>>
>> Thank you very much for the clarification.
>>
>> Actually I was trying to reproduce "Direction Finding with the
>> USRP X-Series and TwinRX"
>>
>> https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
>>
>> <https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2>
>> example but with two X310s with two SBX120 in each instead of one
>> X310 with two TwinRX. I can see that in this example LO is shared
>> between two TwinRX daughterboards using two coax cables which
>> connect these daughterboards directly. This effectively creates
>> the same asymmetric layout as in my case: LO is generated on the
>> first daughterboard and then transferred to the second one via
>> cables. And according to the article such a system has "constant
>> repeatable relative phase offsets" between channels (which is
>> calibrated out). So it look like there is no (?) any thermal
>> drift. Or at least it can be interpreted as if there is "constant
>> repeatable relative phase offsets" in equilibrium state (e.g.
>> after warm-up). But in my case the phase difference between
>> channels on different USRPs is not repeatable even after the
>> warm-up, but it is constant between channels on the same USRP. So
>> I think may be the problem is not only (if any) in asymmetrical
>> cable layout but also in some setup issues or clock
>> synchronization/distribution part...
>>
>>
>> 2017-02-28 1:13 GMT+03:00 <[email protected]
>> <mailto:[email protected]>>:
>>
>> Roman:
>>
>> There will be a fixed phase-offset proportional to the length
>> of your daisy-chaining cables, and the effective electrical
>> length of the circuitry inside the "master" X310 that mirrors
>> the 1PPS and 10MHz internal signals. BOTH of these can
>> experience thermal drift, and there is almost *guaranteed* to
>> be thermal drift between the internal 10MHz/1PPS signals
>> inside the X310 and the cables that are carrying those
>> signals to your 2nd X310.
>>
>> The best way to set up systems like this is with a common
>> clock source, like the Octoclock or Octoclock-G, using
>> equal-lengths of 10MHz and 1PPS cabling to each X310 (or
>> other USRP) that is served by the Octoclock. The internal
>> circuitry inside the Octoclock is designed to be
>> phase-matched, and while it *will* thermal drift, it will all
>> thermal drift at the same rate. Similarly, your external
>> cables, if all the same type and length will provide good
>> long-term phase coherence if they're all in the same type of
>> thermal environment.
>>
>> On 2017-02-27 15:46, Roman Olesyuk via USRP-users wrote:
>>
>>> Hi Everybody,
>>> I have an issue while trying to synchronize two X310s for
>>> MIMO application. I have the following setup.
>>> Two X310s with two SBX120 in each are connected to the same
>>> PC (using PCIe or 1Gbps connection). So in total I have four
>>> channels 0, 1, 2, 3. Master X310 has GPSDO, but currently I
>>> do not use it, only the internal clock is used. Master's PPS
>>> out and clock out are connected to slave's PPS in and clock
>>> in. On all 4 RF inputs I transmit 10kHz sine wave at 2.45
>>> GHz @ 1MHz bandwidth from bladeRF via 4-way splitter. Then
>>> my workflow is as follows:
>>>
>>> 1. create multi_usrp interface
>>> 2. set_clock_source("internal", 0); // On master
>>> 3. set_time_source("internal", 0); // On master
>>> 4. set_clock_source("external", 1); // On slave
>>> 5. set_time_source("external", 1); // On slave
>>> 6. set_time_unknown_pps(uhd::time_spec_t(0.0));
>>> 7. set RX LO center frequency with a time spec
>>> synchronously on the master and on the slave
>>> 8. issue stream command to multi_usrp with the time spec in
>>> future for 10000 samples 1000 times with 1 second pause,
>>> write buffers to the file, thus the total timespan is
>>> about 20 minutes.
>>>
>>> When I calculate phase difference relative to channel 0 for
>>> channels 1, 2, 3, I get the following result. The phase of
>>> channel 1 (on the same X310 as channel 0, on the master) is
>>> stable over the whole timespan. The phases of channels 2, 3
>>> have a slow drift about 1 radian per minute relative the
>>> channel 0. Channels 2, 3 (on the same X310, the slave) drift
>>> synchronously, that is no drift between channels 2 and 3. It
>>> looks like LO PLLs work fine (taking into account that there
>>> is no phase drift between two SBX120 in the same X310 and
>>> that SBX120s do not share the LO). Also the phase drift
>>> fades out (looks exponential). In some experiments I see
>>> more stable picture, in the rest the drift is as described
>>> above.
>>> What can be a problem here?
>>> --
>>> ? ?????????, ????? ??????.
>>> Yours sincerely, Roman Olesyuk.
>>>
>>> _______________________________________________
>>> 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>
>>
>>
>>
>>
>> --
>> ? ?????????, ????? ??????.
>> Yours sincerely, Roman Olesyuk.
> There will NOT be a repeatable phase-offset between your TwinRX
> and SBX modules. Because they have totally different PLL synthesizer
> architectures--even though they share a reference clock. This
> will have to be calibrated every time.
>
>
>
Could you perhaps post a diagram showing how you synchronize things?
Also, are all X310 in the same UHD source/sink block on the same
host, or different hosts? If you're still daisy-chaining, I'll point
out that daisy-chaining isn't really supported on the X310 hardware, and
you're better off with a common source, like an octoclock.
I know that the app-note example was designed specifically for TwinRX,
so a fair amount of re-jigging and experimentation may be required
to make it work adequately with other setups.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170308/8d28deb0/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 8 Mar 2017 22:39:25 +0100
From: Fernando <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Error at receiving end of usrp/2901
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
in ubuntu I think that you must be in the group plugdev to use the uhd
regards
El 08/03/17 a las 18:33, Ozair Iqbal via USRP-users escribi?:
>
> Dear all,
> I am using one USRP/2901 as transmitter of signal while on the
> other end i am using other usrp/2901 as receiving the signal but at
> the receiving end i am receiving following error
>
> UHD Error:
> USB open failed: insufficient permissions.
> See the application notes for your device.
> Traceback (most recent call last):
> File "/home/uzair/top_block.py", line 95, in <module>
> main()
> File "/home/uzair/top_block.py", line 89, in main
> tb = top_block_cls()
> File "/home/uzair/top_block.py", line 66, in __init__
> channels=range(1),
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2671, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: LookupError: KeyError: No devices found for ----->
> Empty Device Address
> Regards,
> Ozair Iqbal (RA)
> ITU,Lahore
>
>
> _______________________________________________
> 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/20170308/b6a5e560/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 08 Mar 2017 16:57:39 -0500
From: Jason Matusiak <[email protected]>
To: "Marcus D. Leech" <[email protected]>, [email protected]
Subject: Re: [USRP-users] B200mini USB3 question
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
OK, that is likely my issue and makes USB3 a showstopper for now. I'll stick
with USB2.1 for now.
Thanks for clearing that up, I am pretty clueless to the ins and outs of USB.
~Jason?
-------- Original message --------
From: "Marcus D. Leech via USRP-users" <[email protected]>
Date: 3/8/17 3:33 PM (GMT-05:00)
To: [email protected]
Subject: Re: [USRP-users] B200mini USB3 question
On 03/08/2017 03:24 PM, Jason Matusiak via USRP-users wrote:
> I am playing with the mini and a Motorola Moto Z MotoMod and having a
> weird issue.? When in USB3 mode, the motoMod powers the mini and I can
> see the microcontroller in the firmware recognizing that a device was
> plugged in, but the mini doesn't enumerate with Android.
>
> Someone pointed out that the MotoMod's "USB3 support is really just
> the super speed lines only, i.e. there is no d+, d-."
>
> I know that the d+/- are wired up for the USB2.1 protocol on the mini,
> but is something needed for the mini on those lines when using it in
> USB3 mode? (the MotoMod's USB3 mode is strictly a USB3 phy, so it does
> not auto-negotiate to USB2.1 if needed)
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
The FX3 comes up in USB-2.0 mode, and switches later on in the process.
_______________________________________________
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/20170308/c1d3c7e9/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 8 Mar 2017 23:15:43 +0000
From: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Link LED blinking RED
Message-ID:
<mwhpr09mb116864bcbc31a2cffdadb5319e...@mwhpr09mb1168.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Nicolas,
The USRP is just idle. I am talking about the LINK led (next to the GPS led to
the right) in the front panel.
Regards,
Naceur
From: Nicolas Cuervo [mailto:[email protected]]
Sent: Wednesday, March 08, 2017 8:18 AM
To: El Ouni, Naceur (IntlAssoc) <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Link LED blinking RED
Hello Naceur,
could you please be more specific on which led is the one you are referring to?
In general, the front panel led will blink red on the TX ports when a
transmission is undergoing [1]. On the same port, being TX/RX, it will blink
green when it is receiving instead.
Are you transmitting with your USRP?
Regards,
-Nicolas
[1] https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_on_board_leds
On Tue, Mar 7, 2017 at 5:59 PM, El Ouni, Naceur (IntlAssoc) via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
What does a Blinking Red LINK LED means.
I am using an NI branded X310 (NI 2942R) with Windows Server 2012 R2.
Ethernet port 0 is connected to a 1G Ethernet interface and port 1 is connected
to a High Speed 10GB Interface using a fiber optic cable.
PS: the blinking is happenning regardless of the port 1 connection i.e.
blinking persists if I disconnect the 10GB Ethernet cable.
Thanks and Regards,
Naceur El Ouni
NIST - Wireless Networks Division (673)
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20170308/ff6cd5ff/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 08 Mar 2017 22:10:49 -0500
From: "Marcus D. Leech" <[email protected]>
To: Jason Matusiak <[email protected]>,
[email protected]
Subject: Re: [USRP-users] B200mini USB3 question
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 03/08/2017 04:57 PM, Jason Matusiak wrote:
> OK, that is likely my issue and makes USB3 a showstopper for now. I'll
> stick with USB2.1 for now.
>
> Thanks for clearing that up, I am pretty clueless to the ins and outs
> of USB.
That's OK, so were the designers of USB. :) [MEOW]
>
> ~Jason
>
>
> -------- Original message --------
> From: "Marcus D. Leech via USRP-users" <[email protected]>
> Date: 3/8/17 3:33 PM (GMT-05:00)
> To: [email protected]
> Subject: Re: [USRP-users] B200mini USB3 question
>
> On 03/08/2017 03:24 PM, Jason Matusiak via USRP-users wrote:
> > I am playing with the mini and a Motorola Moto Z MotoMod and having a
> > weird issue. When in USB3 mode, the motoMod powers the mini and I can
> > see the microcontroller in the firmware recognizing that a device was
> > plugged in, but the mini doesn't enumerate with Android.
> >
> > Someone pointed out that the MotoMod's "USB3 support is really just
> > the super speed lines only, i.e. there is no d+, d-."
> >
> > I know that the d+/- are wired up for the USB2.1 protocol on the mini,
> > but is something needed for the mini on those lines when using it in
> > USB3 mode? (the MotoMod's USB3 mode is strictly a USB3 phy, so it does
> > not auto-negotiate to USB2.1 if needed)
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> The FX3 comes up in USB-2.0 mode, and switches later on in the process.
>
>
>
> _______________________________________________
> 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/20170308/65c1f076/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 9 Mar 2017 12:32:41 +0500
From: Ozair Iqbal <[email protected]>
To: [email protected]
Subject: [USRP-users] fail to transmit a signal by USRP/2901 using
gnuradio-companion software
Message-ID:
<camqc7dvggq3brkh3m6emxwaejpraida8etwgek-wy6dtmwe...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
I am using USRP/2901 for my own experiments. When i connect
USRP/2901 with my laptop, the USRP/2901 is easily detectable. But
when i try to transmit a signal by making a flow graph in
gnuradio-companion then following error message occurs at the
terminal. I have provided the serial no in USRP source block (in
gnuradio companion)
but error is still there.
UHD Error:
USB open failed: insufficient permissions.
See the application notes for your device.
Traceback (most recent call last):
File "/home/uzair/top_block.py", line 102, in <module>
main()
File "/home/uzair/top_block.py", line 96, in main
tb = top_block_cls()
File "/home/uzair/top_block.py", line 67, in __init__
channels=range(1),
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2671, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: LookupError: KeyError: No devices found for ----->
Empty Device Address
Regards,
Ozair Iqbal
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/2b25b794/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 9 Mar 2017 12:35:16 +0500
From: Ozair Iqbal <[email protected]>
To: [email protected]
Subject: [USRP-users] Transmission of signal failure using USRP/2901
by gnuradio-companion
Message-ID:
<camqc7dtr1no80phrusm7pa8zhtx_lr-uf4agnopmf8njgs0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am trying to make NI 2901 USRP work with GNU Radio framework. As NI 2901
is inferfaced via USB so I am connecting the NI 2901 radio to USB 3.0 port
on my workstation. The uhd_find_devices command detects the USRP but I am
unable to make it work on GNU Radio framework. The following error appears
when I try to configure the USRP with GNU Radio framework:
UHD Error:
USB open failed: insufficient permissions.
See the application notes for your device.
Traceback (most recent call last):
File "/home/uzair/top_block.py", line 102, in <module>
main()
File "/home/uzair/top_block.py", line 96, in main
tb = top_block_cls()
File "/home/uzair/top_block.py", line 67, in __init__
channels=range(1),
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2671, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: LookupError: KeyError: No devices found for ----->
Empty Device Address
Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/ad5dcb65/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 9 Mar 2017 11:14:20 +0300
From: Roman Olesyuk <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Two X310s synchronization and a phase drift
Message-ID:
<camzegnhddspdxbn6q0tj+kctetap1x8z3gk3viegvurvppy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
> Could you perhaps post a diagram showing how you synchronize things?
Yes, certainly! Please see the diagram attached.
> Also, are all X310 in the same UHD source/sink block on the same host, or
different hosts?
The same source block via uhd::usrp::multi_usrp interface, on the same host
(as on the diagram).
> If you're still daisy-chaining, I'll point out that daisy-chaining isn't
really supported on the X310 hardware, and you're better off with a common
source, like an octoclock.
I am not sure why this is the case because REF CLOCK IN/OUT and PPS IN/OUT
are there. It seems OK to use cables to synchronize two X310 without an
external clock generator. But an octoclock looks like a more flexible
solution for sure.
2017-03-08 23:51 GMT+03:00 Marcus D. Leech <[email protected]>:
> On 03/08/2017 03:44 PM, Roman Olesyuk wrote:
>
> Hi Marcus,
>
> Thank you for you reply!
>
> May be I was not clear enough describing my setup. I do not own any
> TwinRXs. I only looked at the example with TwinRXs written by Ettus
> Research. And in this example the LO is shared between two TwinRX
> daughterboards in the same X310 at https://kb.ettus.com/
> Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 In
> this article THEY CLAIM "constant repeatable relative phase offsets". At
> least in the example they first calibrate the system, then save calibration
> file to the disk, then load this calibration in the different program. This
> procedure includes FPGA reinitialization, PLL retune and etc.
>
> What I have is two X310s with two SBX120 in each. And I have repeatable
> phase offset between two channels in the same X310. This is expected,
> because SBX120 uses ADF4350 PLL synthesizer with "Phase Resync" feature
> which should guarantee VCO phase alignment to the phase of the base 10 MHz
> clock.
>
> But also I observe the phase drift between channels on different X310 with
> SBX120 modules (two X310 are daisy chained by two cables, PPS and REF
> CLOCK). If the problem in my case is with cables (temperature drift), then
> there also would be the drift in the setup described by Ettus guys at
> https://kb.ettus.com/Direction_Finding_with_the_
> USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 as they use cables too for LO
> sharing.
>
>
> 2017-03-08 23:11 GMT+03:00 Marcus D. Leech <[email protected]>:
>
>> On 03/08/2017 03:04 PM, Roman Olesyuk wrote:
>>
>> Hi mleech,
>>
>> Thank you very much for the clarification.
>>
>> Actually I was trying to reproduce "Direction Finding with the USRP
>> X-Series and TwinRX" https://kb.ettus.com/Direction
>> _Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 example but
>> with two X310s with two SBX120 in each instead of one X310 with two TwinRX.
>> I can see that in this example LO is shared between two TwinRX
>> daughterboards using two coax cables which connect these daughterboards
>> directly. This effectively creates the same asymmetric layout as in my
>> case: LO is generated on the first daughterboard and then transferred to
>> the second one via cables. And according to the article such a system has
>> "constant repeatable relative phase offsets" between channels (which is
>> calibrated out). So it look like there is no (?) any thermal drift. Or at
>> least it can be interpreted as if there is "constant repeatable relative
>> phase offsets" in equilibrium state (e.g. after warm-up). But in my case
>> the phase difference between channels on different USRPs is not repeatable
>> even after the warm-up, but it is constant between channels on the same
>> USRP. So I think may be the problem is not only (if any) in asymmetrical
>> cable layout but also in some setup issues or clock
>> synchronization/distribution part...
>>
>>
>> 2017-02-28 1:13 GMT+03:00 <[email protected]>:
>>
>>> Roman:
>>>
>>> There will be a fixed phase-offset proportional to the length of your
>>> daisy-chaining cables, and the effective electrical length of the circuitry
>>> inside the "master" X310 that mirrors the 1PPS and 10MHz internal
>>> signals. BOTH of these can experience thermal drift, and there is almost
>>> *guaranteed* to be thermal drift between the internal 10MHz/1PPS signals
>>> inside the X310 and the cables that are carrying those signals to your 2nd
>>> X310.
>>>
>>>
>>>
>>> The best way to set up systems like this is with a common clock source,
>>> like the Octoclock or Octoclock-G, using equal-lengths of 10MHz and 1PPS
>>> cabling to each X310 (or other USRP) that is served by the Octoclock. The
>>> internal circuitry inside the Octoclock is designed to be phase-matched,
>>> and while it *will* thermal drift, it will all thermal drift at the same
>>> rate. Similarly, your external cables, if all the same type and length
>>> will provide good long-term phase coherence if they're all in the same type
>>> of thermal environment.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2017-02-27 15:46, Roman Olesyuk via USRP-users wrote:
>>>
>>> Hi Everybody,
>>>
>>> I have an issue while trying to synchronize two X310s for MIMO
>>> application. I have the following setup.
>>>
>>> Two X310s with two SBX120 in each are connected to the same PC (using
>>> PCIe or 1Gbps connection). So in total I have four channels 0, 1, 2, 3.
>>> Master X310 has GPSDO, but currently I do not use it, only the internal
>>> clock is used. Master's PPS out and clock out are connected to slave's PPS
>>> in and clock in. On all 4 RF inputs I transmit 10kHz sine wave at 2.45 GHz
>>> @ 1MHz bandwidth from bladeRF via 4-way splitter. Then my workflow is as
>>> follows:
>>>
>>> 1. create multi_usrp interface
>>> 2. set_clock_source("internal", 0); // On master
>>> 3. set_time_source("internal", 0); // On master
>>> 4. set_clock_source("external", 1); // On slave
>>> 5. set_time_source("external", 1); // On slave
>>> 6. set_time_unknown_pps(uhd::time_spec_t(0.0));
>>> 7. set RX LO center frequency with a time spec synchronously on the
>>> master and on the slave
>>> 8. issue stream command to multi_usrp with the time spec in future
>>> for 10000 samples 1000 times with 1 second pause, write buffers to the
>>> file, thus the total timespan is about 20 minutes.
>>>
>>> When I calculate phase difference relative to channel 0 for channels 1,
>>> 2, 3, I get the following result. The phase of channel 1 (on the same X310
>>> as channel 0, on the master) is stable over the whole timespan. The phases
>>> of channels 2, 3 have a slow drift about 1 radian per minute relative the
>>> channel 0. Channels 2, 3 (on the same X310, the slave) drift synchronously,
>>> that is no drift between channels 2 and 3. It looks like LO PLLs work fine
>>> (taking into account that there is no phase drift between two SBX120 in the
>>> same X310 and that SBX120s do not share the LO). Also the phase drift fades
>>> out (looks exponential). In some experiments I see more stable picture, in
>>> the rest the drift is as described above.
>>>
>>> What can be a problem here?
>>>
>>> --
>>> ? ?????????, ????? ??????.
>>> Yours sincerely, Roman Olesyuk.
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> --
>> ? ?????????, ????? ??????.
>> Yours sincerely, Roman Olesyuk.
>>
>> There will NOT be a repeatable phase-offset between your TwinRX and SBX
>> modules. Because they have totally different PLL synthesizer
>> architectures--even though they share a reference clock. This will
>> have to be calibrated every time.
>>
>>
>>
> Could you perhaps post a diagram showing how you synchronize things?
> Also, are all X310 in the same UHD source/sink block on the same
> host, or different hosts? If you're still daisy-chaining, I'll point
> out that daisy-chaining isn't really supported on the X310 hardware, and
> you're better off with a common source, like an octoclock.
>
> I know that the app-note example was designed specifically for TwinRX, so
> a fair amount of re-jigging and experimentation may be required
> to make it work adequately with other setups.
>
>
>
--
? ?????????, ????? ??????.
Yours sincerely, Roman Olesyuk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/89bedfaf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phase_sychronization_with_two_x310.png
Type: image/png
Size: 154663 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/89bedfaf/attachment-0001.png>
------------------------------
Message: 19
Date: Thu, 9 Mar 2017 11:43:55 +0100
From: Paolo Palana <[email protected]>
To: [email protected]
Subject: [USRP-users] axi_wrapper with simple_mode=0... help me
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi
It is about a week that I have decided to play around with the axi
wrapper not in simple_mode (SIMPLE_MODE=0).
My noc_block, using axi_wrapper in simple_mode (SIMPLE_MODE=1) works
fine, namely I can read packets coming from my X310.
Then I switched to SIMPLE_MODE=0.
Reading comments inside axi_wrapper.v I know that
"SIMPLE_MODE=0 that is User handles CHDR insertion via tuser signals"
So my first attempt to use SIMPLE_MODE=0 is just pass the header coming
from the the axi_wrapper m_axis_data_tuser port to the s_axis_data_tuser
port
of the same axi_wrapper.
To "talk" in verilog:
I decoded the header coming from axi_wrapper to see the value of each field
cvita_hdr_decoder cvita_hdr_decoder (
.header(int_header_from_axiw),
.pkt_type(int_pkt_type_from_axiw),
.eob(int_eob_from_axiw),
.has_time(int_has_time_from_axiw),
.seqnum(int_seqnum_from_axiw),
.length(int_len_from_axiw),
.payload_length(int_payload_len_from_axiw),
.src_sid(int_src_sid_from_axiw),
.dst_sid(int_dst_sid_from_axiw),
.vita_time(int_vita_taime_from_axiw)
);
Reconding the header and sent it to the axi_wapper
//ENCODE THE OUTGOING HEADER
cvita_hdr_encoder cvita_hdr_encoder (
.pkt_type(int_pkt_type_from_axiw),
.eob(int_eob_from_axiw),
.has_time(int_has_time_from_axiw),
.seqnum(int_seqnum_from_axiw),
.payload_length(int_payload_len_from_axiw),
.src_sid(int_src_sid_from_axiw),
.dst_sid(int_dst_sid_from_axiw),
.vita_time(int_vita_taime_from_axiw),
.header(int_header_to_axiw)
);
My problem is that, in this way, what I got is a TIMEOUT on the host. I
have also setup the ILA and what I see is that after two packets the
signal m_axis_data_tvalid
coming from the axi_wrapper, to my logic goes down after two packet. I
monitored also the s_axis_data_* from my logic to the the axi_wrapper
and the waveform
seems to be ok.
What I would ask is if someone has an idea of what is going on. I'm
certain I have miss some details... but I'm unable to understand what.
If you need more info to ask properly, please let me know.
Thank you in advance
Good day
Paolo
------------------------------
Message: 20
Date: Thu, 9 Mar 2017 15:08:06 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: [USRP-users] E312: Cannot find command 'git'
Message-ID:
<CABLDF_fA0C79HWQN7ENTrpOx0DSt9wdsSN=jjDWes--F=j3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi to all,
I am using VMware and Ubuntu 16.04. I try to implement QUICKSTART steps in
the following link.
https://kb.ettus.com/Software_Development_on_the_E310_and_E312
root@ubuntu:~# pip install git+https://github.com/gnuradio/pybombs.git
When I write the above command, I got an error. What might be the
problem?(Up to this step everything was good)
Collecting git+https://github.com/gnuradio/pybombs.git
Cloning https://github.com/gnuradio/pybombs.git to /tmp/pip-Be5RlS-build
Error [Errno 2] No such file or directory while executing command git
clone -q https://github.com/gnuradio/pybombs.git /tmp/pip-Be5RlS-build
Cannot find command 'git'
Here is the screenshot:
?
Best regards,
Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/704905fe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2017-03-09 15-05-03.png
Type: image/png
Size: 272721 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/704905fe/attachment-0001.png>
------------------------------
Message: 21
Date: Thu, 9 Mar 2017 15:11:34 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UBX-160: Receiver with 160MHz bandwidth
Message-ID:
<cabldf_fis9fi94kqo04wbrdbn9zgyy4qsiaaf7w8s-vbm7g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Thanks for the replies. I managed to take record. I will analyze it and
come back if any problem occurs.
Best,
Ali
2017-03-06 20:50 GMT+03:00 Rob Kossler via USRP-users <
[email protected]>:
> Ali,
> For Receive bandwidth, I don't think it matters whether you use the Tx/Rx
> path or the Rx2 path. You should get the same bandwidth in each case. For
> center frequencies below 500 MHz, you already noted the Rx bandwidth
> limitation. For frequencies above 500 MHz, You should be able to get the
> full 160 MHz bandwidth. Note that this limitation for center frequencies
> under 500 MHz is specific to UBX160 daughterboards. For the SBX120,
> CBX120, and WBX120 daughterboards, there is no such limitation on on
> bandwidth related to center frequencies such that you should be able to
> receive 120 MHz bandwidth over the full frequency range of the respective
> daughterboard.
>
> You mentioned that you are using the PCIe interface. This Gen 1 x4
> interface can only support one stream at 200 MS/s so if you have 2 UBX160
> daughterboards in your X310, you will not be able to receive two streams at
> 200 MS/s over this interface. However, you could receive two streams at 200
> MS/s if you use the dual 10Gbe interfaces instead.
>
> Rob
>
> On Mon, Mar 6, 2017 at 11:46 AM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> I'll point out that at 200Msps, you need a *VERY* capable computer to
>> "keep up" with the sample stream.
>>
>>
>>
>>
>>
>>
>> On 2017-03-06 11:29, Kyeong Su Shin via USRP-users wrote:
>>
>> To Whom it may concern:
>>
>> OOps, one mistake:
>>
>> -You probably cannot use 160MS/s because it is not an integer fraction of
>> the master clock. Maybe you have a better luck with 200MS/s.
>>
>> Regards,
>> Kyeong Su Shin
>>
>> On Mon, Mar 6, 2017 at 8:18 AM, Kyeong Su Shin <[email protected]> wrote:
>>
>>> To Whom it may concern:
>>>
>>> I never used X3x0s (only uses N2x0 and B2x0), so I am probably not the
>>> best person to answer this, but this is how I understand:
>>>
>>> -That 160MHz is for the low pass filter bandwidth (3dB point) of the
>>> daughterboard. Has nothing to do with the effective sampling rate of the
>>> system.
>>> -X3x0s can theoretically do 200MS/s with the PCI-e bus. I am not sure
>>> how realistic that is, but in theory, you can do 160MS/s alright (if the
>>> program is well-optimized and your computer can take it).
>>> -During the decimation process, DDC (in USRP) will low-pass your signal
>>> to prevent aliasing. So, if you ask for 80MS/s of effective sampling rate
>>> (on the PC side; post-decimation), you will get 80MHz of bandwidth. You can
>>> modify the FPGA image to increase the filter bandwidth beyond the sampling
>>> rate, but that's probably not what you want. (Unless you *want*
>>> aliasing).
>>> -RX2 / RX/TX antenna port has nothing to do with the usable bandwidth.
>>> UBX daughterboards internally switch their RF frontend circuits at 500MHz
>>> and 1.5GHz. It seems like UBX160 has lower RX bandwidth when you are
>>> between 10-500MHz. This should be true for both RX2 and RX/TX antenna port.
>>>
>>> Regards,
>>> Kyeong Su Shin
>>>
>>> On Mon, Mar 6, 2017 at 5:01 AM, do ber via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi to all,
>>>>
>>>> When I buy UBX-160, I thought that I can receive signals with 160MHz
>>>> bandwidth. I am using GNURadio and USRP X310. And the data is coming over
>>>> PCIe connection. When I used the RX port of the daughterboard, I couldn't
>>>> correctly receive signals wider than 80MHz. Then I saw on the page:
>>>>
>>>> The UBX 160 transmitter path has 160 MHz of bandwidth throughout the
>>>> full frequency range of the device; the receiver path has 84 MHz of
>>>> bandwidth for center frequencies from 10 MHz to 500 MHz.
>>>>
>>>> I have questions related to this statement:
>>>>
>>>> * If I use te TX/RX for the receiving, can I use 160 MHz bandwidth?
>>>>
>>>> * For the receiver path other than 10 MHz to 500 MHz what is the max.
>>>> receiver bandwidth? My signal's center freq. is ~1.5GHz.
>>>>
>>>> In short, can I take samples from a signal with 160MHz bandwidth by
>>>> using UBX-160 and X310? What about WBX120? Can I use this daughterboard
>>>> with signals having 120MHz bandwidth?
>>>>
>>>> Best regards,
>>>> Ali
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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/20170309/0e8b963b/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 9 Mar 2017 13:38:57 +0100
From: Philipp Rudnik <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Segmentation fault while accessing user
registers
Message-ID:
<cadk_vqhsl1zg+lpen+lhkv9qmnxig8dxftejotow1olpcyt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Sir or Madam,
I have trouble getting some user registes defined and to get the host to
communicate with this register.
I am using a X310 USRP.
I want to realize a (host side) write only user register at the gpio_atr
Module.
First of all, i changed the host side as follows:
- In the x300_regs.hpp
#define localparam static const int
#define TOREG(x) ((x)*4)
localparam SR_USER_REGS = 5;
- In the x300_impl.hpp
#include "user_settings_core_200.hpp"
#include "fifo_ctrl_excelsior.hpp"
[...]
private:
fifo_ctrl_excelsior::sptr _fifo_ctrl;
user_settings_core_200::sptr _user;
- In the x300_impl.cpp
////////////////////////////////////////////////////////////////////
// create user-defined control objects
////////////////////////////////////////////////////////////////////
_user = user_settings_core_200::make(_fifo_ctrl, TOREG(SR_USER_REGS));
_tree->create<user_settings_core_200::user_reg_t>(mb_path / "user/regs")
.add_coerced_subscriber(boost::bind(&user_settings_core_200::set_reg,
_user, _1));
- In my own c++ application:
uint32_t prtCycles = (1 << 11) - 1;
usrp_x300->set_user_register(0, prtCycles , 0);
And Second in the FPGA-Code (inside gpio_atr):
reg [31:0] prtCycles; // Local register set by User Settings Bus
wire [31:0] prtCycles_sr; // setting_reg module output
wire prtCycles_ch; // bit indicating the reg has just changed
setting_reg #(.my_addr(0)) sr_0 // 0 is the address you choose.
(there is an 8 bit address space)
(.clk(clk),.rst(reset),.strobe(set_stb),.addr(set_addr),.in(set_data),
.out(prtCycles_sr),.changed(prtCycles_ch));
always @(posedge clk)
if (prtCycles_ch)
prtCycles <= prtCycles_sr;
The code compiles on both sides without any error.
The error message that i receive when trying to run the code:
...(USRP initialize sequence)....
...
Single USRP:
Device: X-Series Device
Mboard 0: X310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: CBX-120 RX
RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: CBX-120 RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: CBX-120 TX
TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: CBX-120 TX
Segmentation fault (core dumped)
I hope that you can help me with this issue. I have no idea on which side
(host or fpga or communication?) the error is located and how to search for
it (or fix it).
yours sincerly,
Philipp Rudnik
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/da97cccf/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 9 Mar 2017 07:52:50 -0500
From: Jason Matusiak <[email protected]>
To: do ber <[email protected]>, [email protected]
Subject: Re: [USRP-users] E312: Cannot find command 'git'
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
I might be oversimplifying this, but do you have git installed? If not,
try 'sudo apt-get install git' and then rerun your command.
~Jason
On 03/09/2017 07:08 AM, do ber via USRP-users wrote:
> Hi to all,
>
> I am using VMware and Ubuntu 16.04. I try to implement QUICKSTART
> steps in the following link.
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
> <https://kb.ettus.com/Software_Development_on_the_E310_and_E312>
>
> root@ubuntu:~# pip install git+https://github.com/gnuradio/pybombs.git
> <https://github.com/gnuradio/pybombs.git>
>
> When I write the above command, I got an error. What might be the
> problem?(Up to this step everything was good)
>
> Collecting git+https://github.com/gnuradio/pybombs.git
> <https://github.com/gnuradio/pybombs.git>
> Cloning https://github.com/gnuradio/pybombs.git
> <https://github.com/gnuradio/pybombs.git> to /tmp/pip-Be5RlS-build
> Error [Errno 2] No such file or directory while executing command
> git clone -q https://github.com/gnuradio/pybombs.git
> <https://github.com/gnuradio/pybombs.git> /tmp/pip-Be5RlS-build
> Cannot find command 'git'
>
> Here is the screenshot:
>
>
> ?
>
> Best regards,
> Ali
>
>
> _______________________________________________
> 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/20170309/286a6666/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 272721 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/286a6666/attachment-0001.png>
------------------------------
Message: 24
Date: Thu, 9 Mar 2017 07:55:30 -0500
From: Jason Matusiak <[email protected]>
To: Ozair Iqbal <[email protected]>, [email protected]
Subject: Re: [USRP-users] Transmission of signal failure using
USRP/2901 by gnuradio-companion
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Have a look at the section "configuring USB" and see if that helps you
any:
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Configuring_USB
~Jason
On 03/09/2017 02:35 AM, Ozair Iqbal via USRP-users wrote:
> I am trying to make NI 2901 USRP work with GNU Radio framework. As NI
> 2901 is inferfaced via USB so I am connecting the NI 2901 radio to USB
> 3.0 port on my workstation. The uhd_find_devices command detects the
> USRP but I am unable to make it work on GNU Radio framework. The
> following error appears when I try to configure the USRP with GNU
> Radio framework:
> UHD Error:
> USB open failed: insufficient permissions.
> See the application notes for your device.
> Traceback (most recent call last):
> File "/home/uzair/top_block.py", line 102, in <module>
> main()
> File "/home/uzair/top_block.py", line 96, in main
> tb = top_block_cls()
> File "/home/uzair/top_block.py", line 67, in __init__
> channels=range(1),
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2671, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: LookupError: KeyError: No devices found for ----->
> Empty Device Address
>
>
> Regards,
>
>
>
> _______________________________________________
> 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/20170309/cb30a249/attachment-0001.html>
------------------------------
Message: 25
Date: Thu, 9 Mar 2017 16:14:53 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E312: Cannot find command 'git'
Message-ID:
<CABLDF_e2VrCin80q4upcPz6hJQ=uktx4rwhtdwb0bmwjwyz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Jason, It was that simple :) I am not so experienced in Linux so I
was just following the steps. Anyway, it worked.
Best,
Ali
2017-03-09 15:52 GMT+03:00 Jason Matusiak <[email protected]>:
> I might be oversimplifying this, but do you have git installed? If not,
> try 'sudo apt-get install git' and then rerun your command.
>
> ~Jason
>
>
> On 03/09/2017 07:08 AM, do ber via USRP-users wrote:
>
> Hi to all,
>
> I am using VMware and Ubuntu 16.04. I try to implement QUICKSTART steps in
> the following link.
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>
> root@ubuntu:~# pip install git+https://github.com/gnuradio/pybombs.git
>
> When I write the above command, I got an error. What might be the
> problem?(Up to this step everything was good)
>
> Collecting git+https://github.com/gnuradio/pybombs.git
> Cloning https://github.com/gnuradio/pybombs.git to /tmp/pip-Be5RlS-build
> Error [Errno 2] No such file or directory while executing command git
> clone -q https://github.com/gnuradio/pybombs.git /tmp/pip-Be5RlS-build
> Cannot find command 'git'
>
> Here is the screenshot:
>
>
> ?
>
> Best regards,
> Ali
>
>
> _______________________________________________
> USRP-users mailing
> [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/20170309/a1f5158c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 272721 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/a1f5158c/attachment-0001.png>
------------------------------
Message: 26
Date: Thu, 09 Mar 2017 08:41:42 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Transmission of signal failure using
USRP/2901 by gnuradio-companion
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 03/09/2017 02:35 AM, Ozair Iqbal via USRP-users wrote:
> I am trying to make NI 2901 USRP work with GNU Radio framework. As NI
> 2901 is inferfaced via USB so I am connecting the NI 2901 radio to USB
> 3.0 port on my workstation. The uhd_find_devices command detects the
> USRP but I am unable to make it work on GNU Radio framework. The
> following error appears when I try to configure the USRP with GNU
> Radio framework:
> UHD Error:
> USB open failed: insufficient permissions.
> See the application notes for your device.
> Traceback (most recent call last):
> File "/home/uzair/top_block.py", line 102, in <module>
> main()
> File "/home/uzair/top_block.py", line 96, in main
> tb = top_block_cls()
> File "/home/uzair/top_block.py", line 67, in __init__
> channels=range(1),
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2671, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: LookupError: KeyError: No devices found for ----->
> Empty Device Address
>
>
> Regards,
Please share with us the contents of your:
/etc/udev/rules.d/10-usrp.rules
File.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/754f82bd/attachment-0001.html>
------------------------------
Message: 27
Date: Thu, 9 Mar 2017 08:42:11 -0500
From: Jason Matusiak <[email protected]>
To: do ber <[email protected]>, [email protected]
Subject: Re: [USRP-users] E312: Cannot find command 'git'
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Good show! There are a couple of things I've run into in the past that
are basically pre-requirements that aren't specifically called out (like
you saw with git). Hopefully that is your only roadblock!
On 03/09/2017 08:14 AM, do ber via USRP-users wrote:
> Thanks Jason, It was that simple :) I am not so experienced in Linux
> so I was just following the steps. Anyway, it worked.
>
> Best,
> Ali
>
> 2017-03-09 15:52 GMT+03:00 Jason Matusiak
> <[email protected] <mailto:[email protected]>>:
>
> I might be oversimplifying this, but do you have git installed?
> If not, try 'sudo apt-get install git' and then rerun your command.
>
> ~Jason
>
>
> On 03/09/2017 07:08 AM, do ber via USRP-users wrote:
>> Hi to all,
>>
>> I am using VMware and Ubuntu 16.04. I try to implement QUICKSTART
>> steps in the following link.
>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>> <https://kb.ettus.com/Software_Development_on_the_E310_and_E312>
>>
>> root@ubuntu:~# pip install
>> git+https://github.com/gnuradio/pybombs.git
>> <https://github.com/gnuradio/pybombs.git>
>>
>> When I write the above command, I got an error. What might be the
>> problem?(Up to this step everything was good)
>>
>> Collecting git+https://github.com/gnuradio/pybombs.git
>> <https://github.com/gnuradio/pybombs.git>
>> Cloning https://github.com/gnuradio/pybombs.git
>> <https://github.com/gnuradio/pybombs.git> to /tmp/pip-Be5RlS-build
>> Error [Errno 2] No such file or directory while executing
>> command git clone -q https://github.com/gnuradio/pybombs.git
>> <https://github.com/gnuradio/pybombs.git> /tmp/pip-Be5RlS-build
>> Cannot find command 'git'
>>
>> Here is the screenshot:
>>
>>
>> ?
>>
>> Best regards,
>> Ali
>>
>>
>> _______________________________________________
>> 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>
>
> _______________________________________________
> 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/20170309/f8bf168f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 272721 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/f8bf168f/attachment-0001.png>
------------------------------
Message: 28
Date: Thu, 9 Mar 2017 08:50:05 -0500
From: Jason Matusiak <[email protected]>
To: "Marcus D. Leech" <[email protected]>, [email protected]
Subject: Re: [USRP-users] B200mini USB3 question
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
OK, I have a question out on the Cypress forum to get some more
information on the FX3, but in the meantime I found the section "USB 3.0
and USB 2.0 Function Coordination" on page 94 of their tech reference
manual for the part (http://www.cypress.com/file/134661/download).
It looks like it tries to come up in 3.0 mode, then falls back to a 2.0
state if it didn't work, and retries for 2.0 and 3.0. I am not sure if
there is a way to figure out what the B200mini is really doing to try to
follow the flow that the FX3 firmware is supposed to follow.
Here are the steps from the PDF:
1. Wait for a valid VBus voltage (GCTL_IOPWR interrupt).
2. Turn on the USB 3.0 PHY to start 3.0 receiver detection.
a. If receiver detection succeeds, the LNK_LTSSM_CONNECT interrupt
will be received. If this interrupt is received, the device will proceed
with enumeration in USB 3.0 mode.
3. If receiver detection fails, the LNK_LTSSM_DISCONNECT interrupt will
be received. If this interrupt is received:
a. Turn off USB 3.0 PHY and turn on USB 2.0 PHY.
b. A USB 2.0 bus reset will be received as part of USB 2.0
connection startup.
c. The 3.0 PHY should be re-enabled on receiving the URESET
interrupt that is triggered on a 2.0 bus reset. Both the 2.0 and 3.0
PHYs will be active at this time.
d. If the 3.0 receiver detection succeeds (LNK_LTSSM_CONNECT):
i.Turn off the USB 2.0 PHY.
ii.Proceed with enumeration as a USB 3.0 device.
e. If the 3.0 receiver detection fails (LNK_LTSSM_DISCONNECT):
i.Turn off the USB 3.0 PHY.
ii.Check number of times that 3.0 receiver detection has
failed. If this count is greater than 3:
4. Proceed with enumeration as a USB 2.0 device.
5. There is no need to attempt 3.0 enumeration on any further bus resets.
So, I guess the question would be, when the B200mini is plugged into the
MotoMod, is it getting a the LNK_LTSSM_CONNECT or LNK_LTSSM_DISCONNECT
interrupt. If it is the latter, then when the FX3 drops down to the USB
2.0 PHY, the MotoMod won't be able to do anything about it because of
the lack of D+/- lines. So that is the $10000 question right now.
~Jason
On 03/08/2017 10:10 PM, Marcus D. Leech wrote:
> On 03/08/2017 04:57 PM, Jason Matusiak wrote:
>> OK, that is likely my issue and makes USB3 a showstopper for now.
>> I'll stick with USB2.1 for now.
>>
>> Thanks for clearing that up, I am pretty clueless to the ins and outs
>> of USB.
> That's OK, so were the designers of USB. :) [MEOW]
>
>
>>
>> ~Jason
>>
>>
>> -------- Original message --------
>> From: "Marcus D. Leech via USRP-users" <[email protected]>
>> Date: 3/8/17 3:33 PM (GMT-05:00)
>> To: [email protected]
>> Subject: Re: [USRP-users] B200mini USB3 question
>>
>> On 03/08/2017 03:24 PM, Jason Matusiak via USRP-users wrote:
>> > I am playing with the mini and a Motorola Moto Z MotoMod and having a
>> > weird issue. When in USB3 mode, the motoMod powers the mini and I can
>> > see the microcontroller in the firmware recognizing that a device was
>> > plugged in, but the mini doesn't enumerate with Android.
>> >
>> > Someone pointed out that the MotoMod's "USB3 support is really just
>> > the super speed lines only, i.e. there is no d+, d-."
>> >
>> > I know that the d+/- are wired up for the USB2.1 protocol on the mini,
>> > but is something needed for the mini on those lines when using it in
>> > USB3 mode? (the MotoMod's USB3 mode is strictly a USB3 phy, so it does
>> > not auto-negotiate to USB2.1 if needed)
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected]
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> The FX3 comes up in USB-2.0 mode, and switches later on in the process.
>>
>>
>>
>> _______________________________________________
>> 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/20170309/48d57cd2/attachment-0001.html>
------------------------------
Message: 29
Date: Thu, 9 Mar 2017 10:15:51 -0500
From: Sean Nowlan <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USB 3 hub for B200/B200mini
Message-ID:
<cagmpsnqnb-qwb1h6piq0zgan5zxwfbb9-b+azgpmxtffpcd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Does anyone have a recommendation for a specific USB 3 hub brand and model
that works well with a B200 or B200mini? I'm streaming pretty low rates -
2-4M samples/second - and I'm sure most hubs could do that, but I'm worried
about reliability of connections, spurious disconnects, etc.
Thanks,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/58d3f2bb/attachment-0001.html>
------------------------------
Message: 30
Date: Thu, 9 Mar 2017 15:29:18 +0000
From: Xingjian Chen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Receiving Bursts Control Question
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am writing a control c++ file to receive timed packages. The idea is to using
Ettus board deterministic clock to schedule when a system start receiving and
recording data repeatedly . You can think it as a control similar to
tx_bursts.cpp in the example c++ file, but here is for receiving.
Assuming we declare "uhd::rx_metadata_t md" and "uhd::stream_cmd_t stream_cmd",
what is the difference between "stream_cmd.time_spec" and "md.time_spec"? What
the data flow look like? Which happened first? In order to achieving burst
receiving, should I schedule both of them? Thank you.
Here are some clues I found:
1. In the description from USRP manual:
uhd::stream_cmd_t Struct Reference
"Command struct for configuration and control of streaming:
A stream command defines how the device sends samples to the host. Streaming is
controlled by submitting a stream command to the rx dsp. Granular control over
what the device streams to the host can be achieved through submission of
multiple (carefully-crafted) commands."
uhd::rx_metadata_t Struct Reference
"RX metadata structure for describing sent IF data. Includes time
specification, fragmentation flags, burst flags, and error codes. The receive
routines will convert IF data headers into metadata."
2. In test_timed_conmmands.cpp, it states as below.
std::cout << boost::format(
" Received packet: %u samples, %u full secs, %f frac secs"
) % num_rx_samps % md.time_spec.get_full_secs() %
md.time_spec.get_frac_secs() << std::endl;
std::cout << boost::format(
" Stream time was: %u full secs, %f frac secs"
) % stream_time.get_full_secs() % stream_time.get_frac_secs() << std::endl;
std::cout << boost::format(
" Difference between stream time and first packet: %f us"
) % ((md.time_spec-stream_time).get_real_secs()*1e6) << std::endl;
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/307023b8/attachment-0001.html>
------------------------------
Message: 31
Date: Thu, 9 Mar 2017 20:01:27 +0800 (CST)
From: ??? <[email protected]>
To: [email protected]
Subject: [USRP-users] [USRP-Users]Promblems with realizing Feedback
with two USRP with XCVR2450 daughterboard
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=GB2312
Hi, I'm now working on two USRP N210s with XCVR2450 daughterboard. I want to
realize a feedback function. That is, USRP A sends a packet to USRP B and then,
USRP B gives an ACK back to USRP A. However, I find XCVR2450 doesn't support
full-duplex communication. How can I make USRP A transmitter first and then a
receiver, and then transmitter again? I try to use multi-threading in Python
but it fails because it seems USRP has decided it is a transmitter or a
receiver at the very beginning when it is initialized. What should I do?
Thank you in advance!
Best,
Yifeng Cao
------------------------------
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 79, Issue 9
*****************************************
