Losing data when extracting bytes from words - 16F18855

[richard]

You will notice you never receive the data from 93 onwards

since your terminator is "]" <==> ascii 93

[Demon]

You will notice you never receive the data from 93 onwards

since your terminator is "]" <==> ascii 93

Ok, but what about these guys?

[0340 0341 0342 0343 0344 0345 0346 0347 0348 0256]
[0860 0768 0000 0000 0000 0000 0000 0000 0000 0000]
[1110 1111 1112 1113 1114 1115 1116 1024 0000 0000]
[1620 1621 1622 1623 1624 1625 1626 1627 1628 1536]
[1880 1881 1882 1883 1884 1792 0000 0000 0000 0000]        <---- this one does have a 93

EDIT: What would you suggest as a good delimiter? I have no idea what would avoid this stuff.

[richard]

349 dec = 0x15d 0x5d = dec 93 <==> ascii "]"

[Demon]

Right.

In mainframe programming, we used high-values.

Is x'FF' is viable option in PBP?


EDIT: This doesn't work, even if tilde is at 126. Some still get triggered.

hserin [ wait("~"), STR MsgData\21\"~" ]

EDIT SOME MORE: it works fine if I don't use delimiters. I'll be sending text and numbers so I don't see a way out, I have to leave the ends "free".

[richard]

the start and finish characters cannot be allowed in the data body of your message using your simplistic scheme ;

there are much simpler and more reliable methods

[Ioannis]

The safest is to use ASCII characters for your numbers and not binary.

Of course this will need more characters to send but that way your delimiter will not mess with your data.

Or maybe you can have specific data length and then CRC check along with timeout.

Ioannis

[Demon]

maybe you can have specific data length and then CRC check along with timeout.

I have a need to identify the to-from PICs, as well as data identification, and a confirmation code if it went OK (still thinking about how to handle Not OK).

I've practiced CRC many years ago, so I might still add that feature to make sure the data was not scrambled while still having valid delimiters.

the start and finish characters cannot be allowed in the data body of your message using your simplistic scheme...

I've been thinking a lot about how to delimit messages with characters that do not interfere with the message (or rather vice versa as Richard pointed out). The last character in the ASCII table is 126 $7E ~, in binary that's 01111110. Is anything stopping me from using %1xxxxxxx and up to act as delimiters?

Prefix delimiter:
- %11nnnnnn, PIC ID (64 combinations);
- %1nnnnnnn, Transaction ID (128 combinations).

Messaqe:
-bla bla bla

CRC:
- byte (can handle 255 byte message, or at worst, a word).

Suffix delimiter (seems it's limited to a single byte in PBP - "Receive string of n characters optionally ended in character c"):
- %111nnnnn, Confirmation code (32 combinations).

This would only cost me 3 bytes, offer plenty combinations and could be imbedded along with the message.

there are much simpler and more reliable methods

What simpler techniques did you have in mind?


I also want to be able to easily add more PICs or Transactions IDs as the project grows (I'm considering an optional control panel). This first project will serve as a template for larger airplanes with many more controls (think Boeing 787).