ODR-DabMod File Output - a thing to keep in mind

[Matthias Brändli]

Hi all,

I just did a small discovery, that is relevant if and only if

- you are using the file output to /dev/stdout
-and-
- your ODR-DabMod has been compiled *with* UHD support

On each startup, UHD prints its status line to standard output, which
will end up in the same place as the I/Q samples !

There are two solutions right now:

- Recompile UHD with a modified the host/lib/version.cpp

- Don't compile ODR-DabMod with UHD if you want to use standard output

I've notified the UHD developers to ask if we can change this upstream.
In the meantime, we have to go around the problem ourself.

Cheers,
mpb

[Rashid Mustapha]

Hi Matthias,

 

What are the ramifications of that status line being printed to stdout? Will it just

overwrite some samples for a bit, or could it cause a continuous problem?

 

If so, what might that be?

 

I'm guessing it depends on what the data formatter in each particular radio device does?

 

I doubt it is related to my ARM stuff not working with HackRF or the basic tx, but at this

point in time I maintaining a very open mind (and with compile with UHD) anyway.

 

Best wishes!

 

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.

[Matthias Brändli]

The message text will be treated as valid data that starts before the
real data stream.

If you're using signed 8-bit IQ, it might break the alignment of the I
and Q channels. Like so:

ODR-DabMod outputs the byte sequence 1, which is interpreted as shown in 2:

1) startup messageIQIQIQIQ
2) IQIQIQIQIQIQIQIQIQIQIQI

You see that there is a I and Q mismatch, and if you look at the IQ
pairs, you will see it mixes up the indices too. If the startup message
has an even length, it'll be fine, but if it prints an odd number of
bytes, your data is messed up.

If you're using float IQ, each complex float sample is 8 bytes long. In
6 out of 8 possibilities, this will totally break the interpretation of
the float values, in 1 out of 8 I and Q will be wrong as for the signed
8-bit case, and in 1 out of 8 you will "only" notice some garbage values
as prefix.

What I observed in the float case where I gave the data to GNURadio is
that it gets stuck in a strange state because it interpreted some values
as NaNs or infinities. Your issue with hackrf_transfer could very well
be related to this problem, so make sure you compile ODR-DabMod without
--enable-output-uhd

If that is not practical, you could avoid stdout and use a named pipe:

mkfifo myamazingfifo
odr-dabmod configfile_that_writes_IQ_to_the_fifo.ini
hackrf_transfer -t myamazingfifo

Writing the configuration file is left as an exercise for the reader :-)

mpb

On 09. 01. 15 16:02, Rashid Mustapha wrote:
> Hi Matthias,
>
> What are the ramifications of that status line being printed to stdout?
> Will it just
> overwrite some samples for a bit, or could it cause a continuous problem?
>
> If so, what might that be?
>
> I'm guessing it depends on what the data formatter in each particular
> radio device does?
>
> I doubt it is related to my ARM stuff not working with HackRF or the
> basic tx, but at this
> point in time I maintaining a very open mind (and with compile with UHD)
> anyway.
>
> Best wishes!
>
> Rash.
>
> On 9 January 2015 at 14:01, Matthias Brändli <matthias...@mpb.li

> <mailto:matthias...@mpb.li>> wrote:
>
> Hi all,
>
> I just did a small discovery, that is relevant if and only if
>
> - you are using the file output to /dev/stdout
> -and-
> - your ODR-DabMod has been compiled *with* UHD support
>
> On each startup, UHD prints its status line to standard output, which
> will end up in the same place as the I/Q samples !
>
> There are two solutions right now:
>
> - Recompile UHD with a modified the host/lib/version.cpp
>
> - Don't compile ODR-DabMod with UHD if you want to use standard output
>
> I've notified the UHD developers to ask if we can change this upstream.
> In the meantime, we have to go around the problem ourself.
>
> Cheers,
> mpb
>
> --
> 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

> <mailto:crc-mmbtools%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>

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

> <mailto:crc-mmbtools...@googlegroups.com>.

[Rashid Mustapha]

Hi Matthias,

 

Thank you for that. It is the best thing I have to go on right now so I will give it a try!

 

Best regards,

Rash. 

 

PS: I am all booked-in for RadioHack, so if I don't make it to FOSDEM I will see you next month anyway.

To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.

[Rash]

Hello,

Just a quick update to say that it didn't solve the HackRF on ARM puzzle.
I'm in the process of selecting some RF layer measurement equipment that
should hopefully provide some clues, but I doubt I will see it for a couple of
months at best. :-/

Maybe I should see if I can get SDR-J working on Linux, as at least that has
a constellation display...although I doubt that will tell us much.

It must be something fundamental if it looks so clean on the analyser, surely?

(And I'm not talking about the plot I managed to post upside-down! :-D)

Regards,

Rash.

> To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.