Ensemble not detected

[b1he]

While rare, I have noticed a few times when I select any service on DAB Melbourne 1, it will not play. I have made a recording where if I try to play it back, it shows the DAB time but does not recognise the ensemble. The opposite happens on welle.io, it plays the recording ok but says the DAB date is invalid.

Recording

[KejPi]

Thanks for reporting and for sharing the recording. The reason why AbracaDABra does not recognise the ensemble is that FIG0/9 is not transmitted. It contains ECC (required by AbracaDABra to consider ensemble as valid) and local time offset (LTO) that is probably required by welle.io to consider time as valid. I assume that the time shown by AbracaDABra has 10 hours offset. According to current DAB standard, FIG0/9 shall have repetition rate of 1 second [8.1.3.2]. I cannot remove requirement for FIG0/9 because it would cause a lot of other issues for compliant ensembles. But it is very interesting that it happens "rarely". I would assume that either they transmit FIG0/9 or not. In the recording you shared in Issue #88 there was FIG0/9 with the rate of 1 second and this this recordinmg there was none.

[andimik]

Yes, true, there is no 0/9

$ etisnoop -i melbourne1_nov2023.raw.eti | grep 0/9
Identified ETI type RAW
ERRORS: Not yet in DB
ERRORS: Not yet in DB
ERRORS: Not yet in DB
Error: FCT not contiguous
Incomplete frame in ETI file!
ETI file read error

@b1he

Does this ensemble has a reconfig? I cannot trust https://www.digitalbitrate.com/dtv.php?mux=9A&liste=1&live=628&lang=en because the reception is not good although the quality bars show all green ...

@KejPi

But it seems that there is ECC detected (maybe from another day??), see bottom line of the log:

Ensemble Country code : 0xf0

[KejPi]

Yes, it seems that they transmit it "sometimes" because otherwise AbracaDABra would never play the ensemble and @b1he stated that it happens in rare cases.

[b1he]

I don't think there have been any recent changes since #88 . That page at the moment is showing zero for ECC though as you mentioned could be reception.

Freq : 202.928MHz Ensemble ID : 0x0000 Ensemble Country code : 0x00 last update 18/11/2023 16:13:49 (Australia/Melbourne Time) by scanner MELBOURN (MELBOURNE)

[KejPi]

They definitely changed something, maybe it is only some mistake or technical problem in their equipment. In the recording from #88 I can see FIG0/9 with valid ECC 0xF0 with 1 sec period. ECC 0x00 is not valid value (ETSI TS 101 756 V2.2.1 tables 3-7) All regions in Australia shall use ECC 0xF0 according to Table 7. I really would like to help you, but currently I do not know how to remove requirement for valid ECC without creating issues like #98 for compliant ensembles. Furthermore some features like SPI application require ECC for unambiguous service identification. I will keep thinking about possible workaround.

[b1he]

It is very rare so I am not too concerned by this so it can be closed. I did find this document (page 18) which confirmed how it went to being 'Malaysia'.

[KejPi]

That is an interesting document. They practically say that they have screwed it up but they know about that. OK, closing this bug.

[andimik]

oh, very interesting, indeed! Thanks for sharing this link!