CODEWITHSUNDEEP
tcpgnuradiognuradio-companion
MidnightJava
MidnightJava

Reputation: 1997

GnuRadio tcp_sink data values are garbled

I'm developing a web front end for a GNU Radio application developed by a colleague.

I have a TCP client connecting to the output of two TCP Sink blocks, and the data encoding is not as I expect it to be.

One TCP Sink is sending complex data and the other is sending float data.

I'm decoding the data at the client by reading each 4-byte chunk as a float32 value. The server and the client are both little-endian systems, but I also tried byte swapping (with the GNU Radio Endian Swap block and also manually at the client), and the data is still not right. Actually it's much worse then, confirming there is no byte order mismatch.

When I execute the flow graph in GNU Radio Companion with appropriate GUI elements, the plots look correct. The data values are shown as expected to between 0 and 10.

However the values decoded at the client are generally around 0.00xxxxx, and the plot looks like noise rather than showing a simple tone as is seen in GNU Radio. If I manually scale the data by multiplying by 1000 it still looks like noise.

I'll describe the pre-D path in GNU Radio since it's shorter, but I see the same problem on the post-D path, where a WBFM Receive and a Rational Resampler are added, followed by a Throttle block and then a TCP Sink block sending float data.

File Source (Output Type: complex, vector length: 1) =>
Throttle (vector length: 1) =>
Low Pass Filter (FIR Type: Complex->Complex (Decimating)) =>
Throttle (vector length: 1) =>
TCP Sink (input type: complex, vector length: 1).

This seems to be the correct way to specify the stream parameters (and indeed Companion shows errors if I make changes which mismatch the stream items), but I can find no way to decode the data correctly on the other end of the stream.

Upvotes: 2

Views: 1463

Answers (2)

CSylvain
CSylvain

Reputation: 11

"the historic RFC 1700 (also known as Internet standard STD 2) has defined the network order for protocols in the Internet protocol suite to be big-endian , hence the use of the term 'network byte order' for big-endian byte order."

see https://en.wikipedia.org/wiki/Endianness

having mentioned the network order for protocols being big-endian, this actually says nothing about the byte order of network payload itself.

also note: Sun Microsystems made big-endian native byte order computers (upon which much Internet protocol development was done).

i am surprised the previous answer has gone this long without a lesson on network byte order versus native byte order.

GNURadio appears to assume native byte order from a UDP Source block.

Examining the datatype color codes in Help->Types of GNURadio Companion, the orange colored 'float' connections are float32.

To verify a computer's native byte order, in Python, do:

from sys import byteorder
byteorder

the result will be 'little' or 'big'

Upvotes: 1

charlieamer
charlieamer

Reputation: 91

It might be possible that no matter what type floats you are sending, when bytes get on network they get ordered in little endian. I had similar problem with udp connection, and I solved it by parsing floats as little endian on client side.

Upvotes: 0

Related Questions