It's been along time since we started using our CSV-like protocol. Now with
a new terminal coming up, I think it's time for a recap on this protocol. I
think the used protocol is not the most flexible/small protocol we can get.
But I would like to have, because of transport-costs. It has to stay
It looks a little like this: TST11,22,33,44,,,77. Where TST is the
identifier and 11 to 77 are parameters send to/from the terminal. Looks
okay. But the tricky part starts when (1) parameters are left out and a
bunch of comma's have to be send (TST11,,,,,,77) and (2) when a message, for
instance this one, has to be extended it will always have to be extended in
the back-part of the message, with (in both cases 1 and 2) always having the
drag of the comma's even when these aren't send for years. Removing the not
used values from the message (to have ,,,,) we called stripping.
Another, more flexible, protocol I was thinking of looks like this:
Where <..> are single karakters <Record Seperator>, <Unit Seperator>. After
each <RS> there is a parameter-id and after each <US> there is a value.
At this time we use a form of compression where almost all message-id's like
TST are compressed to single-byte values. Don't know if we need that with a
Please, some opinions on this would be great!