Differences in firmware revisions of a certain free barcode reader

(known as CueCat)
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.)
Last modified: Jan 11, 2003

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


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

Non-standard EAN-128

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.

Standard EAN-128

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

Numerical EAN-128

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). Short extended code39
Longer Code39 codes cannot be read with rev.02 at all. Rev.01 reads this one OK. Long extended code39
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. Invalid code39


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

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.

MSI with one check digit

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.

MSI 000


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.

Hex Plessey


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.

Long Codabar
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. Short Codabar
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. Flaky Codabar

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.)

ITF 00

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.

Long ITF


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.

Code128 with shift

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

Code128 with controls
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. Random barcode
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. Fake128

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. Long Code128

Neither rev.01 nor rev.02 read these codes

Non-interleaved 2-of-5 (does anybody still use it?) Non-interleaved code 2-of-5
Code 11 Code11
Code 93 Code93

Here is the list of barcode types returned by the devices.

Alphanumeric codes:

Numerical codes:

Product codes (fixed length), abbreviated type is in parentheses:

Here is a Code-128 barcode that is read by both rev.1 and rev.2, but the encoded representation of it may differ. The encoded data is "  <  =" (space space less-than-sign space space equal-sign) which is returned by a scanner either as y2n-y2n+, or (by some devices) with a slash and a comma in place of plus and minus, but I am not sure which replaces which. The only way to have these character in an encoded stream is to use a less-than or a equal sign in 3rd, 6th, 9th, etc. position within a Code-128 barcode, though. Plus-Minus

Comments, additions and suggestions to this spam-protected address(drop q's and x's)

Paperwork reduction notice: only 5 sheets of Letter-sized paper have been used to get all the data above.

Valid HTML 4.0!
hit counter