Hi Dojo,

I'm working on a serial connector and have some questions about unstuffing.

The protocol I'm implementing(Pro-Bel SW-P-08) defines start of message(0x10 0x02) and end of message(0x10 0x03) control characters and defines a rule for cases where 0x10 appears in the data segment. The rule is simple, if the 0x10 appears in the data segment double it.

I'm receiving the following stuffed message:
0x10 0x02  0x0B 0x00 0x03 0x10 0x10 0x03 0x00 0x06 0xD9 0x10 0x03

Original implementation:
Initially I was removing stuffing from inside of the QAction, after reading the response, which works if the 0x10 is not followed by 0x03.

First attempt:
I added advanced tag to remove stuffing from the response.

As result the stream viewer was showing expected unstuffed message:
>> 16:40:10 - Incoming raw data
000000  1002 0B 00 00 10 03 00 06 DC 1003

However, this was still failing in the matching step and the data that was being passed to the QAction was 0x0B 0x00 0x00 which means that response reading was still interpreting 0x10 0x03(in the data segment) as end of message.

My response is defined like so:

Second attempt:
I added replace data action, instead of advanced tag.

Stream Viewer:

After increasing the log levels I was left with the following log:

Here we see that data is replaced properly, however the message is still cut short on the stream viewer level, and matching fails because 0x10 0x03 no longer exists(although it does actually come in).

Third attempt:
I added advanced tag, replace data action and stuffing removal in the QAction.

The advanced tag is the same as in the 1st attempt and replace data action is as follows:

The idea here is that odd number of 0x10 bytes is not possible because of doubling rule, so if I see odd number of bytes in the QAction, I can guarantee that the only source of them is my custom stuffing so I can safely replace them with 0x10 0x02 or 0x10 0x03 in the QAction. This only works if data is actually stuffed so I have to add back the stuffing as well, thus the first replacement rule 0x10 -> 0x10 0x10

All of this seems like a very weird way to achieve a common functionality of the serial communication, something I would expect to be available out of the box.

Is there a better, more straight forward way of achieving this?

Cheers