173 reputation
6
bio website
location
age
visits member for 2 years, 8 months
seen Nov 28 at 15:05

Feb
7
comment Error correction code handling deletions and insertions
@Snowball, first look on your approach tells me I would have decoding problems if corruption will hit error code suffix itself. But thanks, I have to look into this further...
Feb
6
comment Error correction code handling deletions and insertions
@JyrkiLahtonen, you get '12356FA', where 'FA' are digits added by ECC and '12356' is corrupted data. If my hypotetical ECC operates fixed-length strings, I left-pad packet to be 10+2 chars wide, and it's now '0000012356FA', feed it to ECC decoder and suppose to get '12345' in response, either padded or not. No need to track trailing zero, as padding will only add insignificant zeros. Even if I'm forced to do right-padding, I can just reverse the string.
Feb
6
comment Error correction code handling deletions and insertions
@JyrkiLahtonen, latter one :) Yes, "char", "hexdigit" and "4-bit symbol" in my case are the same. Probability of data packet having length less than five is very low, and if the only obstacle is minimal length, it can be easily circumvented by adding some number before encoding, and having that number subtracted after decoding, so this is not a problem really. Your latter scenario is actually what I want to achieve — having uniform overhead on top of encoded message, be able to reveal original message from the one corrupted by mentioned methods.
Feb
6
comment Error correction code handling deletions and insertions
@JyrkiLahtonen, no, unfortunately, I currently cannot determine insertion or deletion. Data packets formally are variable in size, but have upper length bound (10 chars) and can be zero-padded out to constant width to aid ECC.
Feb
6
comment Error correction code handling deletions and insertions
@Snowball, I'm looking for error correction, as error detection can be achieved by some kind of CRC only — this will not give me way to restore original message.