I've not played with the ZMQ blocks, but a number of other drivers can
operate in network mode, eg. UHD, SoapySDR, and rtlsdr. Since the firehose
appears to use 2-bit samples I feel like you could fairly easily convert
that into something resembling rtl_tcp (
https://github.com/osmocom/rtl-sdr/blob/master/src/rtl_tcp.c#L95).

On Fri, Jul 12, 2024 at 3:55 PM Walter Szeliga <walter.szel...@gmail.com>
wrote:

> Hi all,
>     I have a GNSS Firehose (
> https://transitiva.com/product/gnss-firehose-receiver-tri-band-quad-constellation/)
> and have been trying to get it working, in a streaming capacity, with
> Gnuradio. The Firehose sends packets over ethernet using the experimental
> ethertype 0x88b5. I've tried a few things to get data from the Firehose
> into Gnuradio, some have worked, others have not. Things that work:
>
> * Use tcpdump and filter on 0x88b5 and save to a file. Open and repackage
> each packet in the pcap dump as interleaved bytes of I&Q and save to a
> file. Read into Gnuradio.
>
> * Write a custom program using libpcap to filter on 0x88b5 on a selected
> interface, repackage the packets and write directly to a file. Read into
> Gnuradio.
>
> * Write a custom program using libpcap to filter on 0x88b5 on a selected
> interface, repackage the packets and PUB them using ZMQ. SUB to this PUB
> using a simple Python script and dump the message contents to a file. Read
> into Gnuradio. Both tcp and ipc PUB/SUB work equally well.
>
> Some things that do not work:
>
> * SUB to the ZMQ PUB/SUB using the Gnuradio ZMQ SUB Source block.
>
> * Write a custom program using libpcap to filter on 0x88b5 on a selected
> interface, repackage the packets and send them using UDP.
>
> The UDP approach doesn't work because too many packets get dropped and I
> have been unable to set sysctl values appropriately (on an M1 Mac) to avoid
> dropping too many packets.
>
> I'm not sure why the ZMQ approach does not work with Gnuradio. I've tried
> many simple flowgraphs to convert from vector to stream, ibyte to complex,
> you name it, and then dumping the data back out to a file using a File Sink
> (just to use existing software to check for data sanity). Data gets into
> Gnuradio, but it clearly loses something because constellation diagrams of
> the output data become blobs centered on the origin rather than pairs of
> point clouds offset from the origin as one would expect from the BPSK
> nature of the GNSS signals captured by the Firehose.
>
> I've come to the realization that it's probably best to write some sort of
> driver to get data straight from the Firehose into Gnuradio, but I have no
> idea where to start with this. Any ideas about how to fix my ZMQ approach
> or start writing a custom driver would be appreciated. There's a lot in
> here, so let me know if you would like code or flowgraph examples.
>
> Cheers,
> Walter
>


-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Reply via email to