search

sharebrained / portapack-hackrf

Portability Add-On for the HackRF Software-Defined Radio.
GNU General Public License v2.0
996 stars 408 forks source link

External clock #136

Closed cosmo6110 closed 5 years ago

cosmo6110 commented 5 years ago

Portapac H1 batch 20181029. The firmware is not detecting the 2.5ppm TCXO clock I have compiled from difference source "jboone(Furrtek), Furrtek and sharebrained same problem. With this patch the hackerf mode detect the clock https://github.com/sharebrained/portapack-hackrf/commit/01bad2805c633b4d53f59a28ec99f3f16e61c41d but have other issues. My system is 4.18.0-kali2-amd64, compiler gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907.

Is it anything i can try to get the software to detect the hardware clock? br tommy

jboone commented 5 years ago

@cosmo6110 Sorry for the delay. There were still a couple of bugs around the TCXO feature. I believe I have them addressed now. Please try this latest build of PortaPack:

https://portapack-h1-builds.s3.amazonaws.com/sharebrained/portapack-hackrf/202/202.1/build/firmware/portapack-h1-firmware-3b6fce7.tar.bz2

...or change ".bz2" to ".zip" if you prefer a zip file.

You should see the selected clock source in the PortaPack Setup -> Frequency Correction "Reference Source".

cosmo6110 commented 5 years ago

Hi! I tried your latest build and i got the TCXO to show up in the Frequency Correction. So far so good. In the hackrf mode, is not working. hackrf_debug --si5351c -n 0 -r [ 0] -> 0x51

In the latest build my serial number says: Serial number: RunningFromRAM.

hackrf_info version: git-eae870d libhackrf version: git-eae870d (0.5) Found HackRF Index: 0 Serial number: RunningFromRAM Board ID Number: 2 (HackRF One) Firmware Version: git-6e5b31d (API:1.03) Part ID Number: 0xa000cb3c 0x00754f5a CPLD checksum: 0x8b150ff6

Old version hackrf_info version: git-eae870d libhackrf version: git-eae870d (0.5) Found HackRF Index: 0 Serial number: 000000000000000087c867dc2a22575f Board ID Number: 2 (HackRF One) Firmware Version: 2017.02.1 (API:1.02) Part ID Number: 0xa000cb3c 0x00754f5a

br Tommy

jboone commented 5 years ago

@cosmo6110 Try transmitting or receiving with hackrf_transfer first. Then check with hackrf_debug. The "activate_best_clock_source" function is only called when entering transmit or receive mode. So until you receive or transmit, no external clock detection occurs.

You may also want to try my build of firmware from yesterday, as I added an icon on to the PortaPack while in HackRF mode that indicates the clock source:

https://portapack-h1-builds.s3.amazonaws.com/sharebrained/portapack-hackrf/204/204.1/build/firmware/portapack-h1-firmware-3b6fce7.tar.bz2

If hackrf_info reports "RunningFromRAM", that's because you a running firmware in RAM using dfu-util. Program the .bin file using hackrf_spiflash if you want to upgrade the flash to the new firmware.

cosmo6110 commented 5 years ago

@jboone Yes, tried your new firmware, it's working nice.I can see the new icon in the right corner PPK. hackrf_debug --si5351c -n 0 -r [ 0] -> 0x01

I got a weird error, when i run hackrf_spiflash -w portapack-h1-firmware.bin it running the firmware in RAM.

cosmo6110 commented 5 years ago

I compile latest mossmann/hackrf. Kali 4.19.0-kali3-amd64 and programmed it to the flash memory. Maybe it doesn't matter? The fork (hackrf) says it running from ram? hackrf_info version: git-eae870d libhackrf version: git-eae870d (0.5) Found HackRF Index: 0 Serial number: 000000000000000087c867dc2a22575f Board ID Number: 2 (HackRF One) Firmware Version: git-509c8f4 (API:1.03) Part ID Number: 0xa000cb3c 0x00754f5a CPLD checksum: 0x05829db7

https://github.com/jboone/hackrf

hackrf_info version: git-eae870d libhackrf version: git-eae870d (0.5) Found HackRF Index: 0 Serial number: RunningFromRAM Board ID Number: 2 (HackRF One) Firmware Version: git-1b7ef42 (API:1.03) Part ID Number: 0xa000cb3c 0x00754f5a CPLD checksum: 0x05829db7

jboone commented 5 years ago

@cosmo6110 I've identified the issue. It's a bug and a regression. The short story: PortaPack firmware uses a DFU version of the HackRF firmware for "HackRF Mode". This version of the HackRF firmware reports "RunningFromRAM" for a serial number, I guess as a way to tell you're in DFU mode, not running from flash. Everything else is correct, it's just that when PortaPack runs that DFU code, the serial number should be reported, not "RunningFromRAM". It was fixed back when the PortaPack code in HackRF was optional. It's since become baked-in, and that's where the regression happened. I'm identifying a way to fix this (again), and avoid it happening again -- please see new issue #137.

Thanks for the report! I'm closing this issue, as I believe the original issue is resolved.