Add support for EEZ Tire TPMS

[Gliebig]

Thanks for your suggestions! I had some time today to make new recordings and I pushed them to my fork and updated the READEME.md and deleted the old data.

It takes some time to setup the test and to be able to capture since there is no manual trigger on the sensor. The link you sent https://triq.org/spectrogram-next/ was very helpful! Should be able to move to the next phase. I'm a ME and fairly technical but this byte stuff is something that I've struggled with and with some help should be able to get this figured out.

[ProfBoc75]

Hi @Gliebig , I tried to read your samples but they are durty, lot of noise into the captures. Are you able to make new records very closer the valves ? Also try several options to get the best result as explained here https://triq.org/rtl_433/ANALYZE.html#analyze-the-data-packet Try with -s 1024k to get better sampling.

[zuckschwerdt]

We can already confirm that the signal is OOK and the signals looks fine in the spectrogram. (@ProfBoc75 that's how most TPMS look, you won't get a cleaner signal) There is some clipping, so if at all I'd suggest more distance or a lower gain. The -s 1024k is a good suggestion, for some reason neither the -Y classic nor the -Y minmax can properly demod the signal :(

[Gliebig]

OK, I will do a few more test runs this morning after I get the walks shoveled. I did notice another signal was popping up from somewhere when recording -S unknown capturing the TPMS the farther I moved the EBIKE from the antenna. I've tried to isolate the signal as much as possible. I'm inside an office inside a steel warehouse with no activity within 500'. I have a laptop with a second RTL-SDR running a stopwatch and URH. I can easily see the data packet come in every 5 minutes and then note the g... file number that appears on my Xubuntu system with the 1st RTL-SDR dongle. The the signals look really good with URH but they are in the wrong format for use with rtl_433. I then make sure the sample size is correct for the TPMS and append the UID of the sensor (hex) and the temperature and pressure data that was recorded by the head unit that normally sits on the dashboard of the RV to the file name. I'll see what the rtl_433 -f 433.88M -S unknown -s 1024k option produces. and update my repository.

[Gliebig]

OK, I think I've got the recordings figured out. ended up manually setting gain to 27. Looking at the spectrograph there are nice rounded "sine" waves with no squared edges. used rtl_433 -f 433.88M -S unknown 1024K -g 27. I've updated my repository with with the data values and file names trying to simplify things a bit. Still used two different sensors, freezer, and heat gun. g108... and g121 data may be a little off. Removing the sensor put it into an alarm mode. Without a timestamp on the data file I was guessing at the pressure and temperature values as the sensor sends a signal about once per second when there is a fast pressure loss like what happens when removing the sensor from the valve stem.

[zuckschwerdt]

Oh, those files look perfect! E.g. rtl_433 -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=50,l=50,r=120,invert' g071_433.88M_1024k.cu8 gives: {80}ffff 81 0d177e 99 46 0000

Now get all those codes, annotate and paste into a BitBench like this.

Then we need to stare at the numbers until it makes sense :)

[Gliebig]

OK, you lost me. This makes sense and I have read all of the data and parsed in into a spreadsheet.

Test mode active. Reading samples from file: g071_433.88M_1024k.cu8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.041087s
model     : name         count     : 1             num_rows  : 1             rows      :
len       : 232          data      : ffffffffffffffffffffffffffffffffffffffda4644894d32a70c8920
codes     : {232}ffffffffffffffffffffffffffffffffffffffda4644894d32a70c8920
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.075282s
model     : name         count     : 1             num_rows  : 1             rows      :
len       : 80           data      : ffff810d177e99460000
codes     : {80}ffff810d177e99460000
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.093727s
model     : name         count     : 1             num_rows  : 1             rows      :
len       : 80           data      : ffff810d177e99460000
codes     : {80}ffff810d177e99460000
sdr@sdr-alpha:~/Documents/cu8/230217$

But where did these values come from in your bit bench example?

7E F2 E8 81 66 B9

This is what I have so far:

{80}ffff fc 0d177e 00 4a 1000   [g121: 0d177e 0 PSI 75 F]
{80}ffff 85 0d177e 89 4a 1000   [g108: 0d177e 49 PSI 75 F]
{80}ffff 88 0d177e 8c 4a 1000   [g093: 0d177e 50 PSI 75 F]
{80}ffff 8b 0d177e 8f 4a 1000   [g080: 0d177e 51 PSI 75 F]
{80}ffff fd 0d177e 90 2b 2000   [g206: 0d177e 52 PSI 19 F]
{80}ffff ec 0d177e 90 3a 0000   [g207: 0d177e 52 PSI 46 F]
{80}ffff 87 0d177e 97 1e 3000   [g205: 0d177e 54 PSI -4 F]
{80}ffff 81 0d177e 99 46 0000   [g071: 0d177e 55 PSI 68 F]
{80}ffff 87 0d177e 99 4c 0000   [g079: 0d177e 55 PSI 78 F]
{80}ffff 8f 0d177e 99 54 0000   [g078: 0d177e 55 PSI 93 F]
{80}ffff 9c 0d177e 9a 60 0000   [g077: 0d177e 55 PSI 114 F]
{80}ffff ce 54e328 9b 24 3000   [g203: 54e328 56 PSI 6 F]
{80}ffff b7 54e328 9c 3c 0000   [g204: 54e328 56 PSI 50 F]
{80}ffff bf 54e328 a3 2d 1000   [g193: 54e328 59 PSI 23 F]
{80}ffff b0 54e328 a3 2e 0000   [g197: 54e328 59 PSI 24 F]
{80}ffff b4 54e328 a3 32 0000   [g198: 54e328 59 PSI 32 F]
{80}ffff c1 54e328 a3 3f 0000   [g199: 54e328 59 PSI 55 F]
{80}ffff c6 54e328 a4 43 0000   [g201: 54e328 59 PSI 62 F]
{80}ffff d4 54e328 a4 51 0000   [g202: 54e328 59 PSI 87 F]
{80}ffff e1 54e328 a4 5e 0000   [g200: 54e328 59 PSI 111 F]
{80}ffff e2 54e328 b3 20 3000   [g165: 54e328 64 PSI 0 F]

[ProfBoc75]

Hi,

My BitBench findings

So, we have after the small FFFF preamble :

CHECKSUM:8h ID:24h PSI:8h TEMP:8h FLAG:8h 8h

Checksum = Sum off all bytes from ID to FLAG & 0xFF PSI = the round up (Hexa Value / 2.8) Temp = the Hexa Value - 50 --> in Celcius. Flag = Could be some kind of alarm or Battery indicator ? Based on the samples, could battery level : 0 = good and 3 = bad , with the low temps it was = 2 or 3 as batteries dislike the low temps could explained these results, did you have the "sensor battery low" light on ?

[zuckschwerdt]

But where did these values come from in your bit bench example?

I copied from the non-inverted output of pdv, sorry, same thing, your table is perfect.

@ProfBoc75 you really found the fields fast and precise! For pressure I'd guess it's really × 2.5 kPa -- same result and a "round" factor.

I've added the checksum in this BitBench your findings mostly match but there is something not perfect with the upper nibble -- something missing?

[Gliebig]

The display unit that sits on the dashboard is where the units are set from the data received from the sensors. There might be a flag for a fast pressure loss alarm. g079 and g121 are two data points when the alarm was active when I was taking off 0d177e off the tire. The signal changes from being sent once every 5 minutes to an alarm mode that sends data about once per second. I have more data points between g108 ad g121 but I can't be precise on what the pressure and temperature data are since things were happening too fast to be able to record the values without a timestamp displayed on screen when the file was being written to disk. The temperature didn't change all that fast but the pressures did. I can get that data into a table if that would help.

[ProfBoc75]

@Gliebig : Thanks for the feedback, it's good information, I was also looking into its documentation

@zuckschwerdt : this could answer to your question about the upper nibble, here the battery level ( 0 = good) , and the low nibble the pressure deflation alarm indicator. On the console I notice also a battery gauge (3 lines barregraphe) and "sensor battery low" light, this means that battery information is coded with a least 2 bits, where the expected 3.2 V with a brand new battery and 2.8 V for a low battery (page 18 into the doc). So logically, we could have 4 levels , 0 = good/full , with 3 bars in the gauge , 1 = 2 bars, 2 = 1 bar, 3 = 0 bar + "Sensor battery low" light on. To be tested with a variable dc or a low battery, since this is my pure imagination 😄 . Compare to TPMS_JANSITE, this one is very close, not the data sent in the same order and not same modulation, but provides same kind of data.

[Gliebig]

I did not include originally this but here is the data that was recorded when removing sensor 0d177e from the valve stem. I started by creating a "leak" by slightly unscrewing the sensor from the valve stem and watched the file names and recorded the pressure as it dropped. The problem is the display unit cycles through all 6 tires until the alarm goes off. Then it only displays the tire under alarm and records very quickly. I can't guarantee the pressure is on the correct file name. It's a quick series of info that might prove helpful. And the documentation manual is the same as I have.

{80}ffff 8b 0d177e 8f 4a 1000   [g080: 0d177e 51? PSI 75 F]
{80}ffff 8b 0d177e 8f 4a 1000   [g081: 0d177e 51? PSI 75 F]
{80}ffff 8a 0d177e 8e 4a 1000   [g082: 0d177e 51? PSI 75 F]
{80}ffff 8a 0d177e 8e 4a 1000   [g083: 0d177e 51? PSI 75 F]
{80}ffff 8a 0d177e 8e 4a 1000   [g084: 0d177e 51? PSI 75 F]
{80}ffff 8a 0d177e 8e 4a 1000   [g085: 0d177e 51? PSI 75 F]
{80}ffff 89 0d177e 8d 4a 1000   [g086: 0d177e 51? PSI 75 F]
{80}ffff 89 0d177e 8d 4a 1000   [g087: 0d177e 51? PSI 75 F]
{80}ffff 89 0d177e 8d 4a 1000   [g088: 0d177e 51? PSI 75 F]
{80}ffff 89 0d177e 8d 4a 1000   [g089: 0d177e 51? PSI 75 F]
{80}ffff 89 0d177e 8d 4a 1000   [g090: 0d177e 51? PSI 75 F]
{80}ffff 88 0d177e 8c 4a 1000   [g091: 0d177e 51? PSI 75 F]
{80}ffff 88 0d177e 8c 4a 1000   [g092: 0d177e 51? PSI 75 F]
{80}ffff 88 0d177e 8c 4a 1000   [g093: 0d177e 50? PSI 75 F]
{80}ffff 88 0d177e 8c 4a 1000   [g094: 0d177e 50? PSI 75 F]
{80}ffff 88 0d177e 8c 4a 1000   [g095: 0d177e 50? PSI 75 F]
{80}ffff 88 0d177e 8c 4a 1000   [g096: 0d177e 50? PSI 75 F]
{80}ffff 87 0d177e 8b 4a 1000   [g097: 0d177e 50? PSI 75 F]
{80}ffff 87 0d177e 8b 4a 1000   [g098: 0d177e 50? PSI 75 F]
{80}ffff 87 0d177e 8b 4a 1000   [g099: 0d177e 50? PSI 75 F]
{80}ffff 87 0d177e 8b 4a 1000   [g100: 0d177e 50? PSI 75 F]
{80}ffff 86 0d177e 8a 4a 1000   [g101: 0d177e 50? PSI 75 F]
{80}ffff 86 0d177e 8a 4a 1000   [g102: 0d177e 50? PSI 75 F]
{80}ffff 86 0d177e 8a 4a 1000   [g103: 0d177e 50? PSI 75 F]
{80}ffff 86 0d177e 8a 4a 1000   [g104: 0d177e 50? PSI 75 F]
{80}ffff 86 0d177e 8a 4a 1000   [g105: 0d177e 50? PSI 75 F]
{80}ffff 86 0d177e 8a 4a 1000   [g106: 0d177e 50? PSI 75 F]
{80}ffff 85 0d177e 89 4a 1000   [g107: 0d177e 50? PSI 75 F]
{80}ffff 85 0d177e 89 4a 1000   [g108: 0d177e 49? PSI 75 F]
{80}ffff 85 0d177e 89 4a 1000   [g109: 0d177e 49? PSI 75 F]
{80}ffff 85 0d177e 89 4a 1000   [g110: 0d177e 49? PSI 75 F]
{80}ffff 85 0d177e 89 4a 1000   [g111: 0d177e 49? PSI 75 F]
{80}ffff 85 0d177e 89 4a 1000   [g112: 0d177e 49? PSI 75 F]
{80}ffff f4 0d177e 88 4a 0000   [g113: 0d177e 49? PSI 75 F]
{80}ffff fc 0d177e 00 4a 1000   [g114: 0d177e 0? PSI 75 F]
{80}ffff fc 0d177e 00 4a 1000   [g115: 0d177e 0? PSI 75 F]
{80}ffff fc 0d177e 00 4a 1000   [g116: 0d177e 0? PSI 75 F]
{80}ffff fc 0d177e 00 4a 1000   [g117: 0d177e 0? PSI 75 F]
{80}ffff fc 0d177e 00 4a 1000   [g118: 0d177e 0? PSI 75 F]
{80}ffff fc 0d177e 00 4a 1000   [g119: 0d177e 0? PSI 75 F]
{80}ffff fc 0d177e 00 4a 1000   [g120: 0d177e 0? PSI 75 F]

[ProfBoc75]

Thx, so low bit =1 = Deflate alarme, from this extract, the last g114 to g120 pressure should be 0. 88 or 89 = 49 PSI for sure. Well, anyway , it's not enough to be sure how to decode the flag ... since from other extract we have also 2 or 3 at this position, and we know that the battery is also part of the data since you have the indicator on the central console.

[Gliebig]

The main console has a battery indicator in the lower right of the screen that is the battery indicator of the display. It runs on 12v plugged into the RV which charges the internal battery. The display was on the internal batteries for all my testing and did not look for a battery indicator for each sensor. I could do some testing next week using a power supply hooked to the sensor and do some recordings varying the voltage holding pressure and temperature consistent. Are there preferred voltages to try?

Would it be possible to include a time stamp on the screen when recording -S unknown? The file name, sample size are very important but a time stamp would also be very helpful!

[ProfBoc75]

Ok, the gauge is for the internal battery of the console. And only the "Sensor battery low" will flash. page 17 (Sensor Low Battery alert).

[ProfBoc75]

Oh, those files look perfect! E.g. rtl_433 -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=50,l=50,r=120,invert' g071_433.88M_1024k.cu8 gives: {80}ffff 81 0d177e 99 46 0000

I tried the cu8 files, but I don't have the same result as you or @Gliebig , I'm using the last version of rtl_433 ,202302162313. lot of single line and [sdr_callback] Sample buffer length not aligned to sample size! messages, Under Debian, in Windows WSL, last upd update/upgrade, all pre-req install to make rtl_433, no error at the build...

 [Input] Test mode active. Reading samples from file: g071_433.88M_1024k.cu8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.016974s
model     : test         count     : 1             num_rows  : 1             rows      :
len       : 1            data      : 8
codes     : {1}8
[... and so on]

Did you put other option in the command line ? my command :

rtl_433 -X "n=test,m=OOK_MC_ZEROBIT,s=50,l=50,r=120,invert" g071_433.88M_1024k.cu8

[merbanan]

Add -s 1024k.

[ProfBoc75]

same result with -s 1024k

[zuckschwerdt]

Something must be different/broken on your setup? It works for at least @Gliebig and me. Just rtl_433 -X "n=test,m=OOK_MC_ZEROBIT,s=50,l=50,r=120,invert" g071_433.88M_1024k.cu8

[ProfBoc75]

@zuckschwerdt : thanks for the confirmation, I will check where is the issue, thx.

I'm annoyed because I wrote the device driver "tpms_eezrv" but I can't test it.. 😢

[zuckschwerdt]

For a quick test you can also use e.g. -y ffff860d177e8a4a1000 edit: but the code needs to be inverted or the inversion in the decoder removed ;)

[ProfBoc75]

it works with that option : (without invert)

rtl_433 -X "n=test,m=OOK_MC_ZEROBIT,s=50,l=50,r=120" g071_433.88M_1024k.cu8 -y ffff860d177e8a4a1000

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.000000s
model     : test         count     : 1             num_rows  : 1             rows      :
len       : 80           data      : ffff860d177e8a4a1000
codes     : {80}ffff860d177e8a4a1000

[ProfBoc75]

@Gliebig : I just put a PR with my draft device driver, into your rtl_433_test

Going to diner , to be continued later ...

[zuckschwerdt]

it works with that option : (without invert)

Use only rtl_433 -R 0 -X "n=test,m=OOK_MC_ZEROBIT,s=50,l=50,r=120" -y ffff860d177e8a4a1000

The file is not read. Do not use -y and a file together.

[Gliebig]

I'm using rtl_433 version 21.12 (2021-12-14) inputs file rtl_tcp RTL-SDR SoapySDR on an Xubuntu system installed on a Wyse 3040 thin client. Small, Fanless, and 5 volts. I'm planning to install this in my RV for collecting all the SDR data for my home assistant server that is on a PI4. I'm using the command line provided by @zuckschwerdt for getting the test results. I could easily modify a sensor for use with a power supply to collect data for the low battery test since the wheel does not need to rotate. Let me know.

[ProfBoc75]

I could easily modify a sensor for use with a power supply to collect data for the low battery test since the wheel does not need to rotate. Let me know.

If this does not require to much efforts , yes please then we will be sure about the battery bits position to decode the value accordingly. Thanks.

[ProfBoc75]

Some time I'm stupid .... my rtl_433 is working like a charm , just if I download properly the cu8 file, it works better, the source of my mistake is because I download the files with wget with the git url page and not the raw link of the files ...

Edit : This is why my signal was so durty, it was just html code and not the raw signal. The situation is that the extract to sr file for Pulseview did not show errors, ( rtl_433 -W test1.sr gxxxxx.cu8) and same the spectrographe web site accepted this html file as cu8 without error , at the end there is no control that could alert me I made a mistake...

[Gliebig]

Some time I'm stupid .... my rtl_433 is working like a charm , just if I download properly the cu8 file, it works better, the source of my mistake is because I download the files with wget with the git url page and not the raw link of the files ...

Don't worry about it! This has all been a bunch of firsts for me. First pull request, first fork, first time building a unix machine, first time making rtl_433 and using it for recordings. First time doing a merge and only the second time collaborating on a GitHub project and nervous as heck about not making a mistake and I'm an old guy.

[Gliebig]

I understand the 2nd and 3rd packets (duplicated 2nd) contain the data needed for what we're trying to accomplish. I don't understand what the 1st packet it for but to establish some sort of communication with the main display.

[ProfBoc75]

I understand the 2nd and 3rd packets (duplicated 2nd) contain the data needed for what we're trying to accomplish. I don't understand what the 1st packet it for but to establish some sort of communication with the main display.

@Gliebig : you're right, the first packet sounds different from 2 others, where usually the 1st and the other packets are repeats, the reason why I did not deep dive until now. The preamble is very long, this is normal to let this small device start and stabilise the signal frequency before sending the data. I'll let you know my findings about this 1st packet, if any ...

[Gliebig]

I will run the voltage tests tomorrow. I designed and built a power supply adapter for a CR1632 coin cell battery today. I added pictures to the README. I'll post the results when I get them done.

[zuckschwerdt]

Very nice build! This should be a template for all further TPMS hacking :)

[Gliebig]

Updated my repository with the new test data. Let me know what files (if any) you would like me to include under test data as you suggest to keep uploaded recordings to a minimum. The coin cell adapter worked great! Also, there is no indication on the display console that there is a low battery. There is a single beep after about 15 minutes without receiving any data from the sensor. However if this data was available it would be something I would add to poll in mqtt for my home assistant monitor.

[ProfBoc75]

Good job ! Unfortunatly from your samples, I did not see battery information from the 2sd/3rd packets need to check the 1st packet may be here. I'll check that later. And what I identified as flags could be lower nibble for the temp.

[Gliebig]

I did upload the recorded signals from the voltage tests. The file names are in the table of values if thats helpful.

[ProfBoc75]

@Gliebig : Hi, I was not able to find relationship between your voltage tests and the data. The device driver is now merged into the last version of rtl_433, did you test it ?

[gdt]

Looks like git master has acquired improved code. Please restest with that and post a summary of where we are. Otherwise I'll assume this is solved.

[flyboy013]

Trying to get EezTire-E618 to read all my EezTire 515 tire sensors (same as E618?). I have a total of 12 (coach + car). Only about half of the sensor are being decoded. I’m currently using “rtl_433 -s 1024k”. I’ve also tried with various combinations of “-f 433.88M” and “-g 27”, but no change in processed signals. In addition to receiving half of my sensors, I’m receiving another 10 or so from nearby RVs .

I’m using “NooElec R820T2 SDR & DVB-T NESDR Mini 2” receiver. I’m using the receiver on a RPi CM4. I’ve also installed rtl_433 on my MacBook and I’m getting same results. Also relocated MacBook receiver outside of RV thinking location of receiver may have been issue, but I’m getting same result. The EezTire 515 receiver is receiving signal from all tire sensors.

Maybe related (or not), I’ve noticed that I always get “PLL not locked!”. Below is sample rtl_433 output.

mark@Marks-MacBook-Pro /tmp % /usr/local/bin/rtl_433 -s 1024k -vv -R 241
rtl_433 version nightly-1-g72c0f21b branch master at 202309292256 inputs file rtl_tcp RTL-SDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/Users/mark/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registering protocol [241] "EezTire E618 (TPMS10ATC)"
[Protocols] Registered 1 out of 246 device decoding protocols
[Input] The internals of input handling changed, read about and report problems on PR #1978
[SDR] Found 1 device(s)
[SDR] trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Found Rafael Micro R820T tuner
[SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
[R82XX] PLL not locked!
[SDR] Sample rate set to 1024000 S/s.
[Input] Bit detection level set to 0.0 (Auto).
[SDR] Tuner gain set to Auto.
[Input] Reading samples in async mode...
[SDR] Tuned to 433.920MHz.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-09-30 12:54:32
model     : EezTire-E618 type      : TPMS          id        : c1833c
Pressure  : 540 kPa      Temperature: 20.0 C       Flags     : 0             Integrity : CHECKSUM
[pulse_slicer_manchester_zerobit] EezTire E618 (TPMS10ATC)
codes     : {80}ffff9ec1833cd8460000
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-09-30 12:54:32
model     : EezTire-E618 type      : TPMS          id        : c1833c
Pressure  : 540 kPa      Temperature: 20.0 C       Flags     : 0             Integrity : CHECKSUM
[pulse_slicer_manchester_zerobit] EezTire E618 (TPMS10ATC)
codes     : {80}ffff9ec1833cd8460000

Any suggestions on what other options to try. Also willing to dig deeper and contribute to decoder development although I’m am new to rtl_sdr and rtl_433. Thanks!

UPDATE: It appears that the three missing sensors on the coach (wife took car) are reported by the decoder as "Checksum fail". See below for output. Given that these sensors have never been decoded, I'm guess that maybe the checksum calculation may be the problem. Will research further.

[tpms_eezrv_decode] Preamble not found 
[tpms_eezrv_decode] Checksum fail
[pulse_slicer_manchester_zerobit] EezTire E618 (TPMS10ATC)
codes     : {162}ffffffffffffffffffffffffffffffffffffffffc
[tpms_eezrv_decode] Checksum fail
[pulse_slicer_manchester_zerobit] EezTire E618 (TPMS10ATC)
codes     : {161}ffffb73b8e75314700810000b73b8e75314700810
[tpms_eezrv_decode] Preamble not found

597d2a
[tpms_eezrv_decode] Preamble not found
[tpms_eezrv_decode] Preamble not found 
[tpms_eezrv_decode] Checksum fail
[pulse_slicer_manchester_zerobit] EezTire E618 (TPMS10ATC)
codes     : {162}ffffffffffffffffffffffffffffffffffffffffc
[tpms_eezrv_decode] Checksum fail
[pulse_slicer_manchester_zerobit] EezTire E618 (TPMS10ATC)
codes     : {161}ffff81597d2a334d0001000081597d2a334d00010
[tpms_eezrv_decode] Preamble not found
[tpms_eezrv_decode] Preamble not found

93432a
[tpms_eezrv_decode] Preamble not found
[tpms_eezrv_decode] Preamble not found 
[tpms_eezrv_decode] Checksum fail
[pulse_slicer_manchester_zerobit] EezTire E618 (TPMS10ATC)
codes     : {162}ffffffffffffffffffffffffffffffffffffffffc
[tpms_eezrv_decode] Checksum fail
[pulse_slicer_manchester_zerobit] EezTire E618 (TPMS10ATC)
codes     : {80}ffffb693432aec4a0000
[tpms_eezrv_decode] Checksum fail
[pulse_slicer_manchester_zerobit] EezTire E618 (TPMS10ATC)
codes     : {80}ffffb693432aec4a0000
[tpms_eezrv_decode] Preamble not found

[gdt]

Great progress! Also, I suggest getting a better dongle, metal case, TCXO. They are amazingly better. Even if it is a checksum issue. Also graph your frequencies and make sure they are in-band. Also please post if you are using up-to-date git master.

I am thinking the original issue is solved, as you are decoding 5/8 and thinking there is a bug with your variant. If so, maybe we should close this and have you open up a "persistent checksum failures on some EEZ Tire E515 sensors" issue which is finer-grained. Would appreciate your opinion on whether the original issue is fixed, and if there is information there that should be captured in the source code before we close.

[flyboy013]

I'm good with closing this issue and opening another if that is preferred. I believe the checksum calculation needs updating. The checksum is the sum of 6 bytes (id, pressure, temperature, and flags). In my case the, sum is greater than 0xFF. It seems that when the computed checksum is 0x1-- (ie greater than 0xFF), that the checksum is the sum of the 6 bytes & 0xFF plus 1. The one gets added to the computed checksum. When the computed checksum is 0x2--, the computed checksum needs to be or'ed with 0x80. This based on the one sample that I have so far. The car is back, so I need to capture the other 4 sensors and see if this logic holds true.

BTW - I am using the latest version of the software. Built it today from nightly build. rtl_433 version nightly-1-g72c0f21b branch master at 202309292256 inputs file rtl_tcp RTL-SDR with TLS

[gdt]

It's clear that EEZ Tire is mostly working, so I'm closing this as done. Please do open an issue about the checksum, and then eventually a PR when you know how to fix it.