Post by Hoovie on Feb 8, 2018 11:59:25 GMT
by shcm
Thu Dec 01, 2016 3:22 pm
Follow up from main forum thread here:
forum.rav4driversclub.com/topic4949-70.html#p73423
OK, so this is at least applicable to Pacific Industrial Co. TPMS Sensors, part no. PMV-C210 (Toyota part number 42607-02031) as used on my 2016 RAV4 hybrid.
There’s a very good chance this sensor (or at least the data format employed) is used on other Toyotas and possibly other, earlier RAVs, but I’m not claiming any backwards compatibility with earlier 4.4s or even T180s or SR180s. Mainly because I’ve never investigated a sensor off any of these vehicles. Send me a sensor, or bring the vehicle to me and I’ll check!
So, going off at a tangent, I have a set of winter wheels and tyres for the hybrid RAV and a set of TPMS sensors that need mounting onto the rims. The TPMS ECU on the hybrid is supposed to deal with 2 sets of sensors (and therefore 2 sets of wheels), with an easy switch over procedure, between the two sets, involving just the TPMS reset switch. I’ve not yet interrogated the ECU with diagnostic kit to confirm the two set capability, but I’m not expecting any surprises. I wanted to go down this route with the winter wheels and keep the TPMS functionality, rather than “snipping” wires, to put out an annoying warning lamp (which has been discussed ad-nauseum previously). In the meantime, the winter wheel, TPMS sensors, are sitting on my desk for a while……..
Now, from my point of view, it would be nice to read the tyre pressures from the sensors. It would at the very least save me a few minutes every week checking pressures (although I still look @ tyre treads). This is despite some early owner's manuals for 4.4, claiming the pressures could be displayed on the sat nav screen. That capability I don’t think ever came to fruition?
As we know, the Toyota system just puts a warning light up, if low pressure is detected. I can fully appreciate why that approach may have been taken. For a start, presenting some members of Joe Public with numbers, can, as a dealer or VM, generate you more trouble than it’s worth and a system with just a warning lamp is more “automatic”. i.e. you don’t need to be troubled until there’s a problem. Temperature compensation probably also needs to be applied to the readout, otherwise you’d get people complaining of pressure readout variation. The system also has to take into account wheel temperature changes due to braking and the like. When you get into it, it’s a more complex problem, than face value. Anyway, I’m not going to get into how good or bad the system may be. That’s boring. The Toyota system is what it is.
Anyway, back on course & now for the “meat”. Warning! Some of this may (OK, it will!) get a bit (OK, maybe it’s a lot - I really can’t tell these days) technical. If that statement has made you want to go & change your underwear, well I promise I’ll try to be gentle. Or you might want to skip to the end, which may tell you what you want to know. Proper electronic design Engineers (i.e. not the “powerpoint monkey” type) with “nouse” should have no problem with what follows.
I’m a geek. I want to know the pressures from the sensors. Maybe a display would be nice. Either a dedicated one or perhaps even onto a smart phone or an in-car screen of some type, but that’s way ahead of myself.
I’m also a lazy geek. Or maybe I should say, I like to be “efficient”. I really don’t want to be building some hardware and a bit of software, wasting time for a lost cause. For all I knew, the transmission from the sensors was encrypted and then the effort required probably would have out weighed any benefit. Most likely, it would have been for no benefit. Fortunately, there’s a compromise, where a quick “look see” can be done.
It’s well know that the frequency these TPMS sensor things transmit on, is centred around 433.92MHz in Europe (and around 315 MHz in places like the USA and others). So a 434MHz receiver is required. But what type? AM or FM based? What are the transmission parameters? Bandwidth? Data rate? Well, we can find out cheaply, with an hour or two of work.
A few years ago, some very clever people worked out that these things (PC USB TV/DAB/FM sticks)
which can be had on Ebay for a few quid (devices with rtl2832u and e4000 chips are usually recommended) can also actually be tuned over a very wide range of radio frequency spectrum. It easily includes 433.92MHz (and 315MHz). They are by no means the best radio receiver in the world, but good enough for this exercise.
Some other very clever people, have also developed stuff termed “Software Defined Radio” (SDR). Without going into the depths of the fairly complex world of data sampling theory and digital signal processing, the upshot is, that using one of the above USB sticks and some “SDR”, a portion of radio spectrum can be examined and/or radio receivers made in software, on a PC (or even a tablet or smart phone).
One such free “SDR” package is a thing called “gnuradio” and “gnuradio-companion”. Gnuradio-companion allows you to string basic building blocks together, fairly easily and quickly, in a graphical form, to construct a radio system on your PC. See below.
At this point, to build anything, you’re probably going to need a fair bit of electronics and/or radio knowledge. It doesn’t stop you running other SDR/gnuradio systems, that have previously been made by others, though.
Armed with a USB stick, gnuradio and the TPMS sensors for the winter wheels sitting on my desk, I set to work. I made the above system in gnuradio-companion, tweaking it as I found more things out about the transmission. Most of the above blocks in the system are either just ones setting up and allowing adjustment of various parameters or providing extra graphical outputs, to aid me with the analysis. The actual “guts” of the receiver are relatively simple.
For those that understand these things, I believe, (using some techniques I won’t go into here), the the TPMS transmission is FSK (Frequency Shift Keying), with a frequency deviation of about 30kHz.
OK, after a while I got the 8ms long waveform that I’ve been “teasing” you with on the forum. It’s a load of highs and lows or 1s and 0s (or bits, or binary), so it’s almost certainly a data transmission of some form.
Great! What the heck does it all mean though?….beats me! :s_wink
Alright, let’s take it one “bit” at a time. :s_wink
Stare at the waveform for a bit (sorry, I mean stare at the waveform for a while). What’s there that looks unique or constant, between transmissions? Some of you commented about the 10kHz (or 100us period) content of the signal. Near the beginning of the transmission there is a “step” (or high period) that is twice as long as any other pulse there and it never appears ever again in the transmission. That stands a chance of being significant.
These kind of short burst data transmissions, from TPMS and similar, tend also to have what’s called a “preamble”. It’s a load of stuff (or signal) at the beginning of the transmission, which carries no useful data, but is often a pattern that allows the receiver to set stuff up (like automatic gain (amplification) control, for example) before the real data starts.
Alright, before that long pulse near the start, are some other pulses. Maybe it’s a preamble. It’s a bit short as preambles go, but they probably want as short a transmission as possible to prolong battery life. Maybe everything after that long pulse is real data.
Let’s assume it is and also just jump on a little way, over some stuff. For various radio reasons, the data is actually encoded in what’s called Biphase Mark Coding. (BMC) (google is your friend).
For those that can understand these things – For BMC, a new bit period always starts with an “edge” (step in the signal, be it a rising or falling one) regardless. If say a particular bit period represents a “1”, then, within that bit period, there will be another edge. For the other bit state (in this example a “0”) there will be no edge within the bit period. So, for this example, using the TPMS timing, if you had a sequence of only data “0”s you’d have say a area where the demodulated signal was a square wave of 10kHz, for while. For a sequence of “1”s it would be double the frequency, because of the additional “edge” during the bit period. This encoding helps to recover the data. If the recovered bit timing should vary a little, it allows easy “resynchronisation”. Believe me, it does!
We can now get to the bit level and extract the data! Phew! Oh, we still don’t know which state in the BMC represents a 1 and which represents a 0. There’s no real convention I’m aware of. It turns out, for the TPMS sensor, it’s opposite to my above example. i.e. a constant level, with no additional edge, within a bit period, represents a “1”.
Anyway, finally (really?) we can now extract a sequence of ones and zeros from the signal. The data is something like this (obviously it can be different for different transmissions):
111100011001000111001100101101011000111100011111000000001110000111100010
72bits @ 100us (10kHz) per bit period is 7.2ms, plus the preamble is about 8ms. Sounds about right!
Well, I can’t read long strings of binary digits. I have to split ‘em up into chucks of 8 bits (or bytes)
11110001 10010001 11001100 10110101 10001111 00011111 00000000 11100001 11100010
Well, not being modest, I’ve been doing this stuff so long, I can do binary representation of bytes in my sleep, but actually I also like hexadecimal. Some of you will know, 4 bits can be written as 1 hexadecimal digit. So, 2 hex digits to a byte. So, the first 4 bytes of the above, i.e.
11110001 10010001 11001100 10110101
become
F1 91 CC B5.
At this point, you should look @ a photo of my TPMS sensor……………..
……..nice isn’t it?
…….don’t you think?….
……...Hang on! How spooky! 7 of those hex digits above, appear on my TPMS sensor, as its ID. I’m beginning to think Derren Brown has a hand in this, or if not, I’m auditioning for Britain’s Got Talent. :s_wink
Conveniently, ignoring the first 4 bits (The F), we’ve now decoded 4 out of the 9 bytes transmitted, without too much effort and we seem to be on the right lines.
Now, we have to do things to the sensor & see what bits change from transmission to transmission.
Some bits around the middle of the transmission seem to be changing with temperature and the final 8 bits on the right hand end, all seem to change, if only 1 of all the other remaining bits change. Checksums (a thing which allows you great confidence the rest of the data has not been corrupted) show that kind of behaviour. Maybe the last 8 bits are a checksum byte.
The other bits, which change with sensor temperature, look a bit weird, when considered as bytes. Let’s rearrange all the bits slightly So:
11110001 10010001 11001100 10110101 10001111 00011111 00000000 11100001 11100010
becomes
11110001 10010001 11001100 10110101 1 00011110 00111110 0000000 11100001 11100010
by just shuffling and regrouping to the left by one bit, from the position of the fourth byte and beyond.
The “1” grouped on it’s own never seems to change, but the second byte following it, now changes nicely in binary with temperature change (The sensor has been heated and also put in the freezer). I think we found the temperature data. I believe this is the sensor temperature to the nearest degree centigrade, plus 40. Not unreasonable. 0 for the value of this byte, would represent -40C, which is usually the minimum operating temp spec for a vehicle.
After going and receiving the sensor data off the TPMS sensors on my vehicle, I believe the first byte after the single “1” is the pressure data multiplied 4 plus an offset of about 29 (decimal), in PSI. I was kind of expecting it to be a kPa representation, but saying that, I’ve yet to confirm the scaling that I think is used, is actually correct. I need to deflate or part deflate a tyre, which I haven’t done yet. The offset seems a reasonable value, if I compare it with other pressure sensor datasheets. Maximum value transmittable would be about 56.5 PSI, which again, seems not unreasonable.
The 7 zeros now grouped together, in the above bit stream, never seem to change and may actually be fixed. They may also be “status” flags (or bits) that are yet to be determined. There may be a deflation alarm or low battery status bit, but that’s speculation. Again, I need to deflate a tyre and see if anything changes. Update - In fact rapid deflation seems to set bit 2 (read from RHS and first bit is bit 0). Also on deflation, the sensor transmits about 30 times, very rapidly.
The last byte of the 72 bits, as speculated, is in fact a checksum or CRC (cyclic redundancy check). After collecting a few transmissions and applying a bit of magic, I now know the CRC algorithm (or polynomial involved) and can use it to check data integrity. i.e. I can calculate and match the checksum value transmitted, from only the other 8 bytes. This is the way checksums work. Seems to fit.
That leaves the last but one byte. At first I thought it was TPMS battery voltage, as the values from the vehicle sensors and “winter tyre” sensors on my desk, all showed similar values. However, when I applied a bit of pressure to one of the sensors on my desk, the value of this byte changed dramatically. I then spotted that it was in fact, always the same value as the pressure byte, only with all the bits inverted. i.e. compare the byte after the single “1” on its own above:
00011110 with the last but one byte:
11100001
I’m not sure why they have done this. Sending the pressure data twice in the transmission doesn’t really give any more data integrity over the checksum. The checksum is superior. The one thing I can think of, which is pure speculation, is that the sensor is backwards compatible with previous systems, which didn’t have the checksum and that, with later systems, the checksum has just been tagged on the end of the transmission, for better data integrity checking. In fact, with a few bits, rather than just sending the data again, error correction can be added to a transmission, which allows some errors in transmission to be detected and corrected - up to a point.
At this time (well, actually, way before this point), I wrote a small bit of software to display the TPMS transmissions in a more readable form (There are 4 sensors IDs on the screen, as there are 4 sensors on my desk):
Each TPMS sensor transmits every 90 seconds or so. It seems to vary randomly from about 92 to 97-ish seconds. That’s probably part deliberate, so that sensor transmissions don’t continually take place together, interfere with one another and prevent reception.
The time between transmission may decrease once moving, but I don’t know, because I haven’t tried received any data in a moving vehicle yet. Possibly there may be acceleration data to see too, in the areas where there appears to be unused bits.
So in summary, there is, I believe (subject to change):
If I get chance, I may now build some dedicated receiver hardware and software to send the data to a display of some kind. Knowing which sensor (and therefore sensor ID) is on which wheel, will give the capability of displaying the pressure in each tyre.
What else could you do with this info?
Well, you could use it to “spoof” your existing TPMS sensors, when they are not on the car, by transmitting the data in the right format. It’s a rather more complex solution, to snipping a wire, but the system would look completely correct. i.e. the TPMS warning light, should, I expect, come on then go off at ignition. With a wire snip, it won’t. It might fool an MOT inspector, although the TPMS valves are usually obvious from the valve stems, if they are fitted or not.
You could read sensor IDs to enter into the TPMS ECU, without dismounting a tyre, if they were not already known. (I’ve not interrogated my TPMS ECU yet, but I’m confident I know the TPMS valve IDs it is programmed with, by receiving the TPMS valve transmitted data, directly).
On the negative side, you might, in the right, probably tricky, but not impossible circumstances, be able to turn somebody’s TPMS light on remotely, (by spoofing their sensor transmission) but it’s hardly as serious as say hacking their bank account!
In this day and age, the transmission possibly should be encrypted. I’m not surprised it isn’t, but I expect it will come. “cyber security” is appearing to become increasingly important in the industry. VMs are getting jittery, but if you stop and think, it’s actually a huge can of worms. Part replacement and warranty return diagnostics on ECUs becomes a nightmare. That’s for another day though.
In the meantime we have an open system, to our advantage.
Third party aftermarket sensors, that mimic Toyota sensor transmissions, are available, so clearly the transmission format has already been looked at by others. Frankly, it’s not that tricky for a Design Engineer with the right skills to suss this out. Therefore, I’m surprised some sort of aftermarket pressure display box, using the OEM sensors as the data source, is not already available. Maybe it is. I haven’t looked.
Update 05/01/17 - T180 Sensors
RavAsher (http://forum.rav4driversclub.com/member83.html) sent me two sensors, diagnosed as faulty, from off his T180. These are Pacific sensors - PMV-1019, so a different part to those used on my 4.4.
It turns out these two sensors were still transmitting:
The data format is different to the 4.4 sensors.
These are the details:
This is what I think the bits represent (all subject to change):
Both the pressure sensors had different zero "offsets" for the pressure value. One of 90 and the other of 211. As both of these sensors were deemed "faulty" and replaced, it's not easy to determine if either of these offsets is correct for the sensor. A confirmed, correctly operating sensor, would be required to determine that. Whatever the offset, I believe that the value should be divided by 4, after the offset has been subtracted, to get the pressure value in PSI.
So, compared with the newer 4.4 sensors we can speculate that (for 4.4):
Thu Dec 01, 2016 3:22 pm
Follow up from main forum thread here:
forum.rav4driversclub.com/topic4949-70.html#p73423
OK, so this is at least applicable to Pacific Industrial Co. TPMS Sensors, part no. PMV-C210 (Toyota part number 42607-02031) as used on my 2016 RAV4 hybrid.
There’s a very good chance this sensor (or at least the data format employed) is used on other Toyotas and possibly other, earlier RAVs, but I’m not claiming any backwards compatibility with earlier 4.4s or even T180s or SR180s. Mainly because I’ve never investigated a sensor off any of these vehicles. Send me a sensor, or bring the vehicle to me and I’ll check!
So, going off at a tangent, I have a set of winter wheels and tyres for the hybrid RAV and a set of TPMS sensors that need mounting onto the rims. The TPMS ECU on the hybrid is supposed to deal with 2 sets of sensors (and therefore 2 sets of wheels), with an easy switch over procedure, between the two sets, involving just the TPMS reset switch. I’ve not yet interrogated the ECU with diagnostic kit to confirm the two set capability, but I’m not expecting any surprises. I wanted to go down this route with the winter wheels and keep the TPMS functionality, rather than “snipping” wires, to put out an annoying warning lamp (which has been discussed ad-nauseum previously). In the meantime, the winter wheel, TPMS sensors, are sitting on my desk for a while……..
Now, from my point of view, it would be nice to read the tyre pressures from the sensors. It would at the very least save me a few minutes every week checking pressures (although I still look @ tyre treads). This is despite some early owner's manuals for 4.4, claiming the pressures could be displayed on the sat nav screen. That capability I don’t think ever came to fruition?
As we know, the Toyota system just puts a warning light up, if low pressure is detected. I can fully appreciate why that approach may have been taken. For a start, presenting some members of Joe Public with numbers, can, as a dealer or VM, generate you more trouble than it’s worth and a system with just a warning lamp is more “automatic”. i.e. you don’t need to be troubled until there’s a problem. Temperature compensation probably also needs to be applied to the readout, otherwise you’d get people complaining of pressure readout variation. The system also has to take into account wheel temperature changes due to braking and the like. When you get into it, it’s a more complex problem, than face value. Anyway, I’m not going to get into how good or bad the system may be. That’s boring. The Toyota system is what it is.
Anyway, back on course & now for the “meat”. Warning! Some of this may (OK, it will!) get a bit (OK, maybe it’s a lot - I really can’t tell these days) technical. If that statement has made you want to go & change your underwear, well I promise I’ll try to be gentle. Or you might want to skip to the end, which may tell you what you want to know. Proper electronic design Engineers (i.e. not the “powerpoint monkey” type) with “nouse” should have no problem with what follows.
I’m a geek. I want to know the pressures from the sensors. Maybe a display would be nice. Either a dedicated one or perhaps even onto a smart phone or an in-car screen of some type, but that’s way ahead of myself.
I’m also a lazy geek. Or maybe I should say, I like to be “efficient”. I really don’t want to be building some hardware and a bit of software, wasting time for a lost cause. For all I knew, the transmission from the sensors was encrypted and then the effort required probably would have out weighed any benefit. Most likely, it would have been for no benefit. Fortunately, there’s a compromise, where a quick “look see” can be done.
It’s well know that the frequency these TPMS sensor things transmit on, is centred around 433.92MHz in Europe (and around 315 MHz in places like the USA and others). So a 434MHz receiver is required. But what type? AM or FM based? What are the transmission parameters? Bandwidth? Data rate? Well, we can find out cheaply, with an hour or two of work.
A few years ago, some very clever people worked out that these things (PC USB TV/DAB/FM sticks)
which can be had on Ebay for a few quid (devices with rtl2832u and e4000 chips are usually recommended) can also actually be tuned over a very wide range of radio frequency spectrum. It easily includes 433.92MHz (and 315MHz). They are by no means the best radio receiver in the world, but good enough for this exercise.
Some other very clever people, have also developed stuff termed “Software Defined Radio” (SDR). Without going into the depths of the fairly complex world of data sampling theory and digital signal processing, the upshot is, that using one of the above USB sticks and some “SDR”, a portion of radio spectrum can be examined and/or radio receivers made in software, on a PC (or even a tablet or smart phone).
One such free “SDR” package is a thing called “gnuradio” and “gnuradio-companion”. Gnuradio-companion allows you to string basic building blocks together, fairly easily and quickly, in a graphical form, to construct a radio system on your PC. See below.
At this point, to build anything, you’re probably going to need a fair bit of electronics and/or radio knowledge. It doesn’t stop you running other SDR/gnuradio systems, that have previously been made by others, though.
Armed with a USB stick, gnuradio and the TPMS sensors for the winter wheels sitting on my desk, I set to work. I made the above system in gnuradio-companion, tweaking it as I found more things out about the transmission. Most of the above blocks in the system are either just ones setting up and allowing adjustment of various parameters or providing extra graphical outputs, to aid me with the analysis. The actual “guts” of the receiver are relatively simple.
For those that understand these things, I believe, (using some techniques I won’t go into here), the the TPMS transmission is FSK (Frequency Shift Keying), with a frequency deviation of about 30kHz.
OK, after a while I got the 8ms long waveform that I’ve been “teasing” you with on the forum. It’s a load of highs and lows or 1s and 0s (or bits, or binary), so it’s almost certainly a data transmission of some form.
Great! What the heck does it all mean though?….beats me! :s_wink
Alright, let’s take it one “bit” at a time. :s_wink
Stare at the waveform for a bit (sorry, I mean stare at the waveform for a while). What’s there that looks unique or constant, between transmissions? Some of you commented about the 10kHz (or 100us period) content of the signal. Near the beginning of the transmission there is a “step” (or high period) that is twice as long as any other pulse there and it never appears ever again in the transmission. That stands a chance of being significant.
These kind of short burst data transmissions, from TPMS and similar, tend also to have what’s called a “preamble”. It’s a load of stuff (or signal) at the beginning of the transmission, which carries no useful data, but is often a pattern that allows the receiver to set stuff up (like automatic gain (amplification) control, for example) before the real data starts.
Alright, before that long pulse near the start, are some other pulses. Maybe it’s a preamble. It’s a bit short as preambles go, but they probably want as short a transmission as possible to prolong battery life. Maybe everything after that long pulse is real data.
Let’s assume it is and also just jump on a little way, over some stuff. For various radio reasons, the data is actually encoded in what’s called Biphase Mark Coding. (BMC) (google is your friend).
For those that can understand these things – For BMC, a new bit period always starts with an “edge” (step in the signal, be it a rising or falling one) regardless. If say a particular bit period represents a “1”, then, within that bit period, there will be another edge. For the other bit state (in this example a “0”) there will be no edge within the bit period. So, for this example, using the TPMS timing, if you had a sequence of only data “0”s you’d have say a area where the demodulated signal was a square wave of 10kHz, for while. For a sequence of “1”s it would be double the frequency, because of the additional “edge” during the bit period. This encoding helps to recover the data. If the recovered bit timing should vary a little, it allows easy “resynchronisation”. Believe me, it does!
We can now get to the bit level and extract the data! Phew! Oh, we still don’t know which state in the BMC represents a 1 and which represents a 0. There’s no real convention I’m aware of. It turns out, for the TPMS sensor, it’s opposite to my above example. i.e. a constant level, with no additional edge, within a bit period, represents a “1”.
Anyway, finally (really?) we can now extract a sequence of ones and zeros from the signal. The data is something like this (obviously it can be different for different transmissions):
111100011001000111001100101101011000111100011111000000001110000111100010
72bits @ 100us (10kHz) per bit period is 7.2ms, plus the preamble is about 8ms. Sounds about right!
Well, I can’t read long strings of binary digits. I have to split ‘em up into chucks of 8 bits (or bytes)
11110001 10010001 11001100 10110101 10001111 00011111 00000000 11100001 11100010
Well, not being modest, I’ve been doing this stuff so long, I can do binary representation of bytes in my sleep, but actually I also like hexadecimal. Some of you will know, 4 bits can be written as 1 hexadecimal digit. So, 2 hex digits to a byte. So, the first 4 bytes of the above, i.e.
11110001 10010001 11001100 10110101
become
F1 91 CC B5.
At this point, you should look @ a photo of my TPMS sensor……………..
……..nice isn’t it?
…….don’t you think?….
……...Hang on! How spooky! 7 of those hex digits above, appear on my TPMS sensor, as its ID. I’m beginning to think Derren Brown has a hand in this, or if not, I’m auditioning for Britain’s Got Talent. :s_wink
Conveniently, ignoring the first 4 bits (The F), we’ve now decoded 4 out of the 9 bytes transmitted, without too much effort and we seem to be on the right lines.
Now, we have to do things to the sensor & see what bits change from transmission to transmission.
Some bits around the middle of the transmission seem to be changing with temperature and the final 8 bits on the right hand end, all seem to change, if only 1 of all the other remaining bits change. Checksums (a thing which allows you great confidence the rest of the data has not been corrupted) show that kind of behaviour. Maybe the last 8 bits are a checksum byte.
The other bits, which change with sensor temperature, look a bit weird, when considered as bytes. Let’s rearrange all the bits slightly So:
11110001 10010001 11001100 10110101 10001111 00011111 00000000 11100001 11100010
becomes
11110001 10010001 11001100 10110101 1 00011110 00111110 0000000 11100001 11100010
by just shuffling and regrouping to the left by one bit, from the position of the fourth byte and beyond.
The “1” grouped on it’s own never seems to change, but the second byte following it, now changes nicely in binary with temperature change (The sensor has been heated and also put in the freezer). I think we found the temperature data. I believe this is the sensor temperature to the nearest degree centigrade, plus 40. Not unreasonable. 0 for the value of this byte, would represent -40C, which is usually the minimum operating temp spec for a vehicle.
After going and receiving the sensor data off the TPMS sensors on my vehicle, I believe the first byte after the single “1” is the pressure data multiplied 4 plus an offset of about 29 (decimal), in PSI. I was kind of expecting it to be a kPa representation, but saying that, I’ve yet to confirm the scaling that I think is used, is actually correct. I need to deflate or part deflate a tyre, which I haven’t done yet. The offset seems a reasonable value, if I compare it with other pressure sensor datasheets. Maximum value transmittable would be about 56.5 PSI, which again, seems not unreasonable.
The 7 zeros now grouped together, in the above bit stream, never seem to change and may actually be fixed. They may also be “status” flags (or bits) that are yet to be determined. There may be a deflation alarm or low battery status bit, but that’s speculation. Again, I need to deflate a tyre and see if anything changes. Update - In fact rapid deflation seems to set bit 2 (read from RHS and first bit is bit 0). Also on deflation, the sensor transmits about 30 times, very rapidly.
The last byte of the 72 bits, as speculated, is in fact a checksum or CRC (cyclic redundancy check). After collecting a few transmissions and applying a bit of magic, I now know the CRC algorithm (or polynomial involved) and can use it to check data integrity. i.e. I can calculate and match the checksum value transmitted, from only the other 8 bytes. This is the way checksums work. Seems to fit.
That leaves the last but one byte. At first I thought it was TPMS battery voltage, as the values from the vehicle sensors and “winter tyre” sensors on my desk, all showed similar values. However, when I applied a bit of pressure to one of the sensors on my desk, the value of this byte changed dramatically. I then spotted that it was in fact, always the same value as the pressure byte, only with all the bits inverted. i.e. compare the byte after the single “1” on its own above:
00011110 with the last but one byte:
11100001
I’m not sure why they have done this. Sending the pressure data twice in the transmission doesn’t really give any more data integrity over the checksum. The checksum is superior. The one thing I can think of, which is pure speculation, is that the sensor is backwards compatible with previous systems, which didn’t have the checksum and that, with later systems, the checksum has just been tagged on the end of the transmission, for better data integrity checking. In fact, with a few bits, rather than just sending the data again, error correction can be added to a transmission, which allows some errors in transmission to be detected and corrected - up to a point.
At this time (well, actually, way before this point), I wrote a small bit of software to display the TPMS transmissions in a more readable form (There are 4 sensors IDs on the screen, as there are 4 sensors on my desk):
Each TPMS sensor transmits every 90 seconds or so. It seems to vary randomly from about 92 to 97-ish seconds. That’s probably part deliberate, so that sensor transmissions don’t continually take place together, interfere with one another and prevent reception.
The time between transmission may decrease once moving, but I don’t know, because I haven’t tried received any data in a moving vehicle yet. Possibly there may be acceleration data to see too, in the areas where there appears to be unused bits.
So in summary, there is, I believe (subject to change):
- Pacific Industries PMV-C210 (Toyota part number 42607-02031)
- 434MHz FSK transmission. 10KHz bit rate, 30 kHz deviation. Biphase Mark Coding.
- 8ms approx transmission time, 72 data bits. Repeat approx 90s, while stationary. Moving as yet unknown. 30 rapid transmissions on deflation.
- 4 Sensor ID bytes (4 top bits presently unused? – set to F).
- 1 single bit always “1” (Or a status bit?)
- Pressure Data Byte = 4*Pressure in PSI + 29 (decimal) offset (To be confirmed)
- Temperature Data Bye = Temperature in C + 40
- 7 bits always “0” (or status bits TBD). Bit 2 (i.e. value 4) seems to get set on low pressure/deflation.
- Pressure Data Byte, with bits inverted
- Checksum byte (CRC8)
If I get chance, I may now build some dedicated receiver hardware and software to send the data to a display of some kind. Knowing which sensor (and therefore sensor ID) is on which wheel, will give the capability of displaying the pressure in each tyre.
What else could you do with this info?
Well, you could use it to “spoof” your existing TPMS sensors, when they are not on the car, by transmitting the data in the right format. It’s a rather more complex solution, to snipping a wire, but the system would look completely correct. i.e. the TPMS warning light, should, I expect, come on then go off at ignition. With a wire snip, it won’t. It might fool an MOT inspector, although the TPMS valves are usually obvious from the valve stems, if they are fitted or not.
You could read sensor IDs to enter into the TPMS ECU, without dismounting a tyre, if they were not already known. (I’ve not interrogated my TPMS ECU yet, but I’m confident I know the TPMS valve IDs it is programmed with, by receiving the TPMS valve transmitted data, directly).
On the negative side, you might, in the right, probably tricky, but not impossible circumstances, be able to turn somebody’s TPMS light on remotely, (by spoofing their sensor transmission) but it’s hardly as serious as say hacking their bank account!
In this day and age, the transmission possibly should be encrypted. I’m not surprised it isn’t, but I expect it will come. “cyber security” is appearing to become increasingly important in the industry. VMs are getting jittery, but if you stop and think, it’s actually a huge can of worms. Part replacement and warranty return diagnostics on ECUs becomes a nightmare. That’s for another day though.
In the meantime we have an open system, to our advantage.
Third party aftermarket sensors, that mimic Toyota sensor transmissions, are available, so clearly the transmission format has already been looked at by others. Frankly, it’s not that tricky for a Design Engineer with the right skills to suss this out. Therefore, I’m surprised some sort of aftermarket pressure display box, using the OEM sensors as the data source, is not already available. Maybe it is. I haven’t looked.
Update 05/01/17 - T180 Sensors
RavAsher (http://forum.rav4driversclub.com/member83.html) sent me two sensors, diagnosed as faulty, from off his T180. These are Pacific sensors - PMV-1019, so a different part to those used on my 4.4.
It turns out these two sensors were still transmitting:
The data format is different to the 4.4 sensors.
These are the details:
- The bit rate is half that of the 4.4 sensors @ 5kbps.
- The transmission time is 14ms long and in normal mode, re-occurs every 60s, compared with 90s for the 4.4 sensors.
- A total of 70 bit "times" are transmitted (including "pre-amble").
- The preamble consists of at least 3 "high" bit times, followed by 1 low bit time. The "real" data then follows.
This is what I think the bits represent (all subject to change):
- Bits 0 to 27 Are the sensor ID.
- Bit 28 Unknown. Was constantly "0" during my investigation
- Bit 29 to 30 Appear to be a 2 bit transmission "counter". They constantly cycle around between 0 and 3, from transmission to transmission
- Bit 31 Unknown
- Bit 32 Seems to get set with rapid pressure loss
- Bit 33 to 34 Unknown
- Bit 35 to 42 Pressure (see below)
- Bit 43 to 50 Pressure value with bits inverted
- Bit 51 to 60 This I believe is temperature (divide by 16 & subtract 40 to get degrees C??).
- Bit 61 to 62 The appears to be another transmission counter, but its direction appears to be affected by bits 63 and 64. I don't think these
bits are just more LSBs for the temperature value. - Bit 63 to 64, see above.
- Bit 65 Appears to be a parity bit.
Both the pressure sensors had different zero "offsets" for the pressure value. One of 90 and the other of 211. As both of these sensors were deemed "faulty" and replaced, it's not easy to determine if either of these offsets is correct for the sensor. A confirmed, correctly operating sensor, would be required to determine that. Whatever the offset, I believe that the value should be divided by 4, after the offset has been subtracted, to get the pressure value in PSI.
So, compared with the newer 4.4 sensors we can speculate that (for 4.4):
- Bit rate has been increased to shorten transmission time and improve sensor battery life.
- Time between transmissions has been increased, to improve sensor battery life.
- A CRC has been added to 4.4 system, to improve received data integrity.