1

To be honest I am a bit confused and I guess the error is quite obvious. Anyway.

So, on one side I have a UDP sink from GNU Radio sending data to a Python client.

The problem is the data I am receiving does not make much sense (I am able to properly read the data if, instead I read it from a file sink, so it has to do with the way I am doing the network part).

I tried already as little endian and also big endian, just in case, I still get rubbish.

So, on the sink side (the server side) the block config is:

self.blocks_udp_sink_0 = blocks.udp_sink(gr.sizeof_gr_complex*1, "the_ip",8080,1472,True)

So, on the other side I will get 1500 bytes, no? 1472 of payload +28 of the UDP header.

What I did, and based on this[1] example seems ok, is reading 1500 bytes in the client side and assume the header is taken out by recvfrom method:

data_tmp, addr = sock.recvfrom(1500)

I assume data_tmp shall be the 1472 bytes of data, at least the length matches).

As I am sending gr_complex I read 8 bytes (two floats little endian, one for I and one for Q components).

So, what am I missing?

Thanks!!

[1] There are many other like this one, the point is I assume the method splits the header from the payload. https://www.binarytides.com/programming-udp-sockets-in-python/

f.gallardo
  • 41
  • 5

1 Answers1

2

when you read from a socket, the UDP header is already removed, so you shouldn't try to read 1500 bytes but 1472.

Other than that, this looks fine.

I'd generally recommend not using UDP (you'll have to deal with packet loss, potentially even L2 fragmentation etc yourself), but one of the ZeroMQ sinks (PUSH Socket would be a good idea here) and your favourite Python ZeroMQ library (pyzmq) as other end (PULL socket); you get low-overhead data passing interface over TCP (if you need to go over network), IPC (if your GNU Radio flow graph and the receiving program can use Unix inter-process communication) or a couple "specialist" transports.

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
  • You were absolutely right, the bug was in another part of the code. Now it works. I will look into the other points for improvement, as I thought that basing on TCP a communication that requires this level of real time "speed" was bad practice, but I will look into the ZeroMQ point, thanks! – f.gallardo Apr 25 '21 at 06:54
  • it does come with a penalty, indeed, but then again, you might not actually be willing to accept unnoticed packet loss. – Marcus Müller Apr 25 '21 at 10:10