Close

INFORMED HEX DUMP

A project log for WIERD PROTOCOL

Trying to communicate with a device with an undocumented protocol

GabrielGabriel 04/21/2020 at 00:031 Comment

66 03 60 4D F5 
66 03 C0 SOH DE 1D 40 E5 #62 E7 41 EE 70 48 4F 52 50 43 35 33 32 34 37 36 19 06 22 06 22 SOH10 46 30 46 19 SOH42 70 40 40 40 40 40 40 30 30 31 38 30 33 35 33 32 34 37 36 4B 08 08 DC C1 C1 32 DC C1 C1 32 42 B4 42 B4 02 SOH02 02 02 02 02 3C SOH6D 92 86 80 1A D6 89 62 E7 41 EE C5 CE 41 6C 31 74 42 33 3F 80 3F 80 14 29 
66 03 26 FC 11 46 A9 
66 03 22 90 E5 26 30 07 90 40 18 03 53 24 76 38 BD 95 
66 03 26 BE 1C 27 78 
66 03 38 16 SOH 2C 65 36 EA 0A SOH09 70 48 4F 52 50 43 35 33 32 34 37 36 13 ~

66 03 60 4D F5 
66 03 C0 SOH AE 94 40 E5 # 5F D3 41 EE 70 48 4F 52 50 43 35 33 32 34 37 36 19 06 22 06 22 SOH 10 46 30 46 19 SOH 42 70 40 40 40 40 40 40 30 30 31 38 30 33 35 33 32 34 37 36 4B 08 08 33 C6 C1 2D 33 C6 C1 2D 42 B4 42 B4 02 SOH 02 02 02 02 02 3C SOH 6D 8D E3 80 1A BF 89 5F D3 41 EE BF A6 41 6C 2F EA 42 33 3F 80 3F 80 9E 77 
66 03 26 FC 11 46 A9 
66 03 22 90 E6 26 30 07 90 40 18 03 53 24 76 38 09 95 
66 03 26 BE 1C 27 78 
66 03 38 16 SOH 2C 65 36 EA 0A SOH 09 70 48 4F 52 50 43 35 33 32 34 37 36 13 ~

66 03 60 4D F5 
66 03 C0 SOH AE 94 40 E5 # 5F D3 41 EE 'p' 'H' 'O' 'R' 'P' 'C' '5' '3' '2' '4' '7' '6' 19 06 22 06 22 SOH 10 46 30 46 19 SOH 42 70 40 40 40 40 40 40 '0' '0' '1' '8' '0' '3' '5' '3' '2' '4' '7' '6' 4B 08 08 33 C6 C1 2D 33 C6 C1 2D 42 B4 42 B4 02 SOH 02 02 02 02 02 3C SOH 6D 8D E3 80 1A BF 89 5F D3 41 EE BF A6 41 6C 2F EA 42 33 3F 80 3F 80 9E 77 
66 03 26 FC 11 46 A9 
66 03 22 90 E6 26 30 07 90 40 [18 03 53 24 76] 38 09 95 
66 03 26 BE 1C 27 78 
66 03 38 16 SOH 2C 65 36 EA 0A SOH 09 'p' 'H' 'O' 'R' 'P' 'C' '5' '3' '2' '4' '7' '6' 13 ~

So Above you can see more or less what the BUS looks like in HEX. there are 3 instances/bursts of the communications. 

The last instance Ive modified a bit more for your ease.

all bursts share many of these mods, but start with the last one.

Ive "processed" this a bit as follows. 

1) All the NULLs have been removed.

2) Ive at Character 0x7E ive added an \r\n and printed the char in ascii (~). i did this because it felt logical - just go with me on this one.

3) Ive replaced all the 0x01 with the "word" SOH - Start of header. these might not be placed correctly because my capture script blindly swaps the byte for the symbol. so if you see one that looks wierd or out of place. just swap it with a 0x01

4) char 0x04 has been replaced by the character '#'. i did this to clearly mark 2 known float values. The PH and Temperature Data are the 4 bytes directly before '#' and directly after, hi byte and low byte are swapped. they check out with the device screen reading.

5) in the last comunication burst ive replaced what i KNOW to be Ascii with well.. ascii. I know these are correct because well, they match with the device lable and include the last 6 digits of the serial number

6) ive marked 5 bytes between "[ ]" brackets. if you notice (look at the project pics) its the serial number of the gateway.  i dont know why in one part of the exchange they send it in ascii and in another in hex coded decimal...

7) ive added a \r\n before each 0x66 Byte - It seemed logical, ive been looking at this for too long and maybe im finding patterns that dont exist.

Anyways thats what i have for now.

Discussions

Gabriel wrote 04/21/2020 at 13:23 point

i see no logical or pattern to signaling when the data changes from hex/binary to Ascii. I see no pattern involving the use of the SOH character. I cant tell what is the master requesting data and what is the complete response. Obviously the part containing the 2 floats separated by the # are part of the response... but the start and end of each part of the master/ slave conversation escapes me.

  Are you sure? yes | no