Teensy 4.0 / High Voltage Heater

Hi Jordan, all fine here, hope you're doing well too.
Anyway, this chinese heater looks to better documented although I see some unclearities.

View attachment 35078
ID 0x22 represents the signal sent by VDDM to HVCH, with a byte length of 4 bytes. If I wanted to place the maximum values for allowable power, target water temp, water flow signal and enable signal, would it look like this:

uint8_t lindata[] = {0xff, oxff,0x3ff,0x1};
lin.order(0x22, lindata, 4, lin2x);
This is a bit strange; for ID22 the spec states Byte 2 is 10 bits long? If you want to write 0x3FF, you need to split that value over 2 LIN data bytes like so:

Which translates to:
`uint8_t lindata[] = {0xFF, 0xFF, 0xFF, 0xD0};`
`lin.order(0x22, lindata, 4, lin2x);`

For ID 0x33, the length in 3 bytes, but the info only goes into Byte 0 and Byte 1 above. I am trying to understand if there are still 3 separate pieces of information and how they are placed. If I wanted to place zeros for the E2E checksum, E2E counter and HVCH enable signal, would it look like this:

uint8_t lindata[] = {0x0, 0x0, 0x0};
lin.order(0x33, lindata, 3, lin2x);

View attachment 35079

ID33 is actually 2 bytes like so:

Which translates to:
`uint8_t lindata[] = {0x00, 0x08};`
`lin.order(0x33, lindata, 2, lin2x);`

Note 1: LIN messages are only 2, 4 or 8 bytes long, not 3.
Note 2: does the spec state something about how to calculate the `E2E checksum` and what the `E2E counter` means?

ID 0x17 shows what we should be getting on the lin.response, correct?

Would that look like:
lin.response (0x17, data, 3, lin2x)
I was not sure if LSB and MSB come into play in any of this.

Thanks!
To request ID17 you need to request 4 bytes: `lin.response (0x17, data, 4, lin2x)`
The response will look like this:

Hope this bit-fiddling makes sense...

Paul

Thanks again Paul. I do not believe I have any info on calculating the checksum. I will ask the seller and look for anything in what they sent to me.

Just so I understand better, on ID22, is the 0xD0 (208) because in byte 3, there are 2 1s and then a 0 to finish out that command then one more 1 for that entire byte? 2 0 8 ?

If so, on ID33, byte 1 has 4 0s and only the 1 at position 5 (which is a full on or full off signal) so on equals (0x08) 08?

Just so I understand better, on ID22, is the 0xD0 (208) because in byte 3, there are 2 1s and then a 0 to finish out that command then one more 1 for that entire byte? 2 0 8 ?
Correct, I set the bits in byte 3 that are not defined in the datasheet (bits 26, 28-31), to '0'.
If so, on ID33, byte 1 has 4 0s and only the 1 at position 5 (which is a full on or full off signal) so on equals (0x08) 08?
Those 4 0-bits are the value of `E2E counter`. Perhaps we need to write a certain value there? Hopefully the seller returns your question.

Paul