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: X310 Transmit Burst Issues (Merlin Chlosta)
2. Re: Timed Commands with RFNoC Radios (Martin Braun)
3. Re: X310 Transmit Burst Issues (Michael West)
4. Re: Ettus B200 frequency control (Derek Kozel)
5. [Announcement] X300/X310 Dual 10GigE Streaming (Rx) (Martin Braun)
6. [Announcement] X300/X310 Dual 10GigE Streaming (Rx) (Martin Braun)
7. Re: [Announcement] X300/X310 Dual 10GigE Streaming (Rx)
(Martin Braun)
8. Re: Failure to receive ACK packets (Marcus M?ller)
9. Re: X310 UBX Tx issues (Marcus M?ller)
10. Re: X310 UBX Tx issues (Neel Pandeya)
----------------------------------------------------------------------
Message: 1
Date: Mon, 18 Apr 2016 18:23:01 +0200
From: Merlin Chlosta <[email protected]>
To: Michael West <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] X310 Transmit Burst Issues
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 30.03.2016 20:39, Michael West via USRP-users wrote:
> Hi Carel,
>
> I'm glad the patch fixed part of your issue. Those changes will not be
> incorporated into UHD. Some users want the power savings and lower noise
> that turning off the components provides and some users, such as yourself,
> want the performance aspects keeping them on provides. The UHD default is
> generally for lower noise. You don't need the patch, though. You can use
> the multi_usrp::set_gpio_attr() method in your application code to do the
> same thing that the patch does. Just be sure to call the function after
> each tuning as the values may get reset during tuning.
Patching the driver works pretty good, but I tried the set_gpio_attr() approach
as well and failed.
My application switches frequencies and then immediately sends a single data
burst, one burst for each center frequency. The problem with the
multi_usrp::set_gpio_attr() approach might be that the ATR is set to
powersaving for a short period of time, between the tune request and my
application's set_gpio_attr() call. This means I cannot use fast frequency
hopping with burst transmission mode without patching the driver.
Are my observations correct so far? Is there another method that will
completely prevent powersaving, even for those short periods of time after a
frequency tune?
I understand this is pretty specific, but maybe it helps others if they happen
to do burst transmissions + frequency hopping.
Regards,
Merlin Chlosta
>
> As for the buffering issue, samples at the end of the burst will be left in
> the DUC chain so it is necessary to zero pad the end of each burst. The
> amount of zero padding may need some calibration.
>
> Regards,
> Michael
------------------------------
Message: 2
Date: Mon, 18 Apr 2016 10:32:47 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Timed Commands with RFNoC Radios
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Sam,
maybe you have old SWIG artefacts or something like that..?
set_command_time() is a method of rfnoc_radio. You can check your
include/ettus/rfnoc_radio.h to corroborate that.
Cheers,
M
On 04/15/2016 04:03 PM, Sam Carey via USRP-users wrote:
> Howdy,
>
> I?ve been trying to use timed commands with the RFNoC radio blocks
> (rfnoc-devel branch), but I can?t find that feature. If I were using
> normal uhd radios, I would do something like:
>
> self.uhd_usrp_sink_0.set_command_time(uhd.time_spec(2.0))
> self.uhd_usrp_sink_0.set_center_freq(freq_center, 0)
> self.uhd_usrp_sink_0.clear_command_time()
>
> self.uhd_usrp_source_0.set_command_time(uhd.time_spec(2.0))
> self.uhd_usrp_source_0.set_center_freq(freq_center, 0)
> self.uhd_usrp_source_0.clear_command_time()
>
> However, if I try to use RFNoC radios:
>
> self.uhd_rfnoc_streamer_radio_1.set_command_time(uhd.time_spec(2.0))
> self.uhd_rfnoc_streamer_radio_1.set_tx_freq(freq_center)
> self.uhd_rfnoc_streamer_radio_1.clear_command_time()
>
> self.uhd_rfnoc_streamer_radio_0.set_command_time(uhd.time_spec(2.0))
> self.uhd_rfnoc_streamer_radio_0.set_rx_freq(freq_center)
> self.uhd_rfnoc_streamer_radio_0.clear_command_time()
>
> It throws errors like:
> AttributeError: ?rfnoc_radio_sptr? object has no attribute
> ?set_command_time?
>
> I looked in gr-ettus/build/swig/ettus_swig.py and did not see
> ?set_command_time()? listed under "class rfnoc_radio,? although I did
> see ?set_rx_freq().?
>
> Could you please explain how I can use timed commands with RFNoC radios?
>
> Thanks,
> Sam Carey
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Mon, 18 Apr 2016 10:42:42 -0700
From: Michael West <[email protected]>
To: Merlin Chlosta <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 Transmit Burst Issues
Message-ID:
<cam4xkrqeaqo_7jq7mw1ccgevnsj9dns+0vqkuxirsdrnmnb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Merlin,
Your observations are correct. If you tune while idle, it will go into the
powersave mode until you set the ATR settings. However, if you retune and
set the ATR settings while transmitting/receiving (you can transmit zeros
and/or discard received samples), it will never go into the power savings
mode. Not the best workaround, but it should work.
We introduced a notion of a power mode in the UBX daughterboard that allows
for a powersave or performance setting. Unfortunately, porting that
feature to the other daughterboards is a non-trivial task. I will forward
your interest in the feature to the Ettus R&D team.
Regards,
Michael
On Mon, Apr 18, 2016 at 9:23 AM, Merlin Chlosta <
[email protected]> wrote:
> On 30.03.2016 20:39, Michael West via USRP-users wrote:
> > Hi Carel,
> >
> > I'm glad the patch fixed part of your issue. Those changes will not be
> > incorporated into UHD. Some users want the power savings and lower noise
> > that turning off the components provides and some users, such as
> yourself,
> > want the performance aspects keeping them on provides. The UHD default
> is
> > generally for lower noise. You don't need the patch, though. You can
> use
> > the multi_usrp::set_gpio_attr() method in your application code to do the
> > same thing that the patch does. Just be sure to call the function after
> > each tuning as the values may get reset during tuning.
>
> Patching the driver works pretty good, but I tried the set_gpio_attr()
> approach as well and failed.
>
> My application switches frequencies and then immediately sends a single
> data burst, one burst for each center frequency. The problem with the
> multi_usrp::set_gpio_attr() approach might be that the ATR is set to
> powersaving for a short period of time, between the tune request and my
> application's set_gpio_attr() call. This means I cannot use fast frequency
> hopping with burst transmission mode without patching the driver.
>
> Are my observations correct so far? Is there another method that will
> completely prevent powersaving, even for those short periods of time after
> a frequency tune?
>
> I understand this is pretty specific, but maybe it helps others if they
> happen to do burst transmissions + frequency hopping.
>
> Regards,
> Merlin Chlosta
>
> >
> > As for the buffering issue, samples at the end of the burst will be left
> in
> > the DUC chain so it is necessary to zero pad the end of each burst. The
> > amount of zero padding may need some calibration.
> >
> > Regards,
> > Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160418/eaf6e69d/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 18 Apr 2016 14:12:47 -0700
From: Derek Kozel <[email protected]>
To: numeric <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Ettus B200 frequency control
Message-ID:
<CAA+K=ts+pqgulgla-vcrnf-v+qsoaho2uszeopv34bl6nwc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Rob,
The B200, and all other USRPs, is directly controlled by UHD [1]. The EXTIO
wrapper on UHD is not written by Ettus and I don't have in depth knowledge
about it. I'd recommend reading the header files from the EXTIO SVN
repository [2]. The arguments to any of the UHD calls can be found in the
manual [3].
If you are trying to use the same USRP from two processes you will need to
write your own code to merge the control commands from your application and
HDSDR, only one instance of UHD can access a USRP per session.
Let me know if you have any other questions.
Derek
[1] https://github.com/EttusResearch/uhd
[2] http://svn.spench.net/main/USRP/Winrad/
[3] http://uhd.ettus.com
On Wed, Apr 6, 2016 at 9:57 PM, numeric via USRP-users <
[email protected]> wrote:
> Hello,
>
> I am using the B200 USRP board to view the ATSC RF spectrum I am using
> the HDSDR software with ExtIO_USRP.dll to control the B200. Works fine,
> I can view several channels at once.
> However, I would like to enhance the capability. I have created an
> application, written in Pascal for Windows 10, to convert frequency to
> channel and channel to frequency. I would like the B200 change frequency
> from my application and also tune from HDSDR. There are some exports in
> ExtIO_USRP.dll that may work:
>
> SetHWLO64 = _SetHWLO64@8
> SetHWLO = _SetHWLO@4
>
> However I have not found where I can find the .h file that normally
> explains the exports arguments and initialization procedure. Since HDSDR
> initializes the B200,
> 1. How do I access the same memory space for dual control?
>
> I have successfully created an extio.dll file, about 5 years ago, to
> interface with other hardware. Also have used a command line interface
> for other hardware; but never used "client server" or IP software
> methods. I do not get "client server" or IP stuff and would rather find
> a solution with ExtIO_USRP.dll, Windows 10 only and Pascal only.
> Any help is greatly appreciated.
>
> Rob
>
> _______________________________________________
> 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/20160418/c3bd0545/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 18 Apr 2016 17:15:59 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] [Announcement] X300/X310 Dual 10GigE Streaming
(Rx)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Everyone,
the latest push to master provides some code to stream over both 10GigE
connections of an X3x0 at the same time, for receiving 2x200Msps. You
will be able to test this by pulling and building master and then
following these steps:
- Run uhd_images_downloader to get the latest master images.
- Burn an XG image on to your device. Quick reminder: By default, we
provide "HG" images ("hybrid") which allow both 1GigE and 10GigE (on
ports 0 and 1 of your devices, respectively). For this functionality you
will need 2x10GigE, which is provided by the XG image.
- Instantiate your USRP session using the 'second_addr' device argument.
If you want to try our benchmark_rate utility (which is an excellent
idea as a first stop), this would be a valid invocation:
$ benchmark_rate --args addr=192.168.30.2,second_addr=192.168.40.2
--channels 0,1 --rate 200e6
(Change the addresses according to your setup,
- Your system might get crushed by the sheer burden of data coming at it
and it is possible that you will see packets getting dropped by the NIC
(this will show as Ds when running a UHD application). We were able to
circumvent this by increasing the number of descriptors used by the NIC,
which you can do using ethtool:
$ sudo ethtool -G <interface> tx <N> rx <N>
...where N is a bigger number than the default (e.g. 4096). `ethtool -g`
will show you valid values.
Other NIC tuning parameters might apply on your system. We used an Intel
82599ES on an Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz.
*Please note:*
- You're dealing with a *lot* of data at this point. It's very easy to
see overruns when you're actually doing signal processing on the other
end. Writing to disk will take some extremely fast hard disk setup and
most likely some more kernel-level tuning of your system. Other setups
will definitely require smart threading and deferred handling of data.
- This is a receive-only feature at this point.
Cheers,
Martin
------------------------------
Message: 6
Date: Mon, 18 Apr 2016 17:15:59 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] [Announcement] X300/X310 Dual 10GigE Streaming
(Rx)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Everyone,
the latest push to master provides some code to stream over both 10GigE
connections of an X3x0 at the same time, for receiving 2x200Msps. You
will be able to test this by pulling and building master and then
following these steps:
- Run uhd_images_downloader to get the latest master images.
- Burn an XG image on to your device. Quick reminder: By default, we
provide "HG" images ("hybrid") which allow both 1GigE and 10GigE (on
ports 0 and 1 of your devices, respectively). For this functionality you
will need 2x10GigE, which is provided by the XG image.
- Instantiate your USRP session using the 'second_addr' device argument.
If you want to try our benchmark_rate utility (which is an excellent
idea as a first stop), this would be a valid invocation:
$ benchmark_rate --args addr=192.168.30.2,second_addr=192.168.40.2
--channels 0,1 --rate 200e6
(Change the addresses according to your setup,
- Your system might get crushed by the sheer burden of data coming at it
and it is possible that you will see packets getting dropped by the NIC
(this will show as Ds when running a UHD application). We were able to
circumvent this by increasing the number of descriptors used by the NIC,
which you can do using ethtool:
$ sudo ethtool -G <interface> tx <N> rx <N>
...where N is a bigger number than the default (e.g. 4096). `ethtool -g`
will show you valid values.
Other NIC tuning parameters might apply on your system. We used an Intel
82599ES on an Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz.
*Please note:*
- You're dealing with a *lot* of data at this point. It's very easy to
see overruns when you're actually doing signal processing on the other
end. Writing to disk will take some extremely fast hard disk setup and
most likely some more kernel-level tuning of your system. Other setups
will definitely require smart threading and deferred handling of data.
- This is a receive-only feature at this point.
Cheers,
Martin
------------------------------
Message: 7
Date: Mon, 18 Apr 2016 17:37:56 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] [Announcement] X300/X310 Dual 10GigE
Streaming (Rx)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 04/18/2016 05:15 PM, Martin Braun wrote:
> *Please note:*
> - You're dealing with a *lot* of data at this point. It's very easy to
> see overruns when you're actually doing signal processing on the other
> end. Writing to disk will take some extremely fast hard disk setup and
> most likely some more kernel-level tuning of your system. Other setups
> will definitely require smart threading and deferred handling of data.
> - This is a receive-only feature at this point.
I forgot one major point: Our daughterboards have a max analog bandwidth
of 120 MHz or 160 MHz (UBX). Please keep that in mind.
Cheers,
Martin
------------------------------
Message: 8
Date: Tue, 19 Apr 2016 17:36:01 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Failure to receive ACK packets
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Yahia Shabara,
You'll need to tell us a bit about your system? How do the different
nodes access the medium, is it a FDD or a TDD scheme, or are you
aloha'ing when ACKing packets?
Best regards,
Marcus
On 03/23/2016 04:27 PM, Yahia Shabara via USRP-users wrote:
> Hello everybody,
>
> I have implemented a simple network that uses packet based
> transmission and I encountered a strange behavior that I hope you
> could help me understand.
>
> The network consists of four nodes. Two of which are using packet
> feedback (i.e. packet acknowledgment / negative ACK). Every time a
> data packet is transmitted, the transmitter (TX) waits for an ACK
> packet to proceed with the following packet transmission. If no ACK
> (or a NACK) is received, the TX re-transmits the previous packet.
>
> When the receiver sends the packet ACK immediately after the data
> packet is successfully received, the ACK is never received by the TX.
> As a trial to solve this, I introduced a 50ms delay before the
> receiver sends the ACK packet, only then the transmitter is able to
> receive the ACK.
> I also tried to use two different USRPs; one as a transmitter and the
> other as a receiver. As a result, I could make the communication work
> with only 10 ms introduced delay.
>
> I cannot figure out why the delay solved the problem and I would
> really appreciate your help.
>
> I am using N210 rev4 USRPs and GNURadio
> FW Version: 12.4
> FPGA Version: 11.1
> Along with SBXv3 daughter-board.
>
> Output of uname -a is:
> Linux yahia-ThinkPad-T430 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri
> Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> I use gmsk modulation, with bit rate = 0.5Mbps and SPS = 2
>
> Thanks,
>
>
> _______________________________________________
> 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/20160419/9d02bd5e/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 19 Apr 2016 17:39:59 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310 UBX Tx issues
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Tilla,
I totally got lost in the discussions involving you, of which some were
off-list; has this been addressed?
Best regards,
Marcus
On 04/04/2016 05:59 PM, tilla--- via USRP-users wrote:
> Platform:
> Win 7 64 bit
> UHD 3.9.2
> Visual Studio 2015 Update 1
> X310 with UBX-160
> 10Gb interface
>
> I am porting my hardware platform from WBX-120 cards over to UBX-160.
>
> There are some strange things going on with UBX-160.
>
> Looking at the output signal on a spectrum analyzer zero span 1 MHz BW
> at center frequency, the noise floor is about -75 dbm.
>
> executing the command tx_waveforms --args addr=192.168.40.2 --rate
> 10000000 --freq 300000000
>
> When the app starts, signal level goes to about -70 dbm for 1 second,
> then -48 dbm for about 2 seconds, then to -15 dbm for the remainder of
> the application execution. Upon control-c of the application to halt,
> a signal is still being transmitted by the card at -53 dbm.
>
> When run on a WBX-120, none of these startup or shutdown artifacts are
> present.
>
> Seems to be present on all frequencies at varying amplitudes.
>
> I have tried this on multiple X310s and multiple UBX cards, all
> exhibit the same performance.
>
> Is this something you guys are aware of?
>
> Thanks,
>
>
>
> _______________________________________________
> 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/20160419/f01b0673/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 19 Apr 2016 08:45:25 -0700
From: Neel Pandeya <[email protected]>
To: tilla <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] X310 UBX Tx issues
Message-ID:
<CACaXmv9sVa9i3k7FdE_AQMB=bz8646qhlmrhwqjnzy3cljk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Tilla:
Which version of UHD are you using?
Could you please post the output of "uhd_usrp_probe" ?
I will try to reproduce the issue.
--Neel Pandeya
On 4 April 2016 at 08:59, tilla--- via USRP-users <
[email protected]> wrote:
> Platform:
> Win 7 64 bit
> UHD 3.9.2
> Visual Studio 2015 Update 1
> X310 with UBX-160
> 10Gb interface
>
> I am porting my hardware platform from WBX-120 cards over to UBX-160.
>
> There are some strange things going on with UBX-160.
>
> Looking at the output signal on a spectrum analyzer zero span 1 MHz BW at
> center frequency, the noise floor is about -75 dbm.
>
> executing the command tx_waveforms --args addr=192.168.40.2 --rate
> 10000000 --freq 300000000
>
> When the app starts, signal level goes to about -70 dbm for 1 second, then
> -48 dbm for about 2 seconds, then to -15 dbm for the remainder of the
> application execution. Upon control-c of the application to halt, a signal
> is still being transmitted by the card at -53 dbm.
>
> When run on a WBX-120, none of these startup or shutdown artifacts are
> present.
>
> Seems to be present on all frequencies at varying amplitudes.
>
> I have tried this on multiple X310s and multiple UBX cards, all exhibit
> the same performance.
>
> Is this something you guys are aware of?
>
> Thanks,
>
>
> _______________________________________________
> 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/20160419/76f9f217/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 68, Issue 20
******************************************
