EDI network streaming

[sronline]

the software is really great. What is missing for analyzing a multiplex is the ability of receiving data by EDI network streaming (ETI over network - ETSI ETS 300 799, tcp or udp).

Would be great if this could be implemented in future.

Can be tested with ODR-DabMux.

[KejPi]

This is definitely out of scope.

[andimik]

@sronline please use odr-dabmod

[KejPi]

If you are on Linux or macOS, you can create FIFO (named pipe) and use it as output for odr-dabmod and raw file input for AbracaDABra. This way you can avoid creating huge IQ files.

[sronline]

I'm using odr-dabmux and odr-dabmod on linux and AbracaDABra on Windows. Is there a way to get the data live to AbracaDABra?

[KejPi]

Reopening this issue for the discussion about possible workaround although the previous statement is still valid, direct support in application is out of scope.

According to this post it seems that might be possible workaround that could work on Linux and macOS. I am not sure about Windows, maybe MinGW64 could help. Note that currently the proposed command sequence does not work because application does not recognize the server as valid RTL-TCP server but this is should be an easy modification. But I do not know how to test it, are those EDI streams available to public so that I can use some for testing?

The other option could be to use named pipe (FIFO), that might already work on Linux but I have not tried.

[sronline]

If you can change that the server is recognized as valid RTL-TCP server, I can test it. Perhaps adding a new Device named TCP? Using named pipes with Windows seems not to be easy.

[KejPi]

Named pipes on Win work different way. The change is already pushed, if you compile from source, you can try. New device is not introduced, application accepts server that does not have expected identification and uses it as RTL-TCP with unkonwn tuner.

[nona00]

To test the change, I'm trying to build the windows version from source, but it fails at linking.

Do you have a hint for me?

I'm using Windows 10, Qt 6.7.3. External libs (mpg123-1.32.7) are compiled with mingw1120_64 and copied to folder ../AbracaDABra-libs

The missing symbol __imp_PathIsRelativeW of libmpg123 seems to be releated to Shlwapi.

Set PATH=C:\Qt\Tools\mingw1120_64\bin;%PATH%
Set PATH=C:\Qt\Tools\CMake_64\bin;%PATH%
Set PATH=C:\Qt\6.7.3\mingw_64\bin;%PATH%

cmake -G "MinGW Makefiles" -DQCUSTOMPLOT=OFF -DUSE_SYSTEM_QCUSTOMPLOT=ON -DUSE_PORTAUDIO=OFF -DUSE_SYSTEM_MPG123=OFF -DUSE_SYSTEM_PORTAUDIO=OFF ../
mingw32-make

[KejPi]

Building the apps under Windows is always painful :-( Your steps seem to be ok, but I do not do it this way. I use MinGW64 environment to build all libs and to install them is dedicated folders. And also mpg123 I compiled last time is mpg123-1.29.3, maybe this could be a problem.

I build libs following way.

1. Create AbracaDABra-libs/src folder
2. Unpack or checkout all libs sources to this directory
3. I have following script located in AbracaDABra-libs/src folder:

#! /bin/bash

SRC_DIR=$PWD
INSTALL_DIR=$SRC_DIR/../
JX=-j4

# libusb
echo "============= libusb ============" 
cd $SRC_DIR/libusb-1.0.26/
make clean
./configure --prefix=$INSTALL_DIR
make $JX && make install

# rtlsdr
echo "============ rtlsdr ============"
cd $SRC_DIR/rtlsdr
[ -d build ] && rm -Rf build
mkdir build
cd build
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$INSTALL_DIR/lib/pkgconfig/ cmake  -G "MSYS Makefiles" .. -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR
make $JX && make install

# faad
echo "============ faad2 ============" 
cd $SRC_DIR/faad2
make clean
./bootstrap 
./configure --prefix=$INSTALL_DIR
make $JX && make install

# fdk-aac
echo "============ fdk-aac ============" 
cd $SRC_DIR/fdk-aac/
[ -d build ] && rm -Rf build
mkdir build 
cd build
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$INSTALL_DIR/lib/pkgconfig/ cmake  -G "MSYS Makefiles" .. -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR
make $JX && make install

# mpg123
echo "============ mpg123 ============" 
cd $SRC_DIR/mpg123-1.29.3/
make clean
./configure --prefix=$INSTALL_DIR
make $JX && make install

# portaudio
echo "============ portaudio ============" 
cd $SRC_DIR/portaudio/
make clean
./configure --prefix=$INSTALL_DIR
make $JX && make install

# airspy
echo "============ airspy ============" 
cd $SRC_DIR/airspyone_host
[ -d build ] && rm -Rf build
mkdir build 
cd build
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$INSTALL_DIR/lib/pkgconfig/ cmake  -G "MSYS Makefiles" .. -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR
make $JX && make install

# missging libs
cp $INSTALL_DIR/bin/libairspy*.a $INSTALL_DIR/lib/

# SoapySDR
echo "============ SoapySDR ============" 
cd $SRC_DIR/SoapySDR
[ -d build ] && rm -Rf build
mkdir build 
cd build
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$INSTALL_DIR/lib/pkgconfig/ cmake  -G "MSYS Makefiles" .. -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR
make $JX && make install

# SoapyAirspy
echo "====== SoapyAirspy ======" 
cd $SRC_DIR/SoapyAirspy
[ -d build ] && rm -Rf build
mkdir build  
cd build
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$INSTALL_DIR/lib/pkgconfig/ cmake  -G "MSYS Makefiles" .. -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR
make $JX && make install

# SoapyRTLSDR
# not compatible with Oldenburger's RTLSDR
echo "====== SoapyRTLSDR ======" 
cd $SRC_DIR/SoapyRTLSDR
[ -d build ] && rm -Rf build
mkdir build  
cd build
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$INSTALL_DIR/lib/pkgconfig/ cmake  -G "MSYS Makefiles" .. -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR
make $JX && make install

########################################################################
# Done
cd $SRC_DIR

4. I open MinGW64 shell, navigate to AbracaDABra-libs/src folder and run ./build.sh

NOTE: you need to align the script for your source directories (libUSB and mpg123 have version in name, etc.) and remove libs you do not need (like SoapySDR). Good luck!

[nona00]

Yes, it is really painful to build under Windows.

Thank you very very much for your build instructions, I was now able to build the source on my way with the following modification:

`diff --git a/CMakeLists.txt b/CMakeLists.txt
index e1ce70a..eac4291 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -107,6 +107,8 @@ if(WIN32 OR (APPLE AND APPLE_APP_BUNDLE))
set(USE_SYSTEM_AIRSPY OFF)
set(USE_SYSTEM_SOAPYSDR OFF)
set(USE_SYSTEM_QCUSTOMPLOT OFF)
+

• set(CMAKE_CXX_STANDARD_LIBRARIES -lShlwapi)
  endif()`

This allowed linkage of libmpg123.

To stream the data I adapted the command from rundfunkforum:
odr-dabmod mux2stream.ini | nc -l 192.168.1.123 1234

The TCP connection to odr-dabmod can be established :-)

The channels are listed, but I am not able to get a stable transmission.

I'm trying to figure out if that it is caused by commands sent to the TCP socket which are received via nc or a blocking issue. odr-dabmod detects errors and restarts the modulator.

When I connect with telnet the data runs fine and odr-dabmod does not run into an error. In telnet when I type chars I can see them in in the console of odr-dabmod.

I tried with socat und unidirectional mode instead of nc:
odr-dabmod mux2stream.ini | socat -U -d -d -d TCP-LISTEN:1234,BIND=192.168.1.123 -

But the issue is the same.

Perhaps switching from TCP to UDP could help.

[KejPi]

I will check the issue with missing lib on my side and fix it int the repo, thanks for reporting it.

What is the data source for odr-dabmod? The point is that RTL-TCP input is designed in the way that the server is "clock master". Application just reads what is available in the socket. If it cannot provide proper timing then it will not work. For example if odr-dabmod reads data from ETI file and generates U8 IQ output that is passed to nc, then this configuration will not work because anytime AbracaDABra tries to read input, it will get new data until the file is read by odr-dabmod. I am not sure if the explanation is clear. There is RAW file input designed for input from file, all other inputs are designed for live stream with defined sampling rate.

[KejPi]

I have just updated all libraries for Windows and I do not need to link with Shlwapi. Maybe it is W11 related, I still build with W10.

[nona00]

I did a new setup of ODR in a virtual machine to send the data to AbracaDABra.

There it works now with the rtl tcp device :-) It seems on the other system it was a cpu performance or network issue.

Source of odr-dabmod is a live essemble created by ODR-DabMux, which sends its data by edi to odr-dabmod.

The the big advantage of an EDI network streaming input in AbracaDABra would be that udp multicast streams could be used. In this case odr-dabmod would not be needed and simply EDI of ODR-DabMux could be used.

[KejPi]

Yes, it coudl be used but it would require significant effort to implement support for EDI/ETI and major rework of the application that is designed to receive DAB signal from antenna. Decoding from EDI/ETI is different approach. Since ODR-Dab tools can be used to support this rare use-case I still think it is out of scope of AbracaDABra.

I will keep this issue open for some time as a discussion topic in case tehere is anythign I can do to improve support for stream from ODR-DabMux.