1

I have a couple of gnuradio apps that communicate across the internet. The flow graphs are rather complex, so I boiled them down to simplest form to re-create an issue I'm seeing.

The issue is that, when I invoke the client, it connects to the server as expected, but immediately throws an exception "Value nan can not be represented in the target integer type" and appears to be coming from the wavfile sink block.

I simplified the server down to a simple dial tone flow graph that presents the dial tone signal on a TCP port. The client can connect to that port and expect to receive the dialtone signal.

If I run the client and server on the same computer and connect using localhost, the client connects fine and works as expected. However if the client and server are separated at a distance (over the internet) then I receive the nan exception every time.

Theories:

  1. Perhaps the client is starting up and not receiving data soon enough (connect time + 20ms latency) and the wavfile block is receiving NaN's from the socket PDU or stream to tagged stream block?
  2. Perhaps the data is being mangled as it cross the internet in such a way that the packets aren't arriving as expected - fragmentation? I tried MTU 512 but the problem still exists. Trued MTU 10000: same result.
  3. Maybe I'm overlooking a simple usage/syntax error when building my flowgraph
  4. There's a bug in the wavfile sink and it should more gracefully handle the absence of data.

UPDATE 1: Logged a bug report to gnuradio project https://github.com/gnuradio/gnuradio/issues/1763

UPDATE 2: The socket PDU block seems to play a significant role. If I tweak the packet length parameter of the stream to tagged stream block, along with the MTU parameter of the socket PDU block, I can get either error free stream with dropped packets (low MTU) or a dead stream with NaN exception (high MTU).

Server Flowgraph enter image description here

Client Flowgraph (XYZ.com is of course not my real IP) enter image description here

wav result across the internet (20-100ms latency) enter image description here This wav file is 1k and is truncated probably at the same time as the exception but it's hard to tell for sure.

wav result across local interface (1ms or less latency) enter image description here Across the local interface the client runs happily until I stop it. Received signal is as expected. One small thing - notice the glitchy initial first few samples? Not sure if this is a factor. Probably not. But the data is junk for the first 10ms or so even across local interface.

Brad Hein
  • 10,997
  • 12
  • 51
  • 74
  • From my experience the "glitchy" start to signals in GNURadio is quite common, and has not affected any of my systems. Just an observation - the first half of your 20-100ms delayed wav file appears to visually match the signal at the start of your local wav file. Do both pictures have the same time scale? Or have you just zoomed in on the first wav file to illustrate the problem? – Campbell McDiarmid May 04 '18 at 01:27
  • Different time scale, the short one (internet path) is zoomed to fit the width of the window. The local interface sample looks like a good dialtone waveform (350+440Hz) as expected. – Brad Hein May 04 '18 at 14:04

0 Answers0