Trying to communicate with a device with an undocumented protocol

Similar projects worth following
I got a commercial piece of equipment which can talk to a whole suite of sensors. For some of the older 4-20ma Sensors, they've come up with a "Digital Gateway" which makes retrofiting a breeze. The Digital Gateway uses M12 Connectors, with 4 live pins (+12VDC, GND, A+, B-).

Looking at the signals on the O-Scope it looks like differential COMs, like RS-485 or CAN.
I do not believe its CAN by looking a the differential lines voltages.
Since the device has an aditional ModBus optional module for connection with SCADA or the likes, I decided to hook up a 485 transceiver to the sensor cables and just listen to the traffic.

Code to listen to the trafic is as follows:


Read more »


The Txt file with the log

gateway - 6.83 kB - 03/11/2019 at 21:53



    Gabriel04/21/2020 at 00:03 1 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.

  • Some kind of Progress

    Gabriel04/20/2020 at 12:53 0 comments

    So, one thing that kept messing with me was that the packet length was never the same, which i though was pretty wierd. After many data dumps, and start, stop bit combinations, baud changes etc, i finally ended up reaching the conclusion that this was 8N1 at 19200 baud. I decided to try several older encoding/protocols like VT100, VT52, and the likes.

    FINALLY some insight. There are ALOT of blank spaces, or dummy bytes, most likely for timing/sync purposes. Im still unclear if the blank chars are NULL or 0x20 (ascii space).

    There are escape characters, but these do not seem to match with any known (by me atleast) protocol, yet some characters do seem to be standard escape chars like SOH (0x01).. the data contains binary data and Ascii, but i cant seem to figure out the escape sequence for when Ascii starts and ends. ASCII 85 Maybe? 

    This explains the unequal packet lenghts. Some packets need to include more or less escape chars, and thus pretty much no single hex dump was the same length.

    At some point i figured out where the "data" was in the packet, in the form of 2 float (4 bytes) variables ph and temp. I wrote a small script to ignore the blank spaces and print a text representation of all the usual escape characters, basically ascii 0x00 to 0x14....  basically on my terminal i got a bunch of hex but when the byte was a 0x00 it printed the word NULL... 

    This worked and i managed to evesdrop on the data bus and get PH and Temperature.... for a bit... a lot of data loss or wrong values. This was before i figured out that there are a lot of escape characters mixed in even with the data... which makes sense when you realize that a 4 byte float might contain a byte with the same value as an escape char or something along those lines.

    So... next up, do a plain Hex Dump of the bus, and write a new script that purifies the incoming data. If i manage to get a sustained output of PH and temp i will know im on the right path.

    I still cant figure out how the SC200 requests data or when the sensor response begins.

  • Super Important details

    Gabriel03/20/2019 at 11:26 0 comments

    The device im trying to hack is the "Digital Gateway" used to attach sensors to a "Hach SC200". On the main PCB of the SC200 I found 2 RS485 chips ADM3483ARZ which confirms my initial thoughts on the physical layer.

    I have no futher info on the actual gateway as its a solid epoxy block and these devices are NOT CHEAP so destructive hacking is not an option.

    The through the gateway we get temperature and PH/ORP readings among other setup config testing infos. There is a complete modbus map available for the gateway/sensor which a normal user would use while talking to it THROUGH the SC200 which has an additional Optional modbus card (which i have).

    The manual is on the link above and it includes the modbus register map.

    Now to be clear: the gateway does not speak in modbus to the sc200.

    Im trying to AVOID using the SC200 and talk to the gateway directly.

  • What its not

    Gabriel03/11/2019 at 21:57 0 comments

    As clearly seen by the log, the pattern repeats, changing only where the "Data" should be. there are 2 parameters being logged by this sensor.

    I thought this was straight modbus since the device already supports modbus, and the physical layer seems to be 485, but its not.

    I thought it might be CAN over 485, but its not.

    I thought it could be Profibus but you guessed it... its not.

View all 4 project logs

Enjoy this project?



Karl-Wilhelm Wacker wrote 04/20/2020 at 19:58 point

Two additional thoughts - 1) have you looked at the signal[s] with a scope to see the bit rate and if the framing is correct?  2) what happens if you swap the A & B lines for the RS485 - I've seen that sort of weirdness when I had them reversed when working with Modbus & other RS485 stuff.  All the "FF' char is what you would see if the device is pausing between char & the polarity is inverted.

  Are you sure? yes | no

Gabriel wrote 04/21/2020 at 00:07 point

I thought of this, but i have too much coherent data with A & B right where they are. look at the last log i just posted. all help is appreciated!

I have straight Ascii text that corresponds to the sensor name, the sensor serial number and ive already identified the 4 bytes that make the floats for temp and ph.

but hey, im open to any ideas you got!

  Are you sure? yes | no

Karl-Wilhelm Wacker wrote 04/20/2020 at 16:51 point

Have you considered that if there are escape characters, the data might be in 'bisync' or SMS type format?  Both bisync and the format used in some versions of SMS text messaging have reserved characters, and if you encounter the reserved characters in bisync you need to prefix them with the escape character, and with the SMS format, the escape character tells the software to modify the code for the special characters by add/subtracting a constant from the character following the escape character.
  You would see a variable length message due to the varying amount of data characters that needed an escape character in front of them.

  Are you sure? yes | no

Gabriel wrote 04/20/2020 at 19:38 point

thanks for the "bisync" suggestion...seems like a plausible format the problem im having is that none of the escape chars seem to match any protocol... they do match partially with atleast 5 protocols... so nothing works but everything kinda works at the same time...

I did notice that everytihing that IS escaped is larger than 127 (decimal)...i did a quick test and computed a few float values aknowleging the presence of the escape chars but ignoring their use (ie substracting or adding a value from the escape sequence) and i got "reasonable" float values... but they might be off by a few decimals and i would have not noticed.

The stuggle continues... ill try to get a better hex dump today. 

  Are you sure? yes | no

Gravis wrote 03/20/2019 at 20:59 point

"Digital Gateway" is considered the type of device.  The PCB shows the device is made by Hach.  You didn't show a picture of the whole device (e.g. device face) which definitely has the model number of the device printed right on it.  My guess is this is either the SC100 or SC200.  The product info for the SC200 ( ) indicates which protocols are being used: ODBUS RS232/RS485, PROFIBUS DPV1, or HART 7.2

  Are you sure? yes | no

Gabriel wrote 03/20/2019 at 23:00 point

thanks for your reply, but i feel either i didnt explain my self or you did not understand my goal.

On my second proyect log i specifically say i have an SC200. It has a separate modbus/profibus/hart module  for normal comms which i can talk to without issues. This is how regular users get sensor readings from the SC200. To be clear i can comunicate with the SC200 with my eyes closed my hands tied and a paper clip. This is NOT the mystery protocol.

However, SENSORS are connected to the Sc200 via 2 x M12 connectors which use rs485 to talk to a "Digital Gateway" (see project pics) which converts analog sensors to digital. Each digital gateway is specific to the sensor type.

Comms between the SC200 and the "Digital Gateway" are not meant to be seen by regular people and its the propietary protocol i want to break. i would like to eliminate the SC200 and talk directly to the "digital gateway" (the product is actually called that, not just a generic term).

PC->SC200->digital gateway->analog sensor.

Remove PC AND SC200 from this equation.

  Are you sure? yes | no

Gravis wrote 03/21/2019 at 02:33 point

OK, I see the post now.  You need to actually provide the corresponding data that's been decoded by the SC200 to make any sense of the encoded data.  It also appears you have to option to connect J-TAG to the SC200, so you could dump the program, track where it's executing (while reading the sensor) and then reverse engineer that section of code.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates