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: USRP B210 Overflow (Jeremy Hershberger)
2. Re: USRP B210 Overflow (Marcus M?ller)
3. Re: UHD FW for NI USRP 2943R (Sanat Kumar Mishra)
4. Re: UHD FW for NI USRP 2943R ([email protected])
5. Re: UHD FW for NI USRP 2943R (Sanat Kumar Mishra)
6. Re: UHD FW for NI USRP 2943R ([email protected])
7. Re: UHD FW for NI USRP 2943R (Sanat Kumar Mishra)
8. Re: UHD FW for NI USRP 2943R ([email protected])
9. Re: UHD FW for NI USRP 2943R (Sanat Kumar Mishra)
10. Re: UHD FW for NI USRP 2943R ([email protected])
11. Create Congestion in RFNOC Simulation Model (Joshua Monson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 4 Jul 2016 16:49:10 -0400
From: Jeremy Hershberger <[email protected]>
To: Piotr Krysik <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID:
<camziklqzmi-osonkv3y4_hgdqs933_2qe+ap0p1oftxmk9g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have had success streaming from a B210 (2 channel RX, 16-bit, 25MS/s) to
a RAM disk. I have also had success writing smaller files to the RAM disk
(maybe a second or two of data) and then moving those files in a separate
background process to an SSD. By pulling data out of the RAM drive at a
rate that is slightly less than data flows in, I can capture for a longer
total duration. The performance would depend greatly on the speed at which
your host can move data from RAM to disk, but by changing the size of the
temporary files in RAM you should be able to extend your capture duration
significantly.
On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via USRP-users <
[email protected]> wrote:
> 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
>
> _______________________________________________
> 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/c04c68de/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 4 Jul 2016 23:16:47 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
I can also recommend doing two things:
1. Multi-thread your receiver, so that the thread calling recv() isn't
blocked for the duration of write()ing things to storage. Also, now
you're not inherently pushing one core to a high clock speed. The
rx_samples_to_file example is really really really just an example of
how to set up a multi_usrp object, get the rx_streamer and call recv(),
nothing to use as reference when building high-rate receivers.
2. Using something with a large buffering when writing to storage, as
storage rates and latencies are totally unpredictable.
In fact, using GNU Radio you can get both at once: Just connect your
USRP source to a file sink. GNU Radio blocks run each in their own
thread, and the output/input connection is actually a ring buffer; you
can increase the size of that in the "advanced" tab of the USRP source,
by increasing the minimum output buffer size to something relatively
large; I tend to use values 512*2**20 (==512MB) because RAM is cheap :)
If you don't want to use GNU Radio, I can dig up a rather naively
implemented multi-thread-receiver that I wrote a while ago. It worked
pretty well at high rates, and does nothing but allocate a bunch of
"samples_per_packet*bytes_per_sample" sized buffers, puts them in a
"ready to use" queue, let's a thread running recv() fill them one by
one, push them into a "ready to write" queue, from which a storage IO
thread takes them and writes their content to a file, then pushes them
back to the "ready to use" queue. The design was really bad (buffers
aren't inherently allocated contiguously in memory, so we're potentially
losing memory bandwidth unnecessarily), but using enough buffers, one
can completely hide the fact that storage is highly non-deterministic
and that handling storage IO might interfere with the amount of CPU the
OS has available for handling USB traffic.
Best regards,
Marcus
On 04.07.2016 22:49, Jeremy Hershberger via USRP-users wrote:
> I have had success streaming from a B210 (2 channel RX, 16-bit,
> 25MS/s) to a RAM disk. I have also had success writing smaller files
> to the RAM disk (maybe a second or two of data) and then moving those
> files in a separate background process to an SSD. By pulling data out
> of the RAM drive at a rate that is slightly less than data flows in, I
> can capture for a longer total duration. The performance would depend
> greatly on the speed at which your host can move data from RAM to
> disk, but by changing the size of the temporary files in RAM you
> should be able to extend your capture duration significantly.
>
> On Mon, Jul 4, 2016 at 10:33 AM, Piotr Krysik via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> 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
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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/9728904c/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 05 Jul 2016 12:48:20 +0200
From: Sanat Kumar Mishra <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD FW for NI USRP 2943R
Message-ID:
<20160705124820.horde.bj8ey_nqhfrmy5zaeuwr...@webmail.uni-paderborn.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Hello,
I am trying to run the FM receiver example (from youtube) and I get
the following errors:
"Win32; Microsoft Visual C++ version 14.0; Boost_106000;
UHD_003.009.003-0-unknown" - But I am using UHD_003.009.004.
"No such file or directory
Traceback (most recent call last):
File "C:\Users\smishra\Downloads\fm_example.py", line 162, in <module>
main()
File "C:\Users\smishra\Downloads\fm_example.py", line 156, in main
tb = top_block_cls()
File "C:\Users\smishra\Downloads\fm_example.py", line 117, in __init__
self.blocks_wavfile_sink_0 = blocks.wavfile_sink("", 1, 96000, 8)
File "C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig1.py",
line 2701, in make
return _blocks_swig1.wavfile_sink_make(filename, n_channels,
sample_rate, bits_per_sample)
RuntimeError: can't open file"
"UHD Error:
x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - operation timed out."
The PPS LED is blinking which as per the 'Getting Started Guide' means
'The device is not locked to the reference signal.'
Regards,
Sanat
Quoting [email protected]:
> 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
------------------------------
Message: 4
Date: Tue, 05 Jul 2016 10:12:32 -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"
The fact that the header indicates 003.009.003 means that you're
actually running 003.009.003, if you installed 3.9.4, it's likely in a
place outside your %PATH%.
The 'can't open file' error is coming from Gnu Radio, not UHD. My
suspicion is that it's trying to open a file that it cannot open on
Windows, or is specified wrongly. Not all of the examples are 100%
portable.
The communications error is of more concern. What type of Ethernet card
do you have on your system? What is your network setup between your
computer and the X300?
On 2016-07-05 06:48, Sanat Kumar Mishra wrote:
> Hello,
>
> I am trying to run the FM receiver example (from youtube) and I get the
> following errors:
>
> "Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.009.003-0-unknown" - But I am using UHD_003.009.004.
>
> "No such file or directory
> Traceback (most recent call last):
> File "C:\Users\smishra\Downloads\fm_example.py", line 162, in <module>
> main()
> File "C:\Users\smishra\Downloads\fm_example.py", line 156, in main
> tb = top_block_cls()
> File "C:\Users\smishra\Downloads\fm_example.py", line 117, in __init__
> self.blocks_wavfile_sink_0 = blocks.wavfile_sink("", 1, 96000, 8)
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig1.py", line
> 2701, in make
> return _blocks_swig1.wavfile_sink_make(filename, n_channels, sample_rate,
> bits_per_sample)
> RuntimeError: can't open file"
>
> "UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out."
>
> The PPS LED is blinking which as per the 'Getting Started Guide' means 'The
> device is not locked to the reference signal.'
>
> Regards,
> Sanat
>
> Quoting [email protected]:
>
> 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/20160705/dc28dd65/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 05 Jul 2016 16:37:09 +0200
From: Sanat Kumar Mishra <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD FW for NI USRP 2943R
Message-ID:
<20160705163709.horde.2186agownh6ueez9umn6...@webmail.uni-paderborn.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Hi,
@"The communications error is of more concern. What type of Ethernet
card do you have on your system? What is your network setup between
your computer and the X300?"
--- I am using NI USRP 2943-R which I found in the einternet as
X310. Therefore I flashed usrp_x310_fpga_HGS.lvbitx image to the
device. I am using PCI Express for communication using MXI Express
cable as a result I havenot set any network setup for the same.
Please guide me what to do.
Regards,
Sanat
Zitat von [email protected]:
> The fact that the header indicates 003.009.003 means that you're
> actually running 003.009.003, if you installed 3.9.4, it's likely in a
> place outside your %PATH%.
>
> The 'can't open file' error is coming from Gnu Radio, not UHD. My
> suspicion is that it's trying to open a file that it cannot open on
> Windows, or is specified wrongly. Not all of the examples are 100%
> portable.
>
> The communications error is of more concern. What type of Ethernet card
> do you have on your system? What is your network setup between your
> computer and the X300?
>
> On 2016-07-05 06:48, Sanat Kumar Mishra wrote:
>
>> Hello,
>>
>> I am trying to run the FM receiver example (from youtube) and I get
>> the following errors:
>>
>> "Win32; Microsoft Visual C++ version 14.0; Boost_106000;
>> UHD_003.009.003-0-unknown" - But I am using UHD_003.009.004.
>>
>> "No such file or directory
>> Traceback (most recent call last):
>> File "C:\Users\smishra\Downloads\fm_example.py", line 162, in <module>
>> main()
>> File "C:\Users\smishra\Downloads\fm_example.py", line 156, in main
>> tb = top_block_cls()
>> File "C:\Users\smishra\Downloads\fm_example.py", line 117, in __init__
>> self.blocks_wavfile_sink_0 = blocks.wavfile_sink("", 1, 96000, 8)
>> File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig1.py",
>> line 2701, in make
>> return _blocks_swig1.wavfile_sink_make(filename, n_channels,
>> sample_rate, bits_per_sample)
>> RuntimeError: can't open file"
>>
>> "UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw poke32 - operation timed out."
>>
>> The PPS LED is blinking which as per the 'Getting Started Guide'
>> means 'The device is not locked to the reference signal.'
>>
>> Regards,
>> Sanat
>>
>> Quoting [email protected]:
>>
>> 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
------------------------------
Message: 6
Date: Tue, 05 Jul 2016 10:41:47 -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"
What happens if you:
uhd_usrp_probe --args resource=RIO0
??
On 2016-07-05 10:37, Sanat Kumar Mishra wrote:
> Hi,
>
> @"The communications error is of more concern. What type of Ethernet card
> do you have on your system? What is your network setup between your
> computer and the X300?"
> --- I am using NI USRP 2943-R which I found in the einternet as X310.
> Therefore I flashed usrp_x310_fpga_HGS.lvbitx image to the device. I am
> using PCI Express for communication using MXI Express cable as a result I
> havenot set any network setup for the same.
> Please guide me what to do.
>
> Regards,
> Sanat
>
> Zitat von [email protected]:
>
> The fact that the header indicates 003.009.003 means that you're
> actually running 003.009.003, if you installed 3.9.4, it's likely in a
> place outside your %PATH%.
>
> The 'can't open file' error is coming from Gnu Radio, not UHD. My
> suspicion is that it's trying to open a file that it cannot open on
> Windows, or is specified wrongly. Not all of the examples are 100%
> portable.
>
> The communications error is of more concern. What type of Ethernet card
> do you have on your system? What is your network setup between your
> computer and the X300?
>
> On 2016-07-05 06:48, Sanat Kumar Mishra wrote:
>
> Hello,
>
> I am trying to run the FM receiver example (from youtube) and I get the
> following errors:
>
> "Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.009.003-0-unknown" - But I am using UHD_003.009.004.
>
> "No such file or directory
> Traceback (most recent call last):
> File "C:\Users\smishra\Downloads\fm_example.py", line 162, in <module>
> main()
> File "C:\Users\smishra\Downloads\fm_example.py", line 156, in main
> tb = top_block_cls()
> File "C:\Users\smishra\Downloads\fm_example.py", line 117, in __init__
> self.blocks_wavfile_sink_0 = blocks.wavfile_sink("", 1, 96000, 8)
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig1.py", line
> 2701, in make
> return _blocks_swig1.wavfile_sink_make(filename, n_channels, sample_rate,
> bits_per_sample)
> RuntimeError: can't open file"
>
> "UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out."
>
> The PPS LED is blinking which as per the 'Getting Started Guide' means 'The
> device is not locked to the reference signal.'
>
> Regards,
> Sanat
>
> Quoting [email protected]:
>
> 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/20160705/e83d7b8f/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 05 Jul 2016 16:44:50 +0200
From: Sanat Kumar Mishra <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD FW for NI USRP 2943R
Message-ID:
<20160705164450.horde.mr1ofl3x1yxqapszqm5_...@webmail.uni-paderborn.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Hi,
I am using Windows 7. Where shall I write this command?
Zitat von [email protected]:
> What happens if you:
>
> uhd_usrp_probe --args resource=RIO0
>
> ??
>
> On 2016-07-05 10:37, Sanat Kumar Mishra wrote:
>
>> Hi,
>>
>> @"The communications error is of more concern. What type of
>> Ethernet card do you have on your system? What is your network
>> setup between your computer and the X300?"
>> --- I am using NI USRP 2943-R which I found in the einternet as
>> X310. Therefore I flashed usrp_x310_fpga_HGS.lvbitx image to the
>> device. I am using PCI Express for communication using MXI Express
>> cable as a result I havenot set any network setup for the same.
>> Please guide me what to do.
>>
>> Regards,
>> Sanat
>>
>> Zitat von [email protected]:
>>
>> The fact that the header indicates 003.009.003 means that you're
>> actually running 003.009.003, if you installed 3.9.4, it's likely in a
>> place outside your %PATH%.
>>
>> The 'can't open file' error is coming from Gnu Radio, not UHD. My
>> suspicion is that it's trying to open a file that it cannot open on
>> Windows, or is specified wrongly. Not all of the examples are 100%
>> portable.
>>
>> The communications error is of more concern. What type of Ethernet card
>> do you have on your system? What is your network setup between your
>> computer and the X300?
>>
>> On 2016-07-05 06:48, Sanat Kumar Mishra wrote:
>>
>> Hello,
>>
>> I am trying to run the FM receiver example (from youtube) and I get
>> the following errors:
>>
>> "Win32; Microsoft Visual C++ version 14.0; Boost_106000;
>> UHD_003.009.003-0-unknown" - But I am using UHD_003.009.004.
>>
>> "No such file or directory
>> Traceback (most recent call last):
>> File "C:\Users\smishra\Downloads\fm_example.py", line 162, in <module>
>> main()
>> File "C:\Users\smishra\Downloads\fm_example.py", line 156, in main
>> tb = top_block_cls()
>> File "C:\Users\smishra\Downloads\fm_example.py", line 117, in __init__
>> self.blocks_wavfile_sink_0 = blocks.wavfile_sink("", 1, 96000, 8)
>> File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig1.py",
>> line 2701, in make
>> return _blocks_swig1.wavfile_sink_make(filename, n_channels,
>> sample_rate, bits_per_sample)
>> RuntimeError: can't open file"
>>
>> "UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw poke32 - operation timed out."
>>
>> The PPS LED is blinking which as per the 'Getting Started Guide'
>> means 'The device is not locked to the reference signal.'
>>
>> Regards,
>> Sanat
>>
>> Quoting [email protected]:
>>
>> 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
------------------------------
Message: 8
Date: Tue, 05 Jul 2016 10:46:15 -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"
open up a command window
On 2016-07-05 10:44, Sanat Kumar Mishra wrote:
> Hi,
>
> I am using Windows 7. Where shall I write this command?
>
> Zitat von [email protected]:
>
> What happens if you:
>
> uhd_usrp_probe --args resource=RIO0
>
> ??
>
> On 2016-07-05 10:37, Sanat Kumar Mishra wrote:
>
> Hi,
>
> @"The communications error is of more concern. What type of Ethernet card
> do you have on your system? What is your network setup between your
> computer and the X300?"
> --- I am using NI USRP 2943-R which I found in the einternet as X310.
> Therefore I flashed usrp_x310_fpga_HGS.lvbitx image to the device. I am
> using PCI Express for communication using MXI Express cable as a result I
> havenot set any network setup for the same.
> Please guide me what to do.
>
> Regards,
> Sanat
>
> Zitat von [email protected]:
>
> The fact that the header indicates 003.009.003 means that you're
> actually running 003.009.003, if you installed 3.9.4, it's likely in a
> place outside your %PATH%.
>
> The 'can't open file' error is coming from Gnu Radio, not UHD. My
> suspicion is that it's trying to open a file that it cannot open on
> Windows, or is specified wrongly. Not all of the examples are 100%
> portable.
>
> The communications error is of more concern. What type of Ethernet card
> do you have on your system? What is your network setup between your
> computer and the X300?
>
> On 2016-07-05 06:48, Sanat Kumar Mishra wrote:
>
> Hello,
>
> I am trying to run the FM receiver example (from youtube) and I get the
> following errors:
>
> "Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.009.003-0-unknown" - But I am using UHD_003.009.004.
>
> "No such file or directory
> Traceback (most recent call last):
> File "C:\Users\smishra\Downloads\fm_example.py", line 162, in <module>
> main()
> File "C:\Users\smishra\Downloads\fm_example.py", line 156, in main
> tb = top_block_cls()
> File "C:\Users\smishra\Downloads\fm_example.py", line 117, in __init__
> self.blocks_wavfile_sink_0 = blocks.wavfile_sink("", 1, 96000, 8)
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig1.py",
> line 2701, in make
> return _blocks_swig1.wavfile_sink_make(filename, n_channels, sample_rate,
> bits_per_sample)
> RuntimeError: can't open file"
>
> "UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out."
>
> The PPS LED is blinking which as per the 'Getting Started Guide' means
> 'The device is not locked to the reference signal.'
>
> Regards,
> Sanat
>
> Quoting [email protected]:
>
> 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/20160705/2b316d35/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 05 Jul 2016 16:58:53 +0200
From: Sanat Kumar Mishra <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD FW for NI USRP 2943R
Message-ID:
<20160705165853.horde.l66syaiyujtjegoo5p8k...@webmail.uni-paderborn.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
I have got the following results: Please note I am using NI USRP 2943R
which is like x310 from specification.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\smishra>uhd_usrp_probe --args resource=RIO0
Win32; Microsoft Visual C++ version 14.0; Boost_105800;
UHD_003.009.004-release
UHD Error:
x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - operation timed out
UHD Error:
x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - operation timed out
-- X300 initialization sequence...
-- Connecting to niusrpriorpc at localhost:5444...
-- Using LVBITX bitfile C:\Program Files
(x86)\UHD\share\uhd\images\usrp_x310_fp
ga_HGS.lvbitx...
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass
_____________________________________________________
/
| Device: X-Series Device
| _____________________________________________________
| /
| | Mboard: X310
| | revision: 8
| | revision_compat: 7
| | product: 30813
| | mac-addr0: 00:80:2f:25:18:f9
| | mac-addr1: 00:80:2f:25:18:fa
| | gateway: 192.168.10.1
| | ip-addr0: 192.168.10.2
| | subnet0: 255.255.255.0
| | ip-addr1: 192.168.20.2
| | subnet1: 255.255.255.0
| | ip-addr2: 192.168.30.2
| | subnet2: 255.255.255.0
| | ip-addr3: 192.168.40.2
| | subnet3: 255.255.255.0
| | serial: 30D44AD
| | FW Version: 4.0
| | FPGA Version: 19.0
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -100.000 to 100.000 MHz
| | _____________________________________________________
| | /
| | | RX DSP: 1
| | | Freq range: -100.000 to 100.000 MHz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: CBX-120 (0x0085)
| | | Serial: 30D2211
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: CBX-120 RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 1200.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: CBX-120 (0x0085)
| | | Serial: 30D2216
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: CBX-120 RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 1200.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -100.000 to 100.000 MHz
| | _____________________________________________________
| | /
| | | TX DSP: 1
| | | Freq range: -100.000 to 100.000 MHz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: CBX-120 (0x0084)
| | | Serial: 30D2211
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: CBX-120 TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 1200.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9146
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: CBX-120 (0x0084)
| | | Serial: 30D2216
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: CBX-120 TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 1200.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: ad9146
| | | | Gain Elements: None
Quoting [email protected]:
> open up a command window
>
> On 2016-07-05 10:44, Sanat Kumar Mishra wrote:
>
>> Hi,
>>
>> I am using Windows 7. Where shall I write this command?
>>
>> Zitat von [email protected]:
>>
>> What happens if you:
>>
>> uhd_usrp_probe --args resource=RIO0
>>
>> ??
>>
>> On 2016-07-05 10:37, Sanat Kumar Mishra wrote:
>>
>> Hi,
>>
>> @"The communications error is of more concern. What type of
>> Ethernet card do you have on your system? What is your network
>> setup between your computer and the X300?"
>> --- I am using NI USRP 2943-R which I found in the einternet as
>> X310. Therefore I flashed usrp_x310_fpga_HGS.lvbitx image to the
>> device. I am using PCI Express for communication using MXI Express
>> cable as a result I havenot set any network setup for the same.
>> Please guide me what to do.
>>
>> Regards,
>> Sanat
>>
>> Zitat von [email protected]:
>>
>> The fact that the header indicates 003.009.003 means that you're
>> actually running 003.009.003, if you installed 3.9.4, it's likely in a
>> place outside your %PATH%.
>>
>> The 'can't open file' error is coming from Gnu Radio, not UHD. My
>> suspicion is that it's trying to open a file that it cannot open on
>> Windows, or is specified wrongly. Not all of the examples are 100%
>> portable.
>>
>> The communications error is of more concern. What type of Ethernet card
>> do you have on your system? What is your network setup between your
>> computer and the X300?
>>
>> On 2016-07-05 06:48, Sanat Kumar Mishra wrote:
>>
>> Hello,
>>
>> I am trying to run the FM receiver example (from youtube) and I get
>> the following errors:
>>
>> "Win32; Microsoft Visual C++ version 14.0; Boost_106000;
>> UHD_003.009.003-0-unknown" - But I am using UHD_003.009.004.
>>
>> "No such file or directory
>> Traceback (most recent call last):
>> File "C:\Users\smishra\Downloads\fm_example.py", line 162, in <module>
>> main()
>> File "C:\Users\smishra\Downloads\fm_example.py", line 156, in main
>> tb = top_block_cls()
>> File "C:\Users\smishra\Downloads\fm_example.py", line 117, in __init__
>> self.blocks_wavfile_sink_0 = blocks.wavfile_sink("", 1, 96000, 8)
>> File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig1.py",
>> line 2701, in make
>> return _blocks_swig1.wavfile_sink_make(filename, n_channels,
>> sample_rate, bits_per_sample)
>> RuntimeError: can't open file"
>>
>> "UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw poke32 - operation timed out."
>>
>> The PPS LED is blinking which as per the 'Getting Started Guide'
>> means 'The device is not locked to the reference signal.'
>>
>> Regards,
>> Sanat
>>
>> Quoting [email protected]:
>>
>> 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
------------------------------
Message: 10
Date: Tue, 05 Jul 2016 11:09:54 -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"
Not sure why you're getting the communication failtures, but your device
appears, from the uhd_usrp_probe output to be functioning correctly.
I suspect that your Gnu Radio installed was linked against UHD 3.9.3,
which is why the apparent version mismatch, because clearly, your
uhd_usrp_probe is linked against the newer library.
How did you install Gnu Radio? This part of the discussion should
probably be continued on the discuss-gnuradio mailing list.
On 2016-07-05 10:58, Sanat Kumar Mishra wrote:
> I have got the following results: Please note I am using NI USRP 2943R which
> is like x310 from specification.
>
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
>
> C:\Users\smishra>uhd_usrp_probe --args resource=RIO0
> Win32; Microsoft Visual C++ version 14.0; Boost_105800;
> UHD_003.009.004-release
>
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out
>
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out
> -- X300 initialization sequence...
> -- Connecting to niusrpriorpc at localhost:5444...
> -- Using LVBITX bitfile C:\Program Files
> (x86)\UHD\share\uhd\images\usrp_x310_fp
> ga_HGS.lvbitx...
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO.... No GPSDO found
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
> _____________________________________________________
> /
> | Device: X-Series Device
> | _____________________________________________________
> | /
> | | Mboard: X310
> | | revision: 8
> | | revision_compat: 7
> | | product: 30813
> | | mac-addr0: 00:80:2f:25:18:f9
> | | mac-addr1: 00:80:2f:25:18:fa
> | | gateway: 192.168.10.1
> | | ip-addr0: 192.168.10.2
> | | subnet0: 255.255.255.0
> | | ip-addr1: 192.168.20.2
> | | subnet1: 255.255.255.0
> | | ip-addr2: 192.168.30.2
> | | subnet2: 255.255.255.0
> | | ip-addr3: 192.168.40.2
> | | subnet3: 255.255.255.0
> | | serial: 30D44AD
> | | FW Version: 4.0
> | | FPGA Version: 19.0
> | |
> | | Time sources: internal, external, gpsdo
> | | Clock sources: internal, external, gpsdo
> | | Sensors: ref_locked
> | | _____________________________________________________
> | | /
> | | | RX DSP: 0
> | | | Freq range: -100.000 to 100.000 MHz
> | | _____________________________________________________
> | | /
> | | | RX DSP: 1
> | | | Freq range: -100.000 to 100.000 MHz
> | | _____________________________________________________
> | | /
> | | | RX Dboard: A
> | | | ID: CBX-120 (0x0085)
> | | | Serial: 30D2211
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: 0
> | | | | Name: CBX-120 RX
> | | | | Antennas: TX/RX, RX2, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: 1200.000 to 6000.000 MHz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: ads62p48
> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
> | | _____________________________________________________
> | | /
> | | | RX Dboard: B
> | | | ID: CBX-120 (0x0085)
> | | | Serial: 30D2216
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: 0
> | | | | Name: CBX-120 RX
> | | | | Antennas: TX/RX, RX2, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: 1200.000 to 6000.000 MHz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: B
> | | | | Name: ads62p48
> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
> | | _____________________________________________________
> | | /
> | | | TX DSP: 0
> | | | Freq range: -100.000 to 100.000 MHz
> | | _____________________________________________________
> | | /
> | | | TX DSP: 1
> | | | Freq range: -100.000 to 100.000 MHz
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | ID: CBX-120 (0x0084)
> | | | Serial: 30D2211
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: 0
> | | | | Name: CBX-120 TX
> | | | | Antennas: TX/RX, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: 1200.000 to 6000.000 MHz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz
> | | | | Connection Type: QI
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: ad9146
> | | | | Gain Elements: None
> | | _____________________________________________________
> | | /
> | | | TX Dboard: B
> | | | ID: CBX-120 (0x0084)
> | | | Serial: 30D2216
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: 0
> | | | | Name: CBX-120 TX
> | | | | Antennas: TX/RX, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: 1200.000 to 6000.000 MHz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz
> | | | | Connection Type: QI
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: B
> | | | | Name: ad9146
> | | | | Gain Elements: None
>
> Quoting [email protected]:
>
> open up a command window
>
> On 2016-07-05 10:44, Sanat Kumar Mishra wrote:
>
> Hi,
>
> I am using Windows 7. Where shall I write this command?
>
> Zitat von [email protected]:
>
> What happens if you:
>
> uhd_usrp_probe --args resource=RIO0
>
> ??
>
> On 2016-07-05 10:37, Sanat Kumar Mishra wrote:
>
> Hi,
>
> @"The communications error is of more concern. What type of Ethernet card
> do you have on your system? What is your network setup between your
> computer and the X300?"
> --- I am using NI USRP 2943-R which I found in the einternet as X310.
> Therefore I flashed usrp_x310_fpga_HGS.lvbitx image to the device. I am
> using PCI Express for communication using MXI Express cable as a result I
> havenot set any network setup for the same.
> Please guide me what to do.
>
> Regards,
> Sanat
>
> Zitat von [email protected]:
>
> The fact that the header indicates 003.009.003 means that you're
> actually running 003.009.003, if you installed 3.9.4, it's likely in a
> place outside your %PATH%.
>
> The 'can't open file' error is coming from Gnu Radio, not UHD. My
> suspicion is that it's trying to open a file that it cannot open on
> Windows, or is specified wrongly. Not all of the examples are 100%
> portable.
>
> The communications error is of more concern. What type of Ethernet card
> do you have on your system? What is your network setup between your
> computer and the X300?
>
> On 2016-07-05 06:48, Sanat Kumar Mishra wrote:
>
> Hello,
>
> I am trying to run the FM receiver example (from youtube) and I get the
> following errors:
>
> "Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.009.003-0-unknown" - But I am using UHD_003.009.004.
>
> "No such file or directory
> Traceback (most recent call last):
> File "C:\Users\smishra\Downloads\fm_example.py", line 162, in <module>
> main()
> File "C:\Users\smishra\Downloads\fm_example.py", line 156, in main
> tb = top_block_cls()
> File "C:\Users\smishra\Downloads\fm_example.py", line 117, in __init__
> self.blocks_wavfile_sink_0 = blocks.wavfile_sink("", 1, 96000, 8)
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig1.py",
> line 2701, in make
> return _blocks_swig1.wavfile_sink_make(filename, n_channels, sample_rate,
> bits_per_sample)
> RuntimeError: can't open file"
>
> "UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out."
>
> The PPS LED is blinking which as per the 'Getting Started Guide' means
> 'The device is not locked to the reference signal.'
>
> Regards,
> Sanat
>
> Quoting [email protected]:
>
> 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/20160705/d4132423/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 5 Jul 2016 11:48:53 -0400
From: "Joshua Monson" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Create Congestion in RFNOC Simulation Model
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I've created a noc block that transmits sample data onto the NOC. I'd like
to test my state machine properly interacts with s_axis_data_tready signal
(from the noc block axi_wrapper module). However, it appears that there is
not enough activity on the NOC to cause the s_axis_data_tready to fall (its
always asserted). Is there an easy way to cause some artificial congestion
in the so I can test my state machine?
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160705/c91970dc/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 4
*****************************************
