Re: [Discuss-gnuradio] Hackrf Source/Sink Combo

[Jeff Long]

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio