TMC messages with zero data

[windytan]

Some TMC messages have zero as their location or event code.

[windytan]

Not seeings these anymore.

[mvglasow]

Not seeings these anymore.

Intentionally? Or as a side effect of some other change?

I’m frequently seeing zero event codes on RDS Surveyor and wondering what they mean (though I haven’t come across zero location codes yet). If two tools which are not genetically related are seeing the same thing, that makes bug-related artifacts quite unlikely—so it seems these events are actually being received and probably transmitted.

What I noticed is that frequently these zero events arrive shortly after a “real” event for the same location, still within the persistence period of that event. I’m wondering if they’re some kind of cancellation messages.

The TMC standard specifies 2047 as a special event code and FFFF as a special location code for cancellation messages:

• Location code FFFF, regular event code: cancel all messages belonging to the same update class as the specified event code
• Event code 2047, regular location code: cancel all messages for the specified location
• Location code FFFF, event code 2047: cancel all messages from the sending TMC service

Then again, I remember seeing different cancellation message numbers for different groups of events, so the above list may not be exhaustive. However, I didn’t see any mention of event code 0 anywhere.

Attached is a log (iirc about 10 minutes’ worth of data) showing a couple of zero events. Reception was good that day—not a single block error—so transmission errors are quite unlikely.

• The zero event for location 12784 came slightly less than two minutes after an accident warning for the same location.
• Another zero event for location 12861 was received twice in the first minute of the transmission (before the first time message was received). There’s no corresponding “real” event for that location, possibly because the message was canceled before the log was started.
• Finally, location 11914 also has a zero event with no “real” counterpart. The zero event was repeated nine times, I suspect it keeps reappearing for a significant portion of the capture.

I ran the log through redsea 75d8833, which indeed did not report any zero events. Didn’t manage to build any older version, though.

If you’re interested in digging further, I can grab a longer log (beyond the minimum persistence of a TMC message), which will hopefully give a clearer picture.

20150522_bayern3.binstr.txt

[windytan]

Thanks for the report. That's pretty interesting. It would be weird if it's supposed to be a cancellation message, since there's no mention of such method in the standard.

I do see these zero events in redsea TMC output produced from that bit stream though:

{
  "group": "8A",
  "pi": "0xD313",
  "prog_type": "Pop music",
  "tmc": {
    "message": {
      "direction": "single",
      "event_codes": [
        0
      ],
      "extent": "-1",
      "location": 12861,
      "urgency": 0
    }
  },
  "tp": true
}

As for my above comment on the issue, I think I stopped seeing these zero messages just randomly. It was related to local YLE broadcast channel, not associated with any change in the source code.

[windytan]

Redsea is also currently agnostic about message persistence, since there's no storage of past messages. Actual cancellation messages will be printed as "message cancelled".

[mvglasow]

Here’s a longer log (about one hour’s worth of data), with a couple of zero events. Haven’t gotten around to running them through redsea yet, though. I did see, however, that for some of the locations, “real” events were received after the zero events, which is not what I would expect if these were actually cancellation messages.

Going through the standard again: there’s a cancellation message for each of the 39 update classes, as well as the “universal” cancellation code (2047). No mention of event code 0, though—as far as (my understanding) of the standard is concerned, it it not a standardized code.

rdslog_20170404_230524_DE_MUC_BR-KLASS.rds.zip

[mvglasow]

I contacted the broadcaster a couple of days ago, and today got a response:

We had this issue some time ago, which was the result of Metas [apparently the software they use] not always processing more than 3 TMC events from the police. Presumably this issue has returned since the police migrated from TIC2 to TIC3, as the number of events often exceeds 3 and different orders/priorities are used. We still need to verify this in detail, which can take a few more days.

Seems like this is a software issue causing them to send out invalid messages.

[windytan]

Interesting! Thanks for the research!

[andimik]

Same here. Thanks for investigation!