Open gcormier opened 5 years ago
@zuckschwerdt Over my head a bit.
Is this output string the raw string, or the manchester decoded value?
rtl_433 -r g025_315M_250k.cu8 -X "name=test,modulation=FSK_PCM,s=120,l=120,r=300,preamble=aaaf"
time : @0.341740s
model : test count : 1 num_rows : 1 rows :
len : 76 data : 4d4b34ad2b2d4ad54ac
codes : {76}4d4b34ad2b2d4ad54ac
Before I go to town on BitBench, I want to know I'm using the right value. I'm hoping to check every other TPMS format to see if it matches any of those.
Sorry, no this isn't manchester decoded. You would need to apply that by hand. I'll add a few example scripts and maybe a button for BitBench soon.
There currently is no MC decode for FSK as you would need to align the data at a suitable preamble. The trick for subsequent manchester is to make sure all groups of two bits after the preamble are either 01
or 10
. Also the resulting hex code could be shifted 1-3 bits if the preamble to cut off was choosen to short or long.
Sorry again, I'll try to make MC utils available asap.
Sounds good, thanks!
I guess using the tx_tools generator with a suspected preamble would be a nice way to graphically visualize the preamble to make sure it ends at the right spot.
On Thu, Mar 28, 2019 at 3:06 AM Christian W. Zuckschwerdt < notifications@github.com> wrote:
Sorry, no this isn't manchester decoded. You would need to apply that by hand. I'll add a few example scripts and maybe a button for BitBench soon. There currently is no MC decode for FSK as you would need to align the data at a suitable preamble. The trick for subsequent manchester is to make sure all groups of two bits after the preamble are either 01 or 10. Also the resulting hex code could be shifted 1-3 bits if the preamble to cut off was choosen to short or long. Sorry again, I'll try to make MC utils available asap.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/1024#issuecomment-477475029, or mute the thread https://github.com/notifications/unsubscribe-auth/AIABdwD8VFR5pAlG4OAMn9M9EUiUXpBdks5vbGoPgaJpZM4cLxk- .
I tried playing around with this data a bit. After removing a sync/prefix and Differential Manchester decoding the data, I took a stab at trying to identify the fields. I wasn't able to come up with much, but maybe this is progress?
There seems to be a parity bit in there somewhere, and I'd guess it's the final bit. There's a few other flags that may mean something, and there seems to be an 8-bit value that may be related to pressure, but maybe not? Also, I'll assume these samples all come from the same device since bits that probably relate to a TPMS_ID don't change at all.
I would expect 3-4 bytes of ID, 1-2 bytes pressure, 1 byte temp, and 1 byte checksum. Haven't really seen shorter codes. I'll take a closer look this evening.
I did some quick googling to see if there was any Leaf tool that would spit out the TPMS ID's. There's an Android app (Leaf Spy), but even the Pro version doesn't report the ID's.
@gcormier Would it be possible to get samples from other tires, and have a manual tire pressure reading associated with each sample?
@gcormier Just a crude first test, but BitBench now has Preamble/Sync options and Manchester decode also.
Yes, I will try to get readings for PSI as well as something from the other 3 wheels. They don't belong to me, so I'll see when I can get over to my friends to read them :)
This BitBench has the data with Preamble alignment and DMC coding. The didn't check/update the format string tough.
Also note in this BitBench that shifting off the first bit (or using a preamble of 555e
. We can use MC without error. So it's likely MC and not DMC.
Some of my research notes (I think would support the MC theory)
Claims to be OEM : https://www.ebay.com/p/Nissan-407003AN1B-Genuine-OEM-TPMS-Sensor/1437046258?iid=132576949062
https://industrycanada.co/7812D-S180015B https://fccid.io/KR5S180052015B
Remark: *7 WUP definition: - Modulation ASK for the WUP
- 12 blocks in the WUP
- 2 bytes à "00" Manchester, 3 bytes NRZ in each blocks WUP length = 10.0993536ms MAX
Hmm, it's not ASK we're seeing but FSK... so perhaps a red-herring to be ignored.
Also, I have a note that there is some unfinished work done on a sensor by the same company, whether that helps or not : https://github.com/merbanan/rtl_433_tests/compare/master...FizzyWhiz:master for the KR5S180052056.
Interesting though - the picture with the FCC ID clearly has FSK written.
Perhaps I am misinterpreting that Remark *7. Maybe it is not specific to this device.
Agreed that MC looks better than DMC for this. I was able to parse out 8 bits that may relate to pressure, and using the same decoding for a PSI value that the Toyota TPMS sensor uses ((PSI+7)*4), I'm getting sane values.
Here's another stab at decoding: BitBench
Nice! I am heading over to my buddies tomorrow evening to get some captures from the other 3 wheels! I'll make a note of the PSI as well and ambient temp.
To get robust sync the preamble should be shorter so some starting bits a re allowed to be missing, 16 bit seems enough 555e
.
Got the data. Might take a day or two to update the tests and PR, but here's one string from each tire. I have the PSI's all written down too, i just have to crossreference.
7aaaaaaaf4d4b34ad2b2d4ad54ca0
7aaaaaaaf4d52aab2d2b54ad4b34
7aaaaaaaf4cd4acccaab54ad4b4c
7aaaaaaaf4cd34ab2ccb54acd4d4
Tire 2 at 24psi
7aaaaaaaf4d52aab2d2b54ad34b4
Tire 3 at 22psi
7aaaaaaaf4cd4acccaab54ad2b520
Tire 4 at 20psi
7aaaaaaaf4cd34ab2ccb54acd4d4
Also, unfortunately I forgot my IR thermometer. The thermostat in the basement said 18.5 Celsius. Tire 4 was on the bottom, so a change it is slightly colder, and tire 2 was on top, so warmest.
@gcormier Great, thanks! I revised the BitBench a bit to include these new data points and reset the preamble value to what @zuckschwerdt suggested. The TPMS_ID might be only 5 bytes long since the 6th byte doesn't seem to vary at all between all 4 tires. Also, changing the formula for the pressure value to be interpreted as ((PSI+3)*4) seems to line up well with the manual readings you took.
Nice work!
It is odd, the picture shows more values for the sensor ID.. but I don't see where they would be unless they are all matching (what would be the odds?!) in the 4 tires I found.
I'd guess each sensor is only advertising one ID. Since the photo you provided is from a random ebay listing and not the exact sensor you're scanning, it's difficult to tell which ID printed on the sensor is being advertised, and if I aligned the bits correctly to pick it up that way.
Unless you can view the sensor you're scanning (I'm guessing that's unlikely), maybe you can use some kind of OBDII device to have the car tell you what it thinks the IDs of the sensors are? I think that unless we can get some kind of confirmation of what the TPMS_ID of the device is supposed to be, we're just guessing at bits.
Also, I'm not seeing any indication that the sensor is advertising a temperature reading.
The Leaf app won't divulge the sensor ID unfortunately.
I concur on the temperature - I hit it with freezing spray and never noticed a difference.
One last idea is that perhaps there is another mode activated by regular driving that differs from the panic mode, and subsequent "frequent update" mode. Tail end of winter up here, but know that I know a bit of what we're looking for, I can go for a ride along when these wheels are back on the car to see what's getting spit out.
@gcormier while you were working on this, did you happen to stumble across any information related to Honda TPMS sensors?
No I didnt.
On Thu., Apr. 25, 2019, 9:24 p.m. Matt Panaro, notifications@github.com wrote:
@gcormier https://github.com/gcormier while you were working on this, did you happen to stumble across any information related to Honda TPMS sensors?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/1024#issuecomment-486892287, or mute the thread https://github.com/notifications/unsubscribe-auth/ACAAC5YE3YWZXFQEAHYOJS3PSJKWPANCNFSM4HBPDE7A .
I was able to ride around in a 2015 Nissan Leaf and record some data. I used what I found in this issue to write a decoder based off the Citroen decoder. After combing through the data looking for 4 distinct tires I think the data field may be 24 bits wide, b/c that gave me 4 distinct IDs and the time between each set of transmissions was ~65s.
I should put it under a feature branch, but right now I have changes for it sitting on master here: https://github.com/alwilson/rtl_433/commits/master
Before: MODE:2d TPMS_ID:20h UNKNOWN:5b (PSI+THREE)FOUR=8d UNKNOWN:2b After: MODE:3d TPMS_ID:24h (PSI+THREE)FOUR=8d UNKNOWN:2b
Timestamps would help, but here's the data on BitBench with the 24-bit ID encoding.
Although, now that I look at how many times I saw each TPMS_ID I only saw one tire 4 times and only near the end of the drive.
fde56a [32]:
@24.390045s psi: 30.2 mode: 101 unknown: 01
@24.600241s psi: 30.2 mode: 101 unknown: 01
@24.705465s psi: 30.2 mode: 101 unknown: 01
@86.369972s psi: 30.5 mode: 111 unknown: 10
@86.474937s psi: 30.5 mode: 111 unknown: 10
@86.580162s psi: 30.5 mode: 111 unknown: 10
@86.685417s psi: 30.5 mode: 111 unknown: 10
@148.351578s psi: 31.0 mode: 111 unknown: 11
@148.456558s psi: 31.0 mode: 111 unknown: 11
@210.336441s psi: 31.2 mode: 111 unknown: 10
@210.441452s psi: 31.2 mode: 111 unknown: 10
@210.546677s psi: 31.2 mode: 111 unknown: 10
@210.651947s psi: 31.2 mode: 111 unknown: 10
@272.373566s psi: 31.5 mode: 111 unknown: 01
@272.583801s psi: 31.5 mode: 111 unknown: 01
@272.689087s psi: 31.5 mode: 111 unknown: 01
@334.495361s psi: 31.5 mode: 111 unknown: 01
@334.600647s psi: 31.5 mode: 111 unknown: 01
@334.705933s psi: 31.5 mode: 111 unknown: 01
@396.437103s psi: 32.0 mode: 111 unknown: 10
@396.542114s psi: 32.0 mode: 111 unknown: 10
@396.647400s psi: 32.0 mode: 111 unknown: 10
@396.752716s psi: 32.0 mode: 111 unknown: 10
@458.468231s psi: 32.0 mode: 111 unknown: 10
@458.573242s psi: 32.0 mode: 111 unknown: 10
@458.678558s psi: 32.0 mode: 111 unknown: 10
@458.783783s psi: 32.0 mode: 111 unknown: 10
@520.528259s psi: 32.2 mode: 111 unknown: 01
@520.738586s psi: 32.2 mode: 111 unknown: 01
@520.843872s psi: 32.2 mode: 111 unknown: 01
@582.571106s psi: 32.5 mode: 111 unknown: 00
@582.886719s psi: 32.5 mode: 111 unknown: 00
caa485 [23]:
@51.623344s psi: 31.8 mode: 101 unknown: 10
@51.730434s psi: 31.8 mode: 101 unknown: 10
@115.003639s psi: 32.0 mode: 111 unknown: 10
@115.110748s psi: 32.0 mode: 111 unknown: 10
@178.216019s psi: 32.5 mode: 111 unknown: 00
@178.323303s psi: 32.5 mode: 111 unknown: 00
@178.430420s psi: 32.5 mode: 111 unknown: 00
@178.537506s psi: 32.5 mode: 111 unknown: 00
@305.192291s psi: 32.8 mode: 111 unknown: 11
@305.299438s psi: 32.8 mode: 111 unknown: 11
@305.406555s psi: 32.8 mode: 111 unknown: 11
@368.489136s psi: 33.0 mode: 111 unknown: 00
@368.596436s psi: 33.0 mode: 111 unknown: 00
@368.703583s psi: 33.0 mode: 111 unknown: 00
@368.810730s psi: 33.0 mode: 111 unknown: 00
@431.947235s psi: 33.0 mode: 111 unknown: 00
@432.054565s psi: 33.0 mode: 111 unknown: 00
@432.161743s psi: 33.0 mode: 111 unknown: 00
@432.268921s psi: 33.0 mode: 111 unknown: 00
@493.667511s psi: 33.2 mode: 111 unknown: 11
@493.877106s psi: 33.2 mode: 111 unknown: 11
@555.394287s psi: 33.5 mode: 111 unknown: 10
@555.499023s psi: 33.5 mode: 111 unknown: 10
caa486 [29]:
@55.846066s psi: 31.8 mode: 111 unknown: 11
@55.954273s psi: 31.8 mode: 111 unknown: 11
@56.062222s psi: 31.8 mode: 111 unknown: 11
@56.170197s psi: 31.8 mode: 111 unknown: 11
@152.677017s psi: 32.2 mode: 101 unknown: 10
@153.001160s psi: 32.2 mode: 101 unknown: 10
@217.035492s psi: 32.5 mode: 111 unknown: 11
@217.143692s psi: 32.5 mode: 111 unknown: 11
@217.251663s psi: 32.5 mode: 111 unknown: 11
@217.359619s psi: 32.5 mode: 111 unknown: 11
@281.408661s psi: 33.0 mode: 101 unknown: 01
@281.517059s psi: 33.0 mode: 101 unknown: 01
@281.625031s psi: 33.0 mode: 101 unknown: 01
@281.733002s psi: 33.0 mode: 101 unknown: 01
@345.817657s psi: 33.0 mode: 111 unknown: 11
@345.925873s psi: 33.0 mode: 111 unknown: 11
@346.033875s psi: 33.0 mode: 111 unknown: 11
@346.141846s psi: 33.0 mode: 111 unknown: 11
@410.257324s psi: 33.0 mode: 111 unknown: 11
@410.365540s psi: 33.0 mode: 111 unknown: 11
@410.473511s psi: 33.0 mode: 111 unknown: 11
@410.581512s psi: 33.0 mode: 111 unknown: 11
@474.678589s psi: 33.2 mode: 111 unknown: 10
@474.786804s psi: 33.2 mode: 111 unknown: 10
@474.894806s psi: 33.2 mode: 111 unknown: 10
@475.002838s psi: 33.2 mode: 111 unknown: 10
@539.238220s psi: 33.5 mode: 111 unknown: 01
@539.346191s psi: 33.5 mode: 111 unknown: 01
@539.454224s psi: 33.5 mode: 111 unknown: 01
caa487 [4]:
@351.041595s psi: 32.5 mode: 111 unknown: 10
@415.880249s psi: 32.8 mode: 111 unknown: 01
@416.209229s psi: 32.8 mode: 111 unknown: 01
@546.356567s psi: 33.2 mode: 111 unknown: 01
I was able to ride around in a 2015 Nissan Leaf and record some data. I used what I found in this issue to write a decoder based off the Citroen decoder. After combing through the data looking for 4 distinct tires I think the data field may be 24 bits wide, b/c that gave me 4 distinct IDs and the time between each set of transmissions was ~65s.
I should put it under a feature branch, but right now I have changes for it sitting on master here: https://github.com/alwilson/rtl_433/commits/master
Before: MODE:2d TPMS_ID:20h UNKNOWN:5b (PSI+THREE)FOUR=8d UNKNOWN:2b After: MODE:3d TPMS_ID:24h (PSI+THREE)FOUR=8d UNKNOWN:2b
Background: 10 months ago, I started to figure out my 2011 G37 TPMS sensors. I read the TPMS IDs from the BCM and that make figuring out the layout fairly easy. PLUS "chzu" helped me to get started, and pointed out a few key parts.
It was just last week I came across your tpms_nissan.c update and it worked great! The only change I made was to remove the "-3" psi correction, as the is elevation dependant and I want my TPMS display to match the RTL_433 values.
My Ask (Please!!) I have a G37 focused Youtube channel (MotorvateDIY) and have just finished shooting an episode on how to change your own TPMS sensors and program them. I used your update to show the sensor IDs. (compiled locally)
Since most car guys may not know how to compile code, is there nay chance you can make a windows standalone exe? With that, anyone can easily read the IDs and use them to program the BCM. (body control module)
I did try to create a windows standalone, and spent 2 days trying Visual Code and CMAKE, but it always gave me an error "this can't be executed" when on the other windows machine. (I work in the embedded field, so DLL are new to me)
Anyways, thanks for your work on this.
Here is my post from 10 months ago: https://www.reddit.com/r/RTLSDR/comments/wnvyzv/nissaninfiniti_tpms_sensor_decode_question/
I'll try to review and, if possible, merge a decoder tomorrow. We can then create the "nightly" pre-release for Windows.
I'll try to review and, if possible, merge a decoder tomorrow. We can then create the "nightly" pre-release for Windows.
Thank you, thank you!!
If possible, could you outline the steps you use to make a stand alone exe using CMAKE? I am new to CMAKE and want to continue to learn more about it. (My first time using it, was last week)
Anyways, thank you again for all the great work you have done with the RTL_433 program!
could you outline the steps you use to make a stand alone exe using CMAKE?
The steps are automated in https://github.com/merbanan/rtl_433/blob/master/.github/workflows/release.yml and the build script is https://github.com/merbanan/rtl_433/blob/master/do_sysroot.sh But really it should be as simple as installing the dependencies and then building like shown in https://github.com/merbanan/rtl_433/blob/master/docs/BUILDING.md#visual-studio-2017 I'm not sure if building librtlsdr is needed as Pothos should have those libs pre-built.
But really it should be as simple as installing the dependencies and then building like shown in https://github.com/merbanan/rtl_433/blob/master/docs/BUILDING.md#visual-studio-2017
Well.... this is weird. I just followed those instructions again, moved the needed DLLs to a different windows 10 machine and it worked!!! I have no idea what I was doing wrong the last two days!!
I'll look at it again to make sure I understand all this crazy desktop dev stuff.
Update: Looks like I used the Debug version and not the Release on the other PC. :)
Looks like support was merged in #2536. I'm calling this fixed; please comment and explain if I'm wrong.
@gdt #2536 is still open and unmerged though. I haven't touched this in a while, but I can fix up the conflict and update the PR. It sounds like it got some testing, but I'd have to get access to a Nissan Leaf again to test.
Sorry, misread. Yes, if you can get this to mergeable state -- and feel free to open a PR yourself and we can close the one done on your behalf -- that would be great. @zuckschwerdt this is about a PR you are a middleman for.
@alwilson I have access to leaf, how to test?
Updated and manually merged with d34e48d
Please try from current master with -R 248
(there is no MIC so it's default disabled).
Updated and manually merged with d34e48d Please try from current master with
-R 248
(there is no MIC so it's default disabled).
Alright, I've compiled and running it with ./rtl_433 -R 248.
Where are we on this? It seems there is some support in master. Anything else to do? Starting 30-day feedback timer to close, unless there's a reason to keep it open.
Test data https://github.com/merbanan/rtl_433_tests/pull/269
Figured I would bring the discussion here.
Second guessing myself here - did I waste an evening decoding the raw bitstream? Or will the -X output the DMC decoded values? I feel like it's the former... :(
BitBench
Decode string
-X "name=test,modulation=FSK_PCM,s=120,l=120,r=300"