Reputation: 1312
I am trying to program a manchester encoding for my arduino.
This means a 1 bit is represented by 10 and zero is represented by 01.
1111 would be 10101010 in manachester code.
My Program (C++ on Arduino) that encodes the char-array to manchester code looks like:
//Output needs to be twice as big as input
void encodeManchester(char * input, char * output, int size) {
for(int i=0; i<size; i++) {
for(int p=0; p<2; p++) {
int pos = i*2+(p);
output[pos] = 0b00000000;
for (int j=0; j<4; j++) {
int actval = input[i]>>(7-(j+4*p));
if((actval & 0b00000001) == 0b00000001) {
output[pos] = output[pos] | (0b10<<(j*2));
} else {
output[pos] = output[pos] | (0b01<<(j*2));
}
}
}
}
}
My Decoder (Python on PC) Looks like:
def manDecode(data):
ret = []
for i in range(0, len(data)/2):
ret.append(0b00000000);
for p in range(0, 2):
print(bin(data[i*2+p]));
for j in range(0, 4):
part = (data[i*2+p] >> (6-(j*2))) & 0b11
if part == 0b10:
ret[i] = ret[i] | (0b10000000 >> (j+p*4))
return ret;
But I get strange values in manchester code like: 0b11110000 or 0b1111111. where do they come from?
Upvotes: 2
Views: 3685
Reputation: 4432
You have some miss match problems in the indexing of the code between C++ and python.
First, when working with bit operation it's much better to work with unsigned types
(in this case would be unsigned char), because you avoid a lot of problem caused by sign extended when C++ need to convert to larger type.
The C++ version the only change I make was that, changing the input type to unsigned char
void encodeManchester(unsigned char* input, unsigned char* output, int size)
The python version is:
def manDecode(data):
ret = []
for i in range(0, len(data)/2):
ret.append(0b00000000);
for p in range(0, 2):
print(bin(data[i*2+p]));
for j in range(0, 4):
part = (data[i*2+p] >> (6-(j*2))) & 0b11
if part == 0b10:
ret[i] = ret[i] | (1 << (j+(1-p)*4))
return ret;
The change was in the line: ret[i] = ret[i] | (1 << (j+(1-p)*4))
check (1-p) instead of p this is needed because you are forming the number first the high nible
then the low nible
and in the first iteration with the previous version would be ret[i] | (1 << (0 + 0 * 4))
no shifting anything (changing the low nible
)
Upvotes: 3