SPI detection

[andimik]

Grüß dich Clem,

I know that SPI integration is still experimental (although Qirx is now the best tool for that), but let me write this issue anyway ...

I've realized that the (background) SPI detection does not work for Slovene's national DAB mux R1 (the service is called Spored in Slovenia, which means 'preview'). This is similar to https://github.com/JvanKatwijk/qt-dab/pull/238 where I found out that Jan uses some keywords in order to check for SPI resp. EPG services.

In Windows, the corresponding mux folder in the SPI directory is not created at all (as you cannot select a data service in Windows).

qirx.logqirx.log-2021-11-27--09-38-17.txt

In cQIRX under Linux it's the same. The folder ~/.local/share/qirxConsole/SPI is empty when you are just locking to the mux.

But - compared to Windows - cQIRX allows to select a data package. Right after serv=Spored this folder E49200 will be created immediately.

Although I know that there are only 2 files transmitted in this mux as also Qt-DAB says, the number of Objects is 2, see

Starting hidden service Spored          
starting a backend for Spored           (E4910002)
dirSize 91, numObjects 2, segmentSize 91

it might be useful for other muxes as well.

BTW: This is the content. E49200.zip

You can test it with https://github.com/Opendigitalradio/ODR-DabMod and then play it in qirxConsole (without starting rtl_tcp of course) with socat

cat /tmp/slovenia.eti | odr-dabmod  -f /dev/stdout -F u8 -a 0.6 | socat tcp-listen:1234 -

or with netcat

cat /tmp/slovenia.eti | odr-dabmod  -f /dev/stdout -F u8 -a 0.6 | nc -l 1234

and the eti file (length = 1 min 9 sec) is attached in the zip file. slovenia.zip

Andreas

[softsyst]

Hi Andreas,

Thanks for this input. I think the reason for the missing EPG is that qirx is in a similar situation as others, in that it is not too easy to recognize a service containing an EPG. At least - until now - I was not able to find an unambiguous indication from the FIC whether an EPG is available or not. Perhaps not an error, but a clear deficiency in the Standard, IMO.

Apart from trying your suggestions, a raw file would most probably help. Your logfile reports that no EPG label is found. The SW currently looks for labels containing one of the following:

private string[] _epgLabels = new string[4] { "epg" ,"guide" ,"spi" ,"logo" };

The "Spored" which you obviously were able to identify is (of course, because no test data available) not in the list. Perhaps it would be a better solution to put these into the config file and let the user enhance it when a new EPG designation is found.

In case you should know (or have an idea) how to uniquely identify EPG from FIC, this would be worth a try.

[andimik]

Yes. Jan also told me that there is no chance for him to identify an SPI service.

[softsyst]

Due to a trivial error the SPI recognition in FIG0/13 didn't work. After it had been fixed, the Application Type of 7 (SPI) has been found on all ensembles with one or more EPG service components. This is now used as the indication in the software to collect the EPG. The above mentioned strings will (hopefully) no longer be necessary from 3.2.2 on.

In Norway, the "Riks" ensemble carries two EPG services. No other one has been found to date. However, qirx will take it into account and be able to treat more than one EPG service in 3.2.2 Thanks to @esplien for kindly providing the necessary long raw file!

[softsyst]

Hi Andreas,

I tried to check what you suggested by using the ODR tools to generate an IQ file from your ETI, to see whether the EPG works now in your file from Slovenia. Sadly, the ODR configure does not find the fftw on my debian. Do you have an idea where it searches for it or how I could make it find the fftw?

Thanks for now, Clem

[andimik]

Yes, you need FFTW 3. A user wanted just to install FFTW 2, which is not enough. Perhaps you have faced the same problem?

https://github.com/Opendigitalradio/ODR-DabMod/issues/47

https://github.com/Opendigitalradio/ODR-DabMod/blob/master/INSTALL.md

try sudo apt-get install libfftw3-dev and then disable the UHD as you won't need it as well.

[softsyst]

Thanks! With your install command, the install and configuration process worked. However, with nc the ODR command completed with an error, like this:

clem@debian11:~/ODR/ODR-DabMod-master$ cat tmp/slovenia.eti | odr-dabmod  -f /dev/stdout -F u8 -a 0.6 | nc -l 1234
ODR-DabMod version 2.5.0, compiled at Mar  1 2022, 00:32:26
Compiled with features: zeromq SSE 
Input
  Type: file
  Source: /dev/stdin
Output
  Name: /dev/stdout
  Sampling rate: 2.0480 MHz
      Configuration parsed. Starting up version 2.5.0
ERROR Could not set priority for modulator:1
      Setting up timestamp decoder with 0 offset
      Input file format: raw, length: 0, nb frames: endless

The file seems to be recognized. I tried to connect from local and remote, but no success. The qirxConsole worked. On commanding start=1, the connection should happen, as the ODR is listening on port 1234 (which is configured for rx#1 on the localhost).

I did not try with socat, as I have to install it first.

[softsyst]

The ODR seems to work, because when I omit the nc command, the expected binary gibberish is output on the terminal.

[andimik]

pwd will tell you the actual directory.

I fear the cat command wants to play a non existing file as I don't think you have a tmp under ~/ODR/ODR-DabMod-master

[andimik]

Or you write the output to a file instead of sending it to port 1234.

If the file really exists in this directory, then try to include 127.0.0.1 in the nc command.

Or you could basically open a second terminal and collect the port 1234 and save it to a raw file (nc 1234 > /tmp/foo.raw). This raw file then open in Qirx or Qt-DAB.

I think the line with the error in odr-dabmod is normal, but I am not 100% sure.

[andimik]

Ok, your file exists otherwise the error is different...

Then please install the tool pv which is a buffer.

sudo apt install pv

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

[softsyst]

Thanks for comments. Yes, of course the file exists: slovenia.eti, Size 17799168. I copied your command from above here with the only difference being the removed leading backslash in front of the tmp.

No success with the network connection though. But another, even simpler method works and allows me to investigate the data: Just replacing the /dev/stdout with a filename, like slovenia.raw produces a raw file which runs in qirx on Windows. Music is playing, but my log produces some errors. I'll investigate what happens with the SPI. The "Spored" is listed in the "ensemble" window.

[softsyst]

What I did not notice at first glance, is that the SPI obviously worked, as the only picture present in the raw is displayed. It is for Slo 1 Prvi. See above. The log reports that the MOT directory is complete. Inspection of the xml file shows that only for Slo 1 Prvi an image is noted. Thus, everything seems ok, or do you think there are images missing?

Anyway, the SPI recognition only from the Application Type "SPI" (=7) works here as well. No magic strings needed any more!

[andimik]

Ok thanks for the update! I'll try later.

Yes, only the first program Slo 1 Prvi has an SPI image (in only one resolution, BTW).

And I'll check with Riks from Norway (I can receive it as well) regarding the two SPI services.

[softsyst]

No further comments on this one. I close it.