hackrf support

[drtyhlpr]

hi, thanks for your great work! - I wanted to ask if you would like to have hackrf (or better osmosdr) support in your script(s). I created a small untested patch to support osmosdr usrc_src.py. I currently don't have an antenna with me but this should work. (so after testing I can create PR if you wish)

is there any reason I am currently not aware of why this should work with usrp only? - or better is half-duplex a problem at all?

[giech]

Thanks for your comment! I do not have access to a HackRF to test myself, but would like to integrate support that you have added. I suggest creating a separate file for the HackRF (like usrp_src.py), and patching decoder.py and usrp_nfc.py to support it.

One could also create a file like usrp_sink.py, but hardware emulation is not fast, so it is possibly not worth it.

If you create a PR request that you test, I would love to merge it.

[5ch4um1]

Hello. Just wanted to ask if anybody is still interested in this? Tried to make this work with gr-osmosdr and gnuradio 3.9 but i'm very new to all this and i think i have reached a point where i would really appreciate some help.

[FFY00]

Shouldn't this already work with the SoapySDR, SoapyUHD and SoapyHackRF?

[5ch4um1]

Shouldn't this already work with the SoapySDR, SoapyUHD and SoapyHackRF?

probably yes, and i think that's the point of the question, would be nice to be able to use another source and maybe gnuradio 3.9? And how about having all this as a flowgraph too, adding a sink here and there for better visualisation might be practical?

[FFY00]

SoapySDR already has integration with GNURadio, so AFAIK we should already be able to use GNURadio 3.9 as a source.

https://github.com/pothosware/SoapySDR/wiki#gnu-radio

[5ch4um1]

@FFY00 again, probably yes, what we are talking about is this: "...creating a separate file for the HackRF (like usrp_src.py), and patching decoder.py and usrp_nfc.py to support it." Unfortunately i would not consider my own skill level as sufficient to do this alone, but i think even with a small group of interested people it should be possible? So, do you own a hackrf and would you be interested in making this happen?

[FFY00]

Why would you need to add support for a new source if the hardware you want to use should already be supported in usrp_src.py via SoapySDR?

[5ch4um1]

should already be supported in usrp_src.py via SoapySDR?

It is not.

And sorry if i insist, but do you own a HackRF, have you tried this, are you willing to constructively contribute or will you just keep writing "this should already work" while in fact it does not? If it works on your box, then please tell us how.

I tried a few things and did some copy&paste and got it to a point where it seems to use the hackrf and seems to be processing samples, but now i'm a bit lost, i'd need some output on some places to check if what is being processed actually makes sense, and since i'm a total noob, i'd really appreciate some help. A question by the way, how should the output look when used with the example .wav recordings? I seem to get just a few good packets, the rest seems to be empty? Another thing i noticed is that the original uhd source seems to tune directly to the center frequency, but with the hackrf the dc spike removal doesn't seem to work (at least not on my box), so there might be some extra filtering needed? Oh, and the recordings look really impressive, i wonder how did @giech get a stronger signal from the tag than from the reader?!? I'd really love to see a video of this, looks like some components of the setup are moving during the recording? Or is the setup fixed and you change some settings? And i could keep on asking dumb questions for a few hours, so, really, please, if anybody is interested in this, let's talk! :)