Useful, efficient software matches the user's needs, knowledge and skill. Don't buy a swiss army knife when you need a wrench...

About Us

A young company still hungry for challenges, with 30+ years of experience with software development from small embedded systems to distributed real time PC networks and SQL databases. A reasonable design effort to deliver high-quality software e.g. for medical devices on schedule.

External Links




     Other sites


Symbol set
In embedded systems we will probably need to be able to transfer any byte in the message plus maybe some extra symbols for protocol handling that is not part of the message.
If one code is reserved as Escape code the 256 symbol set expands into a 510 symbol set (assuming ESC+ESC is illegal), whereof 254 could be used for control.
In a channel where it i only safe to transmit ASCII codes from 33 to 126 (printable, non-blank), we have 94 symbols. Using one as an escape symbol we have 93+93=186 symbols available. With two different escape codes we have 92+92+92=276 symbols available with one or two bytes sent, enough to transmit any byte plus a few extras for protocol.
A similar example is SLIP framing that reserves the bytes 300 and 333 (octal) for symbols END and ESC. This means these codes are not read into the message buffer but has a meaning for the protocol only. To deliver the code 300 (octal) to the message the combination 333+334 are transmitted over the channel, and to transmit 333, 333+335 are transmitted. Thus all bytes can be transmitted though the END and ESC byte values are transmitted double length.
333 334 333 335 300
Transmitted a message containing bytes 300 and 333 (quoted the reserved END and ESC codes).
You can use as many control chars as feasible and invent escape codes to replace them in the message. Escaped bytes have double length so whether to use reserved byte codes or escaped codes for control depends on whether some byte values are less frequent than the escape codes. E.g. if bytes have random distribution the probability of having the escape in the message is 1/256, and if messages are 8 byte length on average you will use 32 single byte control codes per dual byte escaped code, earning 31 bytes compared to escaping the control code.
Longer messages give less benefit and when message length exceeds symbol set size you gain by escaping the control byte.
 There is also a risk having a multi-symbol combination for framing that with a fixed bit error rate the risk doubles to get a bit error in a two-symbol code compared to a single-byte code, and control codes tend to be more serious to miss than regular data bytes since you can add error detection/correction codes to data but not to control symbols since these are used to find the error detection codes.
In some systems certain codes never are transmitted though they are transmittable over the channel. Some systems need to send only ASCII and the 8th bit can be used to signal control codes.

< Previous
Escaped symbols have the drawback of worst case transmission length twice the length of the original message (imagine wanting to send a number of ESC symbols as data). There are some ways to make message length independent of content of message is to use a subset of the byte bit-packed, similar to Base64 or the older UUEncode or XXEncode. that packages 2 bytes in 3, using 6 bits per byte for payload. With a fully 256-code binary raw symbol set, Using 7 bits of payload per byte allows us to send 7 full bytes in 8 transmitted bytes.
0aaaaaaa 0abbbbbb 0bbccccc 1cccxxxx
3 bytes encoded into 4 where the most significant bit indicates last byte (x is don't care). Or you could send one byte of 8th bits like this:
0abcxxxx 0aaaaaaa 0bbbbbbb 1ccccccc
Slightly trickier is using 9 bit symbols when we can only transfer 8 bits.
aaaaaaaa abbbbbbb bbcccccc cccxxxxx
Here we can use 9 bit symbols and define several escape symbols, but if we lose sync it is trickier to find the starting point since it can be any bit in the byte. Also we need to eliminate any shifts of the framing symbol(s) to guarantee that don't misinterpret data for framing. E.g. if framing is nine consecutive ones, we could disallow codes starting or ending with five or more ones thus nine ones can never be generated by two adjacent symbols. We lose 32 codes out of the 512 which gives us plenty of extras to play with. Shifting bits is a bit compute intensive though so this would work for slow transmissions or be implemented in hardware.
To gain even less overhead we could package several bytes using e.g. 15 bytes out of 16 for data, or 31 out of 32. Note though that we often want to send short messages and with longer codes we will have more waste at end of communication. Also we lose a number of codes to prevent the framing pattern to accidentally appeear in the input stream.
Principally the set of symbols including protocol symbols could be packed arithmetically into a bit-streamed message similar to btoa utility. Btoa generates a packet of 5 bytes computed with base-85 arithmetics from 4 data bytes. With one escape code we could convert the whole messagerequiring only one extra byte required per message up to 1415 bytes. This number n is determined from the inequality:
256^n <= 255^(n+1)
Using ESC, START, FRAME and ACK as reserved inequality becomes:
256^n <= 252^(n+1)
allowing one extra byte per 351 effective bytes.
The arithmetic message length requires a lot of computing power though (base conversion with bignums is tedious).

Next >
Copyright 2013 Useful Software Sweden AB E-mail:, Phone: +46 708 727662 
Useful Software Sweden AB