Supported devices for xexun protocol: Xexun TK102 Xexun TK102-2 Xexun TK103 Xexun TK103-2 Resiont TK110 Xexun X01 Xexun X02 Xexun X04 Xexun X05 Xexun X06 Xexun DDX04 Xexun DDX14 Xexun DDX15

Xexun protocol is updated: identification changed for those xexun devices that send messages in the following format: (027044861111BP05355227044861111190926A0611.4496S10639.5890E000.0073950000.0000000000L00000000) Now such devices are identified by serial number 027044861111 , not by IMEI 3552270448611111 as before. This is likely TK103 and TK110 devices. But it's not for sure. The other xexun devices that send messages in one of the following formats are identified by IMEI as usual: imei:864895030551111,tracker,191003074503,,F,044503.00,A,4700.08753,N,02853.79387,E,4.985,327.55; 190926151811,+31711117111,GPRMC,151811.775,A,5215.5816,N,00508.7693,E,28.31,83.20,260919,,,A*6D,F,SHAKE, imei:354778030121111,03,1.3,F:4.14V,1,143,5451,204,08,0D2A,B6E5\n\r This is likely TK102 , TK102-2 and TK103-2 , but it's not for sure either. So, if you are in doubt what to choose as ident when creating a device, you can: try to connect a device to xexun channel and see how it is identified or use proxy channel and handy hex viewer to see raw traffic from device

we've added a logic to correctly parse wrong timestamps caused by GPS Rollover problem that was detected for TK110 device type This problem is caused because GPS date is defined by 10-bit week number which results to max 1024 number. So when this number overflows to 0 then tracker (with firmware algorithms not covering this) starts to send time as it is in the beginning of the 1024 week period which is August 21, 1999.

xexun protocol is updated: Old TK102 devices are supported, that send arbitrary hexadecimal numbers at the end of packets. Example is here: https://forum.flespi.com/d/94-xexun-protocol

Time Zone setting is added for Xexun TK102-2 device, Actions tab. Setup correct Time Zone value (same as configured in tracker) and hit 'Send over connection' button. After that server will apply this value in timestamp parameter parsing. Some devices require password to change time zone. Please, ensure that correct 'SMS Password' is specified in device configuration.

Time Zone setting is also added for Xexun TK103-2 device. The details are in the post above .

Alarm Message BO01 packet message is supported for xexun protocol. The mapping of xexun alarm information codes into flespi parameters is below: 0 Vehicle power off - power.off.alarm=true 2 Vehicle robbery（SOS help) - sos.alarm=true 3 Vehicle anti-theft and alarming - towing.event=true 4 Lowerspeed Alert - low.speed.alarm=true 5 Overspeed Alert - overspeeding.event=true 6 Alarm when out of Geo-fence - geofence.alarm=true Additionally, numetic value of alarm information code is registered into alarm.code flespi parameter.

[Changelog] xexun protocol

namo

Xexun protocol update is planned for tomorrow 2020-09-02, 12:00 UTC - parsing will be switched to new parsing engine. This is an internal process, no changes in devices' work are expected.

namo

namo
Xexum protocol updated to now parsing engine.

namo

Alarm Message BO01 packet message is supported for xexun protocol.
The mapping of xexun alarm information codes into flespi parameters is below:

0 Vehicle power off - power.off.alarm=true
2 Vehicle robbery（SOS help) - sos.alarm=true
3 Vehicle anti-theft and alarming - towing.event=true
4 Lowerspeed Alert - low.speed.alarm=true
5 Overspeed Alert - overspeeding.event=true
6 Alarm when out of Geo-fence - geofence.alarm=true

Additionally, numetic value of alarm information code is registered into alarm.code flespi parameter.

namo

Xexun protocol is updated.
Add parsing of message content of BP00 packet Handshake signal message.
The following parameters may be registered for this packet (depending on the actual packet content):

device.imei
battery.level, %
battry.voltage, volts

Applicable for Xexun TK102

baja

The protocol will be affected by the change in type of parameters gsm.mcc and gsm.mnc to be installed in 2 weeks - May 23rd, 2022: both parameters that now have type "string" will be stored as "number". The possible leading zeroes in MNC will be ignored (e.g. the value "01" will be stored as 1).

YuryAheichyk

The protocol will be affected by the change in parameter can.dtc to be installed in 2 weeks - Mar 15th, 2024: the parameter can.dtc is currently of string type and will be converted to type array with separate DTC codes.

Added parameter can.dtc.array as an example of future implementation of can.dtc

YuryAheichyk

YuryAheichyk changes have been applied, the can.dtc parameter type changed to array

namo

Xexun protocol is updated: BS 50 General data package is supported.

namo

Xexun protocol is updated: BS 50 Parameters settings package is supported.

YuryAheichyk

Added new devices:

YuryAheichyk

The OBDII DTC codes registration is planned to be changed. Currently, error codes are stored in the can.dtc parameter as an array of strings. To unify with other diagnostic protocol types, errors will be stored as an array of objects.

The changes will be applied in 2 weeks, on May 8, 2025.

For reference, two additional parameters have been added:

can.dtc.strings - contains errors in the current format (will be removed in 1 month, on May 24, 2025)
can.dtc.objects - contains errors in the new format (will be removed in 2 weeks, on May 8, 2025)

can.dtc.strings example:
["P0020","U0001"]
can.dtc.objects example:
[{"standard":"OBDII","code":"P0020"},{"standard":"OBDII","code":"U001"}]

YuryAheichyk

YuryAheichyk changes applied, can.dtc array contain objects now.

For reference, two additional parameters added:

can.dtc.strings - contains errors in the old format (will be removed on May 24, 2025)
can.dtc.objects - contains errors in the new format (will be removed on May 24, 2025)

can.dtc.strings example:
["P0020","U0001"]
can.dtc.objects example:
[{"standard":"OBDII","code":"P0020"},{"standard":"OBDII","code":"U001"}]

YuryAheichyk

YuryAheichyk changes applied, can.dtc.strings and can.dtc.objects parameters removed

namo

Xexun protocol is updated. The following change is introduced into the operation of <FAAF> variant of the protocol:

In cases when the overall structure of packet is correct, but any of underlying Data types contain unknown bytes, parsing error followed by disconnect won't happen any more.

Instead, connection will continue to operate, and unparsed bytes will be stored into custom.param.hex.X parameter in format of a HEX string [where X is decimal number of the corresponding Data type]

Applicable for devices that works over the newest protocol variant: X01, X02, X04, X05, X06, DDX04, DDX14, DDX15