data for REPLY_RAW is incorrect

[brentswekla]

I have a card encoded in H10302 format (Wiegand 37 bit: 2 parity bits enclosing 35 bits for the card number); the card number happens to fit in 34 bits (leading bit of the card number is 0). When I read that card with the latest version of this library the event reports a 'length' of 37 bits, but the 'data' returned is a 38 bit number, and my 34 bit card number shows up in the 34 most significant bits. So the leading parity bit is cut off, and there are three trailing 0's in the data returned (at least those bits happened to be zero in this case).

Before the commit on Oct 1, this library reported a decode error, so at least I'm getting some data out now, but it's not quite right.

[sidcha]

@brentswekla, the specification says that the data bits are left justified in the data byte array. So the last few bits of the bytes boundary (if any) will be zeros. I took a quick look and cannot find anything wrong with the code as it merely breaks down the data and passes it on.

In your case case, there should be 4 bytes of card data (4x8=32bits) and a 5th byte with 5 more data bits (32+5=37 bits total). The least significant 3 bits of 5th byte should be set to zero.

If this is not what you are seeing, can you:

• generate a packet trace log (data trace if you have secure channel enabled)
• print the event struct members from the app
• if possible, print (or tell me) the card data including parity/facility that the PD is trying to send

and post them here?

[brentswekla]

Ah - I didn't realize it was left justified. With that taken into account it all works - thanks!!