hackrf_transfer sample type for stdout

[Mas313]

What would you like to know?

Hi,
I want to pipe output of hackrf_transfer to dump1090 for decoding but over the web, people are referring that hackrf outputs signed 8 bit signed samples but dump1090 expects 8 bit unsigned values. same mentioned here (https://medium.com/@rxseger/flight-tracking-with-ads-b-using-dump1090-mutability-and-hackrf-one-on-os-x-3e2d5e192d6f)
However i see that hackrf buffer inside structure "hackrf_transfer" is already declared as "uint8_t* buffer;" in hackrf.h but in any case the samples passed are not decoded by dump1090. Can anyone guide me. Thanks

[martinling]

The information you're getting is correct: HackRF outputs signed 8-bit samples. So you will need to either convert the data, or modify dump1090 to accept signed 8-bit samples. As that article mentions, there's a fork of dump1090 with direct support for HackRF but it's not the latest version at this point.

[Mas313]

Thanks for the reply but it's buffer are already unsigned so how it could output signed samples.
uint8_t* buffer;" in hackrf.h

Thanks

[martinling]

The buffer field of the hackrf_transfer struct is generic: it contains whatever data is currently being transferred over USB. This is often sample data, but it can also include other things, like block headers in sweep mode.

It's common practice in C to use uint8_t as a type when handling bytes of unspecified binary data, since the language lacks any less specific type (except void, which is unsized).

It's up to the code reading the buffer to decide how to interpret the bytes. For instance, in an RX handler you could interpret the sample data by casting the buffer to an array of a type like:

struct sample {
    int8_t i;
    int8_t q;
};

[dmaltsiniotis]

For what it's worth, you could perform the conversion by piping the output to the Sound eXchange program to do the conversion on the fly. I've done with this hackrf_transfer, sox, and dump1090 in the past with success. This is the full command I use on macOS terminal to get dump1090 to read directly from hackrf_transfer:

hackrf_transfer -f 1090000000 -s 2000000 -p 0 -a 0 -l 32 -g 20 -r - 2> /dev/null | sox --rate 2000000 --channels 1 --type sb - --type ub - | ./dump1090 --interactive --aggressive --fix --net --ifile -

EDIT: Looking back on this, you may want of slightly offset the frequency to avoid the DC spike.

[Mas313]

Thanks for the useful suggestions. I did same but not receiving anything . I am doing this all on my raspberry pi and installed everything correctly. I have also tried with different Antennas but no luck . While my other pc with rtl sdr is receiving and decoding ADS-B data using dump1090. Any idea what could be wrong.

[mossmann]

What specifically did you try? Did you try offset tuning as @dmaltsiniotis suggested? Have you tried dumping the output to a file and looking at it with a tool such as inspectrum?