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: Fwd: Calibration issue : ERROR_CODE_TIMEOUT on
USRP2/N-Series device (bertrand guinebault)
2. Re: Questions on set_clock_source (Dario Fertonani)
3. Re: Questions on set_clock_source (Derek Kozel)
4. Re: Questions on set_clock_source ([email protected])
5. Re: Questions on set_clock_source (Dario Fertonani)
6. Re: Questions on set_clock_source ([email protected])
7. Re: Questions on set_clock_source (Derek Kozel)
8. Re: Questions on set_clock_source ([email protected])
9. Re: B200 Max bandwidth (Martin Braun)
10. Re: B200 FX3 SDK (Martin Braun)
11. Re: UHD Sink Error (Martin Braun)
12. Re: Input IP3 for B210 (Martin Braun)
13. Re: Overflows when doing repeated captures with X300
(Perelman, Nathan)
14. Re: Overflows when doing repeated captures with X300 (Derek Kozel)
15. Re: USB 3 hub for B200/B200mini (Martin Braun)
16. Re: Link LED blinking RED (Martin Braun)
17. Re: Severe underruns with uhd_siggen on 3.10.1.1 UHD
(Martin Braun)
18. Re: Expexted FPGA compatibility number 255.x, but got 14.0
(Martin Braun)
19. Re: USB 3 hub for B200/B200mini (Marcus D. Leech)
20. Re: Expexted FPGA compatibility number 255.x, but got 14.0
(Jonathon Pendlum)
21. Audio Synchronization (Benny Alexandar)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Mar 2017 18:29:16 +0100
From: bertrand guinebault <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Fwd: Calibration issue : ERROR_CODE_TIMEOUT
on USRP2/N-Series device
Message-ID:
<cadpedgtgc-6shvcrkzlxadvhxtv0choeucpwfiasusmsq8c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
If I change the default IP address from 192.168.10.2 to 192.168.10.3 on the
USRP 2, the calibration is working better without issue.
My Fedora 24 have 192.168.10.1 as static IP address.
[root@eBox-XX ~]# uhd_cal_rx_iq_balance
linux; GNU C++ version 6.2.1 20160916 (Red Hat 6.2.1-2); Boost_106000;
UHD_003.010.001.000-0-unknown
Creating the usrp device with: ...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Running calibration for SBXv3 TX
-- Daughterboard serial: 30B52E2
-- Calibration frequency range: 400 MHz -> 4400 MHz
....Error: Receiver error: ERROR_CODE_TIMEOUT
[root@eBox-XX ~]# /usr/libexec/uhd/usrp_burn_mb_eeprom
--args="addr=192.168.10.2"
--values="ip-addr=192.168.10.3,subnet=255.255.255.255"
linux; GNU C++ version 6.2.1 20160916 (Red Hat 6.2.1-2); Boost_106000;
UHD_003.010.001.000-0-unknown
Creating USRP device from address: addr=192.168.10.2
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Fetching current settings from EEPROM...
EEPROM ["ip-addr"] is "192.168.10.2"
EEPROM ["subnet"] is "255.255.255.255"
Setting EEPROM ["ip-addr"] to "192.168.10.3"...
Setting EEPROM ["subnet"] to "255.255.255.255"...
Power-cycle the USRP device for the changes to take effect.
Done
[root@eBox-XX ~]# uhd_cal_rx_iq_balance
linux; GNU C++ version 6.2.1 20160916 (Red Hat 6.2.1-2); Boost_106000;
UHD_003.010.001.000-0-unknown
Creating the usrp device with: ...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO.... No GPSDO found
-- Running calibration for SBXv3 TX
-- Daughterboard serial: 30B52E2
-- Calibration frequency range: 400 MHz -> 4400 MHz
....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
wrote cal data to "/root/.uhd/cal/rx_iq_cal_v0.2_30B52E2.csv"
Regards,
Bertrand
2017-03-17 14:27 GMT+01:00 Marcus D. Leech <[email protected]>:
> On 03/17/2017 06:50 AM, bertrand guinebault wrote:
>
> Hi Marcus,
>
> Thank you for your replies.
> About the interface on my Fedora 24 :
> The MTU is set to 4000
> The speed is set on 1Gb/s, I tried to force it on 1Gb/s (ethtool -s
> enp0s31f6 speed 1000 duplex full autoneg off), the Fedora 24 is directly
> connected to the NU USRP-2922
> And it's using the e1000e driver (i will try to put the up-to-date driver
> from intel (https://downloadmirror.intel.com/22283/eng/22_0_1_cd.zip).
>
> Can you explain me the 82579LM issue ?
>
> The 82579LM controller from Intel has a known hardware issue that causes
> it to drop packets randomly and spontaneously, unrelated
> to system load or network load.
>
>
>
> Regards,
>
> Bertrand
>
> 2017-03-16 18:54 GMT+01:00 Marcus D. Leech via USRP-users <
> [email protected]>:
>
>> On 03/16/2017 01:48 PM, Marcus M?ller via USRP-users wrote:
>>
>> Hi Bertrand,
>>
>> In lack of a better idea right now:
>>
>> Is it possible that Fedora decides to change the Ethernet interface's IP
>> address or link state halfway through, or is it possible that there are
>> other restrictions (limited MTU, not really 1Gigabit, but only 100Mbit
>> ethernet) in the network?
>>
>> Best regards,
>>
>> Marcus
>>
>> Maybe this is the famous 82579LM issue?
>>
>>
>>
>> On 03/16/2017 04:06 PM, bertrand guinebault via USRP-users wrote:
>>
>> Hi,
>>
>> I tried calibration on my NI USRP-2922, and I have some issues with
>> different kind of errors
>> I'm working on Fedora 24, and I tried with different version of UDH
>> provided by ETTUS and Fedora Update
>>
>> Provided by ETTUS directly, I tried
>> UHD-003.010.000.000-release-Linux.rpm
>> UHD-003.010.001.000-release-Linux.rpm
>> UHD-003.010.001.001-release-Linux.rpm
>>
>> From Fedora Update :
>> uhd-3.10.1.0-1.fc24.x86_64.rpm
>>
>> The most common error message:
>> # uhd_cal_rx_iq_balance --args addr=192.168.10.2 --verbose
>> linux; GNU C++ version 6.2.1 20160916 (Red Hat 6.2.1-2); Boost_106000;
>> UHD_003.010.001.000-0-unknown
>>
>>
>> Creating the usrp device with: addr=192.168.10.2...
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> -- Running calibration for SBXv3 TX
>> -- Daughterboard serial: EB040012
>> -- Calibration frequency range: 400 MHz -> 4400 MHz
>> RX IQ: 400.000000 MHz: best suppression 94.282502 dB, corrected 72.926136
>> dB
>> RX IQ: 407.301587 MHz: best suppression 79.399858 dB, corrected 58.191939
>> dB
>> RX IQ: 414.599105 MHz: best suppression 89.244934 dB, corrected 68.194899
>> dB
>> RX IQ: 421.900692 MHz: best suppression 88.884767 dB, corrected 67.885234
>> dB
>> Error: Receiver error: ERROR_CODE_TIMEOUT
>>
>> Some other message error:
>>
>> # uhd_cal_rx_iq_balance --args addr=192.168.10.2 --verbose
>> linux; GNU C++ version 6.2.1 20160916 (Red Hat 6.2.1-2); Boost_106000;
>> UHD_003.010.001.000-0-unknown
>>
>>
>> Creating the usrp device with: addr=192.168.10.2...
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> -- Running calibration for SBXv3 TX
>> -- Daughterboard serial: EB040012
>> -- Calibration frequency range: 400 MHz -> 4400 MHz
>> RX IQ: 400.000000 MHz: best suppression 86.081924 dB, corrected 64.716296
>> dB
>> RX IQ: 407.301587 MHz: best suppression 84.953826 dB, corrected 63.747399
>> dB
>> RX IQ: 414.599105 MHz: best suppression 82.714860 dB, corrected 61.659821
>> dB
>> Error: did not get all the samples requested
>>
>> # uhd_cal_rx_iq_balance --args addr=192.168.10.2 --verbose
>> linux; GNU C++ version 6.1.1 20160621 (Red Hat 6.1.1-3); Boost_106000;
>> UHD_003.010.000.000-release
>>
>>
>> Creating the usrp device with: addr=192.168.10.2...
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> -- Running calibration for SBXv3 TX
>> -- Daughterboard serial: EB040012
>> -- Calibration frequency range: 400 MHz -> 4400 MHz
>> RX IQ: 400.000000 MHz: best suppression 83.099158 dB, corrected 61.726489
>> dB
>> RX IQ: 407.301587 MHz: best suppression 101.920200 dB, corrected
>> 80.708140 dB
>> RX IQ: 414.599105 MHz: best suppression 95.090697 dB, corrected 74.012111
>> dB
>> RX IQ: 421.900692 MHz: best suppression 93.187901 dB, corrected 72.198753
>> dB
>> RX IQ: 429.198209 MHz: best suppression 92.049553 dB, corrected 71.121949
>> dB
>> Error: RuntimeError: fifo ctrl timed out looking for acks
>>
>> Do you have an idea of ??my issue?
>>
>> Regards,
>>
>> Bertrand
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [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/20170317/639d924d/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 17 Mar 2017 10:56:52 -0700
From: Dario Fertonani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Questions on set_clock_source
Message-ID:
<cajgedahb_yho7kveaw+ur+w3m1dtu7p0tgnl+cmcfwv+d-f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Mar 16, 2017 at 9:21 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 03/17/2017 12:05 AM, Dario Fertonani via USRP-users wrote:
>
> In my UHD code, the clock init part is as follows.
> rfBoardPtr->set_clock_source( "internal" );
> rfBoardPtr->set_time_unknown_pps( 0.0 );
> If I want to drive the clock (and all derived units) from a 10 MHz
> reference, is it sufficient to replace "internal" with "external", provided
> that a proper source is plugged in the relevant B210 input? Will the C++
> driver throw any exception if no valid input is detected? If not, is there
> any way to check whether the command is successful (ideally a software way,
> rather than hardware LED checking)?.
>
> At this stage I don't need an absolute time reference, so I plan to leave
> the PPS input unused, and the relevant line of code above unchanged. Is
> this a valid setup?
>
> Finally, I'm assuming the set_clock_source_out function doesn't do
> anything on B210. Is this correct?
>
> Thanks,
> Dario
>
> My recollection is that on B210, if you set the reference clock source to
> "external" and there's nothing there, an error is produced.
>
Unfortunately, that doesn't happen, and no warning is given either -- not a
very robust behavior, in my opinion. Since no message is produced, I was
assuming the board would fall back to the internal reference, but erratic
behavior of OTA performance suggests something else happens (may
undefined?).
>
> You can also check the "ref_locked" motherboard sensor state.
>
Any code snippet to point to?
Thanks,
Dario
>
>
>
>
> _______________________________________________
> 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/20170317/780e3b28/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 17 Mar 2017 11:23:13 -0700
From: Derek Kozel <[email protected]>
To: Dario Fertonani <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Questions on set_clock_source
Message-ID:
<CAA+K=tt=mpOZU0a1o8NNra9jioz=6u9unbjotz7fhz179t2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Dario,
Most of the examples check the ref_locked sensor, here is a link to one.
https://github.com/EttusResearch/uhd/blob/master/host/examples/rx_samples_to_file.cpp#L322
Regards,
Derek
On Fri, Mar 17, 2017 at 10:56 AM, Dario Fertonani via USRP-users <
[email protected]> wrote:
>
>
> On Thu, Mar 16, 2017 at 9:21 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 03/17/2017 12:05 AM, Dario Fertonani via USRP-users wrote:
>>
>> In my UHD code, the clock init part is as follows.
>> rfBoardPtr->set_clock_source( "internal" );
>> rfBoardPtr->set_time_unknown_pps( 0.0 );
>> If I want to drive the clock (and all derived units) from a 10 MHz
>> reference, is it sufficient to replace "internal" with "external", provided
>> that a proper source is plugged in the relevant B210 input? Will the C++
>> driver throw any exception if no valid input is detected? If not, is there
>> any way to check whether the command is successful (ideally a software way,
>> rather than hardware LED checking)?.
>>
>> At this stage I don't need an absolute time reference, so I plan to leave
>> the PPS input unused, and the relevant line of code above unchanged. Is
>> this a valid setup?
>>
>> Finally, I'm assuming the set_clock_source_out function doesn't do
>> anything on B210. Is this correct?
>>
>> Thanks,
>> Dario
>>
>> My recollection is that on B210, if you set the reference clock source to
>> "external" and there's nothing there, an error is produced.
>>
>
> Unfortunately, that doesn't happen, and no warning is given either -- not
> a very robust behavior, in my opinion. Since no message is produced, I was
> assuming the board would fall back to the internal reference, but erratic
> behavior of OTA performance suggests something else happens (may
> undefined?).
>
>
>>
>> You can also check the "ref_locked" motherboard sensor state.
>>
>
> Any code snippet to point to?
>
> Thanks,
> Dario
>
>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170317/b61e0ee8/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 17 Mar 2017 14:43:24 -0400
From: [email protected]
To: Dario Fertonani <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Questions on set_clock_source
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
The behavior boils down to how the PLL hardware behaves for internal vs
external reference.
My recollection may have been based on one of the other products.
Certainly, if you explicitly poll ref_locked after switching to
external, you'll be able to tell.
On 2017-03-17 13:56, Dario Fertonani wrote:
> On Thu, Mar 16, 2017 at 9:21 PM, Marcus D. Leech via USRP-users
> <[email protected]> wrote:
>
> On 03/17/2017 12:05 AM, Dario Fertonani via USRP-users wrote:
>
> In my UHD code, the clock init part is as follows.
> rfBoardPtr->set_clock_source( "internal" );
> rfBoardPtr->set_time_unknown_pps( 0.0 );
> If I want to drive the clock (and all derived units) from a 10 MHz reference,
> is it sufficient to replace "internal" with "external", provided that a
> proper source is plugged in the relevant B210 input? Will the C++ driver
> throw any exception if no valid input is detected? If not, is there any way
> to check whether the command is successful (ideally a software way, rather
> than hardware LED checking)?.
>
> At this stage I don't need an absolute time reference, so I plan to leave the
> PPS input unused, and the relevant line of code above unchanged. Is this a
> valid setup?
>
> Finally, I'm assuming the set_clock_source_out function doesn't do anything
> on B210. Is this correct?
>
> Thanks,
> Dario My recollection is that on B210, if you set the reference clock source
> to "external" and there's nothing there, an error is produced.
Unfortunately, that doesn't happen, and no warning is given either --
not a very robust behavior, in my opinion. Since no message is produced,
I was assuming the board would fall back to the internal reference, but
erratic behavior of OTA performance suggests something else happens (may
undefined?).
> You can also check the "ref_locked" motherboard sensor state.
Any code snippet to point to?
Thanks,
Dario
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170317/8e16facf/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 17 Mar 2017 12:05:49 -0700
From: Dario Fertonani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Questions on set_clock_source
Message-ID:
<cajgedaif1vmqjcuevkpf5z2xgyhmlmgzfozq2ms652opbkc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thank you Derek/Marcus, the following line returns the flag I wanted.
rfBoard->get_mboard_sensor( "ref_locked" ).to_bool( )
Any clue on my other two questions, reposted/reformatted below for your
convenience? The first is important, the second not so much.
1) At this stage I don't need an absolute time reference, so I plan to
leave the PPS input unused, while using the 10 MHz ref. Is this a valid
setup?
2) I'm assuming the set_clock_source_out function doesn't do anything on
B210. Is this correct?
Thanks,
Dario
On Fri, Mar 17, 2017 at 11:43 AM, <[email protected]> wrote:
> The behavior boils down to how the PLL hardware behaves for internal vs
> external reference.
>
> My recollection may have been based on one of the other products.
>
> Certainly, if you explicitly poll ref_locked after switching to external,
> you'll be able to tell.
>
>
>
>
>
>
> On 2017-03-17 13:56, Dario Fertonani wrote:
>
>
>
> On Thu, Mar 16, 2017 at 9:21 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 03/17/2017 12:05 AM, Dario Fertonani via USRP-users wrote:
>>
>> In my UHD code, the clock init part is as follows.
>> rfBoardPtr->set_clock_source( "internal" );
>> rfBoardPtr->set_time_unknown_pps( 0.0 );
>> If I want to drive the clock (and all derived units) from a 10 MHz
>> reference, is it sufficient to replace "internal" with "external", provided
>> that a proper source is plugged in the relevant B210 input? Will the C++
>> driver throw any exception if no valid input is detected? If not, is there
>> any way to check whether the command is successful (ideally a software way,
>> rather than hardware LED checking)?.
>>
>> At this stage I don't need an absolute time reference, so I plan to leave
>> the PPS input unused, and the relevant line of code above unchanged. Is
>> this a valid setup?
>>
>> Finally, I'm assuming the set_clock_source_out function doesn't do
>> anything on B210. Is this correct?
>>
>> Thanks,
>> Dario
>>
>> My recollection is that on B210, if you set the reference clock source to
>> "external" and there's nothing there, an error is produced.
>>
>
> Unfortunately, that doesn't happen, and no warning is given either -- not
> a very robust behavior, in my opinion. Since no message is produced, I was
> assuming the board would fall back to the internal reference, but erratic
> behavior of OTA performance suggests something else happens (may
> undefined?).
>
>
>>
>> You can also check the "ref_locked" motherboard sensor state.
>>
>
> Any code snippet to point to?
>
> Thanks,
> Dario
>
>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170317/74445d00/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 17 Mar 2017 15:08:24 -0400
From: [email protected]
To: Dario Fertonani <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Questions on set_clock_source
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Indeed, you can have an external reference without an external 1 PPS
input.
For hardware that doesn't support that feature, set_clock_source_out()
does nothing. The B210 doesn't have that hardware feature.
On 2017-03-17 15:05, Dario Fertonani wrote:
> Thank you Derek/Marcus, the following line returns the flag I wanted.
>
>> rfBoard->get_mboard_sensor( "ref_locked" ).to_bool( )
> Any clue on my other two questions, reposted/reformatted below for your
> convenience? The first is important, the second not so much.
>
> 1) At this stage I don't need an absolute time reference, so I plan to leave
> the PPS input unused, while using the 10 MHz ref. Is this a valid setup?
> 2) I'm assuming the set_clock_source_out function doesn't do anything on
> B210. Is this correct?
>
> Thanks,
> Dario
>
> On Fri, Mar 17, 2017 at 11:43 AM, <[email protected]> wrote:
>
> The behavior boils down to how the PLL hardware behaves for internal vs
> external reference.
>
> My recollection may have been based on one of the other products.
>
> Certainly, if you explicitly poll ref_locked after switching to external,
> you'll be able to tell.
>
> On 2017-03-17 13:56, Dario Fertonani wrote:
>
> On Thu, Mar 16, 2017 at 9:21 PM, Marcus D. Leech via USRP-users
> <[email protected]> wrote:
>
> On 03/17/2017 12:05 AM, Dario Fertonani via USRP-users wrote:
>
> In my UHD code, the clock init part is as follows.
> rfBoardPtr->set_clock_source( "internal" );
> rfBoardPtr->set_time_unknown_pps( 0.0 );
> If I want to drive the clock (and all derived units) from a 10 MHz reference,
> is it sufficient to replace "internal" with "external", provided that a
> proper source is plugged in the relevant B210 input? Will the C++ driver
> throw any exception if no valid input is detected? If not, is there any way
> to check whether the command is successful (ideally a software way, rather
> than hardware LED checking)?.
>
> At this stage I don't need an absolute time reference, so I plan to leave the
> PPS input unused, and the relevant line of code above unchanged. Is this a
> valid setup?
>
> Finally, I'm assuming the set_clock_source_out function doesn't do anything
> on B210. Is this correct?
>
> Thanks,
> Dario My recollection is that on B210, if you set the reference clock source
> to "external" and there's nothing there, an error is produced.
Unfortunately, that doesn't happen, and no warning is given either --
not a very robust behavior, in my opinion. Since no message is produced,
I was assuming the board would fall back to the internal reference, but
erratic behavior of OTA performance suggests something else happens (may
undefined?).
> You can also check the "ref_locked" motherboard sensor state.
Any code snippet to point to?
Thanks,
Dario
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170317/1055ede5/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 17 Mar 2017 12:31:47 -0700
From: Derek Kozel <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Dario Fertonani <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Questions on set_clock_source
Message-ID:
<CAA+K=ttKCSmyk1wPxhFzwzZ1UjfJ3baokDvqA=qpxginza7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus, I think you may be remembering the behavior of some of our examples
and of GNU Radio which will poll the ref_locked sensor and print a failure
if it does not lock.
For instance this example, which is about the GPSDO but the code works for
any 10 MHz source.
https://github.com/EttusResearch/uhd/blob/master/host/examples/sync_to_gps.cpp#L82
On Fri, Mar 17, 2017 at 12:08 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> Indeed, you can have an external reference without an external 1 PPS input.
>
> For hardware that doesn't support that feature, set_clock_source_out()
> does nothing. The B210 doesn't have that hardware feature.
>
>
>
>
>
>
> On 2017-03-17 15:05, Dario Fertonani wrote:
>
> Thank you Derek/Marcus, the following line returns the flag I wanted.
>
> rfBoard->get_mboard_sensor( "ref_locked" ).to_bool( )
>
>
> Any clue on my other two questions, reposted/reformatted below for your
> convenience? The first is important, the second not so much.
>
> 1) At this stage I don't need an absolute time reference, so I plan to
> leave the PPS input unused, while using the 10 MHz ref. Is this a valid
> setup?
> 2) I'm assuming the set_clock_source_out function doesn't do anything on
> B210. Is this correct?
>
> Thanks,
> Dario
>
>
>
> On Fri, Mar 17, 2017 at 11:43 AM, <[email protected]> wrote:
>
>> The behavior boils down to how the PLL hardware behaves for internal vs
>> external reference.
>>
>> My recollection may have been based on one of the other products.
>>
>> Certainly, if you explicitly poll ref_locked after switching to external,
>> you'll be able to tell.
>>
>>
>>
>>
>>
>>
>> On 2017-03-17 13:56, Dario Fertonani wrote:
>>
>>
>>
>> On Thu, Mar 16, 2017 at 9:21 PM, Marcus D. Leech via USRP-users <
>> [email protected]> wrote:
>>
>>> On 03/17/2017 12:05 AM, Dario Fertonani via USRP-users wrote:
>>>
>>> In my UHD code, the clock init part is as follows.
>>> rfBoardPtr->set_clock_source( "internal" );
>>> rfBoardPtr->set_time_unknown_pps( 0.0 );
>>> If I want to drive the clock (and all derived units) from a 10 MHz
>>> reference, is it sufficient to replace "internal" with "external", provided
>>> that a proper source is plugged in the relevant B210 input? Will the C++
>>> driver throw any exception if no valid input is detected? If not, is there
>>> any way to check whether the command is successful (ideally a software way,
>>> rather than hardware LED checking)?.
>>>
>>> At this stage I don't need an absolute time reference, so I plan to
>>> leave the PPS input unused, and the relevant line of code above unchanged.
>>> Is this a valid setup?
>>>
>>> Finally, I'm assuming the set_clock_source_out function doesn't do
>>> anything on B210. Is this correct?
>>>
>>> Thanks,
>>> Dario
>>>
>>> My recollection is that on B210, if you set the reference clock source
>>> to "external" and there's nothing there, an error is produced.
>>>
>>
>> Unfortunately, that doesn't happen, and no warning is given either -- not
>> a very robust behavior, in my opinion. Since no message is produced, I was
>> assuming the board would fall back to the internal reference, but erratic
>> behavior of OTA performance suggests something else happens (may
>> undefined?).
>>
>>
>>>
>>> You can also check the "ref_locked" motherboard sensor state.
>>>
>>
>> Any code snippet to point to?
>>
>> Thanks,
>> Dario
>>
>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20170317/79c66ba5/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 17 Mar 2017 15:41:43 -0400
From: [email protected]
To: Derek Kozel <[email protected]>
Cc: Dario Fertonani <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Questions on set_clock_source
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hmmm, that may be the case. I had a (vague) recollection that on at
least one of the USRPs, simply asking to set an external reference when
there was none there would raise an expection. But this may well be
cognitive pollution, as you point out.
On 2017-03-17 15:31, Derek Kozel wrote:
> Marcus, I think you may be remembering the behavior of some of our examples
> and of GNU Radio which will poll the ref_locked sensor and print a failure if
> it does not lock.
>
> For instance this example, which is about the GPSDO but the code works for
> any 10 MHz source.
> https://github.com/EttusResearch/uhd/blob/master/host/examples/sync_to_gps.cpp#L82
>
>
> On Fri, Mar 17, 2017 at 12:08 PM, Marcus D. Leech via USRP-users
> <[email protected]> wrote:
>
> Indeed, you can have an external reference without an external 1 PPS input.
>
> For hardware that doesn't support that feature, set_clock_source_out() does
> nothing. The B210 doesn't have that hardware feature.
>
> On 2017-03-17 15:05, Dario Fertonani wrote:
> Thank you Derek/Marcus, the following line returns the flag I wanted.
> rfBoard->get_mboard_sensor( "ref_locked" ).to_bool( )
> Any clue on my other two questions, reposted/reformatted below for your
> convenience? The first is important, the second not so much.
>
> 1) At this stage I don't need an absolute time reference, so I plan to leave
> the PPS input unused, while using the 10 MHz ref. Is this a valid setup?
> 2) I'm assuming the set_clock_source_out function doesn't do anything on
> B210. Is this correct?
>
> Thanks,
> Dario
>
> On Fri, Mar 17, 2017 at 11:43 AM, <[email protected]> wrote:
>
> The behavior boils down to how the PLL hardware behaves for internal vs
> external reference.
>
> My recollection may have been based on one of the other products.
>
> Certainly, if you explicitly poll ref_locked after switching to external,
> you'll be able to tell.
>
> On 2017-03-17 13:56, Dario Fertonani wrote:
>
> On Thu, Mar 16, 2017 at 9:21 PM, Marcus D. Leech via USRP-users
> <[email protected]> wrote:
>
> On 03/17/2017 12:05 AM, Dario Fertonani via USRP-users wrote:
>
> In my UHD code, the clock init part is as follows.
> rfBoardPtr->set_clock_source( "internal" );
> rfBoardPtr->set_time_unknown_pps( 0.0 );
> If I want to drive the clock (and all derived units) from a 10 MHz reference,
> is it sufficient to replace "internal" with "external", provided that a
> proper source is plugged in the relevant B210 input? Will the C++ driver
> throw any exception if no valid input is detected? If not, is there any way
> to check whether the command is successful (ideally a software way, rather
> than hardware LED checking)?.
>
> At this stage I don't need an absolute time reference, so I plan to leave the
> PPS input unused, and the relevant line of code above unchanged. Is this a
> valid setup?
>
> Finally, I'm assuming the set_clock_source_out function doesn't do anything
> on B210. Is this correct?
>
> Thanks,
> Dario My recollection is that on B210, if you set the reference clock source
> to "external" and there's nothing there, an error is produced.
Unfortunately, that doesn't happen, and no warning is given either --
not a very robust behavior, in my opinion. Since no message is produced,
I was assuming the board would fall back to the internal reference, but
erratic behavior of OTA performance suggests something else happens (may
undefined?).
> You can also check the "ref_locked" motherboard sensor state.
Any code snippet to point to?
Thanks,
Dario
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170317/c82c64d2/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 17 Mar 2017 15:16:10 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200 Max bandwidth
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Stephen,
on master branch, we'll soon be publishing a new firmware image that
will increase the available bandwidth. Please bear with us for another
week or two, and this might simply go away. If not, please raise the
issue again.
Cheers,
Martin
On 03/17/2017 04:03 AM, Stephen Bell via USRP-users wrote:
> These are the results that I?m achieving in the following benchmark
> tests with the UHD_003.010.001.000 driver, the only driver that I was
> able to find that could complete every below benchmark test
>
> Hopefully this data will tell where the bottleneck is occurring on my PC
>
>
>
> benchmark_rate.exe --rx_rate 40e6
>
> Benchmark rate summary:
>
> Num received samples: 400001326
>
> 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
>
>
>
> benchmark_rate.exe --rx_rate 56e6
>
> Benchmark rate summary:
>
> Num received samples: 379214389
>
> Num dropped samples: 180753604
>
> Num overflows detected: 2865
>
> Num transmitted samples: 0
>
> Num sequence errors: 0
>
> Num underflows detected: 0
>
> Num late commands: 0
>
> Num timeouts: 0
>
>
> benchmark_rate.exe --rx_rate 61.44e6
>
> Benchmark rate summary:
>
> Num received samples: 375550505
>
> Num dropped samples: 238816361
>
> Num overflows detected: 3521
>
> Num transmitted samples: 0
>
> Num sequence errors: 0
>
> Num underflows detected: 0
>
> Num late commands: 0
>
> Num timeouts: 0
>
>
> benchmark_rate.exe --rx_rate 56e6 --rx_otw sc8
>
> Benchmark rate summary:
>
> Num received samples: 559954132
>
> 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
>
>
> benchmark_rate.exe --rx_rate 56e6 --rx_otw sc12
>
> UHD Error:
>
> The receive packet handler caught a value exception.
>
> ValueError: bad vrt header or packet fragment
>
> Receiver error: ERROR_CODE_BAD_PACKET
>
> Unexpected error on recv, continuing...
>
> OD (X50)
>
> Benchmark rate summary:
>
> Num received samples: 401949438
>
> Num dropped samples: 370673788718
>
> Num overflows detected: 267
>
> Num transmitted samples: 0
>
> Num sequence errors: 0
>
> Num underflows detected: 0
>
> Num late commands: 0
>
> Num timeouts: 0
>
>
>
> benchmark_rate.exe --rx_rate 61.44e6 --rx_otw sc8
>
> Benchmark rate summary:
>
> Num received samples: 614374171
>
> 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
>
>
>
> benchmark_rate.exe --rx_rate 61.44e6 --rx_otw sc12
>
> UHD Error: The receive packet handler caught a value exception.
> alueError: bad vrt header or packet fragment
>
> Receiver error: ERROR_CODE_BAD_PACKET
>
> Unexpected error on recv, continuing...
>
> OD
>
> UHD Error: recv packet demuxer unexpected sid 0x7fedfe5
>
> Receiver error: ERROR_CODE_TIMEOUT, continuing... (X20)
>
> Benchmark rate summary:
>
> Num received samples: 187204164
>
> Num dropped samples: 194317442477
>
> Num overflows detected: 516
>
> Num transmitted samples: 0
>
> Num sequence errors: 0
>
> Num underflows detected: 0
>
> Num late commands: 0
>
> Num timeouts: 39
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 10
Date: Fri, 17 Mar 2017 15:23:39 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200 FX3 SDK
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Thanks for the feedback, Jason!
-- M
On 03/16/2017 07:14 AM, Jason Matusiak via USRP-users wrote:
> Just an update that the README for the FX3 build has a bad link to the
> SDK (since we need v1.2.3). The new link is:
> http://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-sdk-archives.
>
>
> Also, the ARM_GCC.tar.gz file is not located in the archived SDK, so I
> had to download it from here:
> https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update/+download/gcc-arm-none-eabi-4_7-2013q1-20130313-linux.tar.bz2.
> I then renamed the extracted gcc-arm-none-eabi-4_7-2013q1 to arm-2013.03.
>
> I also had to change the instruction "export ARMGCC_VERSION=4.5.2" to
> "export ARMGCC_VERSION=4.7.3".
>
> I am still not getting debug out of my FPGA from the FX3 on the
> B205mini, but that might have been an issue with my coding, not with the
> rebuild of the .hex firmware.
------------------------------
Message: 11
Date: Fri, 17 Mar 2017 15:25:06 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD Sink Error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Nigel,
I haven't seen this before. Which UHD version is this on? And I assume
it's on an X300? And when does this error pop up?
-- M
On 03/16/2017 02:09 AM, Nigel Steed (XENINT) via USRP-users wrote:
> Hi All,
>
>
>
> I have a flowgraph which has both a uhd_sink and uhd_source. I also have
> the samp_rate for both of these linked to a QT Chooser to enable me to
> select valid sample rates dynamically at runtime.
>
>
>
> If I change the sample rate from 500kHz to 12.5MHz I can repeatedly
> generate the following error and the transmitter stops:
>
>
>
> read[thread-per-block[9]: <block gr uhd usrp sink (8)>]: RuntimeError:
> On node 0/DmaFIFO_0, input port 0 is already connected.
>
>
>
> If I change between sample rates closer together (12.5MHz and 3.125MHz)
> this problem does not appear.
>
>
>
> Has anyone else experienced this, and/or know of a solution ?
>
>
>
> Thanks,
>
>
>
> Nigel
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 12
Date: Fri, 17 Mar 2017 15:30:15 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Input IP3 for B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Hey Roy,
it looks like there's a mixup between B200 and AD9361 stats here. That
probably explains the discrepancy.
Regards,
Martin
On 02/13/2017 11:09 PM, ???? via USRP-users wrote:
> Hi,
>
>
> I saw that there is a document called "B200_RF_Performance.pdf" that
> summarizes RF parameters such as NF, Input IP3, and IQ Balance, versus
> center frequency and gain.
>
> Specifically, for frequency of 900MHz and gain of 45dB (page 49) the
> input IP3 should be around -20dBm (and the NF around 10dB). However,
> when I tested it, I got an input IP3 of -37dBm.
>
> The test was performed by recording two CWs, the first at an offset of
> 300Khz from center frequency, and the second at an offset of 500KHz from
> the center frequency, such that the IM3 should be at an offset of 100KHz
> from the center frequency. The power of the IM3 was calculated from
> the fft of the samples. The test was performed twice, first with CWs at
> a power level of -75dBm, where the IM3 was at -150.5dBm, and then with
> CWs at -65dBm, where the IM3 was at -121dBm. The sampling rate was
> around 1.6MHz
>
> Could you help me figure out the difference between the test and the
> document?
>
> In addition, in the AD9361 datasheet it says that for frequency of
> 800MHz, the IP3 and NF at maximum RX gain should be -18dBm and 2dB,
> respectively. However, according to the document, at maximum gain (90dB)
> the input IP3 is -52dBm and the NF is 5dB. What is the reason we can't
> get the performance of the AD9361?
>
> Thanks,
> Roy
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 13
Date: Fri, 17 Mar 2017 22:57:24 +0000
From: "Perelman, Nathan" <[email protected]>
To: Ben Hilburn via USRP-users <[email protected]>
Subject: Re: [USRP-users] Overflows when doing repeated captures with
X300
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I tracked this down to needing to ignore overflow errors if no data has been
received yet. Is something not being reset correctly somewhere when using an
X3x0? There is no need to have this check when doing repeated captures with an
N2x0 or B2x0.
-Nathan
From: USRP-users [mailto:[email protected]] On Behalf Of
Perelman, Nathan via USRP-users
Sent: Friday, March 10, 2017 3:32 PM
To: Ben Hilburn via USRP-users <[email protected]>
Subject: Re: [USRP-users] Overflows when doing repeated captures with X300
Has anyone at Ettus been able to test this and see if the same issue exists for
them? Or some idea of what might be going wrong?
-Nathan
From: USRP-users [mailto:[email protected]] On Behalf Of
Perelman, Nathan via USRP-users
Sent: Wednesday, March 8, 2017 12:23 PM
To: Ben Hilburn via USRP-users
<[email protected]<mailto:[email protected]>>
Subject: [USRP-users] Overflows when doing repeated captures with X300
When using the same multiusrp object to do repeated captures with an X300, I'm
seeing the 2nd (and 3rd, 4th) captures fail with an overflow error (D printed
out). Is there an additional wait step or sensor to wait on for the X300? This
same code works fine for repeated captures with an N210 and B210. To
demonstrate this issue, I added a loop to rx_samples_to_file to have it do
multiple captures (starting at line 333):
for(int i = 0; i < 4; i++)
{
std::cout << "Capture " << i << std::endl;
//recv to file
if (type == "double") recv_to_file<std::complex<double>
>recv_to_file_args("fc64");
else if (type == "float") recv_to_file<std::complex<float>
>recv_to_file_args("fc32");
else if (type == "short") recv_to_file<std::complex<short>
>recv_to_file_args("sc16");
else throw std::runtime_error("Unknown type " + type);
}
The output is:
$ ./rx_samples_to_file --args type=x300 --rate 6250000 --duration 1 --freq
800000000 --null
linux; GNU C++ version 5.3.1 20160406 (Red Hat 5.3.1-6); Boost_106000;
UHD_003.010.001.001-0-unknown
Creating the usrp device with: type=x300...
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 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
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1183.9MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1186.0MB/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
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X300
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: UBX RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: UBX TX
Setting RX Rate: 6.250000 Msps...
Actual RX Rate: 6.250000 Msps...
Setting RX Freq: 800.000000 MHz...
Actual RX Freq: 800.000000 MHz...
Waiting for "lo_locked": ++++++++++ locked.
Press Ctrl + C to stop streaming...
Capture 0
Capture 1
DGot an overflow indication. Please consider the following:
Your write medium must sustain a rate of 25.000000MB/s.
Dropped samples will not be written to the file.
Please modify this example for your purposes.
This message will not appear again.
Capture 2
DGot an overflow indication. Please consider the following:
Your write medium must sustain a rate of 25.000000MB/s.
Dropped samples will not be written to the file.
Please modify this example for your purposes.
This message will not appear again.
Capture 3
DGot an overflow indication. Please consider the following:
Your write medium must sustain a rate of 25.000000MB/s.
Dropped samples will not be written to the file.
Please modify this example for your purposes.
This message will not appear again.
Done!
Any ideas on where I might be going wrong?
-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170317/b0475ea3/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 17 Mar 2017 16:55:57 -0700
From: Derek Kozel <[email protected]>
To: "Perelman, Nathan" <[email protected]>
Cc: Ben Hilburn via USRP-users <[email protected]>
Subject: Re: [USRP-users] Overflows when doing repeated captures with
X300
Message-ID:
<CAA+K=tvFouPa7Ni3WEaQ9yTtjfy32u98UX9RcC=jKGnxa6VJ=a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nathan,
The rx_samples_to_file example wasn't written with repeated acquisitions in
mind so there are several things which are causing or will cause problems.
First, you are specifying a duration rather than an exact number of
samples, this causes the streaming mode to be STREAM_MODE_START_CONTINUOUS
rather than STREAM_MODE_NUM_SAMPS_AND_DONE
https://github.com/EttusResearch/uhd/blob/master/host/examples/rx_samples_to_file.cpp#L63
The problem with this is, as you have discovered, that after the first
acquisition finishes there will be samples left in the USRP's buffers which
have not been flushed. You can either specify the number of samples to
acquire or add code to flush the pipeline, a while loop waiting for a
timeout. This will slow down the rate of acquisitions though so the
NUM_SAMPS_AND_DONE approach is better.
Second, the recv_to_file function is doing a lot of setup every time it is
called, including making a new rx_streamer.
https://github.com/EttusResearch/uhd/blob/master/host/examples/rx_samples_to_file.cpp#L53
It is much better to do all this setup once and just issue a new stream
command each time you want to acquire. We have an example in review which
covers doing repeated acquisitions.
Regards,
Derek
On Fri, Mar 17, 2017 at 3:57 PM, Perelman, Nathan via USRP-users <
[email protected]> wrote:
> I tracked this down to needing to ignore overflow errors if no data has
> been received yet. Is something not being reset correctly somewhere when
> using an X3x0? There is no need to have this check when doing repeated
> captures with an N2x0 or B2x0.
>
> -Nathan
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Perelman, Nathan via USRP-users
> *Sent:* Friday, March 10, 2017 3:32 PM
> *To:* Ben Hilburn via USRP-users <[email protected]>
> *Subject:* Re: [USRP-users] Overflows when doing repeated captures with
> X300
>
>
>
> Has anyone at Ettus been able to test this and see if the same issue
> exists for them? Or some idea of what might be going wrong?
>
> -Nathan
>
>
>
> *From:* USRP-users [mailto:[email protected]
> <[email protected]>] *On Behalf Of *Perelman, Nathan via
> USRP-users
> *Sent:* Wednesday, March 8, 2017 12:23 PM
> *To:* Ben Hilburn via USRP-users <[email protected]>
> *Subject:* [USRP-users] Overflows when doing repeated captures with X300
>
>
>
> When using the same multiusrp object to do repeated captures with an X300,
> I?m seeing the 2nd (and 3rd, 4th) captures fail with an overflow error (D
> printed out). Is there an additional wait step or sensor to wait on for the
> X300? This same code works fine for repeated captures with an N210 and
> B210. To demonstrate this issue, I added a loop to rx_samples_to_file to
> have it do multiple captures (starting at line 333):
>
> for(int i = 0; i < 4; i++)
>
> {
>
> std::cout << "Capture " << i << std::endl;
>
> //recv to file
>
> if (type == "double") recv_to_file<std::complex<double>
> >recv_to_file_args("fc64");
>
> else if (type == "float") recv_to_file<std::complex<float>
> >recv_to_file_args("fc32");
>
> else if (type == "short") recv_to_file<std::complex<short>
> >recv_to_file_args("sc16");
>
> else throw std::runtime_error("Unknown type " + type);
>
> }
>
>
>
>
>
> The output is:
>
> $ ./rx_samples_to_file --args type=x300 --rate 6250000 --duration 1 --freq
> 800000000 --null
>
> linux; GNU C++ version 5.3.1 20160406 (Red Hat 5.3.1-6); Boost_106000;
> UHD_003.010.001.001-0-unknown
>
>
>
>
>
> Creating the usrp device with: type=x300...
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 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
>
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1183.9MB/s)
>
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1186.0MB/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
>
> Using Device: Single USRP:
>
> Device: X-Series Device
>
> Mboard 0: X300
>
> RX Channel: 0
>
> RX DSP: 0
>
> RX Dboard: A
>
> RX Subdev: UBX RX
>
> RX Channel: 1
>
> RX DSP: 0
>
> RX Dboard: B
>
> RX Subdev: UBX RX
>
> TX Channel: 0
>
> TX DSP: 0
>
> TX Dboard: A
>
> TX Subdev: UBX TX
>
> TX Channel: 1
>
> TX DSP: 0
>
> TX Dboard: B
>
> TX Subdev: UBX TX
>
>
>
> Setting RX Rate: 6.250000 Msps...
>
> Actual RX Rate: 6.250000 Msps...
>
>
>
> Setting RX Freq: 800.000000 MHz...
>
> Actual RX Freq: 800.000000 MHz...
>
>
>
> Waiting for "lo_locked": ++++++++++ locked.
>
>
>
> Press Ctrl + C to stop streaming...
>
> Capture 0
>
> Capture 1
>
> DGot an overflow indication. Please consider the following:
>
> Your write medium must sustain a rate of 25.000000MB/s.
>
> Dropped samples will not be written to the file.
>
> Please modify this example for your purposes.
>
> This message will not appear again.
>
> Capture 2
>
> DGot an overflow indication. Please consider the following:
>
> Your write medium must sustain a rate of 25.000000MB/s.
>
> Dropped samples will not be written to the file.
>
> Please modify this example for your purposes.
>
> This message will not appear again.
>
> Capture 3
>
> DGot an overflow indication. Please consider the following:
>
> Your write medium must sustain a rate of 25.000000MB/s.
>
> Dropped samples will not be written to the file.
>
> Please modify this example for your purposes.
>
> This message will not appear again.
>
>
>
> Done!
>
>
>
>
>
> Any ideas on where I might be going wrong?
>
> -Nathan
>
> _______________________________________________
> 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/20170317/f31c2616/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 17 Mar 2017 17:19:33 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USB 3 hub for B200/B200mini
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
I have a D-Link that I've been using for testing, so far no issues. Says
DUB-1340 on the bottom. That's not an endorsement, though, and maybe
I've just gotten lucky.
-- M
On 03/09/2017 07:15 AM, Sean Nowlan via USRP-users wrote:
> Does anyone have a recommendation for a specific USB 3 hub brand and
> model that works well with a B200 or B200mini? I'm streaming pretty low
> rates - 2-4M samples/second - and I'm sure most hubs could do that, but
> I'm worried about reliability of connections, spurious disconnects, etc.
>
> Thanks,
> Sean
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 16
Date: Fri, 17 Mar 2017 17:24:40 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Link LED blinking RED
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Naceur,
the LINK LED is tied to the network traffic. It's like the light that is
adjacent to the SFPs. If you take the lid off, you'll see them blink in
sync. Red just just means there's traffic to the device.
-- M
On 03/08/2017 03:15 PM, El Ouni, Naceur (IntlAssoc) via USRP-users wrote:
> Hi Nicolas,
>
>
>
> The USRP is just idle. I am talking about the LINK led (next to the GPS
> led to the right) in the front panel.
>
>
>
> Regards,
>
> Naceur
>
>
>
> *From:*Nicolas Cuervo [mailto:[email protected]]
> *Sent:* Wednesday, March 08, 2017 8:18 AM
> *To:* El Ouni, Naceur (IntlAssoc) <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Link LED blinking RED
>
>
>
> Hello Naceur,
>
> could you please be more specific on which led is the one you are
> referring to? In general, the front panel led will blink red on the TX
> ports when a transmission is undergoing [1]. On the same port, being
> TX/RX, it will blink green when it is receiving instead.
>
> Are you transmitting with your USRP?
>
> Regards,
>
> -Nicolas
>
>
> [1] https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_on_board_leds
>
>
>
> On Tue, Mar 7, 2017 at 5:59 PM, El Ouni, Naceur (IntlAssoc) via
> USRP-users <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hello,
>
>
>
> What does a Blinking Red LINK LED means.
>
> I am using an NI branded X310 (NI 2942R) with Windows Server 2012 R2.
>
> Ethernet port 0 is connected to a 1G Ethernet interface and port 1
> is connected to a High Speed 10GB Interface using a fiber optic cable.
>
>
>
> PS: the blinking is happenning regardless of the port 1 connection
> i.e. blinking persists if I disconnect the 10GB Ethernet cable.
>
>
>
> Thanks and Regards,
>
>
>
> Naceur El Ouni
>
> NIST - Wireless Networks Division (673)
>
>
>
>
> _______________________________________________
> 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
>
------------------------------
Message: 17
Date: Fri, 17 Mar 2017 17:25:47 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Severe underruns with uhd_siggen on 3.10.1.1
UHD
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Can you test this on network? 1 GigE is enough. Just to rule out your
computer for sure.
-- M
On 03/08/2017 12:23 PM, Roman Olesyuk via USRP-users wrote:
> Hello everyone,
>
> I experience severe underruns (a lot of UUU... messages) when trying
> to uhd_siggen from 3.10.1.1 UHD with the following command:
>
> $ uhd_siggen --args "resource=RIO0" --spec "A:0" --antenna "TX/RX"
> --samp-rate 20e6 --gain 0 --freq 1152e6 --clock-source "internal" --const
>
> My setup is the following:
>
> ASUS Z170M-PLUS, Intel Core i7-6700K, 32Gb RAM, SSD,
>
> Ubuntu 16.04 64 bit, 4.4 kernel, NI RIO 15.0.0 drivers,
>
> Latest stable UHD 3.10.1.1 from official Ubuntu PPA
> ppa:ettusresearch/uhd + GNU Radio 3.7.10 from ppa:myriadrf/gnuradio,
>
> X310 with two SBX120 is connected via PCIe, PCIe interface card is in
> the first x16 PCIe slot.
>
> I also tried to run uhd_siggen with lower sample rates but still have a
> lot of underruns. Is this behavior normal? It looks like this PC should
> be able to produce constant samples at 20 Msps.
>
> --
> ? ?????????, ????? ??????.
> Yours sincerely, Roman Olesyuk.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 18
Date: Fri, 17 Mar 2017 17:28:40 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Expexted FPGA compatibility number 255.x,
but got 14.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Ali,
like Marcus said, it looks like you're trying to run a default image.
That's something we need to fix. There's a 3.10-image in the rfnoc-devel
images package. You can point it to the one called *_RFNOC.bin using
--addr fpga=/path/to/bitfile.
Cheers,
Martin
On 03/14/2017 07:39 AM, Marcus M?ller via USRP-users wrote:
> Hi Ali,
>
> I think you probably know that, but for future readers of this mailing list:
> The E310/E312 *runs* the python code generated by GRC. Thus, everything
> is happening on the E3xx itself ? aside from the flow graph design.
>
> So, the FPGA compatibility mismatch means you're running a UHD on the
> device which doesn't match the FPGA images that it loads. Is that
> possible? Did you build UHD yourself, or are you running from a "plain"
> Release-4 SD card image?
>
>
> Best regards,
>
> Marcus
>
>
> On 14.03.2017 13:57, do ber via USRP-users wrote:
>> Hi to all,
>>
>> I am currently working on E312. My final goal is to control an e312(if
>> possible multi e312 in the future) with GNURadio companion.
>>
>> I installed SDK. I am following the steps written in here:
>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>>
>> I am in the "running the new UHD via sshfs section"
>>
>> I am seeing and using newly compiled
>> UHD(/home/root/usr/bin/uhd_find_devices). So it is ok up to here.
>>
>> When I wrote:
>>
>> *~/usr/usr/lib/uhd/examples/benchmark_rate --tx_rate 1e6*
>>
>> I got:
>>
>> */Error: RuntimeError: Expexted FPGA compatibility number 255.x, but
>> got 14.0: The FPGA build is not compatible with the host code build./*
>>
>> What might be the problem? How can I solve this?
>>
>> _Also, is there any example that I can download. I want an example GRC
>> file which is using e312? (I dont know how to control E312 with
>> gnuradio companion)_
>>
>> Best,
>> Ali
>>
>>
>> _______________________________________________
>> 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: 19
Date: Fri, 17 Mar 2017 20:37:46 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USB 3 hub for B200/B200mini
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 03/17/2017 08:19 PM, Martin Braun via USRP-users wrote:
> I have a D-Link that I've been using for testing, so far no issues. Says
> DUB-1340 on the bottom. That's not an endorsement, though, and maybe
> I've just gotten lucky.
>
> -- M
I've had good luck with Orico hubs. These things change so quickly
though.
In consumer electronics, the device can have the same model number, and
the manufacturer will change the parts line-up in
the middle of the product lifecycle (which is usually about a year)....
>
> On 03/09/2017 07:15 AM, Sean Nowlan via USRP-users wrote:
>> Does anyone have a recommendation for a specific USB 3 hub brand and
>> model that works well with a B200 or B200mini? I'm streaming pretty low
>> rates - 2-4M samples/second - and I'm sure most hubs could do that, but
>> I'm worried about reliability of connections, spurious disconnects, etc.
>>
>> Thanks,
>> Sean
>>
>>
>> _______________________________________________
>> 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: 20
Date: Fri, 17 Mar 2017 22:12:48 -0500
From: Jonathon Pendlum <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Expexted FPGA compatibility number 255.x,
but got 14.0
Message-ID:
<CAGdo0uRHicS32bNKMFbgEU61r-T56oAvU=dzmgzmrgmihhy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Please note that the previous RFNoC images package had an incorrect default
bitstream for the E310. This was corrected in the latest rfnoc-devel image
package and you should *not* see an incorrect compat number with the
current image package.
You likely need to run uhd_images_downloader to get the correct image
package. Otherwise, you will use the original bitstream on the SD card
image which will have the wrong compat number.
On Mar 17, 2017 8:29 PM, "Martin Braun via USRP-users" <
[email protected]> wrote:
Ali,
like Marcus said, it looks like you're trying to run a default image.
That's something we need to fix. There's a 3.10-image in the rfnoc-devel
images package. You can point it to the one called *_RFNOC.bin using
--addr fpga=/path/to/bitfile.
Cheers,
Martin
On 03/14/2017 07:39 AM, Marcus M?ller via USRP-users wrote:
> Hi Ali,
>
> I think you probably know that, but for future readers of this mailing
list:
> The E310/E312 *runs* the python code generated by GRC. Thus, everything
> is happening on the E3xx itself ? aside from the flow graph design.
>
> So, the FPGA compatibility mismatch means you're running a UHD on the
> device which doesn't match the FPGA images that it loads. Is that
> possible? Did you build UHD yourself, or are you running from a "plain"
> Release-4 SD card image?
>
>
> Best regards,
>
> Marcus
>
>
> On 14.03.2017 13:57, do ber via USRP-users wrote:
>> Hi to all,
>>
>> I am currently working on E312. My final goal is to control an e312(if
>> possible multi e312 in the future) with GNURadio companion.
>>
>> I installed SDK. I am following the steps written in here:
>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>>
>> I am in the "running the new UHD via sshfs section"
>>
>> I am seeing and using newly compiled
>> UHD(/home/root/usr/bin/uhd_find_devices). So it is ok up to here.
>>
>> When I wrote:
>>
>> *~/usr/usr/lib/uhd/examples/benchmark_rate --tx_rate 1e6*
>>
>> I got:
>>
>> */Error: RuntimeError: Expexted FPGA compatibility number 255.x, but
>> got 14.0: The FPGA build is not compatible with the host code build./*
>>
>> What might be the problem? How can I solve this?
>>
>> _Also, is there any example that I can download. I want an example GRC
>> file which is using e312? (I dont know how to control E312 with
>> gnuradio companion)_
>>
>> Best,
>> Ali
>>
>>
>> _______________________________________________
>> 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/20170317/ca9f9b01/attachment-0001.html>
------------------------------
Message: 21
Date: Sat, 18 Mar 2017 13:03:34 +0000
From: Benny Alexandar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Audio Synchronization
Message-ID:
<hk2pr02mb1330a22b98cdf4bc2a1c0ddc8b...@hk2pr02mb1330.apcprd02.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I'm implementing the broadcast receiver using USRP & GNU Radio. For audio
synchronization with transmitter clock, should I use the RF local clock base
band arriving sample time or estimate the audio clock after audio decoding ?
How to do the synchronization with audio transmitter clock ?
-ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170318/20f4007b/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 79, Issue 18
******************************************
