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

Which HackRF Firmware? #2

Open
robotastic opened this issue Sep 23, 2014 · 3 comments
Open

Which HackRF Firmware? #2

robotastic opened this issue Sep 23, 2014 · 3 comments
Labels

Comments

@robotastic
Copy link

Which version of the HackRF firmware does this support? The original version for the jawbreaker had unsigned output and the newer version that supports the HackRF One has signed output.

I have the Jawbreaker and haven't upgraded yet. I can't seem to get Kalibrate to work, so I am wondering if it is an issue with my firmware version.

@ckuethe
Copy link
Contributor

ckuethe commented Sep 26, 2014

I haven't made any changes to support recent HackRF firmware, so it probably assumes old format data. Thanks for pointing this out; I'll have a look.

@rxseger
Copy link
Collaborator

rxseger commented Jun 7, 2016

This may be the same problem encountered when porting dump1090 from rtlsdr to hackrf (in what is now dump1090_sdrplus):

http://hackrf-dev.greatscottgadgets.narkive.com/4mLdz4BJ/adding-hackrf-support-to-dump1090

Donald Pupecki 12 months ago
I don't believe hackrf_transfer and rtl_sdr output in the same format. They
are both 8 bit but the hackrf output is signed whereas the rtl output is
unsigned.

If you get this working a hackrf please post the port on github or
somewhere as that would be sweet.

Ilker Temir 12 months ago
Thanks! signed to unsigned conversion was the culprit. I first tested it
with cox by converting the file and then tweaked my code to do that
within the receive path.

itemir/dump1090_sdrplus@f02a8cf#diff-4844415e789781b82d79d4819e97d461R478

@rxseger
Copy link
Collaborator

rxseger commented Jun 8, 2016

A stab in the dark, but if I make this change:

diff --git a/src/usrp_source.cc b/src/usrp_source.cc
index 4a80657..75965a3 100644
--- a/src/usrp_source.cc
+++ b/src/usrp_source.cc
@@ -295,6 +295,11 @@ hackrf_rx_callback (hackrf_transfer * transfer)
   //  cout << transfer->valid_length  << " " << hackrf_rx_count << " " << bytes_to_write << "\n";
   if (bytes_to_write != 0)
     {
+      /* HackRF One returns signed IQ values, convert them to unsigned */
+      for (uint32_t i = 0; i < bytes_to_write;  i++) {
+        transfer->buffer[i] ^= (uint8_t)0x80;
+      }
+
       memcpy (u->ubuf + u->hackrf_rx_count, transfer->buffer, bytes_to_write);
       //    for (size_t i=0; i<bytes_to_write; i++) {
       //      hackrf_rx_buf[hackrf_rx_count+i] = transfer->buffer[i];

it has no discernible effect (still get about +19 ppm with channel 995, -35 ppm with 993). Same results with 2014.08.1 and 2015.07.2 firmware.

@robotastic Could you elaborate (sorry its been a while, if you remember), how did kalibrate-hackrf not work for you? Were you seeing inconsistent offsets on different channels as I am, or was it something else?

rxseger pushed a commit to rxseger/kalibrate-hackrf that referenced this issue Jun 29, 2016
Switch bladeRF sample format to SC16 Q11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants