The first five bytes represent the message ID. The sixth is checksum for the message ID, the seventh and eighth represent mV from the probe (Seventh byte is LSB and eighth is MSB)
Nineth, tenth and (i think) eleventh bytes are the temperature. Tvelveth byte is 8-bit XOR checksum of the seventh to eleventh bytes.
The last one is a mystery to me.
I think the last byte is dependent of the payload and not the message ID or its checksum. One of the messages (i have it logged at work) where the payload was 00 the checksum was also 00 and the last byte was also 00.
If anyone can shine some light on how to calculate the last byte I would very much appreciate it
If the last byte is a CRC check, the program RevEng works very well, but you have to be certain which part of the message is included in the CRC calculation.
However, I doubt that the last byte is the result of a CRC, because you expect several bits in the CRC check to change, even if only one bit in the message changes. It might be a parity check instead.
Considerable trial and error may be required to solve this.
I have been using RevEng for a week now. I tested several variants with no success. With maybe three messages i get crc calc parameters but they don't work with other messages. But mostly i got no module found... I was starting to think the probe uses some custom lookup table.
Could you point me to the right direction on how parity check works or how can I calculate it?
It makes no sense to me why would the make a probe with checksum for the message and for payload and then another check at the end only for payload
It makes no sense to me why would the make a probe with checksum for the message and for payload and then another check at the end only for payload
If you want very high reliability, multiple different checks are required. The message structure made sense to someone.
For an 8 bit CRC, the chance of a random nonsense message passing the check is 1/256, which is certainly not negligible.
Parity checks check the bit pattern or some subset of it for the number of "1" bits. The number of "1"s plus the parity bit must be even or odd to pass, depending on the variant.
Another possibility is an exclusive OR of some subset of the message, which is a similar concept to parity checks.
Easily. Have a bytewise parity check, where the bit significance in each message byte is retained. For example, bit7 of the parity byte is the parity bit check for all bit7s in the message.
And here only the temperature changes by 1
Data like this are not necessary useful.
It is much more useful to collect messages where the data differ by only one single bit, for example when the temperature goes from 0 to 1, or from 2 to 3 (but not from 1 to 2, because two bits change).
If you collect a bunch of messages that exhibit single bit changes in the data fields and post them, I or others may be able to help you solve this problem.
But first, please explain why it is important to do so. You don't need integrity checks to simply interpret the message content.
Do I remember correctly that a parity check exclusive-or each byte of a message and if the end resulting byte was zero, the parity was zero? If non-zero, the parity was considered 1?
jremington: But first, please explain why it is important to do so. You don't need integrity checks to simply interpret the message content.
You are right. Curently I an ignoring those bytes.. The problem is with initialization. I dont hava the data with me now, but to get data from the probe I need to repeatedly send a "query" message to the probe so I get a response like I posted them.
But the thing is that before I can start pooling the probe for measurments I need to send an initialization message (only once at power up) and then I can get responses from the probe.
The Init message is different for every peobe. I can copy it with the original controller and n RS458 to usb converter. But in about a year and a half or maybe rwo years when pthe probe will need to be changed I will not remember how to get the new init code :).
That is why I need to calculate the last byte. The init message is only 2 bytes wide plus the checksum and the las bit. If I could calculate the las bit I can brute force the 2 bytes to get the init.
I am not keen on brute forcing 3 bytes @10Hz it would take 19 and a half days to ID the initialization (worst case). This is for a friends aquarium to very accuratley monitor thepH of the water and calculate the co2 with carbon hardness so we can control a co2 valve. I got this one (and a few broken ones) from a co worker. I could buy some analog hobby ones but the accuracy is not good for this kind of task
jremington:
It is much more useful to collect messages where the data differ by only one single bit, for example when the temperature goes from 0 to 1, or from 2 to 3 (but not from 1 to 2, because two bits change).
If you collect a bunch of messages that exhibit single bit changes in the data fields and post them, I or others may be able to help you solve this problem.
I can do that. But must luck I can have with temperature. Changing ph so slow to read them all will be almost impossible
in one part the last byte is unchanged but the data changes ??
I captured also a part of the init of the probe that seems interesting
[/code]
00 01 8c 00 c6 00 00 00
[/code]
This has nothing to do with the temperature or mV it is part of an initialization of the probe.
I managed to get the probe working with an Arduino
First I sent to the probe
00 01 1a 04 00 1f 22 04 26 80
This is the message ID and is the same for every probe
00 01 1a 04 00 1f
And then I repeatedly send
00 01 01 01 00 01
then I get responses like I posted in the beginning on this post
The tricky part is figuring out the initialization code ( 0x22 0x04 0x26 0x80)
The 0x22 and 0x04 is different for every probe, the 0x26 is the Xor checksum of 0x22 and 0x04. The 0x80 is the same mistery variable.
I could brute force attack and calculate the third byte but that leaves me with 3 bytes and at 10Hz highest pooling speed it would take 19 days (worst case) to find the probe.. I know the probe wil not be changed for a year or more but if/when it will need replacing I would use 19 days to register the new probe
The hex numbers 0x17 and 0x18 differ by 4 bits, not one.
The binary representations are 00010111 and 00011000
Here are two examples where the data change by only 1 bit, and as you see, two of the supposed digits of the "checksums" also change by only 1 bit, suggesting a simple additive/subtractive pattern.
Yeah it seems that the number of bits changed in the message equals the number of bits changed in "checksum". I've been going around this for two weeks with no clue on how to calculate the last byte
