I have a PIC16F1937 series processor on a fire detection control card. I receive the output signal through Rx connections. I cannot figure out the protocol despite all my attempts. The signals present in the image are only reduced and enlarged signals received via RX. With a daughter card that can be connected separately to the main card, the warnings displayed on the current main card become active on the other daughter card. I think these signals indicate communication with the daughter card. I do not yet have the technical knowledge to interpret these sent signals. What I am guessing is whether it is modbus communication or not. These signals can be difficult to interpret. Due to lack of sufficient technical data. The only thing I know is that communication is provided through the Rx and TX pins on the processor. It shows 4035 baud rate as data rate.Logic signal measurement range 260us. Another image is raw data taken with the DsLogic device. 4800 Baud Rate.

enter image description here

enter image description here enter image description here

  • 1
    \$\begingroup\$ @sqrttp do you know anything about the protocol at all? The scope capture in your 1st image appears to be showing the byte sequence (in hex) 22 81 23 46 08 00 00 00 B5 (assuming it's an 8-bit NRZ/UART bit-stream). Does this mean anything to you? \$\endgroup\$
    – brhans
    Apr 3 at 0:06
  • \$\begingroup\$ @brhans Hello, unfortunately I don't know anything about the protocol. But after a lot of different trial and error, it started to give strange reactions when I sent a signal to a motherboard via hex via the computer, thanks to the Modbus modules. As a result of doing a lot of signal analysis, the only data source I came across was this hex code C9 04 62 FF 00 01 0E 0A. When you send this code via the computer via Modbus module, the card reacts. There is a return with a very large amount of data that I want to read the return signals from. \$\endgroup\$
    – sqrttp
    Apr 3 at 0:29
  • \$\begingroup\$ I can tell you from experience with a bunch of different Modbus devices over the years, that even if you know 100% for sure that it is Modbus, you may still have a lot of work to do to figure out how to interpret the data and/or how to read additional parameters on demand, change settings, etc. That's sometimes true even if you have the device manual! \$\endgroup\$ Apr 3 at 2:08
  • 1
    \$\begingroup\$ @manassehkatz-Moving2Codidact Hello, At this stage, MODBUS is frankly an assumption for me. Unfortunately, I wish there was an easier protocol, but it is not. It made me very tired. What I want to do is to develop a communication module suitable for the current system. I want to do this with a module rather than physically soldering. Hypothetically, there might not even be MOBUS. \$\endgroup\$
    – sqrttp
    Apr 3 at 2:37
  • \$\begingroup\$ What manassehkatz probably wants to say, even if you know the transport protocol (MODBUS), you commonly don't know the meaning of the payload. In most cases it is pointless to tinker with it. \$\endgroup\$ Apr 3 at 6:31

1 Answer 1


The steps I'd take when reverse-engineering a protocol like this are:

  1. Try to find an end-of-message marker. Is there a unique character at the end of each message? If not, the message may rely on the link going idle to signal end-of-message.

  2. Try to find CRC/checksum. Are there 2 or 4 bytes that always change, in random-looking ways? If so, they may be a CRC or checksum; usually this is at the end of the message, but I do know of one protocol where they were hidden in the middle of the message, but were still really obvious.

  3. Try to find sequence number / timestamp. Look for a field that increases in every message, which might be a sequence number or time stamp. Work out how many bytes it has (might be 1, 2, or 4).

  4. Look for repeating data, that is the same in each message. This may be the payload, check if it is always the same, or changes occasionally, which might signify a command.

  5. Try replaying data. If you have found a sequence that produces a response, try modifying the payload area you've identified. If you get the same response to any change, then probably what you are seeing is an error report (e.g. CRC error).

  6. Keep trying things, but accept that you may fail; the creators of the protocol may have included security features to make reverse-engineering really difficult, so what you're trying to do might not be possible within a reasonable time-frame.

  • \$\begingroup\$ Hello, thank you very much for the detailed explanation on the subject. Your answers will probably guide me. It might at least change my approach to this subject a little bit. If I get a positive result, I will share it. Thank you very much. Do logic signals make any sense to you in this regard? \$\endgroup\$
    – sqrttp
    Apr 3 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.