Re: [USRP-users] Best path forward on N310

[Marcus D. Leech via USRP-users]

On 10/03/2018 05:22 PM, Lundberg, Daniel via USRP-users wrote:


A bit of background:

I have been using a B205i mini to transmit a variety of pre-computed 
waveforms.  These have ~5 MHz of BW, and I’ve been streamin binary 
files sampled at 6.25 MS/s.  I use a modified version of the 
tx_samples_from_file example, using a host laptop via a USB 3.0 to 
Ethernet adaptor.  The manner in which it is operated allows the 
process to be slow, i.e., it’s OK for me to manually launch a new 
script that selects a different waveform binary file on the host 
laptop each time I want to start transmitting something else.  This 
all works fine.


However, the quality of the waveform is important, and the B205 has 
some noticeable limitations with respect to IQ imbalance resulting in 
unwanted amplitude modulation, phase noise, a 12 bit DAC, etc…  This 
is OK, because it is a <$1000 device, but now it’s time to do better.  
I have an N310 to try, and I am looking for feedback on the best path 
forward.  I understand that the clock rate selections are somewhat 
limited on the N310, but that I should be able to run it in a 
comparable way to the B205 if I allow the N310 to perform 
interpolation, i.e., 125 MS/s with an interpolation factor of 20 for a 
6.25 MS/s input.  This is an OK first step.


So now to my question:

I would like to investigate the transmit quality without the N310’s 
interpolation, because I have no idea exactly how it does this signal 
processing.  So I think the normal path forward there is to set up an 
interface on a host that can stream at 125 MS/s, which is not trivial 
(thunderbolt adaptors, a computer with the right cards, etc…).  I am 
curious if it is possible for me to run the N310 in embedded mode, 
have the waveform files loaded locally on the N310, and issue commands 
to transmit in a loop.  These files are currently ~80MB each, because 
they are ~1.5 seconds sampled at 6.25 MH/s.  They would scale up to 
~1.6 GB if sampled at 125 MS/s with no interpolation.  Is this 
something the N310 hardware could handle in embedded mode, i.e., 
streaming from its own hardware resources, rather than through the 
SFP?  I am finding documentation on the embedded mode of the N310 hard 
to find, but I may just be looking in the wrong places.


Thank you,

DL


There's no way that the embedded CPU on the N310 will be able to stream 
at 125Msps, however the platform supports RFNoC, which means you can

  go from stream to radio without an intervening DUC.

Something to be very much aware of is that the RFIC on the N310, the 
AD9371 is the same overall "family" as the AD9361, but with a couple more

  bits in the DAC.

Have you tried things like offset tuning on the B2xx to reduce the 
effects of the DC-offset removal algorithms, etc?  Are you sure that 
you're not
  saturating things, and causing non-linearity on the RF output? This 
may not be an issue of "it's only a $1K device", but rather, simple 
inadequate

  "tuning" of your application.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Best path forward on N310

[Ali Dormiani via USRP-users]

The N310 SD card has a custom version of open-embedded linux on it with UHD
as well.

You could place your script and binary files in the SD card file system
itself which would resolve streaming to the N310.

The problem is the data generated has no where to go. There is 1 GB of ram
soldered on the N310 motherboard but most of it is used by Linux and it is
not user accessible without some hacks (maybe?).

Therefor if you want to avoid expensive networking gear (TB3 adapters SFP+
ect) The only option is to buy a bigger micro SD card (16 gb for OS, rest
for data generated) that has sufficient sequential write speeds.

SD cards have ratings sort of like food (grade A eggs)

https://www.sdcard.org/developers/overview/speed_class/

Cheers,

Ali Dormiani

On Wed, Oct 3, 2018 at 2:24 PM Lundberg, Daniel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> A bit of background:
>
> I have been using a B205i mini to transmit a variety of pre-computed
> waveforms.  These have ~5 MHz of BW, and I’ve been streamin binary files
> sampled at 6.25 MS/s.  I use a modified version of the tx_samples_from_file
> example, using a host laptop via a USB 3.0 to Ethernet adaptor.  The manner
> in which it is operated allows the process to be slow, i.e., it’s OK for me
> to manually launch a new script that selects a different waveform binary
> file on the host laptop each time I want to start transmitting something
> else.  This all works fine.
>
>
>
> However, the quality of the waveform is important, and the B205 has some
> noticeable limitations with respect to IQ imbalance resulting in unwanted
> amplitude modulation, phase noise, a 12 bit DAC, etc…  This is OK, because
> it is a <$1000 device, but now it’s time to do better.  I have an N310 to
> try, and I am looking for feedback on the best path forward.  I understand
> that the clock rate selections are somewhat limited on the N310, but that I
> should be able to run it in a comparable way to the B205 if I allow the
> N310 to perform interpolation, i.e., 125 MS/s with an interpolation factor
> of 20 for a 6.25 MS/s input.  This is an OK first step.
>
>
>
> So now to my question:
>
> I would like to investigate the transmit quality without the N310’s
> interpolation, because I have no idea exactly how it does this signal
> processing.  So I think the normal path forward there is to set up an
> interface on a host that can stream at 125 MS/s, which is not trivial
> (thunderbolt adaptors, a computer with the right cards, etc…).  I am
> curious if it is possible for me to run the N310 in embedded mode, have the
> waveform files loaded locally on the N310, and issue commands to transmit
> in a loop.  These files are currently ~80MB each, because they are ~1.5
> seconds sampled at 6.25 MH/s.  They would scale up to ~1.6 GB if sampled at
> 125 MS/s with no interpolation.  Is this something the N310 hardware could
> handle in embedded mode, i.e., streaming from its own hardware resources,
> rather than through the SFP?  I am finding documentation on the embedded
> mode of the N310 hard to find, but I may just be looking in the wrong
> places.
>
>
>
> Thank you,
>
> DL
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UHD make failed with osmo-trx binaires on Ubuntu

[Michael Benedict via USRP-users]

Hi all,

I'm having trouble running osmotrx with an Ettus B210. I'm not sure where
the issue is so figured I would ask here.

Running the binary for osmo-trx on Ubuntu 18.04, I see:

:~$ sudo osmo-trx
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

opening configuration table from path :memory:
Config Settings
   Log Level... NOTICE
   Device args.
   TRX Base Port... 5700
   TRX Address. 127.0.0.1
   Channels 1
   Tx Samples-per-Symbol... 4
   Rx Samples-per-Symbol... 1
   EDGE support Disabled
   Reference... Internal
   C0 Filler Table. Disabled
   Multi-Carrier... Disabled
   Diversity... Disabled
   Tuning offset... 0
   RSSI to dBm offset.. 0
   Swap channels... 0

-- Detected Device: B210
-- Operating over USB 3.
ALERT 140391490980800 13:45:44.2 UHDDevice.cpp:799:open: UHD make failed,
device
ALERT 140391490980800 13:45:44.2 UHDDevice.cpp:799:open: UHD make failed,
device
ALERT 140391490980800 13:45:44.2 osmo-trx.cpp:530:main: Failed to create
radio device

ALERT 140391490980800 13:45:44.2 osmo-trx.cpp:530:main: Failed to create
radio device
Shutting down transceiver...

The output is similar with `sudo osmo-trx -a serial=31502DD`, and the
output of uhd_find_devices looks normal to me:

:~$ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.13.0.1-release
--
-- UHD Device 0
--
Device Address:
serial: 31502DD
name: MyB210
product: B210
type: b200

I get similar results with or without the suggested udev rules[1].

Looking at the osmo-trx source[2] I am confused why it would identify the
device and then fail the UHD make step. It seems like
`uhd::usrp::multi_usrp::make`
throws exceptions if the device is not found.

I've been stuck on this for a while and would appreciate any pointers or
ideas of what else to try. In case it helps I'll include the output of
uhd_usrp_probe.

Thanks,
--Michael

[1] https://files.ettus.com/manual/page_transport.html
[2]
https://github.com/osmocom/osmo-trx/blob/74bcc562a9403e224c40a9db77753b81cd412a70/Transceiver52M/device/uhd/UHDDevice.cpp#L632

-

:~$ sudo uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.13.0.1-release
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Detecting internal GPSDO
[INFO] [GPS] No GPSDO found
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
  _
 /
|   Device: B-Series Device
| _
|/
|   |   Mboard: B210
|   |   revision: 4
|   |   product: 2
|   |   serial: 31502DD
|   |   name: MyB210
|   |   FW Version: 8.0
|   |   FPGA Version: 15.0
|   |
|   |   Time sources:  none, internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: A
|   |   |   |   Name: FE-RX2
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: B
|   |   |   |   Name: FE-RX1
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: B210 RX dual ADC
|   |  

Re: [USRP-users] B200 FPGA usage between 3.9 and 3.13

[Michael West via USRP-users]

Hi Silvain,

Thank you for letting us know.  That is quite a jump in utilization.  We
will take a look when we have some time.

We did recently make recent bug fixes in axi_packet_gate.  It looks like
that, and possibly other changes, inadvertently increased resource
utilization more than expected for B200.  Our priority is always first to
make sure the FPGA images successfully build with the bug fixes so we can
get those bug fixes out to users as soon as possible.  We do try to
minimize resource utilization, but that is a secondary priority.

Regards,
Michael

On Wed, Oct 3, 2018 at 3:19 AM Sylvain Munaut via USRP-users <
usrp-users@lists.ettus.com> wrote:

> And the culprit is axi_packet_gate 
> It actually uses so much more BRAMs than the MAP process replaces some
> of the inferred BRAM by inferred dist ram instead to fit everything in
> a B200.
>
> Not sure why this now needs some much more resources than it did before.
>
> Cheers,
>
> Sylvain
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Messaging the DDC

[Jason Matusiak via USRP-users]

Marcus, Looking a little closer, I am a little confused.
 
I can make the change, and that allows the message block to appear in GRC, but 
I am thinking that I need to uncomment the argument commands that set the DDS 
value, right?  I don't see how it would work otherwise (Though it can be poked 
in via a variable, so I am not sure why that would work).
 
 
- Original Message - Subject: RE: Re: [USRP-users] Messaging 
the DDC
From: "Jason Matusiak" 
Date: 10/3/18 9:27 am
To: "Marcus Mller" , usrp-users@lists.ettus.com

 Sorry, Marcus, I was out yesterday and then missed these responses.
 
That is great!  I'll give it a try today and report back!
 
- Original Message - Subject: Re: [USRP-users] Messaging the DDC
From: "Marcus Mller via USRP-users" 
Date: 9/30/18 4:47 pm
To: usrp-users@lists.ettus.com

Hi Jason,
 
 I was about to write code, but then realized: gr-ettus' Block impl
 already has what you need, the message port "rfnoc", which'll accept
 messages in the PMT dict format. You can extract the shape of
 information you need to send in from the  tags in
 uhd_rfnoc_ddc.xml.
 
 I'm attaching what I hope will fix your problem as a patch (use with
 `git apply` from within gr-ettus). We'll most likely upstream a more
 general changeset.
 
 Best regards,
 Marcus
 
 On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote:
 > I have a block that outputs a message with a frequency. I would love
 > to be able to set the frequency adjustment in the RFNoC DDC, but I
 > don't see a way to do it it automagically.
 > 
 > I am guessing that there is no way to do it even though it can be set
 > from a variable slider easily. Is there an option I am missing?
 > ___
 > USRP-users mailing list
 > USRP-users@lists.ettus.com
 > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RuntimeError: Expected FPGA compatibility number 14, but got 15 in GRC

[Marcus D. Leech via USRP-users]

On 10/03/2018 11:03 AM, ogün levent wrote:

Warning message can be seen in the attachments.
I'm going to guess that you have two different installations of UHD on 
your system, or a "half-and-half" situation.


Did you get any errors when you ran uhd_images_downloader?




ogün levent mailto:levento...@gmail.com>>, 3 
Eki 2018 Çar, 17:54 tarihinde şunu yazdı:


Yes. We are trying to run the brand new device for the first time.

Marcus D. Leech via USRP-users mailto:usrp-users@lists.ettus.com>>, 3 Eki 2018 Çar, 17:52
tarihinde şunu yazdı:

On 10/03/2018 10:45 AM, ogün levent via USRP-users wrote:
> Hello there,
>
> Recently I received B210 and went through the installation
guide on
> the ettus website and loaded fpga images
uhd_images_downloader and
> everything seemed fine. When I tried to run a flowgraph I
recieved
> Runtime error. Is it because of the fpga image version? If
so is it
> possible to change fpga .bin file? How can I solve the problem?
>
> Best
>
Did you power-cycle your USRP after loading new images?



___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RuntimeError: Expected FPGA compatibility number 14, but got 15 in GRC

[ogün levent via USRP-users]

Yes. We are trying to run the brand new device for the first time.

Marcus D. Leech via USRP-users , 3 Eki 2018
Çar, 17:52 tarihinde şunu yazdı:

> On 10/03/2018 10:45 AM, ogün levent via USRP-users wrote:
> > Hello there,
> >
> > Recently I received B210 and went through the installation guide on
> > the ettus website and loaded fpga images uhd_images_downloader and
> > everything seemed fine. When I tried to run a flowgraph I recieved
> > Runtime error. Is it because of the fpga image version? If so is it
> > possible to change fpga .bin file? How can I solve the problem?
> >
> > Best
> >
> Did you power-cycle your USRP after loading new images?
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RuntimeError: Expected FPGA compatibility number 14, but got 15 in GRC

[Marcus D. Leech via USRP-users]

On 10/03/2018 10:45 AM, ogün levent via USRP-users wrote:

Hello there,

Recently I received B210 and went through the installation guide on 
the ettus website and loaded fpga images uhd_images_downloader and 
everything seemed fine. When I tried to run a flowgraph I recieved 
Runtime error. Is it because of the fpga image version? If so is it 
possible to change fpga .bin file? How can I solve the problem?


Best


Did you power-cycle your USRP after loading new images?



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RuntimeError: Expected FPGA compatibility number 14, but got 15 in GRC

[ogün levent via USRP-users]

Hello there,

Recently I received B210 and went through the installation guide on the
ettus website and loaded fpga images uhd_images_downloader and everything
seemed fine. When I tried to run a flowgraph I recieved Runtime error. Is
it because of the fpga image version? If so is it possible to change fpga
.bin file? How can I solve the problem?

Best
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Messaging the DDC

[Jason Matusiak via USRP-users]

Sorry, Marcus, I was out yesterday and then missed these responses.
 
That is great!  I'll give it a try today and report back!
 
- Original Message - Subject: Re: [USRP-users] Messaging the DDC
From: "Marcus Mller via USRP-users" 
Date: 9/30/18 4:47 pm
To: usrp-users@lists.ettus.com

Hi Jason,
 
 I was about to write code, but then realized: gr-ettus' Block impl
 already has what you need, the message port "rfnoc", which'll accept
 messages in the PMT dict format. You can extract the shape of
 information you need to send in from the  tags in
 uhd_rfnoc_ddc.xml.
 
 I'm attaching what I hope will fix your problem as a patch (use with
 `git apply` from within gr-ettus). We'll most likely upstream a more
 general changeset.
 
 Best regards,
 Marcus
 
 On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote:
 > I have a block that outputs a message with a frequency. I would love
 > to be able to set the frequency adjustment in the RFNoC DDC, but I
 > don't see a way to do it it automagically.
 > 
 > I am guessing that there is no way to do it even though it can be set
 > from a variable slider easily. Is there an option I am missing?
 > ___
 > USRP-users mailing list
 > USRP-users@lists.ettus.com
 > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B200 FPGA usage between 3.9 and 3.13

[Sylvain Munaut via USRP-users]

And the culprit is axi_packet_gate 
It actually uses so much more BRAMs than the MAP process replaces some
of the inferred BRAM by inferred dist ram instead to fit everything in
a B200.

Not sure why this now needs some much more resources than it did before.

Cheers,

Sylvain

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Can't detect usrp in VMWare Player

[dapodun nudopad via USRP-users]

I run ubuntu on VMWare Workstation Player 15 in a windows 10 host. However
i connected usrp to the port using a gigabit ethernet cable and i can't
ping nor find the uh using uhd_find_device. Does anyone has a solution to
this matter.
thanks.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] B200 FPGA usage between 3.9 and 3.13

[Sylvain Munaut via USRP-users]

Hi,


Before I spend possibly hours tracing this, I was wondering if someone
had an obvious reason for which the FPGA base design size for the B200
increases significantly between 3.9 and 3.13 ?

Just a few examples :

Number used as Memory: 4004  out of  1107236%
Number used as Memory: 5440  out of  1107249%

Number of LUT Flip Flop pairs used:  24062
Number of LUT Flip Flop pairs used:  29549

Number of Block RAM/FIFO:  144  out of17283%
Number of Block RAM/FIFO:  170  out of17298%

AFAIK, the b200 hasn't really gained much (anything ?) in
functionality so ... am I missing something?


Cheers,

Sylvain

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com