| ??? 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 | 



