odr-dabmod with netcat or socat does not work

[andimik]

I'm facing problems with odr-dabmod, but only in combination with socat and netcat, even on the same machine (localhost).

This is not related to a particular eti file, have tried several files from many countries as input. Below I'm using the well-known one from http://tipok.org.ua/downloads/hardware/DAB-TX/Spartan6-FPGA/EasyDABv2/0,0x0425.bin.eti

$ cat foo.eti | odr-dabmod  -f /dev/stdout -F u8 -a 0.8 | nc -l 1234
ODR-DabMod version v2.4.2-9-g0f05769, compiled at Nov 27 2021, 11:53:07
Compiled with features: zeromq output_soapysdr SSE 
Input
  Type: file
  Source: /dev/stdin
Output
  Name: /dev/stdout
  Sampling rate: 2.0480 MHz
      Configuration parsed. Starting up version v2.4.2-9-g0f05769
ERROR Could not set priority for modulator:1
      Setting up timestamp decoder with 0 offset
      Input file format: raw, length: 0, nb frames: endless
@

�o� 

Please note the special characters at the end. They prevent me from getting a stable and error-free DAB signal which I want to use in Qt-DAB or cQIRX or welle-io.

See impulse waterfall diagram attached (remark: the DAB channel 9A is an example and has nothing to do with a real signal on that channel).

As soon these special characters appear odr-dabmod might stop (but not in all cases).

When I write the output into a file or to a fifo file, this works, indeed.

Any idea?

[andimik]

Well, I tried a different approach:

same command like before

$ cat ./dab/0,0x0425.bin.eti | odr-dabmod  -f /dev/stdout -F u8 -a 0.8 | nc -l 1234

and in a second console

nc 127.0.0.1 1234 > /tmp/test.raw

and load that raw into a program. This works indeed, but makes only sense when the DAB tool has a raw file input.

For example, cQIRX and Andi Gsinn's DAB Player don't have such an input (and might not get it in near future).

And trying to send the raw-file again to the port 1234 fails:

cat /tmp/test.raw | nc -l 1234
@
��

[mpbraendli]

I don't understand where this extraneous output comes from. I mean, if cat /tmp/test.raw | nc -l 1234 does that, I suppose it comes from the TCP connection, and nc outputs it to stdout.

How do you connect QIRX/Qt-DAB/welle.io to that socket?

[andimik]

I'm connecting via localhost and built-in rtl_tcp-connection in Qirx/Qt-DAB/welle.io.

I found out (by chance) that odr-dabmod's output (which is sent to port 1234 via nc) is the same format like when a RTLSDR dongle delivers it via rtl_tcp (which needs a live signal, indeed).

I gues that this connection is bi-directional and the special characters are commands from the DAB program. And it seems that it is sent faster than in real-time.

Even nc -l 1234 2> /dev/null > /dev/null did not help. And I also tried to use listen=tcp://*:1234 in a config file (but I fear the ZMQ protocol is not the same as TCP).

Does odr-dabmod have something like a real-time clock (which might prevent nc sending packets too fast)?

And what about to add a new output beside of ZeroMQ? Like this:

[output]
output=tcp

I really was trying to find a solution (file input for rtl_tcp instead dongle), but my only chance was Heiko (nick name: Drehrumbum) from Germany who has programmed such an input, but he does not want to publish it.

[mpbraendli]

I see two source of problems:

• I don't know the details of the rtl_tcp format, and I don't know if connecting the ODR-DabMod IQ output to a rtl_tcp input will work.
• The ODR-DabMod file output expects back-pressure to slow it down, I don't know if the rtl_tcp inputs will do that

Since your input is a file, why do you want to run ODR-DabMod in realtime? You could generate an IQ file faster than realtime and then play that IQ file instead.

You could use the rate limiting features of pv or mbuffer. 2048000 IQ samples per second x 2 bytes per IQ sample

[andimik]

Dear Matthias,

you are a genius!

You could use the rate limiting features of pv or mbuffer. 2048000 IQ samples per second x 2 bytes per IQ sample

First I tried mbuffer, but this does not work properly (no idea why), signal is not stable in DAB Player (but Qt-DAB and Welle.io played it), see SNR graph below:

odr-dabmod foo.eti -f /dev/stdout -F u8 | mbuffer -r 4096000 | nc -l 127.0.0.1 1234

But pv really has no dropouts over several minutes! The syntax is:

odr-dabmod foo.eti -f /dev/stdout -F u8 | pv -L 4096000 | nc -l 127.0.0.1 1234

I'm closing as the DAB Player under Windows (see screenshots above) now works with ETI file input :-)

BTW: It had nothing to do with the special characters. The main reason was the ODR-DabMod speed, which was faster than realtime.

[mpbraendli]

Thanks, I guess that also shows that rtl_tcp is nothing else but IQ data over TCP, useful to know.