Issues with udp streaming data to gr_satellite

Not sure where this really belongs but figured I would ask it here. I have been having consistent issues trying to interface different applications over udp. Sometimes packets will go through and other times nothing. And sometimes certain applications will be able to see the packets and other times not.

For example, I have been trying this combination just for test purposes:

Sdrpp → udp dump 7355 at 48khz at 127.0.0.1 → gr_satellites and I don’t see any packets come through.

Sdrpp → udp dump 7355 at 48khz at 127.0.0.1 → nc -l -u 127.0.0.1 7355 and I don’t see any packets come through.

Sdrpp → udp dump 7355 at 48khz at 127.0.0.1 → generic python socket application. I see packets come through.

Not sure what is the problem and I have tried other applications such as sdrangel and encounter similar issues.

What SDR++ sink are you using and what is the final goal?

Jan PE0SAT

So the whole goal is to be able to stream the udp sink of a sdr software to gr_satellites so that I can decode packets when doing manual tests. Eventually I would also like to do this same process with SDRangel since with this ground station I am trying transmit to digipeater and need the transmit functionality of SDRangel and would be nice to have proper receive decoding at the same time.

Right now I am trying to utilize the radio sink in sdrpp and as mentioned before and I can only see the udp packets come through with python sockets.

I also tried doing something as simple as GNUradio UDP source and plot to a qt frequency and I still don’t see any packets. So it seems like something is fundamentally not working with the GNUradio UDP source given both the gr_satellites and plain gnuradio don’t see any udp packets. I tried two different computers and both show the same problem (minus the previously mentioned ncat issue - that seems to be isolated to some bad install of ncat).

Thanks for the reply, so you want to use the demodulated audio as input for gr_satellites.

Using the following command nc -l -u -p 7355 127.0.0.1 I do see packets being received after clicking start in sdr++

A remark, this will not work when you replay an recorded IQ file because sdr++ isn’t adding a throttle block when replaying and using the Radio network sink.

Maybe consider audio routing towards gr_satellites or use an IQ file as input.

The sdr++ IQ export module is also an option.

Replaying a GRIFEX IQ recording and using the following gr_satellites cli command.

gr_satellites GRIFEX --samp_rate 48000 --udp --udp_raw --udp_port 7355 --udp_ipv4_only --iq

-> Packet from 9k6 FSK downlink
Container: 
    header = Container: 
        addresses = ListContainer: 
            Container: 
                callsign = u'KD8SPS' (total 6)
                ssid = Container: 
                    ch = False
                    ssid = 0
                    extension = False
            Container: 
                callsign = u'CQ' (total 2)
                ssid = Container: 
                    ch = True
                    ssid = 0
                    extension = True
        control = 0x03
        pid = 0xF0
    info = b'\xab\xcd\x00\x00\x00B\x01\xed\x00\xaa_\x00\xdc\x00\x11kN\x16*\x1e\xe5\xa0r|\x95~\x12\xbb\xc5\\\xf5f\xd3I*Kw\xa8\x1c\x0f\xf0\n\xec\x96>\x9b\x8f\xe5Y\xfc\x12\xaf\xad\xa7z\xa3\xa8\x94s\x1e\xa0\xad\xbb\xee\x88\xcev\xda\xa3d,\x1df\xdco\xe9\xea\x94a\x06c\xb6C\x8e\x9aK\x8eRW\xaf\xd8r<f2\xdeB\\H\xf6\xd7\xa7\x98P\x01\xe8\x82d,E5C:r\xd4\x1b\xda\x1c\xd6\x01\x8c;\xf1\xbb/\x9ar\x94\x8cOB;\xff\x12\xaf\xd3"0.\xc4\xb7\x85\xe0o\xe4~\x80\x1b,\x995a\xb1L\xfa\xd4\xe8\xe0m\xfe\xa9\x1e\x85<\xa9\x86S\x8e\xad\xdd\x8c\x05\xb2\x9d\xb1#\x82Q\xfa\x9c\x03\x96\xaeN\x1f.\xe7s\x92\xcc\x1c ;x\x14\x8c\x9b\x94\xae\x1e\x88`\x94\xf39\x97\xc1\xf8%\xdd\x0fn\xc2wI{\x0c(9n\xf0\x16Pw\xaf\xa4\x1cS\xf5\xffR\x8d\xb8\x00\x00\x00\x00' (total 237)

Tagging @DL4PD

Jan | PE0SAT

1 Like

Okay I think it must have been a udp packet format issue (wasn’t using the float32 export with the iq export from sdrpp). Ultimately, I ended up using an internal audio loopback as that proved to be more reliable. Thanks for the help.

1 Like