0

Update: A representative of Omega responded to my request for a communications manual: "The OM-92 is designed and marketed for use only with the provided software. The command set is not available and considered proprietary." Regardless of this, I am still interested in good techniques for reverse engineering serial devices, but will be proceeding in my project with different sensors.

Background: I have an OM-92 temperature and humidity logger that I am trying to communicate with over serial. There doesn't seem to be any documentation about the communication protocol it uses. It comes with a GUI to download data from the device, but I'm trying to record data from this device automatically and the GUI just gets in the way. Additionally, the GUI software only works on Mac and Windows (I am using Ubuntu on a Beagle Bone Black).

Question: How can I determine the communication protocol it uses? How can I determine the command instruction set?

Theories: I have a hunch that it uses Modbus (because the Omega controllers do). All I know for sure is that it connects the the PC with a standard via USB.

Rekamanon
  • 217
  • 2
  • 10
  • Question: does the logger show on Device Manager as a virtual serial port (COMx)? If so you can use com0com plus Termite to sniff on the port, see [here](https://stackoverflow.com/questions/57056042/i-am-sending-commands-through-serial-port-in-python-but-they-are-sent-multiple-t/57062146#57062146). I can write an answer with more details if you need. I'm not sure it will be Modbus, which is a very open and easy protocol when you want to obfuscate how the communication works. You would be lucky if it is, it would be easier to reverse-engineer than a proprietary protocol. – Marcos G. Dec 07 '19 at 08:56
  • @MarcosG. The logger appears with two entries: HID-compliant vendor-defined device; and USB Input Device. (These are the two entries listed under the logger when the Device Manager view is 'By Container' – Rekamanon Dec 09 '19 at 17:59
  • Not what I expected. When you plug it to the Beagle, what is listed on a `lsusb` command or `dmesg | grep USB`? – Marcos G. Dec 09 '19 at 18:15

2 Answers2

-1

Have you opened up any of the files from the device in a Hex editor to see how the data is being stored? If the data is not compressed, then the way the logging is done should be a clue as to how the memory map for the data was created. The file header information may also lead to other clues such as the communication protocol used or it may simply just be 'raw data'. But start there. Usually there is some useful information within the file that can point you in the right direction.

YYC_Code
  • 27
  • 4
  • How data is stored on a file has nothing to do with the protocol used to communicate with the device. – Marcos G. Dec 07 '19 at 08:58
  • Marcos - it can in some ways, yes.If you assume Modbus, then it must follow the modbus protocols for storing the data. Big endian, little. endian, formatting of date codes, byte order, size, etc, can all assist in determing the mapping used. Once you know how the data is being saved, then you can test basic serial comms with the protocol in mind. I used to write modbus drivers for gas analyzers and this was one way I mapped out unknown devices. But it takes a lot of time to do this. But the only way for sure is a protocol sniffer and see how the data is being written to the device. – YYC_Code Dec 07 '19 at 19:51
  • I can agree what you say might hold for the most basic kind of device but in my opinion what you wrote is still very far away from being a useful answer. You could have made the effort of downloading the data logger referred by the question and try to make some kind of connection with the data transfer protocol – Marcos G. Dec 08 '19 at 09:36
  • The GUI only provides options to save as a CSV or as PDF, which I don't think help. – Rekamanon Dec 09 '19 at 18:02
-1

You need to sniff data from comport, and analyze how the program and device communicate.

If you find out the modbus protocol there, you can try to decrypt it, but I assure you, this is a huge job, it will be easier and cheaper to buy a device that supports modbus and have documentation.

Often, large companies go to meet. Call or write a letter to the manufacturer, they will most likely prompt you.

Probably, there is no modbus, the manufacturer is not profitable to hide it..

Евгений Елисеев
  • 374
  • 3
  • 10
  • I agree with the last sentence of your answer: if you use Modbus you will probably advertise it. I disagree with the statement that reverse-engineering Modbus is that difficult but it might be indeed easier and cheaper to buy a new device that is properly documented or at least more programmer-friendly. I'm downvoting because what you wrote is not an answer, it's just opinion and you could have written a comment for that. As it is, your *answer* is not adding any value – Marcos G. Dec 07 '19 at 09:03