2

I have an old water purifier system that consists of a PDA and a main board (I think the ic is a Renesas) that communicate by RS232, I need to know the protocol they use to communicate in order to reproduce it from another device. I already have it practically done, below I detail the characteristics that I have been able to extract:

Protocol details

RS232

Endian: LSB

Baud rate: 9600

Data: 8 bits

Stop bits: 1

Parity: Odd

Packet size: 21 Bytes

Character start / stop: 90

Polarity: Positive

Time between two bytes: 6.8 mS

Time between packets: 1.9 s

second-last (byte 20): checksum (simple sum of all data bytes + 90)

Message format

PDA (TX): 90 + (18 * data_byte) + checksum + unknown_byte

Mainboard (TX): 90 + (18 * data_byte) + checksum + 90

I also already have an idea what each byte of data corresponds to, but the last byte (unknown_byte), I don't know what it corresponds to, it varies constantly even though the data is the same. When I turn on the PDA, it continuously sends the same sequence:

  90 + (18 * zero_byte) + 90 + unknown_byte

The last byte seems to follow a sequence from the start of the PDA, but it does not get to repeat itself exactly:

05, EA, EC, F1, E9, EE, F4, EB, F1, E8, EE, F3, EB, F0, E8, ED, F3, EA, F0, F5, ED, F2, E6, EC, F1, E9, EE, F4, EB, F1, E8, EE, F3, EB, F0, f6, E8, ED, F2, EA, F5, EC, F2, E9, EF, F4, E8, EE, F3, EB, F0, F6, ED, F2, EA, EF, F5, E7, EC ...

Other sequence in DEC:

5,234,236,241,233,238,244,235,241,232,238,243,235,240,232,237,243,234,240,245,237,242,230,236,241,233,238,244,235,241,232,238,243,235,240,246,237,242,234,239,245,236,242,233,239,244,232,238,243,235,240,232,237,242,234,239,245,236,242,233,239,244,236,241,233,238,244,235,237,243,234,240,245,237,242,234,225,245,236,242,233,239,244,236,241,233,238,244,235,240,229,234,239,245,236,242,233,239,244,236,241,233,238,244,235,240,232,237,243,234,240

Does anyone know what this field may correspond to?

Thanks in advance

Improve this question
4
  • Can you extract code from either part of the system to analyze it?
    – Igor Skochinsky ♦
    Commented Mar 15, 2020 at 12:50
  • Unfortunately it is not possible in this case since I do not have a reader for this integrated circuit and it is also very inaccessible on the PCB, hence the problem. I thought it could be a checksum or CRC but discard this possibility because it constantly changes with the same payload
    – Pep
    Commented Mar 15, 2020 at 13:10
  • 2
    There is a third option: The sent data may be just one byte too large and hence the last byte is just garbage from uninitialized memory that is ignored by the receiver. Send some data yourself and see if the last byte has really an effect.
    – Robert
    Commented Mar 15, 2020 at 14:04
  • Thanks Robert, I thought the same, and tried to externally send the same signal that the PDA initially sends (90 + (18) zeros + 90 +90) with the last byte with a fixed value (90), and the main board does respond with the data It has configured, the problem is when updating which does not work, and I think that is where the last byte intervenes, it is quite curious I had never come across something like this
    – Pep
    Commented Mar 15, 2020 at 14:44

3 Answers 3

Reset to default
1

Without access to the code it’s hard to say for sure but I think it’s some kind of sequence number. I’d suggest trying to record as many sequences as you can and try sending the replay on your own to see if you get the same responses.

Improve this answer
1
  • first thanks for the help. I also think it must be some sequence, but I have extracted a long sequence of values ​​and I have tried to locate some pattern but I don't see it. I have tried to externally send the same signal as the PDA with the last byte with a fixed value of 90 and the mainboard responds with the data, the problem comes when I try to update some parameter on the main board, which does not work and must be where it enters I play the last byte
    – Pep
    Commented Mar 15, 2020 at 13:32
1

The fact that this value is not checksummed (as I understand?) is very confusing but it might suggest either:

  • the protocol really doesn't care about bit flips in this value (and needn't drop the packet in that case)
  • the value is not yet known during the checksumming process

I really don't have a clue, if I had to take a shot in the dark I'd say this is some kind of sanity check that checks that something approximately correct over a long period of time.

If I am reading the question correctly, you always see the same sequence when you start it? This makes me think random number generator, probably LCG or XOR shifter. In both cases the algorithm can be reverse engineered with enough data. And if it is an RNG it will eventually repeat.

Interestingly except for the 05, all values are 230 plus something from 0 to 16 (inclusive!!) There could be a mod-17 going on somewhere.

Seen another way, they are all within 238 +- 8.

Why an RNG? Beats me. Theoretically you could work out how many packets have been sent since it was turned on by observing a sequence of them. A strange sort of sequence number.

If you aren't always seeing the same sequence... could it be a time-delta (the time since the last reading?) to prevent clock drift or something. I don't know what the point would be, and it's strange that the same value never repeats twice in a row. But it might fit with the theory that it isn't known at checksum-time.

Good luck...

Improve this answer
1
  • After several tests, I was able to send a command externally, keeping the last byte at a fixed value and it worked (I still have to check with all the other commands to see if they work), so I have concluded, as Robert also pointed out that it may be garbage , it is strange because it follows an initial sequence but it is the only logical explanation. Thanks for the notes Artelius
    – Pep
    Commented Mar 17, 2020 at 19:18
1

Finally, after carrying out multiple tests it seems that it can be garbage, keeping this value fixed I have been able to send a command externally and it has worked

Thanks to all for the help

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.