Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: monitor with E310/312 (liu Jong)
2. Re: USRP B210 Overflow (Piotr Krysik)
3. USRP-B200mini connect to Android Pad (=?gb18030?B?4+XH5Q==?=)
4. UHD FW for NI USRP 2943R (Sanat Kumar Mishra)
5. Re: USRP B210 Overflow (Piotr Krysik)
6. Re: UHD FW for NI USRP 2943R ([email protected])
7. Re: USRP-B200mini connect to Android Pad (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Mon, 4 Jul 2016 11:40:50 +0800
From: liu Jong <[email protected]>
To: john liu <[email protected]>
Cc: Philip Balister <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] monitor with E310/312
Message-ID:
<CAEui2n0mUxTMisc0T27_Y=hqhvuzjfrhskwpfjalunmfpxe...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
we used a USB TO VGA adapter connected E310 to a dell E190S monitor,but
nothing appeared.
the E310 images is sdimage-gnuradio-demo.direct.xz.
need we do something special?
best regards
Jon
2016-04-11 9:07 GMT+08:00 john liu via USRP-users <
[email protected]>:
> Hi ,Philip
> Thank you for your help.
> Best regards
> John
>
> On Sat, Apr 9, 2016 at 12:37 AM, Philip Balister <[email protected]>
> wrote:
>
>> On 04/08/2016 01:29 AM, john liu via USRP-users wrote:
>> > Dear all,
>> > Can we use E312/E312 with a LCD monitor?The interface is USB or
>> > others?And where can we find the hard driver?
>> > thank you for your reply.
>> > best regards
>>
>> gnuradio-demo-image works with this panel:
>>
>> https://www.mimomonitors.com/products/mimo-um-760r-7-display
>>
>> The driver is the udlfb driver.
>>
>> Philip
>>
>> > John
>> >
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected]
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160704/5151236e/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 4 Jul 2016 14:45:52 +0200
From: Piotr Krysik <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>
>> Hi Xuesong,
>>
>> I was just told I misread your email. I'd like to apologize for that!
>>
>>> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
>>> streaming data to a file even with sampling rate of 5 MHz:
>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>> --wirefmt=sc16 --duration=600
>> Ooops, you're doing 5MS/s here.
>> Ok, that's only 20MB/s, and now everything is comparable to the N210
>> case.
>> This is actually not typical; let's do a quick benchmark with dd:
>>
>> yes | dd of=/home/marcus/Desktop/test.bin bs=512 count=$((4*600 * 5 * 10**6
>> / 512)) conv=fsync
>>
>> to try and write data in roughly the same granularity as
>> rx_samples_to_file does by default for a B210 connected using USB3
>> with the same amount of data.
>>
>> Could you also copy&paste the full output of rx_samples_to_file? That
>> could be very helpful.
>>
>> I'm still pretty sure the problem is storage here ? my suspicion is
>> that the write buffer of your operating system fills up with the 12GB
>> of data coming in from the USRP, and then suddenly, the OS has to
>> start throttling the USRP, because it can't write data to the SSD
>> fast enough - possibly partly because filesystem access is everything
>> but CPU-free.
>>
>> Are you planning on using GNU Radio? If you want to do that anyway,
>> something like:
>>
>> UHD USRP Source ---> File Sink
>>
>> would probably work better than the rx_samples_to_file example,
>> because GNU Radio is inherently multi-threaded. If you're using the
>> GNU Radio companion, the USRP Source block has an "advanced options"
>> tab, where you can set a larger minimum output buffer; try something
>> like 10**7, which will give you a couple Megabytes of buffering
>> already, which might already compensate for the non-uniform write
>> speeds of a storage device.
>>
>> Best regards,
>> Marcus
>>
>> On 17.06.2016 17:34, Marcus M?ller wrote:
>>> Hi Xuesong,
>>>
>>> On 06/17/2016 03:20 PM, illuantision via USRP-users wrote:
>>>> Hi all,
>>>>
>>>> If anyone of you encountered the overflow problem when streaming
>>>> data into a file using USRP B210 through USB 3.0?
>>> Yes. Storage devices are usually slower at consuming data than the
>>> B210 is at producing them.
>>> Furthermore, not all USB3 host controller chipsets can deal with the
>>> full rate coming from a USRP. They simply throttle, drop packets or
>>> crash.
>>>>
>>>> The situation is that:
>>>>
>>>> 1) Everything works fine without overruns in benchmark rate test:
>>>> ./benchmark_rate --rx_rate=50e6 --otw=sc16
>>> Excellent! Your USB3 works fine at these rates.
>>>>
>>>> 2) Everything works fine without overruns in rx_samples_to_file
>>>> test: ./rx_samples_to_file --file=/dev/null --rate=50e6
>>>> --wirefmt=sc16 --duration=600
>>> The same as above.
>>>>
>>>> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
>>>> streaming data to a file even with sampling rate of 5 MHz:
>>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>>> --wirefmt=sc16 --duration=600
>>> This is 50MS/s * 4B/S = 200MB/s = 1600Mb/s of data, to a total of
>>> 120GB. Not even most SSDs are up to that write speed over that much
>>> data, which definitely exceeds typical file system RAM buffers.
>>>
>>> If you really need to store 120GB of recorded spectrum at once,
>>> you'll either need a lot of RAM to first write this into a RAMdisk,
>>> or you'll need a really really capable storage subsystem ? PCIe
>>> SSDs, or impressive RAIDs of cheaper SSDs might work. Also, you'll
>>> want to optimize your filesystem for continued streaming
>>> (journalling file systems make no sense here, huge buffers do), and
>>> you'll probably want something else than our rx_samples_to_file
>>> example: it's not really multithreaded, and does no internal write
>>> buffering.
>>>>
>>>> The throughput of the Samsung mSATA SSD disk we are using is more
>>>> than 500 MBps,
>>> Which is too little by more than a factor of 3
>>>> and it works fine with N210.
>>> Which can't do more than 25MS/s @SC16
>>>> I am quite sure this problem is not the fault of CPU, memory, SSD
>>>> disk or USB 3.0. It seems that something happens when they work
>>>> together with B210.
>>> Pretty sure this is your SSD.
>>>>
>>>> I also found previous reports about the same problem in the 2014
>>>> March usurp mail list here:
>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-March/008894.html;
>>>> and in the Github issues here:
>>>> https://github.com/EttusResearch/uhd/issues/58.
>>>>
>>>> Streaming data into files is a basic application of USRP. Hope some
>>>> of you could provide with solutions for this problem.
>>> I'm afraid all I can tell you is:
>>>
>>> * faster storage
>>> * using a multi-threaded, buffering program instead of the
>>> rx_samples_to_file example (it's /really/ just an example of how to
>>> use UHD to receive files, not a throughput-optimized application)
>>>
>>> Best regards,
>>> Marcus
>>
>>
> Also try increasing num_recv_frames in the device argument--up to 128
> or so.
>
> The "dynamics" of general-purpose operating systems are subtle, and
> often not immediately intuitive. Just because you can stream at
> one rate from a particular type of streaming device (a 1GiGe N210),
> does not mean that the same rates are sustainable from a different
> type of device that uses USB3. The operating-system resources
> consumed by the underlying hardware are different, the buffering is
> different, and the dynamic behavior is different.
>
> The B210 is perfectly happy to be a "Niagara Falls" of sample data,
> but the size of the "bucket" you hold under it is a attribute of your
> underlying operating system software and hardware dynamics.
>
> Also, rx_samples_to_file is an example, and as an example, it strives
> to be as simple as possible. Which means that it's single threaded,
> and has no "hooks" to optimize for system specifics.
>
>
Hi Xuesong,
There is a genuine problem with streaming from B210 to a disk. No amount
of computer resources, optimizations and trying different streaming
applications solved the problem for me (rx_sample_to_file is just an
example provided with the driver so it might not be the best application).
For all others who are trying to help - if you can stream from B210 to a
disk on your side at the sample rate of at least 10MHz (single channel,
16bit) and save about 10 minutes of such stream to disk without an
overflow - please share:
-what is a configuration of a computer on which you achieved that
(motherboard, processor, memory, disk),
-what application did you use.
Until someone proves otherwise (at sample rates >=10MSamp/s), it is
officially not possible to stream from USRP B210 to a disk without
transmission problems.
Best Regards,
Piotr Krysik
------------------------------
Message: 3
Date: Mon, 4 Jul 2016 17:58:18 +0800
From: "=?gb18030?B?4+XH5Q==?=" <[email protected]>
To: "=?gb18030?B?dXNycC11c2Vycw==?=" <[email protected]>
Subject: [USRP-users] USRP-B200mini connect to Android Pad
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gb18030"
Hello, Sir and Madam,
My company bought USRP-B200mini, now we want to connect it to
Android Pad.
We have some questions:
1.how to drive usb between USRP-B200mini and android Pad?
2.should we use opensource "libusb" at site http://libusb.info/?
which version? because we saw version libusb0.1,version libusb1.0...and so
on.
3.how to run the ettus program on Android? how to configure Android
environment?
should we compile boost in windows or linux?
Thank you very much,Look forward to your reply.
Sincerely.
Ye
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160704/4202762e/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 04 Jul 2016 15:50:07 +0200
From: Sanat Kumar Mishra <[email protected]>
To: [email protected]
Subject: [USRP-users] UHD FW for NI USRP 2943R
Message-ID:
<20160704155007.horde.nu3038eeicg4vzeicqts...@webmail.uni-paderborn.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Hi,
I just received the NI USRP-2943R device. It has built-in LabView FW
and FPGA images. In NI forum, I read that in order to establish
communication between the USRP and GNUradio, the latest UHD FW and
FPGA images needs to be flashed into the USRP. I downloaded the latest
UHD which is USRP Hardware Driver 003.009.004. Using NI USRP
configuration Utility tool I was able to flash the UHD FPGA image
usrp_x310_fpga_HGS.lvbitx into the USRP. Iam using windows 7 - 64 bit
for my GNUradio application.
After doing this, the GNUradio application gives FW error.
My question is what is the right verion of FW that is compatibale with
the NI-USRP 2943R and which tool to use to load it ?
Best Regards,
Sanat
------------------------------
Message: 5
Date: Mon, 4 Jul 2016 16:33:08 +0200
From: Piotr Krysik <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
W dniu 04.07.2016 o 14:45, Piotr Krysik via USRP-users pisze:
> W dniu 17.06.2016 o 19:28, Marcus D. Leech via USRP-users pisze:
>> On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>>> Hi Xuesong,
>>>
>>> I was just told I misread your email. I'd like to apologize for that!
>>>
>>>> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
>>>> streaming data to a file even with sampling rate of 5 MHz:
>>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>>> --wirefmt=sc16 --duration=600
>>> Ooops, you're doing 5MS/s here.
>>> Ok, that's only 20MB/s, and now everything is comparable to the N210
>>> case.
>>> This is actually not typical; let's do a quick benchmark with dd:
>>>
>>> yes | dd of=/home/marcus/Desktop/test.bin bs=512 count=$((4*600 * 5 * 10**6
>>> / 512)) conv=fsync
>>>
>>> to try and write data in roughly the same granularity as
>>> rx_samples_to_file does by default for a B210 connected using USB3
>>> with the same amount of data.
>>>
>>> Could you also copy&paste the full output of rx_samples_to_file? That
>>> could be very helpful.
>>>
>>> I'm still pretty sure the problem is storage here ? my suspicion is
>>> that the write buffer of your operating system fills up with the 12GB
>>> of data coming in from the USRP, and then suddenly, the OS has to
>>> start throttling the USRP, because it can't write data to the SSD
>>> fast enough - possibly partly because filesystem access is everything
>>> but CPU-free.
>>>
>>> Are you planning on using GNU Radio? If you want to do that anyway,
>>> something like:
>>>
>>> UHD USRP Source ---> File Sink
>>>
>>> would probably work better than the rx_samples_to_file example,
>>> because GNU Radio is inherently multi-threaded. If you're using the
>>> GNU Radio companion, the USRP Source block has an "advanced options"
>>> tab, where you can set a larger minimum output buffer; try something
>>> like 10**7, which will give you a couple Megabytes of buffering
>>> already, which might already compensate for the non-uniform write
>>> speeds of a storage device.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>> Also try increasing num_recv_frames in the device argument--up to 128
>> or so.
>>
> Hi Xuesong,
>
> There is a genuine problem with streaming from B210 to a disk. No amount
> of computer resources, optimizations and trying different streaming
> applications solved the problem for me (rx_sample_to_file is just an
> example provided with the driver so it might not be the best application).
>
> For all others who are trying to help - if you can stream from B210 to a
> disk on your side at the sample rate of at least 10MHz (single channel,
> 16bit) and save about 10 minutes of such stream to disk without an
> overflow - please share:
> -what is a configuration of a computer on which you achieved that
> (motherboard, processor, memory, disk),
> -what application did you use.
>
> Until someone proves otherwise (at sample rates >=10MSamp/s), it is
> officially not possible to stream from USRP B210 to a disk without
> transmission problems.
>
>
Hi all again,
One little tip: streaming to a ramdisk works without problems with
overflows. If I need to make a short recording (single minutes as amount
of RAM is usually quite limited) with USRP B210 I'm using a ramdisc
created with command like this:
sudo mount -t tmpfs -o size=10000m tmpfs /path/to/ramdisc/directory
where 10000m is size of the ramdisc in mega-bytes.
Streaming to a real disc from B210 doesn't work without problems - until
someone figures out what is the problem/bottleneck.
Best Regards,
Piotr Krysik
------------------------------
Message: 6
Date: Mon, 04 Jul 2016 10:37:40 -0400
From: [email protected]
To: Sanat Kumar Mishra <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD FW for NI USRP 2943R
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Could you perhaps share with us the exact error message you received?
On 2016-07-04 09:50, Sanat Kumar Mishra via USRP-users wrote:
> Hi,
>
> I just received the NI USRP-2943R device. It has built-in LabView FW and
> FPGA images. In NI forum, I read that in order to establish communication
> between the USRP and GNUradio, the latest UHD FW and FPGA images needs to be
> flashed into the USRP. I downloaded the latest UHD which is USRP Hardware
> Driver 003.009.004. Using NI USRP configuration Utility tool I was able to
> flash the UHD FPGA image usrp_x310_fpga_HGS.lvbitx into the USRP. Iam using
> windows 7 - 64 bit for my GNUradio application.
>
> After doing this, the GNUradio application gives FW error.
>
> My question is what is the right verion of FW that is compatibale with the
> NI-USRP 2943R and which tool to use to load it ?
>
> Best Regards,
> Sanat
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160704/de81aefc/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 4 Jul 2016 17:53:17 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP-B200mini connect to Android Pad
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear Ye,
it's known that UHD, the USRP drivers, do cross-compile for Android.
However, having the raw drivers work on Android won't help you - there's
nothing you can do with them unless you have some applications that you
can start on your Android tablet that make use of it. Tom Rondeau and
others made it possible to run GNU Radio and a few GUI examples on
Android devices, including communication with UHD. So I'd recommend
following what advice is available on [1].
Generally, it might be helpful if you could explain what kind of Android
application you have in mind ? maybe it'll be easier to point you in the
right direction.
> 1.how to drive usb between USRP-B200mini and android Pad?
UHD, our driver, simply needs the USB interface's raw bulk packets as
libusb offers them. The rest of this question is very Android-dev
specific, which I'm no expert of at all.
> 2.should we use opensource "libusb" at site http://libusb.info/?
> which version? because we saw version
> libusb0.1,version libusb1.0...and so on.
Probably: The latest one that runs on your device.
> 3.how to run the ettus program on Android? how to configure Android
> environment?
> should we compile boost in windows or linux?
These questions aren't USRP-related, to be honest; I'm afraid there's
little expertise in developing Android applications on this list :(
Maybe someone else sees this and can chime in, but I guess the answer
is: You'll need to be quite experienced in developing embedded software
and Android applications to write something sensible for an Android
platform. That's why I recommend going through [1], as it illustrates
what needs to be done to bring both UHD and a complex software that uses
it to the Android platform.
Best regards,
Marcus
[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Android
On 07/04/2016 11:58 AM, ?? via USRP-users wrote:
> Hello, Sir and Madam,
>
> My company bought USRP-B200mini, now we want to connect it to
>
> Android Pad.
>
> We have some questions:
>
> 1.how to drive usb between USRP-B200mini and android Pad?
>
> 2.should we use opensource "libusb" at site http://libusb.info/?
> which version? because we saw version
> libusb0.1,version libusb1.0...and so on.
>
> 3.how to run the ettus program on Android? how to configure Android
> environment?
> should we compile boost in windows or linux?
>
>
> Thank you very much,Look forward to your reply.
>
> Sincerely.
>
> Ye
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160704/2ff637fe/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 71, Issue 3
*****************************************
