Support for hackrf

[pinkavaj]

It looks like hackrf support is not implemented.

• There is a hackrf@.service
• There is relevant line in Makefile.linux

but it looks like hackrf.c does not exists. The implementation is missign right?

Btw would make more sense to implement it specifically for HackRF or just use somethink like soapysdr?

[ka9q]

I have a HackRF, and I used to support it. But I haven't used it in a while, and I haven't kept the front end module up to date. If you'd like to reimplement it using soapySDR, that would be wonderful -- I could use it as a template for other front ends.

[ncorgan]

https://github.com/ncorgan/ka9q-radio/tree/soapy-support

I started a general SoapySDR branch a while back, but I haven't touched it in a while because of life stuff. If there's interest in it, I can get back on it. I don't have a HackRF myself, but I have an RTL-SDR, a USRP, and a few Lime devices, so I can test a few frontends.

Phil, it sounds like you're looking for hardware-specific support through SoapySDR rather than general support?

[ka9q]

Yes, if you can provide SoapySDR support I would love to integrate it. It probably doesn't provide all the features I want (like exact tuner frequency readback) but it would be very handy in supporting hardware I don't already support natively.

[tavi343]

I would like to use RX888-MK2 with soapy_power to get a wide band spectrograph for solar radio bursts recording. It is cheaper than USRP or Lime SDRs. I would replace the analog TV tuner CALLISTO instrument (see e-callisto.org). The most interesting band is between 20-80MHz on HF but a wider band with fast scan is better. No need to decode anything, just record the power vs frequency. I've try with Airspy R2 and bladeRF X40+XB200 and these are too low speed. We need more than 10 full spectrum/second.

[ka9q]

ka9q-radio performs large FFTs on its A/D input stream as part of a filter bank technique called _fast _correlation__. The magic is all in MIT's Fastest Fourier Transform in the West package. I'm routinely handling A/D rates of 20 Ms/s on a Raspberry Pi 4 and up to 130 Ms/s on a mid-range Intel i5 with 30-50% of CPU real time left over.

I'm already adding spectral analysis to drive waterfall displays and to enable search-and-decode applications. So the underlying code you probably need is already there. I'm working on the command-line programs to extract it.

The RX-888 MkII is a wideband SDR front end that works in two modes: direct sampling at up to 130 Ms/s (real), and a downconversion mode that works up to the middle of L-band (1-2 GHz). The downconverter uses the very common R820/828 digital TV tuner so it's limited to about 8 MHz at a time. So far I've only implemented the direct sampling mode since it's easily the most cost-effective device we've found so far for capturing the entire HF spectrum at once.

The Airspy R2 is another good SDR front end that also uses the R820/828 digital TV tuner. It samples at 20 Ms/s (real) as it is also limited by the tuner bandwidth. It operates only in the downconversion mode, so it covers ~25 MHz up to L-band, about 8-9 MHz at a time.

The RX-888 MkII can actually go up as far as the 6 meter amateur band (50-54 MHz), so it'll cover part but not all of the 20-80 MHz range you're interested in. But the stock unit has thermal problems so most of us are running it at half rate (~65 MHz), especially since we're mainly interested in HF. This requires an external 30 MHz low pass filter to suppress aliasing.

[ka9q]

Check out G0ORX's web-based spectral display for ka9q-radio: https://github.com/fventuri/ka9q-web It's still pretty rough but it does use my "spectrum" pseudo-demodulator to drive the spectrum analyzer and waterfall.