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 X310 with UBX-160 - transmit freezes with certain
GNURadio flowgraphs (Jimmy Chau)
2. Re: X310 - It is possible to feed samples from a file to the
rx chain? (Jonathon Pendlum)
3. Re: LO offset effect on passband (Michael West)
4. Re: [RFNoC] FPGA image is 2 bytes larger than expected
(Jonathon Pendlum)
5. Re: No GPSDO found message (Roman Olesyuk)
6. Two X310s synchronization and a phase drift (Roman Olesyuk)
7. Re: Two X310s synchronization and a phase drift
([email protected])
8. Re: No GPSDO found message (Michael West)
9. Driver installation failure on Windows 10 (Andrew P. Lentvorski)
10. Re: No GPSDO found message (Nikita Airee)
11. The difference between the samp_rate in GNU Radio and Nyquist
rate (Bob)
12. Re: [RFNoC] FPGA image is 2 bytes larger than expected
(Felipe Augusto Pereira de Figueiredo)
13. Re: No GPSDO found message (Roman Olesyuk)
14. Changing system date and time with burst transmission
(Claudio Cicconetti)
15. Wireless data transfer (do ber)
16. Re: uhd::io_error (Nigel Steed (XENINT))
17. Re: Asymmetry in achievable TX/RX rates (Stefano Bettelli)
18. Re: Asymmetry in achievable TX/RX rates ([email protected])
19. Re: Wireless data transfer (Marcus M?ller)
20. Re: Asymmetry in achievable TX/RX rates (Stefano Bettelli)
21. header file msg.hpp in the uhd release (Disco Daniele)
22. R: header file msg.hpp in the uhd release (Disco Daniele)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Feb 2017 13:22:01 -0500
From: Jimmy Chau <[email protected]>
To: "Collins, Richard" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP X310 with UBX-160 - transmit freezes
with certain GNURadio flowgraphs
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Rich,
Thank you for confirming that you?re also encountering this problem. Are you
also using the USRP X310 with the UBX-160? I?m curious whether the problem is
specific to this combination of hardware.
I?ve been dealing with some (likely unrelated) problems rebuilding GNURadio,
but I will try release_003_009_006 of UHD when I have a chance. Thanks for the
suggestion.
Best,
-Jimmy
> On Feb 10, 2017, at 3:50 PM, Collins, Richard
> <[email protected]> wrote:
>
> Hello Jimmy,
>
> Running your example flowgraph (noise_mult1_tx.grc) gives me the same error.
> I have a couple other simple flowgraphs that also failed (relating to using
> either the Rational Resampler or Noise Source) the same way as long as I was
> using either release_003_010_001_001 or release_003_010_001_000. Given other
> things that were fixed since 003_010_000_000 that I have to avoid, I've since
> moved to using release_003_009_006, and that seems to (for now) solve it for
> me.
>
> - Rich
>
> On Wed, Nov 9, 2016 at 9:15 PM, Jimmy Chau via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
> Hi,
>
> Using certain GNURadio flowgraphs (created in gnuradio-companion) with the
> USRP X310 and the UBX-160 daughter card, I?m encountering a problem where the
> radio stops transmitting, and signals/items seem to stop being
> generated/propagating through the flowgraph. No error would appear when this
> happens (except sometimes, but not always, a burst of underflow ?U? appearing
> all at once, shortly before before the transmit signal stops).
>
> I?ve tried to narrow down the cause of this problem, and I?ve attached my
> simplest gnuradio-companion flowgraph (noise_mult1_tx.grc) that reliably
> triggers the problem within about 10 seconds. This flowgraph consists of a
> Noise Source, attached to a Multiply Const (that multiples by 1), attached to
> the UHD USRP Sink. I?ve also attached a QT GUI Sink to the input of the UHD
> USRP Sink to view the signal.
>
> Eventually, the QT GUI Sink shows that the signal stops (i.e., stops
> updating), and if I use the RX2 input of the UBX-160 to receive the
> transmitted signal (through a SMA cable and a 20dB attenuator), the received
> signal would simply be the noise floor (i.e., no transmitted signal present).
> However, the receiver would continue update.
>
> I haven?t been able to figure out exactly what?s causing this problem. If I
> remove the Multiply Const block (and connect the Noise Source directly) or if
> I replace the Noise Source with a Signal Source (a sine wave), the problem
> does not appear, and the transmitter works for as long as I let it run.
>
> This problem would also appear if I try to add the outputs of two separate
> NBFM Transmit blocks (with a Rational Resampler), using an Add block, even
> without any Multiply Const block present. The setup that causes this problem
> is arranged as:
>
> [Signal Source] ?> [NBFM Transmit] ?> [Rational Resampler] ?> [Add] ?> [UHD
> USRP Sink]
> [Signal Source] ?> [NBFM Transmit] ?> [Rational Resampler] ?> [ ]
>
> But it doesn?t appear if I try to feed only one NBFM signal into the UHD USRP
> Sink block.
>
> I?ve tried reinstalling uhd and gnuradio using the latest commits from the
> "maint? branch (commit edfbbc from Nov 4 for gnuradio 3.7.10.1), but that did
> not seem to help. I?m running GNURadio on Ubuntu 16.04.1 LTS. UHD?s version
> string is:
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.010.001.000-1-g4594f7d7
> The X310 also has a LFTX daughter card in slot B.
>
> I?ve tried switching to another computer and removing all other USRPs from
> the gigabit Ethernet switch (so only the computer and the USRP X310 are
> connected). However, this did not seem to resolve the problem.
> Unfortunately, the computer and USRP are positioned so that it?s difficult to
> connect them without the switch in between, but I can try to connect them
> directly if it might help.
>
> Any ideas on what the problem might be or suggestions on how to troubleshoot
> this?
> I can provide additional examples if it would be helpful.
>
> Thank you for any help! And please let me know if my question would be
> better directed towards the discuss-gnuradio mailing list.
>
>
> Best regards,
> -Jimmy
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/2f1ad212/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/2f1ad212/attachment-0001.asc>
------------------------------
Message: 2
Date: Mon, 27 Feb 2017 12:50:35 -0600
From: Jonathon Pendlum <[email protected]>
To: Paolo Palana <[email protected]>
Cc: Jason Matusiak <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 - It is possible to feed samples from a
file to the rx chain?
Message-ID:
<CAGdo0uQ--DH86RXGZ5n=SKDXNs_3rC_SAE+YL54B=vqnwdr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Paolo,
You can test the DSP in the RX chain in GNU Radio using a signal source and
the RFNoC: DDC block.
Jonathon
On Mon, Feb 27, 2017 at 4:43 AM, Paolo Palana via USRP-users <
[email protected]> wrote:
> On 02/24/2017 05:35 PM, Jason Matusiak wrote:
> > Paolo,
> >
> > I may be oversimplifying this, but would a file-source block work for
> > you? I currently have a known-signal that is saved in a file that I
> > use to test out my custom RFNoC blocks, it seems to work pretty well
> > (just remember to add a throttle since you aren't using the radio
> > front-end anymore).
>
> Dear Jason, first of all thank you for your replay.
> What you said sounds exactly like what I want. I didn't noticed this
> block before, this is of course my fault.
> What I really need is a way to feed to my block a test signal, e.g. a
> sinusoid, and then observe the results.
> May be you can explain better how to you use this features or give a
> link to understand how to do that?
> Reading the HDL code give me no hint.
>
> Have a good day.
>
> Paolo
>
> _______________________________________________
> 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/20170227/aa5ad0b9/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 27 Feb 2017 10:54:13 -0800
From: Michael West <[email protected]>
To: Dominik Eyerly <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LO offset effect on passband
Message-ID:
<cam4xkrrxsdf5el4wwfplco-otuy732rzgn6mnheaaseuovd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Dominik,
The +/-6 MHz minimum is a red herring. There is no need to shift that
much. That was my misunderstanding. I thought the frontend bandwidth was
getting adjusted automatically and it wasn't. You can use any LO offset as
long as you set the bandwidth correctly.
I believe what you are seeing is expected. You will only have a
symmetrical response (or as close to symmetrical as possible) and the best
flatness at an LO offset of zero. As you apply more of an LO offset, you
will see more roll off. Which way the roll off slopes is determined by
whether the LO offset is positive or negative.
Regards,
Michael
On Mon, Feb 27, 2017 at 4:06 AM, Dominik Eyerly <
[email protected]> wrote:
> Hi Michael,
>
> Thanks for getting back to me. Unfortunately, this does not improve the
> plots. Even settings the bandwidth to max (56e6) still produces a lopsided
> passband. Do you have any other recommendations I could try?
>
> cheers,
> dominik
>
> On 02/25/2017 10:48 PM, Michael West wrote:
>
> Hi Dominik,
>
> I believe you need to set the rx_bandwidth to rate + abs(2*lo_offset).
>
> Regards,
> Michael
>
> On Thu, Feb 23, 2017 at 7:02 AM, Dominik Eyerly via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> I have some follow-up questions to the LO offset discussion. Some quick
>> background, I've been characterizing and calibrating the rx of the B205-i
>> for several months now and I am trying to squeeze every bit of performance
>> out of it. In general, the calibration works quite well. However, I'm
>> always looking for tips and tricks to improve the performance. It was
>> mentioned that one should use an offset of at least +/-6MHz for optimal
>> performance. In spirit of this I wanted to investigate the flatness of the
>> passband with the two options (no offset, -8MHz offset). According to this
>> https://files.ettus.com/manual/page_usrp_b200.html 56MHz is the max
>> master clock so I set mine to 40MHz to enable a 20MHz sample rate. My
>> rx_bandwidth is set according to rate+abs(LO_OFFSET). The test is
>> performed in the following way:
>>
>> 1. Set B205 rx freq to 2.4G, gain to 35, rate to 20M, (10db external
>> pad connected)
>> 2. Generator sweeps a tone from 2.4G-30M to 2.4G+30M in 50kHz steps
>> at constant -20dBm output power.
>> 3. Fetch 50k samples per sweep point, flat top window, FFT, extract
>> largest tone and put it in dBm.
>>
>> The plots linked below are the results of the two sweeps (0 offset, -8MHz
>> offset). Note that the y-axis scale has an arbitrary x-dBm offset that is
>> not interesting for this test.
>>
>> http://imgur.com/a/laDFy
>>
>> I noticed that the flatness and shape of the two options are quite
>> different. Some things I expected like the image being mixed in at the
>> lower frequencies for the -8MHz offset, however, I was hoping the passband
>> would look more similar. For example, at +4MHz tone freq, there is 1dB of
>> difference. My question is as simple as, is this expected or am I
>> configuring something incorrectly? Also, what procedure would you recommend
>> for equalizing the passband?
>>
>> cheers,
>> Dominik
>>
>> --
>>
>>
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>> Email: [email protected]
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>> *Support Telefon: +49 (0) 7732 9815 100
>> <+49%207732%209815100>*[email protected][image: sig]
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
>> _______________________________________________ USRP-users mailing list
>> [email protected] http://lists.ettus.com/mailman
>> /listinfo/usrp-users_lists.ettus.com
>
> --
>
> --
>
> i.A. Dominik Eyerly
> Software
>
> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
> Email: [email protected]
> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
> *Support Telefon: +49 (0) 7732 9815 100
> <+49%207732%209815100>*[email protected][image: sig]
> Gesch?ftsleitung: Michael Konrad
> Handelsregisternr: HRB 550593 in Freiburg
> Ust-Id-Nr. DE 206693267
>
> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
> bitte umgehend. Danke
>
> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
> contains information from Konrad GmbH, which is intended only for the use of
> the individual or entity to which it is addressed, and which may contain
> information that is privileged, confidential, and/or otherwise exempt from
> disclosure under applicable law. If the reader of this message is not the
> intended recipient, any disclosure, dissemination, distribution, copying or
> other use of this communication or its substance is prohibited. If you have
> received this communication in error, please contact us immediately. Thank
> you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/6ef59e3f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/6ef59e3f/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/6ef59e3f/attachment-0001.jpe>
------------------------------
Message: 4
Date: Mon, 27 Feb 2017 12:55:16 -0600
From: Jonathon Pendlum <[email protected]>
To: Felipe Augusto Pereira de Figueiredo <[email protected]>
Cc: Sam Carey <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] [RFNoC] FPGA image is 2 bytes larger than
expected
Message-ID:
<CAGdo0uS7Bp4aAkJw2kcTnm5JrToC-ywPrLORzdvi0jzqLUo=q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Felipe,
What if you build the same image by running make X310_RFNOC_HG in
usrp3/top/x300? Is it still too large?
On Mon, Feb 27, 2017 at 4:23 AM, Felipe Augusto Pereira de Figueiredo via
USRP-users <[email protected]> wrote:
> Dear Sam,
>
> Many thanks for your tip, I've followed that and it worked. Just
> changed the size of the macro with the expected bitstream size.
>
> I hope someone from Ettus can explain why that problem happens and if
> it can be solved other way instead of tweaking the source code.
>
> Now the output of "uhd_usrp_probe" is like I had expected it to be.
>
> | | _____________________________________________________
> | | /
> | | | RFNoC blocks on this device:
> | | |
> | | | * DmaFIFO_0
> | | | * Radio_0
> | | | * Radio_1
> | | | * DDC_0
> | | | * DDC_1
> | | | * DUC_0
> | | | * DUC_1
> | | | * FFT_0
>
> Thanks and Best Regards,
>
> Felipe
>
> On Fri, Feb 24, 2017 at 3:27 PM, Sam Carey <[email protected]> wrote:
> > Howdy,
> >
> > I had this problem a while back. My workaround was to simply edit the
> image
> > loader code so that it is OK with the larger file size.
> > Just do a search for the smaller byte number in the uhd/host source code,
> > change it to the larger byte number, and rebuild/reinstall uhd.
> > Apparently, the byte count is not a strict requirement for image loading.
> >
> > You're the second other person I've seen with this problem.
> > Maybe somebody could apply this change to the main branch or something?
> >
> > -Sam
> >
> >
>
> _______________________________________________
> 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/20170227/70f7bd5d/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 27 Feb 2017 23:27:06 +0300
From: Roman Olesyuk <[email protected]>
To: Nikita Airee <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] No GPSDO found message
Message-ID:
<CAMZegnFr+QfxiQOK+XnZ_iPTJ-hDsxSv4UGsYreN=fyfoeh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nikita,
I experience the same issue. In addition I observe the following behavior. I
checked LEDs on GPSDO board. Two green LEDs are on for several seconds when
I power on X310 and then they go off. If the PCIe connector is plugged in,
but PC is powered off, in about 30-60 seconds I observe that PPS LED starts
blinking once per seconds, and after about 10 minutes GPS LOCK LED (on
GPSDO boards and on the front panel) goes on. This is very stable behavior
when PCIe IS PLUGGED IN, BUT PC IS OFF. I can get very stable GPS lock (the
LED is on as long as I can observe) and PPS is always blinking. If I use
1Gbps network connection (with PCIe connector unplugged) or if I use PCIe
connection (just power on X310, then power on PC), I do not see PPS
blinking even after several minutes. Sometimes PPS LED goes blinking and
after 10-60 seconds it goes off again. Very rarely I can see PPS blinking
for several minutes and GPS LOCK LED is even rarer (almost never see it).
The behaviors are almost the same in PCIe and 1Gbps modes. So it looks for
me like some FPGA/GPSDO initialization problem.
Can you confirm my observations?
--
Yours sincerely, Roman Olesyuk.
2017-02-27 13:43 GMT+03:00 Nikita Airee via USRP-users <
[email protected]>:
> Hi list,
>
> the information I had provided might not have been enough. So here is some
> more:
>
> My X310 has internal GPSDO. This is visible to UHD when I perform
> uhd_usrp_probe provided it is connected to my laptop using Gigabit ethernet:
>
> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO, Firmware
> Rev 0.929a*
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
> ...
>
> However, when I use PCI Express for connection, it says:
>
> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>
> -- X300 initialization sequence...
> -- Connecting to niusrpriorpc at localhost:5444...
> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
> rp_x310_fpga_HGS.lvbitx...
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> --
>
>
> *Detecting internal GPSDO.... UHD Error: GPS invalid reply "", assuming
> none availableNo GPSDO found*
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
> ...
>
> When the same USRP is connected to a laptop with a different UHD version
> via PCIe, I get:
>
> linux; GNU C++ version 4.8.2; Boost_106000; UHD_3.11.0.git-28-gc66cb1ba
>
> -- X300 initialization sequence...
> -- Connecting to niusrpriorpc at localhost:5444...
> -- Using LVBITX bitfile /usr/local/share/uhd/images/
> usrp_x310_fpga_HG.lvbitx...
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO, Firmware
> Rev 0.929a*
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1186.1MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1189.4MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> ...
>
> Also when I try sync_to_gps, it says:
> ...
> Waiting for reference lock...LOCKED
> *WARNING: GPS not locked - time will not be accurate until locked *
> USRP time: 1136078288.000000000
> GPSDO time: 1136078288.000000000
>
> SUCCESS: USRP time synchronized to GPS time
>
> On querying gpsdo sensors soon after, I find that :
>
> USRP Locked to GPSDO 10 MHz Reference.
>
> GPS and UHD Device time are NOT aligned;
> last_pps: 9 vs gps: 1136078227. Trying to set the device time to GPS
> time...
> -- 1) catch time transition at pps edge
> -- 2) set times next pps (synchronously)
> last_pps: 1136078231 vs gps: 1136078231.
> GPS and UHD Device time are aligned.
> Printing available NMEA strings:
> GPS_GPGGA: $GPGGA,011711.00,0000.0000,N,00000.0000,E,0,99,1.0,0.0,M,0.0,M,,*5B
>
> GPS_GPRMC: $GPRMC,011711.00,V,0000.0000,N,00000.0000,E,0.0,0.0,010106,,*25
>
> GPS Epoch time at last PPS: 1136078232.00000 seconds
> UHD Device time last PPS: 1136078232.00000 seconds
> UHD Device time right now: 1136078232.27291 seconds
> PC Clock time: 1487756260 seconds
> ...
>
> Could anybody please help me with this? I suppose that when the gps is
> locked, it means that uhd is time aligned with gps? If so, I would also
> really like to know exactly how you permanently lock gps.
>
> Bests,
> Nikita Airee
>
>
> On Tue, Feb 21, 2017 at 8:20 PM, Nikita Airee <[email protected]>
> wrote:
>
>> Hi list,
>>
>> I have:
>>
>> Ubuntu 14.04
>>
>> UHD: 003.009.006-0-g122d5f8e
>>
>> USRP X310 with CBX20 + GPSDO
>>
>> I moved to UHD 3.9.6 very recently and since then have been facing the
>> following issue related to GPSDO:
>>
>> *UHD Error: GPS invalid reply "", assuming none available
>> No GPSDO found*
>>
>> UHD_3.11.0.git-28-gc66cb1ba would never throw up this message.
>>
>> Is this a known issue? If not, how do I use GPSDO?
>>
>> Bests,
>>
>> Nikita Airee
>>
>>
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
? ?????????, ????? ??????.
Yours sincerely, Roman Olesyuk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/c765b67e/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 27 Feb 2017 23:46:47 +0300
From: Roman Olesyuk <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Two X310s synchronization and a phase drift
Message-ID:
<CAMZegnFbuZTgc38d=2yp-dcnjm4nmqhypncdkmm7akpkwjn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Everybody,
I have an issue while trying to synchronize two X310s for MIMO application.
I have the following setup.
Two X310s with two SBX120 in each are connected to the same PC (using PCIe
or 1Gbps connection). So in total I have four channels 0, 1, 2, 3. Master
X310 has GPSDO, but currently I do not use it, only the internal clock is
used. Master's PPS out and clock out are connected to slave's PPS in and
clock in. On all 4 RF inputs I transmit 10kHz sine wave at 2.45 GHz @ 1MHz
bandwidth from bladeRF via 4-way splitter. Then my workflow is as follows:
1. create multi_usrp interface
2. set_clock_source("internal", 0); // On master
3. set_time_source("internal", 0); // On master
4. set_clock_source("external", 1); // On slave
5. set_time_source("external", 1); // On slave
6. set_time_unknown_pps(uhd::time_spec_t(0.0));
7. set RX LO center frequency with a time spec synchronously on the
master and on the slave
8. issue stream command to multi_usrp with the time spec in future for
10000 samples 1000 times with 1 second pause, write buffers to the file,
thus the total timespan is about 20 minutes.
When I calculate phase difference relative to channel 0 for channels 1, 2,
3, I get the following result. The phase of channel 1 (on the same X310 as
channel 0, on the master) is stable over the whole timespan. The phases of
channels 2, 3 have a slow drift about 1 radian per minute relative the
channel 0. Channels 2, 3 (on the same X310, the slave) drift synchronously,
that is no drift between channels 2 and 3. It looks like LO PLLs work fine
(taking into account that there is no phase drift between two SBX120 in the
same X310 and that SBX120s do not share the LO). Also the phase drift fades
out (looks exponential). In some experiments I see more stable picture, in
the rest the drift is as described above.
What can be a problem here?
--
? ?????????, ????? ??????.
Yours sincerely, Roman Olesyuk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/45d69db0/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 27 Feb 2017 17:13:53 -0500
From: [email protected]
To: Roman Olesyuk <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Two X310s synchronization and a phase drift
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Roman:
There will be a fixed phase-offset proportional to the length of your
daisy-chaining cables, and the effective electrical length of the
circuitry inside the "master" X310 that mirrors the 1PPS and 10MHz
internal signals. BOTH of these can experience thermal drift, and
there is almost *guaranteed* to be thermal drift between the internal
10MHz/1PPS signals inside the X310 and the cables that are carrying
those signals to your 2nd X310.
The best way to set up systems like this is with a common clock source,
like the Octoclock or Octoclock-G, using equal-lengths of 10MHz and 1PPS
cabling to each X310 (or other USRP) that is served by the Octoclock.
The internal circuitry inside the Octoclock is designed to be
phase-matched, and while it *will* thermal drift, it will all thermal
drift at the same rate. Similarly, your external cables, if all the
same type and length will provide good long-term phase coherence if
they're all in the same type of thermal environment.
On 2017-02-27 15:46, Roman Olesyuk via USRP-users wrote:
> Hi Everybody,
>
> I have an issue while trying to synchronize two X310s for MIMO application. I
> have the following setup.
>
> Two X310s with two SBX120 in each are connected to the same PC (using PCIe or
> 1Gbps connection). So in total I have four channels 0, 1, 2, 3. Master X310
> has GPSDO, but currently I do not use it, only the internal clock is used.
> Master's PPS out and clock out are connected to slave's PPS in and clock in.
> On all 4 RF inputs I transmit 10kHz sine wave at 2.45 GHz @ 1MHz bandwidth
> from bladeRF via 4-way splitter. Then my workflow is as follows:
>
> * create multi_usrp interface
> * set_clock_source("internal", 0); // On master
> * set_time_source("internal", 0); // On master
> * set_clock_source("external", 1); // On slave
> * set_time_source("external", 1); // On slave
> * set_time_unknown_pps(uhd::time_spec_t(0.0));
> * set RX LO center frequency with a time spec synchronously on the master and
> on the slave
> * issue stream command to multi_usrp with the time spec in future for 10000
> samples 1000 times with 1 second pause, write buffers to the file, thus the
> total timespan is about 20 minutes.
>
> When I calculate phase difference relative to channel 0 for channels 1, 2, 3,
> I get the following result. The phase of channel 1 (on the same X310 as
> channel 0, on the master) is stable over the whole timespan. The phases of
> channels 2, 3 have a slow drift about 1 radian per minute relative the
> channel 0. Channels 2, 3 (on the same X310, the slave) drift synchronously,
> that is no drift between channels 2 and 3. It looks like LO PLLs work fine
> (taking into account that there is no phase drift between two SBX120 in the
> same X310 and that SBX120s do not share the LO). Also the phase drift fades
> out (looks exponential). In some experiments I see more stable picture, in
> the rest the drift is as described above.
>
> What can be a problem here?
> --
>
> ? ?????????, ????? ??????.
> Yours sincerely, Roman Olesyuk.
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/602c3cff/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 27 Feb 2017 14:36:58 -0800
From: Michael West <[email protected]>
To: Roman Olesyuk <[email protected]>
Cc: Nikita Airee <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] No GPSDO found message
Message-ID:
<CAM4xKrqhXK=LDE8M4oaMsZMEUAt9-mk9k=yccdy_oq7vplx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nikita,
Sadly, we know what this issue is. We sped up the X300 initialization so
much that the firmware on the GPSDO does not have time to finish
initializing before the detection code runs. The problem was fixed in the
3.10.1.1 release, but for some reason the fix did not get applied to the
3.9.6 release. The specific commit that is needed is
https://github.com/EttusResearch/uhd/commit/63fcfb9574d64797b807a0dd356f5d7bfc48f082
You can try to patch with that commit until we get it properly fixed. We
should have it fixed on the LTS branch soon.
Regards,
Michael
On Mon, Feb 27, 2017 at 12:27 PM, Roman Olesyuk via USRP-users <
[email protected]> wrote:
> Hi Nikita,
>
> I experience the same issue. In addition I observe the following behavior. I
> checked LEDs on GPSDO board. Two green LEDs are on for several seconds when
> I power on X310 and then they go off. If the PCIe connector is plugged in,
> but PC is powered off, in about 30-60 seconds I observe that PPS LED starts
> blinking once per seconds, and after about 10 minutes GPS LOCK LED (on
> GPSDO boards and on the front panel) goes on. This is very stable behavior
> when PCIe IS PLUGGED IN, BUT PC IS OFF. I can get very stable GPS lock (the
> LED is on as long as I can observe) and PPS is always blinking. If I use
> 1Gbps network connection (with PCIe connector unplugged) or if I use PCIe
> connection (just power on X310, then power on PC), I do not see PPS
> blinking even after several minutes. Sometimes PPS LED goes blinking and
> after 10-60 seconds it goes off again. Very rarely I can see PPS blinking
> for several minutes and GPS LOCK LED is even rarer (almost never see it).
> The behaviors are almost the same in PCIe and 1Gbps modes. So it looks for
> me like some FPGA/GPSDO initialization problem.
>
> Can you confirm my observations?
>
> --
> Yours sincerely, Roman Olesyuk.
>
> 2017-02-27 13:43 GMT+03:00 Nikita Airee via USRP-users <
> [email protected]>:
>
>> Hi list,
>>
>> the information I had provided might not have been enough. So here is
>> some more:
>>
>> My X310 has internal GPSDO. This is visible to UHD when I perform
>> uhd_usrp_probe provided it is connected to my laptop using Gigabit ethernet:
>>
>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>> Firmware Rev 0.929a*
>> -- Initialize Radio0 control...
>> -- Performing register loopback test... pass
>> -- Initialize Radio1 control...
>> -- Performing register loopback test... pass
>> ...
>>
>> However, when I use PCI Express for connection, it says:
>>
>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>
>> -- X300 initialization sequence...
>> -- Connecting to niusrpriorpc at localhost:5444...
>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>> rp_x310_fpga_HGS.lvbitx...
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> --
>>
>>
>> *Detecting internal GPSDO.... UHD Error: GPS invalid reply "",
>> assuming none availableNo GPSDO found*
>> -- Initialize Radio0 control...
>> -- Performing register loopback test... pass
>> -- Initialize Radio1 control...
>> -- Performing register loopback test... pass
>> ...
>>
>> When the same USRP is connected to a laptop with a different UHD version
>> via PCIe, I get:
>>
>> linux; GNU C++ version 4.8.2; Boost_106000; UHD_3.11.0.git-28-gc66cb1ba
>>
>> -- X300 initialization sequence...
>> -- Connecting to niusrpriorpc at localhost:5444...
>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>> rp_x310_fpga_HG.lvbitx...
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>> Firmware Rev 0.929a*
>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1186.1MB/s)
>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1189.4MB/s)
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> ...
>>
>> Also when I try sync_to_gps, it says:
>> ...
>> Waiting for reference lock...LOCKED
>> *WARNING: GPS not locked - time will not be accurate until locked *
>> USRP time: 1136078288.000000000
>> GPSDO time: 1136078288.000000000
>>
>> SUCCESS: USRP time synchronized to GPS time
>>
>> On querying gpsdo sensors soon after, I find that :
>>
>> USRP Locked to GPSDO 10 MHz Reference.
>>
>> GPS and UHD Device time are NOT aligned;
>> last_pps: 9 vs gps: 1136078227. Trying to set the device time to GPS
>> time...
>> -- 1) catch time transition at pps edge
>> -- 2) set times next pps (synchronously)
>> last_pps: 1136078231 vs gps: 1136078231.
>> GPS and UHD Device time are aligned.
>> Printing available NMEA strings:
>> GPS_GPGGA:
>> $GPGGA,011711.00,0000.0000,N,00000.0000,E,0,99,1.0,0.0,M,0.0,M,,*5B
>>
>> GPS_GPRMC: $GPRMC,011711.00,V,0000.0000,N,00000.0000,E,0.0,0.0,010106,,*25
>>
>> GPS Epoch time at last PPS: 1136078232.00000 seconds
>> UHD Device time last PPS: 1136078232.00000 seconds
>> UHD Device time right now: 1136078232.27291 seconds
>> PC Clock time: 1487756260 seconds
>> ...
>>
>> Could anybody please help me with this? I suppose that when the gps is
>> locked, it means that uhd is time aligned with gps? If so, I would also
>> really like to know exactly how you permanently lock gps.
>>
>> Bests,
>> Nikita Airee
>>
>>
>> On Tue, Feb 21, 2017 at 8:20 PM, Nikita Airee <[email protected]>
>> wrote:
>>
>>> Hi list,
>>>
>>> I have:
>>>
>>> Ubuntu 14.04
>>>
>>> UHD: 003.009.006-0-g122d5f8e
>>>
>>> USRP X310 with CBX20 + GPSDO
>>>
>>> I moved to UHD 3.9.6 very recently and since then have been facing the
>>> following issue related to GPSDO:
>>>
>>> *UHD Error: GPS invalid reply "", assuming none available
>>> No GPSDO found*
>>>
>>> UHD_3.11.0.git-28-gc66cb1ba would never throw up this message.
>>>
>>> Is this a known issue? If not, how do I use GPSDO?
>>>
>>> Bests,
>>>
>>> Nikita Airee
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> ? ?????????, ????? ??????.
> Yours sincerely, Roman Olesyuk.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/e7001990/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 27 Feb 2017 21:21:41 -0800
From: "Andrew P. Lentvorski" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Driver installation failure on Windows 10
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
When I go to update my driver on Windows 10 I get:
"Windows encountered a problem installing the driver software for your
device"
"Windows found driver software for your device but encountered an error
while attempting to install it."
"Ettus Research LLC B200/B210"
"There is no driver selected for the device information set or element"
If I close that, and unplug and replug my B200, Device Manager pops up a
category of "USRPs" and "Ettus Research LLC B200/B210" but
"uhd_find_devices" returns:
"Win32; Microsoft Visual C++ version 14.0; Boost_105900;
UHD_003.010.001.001-release"
"No UHD Devices Found".
Any suggestions?
-a
------------------------------
Message: 10
Date: Tue, 28 Feb 2017 13:03:01 +0530
From: Nikita Airee <[email protected]>
To: Michael West <[email protected]>
Cc: Roman Olesyuk <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] No GPSDO found message
Message-ID:
<CAOT=stnfwylvvt_q0do6oyod3vs3_qopss+qb39d-lqjn_y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
No Roman, I don't see such a behaviour in my USRP. Because in my case the
GPS refuses to lock but the PPS works fine blinking every second. Did you
try the patch? Does it work for you?
Michael, thanks for your suggestion! But it seems like it is not working
for me. It is entirely possible that I may be doing something wrong because
I have never patched a commit before. But the gps_ctrl.cpp file does change
at its location <working directory>/uhd/host/usrp/.
Also for when the gpsdo does work, ie with Ethernet, how do I get this
gpsdo to lock? I suppose simply running sync_to_gps should time and
reference lock my gpsdo?
Bests,
Nikita
On Tue, Feb 28, 2017 at 4:06 AM, Michael West <[email protected]>
wrote:
> Hi Nikita,
>
> Sadly, we know what this issue is. We sped up the X300 initialization so
> much that the firmware on the GPSDO does not have time to finish
> initializing before the detection code runs. The problem was fixed in the
> 3.10.1.1 release, but for some reason the fix did not get applied to the
> 3.9.6 release. The specific commit that is needed is https://github.com/
> EttusResearch/uhd/commit/63fcfb9574d64797b807a0dd356f5d7bfc48f082
>
> You can try to patch with that commit until we get it properly fixed. We
> should have it fixed on the LTS branch soon.
>
> Regards,
> Michael
>
> On Mon, Feb 27, 2017 at 12:27 PM, Roman Olesyuk via USRP-users <
> [email protected]> wrote:
>
>> Hi Nikita,
>>
>> I experience the same issue. In addition I observe the following
>> behavior. I checked LEDs on GPSDO board. Two green LEDs are on for
>> several seconds when I power on X310 and then they go off. If the PCIe
>> connector is plugged in, but PC is powered off, in about 30-60 seconds I
>> observe that PPS LED starts blinking once per seconds, and after about 10
>> minutes GPS LOCK LED (on GPSDO boards and on the front panel) goes on. This
>> is very stable behavior when PCIe IS PLUGGED IN, BUT PC IS OFF. I can get
>> very stable GPS lock (the LED is on as long as I can observe) and PPS is
>> always blinking. If I use 1Gbps network connection (with PCIe connector
>> unplugged) or if I use PCIe connection (just power on X310, then power on
>> PC), I do not see PPS blinking even after several minutes. Sometimes PPS
>> LED goes blinking and after 10-60 seconds it goes off again. Very rarely I
>> can see PPS blinking for several minutes and GPS LOCK LED is even rarer
>> (almost never see it). The behaviors are almost the same in PCIe and 1Gbps
>> modes. So it looks for me like some FPGA/GPSDO initialization problem.
>>
>> Can you confirm my observations?
>>
>> --
>> Yours sincerely, Roman Olesyuk.
>>
>> 2017-02-27 13:43 GMT+03:00 Nikita Airee via USRP-users <
>> [email protected]>:
>>
>>> Hi list,
>>>
>>> the information I had provided might not have been enough. So here is
>>> some more:
>>>
>>> My X310 has internal GPSDO. This is visible to UHD when I perform
>>> uhd_usrp_probe provided it is connected to my laptop using Gigabit ethernet:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>>
>>> -- X300 initialization sequence...
>>> -- Determining maximum frame size... 1472 bytes.
>>> -- Setup basic communication...
>>> -- Loading values from EEPROM...
>>> -- Setup RF frontend clocking...
>>> -- Radio 1x clock:200
>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>> Firmware Rev 0.929a*
>>> -- Initialize Radio0 control...
>>> -- Performing register loopback test... pass
>>> -- Initialize Radio1 control...
>>> -- Performing register loopback test... pass
>>> ...
>>>
>>> However, when I use PCI Express for connection, it says:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>>
>>> -- X300 initialization sequence...
>>> -- Connecting to niusrpriorpc at localhost:5444...
>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>> rp_x310_fpga_HGS.lvbitx...
>>> -- Setup basic communication...
>>> -- Loading values from EEPROM...
>>> -- Setup RF frontend clocking...
>>> -- Radio 1x clock:200
>>> --
>>>
>>>
>>> *Detecting internal GPSDO.... UHD Error: GPS invalid reply "",
>>> assuming none availableNo GPSDO found*
>>> -- Initialize Radio0 control...
>>> -- Performing register loopback test... pass
>>> -- Initialize Radio1 control...
>>> -- Performing register loopback test... pass
>>> ...
>>>
>>> When the same USRP is connected to a laptop with a different UHD version
>>> via PCIe, I get:
>>>
>>> linux; GNU C++ version 4.8.2; Boost_106000; UHD_3.11.0.git-28-gc66cb1ba
>>>
>>> -- X300 initialization sequence...
>>> -- Connecting to niusrpriorpc at localhost:5444...
>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>> rp_x310_fpga_HG.lvbitx...
>>> -- Setup basic communication...
>>> -- Loading values from EEPROM...
>>> -- Setup RF frontend clocking...
>>> -- Radio 1x clock:200
>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>> Firmware Rev 0.929a*
>>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1186.1MB/s)
>>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1189.4MB/s)
>>> -- [RFNoC Radio] Performing register loopback test... pass
>>> -- [RFNoC Radio] Performing register loopback test... pass
>>> -- [RFNoC Radio] Performing register loopback test... pass
>>> -- [RFNoC Radio] Performing register loopback test... pass
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>> ...
>>>
>>> Also when I try sync_to_gps, it says:
>>> ...
>>> Waiting for reference lock...LOCKED
>>> *WARNING: GPS not locked - time will not be accurate until locked *
>>> USRP time: 1136078288.000000000
>>> GPSDO time: 1136078288.000000000
>>>
>>> SUCCESS: USRP time synchronized to GPS time
>>>
>>> On querying gpsdo sensors soon after, I find that :
>>>
>>> USRP Locked to GPSDO 10 MHz Reference.
>>>
>>> GPS and UHD Device time are NOT aligned;
>>> last_pps: 9 vs gps: 1136078227. Trying to set the device time to GPS
>>> time...
>>> -- 1) catch time transition at pps edge
>>> -- 2) set times next pps (synchronously)
>>> last_pps: 1136078231 vs gps: 1136078231.
>>> GPS and UHD Device time are aligned.
>>> Printing available NMEA strings:
>>> GPS_GPGGA:
>>> $GPGGA,011711.00,0000.0000,N,00000.0000,E,0,99,1.0,0.0,M,0.0,M,,*5B
>>>
>>> GPS_GPRMC: $GPRMC,011711.00,V,0000.0000,N,00000.0000,E,0.0,0.0,010106,,*25
>>>
>>> GPS Epoch time at last PPS: 1136078232.00000 seconds
>>> UHD Device time last PPS: 1136078232.00000 seconds
>>> UHD Device time right now: 1136078232.27291 seconds
>>> PC Clock time: 1487756260 seconds
>>> ...
>>>
>>> Could anybody please help me with this? I suppose that when the gps is
>>> locked, it means that uhd is time aligned with gps? If so, I would also
>>> really like to know exactly how you permanently lock gps.
>>>
>>> Bests,
>>> Nikita Airee
>>>
>>>
>>> On Tue, Feb 21, 2017 at 8:20 PM, Nikita Airee <[email protected]>
>>> wrote:
>>>
>>>> Hi list,
>>>>
>>>> I have:
>>>>
>>>> Ubuntu 14.04
>>>>
>>>> UHD: 003.009.006-0-g122d5f8e
>>>>
>>>> USRP X310 with CBX20 + GPSDO
>>>>
>>>> I moved to UHD 3.9.6 very recently and since then have been facing the
>>>> following issue related to GPSDO:
>>>>
>>>> *UHD Error: GPS invalid reply "", assuming none available
>>>> No GPSDO found*
>>>>
>>>> UHD_3.11.0.git-28-gc66cb1ba would never throw up this message.
>>>>
>>>> Is this a known issue? If not, how do I use GPSDO?
>>>>
>>>> Bests,
>>>>
>>>> Nikita Airee
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> --
>> ? ?????????, ????? ??????.
>> Yours sincerely, Roman Olesyuk.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/1dbe2c30/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 28 Feb 2017 15:33:47 +0800 (GMT+08:00)
From: Bob <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] The difference between the samp_rate in GNU
Radio and Nyquist rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
Hello,
How to understand the sample rate in the DSP and the sample rate in the
hardware?
In generally, we use the USRP B210 to receive the RF signal, and finally get
the baseband signal (the signal carrier frequency is 0Hz)
and the lower IF signal (assuming the carrier frequency is 20kHz), then what
are these two cases of Nyquist rate?
And, then use USRP B210 to process this signal, and what is the sample rate in
the block? Is it Nyquist rate?
Finally, If a low-IF signal with a carrier frequency of 20 kHZ is
down-converted to a baseband signal (carrier frequency 0 Hz),
is it possible to implement blocks in GNU Radio using the C ++ language?
Thank you very much for your answers. I am looking forward to your reply as
soon as possible and as detailed as possible.
Thanks!
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/41c25f9a/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 28 Feb 2017 09:43:25 +0100
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: Jonathon Pendlum <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNoC] FPGA image is 2 bytes larger than
expected
Message-ID:
<ca+abmwkw55fcgn8-i+b872mohc8dgjdqjosiago7ligrqn8...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Dear Jonathon,
I tried what you told me. First, I ran setupenv.sh and then executed
make X310_RFNOC_HG.
The bistream was successfully generated as you can see by the messages below.
Creating bitstream...
Writing bitstream
/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-X310_RFNOC_HG/x300.bit...
INFO: [Vivado 12-1842] Bitgen Completed Successfully.
And again, it has the same size, 15878034, as the other bitstream I
generated with 2xDDCs, 2xDUCs and 1xFFT.
-rw-rw-r-- 1 zz4fap zz4fap 15878034 Feb 27 22:47 x300.bit
Could you, please, check why this difference exists? I mean, the
difference of 2 bytes between bitstreams.
While cheking the Makefile at src/uhd-fpga/usrp3/top/x300 I read what
I think could be a clue to the problem:
## build/usrp_<product>_fpga_<image_type>.bit: Configuration
bitstream with header
## build/usrp_<product>_fpga_<image_type>.bin: Configuration
bitstream without header
May the 2 bytes longer bitstream (.bit) contains a 2 bytes long header.
Thanks and Best Regards,
Felipe
On Mon, Feb 27, 2017 at 9:07 PM, Jonathon Pendlum
<[email protected]> wrote:
> Hi Felipe,
>
> Make sure to run 'source setupenv.sh' first before make X310_RFNOC_HG
>
> On Mon, Feb 27, 2017 at 1:31 PM, Felipe Augusto Pereira de Figueiredo
> <[email protected]> wrote:
>>
>> Hi Jonathon,
>>
>> Tried what you said but it didn't work. Could you please be a little
>> bit more specific about the command I should run. I got some error
>> regarding the syntax of the command you told me to run.
>> See output below.
>>
>> Thanks and Best Regards,
>>
>> Felipe
>>
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>> zz4fap@imecdesktop:~/rfnoc/src/uhd-fpga/usrp3/top/x300$ make X310_RFNOC_HG
>> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH= PART_ID=
>> BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1 X310=1
>> EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1
>> X310=1"
>> find:
>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/addsub_hls/solution/impl/verilog/':
>> No such file or directory
>> make[1]: Entering directory
>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
>> BUILDER: Checking tools...
>> * GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
>> * Python 2.7.6
>> * Vivado v2015.4.2 (64-bit)
>> ========================================================
>> BUILDER: Building IP ten_gig_eth_pcs_pma
>> ========================================================
>> BUILDER: Staging IP in build directory...
>> BUILDER: Reserving IP location:
>>
>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_gig_eth_pcs_pma
>> BUILDER: Retargeting IP to part /...
>> ERROR: Invalid target format. Must be
>> <arch>/<device>/<package>/<speedgrade>
>> BUILDER: Building IP...
>>
>> ****** Vivado v2015.4.2 (64-bit)
>> **** SW Build 1494164 on Fri Feb 26 04:18:54 MST 2016
>> **** IP Build 1491208 on Wed Feb 24 03:25:39 MST 2016
>> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
>>
>> source
>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/tools/scripts/viv_generate_ip.tcl
>> # set xci_file $::env(XCI_FILE) ;
>> # set part_name $::env(PART_NAME) ;
>> # set gen_example_proj $::env(GEN_EXAMPLE) ;
>> # set synth_ip $::env(SYNTH_IP) ;
>> # set ip_name [file rootname [file tail $xci_file]] ;
>> # file delete -force "$xci_file.out"
>> # create_project -part $part_name -in_memory -ip
>> WARNING: [#UNDEF] No parts matched ''
>> ERROR: [Coretcl 2-106] Specified part could not be found.
>> INFO: [Common 17-206] Exiting Vivado at Mon Feb 27 20:26:39 2017...
>> BUILDER: Releasing IP location:
>>
>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_gig_eth_pcs_pma
>> make[1]: ***
>> [/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
>> Error 1
>> make[1]: Leaving directory
>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
>> make: *** [X310_RFNOC_HG] Error 2
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> On Mon, Feb 27, 2017 at 7:55 PM, Jonathon Pendlum
>> <[email protected]> wrote:
>> > Hi Felipe,
>> >
>> > What if you build the same image by running make X310_RFNOC_HG in
>> > usrp3/top/x300? Is it still too large?
>> >
>> > On Mon, Feb 27, 2017 at 4:23 AM, Felipe Augusto Pereira de Figueiredo
>> > via
>> > USRP-users <[email protected]> wrote:
>> >>
>> >> Dear Sam,
>> >>
>> >> Many thanks for your tip, I've followed that and it worked. Just
>> >> changed the size of the macro with the expected bitstream size.
>> >>
>> >> I hope someone from Ettus can explain why that problem happens and if
>> >> it can be solved other way instead of tweaking the source code.
>> >>
>> >> Now the output of "uhd_usrp_probe" is like I had expected it to be.
>> >>
>> >> | | _____________________________________________________
>> >> | | /
>> >> | | | RFNoC blocks on this device:
>> >> | | |
>> >> | | | * DmaFIFO_0
>> >> | | | * Radio_0
>> >> | | | * Radio_1
>> >> | | | * DDC_0
>> >> | | | * DDC_1
>> >> | | | * DUC_0
>> >> | | | * DUC_1
>> >> | | | * FFT_0
>> >>
>> >> Thanks and Best Regards,
>> >>
>> >> Felipe
>> >>
>> >> On Fri, Feb 24, 2017 at 3:27 PM, Sam Carey <[email protected]> wrote:
>> >> > Howdy,
>> >> >
>> >> > I had this problem a while back. My workaround was to simply edit the
>> >> > image
>> >> > loader code so that it is OK with the larger file size.
>> >> > Just do a search for the smaller byte number in the uhd/host source
>> >> > code,
>> >> > change it to the larger byte number, and rebuild/reinstall uhd.
>> >> > Apparently, the byte count is not a strict requirement for image
>> >> > loading.
>> >> >
>> >> > You're the second other person I've seen with this problem.
>> >> > Maybe somebody could apply this change to the main branch or
>> >> > something?
>> >> >
>> >> > -Sam
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> USRP-users mailing list
>> >> [email protected]
>> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>> >
>
>
------------------------------
Message: 13
Date: Tue, 28 Feb 2017 12:57:40 +0300
From: Roman Olesyuk <[email protected]>
To: Nikita Airee <[email protected]>
Cc: Michael West <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] No GPSDO found message
Message-ID:
<camzegne5kzmnjkcj4at8h_zqw5oxwvdcg81d3zdix5pwtgu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
I use the latest UHD and FPGA image 3.10.1.1 and still experiece this
issue. My OS is Ubuntu 16.04.2, kernel 4.4.0-64-generic #85 x86_64, NI RIO
drivers 15.0.0. In addition I have unstable PPS/GPS LOCK behavior as
desribed in my previous email (e.g. stable PPS/GPS LOCK only when PC with
PCIe card is power off).
--
? ?????????, ????? ??????.
Yours sincerely, Roman Olesyuk.
28 ????. 2017 ?. 10:33 ???????????? "Nikita Airee" <[email protected]>
???????:
No Roman, I don't see such a behaviour in my USRP. Because in my case the
GPS refuses to lock but the PPS works fine blinking every second. Did you
try the patch? Does it work for you?
Michael, thanks for your suggestion! But it seems like it is not working
for me. It is entirely possible that I may be doing something wrong because
I have never patched a commit before. But the gps_ctrl.cpp file does change
at its location <working directory>/uhd/host/usrp/.
Also for when the gpsdo does work, ie with Ethernet, how do I get this
gpsdo to lock? I suppose simply running sync_to_gps should time and
reference lock my gpsdo?
Bests,
Nikita
On Tue, Feb 28, 2017 at 4:06 AM, Michael West <[email protected]>
wrote:
> Hi Nikita,
>
> Sadly, we know what this issue is. We sped up the X300 initialization so
> much that the firmware on the GPSDO does not have time to finish
> initializing before the detection code runs. The problem was fixed in the
> 3.10.1.1 release, but for some reason the fix did not get applied to the
> 3.9.6 release. The specific commit that is needed is
> https://github.com/EttusResearch/uhd/commit/63fcfb9574d64797
> b807a0dd356f5d7bfc48f082
>
> You can try to patch with that commit until we get it properly fixed. We
> should have it fixed on the LTS branch soon.
>
> Regards,
> Michael
>
> On Mon, Feb 27, 2017 at 12:27 PM, Roman Olesyuk via USRP-users <
> [email protected]> wrote:
>
>> Hi Nikita,
>>
>> I experience the same issue. In addition I observe the following
>> behavior. I checked LEDs on GPSDO board. Two green LEDs are on for
>> several seconds when I power on X310 and then they go off. If the PCIe
>> connector is plugged in, but PC is powered off, in about 30-60 seconds I
>> observe that PPS LED starts blinking once per seconds, and after about 10
>> minutes GPS LOCK LED (on GPSDO boards and on the front panel) goes on. This
>> is very stable behavior when PCIe IS PLUGGED IN, BUT PC IS OFF. I can get
>> very stable GPS lock (the LED is on as long as I can observe) and PPS is
>> always blinking. If I use 1Gbps network connection (with PCIe connector
>> unplugged) or if I use PCIe connection (just power on X310, then power on
>> PC), I do not see PPS blinking even after several minutes. Sometimes PPS
>> LED goes blinking and after 10-60 seconds it goes off again. Very rarely I
>> can see PPS blinking for several minutes and GPS LOCK LED is even rarer
>> (almost never see it). The behaviors are almost the same in PCIe and 1Gbps
>> modes. So it looks for me like some FPGA/GPSDO initialization problem.
>>
>> Can you confirm my observations?
>>
>> --
>> Yours sincerely, Roman Olesyuk.
>>
>> 2017-02-27 13:43 GMT+03:00 Nikita Airee via USRP-users <
>> [email protected]>:
>>
>>> Hi list,
>>>
>>> the information I had provided might not have been enough. So here is
>>> some more:
>>>
>>> My X310 has internal GPSDO. This is visible to UHD when I perform
>>> uhd_usrp_probe provided it is connected to my laptop using Gigabit ethernet:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>>
>>> -- X300 initialization sequence...
>>> -- Determining maximum frame size... 1472 bytes.
>>> -- Setup basic communication...
>>> -- Loading values from EEPROM...
>>> -- Setup RF frontend clocking...
>>> -- Radio 1x clock:200
>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>> Firmware Rev 0.929a*
>>> -- Initialize Radio0 control...
>>> -- Performing register loopback test... pass
>>> -- Initialize Radio1 control...
>>> -- Performing register loopback test... pass
>>> ...
>>>
>>> However, when I use PCI Express for connection, it says:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>>
>>> -- X300 initialization sequence...
>>> -- Connecting to niusrpriorpc at localhost:5444...
>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>> rp_x310_fpga_HGS.lvbitx...
>>> -- Setup basic communication...
>>> -- Loading values from EEPROM...
>>> -- Setup RF frontend clocking...
>>> -- Radio 1x clock:200
>>> --
>>>
>>>
>>> *Detecting internal GPSDO.... UHD Error: GPS invalid reply "",
>>> assuming none availableNo GPSDO found*
>>> -- Initialize Radio0 control...
>>> -- Performing register loopback test... pass
>>> -- Initialize Radio1 control...
>>> -- Performing register loopback test... pass
>>> ...
>>>
>>> When the same USRP is connected to a laptop with a different UHD version
>>> via PCIe, I get:
>>>
>>> linux; GNU C++ version 4.8.2; Boost_106000; UHD_3.11.0.git-28-gc66cb1ba
>>>
>>> -- X300 initialization sequence...
>>> -- Connecting to niusrpriorpc at localhost:5444...
>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>> rp_x310_fpga_HG.lvbitx...
>>> -- Setup basic communication...
>>> -- Loading values from EEPROM...
>>> -- Setup RF frontend clocking...
>>> -- Radio 1x clock:200
>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>> Firmware Rev 0.929a*
>>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1186.1MB/s)
>>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1189.4MB/s)
>>> -- [RFNoC Radio] Performing register loopback test... pass
>>> -- [RFNoC Radio] Performing register loopback test... pass
>>> -- [RFNoC Radio] Performing register loopback test... pass
>>> -- [RFNoC Radio] Performing register loopback test... pass
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>> ...
>>>
>>> Also when I try sync_to_gps, it says:
>>> ...
>>> Waiting for reference lock...LOCKED
>>> *WARNING: GPS not locked - time will not be accurate until locked *
>>> USRP time: 1136078288.000000000
>>> GPSDO time: 1136078288.000000000
>>>
>>> SUCCESS: USRP time synchronized to GPS time
>>>
>>> On querying gpsdo sensors soon after, I find that :
>>>
>>> USRP Locked to GPSDO 10 MHz Reference.
>>>
>>> GPS and UHD Device time are NOT aligned;
>>> last_pps: 9 vs gps: 1136078227. Trying to set the device time to GPS
>>> time...
>>> -- 1) catch time transition at pps edge
>>> -- 2) set times next pps (synchronously)
>>> last_pps: 1136078231 vs gps: 1136078231.
>>> GPS and UHD Device time are aligned.
>>> Printing available NMEA strings:
>>> GPS_GPGGA:
>>> $GPGGA,011711.00,0000.0000,N,00000.0000,E,0,99,1.0,0.0,M,0.0,M,,*5B
>>>
>>> GPS_GPRMC: $GPRMC,011711.00,V,0000.0000,N,00000.0000,E,0.0,0.0,010106,,*25
>>>
>>> GPS Epoch time at last PPS: 1136078232.00000 seconds
>>> UHD Device time last PPS: 1136078232.00000 seconds
>>> UHD Device time right now: 1136078232.27291 seconds
>>> PC Clock time: 1487756260 seconds
>>> ...
>>>
>>> Could anybody please help me with this? I suppose that when the gps is
>>> locked, it means that uhd is time aligned with gps? If so, I would also
>>> really like to know exactly how you permanently lock gps.
>>>
>>> Bests,
>>> Nikita Airee
>>>
>>>
>>> On Tue, Feb 21, 2017 at 8:20 PM, Nikita Airee <[email protected]>
>>> wrote:
>>>
>>>> Hi list,
>>>>
>>>> I have:
>>>>
>>>> Ubuntu 14.04
>>>>
>>>> UHD: 003.009.006-0-g122d5f8e
>>>>
>>>> USRP X310 with CBX20 + GPSDO
>>>>
>>>> I moved to UHD 3.9.6 very recently and since then have been facing the
>>>> following issue related to GPSDO:
>>>>
>>>> *UHD Error: GPS invalid reply "", assuming none available
>>>> No GPSDO found*
>>>>
>>>> UHD_3.11.0.git-28-gc66cb1ba would never throw up this message.
>>>>
>>>> Is this a known issue? If not, how do I use GPSDO?
>>>>
>>>> Bests,
>>>>
>>>> Nikita Airee
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> --
>> ? ?????????, ????? ??????.
>> Yours sincerely, Roman Olesyuk.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/687ecf90/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 28 Feb 2017 11:06:38 +0100
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: [USRP-users] Changing system date and time with burst
transmission
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear all,
I just discovered by chance that modifying the system date and time
while transmitting a burst causes a transmission error: the send()
function returns prematurely with an indication that some samples have
not been transmitted.
To replicate:
1. run tx_bursts, e.g.:
tx_bursts --repeat --rep-delay 0.1 --nsamps=4960 --rate 500000
2. meanwhile, change the system date and time, e.g. (format is month day
hour minute):
date -u 02281102
I have verified this with B200mini (3.9.5) and X300 (3.10.1.1).
The error does *not* occur with continuous transmission.
I could not find this mentioned in the API manual. If this is an
intended behavior and it is not documented, then I suggest to update the
documentation.
Best regards,
Claudio
--
Claudio Cicconetti, PhD
Software Engineer - MBI S.r.l. - Pisa, Italy
------------------------------
Message: 15
Date: Tue, 28 Feb 2017 15:40:55 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: [USRP-users] Wireless data transfer
Message-ID:
<cabldf_fhsuewfammzespt8_nk_4g7bb__ovogzjtcbmas+b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi to all,
I want to create a distributed sensor network by using 2 or 3 USRP X310s(4
to 6 channels in total). The distance between the devices will be large.
So, I will synchronize them by GPS(GPSDO). But, I do not know how to
control them. I want to start recording a stream and then stop the
recording at the same instant.
Is there any way you can suggest for me? Is there any source I can read? I
can not use long cables so what I am looking for is a wireless solution.
Best regards,
Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/71c76321/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 28 Feb 2017 13:04:29 +0000
From: "Nigel Steed (XENINT)" <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd::io_error
Message-ID:
<am4pr0201mb16039fa744b625e718d2ce8491...@am4pr0201mb1603.eurprd02.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi David,
Thought I would let you know. We replaced with a cheaper hub (only USB2) and we
no longer get this error ?
Thanks,
Nigel
From: Derek Kozel [mailto:[email protected]]
Sent: Wednesday, February 22, 2017 6:22 PM
To: Nigel Steed (XENINT) <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] uhd::io_error
Hi Nigel,
Do you have external DC power supplied to each B210? To the hub (how much
current per port in that case)?
How much total bandwidth are you trying to transfer? I don't have a number but
could imagine there being overhead to the hub and (de)muxing of the
connections. Is it an apparently good quality hub?
Thanks,
Derek
On Wed, Feb 22, 2017 at 9:59 AM, Nigel Steed (XENINT) via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi All,
Has anyone experienced this error ? I am connected to 4 B210?s via a USB3 hub
and quite regularly I lose connection with the following error output from
GNURadio:
terminate called after throwing an instance of 'uhd::io_error'
what(): EnvironmentError: IOError: usb tx2 transfer status:
LIBUSB_TRANSFER_ERROR/
So far this seems to be linked to when I am regularly sending frequency re-tune
message into the message port of the UHD Source blocks.
I am using UHD 3.10.1.1 and GNURadio 3.7.10.1
Any comments much appreciated.
Nigel
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/b8df96b5/attachment-0001.html>
------------------------------
Message: 17
Date: Tue, 28 Feb 2017 13:08:03 +0000
From: Stefano Bettelli <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <1C28F8990859A84D809CFC7AB0D38942A85281@lhreml502-mbx>
Content-Type: text/plain; charset="iso-8859-1"
Dear all,
I want to add some findings to this very interesting thread.
During the last week I have been playing with the source of the benchmark_rate
example program.
In the following examples I will be transmitting at 1MS/s with sc16 for both
cpu and otw, and TWO channels.
If I run the "stock" benchmark program (which will use 496 samples per buffer
per channel) and I printout the time it takes to complete the various calls to
send(), I have the following evolution:
10 to 20 calls are executed with times strongly fluctuating in the range 5 - 20
microseconds (transient?)
Several thousand calls are then executed with quite stable call times of 3-5
microseconds
Then, as we hit about 16M samples sent (64MB) every 8th call will return after
3-4 milliseconds
So, clearly send() writes to a local buffer ring on the server, then blocks
when it is filled.
As already noted, it is not necessary to use tx_stream->get_max_num_samps() as
the number of samples per send buffer. If we provide larger buffers the UHD
driver will split them for us. So I tried with 2^18 = 262144 samples per buffer:
The first call executes in about 2.3 milliseconds
The following 30 execute in about 2.0 milliseconds
Then, as we hit the 16M samples mark, the call time jumps to about 261.6
milliseconds.
So, same pattern, same behaviour, but a factor 1000 more in the number of
samples per buffer per channel.
Then, I tried the same transfer with a variable number of samples, choosing
between N and 262144 at every send().
The result is that, without any pattern apparent to me, the benchmark throws a
lot of U's, unless N is very close to the max value (in my case N ~ 220000, but
I am not fully sure, it might just be that I didn't wait enough).
Given that we have talked to our USRPs X310 in 2ch mode at 50MS/s without
errors, I exclude that we are limited by any piece of hardware here. So, my
question is:
Is this evidence of a bug / deficiency in the algorithm that splits send()
buffers inside the UHD driver? Or is there something I did not understand?
Given that the stock benchmark tool fails with (fake?) underruns at low rates
when the --random option is used, I would lean towards the first case.
Is there any document where the internals of the UHD driver are explained in
detail?
Thanks,
Stefano
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Claudio Cicconetti via USRP-users
Sent: Montag, 27. Februar 2017 10:01
To: [email protected]
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Dear all,
I have been struggling for a few months to do continuous streaming of
100 MS/s towards an X300 with a single 10 GbE on Linux (Ubuntu).
My mission is not yet fully accomplished (see below) but I have a few findings
to share that may be useful to others:
- data _must_ be ready when you issue the send() command: no way you can do
processing between consecutive calls to send()
- assigning real-time scheduling priority to the sending thread: surely does
not harm, but also does _not_ save you from underruns if there are concurrent
threads on the same core, even if they have best-effort priority
- CPU speed is important but, again, is _not_ a life-saver: I have same
performance, in terms of rate of underruns, with Intel E5-2660 @ 2.60 GHz and
Intel i7-6700K @ 4.00 GHz
- fiddling with OS (ie. changing CPU frequency scaling, locking thread to a
core, disabling IRQ balancing, disabling unused cores) very easily leads to a
_worse_ performance; on the other hand, I never managed to get any noticeable
improvements out of these tricks
- NIC interrupt coalescing _must_ be enabled in my case (Intel 82599ES):
with interrupt coalescing enabled I have about 8000 interrupts/s, which is much
below the maximum my CPU+OS can sustain (easily 6-7x that)
- for all other network-related configuration the default is sufficient,
including the number of TX descriptors and network buffers
- the size of the vectors passed to send() does not influence performance; in
particular, it does _not_ help to split the vector into chunks with a size that
is a multiple of the maximum samples per packet
The only remaining issue I have is that I get sporadic underruns (in the order
of one every several minutes, on average) that are periodic with base 10
seconds within 0.01 s. For instance, first underrun at 08:22:54.83, next could
be at 08:31:04.83 and then 08:34:24.83 and so on.
Since the only non-vital daemon running on the PC is sshd, I wonder whether it
is something related to the OS (Google did help me pin-pointing the issue) or
to the UHD (something like "every 1 billions samples do something special").
Best regards,
Claudio
On 02/24/2017 10:47 PM, Martin Braun via USRP-users wrote:
> Stefano,
>
> let me just add some statements to this:
>
> - In general, it's harder to create data at high rates from a PC and
> then receive it on the FPGA than vice versa. On top of what Ian said,
> regular OSes + GPPs have a lot of scheduling latency/randomness. At
> 100 Msps, on the 3.10 release cycle, you will get an underrun if you
> miss a chance to transmit a data packet by a small number of ?s (the
> actual value is hard to tell, but we're speaking of two-digit orders
> of magnitude). But even 100 ?s scheduling delays are possible. On my
> machine, I need to tune some knobs until I get this kind of
> performance, such as using "performance" CPU governors (I also
> increase the number of Tx descriptors with ethtool -G, but I'm not sure
> that's as influential.
> I would still recommend you bump it all the way up to 4096).
> - With dual-channel, this gets exacerbated because you have multiple
> threads competing for timely access to the transport device. I would
> assume that with dual cables, that's not true, but who knows what's
> going on internally.
>
> - On 3.10, we are currently *worse off* than on 3.9 in terms of
> streaming performance. There's a whole bunch of reasons for that, but
> the good news is we're currently working on some fixes to improve
> streaming performance. With the current 3.10 release, it's hard to run
> at 200 Msps from GNU Radio, for instance. If your software has
> comparable rates to benchmark_rate, then you're probably not going to
> be affected by this anyway.
>
> -- M
>
>
> On 02/23/2017 12:05 PM, Ian Buckley via USRP-users wrote:
>> Stefano
>> I'll take a stab at explaining the probable background on this. UHD
>> uses credit based flow control to avoid overflowing buffers in the
>> USRP. When you prepare to start a new TX operation the TX buffer
>> inside the USRP is completely empty and can fill at wire rate speed.
>> At some point it may/will become full and at this point the credit
>> based flow control algorithm will pace the data over the network such
>> that it approximates the TX rate over the air (Which is hard real
>> time). When the actual TX over the air operation starts relative to
>> when the buffering of data commences can yield some challenging situations.
>> If the TX operation starts as soon as the first samples of data reach
>> the TX DSP (i.e buffer is practically empty) then it runs the very
>> real risk of underflowing because it consumes data at a constant rate
>> but data delivered from the host tends to be bursty and jitter in
>> delivery (since the host is non-realtime in design) and also the main
>> sample buffer is a DRAM with a single port to which access is
>> arbitrated adding more jitter as ingress and egress compete for
>> access. Typically UHD deals with the "buffer practically empty" case
>> by starting streaming the data to the USRP well in advance of a
>> scheduled TX operation start time allowing time for buffers to fill
>> somewhat, but the buffer access arbitration is tricky at startup
>> since you have a corner case situation with data streaming in at wire
>> speeds rather than rate limited by the credit algorithm plus data
>> being drained at the configured sample rate by the TX DSP. What you
>> are probably therefore seeing is underflows (@ the DSP) during the
>> initial fill of the buffer as internal bandwidth is transiently
>> exceeded, and then smoother operation as the bit rate over the
>> network drops back to approximate the transmission sample rate once the
>> buffer is full.
>>
>> I'm a couple of years stale on the internal implementation details of
>> this now, but that is the gist of the challenge.
>> -Ian
>>
>>
>>
>> On Feb 23, 2017, at 11:02 AM, Stefano Bettelli via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> Hi,
>>>
>>> We are still in the process of extracting maximum performance from
>>> our USRP X310's, and we have a weird problem with transmission of
>>> data, which does not appear while reading data. The USRP that I am
>>> considering has two 10G fibre connections, and uses the XG FPGA
>>> firmware (we use the latest UHD, 3.10.1.1). The software developed
>>> by us and the benchmark_rate example agree on both RX and TX, so I
>>> will report only the results with the benchmark_rate. RX works
>>> nicely, we have 800MB/s on each fibre:
>>>
>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>> --duration 30 --channel "0,1" --rx_otw sc16 --rx_cpu sc16 --rx_rate
>>> 200e6 linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_003.010.001.001-release [...] Testing receive rate 200.000000
>>> Msps on 2 channels Benchmark rate summary:
>>> Num received samples: 12000120052
>>> Num dropped samples: 0
>>> Num overflows detected: 0
>>> Num transmitted samples: 0
>>> Num sequence errors: 0
>>> Num underflows detected: 0
>>> Num late commands: 0
>>> Num timeouts: 0
>>>
>>> However, TX shows a lot of problems for rates larger that 50MS/s,
>>> for
>>> instance:
>>>
>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>> --duration 30 --channel "0,1" --tx_otw sc16 --tx_cpu sc16 --tx_rate
>>> 100e6 linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_003.010.001.001-release [.] Testing transmit rate 100.000000
>>> Msps on 2 channels [. throws a lot of U's .] Benchmark rate summary:
>>> Num received samples: 0
>>> Num dropped samples: 0
>>> Num overflows detected: 0
>>> Num transmitted samples: 6013212352
>>> Num sequence errors: 0
>>> Num underflows detected: 18509
>>> Num late commands: 0
>>> Num timeouts: 0
>>>
>>> Eventually there is transmission at 400MB/s on both fibres, but we
>>> lose the initial part. Achieving tx_rate=200e6 does not work at all
>>> (the USRP stops replying). By observing the threads with htop we see
>>> that one thread approaches 80-90% of CPU usage. By comparison with
>>> our program, where we can identify the threads, I infer that it is
>>> the thread containing the tx_streamer->send() call; this call seems
>>> to be very heavy. All this looks strange because the Ethernet fibres
>>> are exactly the same, and the rest of the system seems to be
>>> configured in the same way for RX and TX:
>>>
>>> Both network interfaces have MTU=9000:
>>> ifconfig | grep enp129 -A3
>>> enp129s0f0 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2c
>>> inet addr:192.168.40.1 Bcast:192.168.40.255 Mask:255.255.255.0
>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2c/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>> --
>>> enp129s0f1 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2d
>>> inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0
>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2d/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>>
>>> Both RX and TX have large network buffer sizes sysctl -a | grep
>>> net.core.*mem_max net.core.rmem_max = 33554432 net.core.wmem_max =
>>> 33554432
>>>
>>> both RX and TX have the same number of descriptors (also on the
>>> other
>>> card):
>>> ethtool -g enp129s0f0
>>> Ring parameters for enp129s0f0:
>>> Pre-set maximums:
>>> RX: 4096
>>> RX Mini: 0
>>> RX Jumbo: 0
>>> TX: 4096
>>> Current hardware settings:
>>> RX: 512
>>> RX Mini: 0
>>> RX Jumbo: 0
>>> TX: 512
>>>
>>> Interrupt coalescing seems not to be available on these cards. The
>>> server is also quite powerful, 2xXeon with 48 cores in total, and
>>> 128GB of memory. Cores run at at least 3GHz. Can you suggest any
>>> idea to help us debugging this problem? Thanks in advance,
>>>
>>> Best regards/Mit freundlichen Gruessen,
>>>
>>> Stefano Bettelli
>>> Senior research engineer
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> 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
------------------------------
Message: 18
Date: Tue, 28 Feb 2017 13:55:46 +0000 (UTC)
From: [email protected]
To: Stefano Bettelli <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Stephano,
I have spent some time in the packetization code and it is well done, cant see
any obvious ways to improve efficiency within the host UHD code...
I havent looked at the --random flag, but if it cant keep the buffers full
based on the tx sample rate because it chooses a streak of small N (too small
to satisfy the data requirements), then underruns will occur.
----- Original Message -----
From: "Stefano Bettelli via USRP-users" <[email protected]>
To: "usrp-users" <[email protected]>
Sent: Tuesday, February 28, 2017 8:08:03 AM
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Dear all,
I want to add some findings to this very interesting thread.
During the last week I have been playing with the source of the benchmark_rate
example program.
In the following examples I will be transmitting at 1MS/s with sc16 for both
cpu and otw, and TWO channels.
If I run the "stock" benchmark program (which will use 496 samples per buffer
per channel) and I printout the time it takes to complete the various calls to
send(), I have the following evolution:
10 to 20 calls are executed with times strongly fluctuating in the range 5 - 20
microseconds (transient?)
Several thousand calls are then executed with quite stable call times of 3-5
microseconds
Then, as we hit about 16M samples sent (64MB) every 8th call will return after
3-4 milliseconds
So, clearly send() writes to a local buffer ring on the server, then blocks
when it is filled.
As already noted, it is not necessary to use tx_stream->get_max_num_samps() as
the number of samples per send buffer. If we provide larger buffers the UHD
driver will split them for us. So I tried with 2^18 = 262144 samples per
buffer:
The first call executes in about 2.3 milliseconds
The following 30 execute in about 2.0 milliseconds
Then, as we hit the 16M samples mark, the call time jumps to about 261.6
milliseconds.
So, same pattern, same behaviour, but a factor 1000 more in the number of
samples per buffer per channel.
Then, I tried the same transfer with a variable number of samples, choosing
between N and 262144 at every send().
The result is that, without any pattern apparent to me, the benchmark throws a
lot of U's, unless N is very close to the max value (in my case N ~ 220000, but
I am not fully sure, it might just be that I didn't wait enough).
Given that we have talked to our USRPs X310 in 2ch mode at 50MS/s without
errors, I exclude that we are limited by any piece of hardware here. So, my
question is:
Is this evidence of a bug / deficiency in the algorithm that splits send()
buffers inside the UHD driver? Or is there something I did not understand?
Given that the stock benchmark tool fails with (fake?) underruns at low rates
when the --random option is used, I would lean towards the first case.
Is there any document where the internals of the UHD driver are explained in
detail?
Thanks,
Stefano
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Claudio Cicconetti via USRP-users
Sent: Montag, 27. Februar 2017 10:01
To: [email protected]
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Dear all,
I have been struggling for a few months to do continuous streaming of
100 MS/s towards an X300 with a single 10 GbE on Linux (Ubuntu).
My mission is not yet fully accomplished (see below) but I have a few findings
to share that may be useful to others:
- data _must_ be ready when you issue the send() command: no way you can do
processing between consecutive calls to send()
- assigning real-time scheduling priority to the sending thread: surely does
not harm, but also does _not_ save you from underruns if there are concurrent
threads on the same core, even if they have best-effort priority
- CPU speed is important but, again, is _not_ a life-saver: I have same
performance, in terms of rate of underruns, with Intel E5-2660 @ 2.60 GHz and
Intel i7-6700K @ 4.00 GHz
- fiddling with OS (ie. changing CPU frequency scaling, locking thread to a
core, disabling IRQ balancing, disabling unused cores) very easily leads to a
_worse_ performance; on the other hand, I never managed to get any noticeable
improvements out of these tricks
- NIC interrupt coalescing _must_ be enabled in my case (Intel 82599ES):
with interrupt coalescing enabled I have about 8000 interrupts/s, which is much
below the maximum my CPU+OS can sustain (easily 6-7x that)
- for all other network-related configuration the default is sufficient,
including the number of TX descriptors and network buffers
- the size of the vectors passed to send() does not influence performance; in
particular, it does _not_ help to split the vector into chunks with a size that
is a multiple of the maximum samples per packet
The only remaining issue I have is that I get sporadic underruns (in the order
of one every several minutes, on average) that are periodic with base 10
seconds within 0.01 s. For instance, first underrun at 08:22:54.83, next could
be at 08:31:04.83 and then 08:34:24.83 and so on.
Since the only non-vital daemon running on the PC is sshd, I wonder whether it
is something related to the OS (Google did help me pin-pointing the issue) or
to the UHD (something like "every 1 billions samples do something special").
Best regards,
Claudio
On 02/24/2017 10:47 PM, Martin Braun via USRP-users wrote:
> Stefano,
>
> let me just add some statements to this:
>
> - In general, it's harder to create data at high rates from a PC and
> then receive it on the FPGA than vice versa. On top of what Ian said,
> regular OSes + GPPs have a lot of scheduling latency/randomness. At
> 100 Msps, on the 3.10 release cycle, you will get an underrun if you
> miss a chance to transmit a data packet by a small number of ?s (the
> actual value is hard to tell, but we're speaking of two-digit orders
> of magnitude). But even 100 ?s scheduling delays are possible. On my
> machine, I need to tune some knobs until I get this kind of
> performance, such as using "performance" CPU governors (I also
> increase the number of Tx descriptors with ethtool -G, but I'm not sure
> that's as influential.
> I would still recommend you bump it all the way up to 4096).
> - With dual-channel, this gets exacerbated because you have multiple
> threads competing for timely access to the transport device. I would
> assume that with dual cables, that's not true, but who knows what's
> going on internally.
>
> - On 3.10, we are currently *worse off* than on 3.9 in terms of
> streaming performance. There's a whole bunch of reasons for that, but
> the good news is we're currently working on some fixes to improve
> streaming performance. With the current 3.10 release, it's hard to run
> at 200 Msps from GNU Radio, for instance. If your software has
> comparable rates to benchmark_rate, then you're probably not going to
> be affected by this anyway.
>
> -- M
>
>
> On 02/23/2017 12:05 PM, Ian Buckley via USRP-users wrote:
>> Stefano
>> I'll take a stab at explaining the probable background on this. UHD
>> uses credit based flow control to avoid overflowing buffers in the
>> USRP. When you prepare to start a new TX operation the TX buffer
>> inside the USRP is completely empty and can fill at wire rate speed.
>> At some point it may/will become full and at this point the credit
>> based flow control algorithm will pace the data over the network such
>> that it approximates the TX rate over the air (Which is hard real
>> time). When the actual TX over the air operation starts relative to
>> when the buffering of data commences can yield some challenging situations.
>> If the TX operation starts as soon as the first samples of data reach
>> the TX DSP (i.e buffer is practically empty) then it runs the very
>> real risk of underflowing because it consumes data at a constant rate
>> but data delivered from the host tends to be bursty and jitter in
>> delivery (since the host is non-realtime in design) and also the main
>> sample buffer is a DRAM with a single port to which access is
>> arbitrated adding more jitter as ingress and egress compete for
>> access. Typically UHD deals with the "buffer practically empty" case
>> by starting streaming the data to the USRP well in advance of a
>> scheduled TX operation start time allowing time for buffers to fill
>> somewhat, but the buffer access arbitration is tricky at startup
>> since you have a corner case situation with data streaming in at wire
>> speeds rather than rate limited by the credit algorithm plus data
>> being drained at the configured sample rate by the TX DSP. What you
>> are probably therefore seeing is underflows (@ the DSP) during the
>> initial fill of the buffer as internal bandwidth is transiently
>> exceeded, and then smoother operation as the bit rate over the
>> network drops back to approximate the transmission sample rate once the
>> buffer is full.
>>
>> I'm a couple of years stale on the internal implementation details of
>> this now, but that is the gist of the challenge.
>> -Ian
>>
>>
>>
>> On Feb 23, 2017, at 11:02 AM, Stefano Bettelli via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> Hi,
>>>
>>> We are still in the process of extracting maximum performance from
>>> our USRP X310's, and we have a weird problem with transmission of
>>> data, which does not appear while reading data. The USRP that I am
>>> considering has two 10G fibre connections, and uses the XG FPGA
>>> firmware (we use the latest UHD, 3.10.1.1). The software developed
>>> by us and the benchmark_rate example agree on both RX and TX, so I
>>> will report only the results with the benchmark_rate. RX works
>>> nicely, we have 800MB/s on each fibre:
>>>
>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>> --duration 30 --channel "0,1" --rx_otw sc16 --rx_cpu sc16 --rx_rate
>>> 200e6 linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_003.010.001.001-release [...] Testing receive rate 200.000000
>>> Msps on 2 channels Benchmark rate summary:
>>> Num received samples: 12000120052
>>> Num dropped samples: 0
>>> Num overflows detected: 0
>>> Num transmitted samples: 0
>>> Num sequence errors: 0
>>> Num underflows detected: 0
>>> Num late commands: 0
>>> Num timeouts: 0
>>>
>>> However, TX shows a lot of problems for rates larger that 50MS/s,
>>> for
>>> instance:
>>>
>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>> --duration 30 --channel "0,1" --tx_otw sc16 --tx_cpu sc16 --tx_rate
>>> 100e6 linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_003.010.001.001-release [.] Testing transmit rate 100.000000
>>> Msps on 2 channels [. throws a lot of U's .] Benchmark rate summary:
>>> Num received samples: 0
>>> Num dropped samples: 0
>>> Num overflows detected: 0
>>> Num transmitted samples: 6013212352
>>> Num sequence errors: 0
>>> Num underflows detected: 18509
>>> Num late commands: 0
>>> Num timeouts: 0
>>>
>>> Eventually there is transmission at 400MB/s on both fibres, but we
>>> lose the initial part. Achieving tx_rate=200e6 does not work at all
>>> (the USRP stops replying). By observing the threads with htop we see
>>> that one thread approaches 80-90% of CPU usage. By comparison with
>>> our program, where we can identify the threads, I infer that it is
>>> the thread containing the tx_streamer->send() call; this call seems
>>> to be very heavy. All this looks strange because the Ethernet fibres
>>> are exactly the same, and the rest of the system seems to be
>>> configured in the same way for RX and TX:
>>>
>>> Both network interfaces have MTU=9000:
>>> ifconfig | grep enp129 -A3
>>> enp129s0f0 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2c
>>> inet addr:192.168.40.1 Bcast:192.168.40.255 Mask:255.255.255.0
>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2c/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>> --
>>> enp129s0f1 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2d
>>> inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0
>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2d/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>>
>>> Both RX and TX have large network buffer sizes sysctl -a | grep
>>> net.core.*mem_max net.core.rmem_max = 33554432 net.core.wmem_max =
>>> 33554432
>>>
>>> both RX and TX have the same number of descriptors (also on the
>>> other
>>> card):
>>> ethtool -g enp129s0f0
>>> Ring parameters for enp129s0f0:
>>> Pre-set maximums:
>>> RX: 4096
>>> RX Mini: 0
>>> RX Jumbo: 0
>>> TX: 4096
>>> Current hardware settings:
>>> RX: 512
>>> RX Mini: 0
>>> RX Jumbo: 0
>>> TX: 512
>>>
>>> Interrupt coalescing seems not to be available on these cards. The
>>> server is also quite powerful, 2xXeon with 48 cores in total, and
>>> 128GB of memory. Cores run at at least 3GHz. Can you suggest any
>>> idea to help us debugging this problem? Thanks in advance,
>>>
>>> Best regards/Mit freundlichen Gruessen,
>>>
>>> Stefano Bettelli
>>> Senior research engineer
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/75f0659d/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 28 Feb 2017 15:18:21 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Wireless data transfer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Ali,
http://files.ettus.com/manual/page_gpsdo_x3x0.html
explains the time-synchronization procedure. After that, you just have
to start and stop streaming using command times. See the
rx_timed_samples and tx_timed_samples examples within the UHD source tree.
Best regards,
Marcus
On 02/28/2017 01:40 PM, do ber via USRP-users wrote:
> Hi to all,
>
> I want to create a distributed sensor network by using 2 or 3 USRP
> X310s(4 to 6 channels in total). The distance between the devices will
> be large. So, I will synchronize them by GPS(GPSDO). But, I do not
> know how to control them. I want to start recording a stream and then
> stop the recording at the same instant.
>
> Is there any way you can suggest for me? Is there any source I can
> read? I can not use long cables so what I am looking for is a wireless
> solution.
>
> Best regards,
> Ali
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/77a1befc/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 28 Feb 2017 14:18:05 +0000
From: Stefano Bettelli <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <1C28F8990859A84D809CFC7AB0D38942A852B4@lhreml502-mbx>
Content-Type: text/plain; charset="utf-8"
No, that?s the entire point of my mail.
It doesn?t underrun because N is small.
I can choose N randomly limited between 200?000 and 260?000 and it will still
fail.
It seems it doesn?t depend on the actual value, only about its variance.
I choose such a small rate (1MS/s) exactly to prove the point.
In another example that I have I can transfer 20MB of data into the UHD, send
the end-of-burst packet, wait a bit, and only after 200ms or more I start
receiving the U?s. But I may be extrapolating from too small a number of
examples. Is there any sort of experiment that I can run to discriminate
between a real underrun and a bug?
From: [email protected] [mailto:[email protected]]
Sent: Dienstag, 28. Februar 2017 14:56
To: Stefano Bettelli <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Hi Stephano,
I have spent some time in the packetization code and it is well done, cant see
any obvious ways to improve efficiency within the host UHD code...
I havent looked at the --random flag, but if it cant keep the buffers full
based on the tx sample rate because it chooses a streak of small N (too small
to satisfy the data requirements), then underruns will occur.
________________________________
From: "Stefano Bettelli via USRP-users"
<[email protected]<mailto:[email protected]>>
To: "usrp-users" <[email protected]<mailto:[email protected]>>
Sent: Tuesday, February 28, 2017 8:08:03 AM
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Dear all,
I want to add some findings to this very interesting thread.
During the last week I have been playing with the source of the benchmark_rate
example program.
In the following examples I will be transmitting at 1MS/s with sc16 for both
cpu and otw, and TWO channels.
If I run the "stock" benchmark program (which will use 496 samples per buffer
per channel) and I printout the time it takes to complete the various calls to
send(), I have the following evolution:
10 to 20 calls are executed with times strongly fluctuating in the range 5 - 20
microseconds (transient?)
Several thousand calls are then executed with quite stable call times of 3-5
microseconds
Then, as we hit about 16M samples sent (64MB) every 8th call will return after
3-4 milliseconds
So, clearly send() writes to a local buffer ring on the server, then blocks
when it is filled.
As already noted, it is not necessary to use tx_stream->get_max_num_samps() as
the number of samples per send buffer. If we provide larger buffers the UHD
driver will split them for us. So I tried with 2^18 = 262144 samples per buffer:
The first call executes in about 2.3 milliseconds
The following 30 execute in about 2.0 milliseconds
Then, as we hit the 16M samples mark, the call time jumps to about 261.6
milliseconds.
So, same pattern, same behaviour, but a factor 1000 more in the number of
samples per buffer per channel.
Then, I tried the same transfer with a variable number of samples, choosing
between N and 262144 at every send().
The result is that, without any pattern apparent to me, the benchmark throws a
lot of U's, unless N is very close to the max value (in my case N ~ 220000, but
I am not fully sure, it might just be that I didn't wait enough).
Given that we have talked to our USRPs X310 in 2ch mode at 50MS/s without
errors, I exclude that we are limited by any piece of hardware here. So, my
question is:
Is this evidence of a bug / deficiency in the algorithm that splits send()
buffers inside the UHD driver? Or is there something I did not understand?
Given that the stock benchmark tool fails with (fake?) underruns at low rates
when the --random option is used, I would lean towards the first case.
Is there any document where the internals of the UHD driver are explained in
detail?
Thanks,
Stefano
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Claudio Cicconetti via USRP-users
Sent: Montag, 27. Februar 2017 10:01
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Dear all,
I have been struggling for a few months to do continuous streaming of
100 MS/s towards an X300 with a single 10 GbE on Linux (Ubuntu).
My mission is not yet fully accomplished (see below) but I have a few findings
to share that may be useful to others:
- data _must_ be ready when you issue the send() command: no way you can do
processing between consecutive calls to send()
- assigning real-time scheduling priority to the sending thread: surely does
not harm, but also does _not_ save you from underruns if there are concurrent
threads on the same core, even if they have best-effort priority
- CPU speed is important but, again, is _not_ a life-saver: I have same
performance, in terms of rate of underruns, with Intel E5-2660 @ 2.60 GHz and
Intel i7-6700K @ 4.00 GHz
- fiddling with OS (ie. changing CPU frequency scaling, locking thread to a
core, disabling IRQ balancing, disabling unused cores) very easily leads to a
_worse_ performance; on the other hand, I never managed to get any noticeable
improvements out of these tricks
- NIC interrupt coalescing _must_ be enabled in my case (Intel 82599ES):
with interrupt coalescing enabled I have about 8000 interrupts/s, which is much
below the maximum my CPU+OS can sustain (easily 6-7x that)
- for all other network-related configuration the default is sufficient,
including the number of TX descriptors and network buffers
- the size of the vectors passed to send() does not influence performance; in
particular, it does _not_ help to split the vector into chunks with a size that
is a multiple of the maximum samples per packet
The only remaining issue I have is that I get sporadic underruns (in the order
of one every several minutes, on average) that are periodic with base 10
seconds within 0.01 s. For instance, first underrun at 08:22:54.83, next could
be at 08:31:04.83 and then 08:34:24.83 and so on.
Since the only non-vital daemon running on the PC is sshd, I wonder whether it
is something related to the OS (Google did help me pin-pointing the issue) or
to the UHD (something like "every 1 billions samples do something special").
Best regards,
Claudio
On 02/24/2017 10:47 PM, Martin Braun via USRP-users wrote:
> Stefano,
>
> let me just add some statements to this:
>
> - In general, it's harder to create data at high rates from a PC and
> then receive it on the FPGA than vice versa. On top of what Ian said,
> regular OSes + GPPs have a lot of scheduling latency/randomness. At
> 100 Msps, on the 3.10 release cycle, you will get an underrun if you
> miss a chance to transmit a data packet by a small number of ?s (the
> actual value is hard to tell, but we're speaking of two-digit orders
> of magnitude). But even 100 ?s scheduling delays are possible. On my
> machine, I need to tune some knobs until I get this kind of
> performance, such as using "performance" CPU governors (I also
> increase the number of Tx descriptors with ethtool -G, but I'm not sure
> that's as influential.
> I would still recommend you bump it all the way up to 4096).
> - With dual-channel, this gets exacerbated because you have multiple
> threads competing for timely access to the transport device. I would
> assume that with dual cables, that's not true, but who knows what's
> going on internally.
>
> - On 3.10, we are currently *worse off* than on 3.9 in terms of
> streaming performance. There's a whole bunch of reasons for that, but
> the good news is we're currently working on some fixes to improve
> streaming performance. With the current 3.10 release, it's hard to run
> at 200 Msps from GNU Radio, for instance. If your software has
> comparable rates to benchmark_rate, then you're probably not going to
> be affected by this anyway.
>
> -- M
>
>
> On 02/23/2017 12:05 PM, Ian Buckley via USRP-users wrote:
>> Stefano
>> I'll take a stab at explaining the probable background on this. UHD
>> uses credit based flow control to avoid overflowing buffers in the
>> USRP. When you prepare to start a new TX operation the TX buffer
>> inside the USRP is completely empty and can fill at wire rate speed.
>> At some point it may/will become full and at this point the credit
>> based flow control algorithm will pace the data over the network such
>> that it approximates the TX rate over the air (Which is hard real
>> time). When the actual TX over the air operation starts relative to
>> when the buffering of data commences can yield some challenging situations.
>> If the TX operation starts as soon as the first samples of data reach
>> the TX DSP (i.e buffer is practically empty) then it runs the very
>> real risk of underflowing because it consumes data at a constant rate
>> but data delivered from the host tends to be bursty and jitter in
>> delivery (since the host is non-realtime in design) and also the main
>> sample buffer is a DRAM with a single port to which access is
>> arbitrated adding more jitter as ingress and egress compete for
>> access. Typically UHD deals with the "buffer practically empty" case
>> by starting streaming the data to the USRP well in advance of a
>> scheduled TX operation start time allowing time for buffers to fill
>> somewhat, but the buffer access arbitration is tricky at startup
>> since you have a corner case situation with data streaming in at wire
>> speeds rather than rate limited by the credit algorithm plus data
>> being drained at the configured sample rate by the TX DSP. What you
>> are probably therefore seeing is underflows (@ the DSP) during the
>> initial fill of the buffer as internal bandwidth is transiently
>> exceeded, and then smoother operation as the bit rate over the
>> network drops back to approximate the transmission sample rate once the
>> buffer is full.
>>
>> I'm a couple of years stale on the internal implementation details of
>> this now, but that is the gist of the challenge.
>> -Ian
>>
>>
>>
>> On Feb 23, 2017, at 11:02 AM, Stefano Bettelli via USRP-users
>> <[email protected]
>> <mailto:[email protected]<mailto:[email protected]%20%3cmailto:[email protected]>>>
>> wrote:
>>
>>> Hi,
>>>
>>> We are still in the process of extracting maximum performance from
>>> our USRP X310's, and we have a weird problem with transmission of
>>> data, which does not appear while reading data. The USRP that I am
>>> considering has two 10G fibre connections, and uses the XG FPGA
>>> firmware (we use the latest UHD, 3.10.1.1). The software developed
>>> by us and the benchmark_rate example agree on both RX and TX, so I
>>> will report only the results with the benchmark_rate. RX works
>>> nicely, we have 800MB/s on each fibre:
>>>
>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>> --duration 30 --channel "0,1" --rx_otw sc16 --rx_cpu sc16 --rx_rate
>>> 200e6 linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_003.010.001.001-release [...] Testing receive rate 200.000000
>>> Msps on 2 channels Benchmark rate summary:
>>> Num received samples: 12000120052
>>> Num dropped samples: 0
>>> Num overflows detected: 0
>>> Num transmitted samples: 0
>>> Num sequence errors: 0
>>> Num underflows detected: 0
>>> Num late commands: 0
>>> Num timeouts: 0
>>>
>>> However, TX shows a lot of problems for rates larger that 50MS/s,
>>> for
>>> instance:
>>>
>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>> --duration 30 --channel "0,1" --tx_otw sc16 --tx_cpu sc16 --tx_rate
>>> 100e6 linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_003.010.001.001-release [.] Testing transmit rate 100.000000
>>> Msps on 2 channels [. throws a lot of U's .] Benchmark rate summary:
>>> Num received samples: 0
>>> Num dropped samples: 0
>>> Num overflows detected: 0
>>> Num transmitted samples: 6013212352
>>> Num sequence errors: 0
>>> Num underflows detected: 18509
>>> Num late commands: 0
>>> Num timeouts: 0
>>>
>>> Eventually there is transmission at 400MB/s on both fibres, but we
>>> lose the initial part. Achieving tx_rate=200e6 does not work at all
>>> (the USRP stops replying). By observing the threads with htop we see
>>> that one thread approaches 80-90% of CPU usage. By comparison with
>>> our program, where we can identify the threads, I infer that it is
>>> the thread containing the tx_streamer->send() call; this call seems
>>> to be very heavy. All this looks strange because the Ethernet fibres
>>> are exactly the same, and the rest of the system seems to be
>>> configured in the same way for RX and TX:
>>>
>>> Both network interfaces have MTU=9000:
>>> ifconfig | grep enp129 -A3
>>> enp129s0f0 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2c
>>> inet addr:192.168.40.1 Bcast:192.168.40.255 Mask:255.255.255.0
>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2c/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>> --
>>> enp129s0f1 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2d
>>> inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0
>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2d/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>>
>>> Both RX and TX have large network buffer sizes sysctl -a | grep
>>> net.core.*mem_max net.core.rmem_max = 33554432 net.core.wmem_max =
>>> 33554432
>>>
>>> both RX and TX have the same number of descriptors (also on the
>>> other
>>> card):
>>> ethtool -g enp129s0f0
>>> Ring parameters for enp129s0f0:
>>> Pre-set maximums:
>>> RX: 4096
>>> RX Mini: 0
>>> RX Jumbo: 0
>>> TX: 4096
>>> Current hardware settings:
>>> RX: 512
>>> RX Mini: 0
>>> RX Jumbo: 0
>>> TX: 512
>>>
>>> Interrupt coalescing seems not to be available on these cards. The
>>> server is also quite powerful, 2xXeon with 48 cores in total, and
>>> 128GB of memory. Cores run at at least 3GHz. Can you suggest any
>>> idea to help us debugging this problem? Thanks in advance,
>>>
>>> Best regards/Mit freundlichen Gruessen,
>>>
>>> Stefano Bettelli
>>> Senior research engineer
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]<mailto:[email protected]>
>>> <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> 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]<mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
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]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/02688e1d/attachment-0001.html>
------------------------------
Message: 21
Date: Tue, 28 Feb 2017 14:54:28 +0000
From: Disco Daniele <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Disco Daniele <[email protected]>
Subject: [USRP-users] header file msg.hpp in the uhd release
Message-ID:
<5a6034b332824593a1c88bd515c58f3c@TELMBXD07BA020.telecomitalia.local>
Content-Type: text/plain; charset="us-ascii"
Hi!
Few days ago I download from github the last release of uhd.
Having problems with a sw, I discovered that in the include files
(/usr/local/include/uhd/utils) the header file msg.hpp is not present.
It is normal?
Now where is declared the namespace msg?
Thank You
Best Regards
Daniele
_____________________________________________
[logo1]
Daniele Disco
Engeenering & Tilab - Wireless Access
Wireless Innovation
Via Reiss Romoli, 274 - 10148 Torino
tel . +39 011 228 7271
cell. +39 331 600 1113
Fax. +39 06 4186 5196
Tim Official: Facebook<https://www.facebook.com/TimOfficialPage> -
Twitter<https://twitter.com/tim_official>
www.tim.it<http://www.tim.it/>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?
necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/b5b95a25/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2519 bytes
Desc: image001.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/b5b95a25/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/b5b95a25/attachment-0003.jpg>
------------------------------
Message: 22
Date: Tue, 28 Feb 2017 15:24:37 +0000
From: Disco Daniele <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Disco Daniele <[email protected]>
Subject: [USRP-users] R: header file msg.hpp in the uhd release
Message-ID:
<6003c2029e014d598c2ff784e095d808@TELMBXD07BA020.telecomitalia.local>
Content-Type: text/plain; charset="iso-8859-1"
I've forgotten to say that msg.hpp is not present in the "master" version
Da: Disco Daniele
Inviato: marted? 28 febbraio 2017 15:54
A: [email protected]
Cc: Daniele Disco
Oggetto: header file msg.hpp in the uhd release
Hi!
Few days ago I download from github the last release of uhd.
Having problems with a sw, I discovered that in the include files
(/usr/local/include/uhd/utils) the header file msg.hpp is not present.
It is normal?
Now where is declared the namespace msg?
Thank You
Best Regards
Daniele
_____________________________________________
[logo1]
Daniele Disco
Engeenering & Tilab - Wireless Access
Wireless Innovation
Via Reiss Romoli, 274 - 10148 Torino
tel . +39 011 228 7271
cell. +39 331 600 1113
Fax. +39 06 4186 5196
Tim Official: Facebook<https://www.facebook.com/TimOfficialPage> -
Twitter<https://twitter.com/tim_official>
www.tim.it<http://www.tim.it/>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?
necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/22d3e1f7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2519 bytes
Desc: image001.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/22d3e1f7/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/22d3e1f7/attachment-0003.jpg>
------------------------------
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 78, Issue 26
******************************************
