Open-Chargeport icon indicating copy to clipboard operation
Open-Chargeport copied to clipboard

Does the PIC and Si4010 code generate exactly the same signal?

Open nicholas-gh opened this issue 5 years ago • 1 comments

I've determined that https://github.com/mstegen/Open-Chargeport/blob/4fdffded66910fe04250e5dc19f3d89ede9bd17c/Si4010/source/keyfob_demo_main.c#L391-L435 is the same data as https://teslamotorsclub.com/tmc/posts/2383825/ - after I spotted the note about LSB. The Si4010 code is 'ready to send', so manchester encoding, preamble, message-repeats markers are all already in it; and since the 'message-repeats' marker (100?) isn't a full byte I see how the repeated data actually doesn't look repeated in the Si4010 code.

The data at https://github.com/mstegen/Open-Chargeport/blob/4fdffded66910fe04250e5dc19f3d89ede9bd17c/sourcecode/OpenChargeport_10F200.asm#L193-L206 is almost the same; but the last few bytes of the repeated message seems to differ.

I think the PIC code generates either

010101100101100110010110011001100110011001011010011010010110101001010110100110100110010101011010 100101

or potentially (if I'm confused how (MC_TX3)[https://github.com/mstegen/Open-Chargeport/blob/4fdffded66910fe04250e5dc19f3d89ede9bd17c/sourcecode/OpenChargeport_10F200.asm#L83] works)

010101100101100110010110011001100110011001011010011010010110101001010110100110100110010101011010 100

and the Si4010 and 'rpitx' examples generate

0101011001011001100101100110011001100110010110100110100101101010010101101001101001100101010110100101 100

I assume all three of these examples work, and the Tesla port doesn't notice the small variation?

If it works (and I assume it must do since it's here), then the PIC code has the most concise representation of the Tesla button code I've come across so far.

nicholas-gh avatar Feb 13 '20 01:02 nicholas-gh

Here's my python playaround to try compare the three examples:

#!/usr/bin/python


# sources
# https://teslamotorsclub.com/tmc/posts/2383825/
# https://github.com/mstegen/Open-Chargeport/blob/master/Si4010/source/keyfob_demo_main.c

thenoone_preamble = "111111111111"
thenoone_data = "00010010100101010101001101100111000110110100001100"
thenoone_rec_split = "100" # not manchester?

Si4010 = [0x55, 0x55, 0x55, 0x51, 0xd3, 0x4c, 0x33, 0x33, 0xd3, 0xb2, 0xb4, 0x52, 0xcb, 0x32, 0xd5, 0xd2, 0xA8, 0x69, 0xa6, 0x99, 0x99, 0x69, 0x59, 0x5a, 0xa9, 0x65, 0x99, 0x6a, 0x69, 0xd4, 0x34, 0xd3, 0xcc, 0xcc, 0xb4, 0x2c, 0xad, 0xd4, 0xb2, 0x4c, 0xb5, 0x34]

pic_preamble = "10"*13 + "0" # 0 is an extra 400us delay after the preamble that's in the code, not in the data
pic = [0x12, 0x95, 0x53, 0x67, 0x1B, 0x43]
pic_3 = 0x20

def manchester(data):
    return "".join(["10" if bit == "1" else "01" for bit in data])
thenoone_symbols = thenoone_rec_split.join([manchester(thenoone_preamble)] + [manchester(thenoone_data)]*3)

print "noone ", [int(thenoone_symbols[b:b+8][::-1], 2) for b in range(0, len(thenoone_symbols), 8)]
print "Si4010", Si4010

pic_symbols = pic_preamble + ("".join([manchester(format(byte, '08b')) for byte in pic]) + manchester(format(pic_3, '03b')))*3
print "pic   ", [int(pic_symbols[b:b+8][::-1], 2) for b in range(0, len(pic_symbols), 8)]

and the output is

noone  [85, 85, 85, 81, 211, 76, 51, 51, 211, 178, 180, 82, 203, 50, 213, 210, 168, 105, 166, 153, 153, 105, 89, 90, 169, 101, 153, 106, 105, 212, 52, 211, 204, 204, 180, 44, 173, 212, 178, 76, 181, 20]
Si4010 [85, 85, 85, 81, 211, 76, 51, 51, 211, 178, 180, 82, 203, 50, 213, 210, 168, 105, 166, 153, 153, 105, 89, 90, 169, 101, 153, 106, 105, 212, 52, 211, 204, 204, 180, 44, 173, 212, 178, 76, 181, 52]
pic    [85, 85, 85, 81, 211, 76, 51, 51, 211, 178, 180, 82, 203, 50, 213, 74, 85, 53, 205, 52, 51, 51, 45, 75, 43, 181, 44, 83, 173, 84, 85, 211, 76, 51, 51, 211, 178, 180, 82, 203, 50, 213, 74, 85]

So the Si4010 and TheNoOne's code varies only at the very end; but I don't understand the Pic code well enough to see if/why its "3 bit" "frame delimiter" is the same result as the other two.

nicholas-gh avatar Feb 13 '20 02:02 nicholas-gh