I broke my HackRF

[LegsAJimbo]

Have you read the HackRF documentation?

yes

What outcome were you hoping for?

The device to function

What outcome actually happened?

Hi All,

A while back I replaced the MGA-81563-TR1G and updated the firmware on my HackRF One portapack. Lesson learned, I should only make one change at a time :/

I am confident I did a good job replacing the amp, I am fairly experienced in micro soldering a decent microscope was used, no pads were pulled, alignment is perfect and you would have no idea any work was done by looking.

Since then the HackRF has stopped functioning, it can be identified, but I was unable to get any kind of waterfall display in either gqrx or the Portapack OS (Mayhem).

Going back to basics, I have separated the HackRF from the portapack and flashed the stock HackRF firmware. I reflashed both the dfu file (using dfu-util) and then the bin file (using hackrf_spi).

However it still has an issue. Running harckrf_sweep give the following output.

Any help or pointers with getting this back up and running would be very much appreciated!

❯ hackrf_sweep
call hackrf_sample_rate_set(20.000 MHz)
call hackrf_baseband_filter_bandwidth_set(15.000 MHz)
Sweeping from 0 MHz to 6000 MHz
Stop with Ctrl-C
0 total sweeps completed, 0.00 sweeps/second

Couldn't transfer any data for one second.

Exiting... hackrf_is_streaming() result: HACKRF_TRUE (1)
Total sweeps: 0 in 1.00119 seconds (0.00 sweeps/second)
hackrf_close() done
hackrf_exit() done
exit

What operating systems are you seeing the problem on?

HackRF Mayhem and EndeavourOS 2024.04.20 (Kernel 6.6.40-2-lts)

What is the output of hackrf_info?

❯ hackrf_info
hackrf_info version: 2024.02.1
libhackrf version: 2024.02.1 (0.9)
Found HackRF
Index: 0
Serial number: 0000000000000000629461dc237d2153
Board ID Number: 2 (HackRF One)
Firmware Version: 2024.02.1 (API:1.08)
Part ID Number: 0xa000cb3c 0x00614756
Hardware Revision: older than r6
Hardware supported by installed firmware:
    HackRF One

Are you using any third-party software?

I have gone back to basics and now simply using hackrf_sweep to test.

Are you using any third-party hardware?

I was using the PortPack H2+, but have now gone back to basics using only the HackRF One on it's own.

[straithe]

Can you please add a picture of your HackRF board to this issue?

[LegsAJimbo]

Certainly!

One admission of guilt I meant to put in the original post, I didn't exactly exercise ESD precautions, so that could be a factor too...

[mossmann]

Can you please try: hackrf_transfer -r /dev/null

[LegsAJimbo]

Sure!

❯ hackrf_transfer -r /dev/null
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_hw_sync_mode(0)
call hackrf_set_freq(900000000 Hz/900.000 MHz)
Stop with Ctrl-C
 0.0 MiB / 1.000 sec =  0.0 MiB/second, average power -nan dBfs

Couldn't transfer any bytes for one second.

Exiting... hackrf_is_streaming() result: HACKRF_TRUE (1)
Total time: 1.00005 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose() done
exit

Thanks Again!

[mossmann]

The microcontroller appears to be working correctly, but it is not receiving samples from the ADC/CPLD. It looks like a hardware fault. I suggest checking the 1V8 power rail with a voltmeter and clock signals GCK1, GCK2, and SGPIO_CLK with an oscilloscope.

[LegsAJimbo]

Thanks. 1V8 looks good, I am reading 1.83V.

Regarding the oscilloscope side of things, this is something I have no experience with. I do have a DSO138 (https://jyetech.com/dso-138-oscilloscope-diy-kit/), I currently have no clue how to use it, but keen to learn.

I shall see what YouTube can teach me this evening :D

[LegsAJimbo]

SUCCESS!

I had a probe around with the DSO138, but couldn't get anything meaningful from pins 13 and 14 on P28.

Then I figured I would just start attacking the larger chips with flux and solder, because that's something I can do :D

The 6th and last of the larger chips I attacked to was the Si5251 and BINGO! hackrf_sweep is now working! I still need to properly reassemble and test, but having sweep working has given me a lot of confidence!

I guess pulling and pushing the headers around during reassembly puts a fair amount of pressure on the PCB and broke a joint. Thinking about it logically, I see the Si5251 is a clock generator, so you were on the right track!

Thanks a lot for your help on this!

[straithe]

We're glad that worked for you!