PARMRK

One for the techies...

On linux, serial port processing has a lot of options, and I mean a lot. It is scary. In order to do this RS485 stuff I was setting the most raw, basic, just give me the bytes mode I could.

However, in a fit if stupidity I set the PARMRK setting in termios. It seemed like a useful thing to tell me if I was getting a BREAK or other framing error on the bus.

All was well, pretty much, but I had not realised, PARMRK does no just prefix framing and parity errors with a sequence like FF 00 so you can see them, it escapes a received FF byte as FF FF.

This makes sense, else how can you tell it is marked or not. I should have thought of that!

The problem is that the Honeywell Galaxy serial stuff uses a 1s complement checksum. Only if the checksum should be 00 would an extra FF byte matter making it FF. In all other cases FF wraps adding 1 more, and causing the checksum not to change.

So I was getting messages, and some would contain FF, and I would see as FF FF, but the checksum would be fine. I was assuming the messages I was debugging were meant to have FF FF. It did strike me as odd in one case, I have to admit. And most of the messages did not contain FF.

Only when I started on the RIO where I had things like tamper reported FF and resistance reported as FF FF (infinity) did it stick out, with the message length being inconsistent. Have eight lots of FF FF escaped by PARMRK in one message and it very quickly looks silly.

I could de-esacpe the input, but simpler was not use that feature. Well done using 1s complement checksums!!!