Problem converting RTL 8 bit IQ samples to gnuradio native format

Hello, I’m using modes_rx in order to decode ADS-B messages.
Usually I use it with an RTL-based SDR simply as:

modes_rx -d

In this way it works perfectly.

However I need to record raw IQ samples using rtl_sdr and later
process them with modes_rx -F option (that reads data from file, in
the gnuradio format).

So I tried the following:

rtl_sdr -f 1090000000 -s 4000000 /tmp/modes.bin

And alter I converted modes.bin into modes.cfile using the following C
program:

int main(void) {
unsigned char in[2];
float out[2];

while(fread(in,1,2,stdin) == 2) {
    out[0] = in[0];
    out[1] = in[1];
    out[0] = (out[0] - 127)*(1.0/128);
    out[1] = (out[1] - 127)*(1.0/128);
    fwrite(out,sizeof(float),2,stdout);
}
return 0;

}

I’m using a little endian computer so in theory I’m converting the 8
bit I,Q samples into 4 byte floats I,Q samples in little endian
format, that should be the native format of Gnuradio from what I read
on the internet.

Unfortunately after this conversion modes_rx -F does not work as
expected, and instead outputs garbage.

I guess I’m doing something wrong in the recording or in the
conversion step, but I can’t find what the problem is. If you can
point me to the right direction I’ll appreciate your help.

Regards,
Salvatore


Salvatore ‘antirez’ Sanfilippo
open source developer - VMware
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
David Gelernter

I believe Salvatore’s message was hung up in the listserv as I’ve
answered him already on Github. :wink:

For posterity, modes_rx with the -F option is looking for the usual
Gnuradio complex sample format – 32-bit floating point I,Q,I,Q…

–n

On Wed, Dec 19, 2012 at 8:48 PM, Nick F. [email protected] wrote:

I believe Salvatore’s message was hung up in the listserv as I’ve answered
him already on Github. :wink:

For posterity, modes_rx with the -F option is looking for the usual Gnuradio
complex sample format – 32-bit floating point I,Q,I,Q…

Hello Nick,

actually I posted here because after your reply on Github I’m now sure
that the problemi is not about modes_rx -F, but the fact I do the
conversion in the wrong way or something like that, as I believe I’m
outputting 32 bit floating point I,Q,I,Q samples.
So the Github message was to check if the format was what I believed
it was (and it is).
This message was a request for help, to understand what I’m doing wrong.

The code I posted is a trivial transposition of the Gnuradio block I
see everywhere on the internet to convert from RTL raw IQ samples to
Gnuradio format, but maybe writing the C code I did some mistake.

Regards,
Salvatore

In this way it works perfectly.
program:
fwrite(out,sizeof(float),2,stdout);
expected, and instead outputs garbage.
open source developer - VMware
Discuss-gnuradio Info Page


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page


Salvatore ‘antirez’ Sanfilippo
open source developer - VMware
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
David Gelernter

On 12/19/2012 12:02 PM, Salvatore S. wrote:

conversion in the wrong way or something like that, as I believe I’m
outputting 32 bit floating point I,Q,I,Q samples.
So the Github message was to check if the format was what I believed
it was (and it is).
This message was a request for help, to understand what I’m doing wrong.

The code I posted is a trivial transposition of the Gnuradio block I
see everywhere on the internet to convert from RTL raw IQ samples to
Gnuradio format, but maybe writing the C code I did some mistake.
Sorry about that, I didn’t read closely enough.

Does rtl_sdr really output 4.0Msps? I thought it was confined to 2.8Msps
or 3.2Msps. If it’s operating at one or the other of those two native
sample rates, you will have to resample to 4Msps for use with modes_rx,
or modify modes_rx so it resamples when using the file sink, similar to
how it resamples for rtl_sdr sources now.

If this is a common use case it might be worthwhile to make modes_rx
automatically resample to an integer number of samples per symbol for
any file source sample rate, or to make the guts operate on a
non-integer-number of samples per symbol; the latter would be quite a
bit of work.

–n

On Wed, Dec 19, 2012 at 9:29 PM, Nick F. [email protected] wrote:

Does rtl_sdr really output 4.0Msps? I thought it was confined to 2.8Msps or
3.2Msps. If it’s operating at one or the other of those two native sample
rates, you will have to resample to 4Msps for use with modes_rx, or modify
modes_rx so it resamples when using the file sink, similar to how it
resamples for rtl_sdr sources now.

Thank you for your reply Nick, yes indeed I tried different sampling
options, my last try was:

rtl_sdr -f 1090000000 -s 3200000 -g 34 modes.bin

So I set the same gain and sampling rate modes_rx uses when capturing
directly from the device.
Still after the conversion the output of modes_rx -F filename.cfile is
a lot of random meaningless mode s messages.

Maybe there is some subtle error in my conversion code even if it’s so
simple that’s puzzling. I’ll try to write a few hand-written 8 bit IQ
samples and convert them just to see that the output is the expected
one.

The reason I’m doing this is because I want to be sure about the right
conversion from raw RTL output to cfile, as I plan to implement this
into the rtl_sdr utility itself, because many programes want cfiles as
input, so it is handy if rtl_sdr is able to output it directly.

Cheers,
Salvatore


Salvatore ‘antirez’ Sanfilippo
open source developer - VMware
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
David Gelernter

On Wed, Dec 19, 2012 at 11:55 PM, Marcus D. Leech [email protected]
wrote:

The RTL WILL NOT support sample rates reliably above 2.4Msps, regardless
of how well-appointed your CPU is. It drops them internally in
its pipeline. I would suggest using 2.4Msps, and up-sampling to 4Msps.

Thanks Marcus, I noticed this using rtl_test + a very fast computer:
still losing bytes above 2.4.

So should I assume that when modes_rx uses gets data directly from RTL
there is a software layer performing the up-sampling, and this is a
probable cause of my issues after the conversion?

Salvatore


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


Salvatore ‘antirez’ Sanfilippo
open source developer - VMware
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
David Gelernter

On 12/19/2012 05:35 PM, Salvatore S. wrote:

The reason I’m doing this is because I want to be sure about the right
http://invece.org

The RTL WILL NOT support sample rates reliably above 2.4Msps,
regardless of how well-appointed your CPU is. It drops them internally
in
its pipeline. I would suggest using 2.4Msps, and up-sampling to
4Msps.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On Thu, Dec 20, 2012 at 12:04 AM, Marcus D. Leech [email protected]
wrote:

Seems likely, perhaps Nick can confirm.

Re-reading Nick’s message I see it mentioned modes_rx already does
resampling at 4000000 msps, so this is probably the problem.

Thanks for the information,
Salvatore


Salvatore ‘antirez’ Sanfilippo
open source developer - VMware
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
David Gelernter

On 12/19/2012 05:59 PM, Salvatore S. wrote:

probable cause of my issues after the conversion?

Salvatore

Seems likely, perhaps Nick can confirm.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium