Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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.

List of 13 messages in thread
TopicAuthorDate
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      

Back to Subject List