I am looking for an OEM scan engine to be used in a small handheld device. The Symbol CSE600 and SE655 look promising, but I'm having a hard time finding a distributor for small quantities. I am also yet to find a data sheet for the latter part, google search just finds the same two page spec sheet over and over again.
Small size and low energy consumption are more important to me than performance. Cheap would of course be nice as well. Any recommendations? Am I way off looking at the Symbol parts?
You are just looking for 1D codes? Are these devices "scanning" readers (i.e., do they deflect the beam and/or image a large area for "batch" decoding)? Is a "wand"-type interface acceptable (i.e., where the user must drag the scanning element across the label -- usually in direct contact)? These latter can be done for very low power budgets since only the emitter and detector need to be powered (*your* CPU does the number crunching).
Symbol is now Motogorilla, IIRC. So, the level of support you receive will tend to be driven by your quantities. If the device does what you want out-of-the-box, then all is well. OTOH, if there is some gray area in the specification, my experiences have been unsatisfying when looking for quantitative answers :-/ (i.e., they probably won't spend much time *digging* for those answers if it means they have to grep their source code, locate the original developer, etc.)
You should also think carefully about the smarts in the device. These engines tend to be all things to all people and, often, make assumptions that might not fit your needs.
E.g., if you need access to the "raw data" (in the sense of *all* the decoded characters -- including check digits, etc. -- as well as the actual symbology/code that the engine believes the label to be, then make sure you can fetch that information from the engine and/or configure it to *only* accept the codes you are interested in.
I suppose the number crunching would be feasible with an 8-bit MCU? I am planning to use a BLE module which uses the TI chipset. The chipset has an embedded 8051 (of all things), so that will be my CPU. I only need to be able to read bar codes produced by myself, so the code can be made as decoding friendly as needed.
What sort of emitter/detector pair would be suitable for this kind of application? My main concern is that it should be possible to do reading in bright daylight.
That's the distinct impression one gets when perusing the web pages.
Perhaps I should back up a bit and explain what I am trying to accomplish. The device is a simple data logger, which the user uses to collect data associated with notebook entries. The entries are free form, and may be created on the fly. For practical reasons there is no time to fumble with any sort of computer like devices during data collection.
My initial idea is to use paper and print bar codes every few lines on the notebook pages. The user swipes on the bar code to indicate that data is now collected for the particular entry, kind of a poor man's version of the Livescribe digital pen.
I'm open to suggestions though, if someone has a better idea of how to go about associating data with the entries.
Yes. The only problem with (wand-) barcode decoding is getting good "measurements" of the bar/space widths. This, of course, involves tracking *times* between video transitions (black-to-white followed by white-to-black, etc.).
These times are dependant on the dimensions of the bars/spaces, the
*differences* in dimensions and the rate at which the sensor is dragged across the image/label.
If, for example, you try to scan a commercial label, you might be dealing with dimensions on the order of 0.010 inches (or finer) and "wand rates" of 100 inches per second (or more).
[this is actually very easy to do if you are trying to screw up the device! :< ]
So, you're dealing with times on the order of 10us.
OTOH, if you create your own label (or, print a label at a lower
*pitch* == wider bars/spaces) *or* can expect the user to move the wand at a more reasonable rate, then these numbers can quickly become friendlier.
[a drawback to reduced wand speed is that the speed has a greater chance of *varying* over the length of the label... try dragging a pencil at a constant speed across a sheet of paper very slowly vs. very quickly]
To measure these widths, you want to be able to catch the times at which the video changes (black/white) using a counter-timer in the processor. Typically, you set a capture register to trigger on a white-to-black transition (whether that is a rising edge or a falling edge depends on the polarity of the signal from your sensor) and wait for the associated interrupt, store the timer's value, reprogram for the black-to-white transition, etc.
Meanwhile, you gather up contiguous pairs of times and form the difference to determine the width (of the bar or space). Then, feed these widths to something that tries to make them into characters/symbols based on the rules of the symbology you have implemented. Yet another level of software applies some meaning to this "content".
Of course, all along the way, you are looking for things that "don't look right" so you can discard bad data and try to resynchronize with (hopefully) good data.
If your usage procedure requires the user to do something explicit before starting a scan (like pressing/holding a "scan now" button), then this process is much simpler -- you
*know* when to expect a barcode to be encountered (and can shift your resources accordingly... power up the emitter, activate the interrupt routine, etc.)
No idea of what sort of capabilities it has -- especially considering its communications responsibilities (i.e., can you stop the BT portion of the code while scanning labels?)
Wands are essentially contact devices. An emitter is located proximate to the detector and "illuminates" the image (the light from the emitter reflects off the image and into the detector... the total light path might be just a dozen mm)
The "entries" are things like observations of atmospheric conditions, weights of newborn infants at a local hospital, gallons of printer's ink used per hour in the production of a newspaper, etc. ? I.e.,
*so* "unconstrained" that *you* aren't trying to enter the actual data, itself. Rather, you are just trying to provide a mechanism to allow "data entry people" to keep track of how far down the page they have transcribed the data? I.e., "I have typed in all of the information on line 47 of page 192"
If my above assessment is correct, then you need a relatively small number of "labels" per page? I.e., 50 or 100?
Do these "line number labels" need to also carry an encoding of the page on which they appear? I.e., is the first label on page 7 the
*same* as the first label on page 19? Or, is each label unique in the entire *book*? (i.e., 007_01 vs. 019_01 for the above example)
I assume you are "printing" on loose sheets and then assembling them into a bound book (or looseleaf notebook)? And, would (ideally) like to reduce the requirements (resolution) on the printer that you use for this purpose?
At the same time, you don't want the labels to take up a lot of room on the page (e.g., an inch is probably OK... but 3 inches would be a nuisance!).
And, you would expect some number of labels to be "corrupted" to some degree (liquid spills, written over, etc.)?
Finally, your device probably has limited I/O capabilities as they would increase size/bulk and/or power requirements. But, perhaps you could support an LED or piezoelectric annunciator to provide feedback to the user of a successful scan/decode?
For example:
- User presses (and holds) "scan" button prior to scan.
- Power supplied (!) to device (i.e., no power unless scanning)
- User drags device across label.
- Device scans and decodes label.
- If valid decode (checksum, etc.), device sends report via BT.
- Device receives acknowledgement (via BT).
- Device flashes LED or chirps signalling "good read".
- User releases button and device powers off.
(i.e., lack of acknowledgement tells user to try again. In the event of a duplicate scan, no harm done! :> )
[note that your device might simply *store* the successful scans and later transmit them via BT when in range of the host... not sure of your actual usage pattern. This would be easier than trying to communicate *and* scan at the same time]
Thanks for a very thorough answer, I'll try to address some of your points below. I am at a concepting state, so some of the details are still unclear. I need to do some prototyping to see what really works in practice.
The entries are steps in an animal training plan. There is some quantitative data that will be collected with the data logger, and some qualitative data that is best scribbled down with a pen and paper. A dozen or so entries per page would be plenty.
The entry ids need to be unique for a particular user, but it is not necessary to have a mapping back from entry id to notebook page. Something like the date and time of printing plus a running sequence number would generate sufficiently unique ids. Just like you suggested, my intent is to print loose sheets and assemble them into a notebook.
I can make bar code detection as easy as necessary for the device, i.e. let the user indicate when scanning starts, and make the bar codes physically sufficiently large.
My main concern going this route is the sensor. I presume one would need some optics and suitably positioned emitter and sensor to get reliable results. Are there chips/modules out there that would include both the electronics and the optics? Googling for barcode sensors is a tad frustrating, as the results just show loads of complete barcode scanners.
"Fido bit trainer" "Fido reqarded with a cookie" "Fido ran away" ...
?
As such, you (your device) is really only interested in how far through the training process "Fido" has progressed? Someone *else* might be interested to know that Fido bit the trainer -- but, they will garner that data by manually inspecting the logs (?)
Can the entries on page 1 be identical with those on page 97? Note that I am not trying to ask the question you answered immediately below... rather, just asking how many different "labels" you need to be able to decode -- *ever*!
In other words, if you only need "a dozen or so entries per page" AND the pages can be identical, then your code can simply support
12 different "symbols" and doesn't have to be more "general purpose" than that.
I.e., a typical code will encode things like the 10 digits, possibly some special characters, etc. Some might even encode the full ASCII character set. So, a conventional approach you might opt to encode the two character sequence '1' '2' for the number "12". This typically requires a lot more "bits" than the 4 bits you would need to represent "1 of 12" items.
This information can't be inferred from the "scanner"? I.e., giving each user a scanner that has his "ID" stored in the scanner...
Again, you need to figure out how much data (bits) you are trying to represent. And, if the data has to directly correspond to "ASCII characters" or if you can tolerate some sort of intermediary that maps those "codes" (values) into human recognizable form.
E.g., if you stored 10 bits in a label, you could encode 3 user id's plus a "day of year" (assuming you only "work" on weekdays) using:
value = (id * ((52+1) * 5)) + ((5 * week) + DoW)
id is [0..2], week is [0..52] and DoW is [0..4]
If, on the other hand, you use a symbology that allows "digits" to be represented directly in the label (4 bits per digit), then you might need 4 digits (16 bits) to represent the same data (1 digit ID, 2 digits for WK, 1 digit for DoW).
Ages ago, I liked HEDS-1000's but they are overkill for your purpose. (I have no idea if they are even manufactured any more)
I would look into reflective optodetectors where the emitter and detector are at ~90 degree angles to each other -- and 45 degrees to the scanning surface. If you can shrink the effective aperture size (by mounting this in a plastic case with a tiny slit for the emitter/detector to peek out of) you can get improved resolution (we're not looking for the 0.005" resolution that you might find with a commercial sensor designed to read regular barcodes!)
You can also look into commercial *wands* (HP used to make some inexpensive wands that could be used as "components" -- had some signal conditioning inside, etc.).
I don't know what your real quantities are, budget, size constraints, etc. I.e., if you're just trying to hack together a few devices using off the shelf components, a judicious supply of silly-putty and, of course, duct tape (!) then you would approach this different than if you were trying to have a custom injected molded plastic case fabricated, etc.
Try some of the reflective emitter detector pairs. Hook up to a scope or some crude signal conditioning circuitry and drag it across some black white patterns to see what sort of sensitivity (and repeatability) you can get.
While poking around looking for suitable components, I stumbled upon this page:
I am not suggesting you follow their approach but it gives you a crude idea of what's involved. In particular, their home-made emitter-detector resembles the sorts of commercial reflective emitter-detector pairs available (though the commercial devices are made without *wood*! :> )
We have used the Microscan MS-1 module. The original used a 16-bit processor, while the new version uses a 32-bit ARM. You should not forget about read performance. If you are generating barcodes with a thermal printer, then the quality of the printing varies greatly over time. We used a cheaper module initially for our product. It scanned 99.9% of barcodes without problems initially. Over time the read success dropped to less than 50%, which caused lots of problems in the overall system. The modules also became less able to read barcodes over time. Probably caused by slight shifting of the optics in the unit over time.
I didn't see your original post, so I don't know how many you are looking for, but I've been involved with barcode scanning for more than
20 years, all the way from actually building wands and decoding the barcodes entirely in software to using CCD and laser modules made by various companies.
If you're only after a few, I really think you'd be hard pressed to do better than buying a couple of cheap asian-made scanners on eBay. That way, you get the whole thing, nice-ish looking case and all. Some scanners will use virtually zero power until the scan button is pressed, but others may draw 100mA or more all the time, and you won't know which until you test them.
If you go for this idea, you'll need to look at the interface - USB may be beyond your host's capabilities, but PS/2 Keyboard Wedge (basically clocked serial) or RS-232 (probably hard to find) are easy to read.
Sorry for dr> So, the labels on each page essentially say:
Something like that, yes. The quantitive part can be e.g. timing: how long does it take for a dog to clear a particular agility obstacle.
The labels need to be unique for a particular user over time, but it does not matter if two users happen to get the same label. If the user generates labels in batches, the time of generation plus a running sequence number would be sufficiently unique.
I'll have to see what I can come up with. Regarding your other message about the wooden reader device, I came across it as well, and thought it was pretty ingenious.
I took a look and it looks pretty nice. The only drawback from my point of view is that it takes 5V, and I was hoping to get by with 3V only. Can't get it all I suppose.
Absent the good weather, I've spent much of the past week doing the same :-/ Erect a new wall in the kitchen, tonight!
Or, just a *sequence* number? (I'm just trying to shrink the number of bits in the label) Does the device that generates the "batches" have any memory (i.e., could it remember that the "most recent sequence number" for this user was ______)?
Many reflective emitter detector pairs are mounted in a similar arrangement -- except in *plastic* instead of *wood* :>
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.