0

I need to construct the (31,26) hamming code of 0x444.

After reading Wikipedia and the algorithm shown in GeeksForGeeks I still can't understand how this works as my construction ended up different than the result of a calculator I found on the internet.

My result is: 0100 0100 0010 0010 or 0x4422 is it correct?

As I understand: P1 = Bitwise XOR(C1,C3,C5,C7,C9,C11,C13.C15,C17..) = 0

P2 = Bitwise XOR(C2,C3,C6,C7,C10,C11,C14,C15..) = 1

P3 = Bitwise XOR(C4,C5,C6,C7,C12,C13,C14,C15..) = 0

P4 = Bitwise XOR(C8,C9,C10,C11,C12,C13,C14,C15..) = 0

P5 = Bitwise XOR(C16,C17..) = 0

Another thing I can't understand.. if (31,26) hamming code is supposed to output a 31 bit result with 5 parity bits and 26 data bits.. why (7,4) hamming code transforms each 4 bits to 7 bits representation and not just 1 representation of 7 bits with 3 parity bits?

Thanks.

jjj
  • 11
  • 1

1 Answers1

0

Yes, assuming you are numbering the bits from 1 at the right-hand end, then 0x000444 is encoded as 0x00004422 for a (31,26) Hamming Code -- for an even parity code-word.

Where C1, C2, etc are bit 1, 2, etc of the code-word, and P1, P2, etc are parity bits 1, 2, etc. I think is clearer to say that:

  P1 = C1 = Bitwise_XOR(C3, C5, C7, C9, ...)

so that: 

  Bitwise_XOR(C1, C3, C5, C7, C9, ...) == 0

and so on. This is even parity.

You do not say which "calculator" you tried, but it could be that the discrepancy you see is to do with what end you number from. I note that Wikipedia gives:

If a byte of data to be encoded is 10011010, then the data word (using _ to represent the parity bits) would be __1_001_1010, and the code word is 011100101010.

which is clearly counting bits from the left-hand end.

I regret I do not understand your second question. I can say that a (31,26) Hamming Code does indeed take 26 bits of data and adds 5 parity bits to produce a 31 bits code-word. And that a (7,4) Hamming Code does likewise for 4 bits of data, 3 parity bits and a 7 bit code-word.

Chris Hall
  • 1,707
  • 1
  • 4
  • 14