Linux Reads Bar Codes
With the wand connected to the serial port of the PC, our kernel device driver code has only to raise DTR to high to turn on the power to the wand. We can then read the modem status line called Data Carrier Detect to sample the video signal being generated by the wand. Some circuit diagrams refer to this signal as Received Line Signal Detect (RLSD). Our driver module will turn the wand power on when we install the module and leave it on. Spurious data is created when the power is toggled, so we leave power on all the time whenever the device driver is installed. We turn the wand power off only when the driver module is removed by our ``cleanup'' routine. To keep the kernel side code ``too small to cause trouble'', the device driver read function of our kernel module, when called by user-side code, simply samples the state of the DCD line and returns that state to the calling program. While the 100Hz interrupt that takes control back to the kernel finds little or nothing to do there, the delay created is uniformly merged into the delay loop of our software timer, which then appears to work just fine.
On the back cover of most trade books these days you will find a Bookland bar code for the ISBN, followed usually by what is called a price extension that states a recommended retail price for the book. When we scan a Bookland bar code and its price extension, we should find exactly 91 bars: 46 black and 45 white. The first three bars are black, white, black; each of these bars is one unit wide. These are the so-called ``left guard bars''. The next 24 bars encode the left group of six digits. Four bars are used to encode each digit in a white, black, white, black, pattern. Each of these bars can be one, two, three or four width-units wide, but the total width of the four-bar digit pattern must be exactly seven width units. The first ISBN digit, by the way, usually a ``9'', and usually printed in the clear at the left of the bar code pattern, is not represented in the bar code.
Following the six digits of the left group we find the five ``middle guard bars''. These bars are white, black, white, black, white; each one unit wide. The next 24 bars encode the right group of six digits. Again, four bars encode each digit, this time in a black, white, black, white, pattern; just the opposite of the ink pattern used for digits in the left group of six digits. The right group of six digits is followed by three unit-width ``right guard bars'', black, white, black, that mark the end of the ISBN bar code.
Following the ISBN portion of the bar code there is a large white space that provides the ``quiet zone'' in front of the price code extension. This quiet zone will be read as one large white bar. Next we see a unit-width black bar, a unit-width white bar and then a black bar two units wide. These three bars are the price extension guard bars.
Following the price extension guard bars we find the price extension itself in the form of five encoded decimal digits. For example, a book with price digits 51695 means that the book has a recommended retail price of $16.95 US. (The first five indicates that the price is in US dollars. Prices over $100 would be impossible for the present scheme to handle.) Each digit is encoded with four bars (white, black, white, black, just as in the left group of the ISBN), but here, two additional unit-width bars (white, black) are inserted into each gap between digits. These are the so-called price code extension inter digit ``delineators''. In our software that decodes bar data, we pretty much ignore both the guard bars and the inter digit delineators. Possibly the redundant bars could be used to help calibrate a scanner if that turned out to be needed. The algorithm that we use here just steps over the guard bars and interdigit delineators and works with the groups of four measured bar times for each digit. Guard bars and delineators are, of course, assumed to be present in the captured data, and so in a sense they do provide framing information, somewhat like serial line start and stop bits.
The EAN ``symbology'' used by Bookland, encodes the decimal digits 0 through 9, using four bar widths. Each bar can be one, two, three or four units wide. Each encoded decimal digit occupies exactly seven units of bar space, so the sum of the four bar widths for any digit must be seven. Scanner software that decodes the bar code will make use of that. In terms of bar widths, the code looks like that shown in Table 1.
The left group of six digits uses bar patterns from groups A and B; the right group of six digits uses patterns from group C. A bar width pattern uniquely identifies a decimal digit. In terms of bar width, as we can see here, there are just 20 distinct bar-width patterns.
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
- Optimization in GCC
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python