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


  • 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 2 project logs

Enjoy this project?



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