??? 08/12/11 09:52 Read: times |
#183321 - Transfer size? Responding to: ???'s previous message |
Oliver Sedlacek said:
I'm all in favour of KISS. The 37 command bytes are more less arbitrarily chosen, so recoding them with a greater hamming distance is the simplest solution I can think of. Sending 2 bytes actually requires more complicated code, although it's obviously still relatively simple.
The goal is to maximise robustness in an industrial environment where ESD and fast transients might cause bit errors. As we don't know the BER, we are just looking for generic ruggedness without added cost. So, you have 37 symbols. How did you plan to go the KISS route and manage with a single transmitted character and still manage the hamming route? I'm a bit tired just now, but wouldn't you need 6+3 data bits (so potentially manually plaing with parity bit if using a PC to send)? And that design would detect and correct a single-bit error. Or detect double-bit errors if you do not try to correct. Add a global parity bit (nice to get the UART to send 10 bits) to be able to both correct one-bit errors and detect two-bit errors. There is nothing wrong with the hamming route, except that 8-bit (plus optional parity) transfers are normally preferable. |
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 |