EPG logos from OpenDigitalRadio SI encoder are not shown

[nona00]

Hello,

i'm testing transmitting EPG logos with OpenDigitalRadio. I created a multiplex with 2 channels and created the SPI with 4 logos each with ODR-Bridge-EPG.

Playback of audio channels works with qirx, but no logos are decoded:

To be able to analyze the issue, I uploaded an 1 minute iq recording of the multiplex:

https://www.file-upload.net/en/download-15390191/ODR.raw.html

AbracaDABra is able to decode the logos:

[softsyst]

Thanks for the raw file. I had a look.

What I see here:

• Many "MOT packet sequence error"
• Only packets of type "MOT Body" are recognized. This is not sufficient. QIRX only decodes SPI in "directory mode", requiring packets of type "MOT Directory". This is a requirement of the Standard.

Please have a look at Issue #143, where I commented on a similar issue.

[nona00]

I checked the QIRX log and can also see the MOT packet Sequence errors. I read on ODR mailing list, that this could be a padding issue with the ODR SI encoder.

But regarding the missing MOT Directory you mentioned, I can't see an issue with other analyzers, e.g. DAB-Scout:

[softsyst]

Maybe the 1-minute raw is too short, or the sequence error is the reason. The MOT Directory message would also show up in the QIRX log (what you had activated, but make sure to use "Debug" level), which isn't the case with your raw. Packets showing a sequence error are discarded. You could easily find the Directory message by its orange "Warning" color (in log4view), selected for easy recognition. It would look similar like so:

[softsyst]

The sequence error is the culprit. If I deactivate it, the logos appear:

[nona00]

Thank you very much for your analysis, i will create an issue at ODR-Bridge-EPG.

[nickpiggott]

I contribute to the code base at odr-radioepg-bridge.

Which sequencer counter is not correct? (There's a number of different ways of connecting the output of odr-radioepg-bridge to the multiplexer, and one of the methods will recreate new identifiers on each rotation if the carousel).

[softsyst]

Hi Nick,

It is the "Continuity Index", DAB Standard 5.3.2 Packet mode - network level. Quote: Continuity index: this 2-bit, modulo-4 counter shall be incremented by one for each successive packet in a series having the same address. It provides the link between successive packets, carrying the same service component, regardless of length.

What I observe, is the following: With most packets, their sequence is from 0 ..3, modulo 4, as it should. However, if a datagroup start has been reported, the packets Continuity Index starts from zero again, breaking the sequence. IMO not correct, as the address of the newly reported DGroup packet did obviously not change.

Clem

[nickpiggott]

I've had a look at the code today, and I think I can see the condition where this happens.

The generate-epg process creates a file of packets. odr-dabmux reads these packets in and cycles through them. At the final packet, it loops to the first packet again.

Within a file, the packets continuity index is progressing as expected 0,1,2,3,0,1,2,3 etc. The first packet in the file always has continuity index 0.

However, if the final packet in the file has a continuity index !=3, then there will be a discontinuity as it "loops". The MOT Directory is the FIRST object in the file, so unless you're lucky, it will be the in the first packet with a discontinuous packet continuity value, and therefore may not be decoded. If the MOT Directory is not decoded, the entire SPI service cannot be decoded.

The only way I can see to fix this problem is to add padding packets with 0 byte payloads, at the end of the file, so that the final continuity index value is always 3. I'll try adding that to the code today.

Interesting observation, and a detail that's never been picked up before.

[nickpiggott]

EN 300 401 (section 5.3.2) says two things:

"Continuity index: this 2-bit, modulo-4 counter shall be incremented by one for each successive packet in a series having the same address. It provides the link between successive packets, carrying the same service component, regardless of length. "

and

"Address: this 10-bit field shall identify packets carrying a particular service component within a sub-channel. Address 0 shall be used for padding packets and shall not be assigned to any service component. Up to 1 023 service components may be carried simultaneously in a sub-channel."

So the assumption is that padding packets, as described in the standard, are only used to pad the data channel to it's allocated capacity, not within an application as discardable packets.

What's the right way to add a padding packet within an application (specific packet address)?

My current assumption is to create a packet where:

Packet address = application packet address (1)
First = True
Last = True
Continuity = the appropriate sequential value
Useful Data Length = 0

Is this a reasonable assumption?

[nickpiggott]

I've written a [more|less] elegant approach that simply duplicates the packet stream into the output file until the final packet has continuity index of 3.

That means the file could be twice or four-times bigger than than the requirement and will contain two/four repetitions of the SPI bitstream. That means acquisition time is unchanged, but the continuity index will be consistent.

If anyone wants to try it, the amended libraries are in my GitHub repo (not yet pushed to ODR) - https://github.com/nickpiggott/python-dabmsc and https://github.com/nickpiggott/odr-radioepg-bridge

[nona00]

Thank you very much, I will try it and give feedback.

[nona00]

YES! It solves the issue :-)

Logos are visible in qirx and no more sequence errors are in the log.

I uploaded an 1 minute iq recording of the data:

https://www.file-upload.net/download-15395942/ODR.raw.html