Type Conversion from dabmod to hackrf_transfer utility

[Peter Symonds]

Me and Rash have been trying to get the output of dabmod to the input of hackrf_transfer utility for transmission.

I have found a way of converting types using gnu radio but I'm wondering if there is an easier way of doing it?

I've attached the grc solution. mod.fifo is the input from dabmod and processed.fifo is the output to be transmitter via hackrf_transfer utility.

Pete

[Rashid Mustapha]

I have this HackRF on loan until the 6th of Jan, so I would like to evaluate the RF performance with the odr-mmbtools before then.

The first problem (as Peter has pointed out) is HackRF expects an unsigned 8-bit input, and not the (32-bit) complex float output 

format of odr-dabmod.

I'm trying to avoid using GNURadio (like the plague!) so I wonder if there a 'Swiss Army Knife' type format converter which could sit

in the pipeline?

Regards,

Rash.

--
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]

Peter,

I suppose i should just take the path of least resistance and build the GNURadio sink 

for HackRF - that will get me to where I can look at the signal on the spectrum analyser.

If it looks useable, then we could either do something with numpy, or maybe add support

in odr-dabmod...but I expect that will need a very compelling argument, with proof that

the 8-bit resolution provides acceptable performance.

Interestingly the ETSI standard specifies an 8-bit depth for each of the IQ samples, so it

should be useable.

R.

--

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.

<conversion.grc>

[Peter Symonds]

It is a long way round of doing it. It is easier using the osmocom sink if you are going to use gnu radio anyway.

It does prove that it needs samples sent to it in the 8 bit format.

Pete

[Matthias Brändli]

On 21. 12. 14 12:34, Rashid Mustapha wrote:
> The first problem (as Peter has pointed out) is HackRF expects an
> unsigned 8-bit input, and not the (32-bit) complex float output
> format of odr-dabmod.
>
> I'm trying to avoid using GNURadio (like the plague!) so I wonder if
> there a 'Swiss Army Knife' type format converter which could sit
> in the pipeline?

Maybe sox could do it in a pipeline between odr-dabmod and your hackrf
player.

mpb

[Rash]

Hmm...my previous message was a little bit ambiguous - HackRF expects 8-bits for I and 8-bits for Q, but it seems what I was getting at was understood anyway!

Sox eh? I'll take a look. I have used it for audio SRC before and I never thought about using it for anything else!

I'm going to go for getting it running with GNURadio first, and if it looks ok we will go from there!

Cheers,

R.

Sent from my iPad

[Rash]

Hmm...having looked, I think I will pass the sox avenue by.

GNURadio it is. For now at least!

:-)

On 21 Dec 2014, at 17:52, Matthias Brändli <matthias...@mpb.li> wrote:

[Matthias Brändli]

Yes it's probably easier to get it right with GNURadio. Also, you
probably have to normalise the samples, because the odr-dabmod output is
not between -1.0 and 1.0, but between around -35000.0 to 35000.0.

I tried to convert an IQ file using sox, but it seems to truncate the
sample values already at the input. Maybe there is a way. The command I
used is

sox -t raw -r 2048000 --volume .000028 -c 1 -b 32 -e floating-point
foo.iq -b 8 -e signed-integer -t raw -r 2048000 bar.iq

mpb

[Peter Symonds]

Might give sox a try tonight. It would save compiling GNU Radio.

Pete

[Rash]

A Corrigendum: 

Previously I mentioned what I thought the HackRF expected for tx.

HackRF expects two 8-bit signed integers for each sample (One for I and one for Q)

Merry Christmas! :-D

Best regards,

Rash.

Sent from my iPad

[Peter Symonds]

Would that mean -c 2 instead of -c 1 i.e. 2 channels. I did find that the s/n ratio wasn't very good looking at the output whilst using sox.

I will have a go at using -c 2 see if that does improve it.

Anyway I hope you all have a merry Christmas and a happy new year!

Pete

[Matthias Brändli]

On 25. 12. 14 01:41, Peter Symonds wrote:
> Would that mean -c 2 instead of -c 1 i.e. 2 channels. I did find that the s/n ratio wasn't very good looking at the output whilst using sox.

I wouldn't expect this to change anything, because it's equivalent to
consider the IQ data stream as a single stream of float numbers, or a
stream of pairs of float numbers (I and Q).

Did it print an error about the range of the values ? I have the
impression the range gets truncated at some point because of the error
sox WARN sox: `foo.iq' input clipped 1550455 samples. And the output
doesn't look so nice either.

mpb

[Matthias Brändli]

On 21. 12. 14 18:31, Peter Symonds wrote:
> It is a long way round of doing it. It is easier using the osmocom sink if you are going to use gnu radio anyway.
>
> It does prove that it needs samples sent to it in the 8 bit format.

I've added a format converter to ODR-DabMod's file output, that can
convert the complex floats to signed 8-bit integers. It applies a
normalisation factor of 128/50000 in order to use the full 8-bit range
[-127; 127], but you can tune this using the digital_gain. With this
reduced dynamic range you have to be more careful to avoid digital clipping.

I didn't try if this creates a valid signal because I'm in the train (as
if that was a valid excuse !), but the enclosed python script that does
the same conversion agrees with the implementation, which shows that I
agree with myself on how to do the conversion. I hope you will be able
to agree too :-)

An example is given in doc/example.ini, as usual on the "next" branch.

Cheers, and have a happy Christmas!
mpb

[Rash]

Ah, now you mention the digital gain in odr-dabmod I now remember that I have it set to 0.8 in odr-dabmod (for UHD driver reasons).

I can now confirm that 4096k does appear to be the sampling rate to use with HackRF - I don't think any more screenshots are needed as we could all see which direction it was going! :-) Now you've gone all 'Père Noël' on us, and brought us the gift of 'retro' 8-bit output, I am going to give it a go with hackrf_transfer.

Wishing you a pleasant journey!

Best wishes,

Rash.

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

> <check-s8.py>

[Peter Symonds]

Excellent! On both fronts. I'll give them a try after lunch today.

Pete

[Rash]

Hi Peter,

The python script proves the principle works. I've only checked it on the analyser, and it looks encouraging with 4096k sampling, but I need more dynamic range to see what is hidden under the proverbial carpet/noise floor. Next I will try to demodulate and check the BER.

There may be a problem building odr-dabmod from the 'next' branch if you are using the same compiler as me - Matthias is aware...

R.

On 26 Dec 2014, at 12:15, Peter Symonds <peteys...@gmail.com> wrote:

> Excellent! On both fronts. I'll give them a try after lunch today.
>
> Pete
>

[Peter Symonds]

I'm guessing you need to see the whole 100dB of the signal to check it against the critical masks.

Pete

[Rashid Mustapha]

Hi Peter,

No, not particularly, but the better it is to start with, the easier it is to clean up after the amplifier.

 

Close-in performance is the critical bit, as the mask filter is not magic (unfortunately) so the level

of the close-in unwanted (i.e - everything further out from 770 kHz from the centre is quite important,

and the closer it is, the more problematic it is as it is closer to the filter passband.

I can confirm that Matthias' python script does produce a valid signal with hackrf_transfer :-) AND

the BER is pretty good considering I haven't tweaked for best signal yet!

R.

On 26 December 2014 at 15:25, Peter Symonds <peteys...@gmail.com> wrote:

I'm guessing you need to see the whole 100dB of the signal to check it against the critical masks.

Pete