Having some issues with Toyota

[Crsarmv7l]

I would appreciate any technical help:

I have been attempting to generate a Toyota TPMS signal for a while off and on with varied success utilizing a Yardstick one and the rtl_433 source as a guide, specifically here https://github.com/merbanan/rtl_433/blob/master/src/devices/tpms_toyota.c

I am able to recreate and get rtl_433 to recognize a transmission crafted using this file as a basis https://github.com/merbanan/rtl_433_tests/blob/master/tests/Toyota_TPMS/02/0d5aee3_g007_433.92M_250k.cu8

I believe my CRC8 is correct as well, as I am able to modify parts of the data packet and it is still recognized in rtl_433 (see below)

However, I did not find this in the src to be entirely accurate:

In the process of elimination I found this to work on some but not all ID's note the added "0" and the "11" at the end (instead of 3 bits)

But even this does not make sense to me as analysis in URH yields the following:
DMC Decoded: 100001111100001101010110101110111000111101001010100010100000000101101010001000
with 100001 as the preamble decoded and I don't see any trailing bits in the signal.

and yet there are various ID's that I cannot generate a valid signal for:
f01b2881 to name one.

I am looking for any help you can possibly give me because this is driving me up a wall. What am I missing?

[Crsarmv7l]

Just to cover all bases, here is how I am doing the CRC calc (incase I screwed something up)

[zuckschwerdt]

The match 01010101001111 with data then 00110011 [...64 manchester bits] 00101010111 might only work if the data (id) starts with a 10 (but not 11) code. (Note that the alignment in the text seems off, the first DMC bit is here: 0101010100111 >1 0< 0110011 [...64 manchester bits] 00101010111).
So for a 01 or 00 start we might have 01010101001110 00… or maybe not.

But being DMC you have a choice of polarity at the beginning, and I suspect that due to the 1111 sync you must not start with a 11 symbol. Maybe try flipping the whole generated code.

[Crsarmv7l]

Gave inverting the DMC piece a quick try:

The bitstring for f01b2881 with my normal way is:
01010101001111001100110101010101010100110100110101001011010101001010101010101100110100101011010010110101010010110101010101010101001011001011010010101101010101011
Which I can see doesn't end up with the trailing "111" at the end. Here are the results with DMC inverted:

Yields this:
01010101001111010011001010101010101011001011001010110100101010110101010101010011001011010100101101001010101101001010101010101010110100110100101101010010101010111
Which looks better and now has the 3 trailing "111".

For ref f0d5aee3 as recognized by rtl_433 looks like this:

and yields this:
01010101001111001100110101010100110100101101001101001011001101001100101010110011001011010100101101001010101101001010101010101010110100110100101101010100101010111

Just to see what happens, I also ran f0d5aee3 with the DMC piece inverted:
01010101001111010011001010101011001011010010110010110100110010110011010101001100110100101011010010110101010010110101010101010101001011001011010010101011010101011

Which like my issues with f01b2881, ends with only "11" instead of "111" when recognized and decoded correctly.
I wont have a chance to see if the inverted DMC bitstring when txed is recognized till later, but it does look more promising

[Crsarmv7l]

Hmm inverted f01b2881 is really close but not quite there. If you look at the end, it should be
00101010111
but instead it is
0010101010111 (extra 01)

Haven't yet tested against rtl_433, but this is discouraging

[Crsarmv7l]

Nope no luck on rtl_433.

Guhhhhhh guess I will go through all the test repo files and see if I can figure out what the deal is

[Crsarmv7l]

Thinking now that it is an issue with how I truncate my crc8. There is nothing else it could be, since that is at the end and would effect the DMC "00101010111" ending sequence and would throw off lengths potentially.

[zuckschwerdt]

Note that 11 is only valid DMC if a 00 or 10 preceeds it. Since it is seen as 111 it is always invalid -- a desync. It may be that the last state is just repeated 2 more times (…1 -> …111 and maybe …0 -> …000) or that always at least three 1's are needed to force desync.

[Crsarmv7l]

Thanks, no real reason to do this other than I thought I knew how it worked, and now it is bugging me 🤣 . f01b2881 was decoded by rtl so I know it is possible

[Crsarmv7l]

GUH I am an idiot.

When doing the crc I was padding to the right (if needed). For f0d5aee3 that happened to work out since the CRC was 8bits. For f01b2881 it wasn't and didnt 🥴 .

All id's I tried worked against rtl_433 with the following (no idea if it works on real hardware):

fin = "010101010011110" + differential_manchester_encode(payload + crc_bits) + "11"
then converting fin to bytes.

Pad CRC on the left if needed

[zuckschwerdt]

Oh, sorry, I was convinced the CRC would be correct. When working in Python I use bitstring to manipulate rows of bits.

[Crsarmv7l]

My CRC calc was correct so no way you could have known.

For f0d5aee3 the crc8 was something like 10010000 (no matter changes to the data) so I didn't pad it. f01b2881 the CRC8 was something like 1011, if I remember correctly, so it needed padding which caused the issues. Thats what happens when I make stupid mistakes like padding on the right.

I'm using bitstring for the bytes conversion, but I'll have to look into it for other uses, thanks