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. Problem using B210 with two different RX frequency (??)
2. X310 over PCIe is ok, now which SBX do I have ?
(El Ouni, Naceur (IntlAssoc))
3. Re: X310 over PCIe is ok, now which SBX do I have ?
(James Humphries)
4. USRP B210 - signals shifted when using both TX channels and
LO offsets (Chavez, Christopher A. (Assoc))
5. Re: MSK Modulation Examples (Marcus M?ller)
6. Re: Problem using B210 with two different RX frequency
(Marcus M?ller)
7. Re: Waveform received from USRP2 freezes (Marcus M?ller)
8. Re: USRP B210 - signals shifted when using both TX channels
and LO offsets (Marcus M?ller)
9. Re: USRP-n210: Expected FPGA compatibility number 10, but got
16 (Marcus M?ller)
10. Re: USRP-n210: Expected FPGA compatibility number 10, but got
16 (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 8 Jul 2016 11:56:11 +0800
From: ?? <leon...@qq.com>
To: usrp-users <usrp-users@lists.ettus.com>
Subject: [USRP-users] Problem using B210 with two different RX
frequency
Message-ID: <201607081156102668...@qq.com>
Content-Type: text/plain; charset="gb2312"
Hi!
Recently I tried to use B210 to receive both uplink and downlink channels
of GSM 900. I noticed that the two RX channels in AD9361 share one LO. So I
have to set a high sampling rate (at least 45Msps) and do DDC and decimation
using FPGA. I disabled the limit of sampling rate in UHD while using two RXs.
Then I set the master_clock_rate to 32MHz - 44MHz and it works fine. But when I
set the master_clock_rate higher than 45MHz I got nothing but noise. It doesn't
works when the rate is higher than 45MHz. What's wrong with that? Or is there
other way to receive both up&downlink of GSM signals using B210?
PS: When I set master_clock_rate to 32MHz or higher, sampling rate of data
processing on PC is set to 2M to 4Msps.
Best wishes!
Zhangmeng
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/9d7e3c1e/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 8 Jul 2016 20:31:43 +0000
From: "El Ouni, Naceur (IntlAssoc)" <naceur.elo...@nist.gov>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] X310 over PCIe is ok, now which SBX do I have ?
Message-ID:
<sn1pr09mb0925bd6af5ffb96780c34d689e...@sn1pr09mb0925.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
Thanks James Humphries: I turned off my server. Booteed the X310 then booted
again the server, re-installed niusrprio-installer, turned service on and
voila: X310 communication over PCIe is successful.
I did uihd_usrp_probe on a N210 and got the daughterboard: SBX (0x0054), Name:
SBXv3
and on my X310 it gives SBX v5 (0x0069), Name: SBX/CBX
I am wondering whether the SBX on X310 is the SBX120 or a SBX40.
In Ettus Website: both SBXs are mentioned to be compatible with the X310.
Thanks and Regards,
Naceur El Ouni
NIST - Wireless Networks Division (673)
100 Bureau Dr. Building 222-A218
Gaithersburg, MD 20899
(301) 975-3353
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/00e17f0a/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 8 Jul 2016 16:51:22 -0400
From: James Humphries <james.humphr...@ettus.com>
To: "El Ouni, Naceur (IntlAssoc)" <naceur.elo...@nist.gov>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] X310 over PCIe is ok, now which SBX do I
have ?
Message-ID:
<caewgfhxfg6-d4ccs3aqfezqw6bcna-wkuw+6ti9thkj1kzu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Naceur,
Just for your reference, a list of the EEPROM hex values for the USRP
products is given here:
https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices
It appears you have the SBX-40 in your X310. The SBX-120 would return
0x0082 (TX) or 0x0083 (RX).
-Trip
On Fri, Jul 8, 2016 at 4:31 PM, El Ouni, Naceur (IntlAssoc) via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
>
>
> Thanks James Humphries: I turned off my server. Booteed the X310 then
> booted again the server, re-installed niusrprio-installer, turned service
> on and voila: X310 communication over PCIe is successful.
>
> I did uihd_usrp_probe on a N210 and got the daughterboard: * SBX
> (0x0054), Name: SBXv3*
>
> and on my X310 it gives *SBX v5 (0x0069), Name: SBX/CBX*
>
>
>
> I am wondering whether the SBX on X310 is the SBX120 or a SBX40.
>
> In Ettus Website: both SBXs are mentioned to be compatible with the X310.
>
>
>
> Thanks and Regards,
>
>
>
> Naceur El Ouni
>
> NIST - Wireless Networks Division (673)
>
> 100 Bureau Dr. Building 222-A218
>
> Gaithersburg, MD 20899
>
> (301) 975-3353
>
>
>
> _______________________________________________
> 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/20160708/92b2df42/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 8 Jul 2016 22:38:18 +0000
From: "Chavez, Christopher A. (Assoc)" <christopher.cha...@nist.gov>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] USRP B210 - signals shifted when using both TX
channels and LO offsets
Message-ID:
<dm2pr09mb0732adc947b6d8152ee6501af0...@dm2pr09mb0732.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi everyone,
I attempted set the transmitters of a B210 such that they are in adjacent
frequency bands using LO offsets. Normally when using only a single
transmitter, the LO can be offset while keeping the signal at the intended
center frequency. I've found that when the other transmitter is also used,
signals are instead aliased to be within the Nyquist band around the LO. For
example, setting the LO offset to a multiple of 2*Nyquist frequency will shift
the entire signal, while anything between will shift only part of the signal.
I am using UHD 3.9.4 and GNU Radio 3.7.9 on Ubuntu 14.04; the B210 is
practically new (revision 4, product 2, FW v. 8.0, FPGA v. 13.0). Both TX
channels of the B210 are connected to a splitter into the RX of an N210 (SBX
daughterboard). I have a setup with one transmitter sending a recording and the
other transmitter sending zeroes, both at 12.5MSa/s, and the receiver is set to
a sampling rate of 25MSa/s.
I've attached the GRC flowgraphs and generated Python code I used. The only
difference between single_usrp_tx_file and multi_usrp_tx_file flowgraphs are
that the second channel is disabled in single_usrp_tx_file. The screenshots are
of the transmitter GUI and the UHD FFT example program for the receiver:
- one_tx_lo_center: the LO is at the center of the FFT, and the signal is at
the desired center frequency on the left-hand side of FFT.
- one_tx_lo_right: the LO is one the right-hand side of the FFT, and the signal
is at the desired center frequency on the left-hand side of FFT.
- two_tx_lo_center: the LO is at the center of the FFT, but only part of signal
the desired center frequency on the left-hand side of the FFT while the rest is
shifted by 2*Nyquist to the right.
- two_tx_lo_right: the LO is on the right-hand side of the FFT, and the signal
is shifted by 2*Nyquist to the right of the desired center frequency.
Is this possibly a UHD bug or more likely something in the B210 firmware? At
the moment the B210 is the only device with multiple transmitters I have tested
this on.
Thanks,
Christopher A. Chavez
National Institute of Standards and Technology
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi_usrp_tx_file.py
Type: application/octet-stream
Size: 9916 bytes
Desc: multi_usrp_tx_file.py
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/0dea73bf/attachment-0002.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: one_tx_lo_center.png
Type: image/png
Size: 83959 bytes
Desc: one_tx_lo_center.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/0dea73bf/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: one_tx_lo_right.png
Type: image/png
Size: 83717 bytes
Desc: one_tx_lo_right.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/0dea73bf/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: single_usrp_tx_file.py
Type: application/octet-stream
Size: 7326 bytes
Desc: single_usrp_tx_file.py
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/0dea73bf/attachment-0003.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_multi_usrp_tx_file.grc
Type: application/octet-stream
Size: 25731 bytes
Desc: test_multi_usrp_tx_file.grc
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/0dea73bf/attachment-0002.grc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_single_usrp_tx_file.grc
Type: application/octet-stream
Size: 25476 bytes
Desc: test_single_usrp_tx_file.grc
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/0dea73bf/attachment-0003.grc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: two_tx_lo_center.png
Type: image/png
Size: 88722 bytes
Desc: two_tx_lo_center.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/0dea73bf/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: two_tx_lo_on_right.png
Type: image/png
Size: 88179 bytes
Desc: two_tx_lo_on_right.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/0dea73bf/attachment-0007.png>
------------------------------
Message: 5
Date: Sat, 9 Jul 2016 11:17:24 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] MSK Modulation Examples
Message-ID: <321c39e2-5ae4-114b-6325-edf7c853c...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Charles Yin,
GNU Radio has excellent tutorials on [1] that also cover implementing
modulators.
I'm afraid we don't have tutorials on how to implement specific
modulations in Verilog ? I'd, however, start from easy to hard:
1. Implement noc_block_skeleton block in your FPGA image, verify you
can use it from your PC.
2. go to fpga-src/usrp3/lib/rfnoc/noc_block_skeleton_tb and verify you
can run "make xsim" to run a test bench
3. Where the skeleton just forwards data, write your own AXI
stream-consuming/producing verilog module that e.g. just multiplies
with a constant; save to a new file, replace all occurences of
"skeleton" with your a name of your own; do the same fot the
noc_block_skeleton_tb/ directory and the files within. Make sure you
can run the test bench against your new block.
4. Modify that block to map symbols (let's assume they come in unpacked
as one byte containing one symbol) to constellation points; verify
by testbench as above
5. Implement pulse shaping in another block.
Best regards,
Marcus
[1] http://tutorials.gnuradio.org
On 05.07.2016 20:30, Yin, Charles - 0665 - MITLL via USRP-users wrote:
>
> Neel and Jonathan,
>
>
>
> Thank you for your help, I was able to get RFNoC working on my machine
> finally. I am still fairly new with developing programs in Verilog
> and I was wondering if there were some examples that I can look at
> with creating MSK modulation for GNU Radio. If not, is there any
> general development tutorials that I can look at? Thanks!
>
>
>
> Charles Yin
>
>
>
>
>
> _______________________________________________
> 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/20160709/0f6f528d/attachment-0001.html>
------------------------------
Message: 6
Date: Sat, 9 Jul 2016 11:30:32 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Problem using B210 with two different RX
frequency
Message-ID: <c6bff4f3-7526-d92e-0c74-6f12da193...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Hi Zhangmeng,
> I disabled the limit of sampling rate in UHD while using two RXs.
What exactly did you change? As far as I know, there's only one limit in
there ? and that's the hardware limitation of the AD9361 chip, which
can't use full rates in dual channel configuration.
> Then I set the master_clock_rate to 32MHz - 44MHz and it works fine
Last time I tried, the maximum master clock rate for two channels is
30.72 MHz, as dictated by by the maximum data clock frequency of the
AD9361, which is 61.44 MHz, and has to be shared between the two
channels. So, in fact, I'm a little surprised you say it works fine!
> When I set master_clock_rate to 32MHz or higher, sampling rate of data
> processing on PC is set to 2M to 4Msps.
Are you sure you've actually set a master clock rate of > 30.72 MHz? Is
it possible that UHD automatically used a different rate?
So, I'd like to fully understand the situation here:
We're talking about E-GSM 900, with uplink at 880.0 ? 915.0 MHz and
downlink at 925.0 ? 960.0, right?
Best regards,
Marcus
On 08.07.2016 05:56, ?? via USRP-users wrote:
>
> Hi!
>
> Recently I tried to use B210 to receive both uplink and downlink
> channels of GSM 900. I noticed that the two RX channels in AD9361
> share one LO. So I have to set a high sampling rate (at least 45Msps)
> and do DDC and decimation using FPGA. I disabled the limit of sampling
> rate in UHD while using two RXs. Then I set the master_clock_rate to
> 32MHz - 44MHz and it works fine. But when I set the master_clock_rate
> higher than 45MHz I got nothing but noise. It doesn't works when the
> rate is higher than 45MHz. What's wrong with that? Or is there other
> way to receive both up&downlink of GSM signals using B210?
>
> PS: When I set master_clock_rate to 32MHz or higher, sampling rate of
> data processing on PC is set to 2M to 4Msps.
>
> Best wishes!
>
> ------------------------------------------------------------------------
> Zhangmeng
>
>
> _______________________________________________
> 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/20160709/611a3dee/attachment-0001.html>
------------------------------
Message: 7
Date: Sat, 9 Jul 2016 11:36:50 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Waveform received from USRP2 freezes
Message-ID: <f73ec96c-2ab1-30da-e053-18590b7f4...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Nik,
> I have been using Thinkpad X201, and the plot comes out alright, I
> mean it shows *some* waveform.
Best notebook ever. Still using that, too. It's a little weak CPU-wise
nowadays.
> I have a C# program that calls the sample program
> (rx_sample_to_file.cpp) to read data from the usrp, and using NPlot (a
> free cahrting library for .NET), the C# program plots the waveform.
Does calling rx_samples_to_file.exe manually still work? Because:
> The X1 Carbon does not have a wired lan ( how I wished that I knew it
> before I bought it!) , so I am using USB to ethernet converter to
> connect to the usrp. Could it be the cause?
Yes! We know that most USB3-to-Gigabit-Ethernet adapters don't live up
to their promises, and that the AX???? models tend to just shuffle the
order at which ethernet packets reach your Operating system ? which is
fine for file transfers and such, but UHD doesn't try to re-order
packets, being a realtime protocol - and hence, you get "S" errors
(sequence errors) printed by UHD.
If that's not the cause, I'd suspect there's some software reason; I
really don't know your software nor NPlot, but that would be my primary
suspect if recording just goes smooth.
Haven't tried that on a Carbon, but maybe you could download the GNU
Radio LiveDVD [1], write it to a USB memory stick and boot and try if
things work there, e.g. with GQRX.
Best regards,
Marcus
[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
On 08.07.2016 14:07, Nik B. via USRP-users wrote:
>
> My guess is it is about the graphics hardware or software of my laptop.
>
>
> Working environment is windows 7.-64.
>
> I have a C# program that calls the sample program
> (rx_sample_to_file.cpp) to read data from the usrp, and using NPlot (a
> free cahrting library for .NET), the C# program plots the waveform.
>
>
> I have been using Thinkpad X201, and the plot comes out alright, I
> mean it shows *some* waveform.
>
>
> Today, I got a shiny new X1 Carbon.
>
> I went through the same routine: installed UHD driver ( the latest)
> for Windows, installed and configured boost (1.60). Installed Visual
> Studio 2015 (CE) and compiled and built the above program, just I had
> done with the X201 few months back.
>
>
> Now when I click the exe file, I see a GUI and I see that the program
> starts to fetch data, but within seconds, the GUI freezes.
>
>
> The X1 Carbon has Intel HD graphics 520, built-into the CPU.
>
> I don't have the graphics spec of the X201, right now.
>
>
> I downloaded and installed X1 Carbon's graphics driver just to make
> sure that I have the latest.
>
> I visited this page:
>
> https://www.youtube.com/watch?v=1-UdWS4RAA4
>
> and I can see the movie/graphics all smooth and cool.
>
>
> Yet, the waveform (just random noise from the usrp2, as there is no
> input to the device and there is no antenna) freezes for this test.
>
>
> And the old, old, X201 shows the same waveform smoothly.
>
>
> Knowlege is power.
>
> How sweet it is to have this knowlege why things don't work as expected.
>
>
> The X1 Carbon does not have a wired lan ( how I wished that I knew it
> before I bought it!) , so I am using USB to ethernet converter to
> connect to the usrp. Could it be the cause?
>
> Of course, the X201 does have a wired lan.
>
>
> Video memory of the X1 was set at 256MB, I changed it to 512MB, but
> no improvement.
>
>
>
> _______________________________________________
> 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/20160709/457e23ef/attachment-0001.html>
------------------------------
Message: 8
Date: Sat, 9 Jul 2016 11:50:18 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210 - signals shifted when using both
TX channels and LO offsets
Message-ID: <46623045-f70e-01b9-9dfd-0c8b16a01...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Christopher,
I think it could be a UHD bug with an easy workaround: can you specify
"type=b200,master_clock_rate=25e6" as the device string and see whether
that solves your problem?
Best regards,
Marcus
On 09.07.2016 00:38, Chavez, Christopher A. (Assoc) via USRP-users wrote:
> Hi everyone,
>
> I attempted set the transmitters of a B210 such that they are in adjacent
> frequency bands using LO offsets. Normally when using only a single
> transmitter, the LO can be offset while keeping the signal at the intended
> center frequency. I've found that when the other transmitter is also used,
> signals are instead aliased to be within the Nyquist band around the LO. For
> example, setting the LO offset to a multiple of 2*Nyquist frequency will
> shift the entire signal, while anything between will shift only part of the
> signal.
>
> I am using UHD 3.9.4 and GNU Radio 3.7.9 on Ubuntu 14.04; the B210 is
> practically new (revision 4, product 2, FW v. 8.0, FPGA v. 13.0). Both TX
> channels of the B210 are connected to a splitter into the RX of an N210 (SBX
> daughterboard). I have a setup with one transmitter sending a recording and
> the other transmitter sending zeroes, both at 12.5MSa/s, and the receiver is
> set to a sampling rate of 25MSa/s.
>
> I've attached the GRC flowgraphs and generated Python code I used. The only
> difference between single_usrp_tx_file and multi_usrp_tx_file flowgraphs are
> that the second channel is disabled in single_usrp_tx_file. The screenshots
> are of the transmitter GUI and the UHD FFT example program for the receiver:
> - one_tx_lo_center: the LO is at the center of the FFT, and the signal is at
> the desired center frequency on the left-hand side of FFT.
> - one_tx_lo_right: the LO is one the right-hand side of the FFT, and the
> signal is at the desired center frequency on the left-hand side of FFT.
> - two_tx_lo_center: the LO is at the center of the FFT, but only part of
> signal the desired center frequency on the left-hand side of the FFT while
> the rest is shifted by 2*Nyquist to the right.
> - two_tx_lo_right: the LO is on the right-hand side of the FFT, and the
> signal is shifted by 2*Nyquist to the right of the desired center frequency.
>
> Is this possibly a UHD bug or more likely something in the B210 firmware? At
> the moment the B210 is the only device with multiple transmitters I have
> tested this on.
>
> Thanks,
>
> Christopher A. Chavez
> National Institute of Standards and Technology
>
>
> _______________________________________________
> 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/20160709/c2f3a2f9/attachment-0001.html>
------------------------------
Message: 9
Date: Sat, 9 Jul 2016 12:04:05 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP-n210: Expected FPGA compatibility
number 10, but got 16
Message-ID: <916ef6da-1db4-9f5d-2662-13d82bbdb...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Dear Wangerw,
that code, 32, is normally emitted by the USRP's firmware when it didn't
understand a command that the flasher sent.
Can you give us a network capture? The best way of doing that would be to
1. Install wireshark ("sudo apt-get install wireshark")
2. run wireshark (probably needs to be done as root, i.e. "sudo wireshark")
3. click the "capture options" button, select only the network
interface that connects to your USRP.
4. start the capture, do exactly one execution of uhd_image_loader
--args "type=usrp2,addr=192.168.10.2" , and save the capture in a
PCAPNG file
Best regards,
Marcus
On 07.07.2016 12:10, ??? via USRP-users wrote:
> Hello community,
> There seems to be software compatibility issue between the host (ubuntu
> 16.04) uhd build and USRP N210 FPGA image.
> The Runtime errors are captured as:------------------------------
> wsn1@wsn1-ThinkPad-X200 ~> uhd_usrp_probe
> linux; GNU C++ version 5.3.1 20160413; Boost_105800;
> UHD_003.010.000.git-249-gef57ffcb
>
> -- Opening a USRP2/N-Series device...
> Error: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 10, but got 16:
> The FPGA build is not compatible with the host code build.
>
> But when I download images by running uhd_images_downloader, then run
> uhd_image_loader ,the error is captured as :-----------
> wsn1@wsn1-ThinkPad-X200 ~> uhd_image_loader --args="type=usrp2,addr=192.
> 168.10.2"
> linux; GNU C++ version 5.3.1 20160413; Boost_105800;
> UHD_003.010.000.git-249-gef57ffcb
>
> Error: RuntimeError: Received invalid reply 32 from device.
> ----------------------------------------------------------------------------
> ---------------
> I don't know what the reason is. Can youhelp me!
> Thanks,
> Wangerw
>
>
> _______________________________________________
> 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/20160709/a62729ea/attachment-0001.html>
------------------------------
Message: 10
Date: Sat, 9 Jul 2016 12:05:07 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP-n210: Expected FPGA compatibility
number 10, but got 16
Message-ID: <aacf9e37-f609-adcf-5139-40308be46...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Forgot to ask: What kind of network card do you use? if in doubt, "lspci
| grep -i ether" will probably tell you.
Best regards,
Marcus
On 09.07.2016 12:04, Marcus M?ller wrote:
>
> Dear Wangerw,
>
> that code, 32, is normally emitted by the USRP's firmware when it
> didn't understand a command that the flasher sent.
>
> Can you give us a network capture? The best way of doing that would be to
>
> 1. Install wireshark ("sudo apt-get install wireshark")
> 2. run wireshark (probably needs to be done as root, i.e. "sudo
> wireshark")
> 3. click the "capture options" button, select only the network
> interface that connects to your USRP.
> 4. start the capture, do exactly one execution of uhd_image_loader
> --args "type=usrp2,addr=192.168.10.2" , and save the capture in a
> PCAPNG file
>
> Best regards,
>
> Marcus
>
> On 07.07.2016 12:10, ??? via USRP-users wrote:
>> Hello community,
>> There seems to be software compatibility issue between the host (ubuntu
>> 16.04) uhd build and USRP N210 FPGA image.
>> The Runtime errors are captured as:------------------------------
>> wsn1@wsn1-ThinkPad-X200 ~> uhd_usrp_probe
>> linux; GNU C++ version 5.3.1 20160413; Boost_105800;
>> UHD_003.010.000.git-249-gef57ffcb
>>
>> -- Opening a USRP2/N-Series device...
>> Error: RuntimeError:
>> Please update the firmware and FPGA images for your device.
>> See the application notes for USRP2/N-Series for instructions.
>> Expected FPGA compatibility number 10, but got 16:
>> The FPGA build is not compatible with the host code build.
>>
>> But when I download images by running uhd_images_downloader, then run
>> uhd_image_loader ,the error is captured as :-----------
>> wsn1@wsn1-ThinkPad-X200 ~> uhd_image_loader --args="type=usrp2,addr=192.
>> 168.10.2"
>> linux; GNU C++ version 5.3.1 20160413; Boost_105800;
>> UHD_003.010.000.git-249-gef57ffcb
>>
>> Error: RuntimeError: Received invalid reply 32 from device.
>> ----------------------------------------------------------------------------
>> ---------------
>> I don't know what the reason is. Can youhelp me!
>> Thanks,
>> Wangerw
>>
>>
>> _______________________________________________
>> 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/20160709/f68c1285/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 71, Issue 8
*****************************************
