Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Porting/Using UHD (B200) under FreeBSD (Mike)
2. Re: [Discuss-gnuradio] connect USRP-2921 to gnuradio
(Marcus M?ller)
3. E300 Labview Fpga Programming (Adeel Anwar)
4. Re: E300 Labview Fpga Programming (Matt Ettus)
5. Re: X310 clock freq options (Jonathon Pendlum)
6. USRP Buffer Overflow (Andrew Wells)
7. FW: Welcome to the "USRP-users" mailing list (Digest mode) (Home)
8. Re: FW: Welcome to the "USRP-users" mailing list (Digest
mode) (Marcus M?ller)
9. Re: USRP Buffer Overflow (James Humphries)
10. Re: USRP Buffer Overflow (Marcus M?ller)
11. Fwd: Query - LFRX Daugterboard 0-30 MHz Rx (Kumar Vikramjeet)
12. Re: Fwd: Query - LFRX Daugterboard 0-30 MHz Rx (Derek Kozel)
13. Re: Fwd: Query - LFRX Daugterboard 0-30 MHz Rx (Marcus D. Leech)
14. Re: USRP Buffer Overflow (Andrew Wells)
15. Re: USRP Buffer Overflow (James Humphries)
16. Re: USRP Buffer Overflow (Andrew Wells)
17. Re: USRP Buffer Overflow (Rob Kossler)
18. Re: USRP Buffer Overflow (Marcus M?ller)
19. Fpga build compatibility issue (Tellrell White)
20. niusrprio_pcie failed to start (??)
21. Re: USRP Buffer Overflow (Andrew Wells)
22. Re: niusrprio_pcie failed to start (James Humphries)
23. Re: niusrprio_pcie failed to start (??)
24. Re: USRP Buffer Overflow (Marcus M?ller)
25. Why can't I load up my own custom wave.do file during an
RFNoC simulation in Modelsim? (Swanson, Craig)
26. Re: USRP Buffer Overflow (Rob Kossler)
27. Re: USRP Buffer Overflow (mle...@ripnet.com)
28. Re: Unknown UHD device type, running ./osmo-trx -f -> USRP
E310 (Carlos Canet)
29. Re: niusrprio_pcie failed to start (James Humphries)
----------------------------------------------------------------------
Message: 1
Date: Wed, 18 Nov 2015 18:20:22 +0100
From: Mike <e20151...@eeeit.de>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Porting/Using UHD (B200) under FreeBSD
Message-ID:
<20151118182022.horde.ql2gc9w8u4b9zdmqg4jl...@mail.eeeit.de>
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Hi Marcus,
I've setup a new FreeBSD system - 11-current - also built-in
USB3.0/USB2.0 Ports (ASrock N3150M).
The B200 Power connector is sourced by 6.3V this time additionally.
On USB3.0 I'm getting nearly the same behaviour as on the UX32VD with
uhd_usrp_probe:
...
root@ws1:/usr/ports/comms/uhd # uhd_usrp_probe
FreeBSD 11; Clang version 3.7.0 (tags/RELEASE_370/final 246257);
Boost_105500; UHD_003.009.001-0-unknown
-- Loading firmware image:
/usr/local/share/uhd/images/usrp_b200_fw.hex... done
-- Detected Device: B200
-- Loading FPGA image: /usr/local/share/uhd/images/usrp_b200_fpga.bin... done
-- Operating over USB 3.
libusb1_zero_copy,libusb_async_cb,tx,16,16,0,60635730041,60635728887
libusb1_zero_copy,libusb_async_cb,rx,0,24,0,60635730648,60635727228
libusb1_zero_copy,libusb_async_cb,tx,17,16,0,60635731176,60635730899
libusb1_zero_copy,libusb_async_cb,rx,1,24,0,60635731287,60635727264
libusb1_zero_copy,libusb_async_cb,tx,18,16,0,60635731366,60635730929
libusb1_zero_copy,libusb_async_cb,rx,2,24,0,60635731475,60635727426
libusb1_zero_copy,libusb_async_cb,tx,19,16,0,60635731655,60635731193
libusb1_zero_copy,libusb_async_cb,tx,20,16,0,60635731744,60635731219
libusb1_zero_copy,libusb_async_cb,rx,3,24,0,60635731820,60635727428
libusb1_zero_copy,libusb_async_cb,tx,21,16,0,60636776295,60636775638
libusb1_zero_copy,libusb_async_cb,rx,4,24,0,60636776407,60635727429
-- Detecting internal GPSDO....
libusb1_zero_copy,libusb_async_cb,tx,22,16,0,60636777148,60636776723
libusb1_zero_copy,libusb_async_cb,tx,23,16,0,60636777251,60636776750
No GPSDO found
libusb1_zero_copy,libusb_async_cb,tx,24,16,0,60638477034,60636776764
libusb1_zero_copy,libusb_async_cb,tx,25,16,0,60638477139,60636776767
libusb1_zero_copy,libusb_async_cb,tx,26,16,0,60638491558,60636776769
libusb1_zero_copy,libusb_async_cb,tx,27,16,0,60638491640,60636776771
libusb1_zero_copy,libusb_async_cb,rx,32,0,3,60640899073,60638490195
libusb1_zero_copy,libusb_async_cb,rx,33,0,3,60640899260,60638490219
libusb1_zero_copy,libusb_async_cb,rx,34,0,3,60640899391,60638490358
libusb1_zero_copy,libusb_async_cb,rx,35,0,3,60640899467,60638490361
libusb1_zero_copy,libusb_async_cb,rx,36,0,3,60640899541,60638490362
libusb1_zero_copy,libusb_async_cb,rx,37,0,3,60640899615,60638490363
libusb1_zero_copy,libusb_async_cb,rx,38,0,3,60640899690,60638490363
libusb1_zero_copy,libusb_async_cb,rx,39,0,3,60640899765,60638490364
libusb1_zero_copy,libusb_async_cb,rx,40,0,3,60640899840,60638490365
libusb1_zero_copy,libusb_async_cb,rx,41,0,3,60640899919,60638490366
libusb1_zero_copy,libusb_async_cb,rx,42,0,3,60640899994,60638490367
libusb1_zero_copy,libusb_async_cb,rx,43,0,3,60640900061,60638490368
libusb1_zero_copy,libusb_async_cb,rx,44,0,3,60640900126,60638490369
libusb1_zero_copy,libusb_async_cb,rx,45,0,3,60640900200,60638490370
libusb1_zero_copy,libusb_async_cb,rx,46,0,3,60640900275,60638490371
libusb1_zero_copy,libusb_async_cb,rx,47,0,3,60640900350,60638490372
libusb1_zero_copy,libusb_async_cb,tx,28,16,0,60640900873,60636776773
libusb1_zero_copy,libusb_async_cb,tx,29,16,0,60640901094,60636776774
libusb1_zero_copy,libusb_async_cb,tx,16,16,3,60643356966,60636776781
libusb1_zero_copy,libusb_async_cb,tx,17,16,3,60643357061,60636776783
libusb1_zero_copy,libusb_async_cb,tx,18,16,3,60643357139,60636776785
libusb1_zero_copy,libusb_async_cb,tx,19,16,3,60643357206,60636776787
libusb1_zero_copy,libusb_async_cb,tx,20,16,3,60643357281,60636776789
libusb1_zero_copy,libusb_async_cb,tx,21,16,3,60643357356,60638476611
libusb1_zero_copy,libusb_async_cb,tx,22,16,3,60643357431,60638491144
libusb1_zero_copy,libusb_async_cb,tx,23,16,3,60643357505,60638491179
libusb1_zero_copy,libusb_async_cb,tx,24,16,3,60643357572,60640900724
libusb1_zero_copy,libusb_async_cb,tx,30,0,3,60643357647,60636776776
libusb1_zero_copy,libusb_async_cb,tx,31,0,3,60643357714,60636776778
libusb1_zero_copy,libusb_async_cb,rx,0,24,3,60643359674,60635730770
libusb1_zero_copy,libusb_async_cb,rx,1,24,3,60643359756,60635731397
libusb1_zero_copy,libusb_async_cb,rx,2,24,3,60643359824,60635731618
libusb1_zero_copy,libusb_async_cb,rx,3,24,3,60643359894,60635731922
libusb1_zero_copy,libusb_async_cb,rx,4,24,3,60643359960,60636776502
libusb1_zero_copy,libusb_async_cb,rx,5,0,3,60643360036,60635727430
libusb1_zero_copy,libusb_async_cb,rx,6,0,3,60643360112,60635727431
libusb1_zero_copy,libusb_async_cb,rx,7,0,3,60643360187,60635727432
libusb1_zero_copy,libusb_async_cb,rx,8,0,3,60643360261,60635727433
libusb1_zero_copy,libusb_async_cb,rx,9,0,3,60643360336,60635727434
libusb1_zero_copy,libusb_async_cb,rx,10,0,3,60643360410,60635727435
libusb1_zero_copy,libusb_async_cb,rx,11,0,3,60643360482,60635727436
libusb1_zero_copy,libusb_async_cb,rx,12,0,3,60643360555,60635727437
libusb1_zero_copy,libusb_async_cb,rx,13,0,3,60643360621,60635727438
libusb1_zero_copy,libusb_async_cb,rx,14,0,3,60643360692,60635727439
libusb1_zero_copy,libusb_async_cb,rx,15,0,3,60643360759,60635727440
Error: AssertionError: accum_timeout < _timeout
in boost::uint64_t radio_ctrl_core_3000_impl::wait_for_ack(const bool)
at
/usr/ports/comms/uhd/work/uhd-f7a15853324e3e0001c7a9e5bab397cb24e0e01f/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:230
...
On USB2.0 Port I get on first call:
...
root@ws1:/usr/ports/comms/uhd # uhd_usrp_probe
FreeBSD 11; Clang version 3.7.0 (tags/RELEASE_370/final 246257);
Boost_105500; UHD_003.009.001-0-unknown
-- Detected Device: B200
-- Operating over USB 2.
libusb1_zero_copy,libusb_async_cb,tx,16,16,0,61504538865,61504537676
libusb1_zero_copy,libusb_async_cb,rx,0,24,0,61504539426,61504536066
libusb1_zero_copy,libusb_async_cb,tx,17,16,0,61504539892,61504539693
libusb1_zero_copy,libusb_async_cb,rx,1,24,0,61504540174,61504536102
libusb1_zero_copy,libusb_async_cb,tx,18,16,0,61504540268,61504539723
libusb1_zero_copy,libusb_async_cb,rx,2,24,0,61504540344,61504536214
libusb1_zero_copy,libusb_async_cb,tx,19,16,0,61504540417,61504539962
libusb1_zero_copy,libusb_async_cb,tx,20,16,0,61505555655,61504539992
libusb1_zero_copy,libusb_async_cb,tx,21,16,0,61505555750,61505555239
libusb1_zero_copy,libusb_async_cb,rx,3,24,0,61505555832,61504536217
-- Detecting internal GPSDO....
libusb1_zero_copy,libusb_async_cb,tx,22,16,0,61505556535,61505556247
libusb1_zero_copy,libusb_async_cb,tx,23,16,0,61505556803,61505556270
No GPSDO found
libusb1_zero_copy,libusb_async_cb,tx,24,16,0,61507256002,61505556284
libusb1_zero_copy,libusb_async_cb,tx,25,16,0,61507256098,61505556287
libusb1_zero_copy,libusb_async_cb,tx,26,16,0,61507270281,61505556289
libusb1_zero_copy,libusb_async_cb,tx,27,16,0,61507270364,61505556291
libusb1_zero_copy,libusb_async_cb,rx,32,0,3,61509677958,61507269025
libusb1_zero_copy,libusb_async_cb,rx,33,0,3,61509678098,61507269051
libusb1_zero_copy,libusb_async_cb,rx,34,0,3,61509678175,61507269130
libusb1_zero_copy,libusb_async_cb,rx,35,0,3,61509678249,61507269133
libusb1_zero_copy,libusb_async_cb,rx,36,0,3,61509678316,61507269134
libusb1_zero_copy,libusb_async_cb,rx,37,0,3,61509678391,61507269135
libusb1_zero_copy,libusb_async_cb,rx,38,0,3,61509678465,61507269135
libusb1_zero_copy,libusb_async_cb,rx,39,0,3,61509678531,61507269136
libusb1_zero_copy,libusb_async_cb,rx,40,0,3,61509678604,61507269137
libusb1_zero_copy,libusb_async_cb,rx,41,0,3,61509678679,61507269138
libusb1_zero_copy,libusb_async_cb,rx,42,0,3,61509678757,61507269139
libusb1_zero_copy,libusb_async_cb,rx,43,0,3,61509678823,61507269140
libusb1_zero_copy,libusb_async_cb,rx,44,0,3,61509678903,61507269141
libusb1_zero_copy,libusb_async_cb,rx,45,0,3,61509678977,61507269147
libusb1_zero_copy,libusb_async_cb,rx,46,0,3,61509679044,61507269147
libusb1_zero_copy,libusb_async_cb,rx,47,0,3,61509679120,61507269148
libusb1_zero_copy,libusb_async_cb,tx,28,16,0,61509679734,61505556293
libusb1_zero_copy,libusb_async_cb,tx,29,16,0,61509679817,61505556294
libusb1_zero_copy,libusb_async_cb,tx,16,16,3,61512137240,61505556301
libusb1_zero_copy,libusb_async_cb,tx,17,16,3,61512137348,61505556303
libusb1_zero_copy,libusb_async_cb,tx,18,16,3,61512137422,61505556305
libusb1_zero_copy,libusb_async_cb,tx,19,16,3,61512137490,61505556307
libusb1_zero_copy,libusb_async_cb,tx,20,16,3,61512137562,61505556365
libusb1_zero_copy,libusb_async_cb,tx,21,16,3,61512137634,61507255563
libusb1_zero_copy,libusb_async_cb,tx,22,16,3,61512137708,61507269901
libusb1_zero_copy,libusb_async_cb,tx,23,16,3,61512137783,61507269967
libusb1_zero_copy,libusb_async_cb,tx,24,16,3,61512137861,61509679459
Assertion failed: (!posix::pthread_mutex_destroy(&m)), function
~mutex, file /usr/local/include/boost/thread/pthread/mutex.hpp, line
108.
Abort (core dumped)
...
On subsequent calls:
...
root@ws1:/usr/ports/comms/uhd # uhd_usrp_probe
FreeBSD 11; Clang version 3.7.0 (tags/RELEASE_370/final 246257);
Boost_105500; UHD_003.009.001-0-unknown
-- Detected Device: B200
-- Operating over USB 2.
libusb1_zero_copy,libusb_async_cb,tx,16,16,0,61520442317,61520441742
libusb1_zero_copy,libusb_async_cb,rx,0,24,0,61520442927,61520440311
libusb1_zero_copy,libusb_async_cb,tx,17,16,0,61520443545,61520443226
libusb1_zero_copy,libusb_async_cb,rx,1,24,0,61520443667,61520440347
libusb1_zero_copy,libusb_async_cb,tx,18,16,0,61520443752,61520443252
libusb1_zero_copy,libusb_async_cb,rx,2,24,0,61520443819,61520440419
libusb1_zero_copy,libusb_async_cb,tx,19,16,0,61521506854,61520443420
libusb1_zero_copy,libusb_async_cb,tx,20,16,0,61521506950,61520443425
libusb1_zero_copy,libusb_async_cb,tx,21,16,0,61523913135,61521506466
libusb1_zero_copy,libusb_async_cb,rx,3,24,0,61523913268,61520440422
libusb1_zero_copy,libusb_async_cb,tx,22,16,0,61523913335,61523912490
libusb1_zero_copy,libusb_async_cb,rx,4,24,0,61523913557,61520440423
libusb1_zero_copy,libusb_async_cb,rx,0,24,3,61523920767,61520443096
libusb1_zero_copy,libusb_async_cb,rx,1,24,3,61523920876,61520443761
libusb1_zero_copy,libusb_async_cb,rx,2,24,3,61523920943,61520443909
libusb1_zero_copy,libusb_async_cb,rx,3,24,3,61523921010,61523913386
libusb1_zero_copy,libusb_async_cb,rx,4,24,3,61523921075,61523913680
libusb1_zero_copy,libusb_async_cb,rx,5,0,3,61523921152,61520440424
libusb1_zero_copy,libusb_async_cb,rx,6,0,3,61523921227,61520440425
libusb1_zero_copy,libusb_async_cb,rx,7,0,3,61523921303,61520440426
libusb1_zero_copy,libusb_async_cb,rx,8,0,3,61523921377,61520440427
libusb1_zero_copy,libusb_async_cb,rx,9,0,3,61523921451,61520440428
libusb1_zero_copy,libusb_async_cb,rx,10,0,3,61523921526,61520440429
libusb1_zero_copy,libusb_async_cb,rx,11,0,3,61523921601,61520440430
libusb1_zero_copy,libusb_async_cb,rx,12,0,3,61523921676,61520440431
libusb1_zero_copy,libusb_async_cb,rx,13,0,3,61523921750,61520440431
libusb1_zero_copy,libusb_async_cb,rx,14,0,3,61523921825,61520440432
libusb1_zero_copy,libusb_async_cb,rx,15,0,3,61523921905,61520440433
Error: AssertionError: accum_timeout < _timeout
in boost::uint64_t radio_ctrl_core_3000_impl::wait_for_ack(const bool)
at
/usr/ports/comms/uhd/work/uhd-f7a15853324e3e0001c7a9e5bab397cb24e0e01f/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:230
...
NB:
After unplug-plug the B200 from one USB port to another Port the
images don't get reloaded so it seems
that they get transferred correctly...
BTW:
If plugged in on the USB2.0 Port the OS sees:
root@ws1:/usr/ports/comms/uhd # usbconfig
ugen0.1: <XHCI root HUB 0x8086> at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=SAVE (0mA)
ugen0.2: <USB2.0 Hub vendor 0x05e3> at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (100mA)
ugen0.3: <USB Receiver Logitech> at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (98mA)
ugen0.4: <USRP B200 Ettus Research LLC> at usbus0, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON (2mA)
In USB3.0:
root@ws1:/usr/ports/comms/uhd # usbconfig
ugen0.1: <XHCI root HUB 0x8086> at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=SAVE (0mA)
ugen0.2: <USB2.0 Hub vendor 0x05e3> at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (100mA)
ugen0.3: <USB Receiver Logitech> at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (98mA)
ugen0.4: <USRP B200 Ettus Research LLC> at usbus0, cfg=0 md=HOST
spd=SUPER (5.0Gbps) pwr=ON (2mA)
I'll try Linux on this machine tomorrow but would expect it to work
too like on the UX32VD.
Hmm.
Greetings
---
Mike
Zitat von Marcus M?ller <marcus.muel...@ettus.com>:
> I must admit I don't know how to query the exact version of a library
> installed under FreeBSD, so knowing you're not using some pre-1 libusb
> is good.
>
> At this point, I think we need to reduce sources of error. Frankly, as
> none other than you involved in this discussion has extensive FreeBSD
> experience, I'd like to ask you to boot a live Linux medium to test
> whether it's a problem with the USRP or your OS / cooperation of UHD
> with that. There's the GNU Radio liveDVD [1], is that an option?
>
> Anyway,
>> Error: AssertionError: accum_timeout < _timeout
>> in boost::uint64_t radio_ctrl_core_3000_impl::wait_for_ack(const
>> bool)
> really has hit myself whenever my USB host's voltage went down under
> load; hence, really try for the external supply.
>
> The idea with the external supply actually came from the hope that
> disconnecting the B200 from the USB would reinitialize the B200 side of USB.
>
> Best regards,
> Marcus
>
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
> On 11/17/2015 04:59 PM, Mike wrote:
>> Hi Marcus,
>> at first I havn't found the proper pinout of the power supply
>> connector J601 anywhere.
>> Is the inner pin (+) or (-)?
>>
>> Anyway, I tried to achieve the same behaviour by using a powered
>> USB3.0 HUB.
>>
>> At the first call I get the bus-error like below.
>> Re-plug the HUB.
>> After re-pluging uhd_usrp_probe does not reload the images and behaves
>> like
>> if called repeatedly without re-pluging (triggering the assert).
>>
>> This seems at least to indicate that the images got transferred
>> correctly, right?
>>
>> Regarding the libusb version:
>> According to the manpage:
>> ...
>> The current implementation supports v1.0 of the libusb API.
>> ...
>>
>> Greetings
>> ---
>> Mike
>>
>> Zitat von Marcus M?ller via USRP-users <usrp-users@lists.ettus.com>:
>>
>>> Hi Mike,
>>>
>>> usually, if loading failed, you'd get an error. Since you don't, let's
>>> presume that works.
>>> Regarding your OS-specificness question: No, we don't differentiate.
>>> It's all libusb to us. By the way, which version of that are you using?
>>>
>>> Verification approach for successful loading:
>>> 1. Connect external power supply & USB
>>> 2. uhd_usrp_probe --init-only
>>> 3. Un- and Replug USB (hopefully correctly resetting bus state)
>>> 4. uhd_usrp_probe should now not try to load the firmware.
>>>
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 17.11.2015 10:01, Mike via USRP-users wrote:
>>>> Hi Michael,
>>>>
>>>>
>>>> Zitat von Michael West <michael.w...@ettus.com>:
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> This looks like it could be a USB host controller issue. I'm not
>>>>> sure what
>>>>> controller you are using, but we have seen these type of issues on
>>>>> Asmedia
>>>>> USB 3.0 controllers. Try a USB 2.0 port and see if it works. If it
>>>>> fails
>>>>> on the USB 2.0 port, it may be a hardware issue.
>>>>>
>>>>
>>>> HW-Failure is unlikely because - and sorry I forgot to mention earlier:
>>>> - I'm using a ASUS UX32VD Notebook which has USB3.0 only (3 ports)
>>>> - It has a INTEL USB Chipset
>>>> - The same config works (more-or-less without drops up to certain
>>>> bandwidth's) under Linux (Manjaro with the same version of UHD 3.9.1)
>>>>
>>>> Is there a way to ensure that - as a starter - the firmware/FPGA
>>>> images where transferred correctly?
>>>> (The uploader does not print any debug info...)
>>>>
>>>> Maybe there are differences in blocksizes, handshakes... between Linux
>>>> and others ?...
>>>> (Would a usbdump help here?)
>>>>
>>>> Greetings
>>>> ---
>>>> Mike
>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Sat, Nov 14, 2015 at 12:47 PM, Mike via USRP-users <
>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>> I'm trying to maintain and use the UHD 3.9.1 under/for FreeBSD.
>>>>>> The SW compiles under FreeBSD-current with two small CMake-Patches
>>>>>> quite
>>>>>> cleanly.
>>>>>> For debugging purposes I compiled with -DUHD_TXRX_DEBUG_PRINTS="yes"
>>>>>> UHD was compiled with clang3.7 and boost 1.55:
>>>>>> ...
>>>>>> boost-libs-1.55.0_9 Free portable C++ libraries (without
>>>>>> Boost.Python)
>>>>>> boost-python-libs-1.55.0 Framework for interfacing Python
>>>>>> and C++
>>>>>> ...
>>>>>>
>>>>>> Some parts seem to work like talking to or resetting the device:
>>>>>> ...
>>>>>> ux32)(root) # /usr/local/share/uhd/utils/b2xx_fx3_utils -S
>>>>>> FreeBSD 11; Clang version 3.7.0 (tags/RELEASE_370/final 246257);
>>>>>> Boost_105500; UHD_003.009.001-0-unknown
>>>>>>
>>>>>> Device opened (VID=0x2500,PID=0x0020)
>>>>>> B2xx detected... Control of B2xx granted...
>>>>>>
>>>>>> Currently operating at USB 3
>>>>>> Operation complete! I did it! I did it!
>>>>>> ...
>>>>>> (ux32)(root) # /usr/local/share/uhd/utils/b2xx_fx3_utils -D
>>>>>> FreeBSD 11; Clang version 3.7.0 (tags/RELEASE_370/final 246257);
>>>>>> Boost_105500; UHD_003.009.001-0-unknown
>>>>>>
>>>>>> Device opened (VID=0x2500,PID=0x0020)
>>>>>> B2xx detected... Control of B2xx granted...
>>>>>>
>>>>>> Operation complete! I did it! I did it!
>>>>>> ...
>>>>>>
>>>>>> (ux32)(root) # uhd_usrp_probe
>>>>>> FreeBSD 11; Clang version 3.7.0 (tags/RELEASE_370/final 246257);
>>>>>> Boost_105500; UHD_003.009.001-0-unknown
>>>>>>
>>>>>> -- Loading firmware image:
>>>>>> /usr/local/share/uhd/images/usrp_b200_fw.hex...
>>>>>> done
>>>>>> -- Detected Device: B200
>>>>>> -- Loading FPGA image:
>>>>>> /usr/local/share/uhd/images/usrp_b200_fpga.bin...
>>>>>> done
>>>>>> -- Operating over USB 3.
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,16,16,0,78036197267,78036195937
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,0,24,0,78036197419,78036195367
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,17,16,0,78036197557,78036197502
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,1,24,0,78036197605,78036195382
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,18,16,0,78036197791,78036197510
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,2,24,0,78036197818,78036195416
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,19,16,0,78036197847,78036197585
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,3,24,0,78036197878,78036195417
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,20,16,0,78037198296,78036197600
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,21,16,0,78037198352,78037198233
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,4,24,0,78037198579,78036195418
>>>>>> -- Detecting internal GPSDO....
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,22,16,0,78037198825,78037198705
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,23,16,0,78037198848,78037198711
>>>>>> No GPSDO found
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,24,16,0,78038811350,78037198714
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,25,16,0,78038811394,78037198715
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,26,16,0,78038823766,78037198715
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,27,16,0,78038823799,78037198716
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,32,0,3,78041230453,78038823349
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,33,0,3,78041230514,78038823356
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,34,0,3,78041230547,78038823385
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,35,0,3,78041230578,78038823386
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,36,0,3,78041230609,78038823387
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,37,0,3,78041230639,78038823388
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,38,0,3,78041230669,78038823388
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,39,0,3,78041230700,78038823389
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,40,0,3,78041230730,78038823389
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,41,0,3,78041230760,78038823389
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,42,0,3,78041230791,78038823390
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,43,0,3,78041230820,78038823390
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,44,0,3,78041230850,78038823390
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,45,0,3,78041230880,78038823390
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,46,0,3,78041230910,78038823391
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,47,0,3,78041230940,78038823391
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,28,16,0,78041231078,78037198717
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,29,16,0,78041231108,78037198717
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,16,16,3,78043706050,78037198719
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,17,16,3,78043706113,78037198720
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,18,16,3,78043706144,78037198720
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,19,16,3,78043706170,78037198721
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,20,16,3,78043706202,78037198722
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,21,16,3,78043706233,78038811293
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,22,16,3,78043706261,78038823598
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,23,16,3,78043706289,78038823611
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,24,16,3,78043706316,78041231043
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,30,0,3,78043706343,78037198718
>>>>>> Bus error(core dumped)
>>>>>>
>>>>>> (ux32)(root) # uhd_usrp_probe
>>>>>> FreeBSD 11; Clang version 3.7.0 (tags/RELEASE_370/final 246257);
>>>>>> Boost_105500; UHD_003.009.001-0-unknown
>>>>>>
>>>>>> -- Detected Device: B200
>>>>>> -- Operating over USB 3.
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,16,16,0,78138123983,78138123927
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,0,0,1,78138129478,78138123359
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,1,0,2,78138129507,78138123376
>>>>>>
>>>>>> UHD Error:
>>>>>> An unexpected exception was caught in a task loop.
>>>>>> The task loop will now exit, things may not work.
>>>>>> RuntimeError: usb rx8 transfer status: LIBUSB_ERROR_UNKNOWN
>>>>>> libusb1_zero_copy,libusb_async_cb,tx,17,16,0,78140529731,78140529672
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,2,0,3,78143010782,78138123411
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,3,0,3,78143010840,78138123412
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,4,0,3,78143010871,78138123413
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,5,0,3,78143010899,78138123413
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,6,0,3,78143010926,78138123414
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,7,0,3,78143010948,78138123414
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,8,0,3,78143010975,78138123415
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,9,0,3,78143011000,78138123415
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,10,0,3,78143011024,78138123416
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,11,0,3,78143011048,78138123416
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,12,0,3,78143011072,78138123417
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,13,0,3,78143011100,78138123418
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,14,0,3,78143011125,78138123418
>>>>>> libusb1_zero_copy,libusb_async_cb,rx,15,0,3,78143011150,78138123419
>>>>>> Error: AssertionError: accum_timeout < _timeout
>>>>>> in boost::uint64_t radio_ctrl_core_3000_impl::wait_for_ack(const
>>>>>> bool)
>>>>>> at
>>>>>> /usr/ports/comms/uhd/work/uhd-f7a15853324e3e0001c7a9e5bab397cb24e0e01f/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:230
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Any idea what could go wrong and how to debug this further?
>>>>>>
>>>>>> Tanks in advance!
>>>>>>
>>>>>> Greetings
>>>>>> ---
>>>>>> Michael
>>>>>> --
>>>>>> Greetings
>>>>>> ----
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
--
Greetings
----
Mike
------------------------------
Message: 2
Date: Wed, 18 Nov 2015 19:14:40 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: discuss-gnura...@gnu.org, "usrp-users@lists.ettus.com"
<USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] connect USRP-2921 to
gnuradio
Message-ID: <564cc010.5070...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Mohamed,
You're really not annoying; it's really nice to have you here!
I'm taking the usrp-users list into CC: here, and would like you to sign
up [1]for that and follow up there; this discussion doesn't have much to
do with GNU Radio, yet :)
I generally do not recommend using virtualization for high rate, real
time signal processing like you want to do, unless you know very well
how to set up your virtualizer in a manner that supports low-latency,
high-rate network communication.
Generally, this is with almost 99% probability a network problem, made
more complicated by the fact that you're in a VM.
What you really should not do is use NAT to connect your VM to your host
computer's network card; make sure you use a bridged network
configuration instead.
Best regards,
Marcus
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On 18.11.2015 18:22, mohamid92 wrote:
>
> Hello again and sorry for annoying
>
> I did all the step mentioned and installed gnuradio
>
> But again am still not able to connect to USRP 2921
>
> I AM using VMware , I detect the USRP in Windows but when I
> uhd_usrp_probe args=?addr=192.168.10.2? still cant detect it .
>
>
> : LookupError: KeyError: No devices found for ----->
> Device Address:
> addr: 192.168.10.2
>
>
>
> I can ping the host and USRP ip but cant detect the UHD ?
>
> *From:*Marcus M?ller-3 [via GnuRadio] [mailto:[hidden email]
> </user/SendEmail.jtp?type=node&node=57005&i=0>]
> *Sent:* Tuesday, November 17, 2015 1:36 PM
> *To:* mohamid92 <[hidden email]
> </user/SendEmail.jtp?type=node&node=57005&i=1>>
> *Subject:* Re: connect USRP-2921 to gnuradio
>
>
>
> Hi Mohamed,
>
> UHD 3.5.5, which you seem to be using, is so very old that it lacks
> crucial features. You should definitely update your UHD version.
> I assume you're using Ubuntu 14.04 (they are the only ones who still
> ship this old UHD), so please
>
> sudo apt-get remove uhd-host libuhd003 gnuradio
>
> and use pybombs to build UHD in its current version, a GNU Radio that
> uses that version and everything you need, from source:
>
> http://pybombs.info
>
> Then, try to ping your USRP:
>
> ping <ip-address of your USRP>
>
> If that doesn't work, you still have a network problem. Please refer to
> [1] :)
>
> Best regards,
> Marcus
>
> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_commprob
>
> On 17.11.2015 09:13, mohamid92 wrote:
>
>
> > hello
> >
> > i tried to implement FM reciever from this video :
> > https://www.youtube.com/watch?v=KWeY2yqwVA0
> >
> > but the problem is that everytime i need to run the grc an error
> show which
> > is:
> >
> > ----------------------------------------------
> >
> > linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
> >
> > Using Volk machine: avx_64_mmx_orc
> > Traceback (most recent call last):
> > File "/home/mohamed/GNURADIO exercise/top_block.py", line 157, in
> <module>
> > tb = top_block()
> > File "/home/mohamed/GNURADIO exercise/top_block.py", line 92, in
> __init__
> > channels=range(1),
> > File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line
> > 122, in constructor_interceptor
> > return old_constructor(*args)
> > File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line
> > 1737, in make
> > return _uhd_swig.usrp_source_make(*args)
> > RuntimeError: LookupError: KeyError: No devices found for ----->
> > Empty Device Address
> >
> > -----------------------------------------------
> >
> >
> >
> > --
> > View this message in context:
> http://gnuradio.4.n7.nabble.com/connect-USRP-2921-to-gnuradio-tp56967.html
> > Sent from the GnuRadio mailing list archive at Nabble.com.
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > [hidden email] </user/SendEmail.jtp?type=node&node=56969&i=0>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email] </user/SendEmail.jtp?type=node&node=56969&i=1>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ------------------------------------------------------------------------
>
> *If you reply to this email, your message will be added to the
> discussion below:*
>
> http://gnuradio.4.n7.nabble.com/connect-USRP-2921-to-gnuradio-tp56967p56969.html
>
>
> To unsubscribe from connect USRP-2921 to gnuradio, click here.
> NAML
> <http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
>
>
> ------------------------------------------------------------------------
> View this message in context: RE: connect USRP-2921 to gnuradio
> <http://gnuradio.4.n7.nabble.com/connect-USRP-2921-to-gnuradio-tp56967p57005.html>
> Sent from the GnuRadio mailing list archive
> <http://gnuradio.4.n7.nabble.com/> at Nabble.com.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/ef853dcc/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 18 Nov 2015 23:18:04 +0500
From: Adeel Anwar <adeela...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] E300 Labview Fpga Programming
Message-ID:
<cabpwzao9etu6ptngvx7xd1oaqpzeyjer_q+0pz_jwa-yuaf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have recently downloaded Matt Ettus GRcon15 presentation. It is mentioned
in the slides related to E300 that it supports Labview and Labview FPGA.
I just want to know that Labview USRP driver supporting E300 Fpga
programming has been released or its still under development?
Thanks
Adeel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/0d69431b/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 18 Nov 2015 10:39:59 -0800
From: Matt Ettus <m...@ettus.com>
To: Adeel Anwar <adeela...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E300 Labview Fpga Programming
Message-ID:
<CAN=1kn-hsf0qvxsfd0zxqmnjc-d3vrvqtggqf2gps9n7jxs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Adeel,
Unfortunately our plans have changed sine that presentation, and LabVIEW is
not going to be supported on E300. There is just too much effort that goes
into porting LabVIEW to the platform. The E300 series does support a full
UHD implementation, and GNU Radio runs on it very well.
Matt Ettus
On Wed, Nov 18, 2015 at 10:18 AM, Adeel Anwar via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> I have recently downloaded Matt Ettus GRcon15 presentation. It is
> mentioned in the slides related to E300 that it supports Labview and
> Labview FPGA.
> I just want to know that Labview USRP driver supporting E300 Fpga
> programming has been released or its still under development?
>
> Thanks
> Adeel
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/7f383887/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 18 Nov 2015 11:04:24 -0800
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Jason Matusiak <ja...@gardettoengineering.com>
Cc: Ettus Mail List <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] X310 clock freq options
Message-ID:
<CAGdo0uSQR4jbxkHyazmwCo=boqdhrmk0gnxiobe2i9ezda-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
You could use either, but bus_clk in my opinion is a better choice since it
operates at a fixed frequency. The MMCM settings change depending on the
input frequency, so if the MMCM was configured for a radio_clk of 200 MHz
and then driven at 120 MHz, the output clock could be incorrect.
On Wed, Nov 18, 2015 at 4:52 AM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:
> I think your direction will perfectly solve my problems, thank you.
>
> > I have hooked them all up to radio_clk which runs at the master clock
> rate and can be set to 200, 184.32,
> > or 120 MHz. There is also bus_clk which runs at 166.67 MHz that you can
> use or you can generate your own
> > clock with a MMCM.
>
> I was wondering if I was reading into your above statement too much? It
> looks to me that if I wanted to create my own clock (which I don't
> currently need to do), I should be using the bus_clk to drive the MMCM.
> What is special about the buc_clk that you recommend it for driving the
> MMCM versus the three clocks that are generated via the master clock?
> My guess would be the way that you are utilizing the fabric in the FPGA
> on the X310, but I thought I would ask for clarity. TIA!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/4869c776/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 18 Nov 2015 18:35:04 +0000
From: Andrew Wells <awe...@trellisware.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] USRP Buffer Overflow
Message-ID:
<b69db87ac918ec43b1b6fc1777d774481eec0...@twhq-mail1.trellisware.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I have a simple flowqraph in GNU Radio Companion, which is just a USRP source
connected to a File Sink. I'm using a USRP B200 connected by USB 3.0 to an
Intel USB controller. Based on the chart found at
http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
overflow (O's in the console) at sampling rates as low as 30 MS/s. A sampling
rate of 50 MS/s is critical for my intended application. Are there other parts
of the system that may be limiting the sample rate or other ways to increase it
without overflow?
Thanks,
Andrew Wells
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/3c5251d6/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 18 Nov 2015 22:14:08 +0300
From: Home <mohami...@live.com>
To: <usrp-users@lists.ettus.com>
Subject: [USRP-users] FW: Welcome to the "USRP-users" mailing list
(Digest mode)
Message-ID: <dub405-eas355ed903bdd79e93a34392c3...@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
when write in the command uhd_usrp_probe --args "addr=192.168.10.1" it will
show
sudo uhd_usrp_probe --args "addr=192.168.10.1"
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-89-gb17b440d
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
_____________________________________________________
/
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: N210r4
| | hardware: 2577
| | product: 30195
| | mac-addr: 00:80:2f:0a:ec:44
| | ip-addr: 192.168.10.1
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: F4EE38
| | FW Version: 12.4
| | FPGA Version: 11.1
| |
| | Time sources: none, external, _external_, mimo
| | Clock sources: internal, external, mimo
| | Sensors: mimo_locked, ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -50.000 to 50.000 MHz
| | _____________________________________________________
| | /
| | | RX DSP: 1
| | | Freq range: -50.000 to 50.000 MHz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: XCVR2450, XCVR2450 - r2.1 (0x0061)
| | | Serial: F4D8CE
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: XCVR2450 RX
| | | | Antennas: J1, J2
| | | | Sensors: lo_locked, rssi
| | | | Freq range: 2400.000 to 6000.000 MHz
| | | | Gain range LNA: 0.0 to 30.5 step 15.0 dB
| | | | Gain range VGA: 0.0 to 62.0 step 2.0 dB
| | | | Bandwidth range: 13500000.0 to 39600000.0 step 600000.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ads62p44
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | | | Gain range fine: 0.0 to 0.5 step 0.1 dB
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -50.000 to 50.000 MHz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: XCVR2450 - r2.1 (0x0059)
| | | Serial: F4D8CE
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: XCVR2450 TX
| | | | Antennas: J1, J2
| | | | Sensors: lo_locked
| | | | Freq range: 2400.000 to 6000.000 MHz
| | | | Gain range VGA: 0.0 to 30.0 step 0.5 dB
| | | | Gain range BB: 0.0 to 5.0 step 1.5 dB
| | | | Bandwidth range: 24000000.0 to 48000000.0 step 12000000.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9777
| | | | Gain Elements: None
But if write uhd_usrp_probe it will not detect the device
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-89-gb17b440d
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
- Below is my UHD block parameters Is it correct ?
-
-
Also Is there any images should I install for USRP-2921 ?
Thank you very much
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/0ee2c820/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 18718 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/0ee2c820/attachment-0001.jpg>
------------------------------
Message: 8
Date: Wed, 18 Nov 2015 20:20:54 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] FW: Welcome to the "USRP-users" mailing list
(Digest mode)
Message-ID: <564ccf96.3080...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Mohamed,
really, when you can address the USRP using its address, but it can't be
autodetected, it definitely is a network problem (albeit not a bad
one); it means that whatever sits between UHD and your network card
(i.e. a firewall and your virtualizer) is blocking broadcast packets.
Again, please refer to [1] to see which ports you will need to make
available.
Please, also don't run UHD programs as root ("sudo ..."), because they
don't need any root privileges.
Best regards,
Marcus
[1] http://files.ettus.com/manual/page_usrp2.html#usrp2_commprob_firewall
On 18.11.2015 20:14, Home via USRP-users wrote:
>
> when write in the command uhd_usrp_probe --args "addr=192.168.10.1" it
> will show
>
>
>
> sudo uhd_usrp_probe --args "addr=192.168.10.1"
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-89-gb17b440d
>
> ....
>
> But if write uhd_usrp_probe it will not detect the device
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-89-gb17b440d
>
>
>
> Error: LookupError: KeyError: No devices found for ----->
>
> Empty Device Address
>
> - Below is my UHD block parameters Is it correct ?
>
> -
>
> -
>
>
>
> Also Is there any images should I install for USRP-2921 ?
>
>
>
> Thank you very much
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/462414c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 18718 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/462414c6/attachment-0001.jpe>
------------------------------
Message: 9
Date: Wed, 18 Nov 2015 14:24:03 -0500
From: James Humphries <james.humphr...@ettus.com>
To: Andrew Wells <awe...@trellisware.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID:
<caewgfhxb3bywto-ueml0yonutb7eug41utbrtj2ihpldqrj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Andrew,
Writing to a file sink is usually a big bottleneck, as the hard drive will
limit the rate at which you can store data. You could try using a vector
sink to store data in memory or a RAM disk and have the file sink store
data there.
There is some extra overhead that is not counted in the benchmarks which
you will have in 'real world' use cases.
-Trip
On Wed, Nov 18, 2015 at 1:35 PM, Andrew Wells via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
>
>
> I have a simple flowqraph in GNU Radio Companion, which is just a USRP
> source connected to a File Sink. I?m using a USRP B200 connected by USB
> 3.0 to an Intel USB controller. Based on the chart found at
>
>
>
>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
>
>
> I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
> overflow (O?s in the console) at sampling rates as low as 30 MS/s. A
> sampling rate of 50 MS/s is critical for my intended application. Are there
> other parts of the system that may be limiting the sample rate or other
> ways to increase it without overflow?
>
>
>
> Thanks,
>
> Andrew Wells
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/cdfcb91f/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 18 Nov 2015 20:24:26 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID: <564cd06a.30...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Try replacing the file sink by e.g. a vector sink. Usually, hard drives
are much slower at writing than people expect; keeping up with a rate of
30MS/s of complex floats means that your hard drive needs to _sustain_ a
30MS/s*2float/s*4B/float = 240MB/s
write rate. That's too much even for many SSDs.
Notice that USB3 performance really depends on a lot of factors, but
this is the "easiest to diagnose" and "easiest to remedy" one; buffering
in RAM disk can often solve the problem (and that's exactly what
vector_sink does).
Best regards,
Marcus
On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
>
> Hello,
>
>
>
> I have a simple flowqraph in GNU Radio Companion, which is just a USRP
> source connected to a File Sink. I?m using a USRP B200 connected by
> USB 3.0 to an Intel USB controller. Based on the chart found at
>
>
>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
>
>
> I should be able to sample at up to 61.44 MS/s, but GNU Radio is
> reporting overflow (O?s in the console) at sampling rates as low as 30
> MS/s. A sampling rate of 50 MS/s is critical for my intended
> application. Are there other parts of the system that may be limiting
> the sample rate or other ways to increase it without overflow?
>
>
>
> Thanks,
>
> Andrew Wells
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/e546f5e8/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 18 Nov 2015 12:53:38 -0800
From: Kumar Vikramjeet <kumar.vikramj...@sv.cmu.edu>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Fwd: Query - LFRX Daugterboard 0-30 MHz Rx
Message-ID:
<CAFiSk=xfytlb0glhluuhrna+rinsenaf4hn7caaqnv78v0_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
We are working on a RF project, where we need to catch LF frequency
(135kHz) and transmit. We are already using ettus USRPs.
Can you please let us know if "LFRX Daughterboard 0-30 MHz Rx" can be used
for this purpose?
Also, if we order the device, how long it will take to reach us. We are
based in Mountain View, CA.
*Thanks & Regards,*
*Kumar Vikramjeet*
*Carnegie Mellon University*
*Information Networking Institute *
*MSIT-IS MS26 *
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/16f60fd6/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 18 Nov 2015 21:07:34 +0000
From: Derek Kozel <derek.ko...@ettus.com>
To: Kumar Vikramjeet <kumar.vikramj...@sv.cmu.edu>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Fwd: Query - LFRX Daugterboard 0-30 MHz Rx
Message-ID:
<CAA+K=tv4ynbfau8aibq6bzp8zeht+kww+_rapjwd0u_8m7a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Kumar,
Yes, the LFRX can receive 135 kHz. You will need the LFTX in order to
transmit. The fulfilment is done through NI so I don't know how long it
would take to arrive on campus, but my understanding is that they are in
stock.
Regards,
Derek
On Wed, Nov 18, 2015 at 8:53 PM, Kumar Vikramjeet via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
> Hi,
>
> We are working on a RF project, where we need to catch LF frequency
> (135kHz) and transmit. We are already using ettus USRPs.
>
> Can you please let us know if "LFRX Daughterboard 0-30 MHz Rx" can be
> used for this purpose?
>
> Also, if we order the device, how long it will take to reach us. We are
> based in Mountain View, CA.
>
>
>
>
> *Thanks & Regards,*
> *Kumar Vikramjeet*
> *Carnegie Mellon University*
> *Information Networking Institute *
> *MSIT-IS MS26 *
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/8cc2693c/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 18 Nov 2015 16:24:28 -0500
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Fwd: Query - LFRX Daugterboard 0-30 MHz Rx
Message-ID: <564cec8c.4020...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 11/18/2015 03:53 PM, Kumar Vikramjeet via USRP-users wrote:
>
> Hi,
>
> We are working on a RF project, where we need to catch LF frequency
> (135kHz) and transmit. We are already using ettus USRPs.
> Can you please let us know if "LFRX Daughterboard 0-30 MHz Rx" can be
> used for this purpose?
>
> Also, if we order the device, how long it will take to reach us. We
> are based in Mountain View, CA.
>
>
You'd have to talk to sa...@ettus.com for delivery.
Yes, the LF_RX and LF_TX operate over those frequency ranges. They have
no RF gain at all, they just "buffer" the ADC/DAC and provide a
30MHz low-pass response.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/69997d4a/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 18 Nov 2015 21:25:21 +0000
From: Andrew Wells <awe...@trellisware.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID:
<b69db87ac918ec43b1b6fc1777d774481eec0...@twhq-mail1.trellisware.com>
Content-Type: text/plain; charset="iso-8859-1"
I tried using a vector sink and reducing the USRP output data to complex int16
and the overflow persisted. Even using a null sync still had overflow. I have
an SSD that is supposed to be able to write at 460 MB/s, so that should not be
an issue for the file sync. Anything else I can try? I've experienced this
issue on two different machines.
Andrew
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
Marcus M?ller via USRP-users
Sent: Wednesday, November 18, 2015 11:24 AM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Buffer Overflow
Try replacing the file sink by e.g. a vector sink. Usually, hard drives are
much slower at writing than people expect; keeping up with a rate of 30MS/s of
complex floats means that your hard drive needs to _sustain_ a
30MS/s*2float/s*4B/float = 240MB/s
write rate. That's too much even for many SSDs.
Notice that USB3 performance really depends on a lot of factors, but this is
the "easiest to diagnose" and "easiest to remedy" one; buffering in RAM disk
can often solve the problem (and that's exactly what vector_sink does).
Best regards,
Marcus
On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
Hello,
I have a simple flowqraph in GNU Radio Companion, which is just a USRP source
connected to a File Sink. I'm using a USRP B200 connected by USB 3.0 to an
Intel USB controller. Based on the chart found at
http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
overflow (O's in the console) at sampling rates as low as 30 MS/s. A sampling
rate of 50 MS/s is critical for my intended application. Are there other parts
of the system that may be limiting the sample rate or other ways to increase it
without overflow?
Thanks,
Andrew Wells
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/6891757d/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 18 Nov 2015 16:33:51 -0500
From: James Humphries <james.humphr...@ettus.com>
To: Andrew Wells <awe...@trellisware.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID:
<caewgfhwdqpvc_+7ezfb9rzdckb6cehthdsp9a6qdh5eaj28...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
You may want to try using a tool to set the CPU to maximum performance. I
use 'indicator-cpufreq'. Make sure there are no power settings that may
limit CPU. What are you system specs (cpu, ram, etc)?
You can also try to set 'Realtime Scheduling' in the options block of your
flowgraph to see if that helps.
-Trip
On Wed, Nov 18, 2015 at 4:25 PM, Andrew Wells via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I tried using a vector sink and reducing the USRP output data to complex
> int16 and the overflow persisted. Even using a null sync still had
> overflow. I have an SSD that is supposed to be able to write at 460 MB/s,
> so that should not be an issue for the file sync. Anything else I can try?
> I?ve experienced this issue on two different machines.
>
>
>
> Andrew
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf
> Of *Marcus M?ller via USRP-users
> *Sent:* Wednesday, November 18, 2015 11:24 AM
> *To:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> Try replacing the file sink by e.g. a vector sink. Usually, hard drives
> are much slower at writing than people expect; keeping up with a rate of
> 30MS/s of complex floats means that your hard drive needs to _sustain_ a
> 30MS/s*2float/s*4B/float = 240MB/s
> write rate. That's too much even for many SSDs.
>
> Notice that USB3 performance really depends on a lot of factors, but this
> is the "easiest to diagnose" and "easiest to remedy" one; buffering in RAM
> disk can often solve the problem (and that's exactly what vector_sink does).
>
>
> Best regards,
> Marcus
>
> On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
>
> Hello,
>
>
>
> I have a simple flowqraph in GNU Radio Companion, which is just a USRP
> source connected to a File Sink. I?m using a USRP B200 connected by USB
> 3.0 to an Intel USB controller. Based on the chart found at
>
>
>
>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
>
>
> I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
> overflow (O?s in the console) at sampling rates as low as 30 MS/s. A
> sampling rate of 50 MS/s is critical for my intended application. Are there
> other parts of the system that may be limiting the sample rate or other
> ways to increase it without overflow?
>
>
>
> Thanks,
>
> Andrew Wells
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users@lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/466c0556/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 18 Nov 2015 21:55:20 +0000
From: Andrew Wells <awe...@trellisware.com>
To: James Humphries <james.humphr...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID:
<b69db87ac918ec43b1b6fc1777d774481eec0...@twhq-mail1.trellisware.com>
Content-Type: text/plain; charset="utf-8"
Thanks! The ?Realtime Scheduling? option allowed us to output to a null sync at
50 MS/s, but we are still having issues writing to a file at that speed.
Outputting to a vector sync seems to be worse than writing to a file. Any ideas
on how to increase the file write speed?
System Specs:
RAM: 12 GB
Processor: i7-6500u @ 2.5 GHz
OS: Ubuntu 15.10
SSD: Micron M600 MTFDDAK512MBF (510 MB/s write speed)
Andrew
From: James Humphries [mailto:james.humphr...@ettus.com]
Sent: Wednesday, November 18, 2015 1:34 PM
To: Andrew Wells
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Buffer Overflow
You may want to try using a tool to set the CPU to maximum performance. I use
'indicator-cpufreq'. Make sure there are no power settings that may limit CPU.
What are you system specs (cpu, ram, etc)?
You can also try to set 'Realtime Scheduling' in the options block of your
flowgraph to see if that helps.
-Trip
On Wed, Nov 18, 2015 at 4:25 PM, Andrew Wells via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
I tried using a vector sink and reducing the USRP output data to complex int16
and the overflow persisted. Even using a null sync still had overflow. I have
an SSD that is supposed to be able to write at 460 MB/s, so that should not be
an issue for the file sync. Anything else I can try? I?ve experienced this
issue on two different machines.
Andrew
From: USRP-users
[mailto:usrp-users-boun...@lists.ettus.com<mailto:usrp-users-boun...@lists.ettus.com>]
On Behalf Of Marcus M?ller via USRP-users
Sent: Wednesday, November 18, 2015 11:24 AM
To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Try replacing the file sink by e.g. a vector sink. Usually, hard drives are
much slower at writing than people expect; keeping up with a rate of 30MS/s of
complex floats means that your hard drive needs to _sustain_ a
30MS/s*2float/s*4B/float = 240MB/s
write rate. That's too much even for many SSDs.
Notice that USB3 performance really depends on a lot of factors, but this is
the "easiest to diagnose" and "easiest to remedy" one; buffering in RAM disk
can often solve the problem (and that's exactly what vector_sink does).
Best regards,
Marcus
On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
Hello,
I have a simple flowqraph in GNU Radio Companion, which is just a USRP source
connected to a File Sink. I?m using a USRP B200 connected by USB 3.0 to an
Intel USB controller. Based on the chart found at
http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
overflow (O?s in the console) at sampling rates as low as 30 MS/s. A sampling
rate of 50 MS/s is critical for my intended application. Are there other parts
of the system that may be limiting the sample rate or other ways to increase it
without overflow?
Thanks,
Andrew Wells
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/bc2d38ee/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 18 Nov 2015 17:40:54 -0500
From: Rob Kossler <rkoss...@nd.edu>
To: Andrew Wells <awe...@trellisware.com>
Cc: James Humphries <james.humphr...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID:
<cab__htqlcx8fm8wvx2p2rhnrfcrk7d_+as1tmlucj4-8jcd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Andrew,
I suggest setting up a RAM disk (relatively easy to do under Ubuntu). I
have 32GB RAM on my PC and I typically configure a 28GB RAM disk.
I have a Samsung EVO that reportedly can do in the ballpark of 500 MB/s.
However, even with 4 of these in an SSD array such that the write speed
should not be a bottleneck, I still can have issues at very fast sample
rates unless I stream to a file on the RAM disk. Not quite sure why.
Rob
On Wed, Nov 18, 2015 at 4:55 PM, Andrew Wells via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Thanks! The ?Realtime Scheduling? option allowed us to output to a null
> sync at 50 MS/s, but we are still having issues writing to a file at that
> speed. Outputting to a vector sync seems to be worse than writing to a
> file. Any ideas on how to increase the file write speed?
>
>
>
> System Specs:
>
> RAM: 12 GB
>
> Processor: i7-6500u @ 2.5 GHz
>
> OS: Ubuntu 15.10
>
> SSD: Micron M600 MTFDDAK512MBF (510 MB/s write speed)
>
>
>
>
>
> Andrew
>
>
>
> *From:* James Humphries [mailto:james.humphr...@ettus.com]
> *Sent:* Wednesday, November 18, 2015 1:34 PM
> *To:* Andrew Wells
> *Cc:* usrp-users@lists.ettus.com
>
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> You may want to try using a tool to set the CPU to maximum performance. I
> use 'indicator-cpufreq'. Make sure there are no power settings that may
> limit CPU. What are you system specs (cpu, ram, etc)?
>
>
>
> You can also try to set 'Realtime Scheduling' in the options block of your
> flowgraph to see if that helps.
>
>
>
> -Trip
>
>
>
> On Wed, Nov 18, 2015 at 4:25 PM, Andrew Wells via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I tried using a vector sink and reducing the USRP output data to complex
> int16 and the overflow persisted. Even using a null sync still had
> overflow. I have an SSD that is supposed to be able to write at 460 MB/s,
> so that should not be an issue for the file sync. Anything else I can try?
> I?ve experienced this issue on two different machines.
>
>
>
> Andrew
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf
> Of *Marcus M?ller via USRP-users
> *Sent:* Wednesday, November 18, 2015 11:24 AM
> *To:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> Try replacing the file sink by e.g. a vector sink. Usually, hard drives
> are much slower at writing than people expect; keeping up with a rate of
> 30MS/s of complex floats means that your hard drive needs to _sustain_ a
> 30MS/s*2float/s*4B/float = 240MB/s
> write rate. That's too much even for many SSDs.
>
> Notice that USB3 performance really depends on a lot of factors, but this
> is the "easiest to diagnose" and "easiest to remedy" one; buffering in RAM
> disk can often solve the problem (and that's exactly what vector_sink does).
>
>
> Best regards,
> Marcus
>
> On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
>
> Hello,
>
>
>
> I have a simple flowqraph in GNU Radio Companion, which is just a USRP
> source connected to a File Sink. I?m using a USRP B200 connected by USB
> 3.0 to an Intel USB controller. Based on the chart found at
>
>
>
>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
>
>
> I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
> overflow (O?s in the console) at sampling rates as low as 30 MS/s. A
> sampling rate of 50 MS/s is critical for my intended application. Are there
> other parts of the system that may be limiting the sample rate or other
> ways to increase it without overflow?
>
>
>
> Thanks,
>
> Andrew Wells
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users@lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/04aa1455/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 18 Nov 2015 23:47:20 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID: <564cfff8.8060...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Andrew,
Writing to a vector sink should under no circumstances be slower, as
that really takes but allocation of memory and in-RAM copies, unless you
run out of RAM, and in fact start writing to disk inadvertedly, by
swapping RAM to disk.
However, to fill 10GB (=10*2**30 B, assuming you need 2GB RAM for the
rest of your system) you'd need quite some samples ie. 10*2^30 B /
(4B/S) Samples for short complex, or half of that for float complex.
That would, at 50MS/s, amount to about 53s or 26s, respectively.
How long is your capture?
Regarding your SSD:
if you have that installed, run gnome-disks, and have a bit of fun with
different block sizes; here's two plots for different write block sizes
(1MB and 1000MB).
So, if it is really like your SSD is the bottleneck, we can expect the
work function of that to always find a full buffer, which typically is
32KB. If unbuffered is on, that's the granularity with which you ask
your file system to write stuff away.
If you want to have a raw write test in GNU Radio, connect a constant
source to "probe rate" block and a file sink.
If you want much more in-depth analysis of who spends how much time in
which block: compile GNU Radio with controlport enabled and add at
ctrlport monitor to your flow graph.
Best regards,
Marcus
On 18.11.2015 22:55, Andrew Wells via USRP-users wrote:
>
> Thanks! The ?Realtime Scheduling? option allowed us to output to a
> null sync at 50 MS/s, but we are still having issues writing to a file
> at that speed. Outputting to a vector sync seems to be worse than
> writing to a file. Any ideas on how to increase the file write speed?
>
>
>
> System Specs:
>
> RAM: 12 GB
>
> Processor: i7-6500u @ 2.5 GHz
>
> OS: Ubuntu 15.10
>
> SSD: Micron M600 MTFDDAK512MBF (510 MB/s write speed)
>
>
>
>
>
> Andrew
>
>
>
> *From:*James Humphries [mailto:james.humphr...@ettus.com]
> *Sent:* Wednesday, November 18, 2015 1:34 PM
> *To:* Andrew Wells
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> You may want to try using a tool to set the CPU to maximum
> performance. I use 'indicator-cpufreq'. Make sure there are no power
> settings that may limit CPU. What are you system specs (cpu, ram, etc)?
>
>
>
> You can also try to set 'Realtime Scheduling' in the options block of
> your flowgraph to see if that helps.
>
>
>
> -Trip
>
>
>
> On Wed, Nov 18, 2015 at 4:25 PM, Andrew Wells via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> I tried using a vector sink and reducing the USRP output data to
> complex int16 and the overflow persisted. Even using a null sync still
> had overflow. I have an SSD that is supposed to be able to write at
> 460 MB/s, so that should not be an issue for the file sync. Anything
> else I can try? I?ve experienced this issue on two different machines.
>
>
>
> Andrew
>
>
>
> *From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com
> <mailto:usrp-users-boun...@lists.ettus.com>] *On Behalf Of *Marcus
> M?ller via USRP-users
> *Sent:* Wednesday, November 18, 2015 11:24 AM
> *To:* usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> Try replacing the file sink by e.g. a vector sink. Usually, hard
> drives are much slower at writing than people expect; keeping up with
> a rate of 30MS/s of complex floats means that your hard drive needs to
> _sustain_ a
> 30MS/s*2float/s*4B/float = 240MB/s
> write rate. That's too much even for many SSDs.
>
> Notice that USB3 performance really depends on a lot of factors, but
> this is the "easiest to diagnose" and "easiest to remedy" one;
> buffering in RAM disk can often solve the problem (and that's exactly
> what vector_sink does).
>
>
> Best regards,
> Marcus
>
> On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
>
> Hello,
>
>
>
> I have a simple flowqraph in GNU Radio Companion, which is just a
> USRP source connected to a File Sink. I?m using a USRP B200
> connected by USB 3.0 to an Intel USB controller. Based on the
> chart found at
>
>
>
>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
>
>
> I should be able to sample at up to 61.44 MS/s, but GNU Radio is
> reporting overflow (O?s in the console) at sampling rates as low
> as 30 MS/s. A sampling rate of 50 MS/s is critical for my intended
> application. Are there other parts of the system that may be
> limiting the sample rate or other ways to increase it without
> overflow?
>
>
>
> Thanks,
>
> Andrew Wells
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/dcd54dc4/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 18 Nov 2015 18:57:42 -0500
From: Tellrell White <t_whit...@yahoo.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Fpga build compatibility issue
Message-ID: <f5bf045c-0ce8-4b07-a4f5-401b75675...@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Hello
I'm trying to run the rfnoc_tx example on the e310 but i'm getting the error
below. It's a compatibility issue with the fpga build. How exactly would i go
about fixing this issue?
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control...
-- Performing register loopback test... pass
Traceback (most recent call last):
File "./rfnoc_tx.py", line 130, in <module>
tb = rfnoc_tx()
File "./rfnoc_tx.py", line 58, in __init__
self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t(
",".join(("type=e3x0", "")) ))
File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line 1803, in
make
return _ettus_swig.device3_make(*args, **kwargs)
RuntimeError: RuntimeError: Expected FPGA compatibility number 255.x, but got
10.0:
The FPGA build is not compatible with the host code build.
Please run:
"/usr/lib/uhd/utils/uhd_images_downloader.py"
Thanks
Tellrell
Sent from my iPhone
------------------------------
Message: 20
Date: Thu, 19 Nov 2015 09:03:54 +0800
From: ?? <bighead13...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] niusrprio_pcie failed to start
Message-ID:
<cajljrcqg307jhprqj5kwgs9ec9pzzk7ddll8bjxzorp1wiq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello every,
I'm using Ubuntu 14.04.3 with UHD 003.010.git-87-g88b0baea. I trying to
install niusrprio-installer 15.0.0 to connect X310 with MXI-Express. I
follow this instruction :
http://files.ettus.com/manual/page_ni_rio_kernel.html I also run sudo
/usr/local/bin/updateNIDrivers --no-prompt to rebuild the kernel modules
for the currently running kernel and reboot.
Herer is start the service comes problem :
# sudo /usr/local/bin/niusrprio_pcie start
Loading: NiRioSrv modprobe: ERROR: could not insert 'NiRioSrv': Invalid
argument
niusrpriok modprobe: ERROR: could not insert 'niusrpriok': Invalid argument
Starting: niusrpriorpc
I using dmesg and find out this
[ 122.326245] nibds: no symbol version for nNIKAL100_getTimeOfDayInterval
[ 122.326255] nibds: Unknown symbol nNIKAL100_getTimeOfDayInterval (err
-22)
[ 122.326263] nibds: no symbol version for nNIKAL100_createSpinLock
[ 122.326267] nibds: Unknown symbol nNIKAL100_createSpinLock (err -22)
[ 122.326274] nibds: no symbol version for nNIKAL150_createMutex
[ 122.326277] nibds: Unknown symbol nNIKAL150_createMutex (err -22)
[ 122.326283] nibds: no symbol version for nNIKAL100_destroySpinLock
[ 122.326287] nibds: Unknown symbol nNIKAL100_destroySpinLock (err -22)
[ 122.326293] nibds: no symbol version for nNIKAL200_joinThread
[ 122.326296] nibds: Unknown symbol nNIKAL200_joinThread (err -22)
[ 122.326303] nibds: no symbol version for nNIKAL100_releaseSingleUseEvent
[ 122.326306] nibds: Unknown symbol nNIKAL100_releaseSingleUseEvent (err
-22)
...
...
....
How to fixed it ?
Thanks
Jeff Guo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151119/74fb05b7/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 19 Nov 2015 01:25:26 +0000
From: Andrew Wells <awe...@trellisware.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID:
<b69db87ac918ec43b1b6fc1777d774481eec0...@twhq-mail1.trellisware.com>
Content-Type: text/plain; charset="iso-8859-1"
I tried the raw write test in GNU Radio using the probe rate block and found
that the data was being written the disk relatively consistently at 50 MS/s,
but has occasional drops below that rate. This is consistent with the overflow
we are seeing when collecting data from the USRP. Setting up a RAM disc is not
a great option for us because we only have 12 GB of ram and are looking to run
for longer than a minute at a time. Are there any Linux specific things we can
do stabilize the SSD write rate or prioritize writes from GNU Radio?
Andrew
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
Marcus M?ller via USRP-users
Sent: Wednesday, November 18, 2015 2:47 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Buffer Overflow
Hi Andrew,
Writing to a vector sink should under no circumstances be slower, as that
really takes but allocation of memory and in-RAM copies, unless you run out of
RAM, and in fact start writing to disk inadvertedly, by swapping RAM to disk.
However, to fill 10GB (=10*2**30 B, assuming you need 2GB RAM for the rest of
your system) you'd need quite some samples ie. 10*2^30 B / (4B/S) Samples for
short complex, or half of that for float complex. That would, at 50MS/s, amount
to about 53s or 26s, respectively.
How long is your capture?
Regarding your SSD:
if you have that installed, run gnome-disks, and have a bit of fun with
different block sizes; here's two plots for different write block sizes (1MB
and 1000MB).
So, if it is really like your SSD is the bottleneck, we can expect the work
function of that to always find a full buffer, which typically is 32KB. If
unbuffered is on, that's the granularity with which you ask your file system to
write stuff away.
If you want to have a raw write test in GNU Radio, connect a constant source to
"probe rate" block and a file sink.
If you want much more in-depth analysis of who spends how much time in which
block: compile GNU Radio with controlport enabled and add at ctrlport monitor
to your flow graph.
Best regards,
Marcus
On 18.11.2015 22:55, Andrew Wells via USRP-users wrote:
Thanks! The 'Realtime Scheduling' option allowed us to output to a null sync at
50 MS/s, but we are still having issues writing to a file at that speed.
Outputting to a vector sync seems to be worse than writing to a file. Any ideas
on how to increase the file write speed?
System Specs:
RAM: 12 GB
Processor: i7-6500u @ 2.5 GHz
OS: Ubuntu 15.10
SSD: Micron M600 MTFDDAK512MBF (510 MB/s write speed)
Andrew
From: James Humphries [mailto:james.humphr...@ettus.com]
Sent: Wednesday, November 18, 2015 1:34 PM
To: Andrew Wells
Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
You may want to try using a tool to set the CPU to maximum performance. I use
'indicator-cpufreq'. Make sure there are no power settings that may limit CPU.
What are you system specs (cpu, ram, etc)?
You can also try to set 'Realtime Scheduling' in the options block of your
flowgraph to see if that helps.
-Trip
On Wed, Nov 18, 2015 at 4:25 PM, Andrew Wells via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
I tried using a vector sink and reducing the USRP output data to complex int16
and the overflow persisted. Even using a null sync still had overflow. I have
an SSD that is supposed to be able to write at 460 MB/s, so that should not be
an issue for the file sync. Anything else I can try? I've experienced this
issue on two different machines.
Andrew
From: USRP-users
[mailto:usrp-users-boun...@lists.ettus.com<mailto:usrp-users-boun...@lists.ettus.com>]
On Behalf Of Marcus M?ller via USRP-users
Sent: Wednesday, November 18, 2015 11:24 AM
To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Try replacing the file sink by e.g. a vector sink. Usually, hard drives are
much slower at writing than people expect; keeping up with a rate of 30MS/s of
complex floats means that your hard drive needs to _sustain_ a
30MS/s*2float/s*4B/float = 240MB/s
write rate. That's too much even for many SSDs.
Notice that USB3 performance really depends on a lot of factors, but this is
the "easiest to diagnose" and "easiest to remedy" one; buffering in RAM disk
can often solve the problem (and that's exactly what vector_sink does).
Best regards,
Marcus
On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
Hello,
I have a simple flowqraph in GNU Radio Companion, which is just a USRP source
connected to a File Sink. I'm using a USRP B200 connected by USB 3.0 to an
Intel USB controller. Based on the chart found at
http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
overflow (O's in the console) at sampling rates as low as 30 MS/s. A sampling
rate of 50 MS/s is critical for my intended application. Are there other parts
of the system that may be limiting the sample rate or other ways to increase it
without overflow?
Thanks,
Andrew Wells
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151119/68596982/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 18 Nov 2015 22:07:25 -0500
From: James Humphries <james.humphr...@ettus.com>
To: ?? <bighead13...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] niusrprio_pcie failed to start
Message-ID:
<caewgfhu+tcz-anwqeaiuzqavotzjjb9jok9idzagbn3cqbx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jeff,
What kernel are you running with your installation? The following command
should tell you:
uname -r
-Trip
On Wed, Nov 18, 2015 at 8:03 PM, ?? via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello every,
>
> I'm using Ubuntu 14.04.3 with UHD 003.010.git-87-g88b0baea. I trying to
> install niusrprio-installer 15.0.0 to connect X310 with MXI-Express. I
> follow this instruction :
> http://files.ettus.com/manual/page_ni_rio_kernel.html I also run sudo
> /usr/local/bin/updateNIDrivers --no-prompt to rebuild the kernel modules
> for the currently running kernel and reboot.
>
> Herer is start the service comes problem :
> # sudo /usr/local/bin/niusrprio_pcie start
> Loading: NiRioSrv modprobe: ERROR: could not insert 'NiRioSrv': Invalid
> argument
> niusrpriok modprobe: ERROR: could not insert 'niusrpriok': Invalid argument
>
> Starting: niusrpriorpc
>
> I using dmesg and find out this
> [ 122.326245] nibds: no symbol version for nNIKAL100_getTimeOfDayInterval
> [ 122.326255] nibds: Unknown symbol nNIKAL100_getTimeOfDayInterval (err
> -22)
> [ 122.326263] nibds: no symbol version for nNIKAL100_createSpinLock
> [ 122.326267] nibds: Unknown symbol nNIKAL100_createSpinLock (err -22)
> [ 122.326274] nibds: no symbol version for nNIKAL150_createMutex
> [ 122.326277] nibds: Unknown symbol nNIKAL150_createMutex (err -22)
> [ 122.326283] nibds: no symbol version for nNIKAL100_destroySpinLock
> [ 122.326287] nibds: Unknown symbol nNIKAL100_destroySpinLock (err -22)
> [ 122.326293] nibds: no symbol version for nNIKAL200_joinThread
> [ 122.326296] nibds: Unknown symbol nNIKAL200_joinThread (err -22)
> [ 122.326303] nibds: no symbol version for nNIKAL100_releaseSingleUseEvent
> [ 122.326306] nibds: Unknown symbol nNIKAL100_releaseSingleUseEvent (err
> -22)
> ...
> ...
> ....
>
> How to fixed it ?
>
> Thanks
>
> Jeff Guo
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151118/a461ce32/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 19 Nov 2015 11:27:32 +0800
From: ?? <bighead13...@gmail.com>
To: James Humphries <james.humphr...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] niusrprio_pcie failed to start
Message-ID:
<cajljrcpexoxfcwkqtts3e2z8ae9uc5bzekwcmm_6ape1lp5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Trip,
# uname -r
3.19.0-33-generic
According to http://files.ettus.com/manual/page_ni_rio_kernel.html, I think
it works. Am I right?
I do sudo /usr/local/bin/updateNIDrivers --no-prompt many many times and
reboot, still the same problem.
Jeff
2015-11-19 11:07 GMT+08:00 James Humphries <james.humphr...@ettus.com>:
> Hi Jeff,
>
> What kernel are you running with your installation? The following command
> should tell you:
>
> uname -r
>
> -Trip
>
> On Wed, Nov 18, 2015 at 8:03 PM, ?? via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello every,
>>
>> I'm using Ubuntu 14.04.3 with UHD 003.010.git-87-g88b0baea. I trying to
>> install niusrprio-installer 15.0.0 to connect X310 with MXI-Express. I
>> follow this instruction :
>> http://files.ettus.com/manual/page_ni_rio_kernel.html I also run sudo
>> /usr/local/bin/updateNIDrivers --no-prompt to rebuild the kernel modules
>> for the currently running kernel and reboot.
>>
>> Herer is start the service comes problem :
>> # sudo /usr/local/bin/niusrprio_pcie start
>> Loading: NiRioSrv modprobe: ERROR: could not insert 'NiRioSrv': Invalid
>> argument
>> niusrpriok modprobe: ERROR: could not insert 'niusrpriok': Invalid
>> argument
>>
>> Starting: niusrpriorpc
>>
>> I using dmesg and find out this
>> [ 122.326245] nibds: no symbol version for nNIKAL100_getTimeOfDayInterval
>> [ 122.326255] nibds: Unknown symbol nNIKAL100_getTimeOfDayInterval (err
>> -22)
>> [ 122.326263] nibds: no symbol version for nNIKAL100_createSpinLock
>> [ 122.326267] nibds: Unknown symbol nNIKAL100_createSpinLock (err -22)
>> [ 122.326274] nibds: no symbol version for nNIKAL150_createMutex
>> [ 122.326277] nibds: Unknown symbol nNIKAL150_createMutex (err -22)
>> [ 122.326283] nibds: no symbol version for nNIKAL100_destroySpinLock
>> [ 122.326287] nibds: Unknown symbol nNIKAL100_destroySpinLock (err -22)
>> [ 122.326293] nibds: no symbol version for nNIKAL200_joinThread
>> [ 122.326296] nibds: Unknown symbol nNIKAL200_joinThread (err -22)
>> [ 122.326303] nibds: no symbol version for
>> nNIKAL100_releaseSingleUseEvent
>> [ 122.326306] nibds: Unknown symbol nNIKAL100_releaseSingleUseEvent (err
>> -22)
>> ...
>> ...
>> ....
>>
>> How to fixed it ?
>>
>> Thanks
>>
>> Jeff Guo
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151119/db13b396/attachment-0001.html>
------------------------------
Message: 24
Date: Thu, 19 Nov 2015 11:31:25 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: Andrew Wells <awe...@trellisware.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID: <564da4fd.1030...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Andrew,
I must admit that I've had long discussions about that and we never came
quite to a conclusion, but:
of course you can optimize your system for write performance. Make the
file system buffers large, don't use a journalling file system, make
sure GNU Radio is the only one acquiring attention from that disk to
make things work more "averagely" on the data sink side of things.
I usually refer people to [1] for tweaking of their file system
behavior. What I like about that answer is that the author stresses the
fact that you're trading safety for speed if you're buffering much of
your samples in RAM.
Another approach that many people find helpful is:
1. Making a Unix-style FIFO, e.g. mkfifo /arbitrary/path/fifo
2. start writing the contents of that FIFO to the storage (this will
block until there actually is data), ie. cat /arbitrary/path/fifo >
/media/ssd/samples.dat (or even "dd if=/arbitrary/path/fifo
of=/media/ssd/samples.dat bs=<block size in Bytes>", if you want to
control the write chunk sizes. Try with just cat first.)
3. use the file sink with the /arbitrary/path/fifo
Cheers,
Marcus
[1] http://unix.stackexchange.com/a/41831/106650
On 19.11.2015 02:25, Andrew Wells wrote:
>
> I tried the raw write test in GNU Radio using the probe rate block and
> found that the data was being written the disk relatively consistently
> at 50 MS/s, but has occasional drops below that rate. This is
> consistent with the overflow we are seeing when collecting data from
> the USRP. Setting up a RAM disc is not a great option for us because
> we only have 12 GB of ram and are looking to run for longer than a
> minute at a time. Are there any Linux specific things we can do
> stabilize the SSD write rate or prioritize writes from GNU Radio?
>
>
>
> Andrew
>
>
>
> *From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
> Behalf Of *Marcus M?ller via USRP-users
> *Sent:* Wednesday, November 18, 2015 2:47 PM
> *To:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> Hi Andrew,
>
> Writing to a vector sink should under no circumstances be slower, as
> that really takes but allocation of memory and in-RAM copies, unless
> you run out of RAM, and in fact start writing to disk inadvertedly, by
> swapping RAM to disk.
> However, to fill 10GB (=10*2**30 B, assuming you need 2GB RAM for the
> rest of your system) you'd need quite some samples ie. 10*2^30 B /
> (4B/S) Samples for short complex, or half of that for float complex.
> That would, at 50MS/s, amount to about 53s or 26s, respectively.
> How long is your capture?
>
> Regarding your SSD:
> if you have that installed, run gnome-disks, and have a bit of fun
> with different block sizes; here's two plots for different write block
> sizes (1MB and 1000MB).
> So, if it is really like your SSD is the bottleneck, we can expect the
> work function of that to always find a full buffer, which typically is
> 32KB. If unbuffered is on, that's the granularity with which you ask
> your file system to write stuff away.
>
> If you want to have a raw write test in GNU Radio, connect a constant
> source to "probe rate" block and a file sink.
> If you want much more in-depth analysis of who spends how much time in
> which block: compile GNU Radio with controlport enabled and add at
> ctrlport monitor to your flow graph.
>
> Best regards,
> Marcus
>
> On 18.11.2015 22:55, Andrew Wells via USRP-users wrote:
>
> Thanks! The ?Realtime Scheduling? option allowed us to output to a
> null sync at 50 MS/s, but we are still having issues writing to a
> file at that speed. Outputting to a vector sync seems to be worse
> than writing to a file. Any ideas on how to increase the file
> write speed?
>
>
>
> System Specs:
>
> RAM: 12 GB
>
> Processor: i7-6500u @ 2.5 GHz
>
> OS: Ubuntu 15.10
>
> SSD: Micron M600 MTFDDAK512MBF (510 MB/s write speed)
>
>
>
>
>
> Andrew
>
>
>
> *From:*James Humphries [mailto:james.humphr...@ettus.com]
> *Sent:* Wednesday, November 18, 2015 1:34 PM
> *To:* Andrew Wells
> *Cc:* usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> You may want to try using a tool to set the CPU to maximum
> performance. I use 'indicator-cpufreq'. Make sure there are no
> power settings that may limit CPU. What are you system specs (cpu,
> ram, etc)?
>
>
>
> You can also try to set 'Realtime Scheduling' in the options block
> of your flowgraph to see if that helps.
>
>
>
> -Trip
>
>
>
> On Wed, Nov 18, 2015 at 4:25 PM, Andrew Wells via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
> wrote:
>
> I tried using a vector sink and reducing the USRP output data to
> complex int16 and the overflow persisted. Even using a null sync
> still had overflow. I have an SSD that is supposed to be able to
> write at 460 MB/s, so that should not be an issue for the file
> sync. Anything else I can try? I?ve experienced this issue on two
> different machines.
>
>
>
> Andrew
>
>
>
> *From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com
> <mailto:usrp-users-boun...@lists.ettus.com>] *On Behalf Of *Marcus
> M?ller via USRP-users
> *Sent:* Wednesday, November 18, 2015 11:24 AM
> *To:* usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> Try replacing the file sink by e.g. a vector sink. Usually, hard
> drives are much slower at writing than people expect; keeping up
> with a rate of 30MS/s of complex floats means that your hard drive
> needs to _sustain_ a
> 30MS/s*2float/s*4B/float = 240MB/s
> write rate. That's too much even for many SSDs.
>
> Notice that USB3 performance really depends on a lot of factors,
> but this is the "easiest to diagnose" and "easiest to remedy" one;
> buffering in RAM disk can often solve the problem (and that's
> exactly what vector_sink does).
>
>
> Best regards,
> Marcus
>
> On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
>
> Hello,
>
>
>
> I have a simple flowqraph in GNU Radio Companion, which is
> just a USRP source connected to a File Sink. I?m using a USRP
> B200 connected by USB 3.0 to an Intel USB controller. Based on
> the chart found at
>
>
>
>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
>
>
> I should be able to sample at up to 61.44 MS/s, but GNU Radio
> is reporting overflow (O?s in the console) at sampling rates
> as low as 30 MS/s. A sampling rate of 50 MS/s is critical for
> my intended application. Are there other parts of the system
> that may be limiting the sample rate or other ways to increase
> it without overflow?
>
>
>
> Thanks,
>
> Andrew Wells
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151119/5b625edb/attachment-0001.html>
------------------------------
Message: 25
Date: Thu, 19 Nov 2015 12:40:00 +0000
From: "Swanson, Craig" <craig.swan...@gtri.gatech.edu>
To: Jonathon Pendlum <jonathon.pend...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Why can't I load up my own custom wave.do file
during an RFNoC simulation in Modelsim?
Message-ID: <1447936799954.2...@gtri.gatech.edu>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
I think I remember you told me that this was a Xilinx tcl script issue and not
a Modelsim issue.
To review, here are my steps to reproduce the problem:
1. ?from /lib/rfnoc/noc_block_moving_avg_tb?, run "make vsim GUI=1" (I have
to run in GUI mode because of the Modelsim DE 10.4b issue). If I run without
the GUI=1 then it fails. It would be great if you could help me fix this issue
as well.
2. Vivado opens up
3. Run a behavioral simulation
4. Modelsim opens up and runs the simulation.
5. Delete the default waveform (tc_running, tc_failed, tc_run_count,
tc_pass_count, bus_clk, GSR, etc.)
6. Load up my own wave.do file with more useful information
7. Restart and rerun the simulation
It is such a hassle to delete the default wave.do file and reload my own
wave.do file every time I want to run an RFNoC Modelsim simulation.
What is the specific reason why I cannot have the script load up my own wave.do
file, and how can we get around this? I would be glad to contact Xilinx or
Modelsim if you don't have the time.
Thanks,
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151119/fcb72675/attachment-0001.html>
------------------------------
Message: 26
Date: Thu, 19 Nov 2015 10:16:27 -0500
From: Rob Kossler <rkoss...@nd.edu>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: Andrew Wells <awe...@trellisware.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID:
<cab__httraujan+sv98gw+bbvjapag9sv2j15zdacw0yfmmq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
Regarding the Unix-style FIFO, it is my understanding that such a FIFO does
not actually buffer any data. My understanding is that such a FIFO just
provides a "connection" between the producer and consumer by way of a
file. I think that the consumer will still need to keep up at the
instantaneous streaming rates (rather than the average streaming rates).
If true, then I don't think this helps the issue. Is my understanding
wrong? I recall that we had a discussion on this topic several months ago
Rob
On Thu, Nov 19, 2015 at 5:31 AM, Marcus M?ller <usrp-users@lists.ettus.com>
wrote:
> Hi Andrew,
> I must admit that I've had long discussions about that and we never came
> quite to a conclusion, but:
> of course you can optimize your system for write performance. Make the
> file system buffers large, don't use a journalling file system, make sure
> GNU Radio is the only one acquiring attention from that disk to make things
> work more "averagely" on the data sink side of things.
> I usually refer people to [1] for tweaking of their file system behavior.
> What I like about that answer is that the author stresses the fact that
> you're trading safety for speed if you're buffering much of your samples in
> RAM.
>
> Another approach that many people find helpful is:
> 1. Making a Unix-style FIFO, e.g. mkfifo /arbitrary/path/fifo
> 2. start writing the contents of that FIFO to the storage (this will block
> until there actually is data), ie. cat /arbitrary/path/fifo >
> /media/ssd/samples.dat (or even "dd if=/arbitrary/path/fifo
> of=/media/ssd/samples.dat bs=<block size in Bytes>", if you want to control
> the write chunk sizes. Try with just cat first.)
> 3. use the file sink with the /arbitrary/path/fifo
>
> Cheers,
> Marcus
>
> [1] http://unix.stackexchange.com/a/41831/106650
>
>
>
> On 19.11.2015 02:25, Andrew Wells wrote:
>
> I tried the raw write test in GNU Radio using the probe rate block and
> found that the data was being written the disk relatively consistently at
> 50 MS/s, but has occasional drops below that rate. This is consistent with
> the overflow we are seeing when collecting data from the USRP. Setting up a
> RAM disc is not a great option for us because we only have 12 GB of ram and
> are looking to run for longer than a minute at a time. Are there any Linux
> specific things we can do stabilize the SSD write rate or prioritize writes
> from GNU Radio?
>
>
>
> Andrew
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com
> <usrp-users-boun...@lists.ettus.com>] *On Behalf Of *Marcus M?ller via
> USRP-users
> *Sent:* Wednesday, November 18, 2015 2:47 PM
> *To:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> Hi Andrew,
>
> Writing to a vector sink should under no circumstances be slower, as that
> really takes but allocation of memory and in-RAM copies, unless you run out
> of RAM, and in fact start writing to disk inadvertedly, by swapping RAM to
> disk.
> However, to fill 10GB (=10*2**30 B, assuming you need 2GB RAM for the rest
> of your system) you'd need quite some samples ie. 10*2^30 B / (4B/S)
> Samples for short complex, or half of that for float complex. That would,
> at 50MS/s, amount to about 53s or 26s, respectively.
> How long is your capture?
>
> Regarding your SSD:
> if you have that installed, run gnome-disks, and have a bit of fun with
> different block sizes; here's two plots for different write block sizes
> (1MB and 1000MB).
> So, if it is really like your SSD is the bottleneck, we can expect the
> work function of that to always find a full buffer, which typically is
> 32KB. If unbuffered is on, that's the granularity with which you ask your
> file system to write stuff away.
>
> If you want to have a raw write test in GNU Radio, connect a constant
> source to "probe rate" block and a file sink.
> If you want much more in-depth analysis of who spends how much time in
> which block: compile GNU Radio with controlport enabled and add at ctrlport
> monitor to your flow graph.
>
> Best regards,
> Marcus
>
> On 18.11.2015 22:55, Andrew Wells via USRP-users wrote:
>
> Thanks! The ?Realtime Scheduling? option allowed us to output to a null
> sync at 50 MS/s, but we are still having issues writing to a file at that
> speed. Outputting to a vector sync seems to be worse than writing to a
> file. Any ideas on how to increase the file write speed?
>
>
>
> System Specs:
>
> RAM: 12 GB
>
> Processor: i7-6500u @ 2.5 GHz
>
> OS: Ubuntu 15.10
>
> SSD: Micron M600 MTFDDAK512MBF (510 MB/s write speed)
>
>
>
>
>
> Andrew
>
>
>
> *From:* James Humphries [mailto:james.humphr...@ettus.com
> <james.humphr...@ettus.com>]
> *Sent:* Wednesday, November 18, 2015 1:34 PM
> *To:* Andrew Wells
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> You may want to try using a tool to set the CPU to maximum performance. I
> use 'indicator-cpufreq'. Make sure there are no power settings that may
> limit CPU. What are you system specs (cpu, ram, etc)?
>
>
>
> You can also try to set 'Realtime Scheduling' in the options block of your
> flowgraph to see if that helps.
>
>
>
> -Trip
>
>
>
> On Wed, Nov 18, 2015 at 4:25 PM, Andrew Wells via USRP-users <
> <usrp-users@lists.ettus.com>usrp-users@lists.ettus.com> wrote:
>
> I tried using a vector sink and reducing the USRP output data to complex
> int16 and the overflow persisted. Even using a null sync still had
> overflow. I have an SSD that is supposed to be able to write at 460 MB/s,
> so that should not be an issue for the file sync. Anything else I can try?
> I?ve experienced this issue on two different machines.
>
>
>
> Andrew
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf
> Of *Marcus M?ller via USRP-users
> *Sent:* Wednesday, November 18, 2015 11:24 AM
> *To:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> Try replacing the file sink by e.g. a vector sink. Usually, hard drives
> are much slower at writing than people expect; keeping up with a rate of
> 30MS/s of complex floats means that your hard drive needs to _sustain_ a
> 30MS/s*2float/s*4B/float = 240MB/s
> write rate. That's too much even for many SSDs.
>
> Notice that USB3 performance really depends on a lot of factors, but this
> is the "easiest to diagnose" and "easiest to remedy" one; buffering in RAM
> disk can often solve the problem (and that's exactly what vector_sink does).
>
>
> Best regards,
> Marcus
>
> On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
>
> Hello,
>
>
>
> I have a simple flowqraph in GNU Radio Companion, which is just a USRP
> source connected to a File Sink. I?m using a USRP B200 connected by USB
> 3.0 to an Intel USB controller. Based on the chart found at
>
>
>
>
> <http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
>
>
> I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
> overflow (O?s in the console) at sampling rates as low as 30 MS/s. A
> sampling rate of 50 MS/s is critical for my intended application. Are there
> other parts of the system that may be limiting the sample rate or other
> ways to increase it without overflow?
>
>
>
> Thanks,
>
> Andrew Wells
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users@lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users@lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151119/eaa60191/attachment-0001.html>
------------------------------
Message: 27
Date: Thu, 19 Nov 2015 10:22:32 -0500
From: mle...@ripnet.com
To: Rob Kossler <rkoss...@nd.edu>
Cc: Marcus M?ller <marcus.muel...@ettus.com>,
usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Buffer Overflow
Message-ID: <653cccfff289d03527d4338f32d92...@ripnet.com>
Content-Type: text/plain; charset="utf-8"
FIFOs are implemented as ring-buffers in kernel memory. They aren't
huge, but they are buffers. In the very early days of "named pipes"
(what FIFOs were originally called), the ring buffer was managed on
disk, but in Linux, it's a RAM-resident ring buffer.
On 2015-11-19 10:16, Rob Kossler via USRP-users wrote:
> Marcus,
> Regarding the Unix-style FIFO, it is my understanding that such a FIFO does
> not actually buffer any data. My understanding is that such a FIFO just
> provides a "connection" between the producer and consumer by way of a file. I
> think that the consumer will still need to keep up at the instantaneous
> streaming rates (rather than the average streaming rates). If true, then I
> don't think this helps the issue. Is my understanding wrong? I recall that we
> had a discussion on this topic several months ago
>
> Rob
>
> On Thu, Nov 19, 2015 at 5:31 AM, Marcus M?ller <usrp-users@lists.ettus.com>
> wrote:
>
> Hi Andrew,
> I must admit that I've had long discussions about that and we never came
> quite to a conclusion, but:
> of course you can optimize your system for write performance. Make the file
> system buffers large, don't use a journalling file system, make sure GNU
> Radio is the only one acquiring attention from that disk to make things work
> more "averagely" on the data sink side of things.
> I usually refer people to [1] for tweaking of their file system behavior.
> What I like about that answer is that the author stresses the fact that
> you're trading safety for speed if you're buffering much of your samples in
> RAM.
>
> Another approach that many people find helpful is:
> 1. Making a Unix-style FIFO, e.g. mkfifo /arbitrary/path/fifo
> 2. start writing the contents of that FIFO to the storage (this will block
> until there actually is data), ie. cat /arbitrary/path/fifo >
> /media/ssd/samples.dat (or even "dd if=/arbitrary/path/fifo
> of=/media/ssd/samples.dat bs=<block size in Bytes>", if you want to control
> the write chunk sizes. Try with just cat first.)
> 3. use the file sink with the /arbitrary/path/fifo
>
> Cheers,
> Marcus
>
> [1] http://unix.stackexchange.com/a/41831/106650 [2]
>
> On 19.11.2015 02:25, Andrew Wells wrote:
>
> I tried the raw write test in GNU Radio using the probe rate block and found
> that the data was being written the disk relatively consistently at 50 MS/s,
> but has occasional drops below that rate. This is consistent with the
> overflow we are seeing when collecting data from the USRP. Setting up a RAM
> disc is not a great option for us because we only have 12 GB of ram and are
> looking to run for longer than a minute at a time. Are there any Linux
> specific things we can do stabilize the SSD write rate or prioritize writes
> from GNU Radio?
>
> Andrew
>
> FROM: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] ON BEHALF OF
> Marcus M?ller via USRP-users
> SENT: Wednesday, November 18, 2015 2:47 PM
> TO: usrp-users@lists.ettus.com
> SUBJECT: Re: [USRP-users] USRP Buffer Overflow
>
> Hi Andrew,
>
> Writing to a vector sink should under no circumstances be slower, as that
> really takes but allocation of memory and in-RAM copies, unless you run out
> of RAM, and in fact start writing to disk inadvertedly, by swapping RAM to
> disk.
> However, to fill 10GB (=10*2**30 B, assuming you need 2GB RAM for the rest of
> your system) you'd need quite some samples ie. 10*2^30 B / (4B/S) Samples for
> short complex, or half of that for float complex. That would, at 50MS/s,
> amount to about 53s or 26s, respectively.
> How long is your capture?
>
> Regarding your SSD:
> if you have that installed, run gnome-disks, and have a bit of fun with
> different block sizes; here's two plots for different write block sizes (1MB
> and 1000MB).
> So, if it is really like your SSD is the bottleneck, we can expect the work
> function of that to always find a full buffer, which typically is 32KB. If
> unbuffered is on, that's the granularity with which you ask your file system
> to write stuff away.
>
> If you want to have a raw write test in GNU Radio, connect a constant source
> to "probe rate" block and a file sink.
> If you want much more in-depth analysis of who spends how much time in which
> block: compile GNU Radio with controlport enabled and add at ctrlport monitor
> to your flow graph.
>
> Best regards,
> Marcus
>
> On 18.11.2015 22:55, Andrew Wells via USRP-users wrote:
>
> Thanks! The 'Realtime Scheduling' option allowed us to output to a null sync
> at 50 MS/s, but we are still having issues writing to a file at that speed.
> Outputting to a vector sync seems to be worse than writing to a file. Any
> ideas on how to increase the file write speed?
>
> System Specs:
>
> RAM: 12 GB
>
> Processor: i7-6500u @ 2.5 GHz
>
> OS: Ubuntu 15.10
>
> SSD: Micron M600 MTFDDAK512MBF (510 MB/s write speed)
>
> Andrew
>
> FROM: James Humphries [mailto:james.humphr...@ettus.com]
> SENT: Wednesday, November 18, 2015 1:34 PM
> TO: Andrew Wells
> CC: usrp-users@lists.ettus.com
> SUBJECT: Re: [USRP-users] USRP Buffer Overflow
>
> You may want to try using a tool to set the CPU to maximum performance. I use
> 'indicator-cpufreq'. Make sure there are no power settings that may limit
> CPU. What are you system specs (cpu, ram, etc)?
>
> You can also try to set 'Realtime Scheduling' in the options block of your
> flowgraph to see if that helps.
>
> -Trip
>
> On Wed, Nov 18, 2015 at 4:25 PM, Andrew Wells via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> I tried using a vector sink and reducing the USRP output data to complex
> int16 and the overflow persisted. Even using a null sync still had overflow.
> I have an SSD that is supposed to be able to write at 460 MB/s, so that
> should not be an issue for the file sync. Anything else I can try? I've
> experienced this issue on two different machines.
>
> Andrew
>
> FROM: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] ON BEHALF OF
> Marcus M?ller via USRP-users
> SENT: Wednesday, November 18, 2015 11:24 AM
> TO: usrp-users@lists.ettus.com
> SUBJECT: Re: [USRP-users] USRP Buffer Overflow
>
> Try replacing the file sink by e.g. a vector sink. Usually, hard drives are
> much slower at writing than people expect; keeping up with a rate of 30MS/s
> of complex floats means that your hard drive needs to _sustain_ a
> 30MS/s*2float/s*4B/float = 240MB/s
> write rate. That's too much even for many SSDs.
>
> Notice that USB3 performance really depends on a lot of factors, but this is
> the "easiest to diagnose" and "easiest to remedy" one; buffering in RAM disk
> can often solve the problem (and that's exactly what vector_sink does).
>
> Best regards,
> Marcus
>
> On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
>
> Hello,
>
> I have a simple flowqraph in GNU Radio Companion, which is just a USRP source
> connected to a File Sink. I'm using a USRP B200 connected by USB 3.0 to an
> Intel USB controller. Based on the chart found at
>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
> [3]
>
> I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
> overflow (O's in the console) at sampling rates as low as 30 MS/s. A sampling
> rate of 50 MS/s is critical for my intended application. Are there other
> parts of the system that may be limiting the sample rate or other ways to
> increase it without overflow?
>
> Thanks,
>
> Andrew Wells
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users@lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users@lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[2] http://unix.stackexchange.com/a/41831/106650
[3]
http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151119/6ce09f46/attachment-0001.html>
------------------------------
Message: 28
Date: Thu, 19 Nov 2015 16:59:54 +0100
From: Carlos Canet <ccanet1...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Unknown UHD device type, running ./osmo-trx
-f -> USRP E310
Message-ID:
<cajuoqyhdjsldmuc2kfby7du9v0c4jqd5udz0pbuthlj+29b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi!
I added the next log(alert) to see what was exactly my device type:
LOG(ALERT) << "Unknown UHD device type " << mboard_str;
mboard_str printed *E3XX* so then I had to change:
e310_str = mboard_str.find("*E310*"); to e310_str = mboard_str.find("*E3XX*"
);
Issue solved!
Best regards,
Carlos
2015-11-16 19:41 GMT+01:00 Carlos Canet <ccanet1...@gmail.com>:
> Hi everyone,
>
> Following the guide (http://openbts.org/w/index.php/E3x0) to run openBTS
> on a USRP E310. I try running ./osmo-trx -f unssuccesfully.
>
> *The error I get is the following:* ->
> http://pastebin.com/raw.php?i=53QEteFa
>
> ALERT 3069337600 09:56:33.8 UHDDevice.cpp:682:parse_dev_type: Unknown UHD
> device type E-Series Device
> ALERT 3069337600 09:56:33.8 UHDDevice.cpp:682:parse_dev_type: Unknown UHD
> device type E-Series Device
>
> ALERT 3069337600 09:56:33.8 osmo-trx.cpp:412:main: Failed to create radio
> device
> ALERT 3069337600 09:56:33.8 osmo-trx.cpp:412:main: Failed to create radio
> device
> Shutting down transceiver...
>
> I've been looking in UHDDevice.cpp (
> https://github.com/osmocom/osmo-trx/blob/master/Transceiver52M/UHDDevice.cpp).
> When compares e300_str with std::string::npos(line 669) results that
> matches with constant npos (probably -1), therefore goes down to the
> log(ALERT)-> Unknown UHD device type E-Series Device. I guess that means
> that mboard_str fails picking the name.
>
> mboard_str = usrp_dev->get_mboard_name();
> e310_str = mboard_str.find("E310");
>
>
> Maybe #define E3XX_CLK_RT and #define E3XX_BASE_RT have to be included in
> UHDDevice.cpp? If it's necessary, I'm not sure which values I should put.
> Also line 200 case E3XX should return E3XX_BASE_RT * sps; ?
> Any help would be appreciated.
>
> Thanks in advance!
>
> Regards,
>
> Carlos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151119/5d328092/attachment-0001.html>
------------------------------
Message: 29
Date: Thu, 19 Nov 2015 11:10:07 -0500
From: James Humphries <james.humphr...@ettus.com>
To: ?? <bighead13...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] niusrprio_pcie failed to start
Message-ID:
<caewgfhvujwhc3acg7hkbusfhlmesvcrzrtmqx29ogeuqxgw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jeff,
Thanks for the info, that kernel should be ok. Just to confirm, you are
running on a 64-bit system?
Can you try and reinstall the drivers? You will need to uninstall the NI
drivers first. If you can, make sure your system is up to date before you
reinstall with:
sudo apt-get update && sudo apt-get upgrade
-Trip
On Wed, Nov 18, 2015 at 10:27 PM, ?? <bighead13...@gmail.com> wrote:
> Hi Trip,
>
> # uname -r
> 3.19.0-33-generic
>
> According to http://files.ettus.com/manual/page_ni_rio_kernel.html, I
> think it works. Am I right?
>
> I do sudo /usr/local/bin/updateNIDrivers --no-prompt many many times and
> reboot, still the same problem.
>
> Jeff
>
>
> 2015-11-19 11:07 GMT+08:00 James Humphries <james.humphr...@ettus.com>:
>
>> Hi Jeff,
>>
>> What kernel are you running with your installation? The following command
>> should tell you:
>>
>> uname -r
>>
>> -Trip
>>
>> On Wed, Nov 18, 2015 at 8:03 PM, ?? via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello every,
>>>
>>> I'm using Ubuntu 14.04.3 with UHD 003.010.git-87-g88b0baea. I trying to
>>> install niusrprio-installer 15.0.0 to connect X310 with MXI-Express. I
>>> follow this instruction :
>>> http://files.ettus.com/manual/page_ni_rio_kernel.html I also run sudo
>>> /usr/local/bin/updateNIDrivers --no-prompt to rebuild the kernel modules
>>> for the currently running kernel and reboot.
>>>
>>> Herer is start the service comes problem :
>>> # sudo /usr/local/bin/niusrprio_pcie start
>>> Loading: NiRioSrv modprobe: ERROR: could not insert 'NiRioSrv': Invalid
>>> argument
>>> niusrpriok modprobe: ERROR: could not insert 'niusrpriok': Invalid
>>> argument
>>>
>>> Starting: niusrpriorpc
>>>
>>> I using dmesg and find out this
>>> [ 122.326245] nibds: no symbol version for
>>> nNIKAL100_getTimeOfDayInterval
>>> [ 122.326255] nibds: Unknown symbol nNIKAL100_getTimeOfDayInterval (err
>>> -22)
>>> [ 122.326263] nibds: no symbol version for nNIKAL100_createSpinLock
>>> [ 122.326267] nibds: Unknown symbol nNIKAL100_createSpinLock (err -22)
>>> [ 122.326274] nibds: no symbol version for nNIKAL150_createMutex
>>> [ 122.326277] nibds: Unknown symbol nNIKAL150_createMutex (err -22)
>>> [ 122.326283] nibds: no symbol version for nNIKAL100_destroySpinLock
>>> [ 122.326287] nibds: Unknown symbol nNIKAL100_destroySpinLock (err -22)
>>> [ 122.326293] nibds: no symbol version for nNIKAL200_joinThread
>>> [ 122.326296] nibds: Unknown symbol nNIKAL200_joinThread (err -22)
>>> [ 122.326303] nibds: no symbol version for
>>> nNIKAL100_releaseSingleUseEvent
>>> [ 122.326306] nibds: Unknown symbol nNIKAL100_releaseSingleUseEvent
>>> (err -22)
>>> ...
>>> ...
>>> ....
>>>
>>> How to fixed it ?
>>>
>>> Thanks
>>>
>>> Jeff Guo
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151119/0e0179de/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 63, Issue 19
******************************************
