HackRF with odr-dabmod

[Rash]

HackRF Christmas Day progress:

Early this morning (so early that I had only just installed the parking meter on my roof :-D) I got to the point of producing some half-way sensible output from HackRF after installing GNURadio on a laptop. The nice thing was building it with the SARS script is that it installs the Osmocom sink automatically, so I am now where I need to be to evaluate the RF output of HackRF. Interestingly the sink expects 32-bit complex floats, which has proven handy - I wonder why the hackrf_transfer utility doesn't have an option for that!

So, Santa has brought you a HackRF (Ha! Not flippin' likely!) for Christmas and you want to get it generating DAB? Do ignore the Chinese instructions that are around on how to do this - its driving loads of stuff way into clipping. I am surprised it produces a viable signal at all, which goes to show how robust a DAB signal is! I used a slider as the digital gain control 0-100u, and found 50u puts in in a comfortable place. On the sink, Ch0 RF gain doesn't seem to do anything (suspicious!) and 20(dB) for both IF and Baseband gain. Any more and bad things happen!

Here is the good news: the BER performance is ok...and thats where it ends. No, not really - HackRF allows me to peek at what is going on way above where the analyser works (its a cheapo 1.5 GHz one, and HackRF goes to 6GHz!) and is a really tool considering it's frequency range and current price. The devil on my shoulder keeps reminding me that it covers a lot more ground than my WBX's...it covers the ISM bands/WiFI for a start.

The bad news (and I am not expecting this to change unless the final amp is not enabled somehow by the sink, but even so that would not change the game) is the level one can obtain while seeing reasonable shoulder performance and spuri is very, very low. Close-in spectral occupancy shows the two main spurs of interest from Fc which sit at about -32dBc. I've observed a similar pair with B100s, but they sit around -60, but I believe I know how to deal with this, so please allow me to explain.

What I do know is that how pronounced they are appears to be affected by sample rate, as these spurs are images which fall inside the passband of the 1.75 MHz filter Running at native 2.048M the BER is still low, but then the spectrum situation looks a whole lot worse than 3.2M, and of course the images move further away, and into the filter stop band...things start looking more promising. Don't turn the filter off, or force it wider as HackRF will produce loads of images way out from Fc if you do, so it would appear that the lowest filter frequency is not quite low enough for our applications...or is it! At 2048k the closest bit of the image to Fc is 1.2 MHz (filter rolls at 1.75 MHz), 32000k puts it at 2.4 MHz, which is into the stop-band but not quite enough. I am sure you can guess my hypothesis for making it go away properly? Yes, we have to try to run odr-dabmod and HackRF at 4096k, which will push the images out to 4.8 MHz from Fc, which is way, way inside the stop-band of the filter...I'm sure this 2x oversampling with our 8-bit DA isn't going to hurt us either. :-)

This has been a really worthwhile piece of work (or fun, depending on how one sees this) as it also tells me the Sergiy modulator could cover the entire band (although it seems to do a good job of that anyway anyway) using the same technique of halving sample resolution and doubling sample rate.

On to the pics...The first, less horrible pic is with 3.2M sampling. Much better but still unusable unless you were trying to warm up a mask filter! For 4096M I will have to produce another IQ samples file - I have a pre-fork dabmod that I know works ok for that. I will try it I suppose its only the same bandwidth going over the wire (USB) as a B100 at 2.048M, so it should be fine, except it might challenge the laptop at this will double the bandwidth right up to the HackRF sink, and there is no way around this unless odr-dabmod had a double sample, half resolution output mode. I dare say, my beloved Odroids may not much like being asked to resample though, so the outlook for using them with HackRF for DAB looks pretty bleak right now, although this could all change if my stubbornness to accept it won't work kicks in.

I forwarded these from my phone so apologies for crappy quality - I've not hooked it up to a computer. I will report my findings at 4096k sampling when I have a chance (and assuming I can make it work!) which should confirm that this is how to do DAB properly with HackRF One.

Best Chrimbo greetings to you all!

Rash.
>
> 3.2M sampling - looking promising but for the low output (which we can fix!) but look at those annoying spurs (I believe these are images falling within the passband of the filter on HackRF...it gets worse, as you will see from the native sample rate tests.
>

[Peter Symonds]

I've had a go with sox again. Still the same results. I found that you could not stop it with the usual Ctrl+C but you had to kill the process. It was using 11% of the CPU on a quad core AMD as well!

Using GNU radio I did find as well that the signal looked a bit cleaner if you didn't hammer the hackrf to the maximum in terms of the IF amplifier, but I did have to move the receiver closer to get the BER back down to 0. I am guessing that would be down to the sensitivity of the receiver.

Those pictures did reconfirm what I was seeing through the RTL-SDR, basically sprogs trying to form each side of the wanted signal but being caught by the filter.

Pete

> 2048k sampling. Close-in image is not all in the filter stop-band.
>

>
> 2048k sampling. Wider span just to show just how bad it currently looks - note the ~2-3dB in-band ripple. I believe this can be fixed by simply running everything with a mad-fast 4MHz (or greater if you are completely crazy) sampling rate.
>


Best Christmas regards to you all!

Rash.

[Rash]

I am there with HackRF now - thanks to Matthias' surprise feature.

The attached shows about as good as it gets for me. In the odr-dabmod .ini file I have enabled the new 's8' output, and running at 4096k with digital gain to 2.4 (as 2.5 starts to clip occasionally, causing a tiny bit of 'splatter' ;-). The baseband filter makes a real noticeable difference worth nearly 5dB at the Δ 970 kHz breakpoint.

The cleanest signal I have so far yet to obtain from HackRF One (and it ain't gonna get many dBs better!) is the one pictured. RF level is approx -25dBm and I say approx because this cheapo analyser only goes out to 1 MHz resolution bandwidth, which is too small integration bandwidth for the signal. There is another RF stage (counterintuitive as it is a=o to turn it on. I'm still quite impressed considering...~40dB down at 970kHz away from Fc is quite respectable! The following command produced this, with the dabmod .ini tweaks:

odr-dabmod -C HackRF.ini |hackrf_transfer -t /dev/stdin -f 216928000 -x 47 -a 1 -s 4096000 -b 1750000

I note this is merely tickling this i3 laptop cpu, so I am sure you can guess what I would like to try next! :-)

Best regards,

Rash.

[Simon Hill]

Hi Rash,

I am waiting on my HackRF One to arrive, with that in mind do you have any key things that would help me on my way to getting my test dab mux up and running?

thanks

Simon

[Rashid Mustapha]

Hi Simon,

 

HackRF One 'works', but I'm not yet certain if the performance is adequate for real world use due to not having enough dynamic range

available, but it certainly works fine for testing purposes. I'll continue looking at it when the jawbreaker I have bought (hopefully!) turns up

as I have returned the loan unit.

 

I'd stay away from ARM devices for your test environment - HackRF does not yet work properly for some (currently unknown) reason.

Also, use Debian. I quite rightly got told off a long time ago for using some exotic version of Ubuntu because it makes it quite difficult for

anyone to help if you run into trouble. I can confirm an i3 laptop running Debian x64 runs all of the tools and HackRF quite smoothly.

 

A good method is to start with building the encoder, and use it to generate a test mp2 file (with some DLS from the MOT Encoder if you

wish, as that can be checked in XPADXpert), next build the multiplexer and use the mp2 file as a looped service in a basic mux config.

Configure the mux to write an ETI file (collecting ETI files from elsewhere is useful!) which then can be used to test the modulator

in isolation when you build it. You can check your ETI file using etisnoop, and XPADXpert also has uses for that too.

 

HackRF can produce reasonable DAB signals with the following sampling rates: 4096k, 6144k and 8192k. The spectral output gets

cleaner the increasing sampling rates help to push the unwanted images increasingly into the stop band of the 1.75 MHz filter . But

watch out for samples dropping at the upper rates as some hardware could struggle. The lower sampling rates are therefore a good

place to start. 

 

Once all of the components have been tested, then try to run the mux and mod together, and then start adding additional services. The

mux will soon let you know if you made a mistake when you try to start it!

 

Once you have a signal, an easy and low-cost way to check your configuration is correct is to get a receiver stick (almost anything based

on an RTL2832u) and use Andreas Gsinn's Dab Player which enables you to see quite a few parameters.

 

I suppose it would be irresponsible of me not to point out that if you are generating *RF, you will need to be absolutely certain that your setup

is exempt due to 'suppressed radiation conditions'. Best practice is to use a faraday cage...otherwise you will need to hold a licence! :-)

 

 

Best regards,

 

Rash. :-D

 

*Planes will fall.

 

 

 

 

--
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/d/optout.

[Rash]

Ahhh!

I need to clarify something as I sense it is causing confusion. I said : 

"HackRF One 'works', but I'm not yet certain if the performance is adequate for real world use due to not having enough dynamic range

available"

By this I mean that I do not have adequate dynamic range available in the spectrum analyser. HackRF does have less dynamic range

than the Ettus boxes by the very nature of it's 8-bit resolution. Re-reading my post made me realise that it is somewhat ambiguous.

8-bit samples are fine - the ETSI spec actually calls for them (due to the limitations of the day, and because of some some distribution

methods in there), but of course more is better. If it is clean to start with, it is easier to keep clean, and clean up.

Humble apologies!

Thinking about it further, I measured shoulder performance to be nearly 40dB, which is similar (and in fact better) than what was achieved

by some first generation modulators, so that probably isn't a big deal. I'm more worried about the IQ balance as I have observed some carrier 

leakage, and I'm looking into possible ways of addressing that.

R.