hackrf VS dumpvdl2

Another example: the HackRF SDR board was done in KiCAD

https://github.com/greatscottgadgets/hackrf

keep and eye out for this issue: https://github.com/greatscottgadgets/hackrf/issues/668

I have read about this issue on github (have been some reddit posts over the years as well), originally in #541 which has now culminated in an ongoing investigation #974.

HackRF would be my next choice... https://greatscottgadgets.com/hackrf/

However, unlike your sensitivity issues, i dont get any birdies. i have a TCXO though. (https://github.com/greatscottgadgets/hackrf/issues/216). it seems its related to clock drift calibration without one. However this is something most SDR's suffer from, as a cost saving measure. Most RTL_SDR's suffer from this as well ("rtl sdr blog v3" comes with a stable TCXO, resolving the issue.).

I assume this is the case since I found a GitHub issue talking about blown TX: https://github.com/greatscottgadgets/hackrf/issues/1051 And I followed the recommendation of using hackrf_transfer -c with both -a 0 and -a 1. With a separate RTL SDR tuned to the output frequency I can see a very low power CW signal with -a 0. With -a 1 there is no output. This seems to match the results in the issue.

If you're talking about building attachments to work with a phone, you're almost all the way there to a standalone device anyway. You might want to look into HackRF and pwnagotchi for inspiration.

If you get a HackRF there's a utility called hackrf_transfer which can record a block of spectrum and then play it back.

dumpVDL2