UHD Driver and USRP B100

[Rash]

Dear all,

I have noticed that Ettus are selling a new, low cost USRP (the B100)
bundle with a WBX board for $850 and I really want to buy
one...however if is isn't going to work, it is still quite a lot to
spend on something to prop the door open!

So, my question is has anyone managed to get the UHD driver working
properly and reliably for realtime modulation and equally important -
has anyone else any experiences of success or disaster with the USRP
B100?


Best regards,

Rash.

[Alex To]

Hi,

Please provide more details for e.g. what do you need to achieve what that board. USRP is a Universal Software Radio platform so you could do pretty much a lot of things. And on which OS do you intend to run it on?

I don't have B100 but I have USRP1 https://www.ettus.com/product/details/USRP-PKG. I am able to use it with GNU Radio and CRC-Tool to transmit DAB, receive FM signal on Linux etc...

I have a new project launching internally to use it with our DAB multiplexer to transmit DAB on Windows however it is not yet started so I can't tell you much about the result.

Regards

Alex

[Rashid Mustapha]

Apologies - I assumed way too much.

My intention is to use mmbtools and on Ubuntu Linux (probably 10.04
LTS on account the desktop is waaay nicer :-P) with the objective to run the
CRC-DABmod in realtime playing out an ETI file or ETIoIP feed.

I doubt I need to do anything with GNURadio, but I will update it anyway.

R.

[Alex To]

I didn't try ETIoIP and B100.

As mentioned I only have USRP1 but B100 is being delivered to my office and probably will reach in 1, 2 weeks time.

I tried playing ETI or IQ Baseband using CRC-DabMod on Ubuntu and it works fine with USRP1.

If you are not in a hurry to get B100, I maybe able to let you know after I try B100.

Regards

Alex

[Coinchon, Mathias]

Hi,

We are testing the B100 with mmTools.
A new baseband player to drive USRP is needed. I have posted 2 of them (one graphical and one non-graphical) here:
http://www.opendigitalradio.org/index.php/DAB_modulation

The B100 has a slightly better spectrum than the USRP1 because of half-band filter in the transmission chain.

However, in my experience so far, the UHD driver with the B100 is not as stable as the gnuradio classic USRP1 driver (that unfortunately gets removed from gnuradio version 3.5).
Ettus is working on improving it and the latest test version I've tried is much better. However the baseband player must run with "realtime" option.
It works well but you need a powerful machine and take care of not having any other device on the same USB bus.

For this reason, we continue working with classic USRP1 driver at the moment for our live broadcast transmission.

In the long term UHD will be the only way to go as all other will be deprecated and new Ettus products only work with it.

Regards

Mathias Coinchon

Dear all,

Best regards,

Rash.
------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************

[Rashid Mustapha]

Well it seems when they sort out the driver, the B100 will actually be slightly better! By cleaner spectrum, do you just mean harmonic energy, or is the MER better too? :-)

I'd be curious to know how powerful a machine is needed - I was hoping to run it on a dual core Atom 1.6, but by the sound of it I can forget that thought!

Thank you both for your input, and Mathias - keep up the good work!

Regards,

Rash.

[Coinchon, Mathias]

Hi,

 

By cleaner spectrum, I mean that you don't have these small spurious remains at the boundaries of the sampling bandwidth.

With USRP1, as I have understood, they have a less powerful FPGA and didn't implement half-band filter for transmission.

The results is that if you run at lower sampling frequencies like 2Msamples/s, more close to DAB bandwidth you get them stronger. If you run at higher sampling rate like 3.2Msamples as we do, they get less present.

 

Testing the B100 a 2Msamples/s you don't get these spurious components.

 

You could try to run it on an Atom but this may be difficult, I never tried. A lot of processing power of crc-dabmod is used for resampling, if you can avoid it , you can decrease CPU use a lot but then you need to have a USRP clock running at a multiple of 2.048MHz.

The B100 has a programmable clock so could in theory do that but I have never tested.

 

Regards

 

Mathias

[Pascal Charest]

Hum... from past experience I would say that the Atom 1.6 is not
powerful enough to run CRC-DabMod in real-time, whichever version of
USRP you get. By the way, it is the same with a Pentium M 175.

I've once tried CRC-DabMod on a Acer AspireRevo AR3610 and the CPU was
unable to keep up. Only one core is used as CRC-DabMod is single
threaded. To limit the CPU power requirement, I've changed the hardware
clock of the USRP1 so that no resampling was required; it is the
building block that requires the most CPU power. Even doing that, the
processor was not powerful enough.

Regards,

Pascal

Rashid Mustapha wrote:
>
> Well it seems when they sort out the driver, the B100 will actually be
> slightly better! By cleaner spectrum, do you just mean harmonic
> energy, or is the MER better too? :-)
>
> I'd be curious to know how powerful a machine is needed - I was hoping
> to run it on a dual core Atom 1.6, but by the sound of it I can forget
> that thought!
>
> Thank you both for your input, and Mathias - keep up the good work!
>
> Regards,
>
> Rash.
>
> On Feb 9, 2012 4:38 PM, "Coinchon, Mathias" <coin...@ebu.ch

[Rashid Mustapha]

That is unsurprising...on that basis I would probably be better off with a single core P4 at 3GHz!

I have decided to take the plunge and get a B100 - I can think of so many uses for it as well as the principle driver - being able to try mmbtools end-to-end as I can probably use it as a crude spectrum analyser with tracking generator.....now those don't come cheaply enough anyway!

There! I've convinced myself it is an essential tool, and therefore a good investment!

Best regards,

Rash.

[Pascal Charest]

Rashid Mustapha wrote:
>
> That is unsurprising...on that basis I would probably be better off
> with a single core P4 at 3GHz!
>

Exactly! I think that our first demo was working on a P4, but I can't
remember the frequency.

Pascal

> I have decided to take the plunge and get a B100 - I can think of so
> many uses for it as well as the principle driver - being able to try
> mmbtools end-to-end as I can probably use it as a crude spectrum
> analyser with tracking generator.....now those don't come cheaply
> enough anyway!
>
> There! I've convinced myself it is an essential tool, and therefore a
> good investment!
>

> On Feb 9, 2012 6:56 PM, "Pascal Charest" <pascal....@crc.ca

--
Pascal Charest
Research Engineer Ingénieur en recherche
Communications Research Centre Centre de recherches sur
Canada les communications Canada
3701 Carling Ave. 3701, avenue Carling
PO Box 11490, Station H CP 11490, succursale H
Ottawa, Ontario Ottawa, Ontario
Canada K2H 8S2 Canada K2H 8S2
Tel: (613) 998-2479 Tél.: (613) 998-2479
Fax: (613) 993-9950 Téléc.: (613) 993-9950
Email: pascal....@crc.ca Cour.: pascal....@crc.ca
Web site: www.crc.ca Site web: www.crc.ca
Government of Canada Gouvernement du Canada

[Rashid Mustapha]

Well, I have ordered the B100...I will report my findings! :-)

[Rashid Mustapha]

Well I am having some trouble getting this to work!

Problem is that I have little to go on to find the problem, which is
at the USRP end
I believe. A process of elimination tells me this...

I performed a tiny mod to Mathias's UHD player code to change the
Device Address from
usrp1 to b100, and built new python code which made everything appear
to work - I am
getting a stable fft plot, and a solid 'A' led on the unit, but mostly
no signal on the test
receivers - two different ones, for the avoidance of any doubt!

It eventually detects the ensemble, and I get the occasional burst of
audio, probably
for no longer than 300mS. I know the problem could be anything, unless there is
some fundamental thing about the B100 that I have yet to appreciate! I
was wondering
about clocking for a while, because I understand that the B100 has a
more flexible clock
than the usrp1. I did wonder why the output of dabmod was up-sampled
to 3.2M, when
it is 2.048M native, so again I modded the player code for that and
re-built, but the b100
didn't like it as it could only operate at ~2.062M.

Is there something fundamental I am missing? The UHD driver is freshly
compiled from
git, I have the latest GNURadio....CPU sits at about 53%, and memory
at ~25%. Its a
dual core pentium (lenovo). I have tried other machines too with the
same result.

Wish I had some decent test gear still! I'm wondering if there is some
code I can run on
the other port on the WBX to demod and look at what is going on with
the constellations?

Regards,

Rash.

[Rash]

Gentlemen,

After quite some time struggling with getting any more than 1-200mS of frame-up out of my test chain using a B100, I think I have worked out what is wrong. Under the circumstances it is quite astonishing that it has tried to work at all.

I believe a single, salient difference between the usrp1 and the b100 is the master clock. Usrp1 being fixed at 100 MHz and the B100 is programmable between 10 and 64 MHZ. I changed the devid code in Mathias's baseband player to get it to talk to the B100.

Can anyone suggest if it will work at a lower clock rate? The B100 clock defaults to 64 MHz.....suggestions?

Regards,

Rash.

Sent from my iPhone

[Pascal Charest]

Rashid Mustapha wrote:
> It eventually detects the ensemble, and I get the occasional burst of
> audio, probably
> for no longer than 300mS. I know the problem could be anything, unless there is
> some fundamental thing about the B100 that I have yet to appreciate! I
> was wondering
> about clocking for a while, because I understand that the B100 has a
> more flexible clock
> than the usrp1. I did wonder why the output of dabmod was up-sampled
> to 3.2M, when
> it is 2.048M native, so again I modded the player code for that and
> re-built, but the b100
> didn't like it as it could only operate at ~2.062M.

Hi Rashid,

These are theoretical answers as I've never used something else than
USRP-1 with CRC-Dabmod.

References: http://files.ettus.com/uhd_docs/manual/html/

2.048 M samples per seconds is the native DAB sampling rate

128 M is the base USRP-1 clock
3.2 M is the minimum compatible rate over 2.048M compatible with 128M
The -c option should be used

100M is the base USRP-2 clock
4M should be used for CRC-Dabmod
The -c option should NOT be used

32-64 M is the base USRP-B100 clock (not sure???)
If possible, master clock should be set to 32.768 M and 2.048 should be
used for CRC-Dabmod
The -c option should NOT be used
http://files.ettus.com/uhd_docs/manual/html/usrp_b1xx.html#set-other-rates-uses-internal-vco

Note: The -c option enables a pre-processing filter that is equal to the
USRP-1 resampling building block response. It should not be used for
anything other than for the USRP-1

Regards,

Pascal

[Rashid Mustapha]

Thanks Pascal,

Yes, it isn't 10-64 MHz like I initially thought - it does seem to
accept 32.768 MHz fortunately
so I will give it a go.

The sample rates in Mathias's player are fixed at 3200k, so I will
modify this to 2048k - not sure
if I will have to do anything with the multiply constant though...

I will carry on regardless!

R.

So the player also needs modification to operate at 2048

[Rashid Mustapha]

Update:

It turned out to be trivial to alter the sampling rates in the UHD
dwap, but what I
am struggling with is setting the B100 clock on execution. It is
volatile and needs
the argument each time it is executed.

uhd_usrp_probe --args="master_clock_rate=32768000"

R.

[Rashid Mustapha]

Uh oh...

As suspected, the out-rate goes back to 64 MHz...worse is the sample
rate warning :(

-- USRP-B100 clock control: 10
-- r_counter: 2
-- a_counter: 0
-- b_counter: 20
-- prescaler: 8
-- vco_divider: 5
-- chan_divider: 5
-- vco_rate: 1600.000000MHz
-- chan_rate: 320.000000MHz
-- out_rate: 64.000000MHz
--

UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 2.048000 MSps
Actual sample rate: 2.064516 MSps
-- Loaded /home/sdr/.uhd/cal/tx_iq_cal_v0.1_E1R1BWCXW.csv
-- Loaded /home/sdr/.uhd/cal/tx_dc_cal_v0.1_E1R1BWCXW.csv
>>> gr_fir_ccf: using SSE

[Rashid Mustapha]

I hope eventually this will save many other from this trouble!

Last report, as it is now time for bed.

No joy - nothing :(

B100 clock running at 64 MHz. I figure it is ok because this is 16x oversampling
with crc-dabmod output running at 4M, dwap at 4M.

No errors, and cpu/mem seem happy. Solid TX light on USRP.

I presume it cannot be that the signal is inverted? I'll try to
multiply by minus to
spin the vector in the opposite direction, but I am clutching at straws now!

R.

[Pascal Charest]

I've tested the transmission with the B100 this afternoon. Here is the
instruction using Mathias' script.

Append the option pair in the Device Attr.
1- double click UHD: USRP Sink
2- select Device Attr
3- write "type=b100,master_clock_rate=32768000 "
4- save and compile
5- run CRC-DABMOD with no -r -c options
6- run Mathias script with -r2048000 option
Et voilà!

For options 3, I suggest to also add num_send_frame=128 for better
stability.

Pascal

[Rash]

Thanks Pascal!

I was looking for documentation on the new sink module - I guess not in the right place!

Will try it out after work today, It was annoying knowing what I had to change, but not being able to find it so I am grateful! Thanks also for the stability tweak - I'd like to find the dox for the sink so I can better understand the conversation between the modulator and the B100!

Thanks also to Mathias for his UHD dwap.

Best regards,

Rash.

Sent from my iPhone

[Pascal Charest]

The docs is here:
http://files.ettus.com/uhd_docs/manual/html/

You need to read between lines; every option can be used as comma
separated pair within Device Attr.

Another really useful tips for stability: turn off onDemand CPU
frequency scaling otherwise there is a lot of underruns (you know, UuUu...)

Pascal

[Rashid Mustapha]

Hi Pascal,

I've been digging around in there for some time but couldn't figure how to apply
that argument. I think it is the GNU Radio (especially the UHD sink) that I need
to invest some time in in reading up on.

It works :-) Not impressed with the MER at the moment so I am going to remove
the self-cal files and see if that improves matters.

R.

[Rashid Mustapha]

No improvement, so I have put them back and I'll look into it.

Pleased it is doing something though!

R.

[Rafael Aguilar Gonzalez]

Hi everybody!

i'm working in a proyect about cognitive radio at Universidad Autónoma de San Luis Potosí, but we want to obtain a plataform for simulated our algorithms. I was looking and found Ettus devices. 

I think to shop two USRP B100 & WBX Bundle, i suppose that it's module needs 4 antennas, because has a basic radio with Tx/Rx and  WBX another two antenas. But i'm not sure, i need more information, i sent a e-mail to a sales but he didn't tell me well, i need know all about this and about is MIMO captable. He suggest me other devices obviously more expensive.

The main goal of the project is a communication device on two different frequencies from a primary user aparción as cognitive rado.

Basically simulate cognitvio radio enabled devices.

Really i want to know what i can do with USRP B100 & WBX Bundle or if i'm in a mistake tell me, please help.

Regards

[Pascal Charest]

Hi Rafael,

Wrong mailing list. We don't sale any Ettus product. If you want to get
more information about MIMO, it is also the wrong mailing list. But if
you have questions about CRC-mmbTools and DAB with GnuRadio and the
USRP, this is the perfect list.

Pascal

[Rash]

Hi all,

Has anyone else been trying mmbtools with a USRP B100? I am aware that

[Rash]

Let's try that again shall we....bumpy train! :-)
> Hi all,
>
> Has anyone else been trying mmbtools with a USRP B100? I am aware that the USRP1 is deemed stable, but the B100 seems to be another story entirely!

For the avoidance of any doubt I have tried various machines with different USB chipsets. The current beast is an 8 core monster server with a 1.3GHz FSB and 4GB of fully buffered RAM.

I am still experiencing instability after a period of running.

Dabmod is running at 2048, as is the wave player (I have tried several) including the simple version. My next plan of attack is to remove the FIR filter, as this is the common module that I have put into all players - notably I believe I had less trouble without it, but I have hard coded it in so it is always 'in circuit'.

Anyway, I suppose I am asking if anyone has a B100 which is behaving like it should? If so, which version of UHD are you using, and it would be useful to know about which sampling rates you have and any other strange settings!

In the meanwhile I intend to build a player without the FIR just to see it that behaves any differently.

Any thoughts appreciated - I am losing hair over this now!

Best regards,

Rash.

[Pascal Charest]

Have you tried to use modification that I suggested a while ago?
Changing the size of the Usb buffer can help.

I sometimes have observed similar instability issue when using UHD drivers.

Pascal

[Rash]

Hi Pascal,

Yes, I am using your suggested settings.
I think the usb has a 16k buffer? Maybe increasing it to 128k might make a difference.
At least recompiling the kernel shouldn't take long on this server I am using! :-)

R.

Sent from my iPad

[Pascal Charest]

You shouldn't need to recompile the kernel to apply my suggested
settings, it's all done with the command line. I needed to play with
different values for both variables to find the best match on my system.
For each value there was a sweep spot for making the pair, not higher
nor lower. I expect these pairs to be different on every system.

Pascal

[Rashid Mustapha]

I will hold off then - just running out of ideas! I certainly am keen to avoid introducing any more variables.

I was looking into known USB problems with external drives and flash sticks and noticed the quoted 16k buffer size, and the suggested patch, but I take your point!

In terms of settings, I am assuming you were referring to the arguments for the USRP:

"type=b100,master_clock_rate=32768000,num_send_frame=128"

Or are you referring to something else? I have looked through messages and can't see anything else...hope I've not missed something!

Best regards,

Rash.

[Pascal Charest]

Hum, maybe I forgot to mention the other parameter, send_frame_size. Try
to play with both num_send_frame and send_frame_size. Here is a webpage
explaining different driver parameters.
http://files.ettus.com/uhd_docs/manual/html/transport.html

Pascal

[Rash]

Seems like that was a pretty important parameter!

I think I'll run it for a few days before changing anything else...

Regards,

Rash.

Sent from my iPad

[robox]

Hi Rash,

 

I am looking to order the USRP B100 & wondering if you have had any further luck with this.

 

Regards

Rob

[Rash]

Hi,

Well I did manage to get it quite stable after a lot of fiddling around!

R.

Sent from my iPad

--
You received this message because you are subscribed to the Google Groups "mmbtools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[robox]

That's good to hear Rash,

 

I wonder if I could trouble you for your best settings when I receive & setup the B100.

 

I am guessing that the biggest issue was with the UHD settings.

 

If possible I will try to add to your work & give some help back.

 

Regards

 

Rob

[Rash]

Hi - I tried loads!

I'll have to check what ended up being in the script. It might have been 1023 and 128.

Sent from my iPad

[robox]

 Thanks Rash,

 

It will be great to know your best working script.

 

Regards

 

Rob 

[Rash]

Hi Rob,

That's probably a good starting point. As Pascal said, it's a lot of trial and error and seems to be different on each machine.

Sent from my iPad

--

[Youri Westerman]

Hi,

First of all I'm new here so a short introduction: I'm trying to get mmbTools working with a Ettus B100(WBX daughterboard) through the UHD driver and with the coinwap script instead of the regular dwap.
I have succesfully compiled CRC-DabMod, CRC-DabMux and libFec on Fedora18 (The uhd driver and gnuradio are installed through yum). These all seem to work fine.
So to test sending a DAB+ signal I have used: http://mmbtools.crc.ca/content/view/26/50/ to generate an ETI file, modified the coinwap script using gnuradio-companion to use the options mentioned earlier and am using the following call to start transmitting:
crc-dabmod ./sine_1365497276_477148.eti -l -g1 |~/Documents/coinwap_uhd_full3.py

However I am unable to pick up my channel on all DAB enabled devices I've tried (Samsung Galaxy S, Sensa Pure). My apologies for my inexperience, but I'm looking for a way to find out what is going wrong here. An earlier post stated that the following: type=b100,master_clock_rate=32768000,num_send_frame=128,send_frame_size=1023 should be entered in the Device Attr field of the UHD USRP Sink, but that field does not exist in my version. I tried to put it in the Device Addr field (did not seem logical) and in the Stream Attr field, but am unsure of which field to use. When having the line in Device Addr with send_frame_size set to whatever value I get a segfault and coinwap crashes so I don't think it should be there, then again if I leave it out gnuradio states it has type=usrp1 set.

I would very much like to produce a DAB slideshow, but thought I'd start off getting a good signal reception.

Thanks in advance for your time.

Regards,

Youri

[Rash]

I'm guessing here....

Have you loaded up the .grc file into GNU Radio companion, and built a version for the B100? You'll find the missing bits in there I think. You will also have to alter the sample rate accordingly.

The 128/1023 values can be problematic. Try lowering the 1023 value as if that is to high it seems to give a segmentation fault.

R.

Sent from my iPad

--

[Youri Westerman]

Yes I've loaded the grc file in gnuradio-companion and entered type=b100,master_clock_rate=32768000,num_send_frame=128,send_frame_size=1023 in the Device Addr field of the UHD sync. I'm setting the sample rate through an argument: crc-dabmod ~/Downloads/sine_1365497276_477148.eti -l -g1 |~/Documents/coinwap_uhd_full3.py -r2048000
Instead of 1023, I've tried: 1000, 900, 800, 700, 600, 500, 400, 300, 255, 200, 100, 10 and a bunch of other seemingly random numbers, but it segfaults on me regardless... Without the send_frame_size set it does not segfault.

Youri

Op dinsdag 9 april 2013 21:04:55 UTC+2 schreef Rash het volgende: