Eeztire Decoding Issues

[flyboy013]

I'm using the eezrv decoder to receive the tire sensor information on my RV to load into Home Assistant. With the help of the information in issue #2387 I have successfully decoded signals from 5 of my 12 sensors, but have discovered issues in decoding the other 7. The issues that I've encounter are below:

1. The checksum calculation is incorrect. It should be computed based on 7 data bytes, not 6. The code currently assumes the 7th byte is 0x00, but I’m seeing messages where the LSB of the 7th byte is set and included in the checksum calculation.

2. The tire pressure calculation is incorrect. I have tires with pressures of 36, 85, and 110 psi. For 110 psi, the current pressure formula would require the reported pressure to be greater than what the single pressure byte can report. For these higher pressure reports I’m seeing the LSB of data byte 7 set. I’m still working on determining the correct pressure calculation when this bit is set.

3. The reference to “TPMS10ATC” in the device name should be removed. According to the manufacturer’s website the TPMS transmitter (ie. sensor) is E618 and it works with several displays including the T515, E518, and the E618 (TPMS10ATC).

4. I have several sensors in which the checksum validation fails (other than due to issue # 1 above). The checksum in the message is the computed checksum along with the MSB (or’ed with 0x80) set. I haven’t yet determined the logic for the additional bit being set.

5. The documentation states the message being 7 bytes containing the checksum (1 byte), sensor id (3 bytes), pressure (1 byte), temperature (1 byte), flags (1 byte), and a trailing byte of 0x00. The trailing 0x00 should be reflected as a second flag byte which is evident with the LSB set when the pressure is greater than 0xFF.

6. The sensor is capable of reporting a fast leak. Need to determine how this is reported in the message and have this information outputted.

Below are the codes that I have received from the 12 sensors, in case anyone wants to assist in resolving the issues identified above.

codes : {80}ffff89597d2a3c4c0001
codes : {80}ffff9f379699f0490000
codes : {80}ffffb2598799f0490000
codes : {80}ffffb993432af0490000
codes : {80}ffffbb3b8e7535470001
codes : {80}ffffc551e654f1490000
codes : {80}ffffd1af608aef490000
codes : {80}ffffd3315712f0490000
codes : {80}ffffdbaeff0562470000
codes : {80}ffffe83b8ef762460000
codes : {80}ffffe9af001261470000
codes : {80}ffffedaef72161460000

@ProfBoc75, @zuckschwerdt, @Gliebig

[gdt]

Thanks for the concise report! I will assume you are going to figure this out and submit one or more PRs to improve the code.

[flyboy013]

Yes. I've almost figured it all out. Initial testing yields the desired results. I plan on cleaning up the changes and submitting a PR in the next few days to a week as time permits. Would like input / testing from initial developers if possible. They were tagged on this issue.

[Gliebig]

I've been having issues with the original decoder from this past spring. I have not had time to re-investigate over the summer months. Thanks for your efforts!!

[ProfBoc75]

Hi @flyboy013 : I'm busy for the moment, but in the meantime, are you able to capture several cu8 files in order to replay them. I will take into account your findings for sure and then correct the decoder accordingly.

[flyboy013]

All issues listed here have been resolved and merged. See PR #2664.