Questions about decoded data

[djhopkins2]

I watched your talk on decoding the data that is received and I've looked through the code regarding some preset decoding profiles. Do you ID the protocol type based on the decoded preamble after you've identified the modulation scheme?

I started recording data from my car last night and it appears to be getting ~4 sets of packets with what appears to be an unchanging ID portion and a section with small changes. What you'd expect from a drive cycle. However, it appears that the data received is way too short to possibly contain the all of the parameters that should be there. It almost appears the the data is half of what would be expected, like the bit clock is off by a factor of 2? I am getting 8 hex chars of data each time

This data is from a set of 315Mhz tpms sensors on my 2008 Subaru outback. The IDs that you program into the ECU are supposed to be 6 Hex Chars which wouldn't leave any space for other data in packet I appear to be getting.

First of all, is there a good way to go about working with these tools to deconstruct the modulation and encoding scheme and make sure it makes sense? Would I just modify the profiles to include the new encoding scheme? Also, is there a better place than here to discuss this?

Once I get a grip on how to set it up properly, I could provide you with some of the output data or the burst files. I am also going to go to the tire shop at some point and have them read me the current IDs. One goal in playing with this is that I'd like to reverse-engineer the Can-Bus protocol for reading and setting tpms IDs at the ECU and to make that information available to DIY minded people.

record_subaru_11-25-15.txt

[jboone]

In the video, I used tools from a separate project at https://github.com/jboone/tpms. But that project is a pretty terrible cruft-ball of code.

I would recommend capturing baseband using your SDR (RTL-SDR?) and then using a tool like Inspectrum (https://github.com/Miek/inspectrum) to view the spectrum and observe modulation characteristics. Does it look like Morse code (ASK/OOK modulation) or is the frequency modulating back and forth between two frequencies (FSK)? If FSK, how far apart are the two frequencies, and how often do they change (symbol rate)?

Yes, you should be able to augment the table of modulation schemes to handle new combinations.

No, at present there is no better public place to discuss this stuff. You can e-mail me privately, but then nobody would benefit from our discussion. I would get a mailing list set up, but haven't taken the time to configure my mail server yet.

Have you looked for the FCC ID of your TPMS sensors? If your sensors are embedded in your wheels already, you can look on eBay for TPMS sensors that match the make/model of your vehicle, and often find photos clear enough to see the FCC ID. I think Subarus use Schrader, perhaps FCC ID MRXSMD3MA4. Look it up at http://fcc.io/MRXSMD3MA4. Packets are 74 symbols long, Manchester decoded to 37 bits. If the sensor ID is 6 hex digits long (24 bits), that leaves 13 bits, which is plenty to encode the sensor status and tire temperature. I don't think this device uses a checksum or CRC, but instead transmits several times and expects the receiver to take the best M out of N packets as the correct data.

[djhopkins2]

Thank you. I managed to get a longer log of data from a 15 minute drive and I believe that you are right on the encoding and length of my sensors. Also, when I looked at the data, it matches the encoding you found in that FCC filing. So, it looks like your script is correctly decoding the data from my sensors. What I'm waiting on at the moment, before I interpret the data, is an appointment at discount tire to pick up winter tires and to have them give me the IDs for the sensors I just recorded. With a quick analysis, It appears that the ID is at the beginning of the transmission because there are only 4 unique 24bit sequences in the log I recorded at the front of each packet. Once I can compare those to the actual IDs, I'll be certain of the alignment of that data in the packet. Also, I agree with it likely being best x of y packets. Each transmission is duplicated 4 times in quick succession.

[djhopkins2]

I'm also hoping to have a CAN analyzer connected when they program my ECU, so I can reverse engineer the programming process...

[shortwavedave]

Are the bits that print out already manchester decoded, or are the scripts simply letting us know what the encoding is? How do you decode error values in manchester decoding, ie when successive values are equal? Also, in your example above is the FCC id supposed to correspond to the sensor id and if so then do you think the letters in the id are encoded in 8-bit ascii?

[Entropy512]

@davethemave The FCC ID is a model ID that is used to represent a given circuit design when it goes for FCC approval. ALL sensors of a given model/design share the same FCC ID. The sensor ID (the six hex digits referenced by @djhopkins2 ) is a serial number - similar in concept to a MAC address. The sensor might have that ID also printed on it, although many sensors now are programmable.

@djhopkins2 Did you ever get a chance to obtain a CAN trace of the sensor readout? I unfortunately didn't pull it off - I couldn't be present when my wheels had the sensors changed out in early January, and I also don't have access to my Outback until March (traded vehicles with family to support a move). I do happen to have a whole pile of other CAN traces from the Outback with a number of fields identified beyond what's at https://subdiesel.wordpress.com/ecu-analysis/can-messages/ if you're interested.

[djhopkins2]

Andrew, I never ended up obtaining the messages used when programming TPMS IDs into the car because I ended up finding out that the Schrader sensors that tire shops sell now are reprogrammable and can have their IDs cloned. I really wished I had known that so that I could have my RTL SDR dongle recording when they did the programming. They cloned my IDs so that I didn't have to reprogram the ECU between summer and winter tire sets. I did end up doing some research on the wiring from the TPMS module to ascertain whether I could tap into the can lines at the OBD2 connector. I have a bus analyzer I've been meaning to connect up because I wanted to try and decode the messages from the TPMS unit to see what my tire pressures are and what's causing errors. I was going to see if it was a supported protocol for the elm327 Bluetooth dongles.

If you have more can IDs, I would be more than glad to look at them :-). Were you able to decipher ones regarding TPMS

On Wed, Feb 8, 2017, 6:41 PM Andrew Dodd notifications@github.com wrote:

@davethemave https://github.com/davethemave The FCC ID is a model ID that is used to represent a given circuit design when it goes for FCC approval. ALL sensors of a given model/design share the same FCC ID. The sensor ID (the six hex digits referenced by @djhopkins2 https://github.com/djhopkins2 ) is a serial number - similar in concept to a MAC address. The sensor might have that ID also printed on it, although many sensors now are programmable.

@djhopkins2 https://github.com/djhopkins2 Did you ever get a chance to obtain a CAN trace of the sensor readout? I unfortunately didn't pull it off - I couldn't be present when my wheels had the sensors changed out in early January, and I also don't have access to my Outback until March (traded vehicles with family to support a move). I do happen to have a whole pile of other CAN traces from the Outback with a number of fields identified beyond what's at https://subdiesel.wordpress.com/ecu-analysis/can-messages/ if you're interested.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/jboone/gr-tpms/issues/7#issuecomment-278499524, or mute the thread https://github.com/notifications/unsubscribe-auth/APR4QqnKOLH-rxv1kZSRgEdEEjKIf7M-ks5ralKUgaJpZM4Gpdfs .