??? 08/11/11 14:19 Read: times |
#183299 - Hamming distance really not a good choice Responding to: ???'s previous message |
But hamming distance is a concept for handling a bit stream, where you want to control how many bits that may toggle before symbol A becomes symbol B. With a parity, you can detect a one-bit error but not perform any correction. With large hamming distances, you can detect multi-bit errors and you can correct few-bit errors.
But you are in no need of hamming distance. You aren't even sending long binary streams. As long as you have a pause between each command so you are sure the UART synchronizes on a start bit and doesn't start to listen in the middle of a character transfer because of an earlier false start bit, you get a new synchronization for each command. In that case, it's way better to use two characters than trying to separate the symbols within a single byte. The next issue here is that a UART normally don't allow you to arbitrarily adjust the number of bits for a symbol, to give you the specific number of bits you need for having a specific minimum hamming distance for a specific set of symbols. Hamming distance allows you to have an optimum symbol size. Why do you need an optimum symbol size? A two-character combo is not wasting any real bandwidth - especially if you are able to send them by console - and consumes a minimum of code. So less resources wasted, and less chance of an error. And it's so very trivial to add a new command. What do you think happens if you base your design on hamming distance, and need to add one more symbol value? You might suddenly have a too small symbol... You think two bytes are brute force. But shouldn't you think KISS? Keep It Simple Stupid - get a simple solution that handles the task. Put more thought into the task of ack/nack instead, so the sender knows if the command is processed or rejected. With a two-character solution, you must always have two bits toggled (one in each byte) to _maybe_ get into a different symbol. But with parity turned on, you will catch single-bit errors. So the trivial two-character solution would then require at least two bits in each character to be toggled. So bit position x and y in both first and second character must be toggled. That is quite good, unless you have a truly lousy connection. |
Topic | Author | Date |
Error detecting codes over RS232 | 01/01/70 00:00 | |
RE: increase the error detection capability | 01/01/70 00:00 | |
How complex? | 01/01/70 00:00 | |
Hamming distance | 01/01/70 00:00 | |
Hamming distance really not a good choice | 01/01/70 00:00 | |
KISS | 01/01/70 00:00 | |
Transfer size? | 01/01/70 00:00 | |
Transfer Size --- | 01/01/70 00:00 | |
Parameter free | 01/01/70 00:00 | |
Transfer Size --- | 01/01/70 00:00 | |
double command and CR | 01/01/70 00:00 | |
a bit more involved and better | 01/01/70 00:00 | |
Double Characters... | 01/01/70 00:00 |