A GR block is not intended to be both a source and a sink, though you
could probably force something. Even if you could, gr-osmosdr sits
between GR and HackRF, and also separates source and sink.
You could rework the gr-osmosdr hackrf support to provide a hardware
manager below the source and sink that does TX/RX switching and presents
the attached source and sink as two different devices. Whenever samples
hit the sink, the switch would would enable TX, and then go back to RX
when samples stop. Shouldn't be too bad for a basic implementation where
timing isn't super critical (e.g., PTT radio).
Here's a related thread (maybe you're already on it?). I don't have any
experience with SoapySDR yet, but it looks like Josh and others have
thought about this.
https://github.com/mossmann/hackrf/issues/195
On 12/13/2017 06:11 PM, Gavin Jacobs wrote:
I have a HackRF One and I have been using the Osmocom Source/Sink blocks
to access it. In the Device arguments I put this:
hackrf=0
I have also used the Osmocom Source/Sink blocks with the Soapy/Hackrf
driver when I need to transmit and receive in the same flow graph. To
use the soapy driver, I use this for Device Arguments:
soapy=0,driver=hackrf
Both methods have pros & cons, but neither works well with the Hackrf.
It's like driving a square peg in a round hole. I would really like a
single block with an optional source port and an optional sink port,
plus some logic which controls the TX/RX switching via tags or messages.
I've written a dozen or so OOT modules, so I am reasonably confident
that I can code it. My question is this:
Is there any architectural constraint in gnuradio which would prevent a
source/sink combo block from working?
Thanks,
Jake
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
