On 12/13/2017 03: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
You should be using the serial number of the hackrf instead.
Type
hackrf_info
and you should get a number like this for the Serial number:
000000000000000014d463fc2fb138e9
Then use
hackrf=2fb138e9
In case I counted incorrectly, it's the last 8 digits.
But your mileage may vary depending on the version of hackrf libraries,
firmware - and the version of gnuradio - or even possibly the version of
gr-osmosdr.
-- Cinaed
>
> 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
