hackrf mode - Githubissues

zoomequipd commented 7 years ago

I've had some consistent problems trying to get hackrf mode to work. FWIW, I also had this issue with the havoc firmware and went back to your firmware to troubleshoot

To replicate: 1) plug portapack into pc 2) from the menu on the portpack - enable hackrf mode 3) start gqrx 4) setup the IO Device as normal 5) click 'Start DSP' button 6) nothing seems to happen

I've flashed the latest firmware (manually compiled from git master branch) - the pc finds the hackrf fine, but I've never gotten GQRX to work with the device while in this mode.

$ hackrf_info
hackrf_info version: git-44333b7
libhackrf version: git-44333b7 (0.5)
Found HackRF
Index: 0
Serial number: 000000000000000----REDACTED----
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1 (API:1.02)
Part ID Number: 0xa000cb3c 0x004f4338

To troubleshoot, I removed the portpack and re-flashed the standard hackrf firmware on the device, plugged it in without the portpack connected and it worked fine.

jboone commented 6 years ago

@zoomequipd My apologies for totally missing your issue until now. Can you report on the state of the HackRF LEDs after you enable HackRF mode from the PortaPack main menu? Can I assume you're using a flavor of Linux? Can you say which version (repo commit hash or tagged release) of GQRX you're using? I am wondering if there's a HackRF API version mismatch, somehow. Do you see any USB-related erros in dmesg after entering HackRF mode?

fantuz commented 6 years ago

Hello @jboone I experiment the same behaviour described by @zoomequipd on portapack-havoc project and on portapack-hackrf.

Yes, all gr-osmo and gnuradio environment setup correctly, compiled. Ubuntu 16, environment didn't change.

I basically will use this procedure to go back to basic WORKING hackf (without recompiling/touchng GQRX, all git all up-to-date):

hackrf_spiflash -w /home/max/hackrf/firmware/build/hackrf_usb/hackrf_usb.bin
hackrf_cpldjtag -x /home/max/hackrf/firmware/cpld/sgpio_if/default.xsvf

So, I guess there must be something wrong in the converter xsvf/svf parts ! Might be a trace ?

To reproduce this "blackout" issue, put the portapack in hackrf-mode, and try to start GQRX, we get:

max@trinity:~/gqrx/build$ ./gqrx &
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.12git-295-ga0adcd33
built-in source types: file osmosdr fcd rtl rtl_tcp hackrf bladerf rfspace airspy 
Resampling audio 96000 -> 48000
BookmarksFile is /home/max/.config/gqrx/bookmarks.csv
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.12git-295-ga0adcd33
built-in source types: file osmosdr fcd rtl rtl_tcp hackrf bladerf rfspace airspy 
Using HackRF One with firmware 2017.02.1 
terminate called after throwing an instance of 'std::runtime_error'
  what():  hackrf_set_freq(1e+12) has failed (-1000) Pipe error

[1]+  Aborted                 (core dumped) ./src/gqrx

Will be necessary to edit the /home/max/.config/gqrx/default.conf and get rid of the [input] part just to have GQRX starting again (but this is not an issue). Obviously this editing of preference file will not make the acquisition work, will just let GQRX start clean before reproducing the error over and over again.

If the full reflash is done, no issues, no recompilng of GQRX or GR-OSMO whatsoever. Is not a gqrx issue anyway, as I am used to gnuradio and gqrx, I tend to keep all my environment fully working toward all the git dependencies and releases (I run Airspy, BladeRF and rtl at the same time, along with basic HackRF and now portapack).

Cheers and thanks Max / HB3YOE

fantuz commented 6 years ago

Just extra notes:

in GQRX the device is selectable, no evident signs of malfunction.
once DSP started, GQRX shows proper gain settings (not like if device busy, we won't get gain controls)
no alerts on the dmesg, no evident TX light on, no explicable fault.
CLK IN (3v3 10mhz) just as extra complexity, plugging it out doesn't change

max@trinity:~$ hackrf_debug --si5351c -n 0 -r [ 0] -> 0x01

That just shows my input is OK (otherwise 0x51 if no GPSDO or TCXO) 3v3 spot on, good square wave 10MHz from Leo Bodnar GPSDO at 24mA drive.

jboone commented 6 years ago

@fantuz In your error log, "1e+12" (1 terahertz) argument to hackrf_set_freq() is not a valid frequency for the HackRF. If you use the command-line hackrf_transfer to do some basic baseband recording, do you receive the same errors?

fantuz commented 6 years ago

yes @jboone I can confirm the error still happens on CLI

anyway the THz thing is more result of a crash, and as said if I edit the config, I can start DSP but no INPUT (even if gain controls and empty waterfall).

flashing all back to HACKRF-firmware works, so is definitely a portapack-issue...

thanks if you get the time to look at it.

73 Max

fantuz commented 6 years ago

max@trinity:~$ hackrf_transfer -r /tmp/12345 -f 147.325Mhz -a 1 -g 42 -l 32 -C 0                                                                                              
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_hw_sync_mode(0)
call hackrf_set_freq(147 Hz/0.000 MHz)
call hackrf_set_amp_enable(1)
Stop with Ctrl-C
 0.0 MiB / 1.000 sec =  0.0 MiB/second

Couldn't transfer any bytes for one second.

Exiting... hackrf_is_streaming() result: HACKRF_TRUE (1)
Total time: 1.00009 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit
max@trinity:~$

fantuz commented 6 years ago

Can confirm the same beahaviour after multiple flashes and rebuilds of gr-osmocom gnuradio gqrx and Co.

On Ubuntu 16 and yesterday tested on different setup, Ubuntu 17.10....

fantuz commented 6 years ago

Hello @jboone the guess about the error I posted (( "1e+12" (1 terahertz) )) Is not related to hackrf-mode not working, as this little message wa due to a gqrx bug, fixed.

otherwise, hackrf mode still not working for me ! owning the latest portapack....bought hackrf last year from greatscott.

i wonder why the stock CPLD file is compressed, in xsvf format within HACKRF project while yours and furrtek's firmware are not... may it help ? i tested with both portapack projects, no luck.

anyway, once more, tested even on another machine, I confirm the hackrf mode not working on my side (device present, transfer fail, gqrx works with stock FW).

is compression of CPLD to be taken in account ? why i experience random crashes ? i am ham-radio licensed and very carefyl on my circuits since ever, not an hardware issue as the unit works with GPSDO, gnuradio, gqrx and even qspectrumanalizer using the latest hacrkrf_sweep....

ciao, Max

jboone commented 6 years ago

Hi @fantuz:

The file is stored as XSVF in the firmware to save space, and require a lighter parser to perform the operations on the CPLD. The HackRF has only 1 Megabyte of SPI flash, so I try to preserve that resources as much as possible.

If you would, please put your PortaPack in HackRF mode. Then try these commands:

hackrf_info
hackrf_transfer -r /dev/null -s 10000000 -f 100000000

...and let me know what the output and results are. Thanks! We'll figure out what's going on.

fantuz commented 6 years ago

It works in HackRF mode only if I erase all portapack-related firmware. So, I will execute the suggested command and paste result, but the issue for me really is that I cannot use HackrRF in HackRF mode once the HAVOC has been flashed.

Even if device-wise, my hackrf is correctly enumerating. Will follow up soon

PS: the GPSDO is not always connected or in use, and that does not influence my experience.

fantuz commented 6 years ago

thanks for CPLD XSVF format info (i suspected the limit of resources was a concern)

jayPhantomic commented 6 years ago

I am having the same issue on standard portapack firmware as described by the above replication procedures.

I had a couple of questions. Fantuz, were you only able to return the HackRF to standard operating mode, i.e. HackRF mode, after removing the portapack pcb? Because I flashed the latest HackRF official firmware, and it indicated a successful flash.

However, I still got the same response from GQRX on kali-rolling, and SDRSharp on win10. Device was initializing, gain controls seemed operative, but no output.

Also, I have been using the release binaries for the HackRF official firmware, is there any possible benefit a source build could offer?

Thanks in advance.

jboone commented 5 years ago

@zoomequipd, @fantuz, @jayPhantomic I have some firmware that might address your issue. I did some work on restoring the hardware state to that expected by the HackRF firmware. Here is some test firmware which might address your issue: https://portapack-h1-builds.s3.amazonaws.com/sharebrained/portapack-hackrf/176/176.1/build/firmware/portapack-h1-firmware-90f64a6.tar.bz2

jboone commented 5 years ago

A lot of work was done on or related to HackRF mode, and I believe the issues are resolved. Closing...

sharebrained / portapack-hackrf

hackrf mode #115