Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hackrf_transfer sample type for stdout #1524

Open
Mas313 opened this issue Jan 9, 2025 · 5 comments
Open

hackrf_transfer sample type for stdout #1524

Mas313 opened this issue Jan 9, 2025 · 5 comments
Labels
question question from the community that is not technical support

Comments

@Mas313
Copy link

Mas313 commented Jan 9, 2025

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

@Mas313 Mas313 added the question question from the community that is not technical support label Jan 9, 2025
@martinling
Copy link
Member

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
Copy link
Author

Mas313 commented Jan 9, 2025

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
Copy link
Member

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
Copy link
Contributor

dmaltsiniotis commented Jan 9, 2025

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
Copy link
Author

Mas313 commented Jan 13, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question question from the community that is not technical support
Projects
None yet
Development

No branches or pull requests

3 participants