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?