I'm cheating a little and basing my answer off of the 120 barcodes the OP provided in chat.
I'm reading the squares as bits from right-to-left, bottom-to-top, with black as
0 and white as
1. Here is the bit numbering I use:
16 15 14 13 12 11 10 9
8 7 6 5 4 3 2 1
Note that this disagrees with the silkscreened labels on the barcode reader PCB. I don't think that the hardware labels necessarily correspond to the software's processing order though.
The first thing I noticed was that bits
11 of the barcodes are just
((J - 1) >> 1) & 0x3F (where
J is the number printed on each barcode).
J-101 do not follow this pattern:
J-045: should be
0x16 (22), actually
J-093: should be
0x2E (46), actually
J-101: should be
0x32 (50), actually
There are two other patterns that I am fairly sure about though:
16 are always opposite of each other.
- Excluding bit
16, the number of
1s is always even.
Therefore I believe that bits
16 are some form of parity check.
The remaining bits,
14, seem to have an additional parity check. For all the barcodes we have, I found the following relations:
xor( b2, b3, b4, b5, b6, b7 ) = b11
xor(b1, b3, b4, b5, b8, b9 ) = b12
xor(b1, b2, b4, b5, b6, b8, b10) = b13
xor(b1, b2, b3, b5, b7, b9, b10) = b14
My best guess is that the first fourteen bits contain a ten-bit value and some sort of four-bit checksum. However, an exhaustive search of all 4- and 5-bit CRC generator polynomials has not yielded any results.