Differences in firmware revisions of a certain free barcode reader

Copyright 2000-2002 Leonid Broukhis -- all rights reserved. Direct linking to this page from any web site, as well as not-for-profit reproduction of this page in its entirety, including this copyright notice, is hereby granted. Any other use of this information is by permission only. (Drop q's and x's before mailing.)

Rev.01 and rev.02 differ in handling of these codes

UCC/EAN-128

This EAN-128 code can be read with rev.01 (type E28), but not rev.02.

And this code can be read by both rev.01 and rev.02. Can you spot the differences? Select this paragraph and below with your mouse for the answer. The previous code starts with a StartA symbol that rev.02 does not support properly. This code starts with a StartB symbol.

The numerical UCC/EAN-128 codes (they start with a StartC symbol), sometimes found on grocery coupons, can be read by both revisions.

Extended Code39

Extended Code39 is handled properly by rev.01 (type C39, data Hi!\n); rev.02 reads it as regular Code39 (type C39, data H+I/A$J).

Longer Code39 codes cannot be read with rev.02 at all. Rev.01 reads this one OK.

This is not a valid barcode. Rev.01 does not read it. Rev.02 returns 1 to 3 characters with code 353 (octal) depending on the scanning speed.

MSI

Rev.02 read this code as type MSI, data 1234567890. Rev.01 reads it as type PLS.

Rev.02 reads MSI codes that are 3 to 14 data digits long and contain two correct check digits. Rev.01 is satisfied by the second check digit and ignores the value of the first one. It reads the code on the right as type PLS, data 12 (0 is a check digit for 123, whereas the two check digits for 12 are 55).

Also codes with 2:1 wide/narrow bar ratio can be read by rev.01 but not rev.02. The latter sometimes misreads them as arbitrary Interleaved 2 of 5 codes.

Only decimal digits seem to be read.

The shortest code (and printed with minimum ink) that can be read by rev.01 is 0 (encoded 000). This code is also the most regular readable pattern. Rev.01 reads MSI codes (and reports them as PLS) as long as 40 data digits.

Plessey

The (real) Plessey code can be read with rev.02 (type PLS, data 1234567890), but not with rev.01.

The shortest code read is 3 digits long (BarcodeMill can produce codes 100 and 001 that can be read, but not 000).

8 bit CRC (with producing polynomial x^8 + x^7 + x^6 + x^5 + x^3 + 1) is used for checking. Looks like a sloppy implementation of the CRC algorithm in the firmware.

Codes with 2:1 wide/narrow bar ratio do not seem to be read.

The longest readable code is 12 data digits.

All 16 hex digits of Plessey code are read by rev.02.

Codabar

This code can be read with rev.01 (type CBR, data 0123456789-$/:.+), but not with rev.02.

Rev.02 does not read codes with more than 15 data characters.

Rev.01 reads codes that are at least 20 data characters long.

This code can be read with rev.02 (type CBR, data -$), but not with rev.01. Rev.01 does not read codes with less than 3 data characters. Rev.02 reads codes that are as short as 1 data character.

There may be some play in attempt to reduce the misread rate of other barcodes as CBR. The two revisions differ in their preference of wide bar/narrow bar ratio and have different sensitivity to bar width variance. This code can only be read with rev.01.

Interleaved 2 of 5

Interleaved 2 of 5 (ITF) codes shorter than 6 digits, even with a valid check digit (here, the check digit for "0" is 0) cannot be read by rev.02. 2- and 4-digit long codes can be read with rev.01. Both revisions can read longer codes with or without a check digit. This could have been done to reduce the misread rate of other barcodes as ITF. (By the way, this code has the smallest number of bars of all codes that can be read.)

The following barcode can be used to test the maximum length of an ITF code that can be read. Note that the encoding for 56 is such that it starts with a stop sequence and ends with a start sequence. This makes it "self-terminating" at any position.

Rev.01 reads it completely, all 86 digits of it (I gave up trying to find out what is the longest code it can read); rev.02 reads no more than 24 digits - thus it is unusable e.g. to scan barcodes on FedEx packages that consist of 32 digits. Also it may misread the code if you move the device slowly and/or unevenly.

Code-128

Overall, rev.01 seems to handle full Code-128 completely and correctly. Rev.02, on the other hand, only seems to handle Code B (printable ASCII characters) and Code C (numbers) properly. Any non-trivial code involving Code A wreaks havoc.
Codes that start with StartA do not seem to be read at all;
Codes that contain a switch to CodeA either stop at it, or produce weird results (see below);
Codes that contain a shift from Code B to Code A and back, do not work properly. E.g. the code on the right should read a\ta\ta (a, TAB, a, TAB, a), and is read as such by rev.01; rev.02 reads it a\t\1ia (a, TAB, CTRL-a, i, a). I.e. the Shift symbol that should change the encoding for one character, works as CodeA or CodeB that switch the encoding until further notice.

This is an example of how to make rev.02 to produce control characters by fooling it (StartB Shift does the trick).

This legal Code128 barcode, encoding cat\b\b\bdog (the "\b"'s are backspaces), is properly read by rev.01, but rev.02 scans it differently every time.

Fake Code128 without a proper start character (for which the maker of the barcode reader in question likes to use a 3-letter trademarked name starting with C and prepended with a colon) is read as if StartB is implied; handling of subsequent Code128 control characters in the code differs between rev.01 and rev.02 because of differences in handling of Shift and functional symbols.

Rev.01 can read this (simulated) barcode on a California DMV renewal notice (%0<17-char VIN>A<7-char licence#>), rev.02 cannot, it's too long for it. Rev.02 only reads codes that are up to 19 letters or 38 digits long; rev.01 can read a code that is 64 digits long.