VL502 JT808 overspeed alarm not decoded

Hi hello everyone,

I think there is a missing alarm mapping for the Jimi VL502 in the JT808 decoder.

I noticed that VL502 devices were not generating any overspeed alarms in Traccar, so I tested two units with lower speed thresholds and checked the raw traffic.

The devices do send the overspeed alarm using the transparent "0x0900" message, "F0" data, subtype "0x03".

Example from a real device:

7e0900001b4f07788f224e0070f02608202132540002030125023832000c000a003add320494a9c00f7e

Relevant part:

03 01 25 02 38 32

According to the VL502 protocol documentation, "0x25" in this message is Speed driving. In this sample the extra data is ASCII "82".

I found several other samples as well, with values 92, 84 and 45.

Looking at "Jt808ProtocolDecoder.decodeTransparent()", subtype "0x03" already handles "0x1A", "0x1B", "0x1C", "0x23", "0x26" etc., but there is no case for "0x25", so it seems to be skipped.

Would this mapping be correct?

case 0x25:
    position.addAlarm(Position.ALARM_OVERSPEED);
    break;

I can provide the complete raw log if needed.

Thanks.

Please provide the documentation.

Sure. This is the VL502 protocol documentation I used:

https://www.traccar.org/protocol/5015-jt808/Communication%20Protocol%20of%20VL502%20%20V1.0.7_eng.pdf

The relevant section is 9.14.1.3 – Report of alarm and driving behavior data 0x03. In the alarm ID table, "0x25" is listed as Speed driving.

Thanks.

Implemented:

https://github.com/traccar/traccar/commit/bde6df55b8711310c86d93ff5aa02271cac98441

Thanks Anton, much appreciated!!!

Hi Anton,

I tested the overspeed change and can confirm that the VL502 0x25 alarm is now decoded correctly as overspeed. Thanks again for implementing it.

After that, I reviewed the F0 / 0x03 alarms actually sent by several VL502 devices over a few hours, to check if there were any other relevant IDs missing from the decoder.

The only additional one I found that seems to have a direct Traccar equivalent is 0x0E, which the VL502 documentation defines as Overrun idling time alarm.

Example:

7e0900001b4f07788f227a001bf0260820220750000203010e023233000c000a00396865048caad0a87e

I found this alarm multiple times from different VL502 devices.

Would 0x0E be appropriate to map to Position.ALARM_IDLE?

Thanks.

Added.

Thanks Anton!