Barcode Symbologies
in [Embedded]
|
Prev: Extended deadline (15 July 2010): CACS Singapore [EI Compendex,ISTP,IEEE Xplore]
Next: Spore Forming Protozoa
From: Steve Watt on 25 May 2010 18:17 In article <htf5eg$9sc$1(a)speranza.aioe.org>, D Yuniskis <not.going.to.be(a)seen.com> wrote: >tlbs101 wrote: >> On May 24, 3:06 pm, tlbs101 <tlbs...(a)excite.com> wrote: >>> On May 24, 9:36 am, D Yuniskis <not.going.to...(a)seen.com> wrote: >>> >>>> I need to pick a barcode symbology that is unlinkey to be >>>> encountered in day-to-day items to minimize conflicts. E.g., >>>> UPC is non-starter. [ snip ] >>>> But, I'd be open to other suggestions. [I can't roll my own >>>> code as I want to use COTS scanners.] >>>> Thanks! > >Rather, the problem is ensuring that the scanner doesn't >"hit" on a label that isn't "mine". This part's tough for COTS/surplus scanners. Admittedly, it's been nearly 20 years since I looked around in the market, but I couldn't find any back then that allowed suppression of the scan acknowledge "beep". My solution was to find readers that didn't have a beep and use the terminal[1]'s bell to signify a good read. >So far, it seems like Codabar fits the bill in terms of >being recognizable by OTS scanners, rare enough that it is >unlikely to "pop up" out of pure coincidence *and* tweakable >enough that I can further minimize the chance of false positives >by "abusing" certain features of the code. :-/ Codabar is still pretty common. I'm staring at a Dell machine with a M$ tax sticker on it that has two what look like Codabar lines and a 2D line. I seem to recall Codabar being very common in libraries, too. >I'll configure the scanner to tag the data with the code >used and parse that in addition to the data. I.e., if the >data isn't in the expected symbology, then it can't be >"one of my labels". Back then, I chose code 39, and used an additional check digit inside the regular scan path. [1] Yes, I'm probably showing my age. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices...
From: D Yuniskis on 25 May 2010 18:48 Hi Steve, Steve Watt wrote: >> Rather, the problem is ensuring that the scanner doesn't >> "hit" on a label that isn't "mine". > > This part's tough for COTS/surplus scanners. Admittedly, it's > been nearly 20 years since I looked around in the market, but > I couldn't find any back then that allowed suppression of the > scan acknowledge "beep". My solution was to find readers that > didn't have a beep and use the terminal[1]'s bell to signify a good > read. I've found some that will let you turn off the beep. Some will even let you *drive* the beep (^G) with an appropriate interface (i.e., duplex). If push comes to shove, I can cut the leads to the transducer (or pour epoxy on it so it can't flex audibly enough :> ). But, having the beep *in* the scanner is a real win (especially for the cordless scanners) as it is "right there" with the user (instead of at the other end of the cord) >> So far, it seems like Codabar fits the bill in terms of >> being recognizable by OTS scanners, rare enough that it is >> unlikely to "pop up" out of pure coincidence *and* tweakable >> enough that I can further minimize the chance of false positives >> by "abusing" certain features of the code. :-/ > > Codabar is still pretty common. I'm staring at a Dell machine > with a M$ tax sticker on it that has two what look like Codabar > lines and a 2D line. The Dells that I have use 7 character Code128 label for the service tag, Code 128 on the motherboard, etc. Even the XP license sticker is Code128 (two linear codes and a 2D code). I have a little Symbol PDA (Palm III with barcode reader built in) that has a handy little diagnostic application. Scan a label and it tells you the label's contents as well as the symbology used. Quite handy! :> > I seem to recall Codabar being very common in libraries, too. Yes. >> I'll configure the scanner to tag the data with the code >> used and parse that in addition to the data. I.e., if the >> data isn't in the expected symbology, then it can't be >> "one of my labels". > > Back then, I chose code 39, and used an additional check > digit inside the regular scan path. I think there's enough ways that I can "bend" the labels' format and content that I should be able to drive the probability of a "bogus read" into the mud. My biggest fear is *picking* something (i.e., without careful consideration) and discovering after-the-fact that some supplier *also* uses that and there are conflicts every 10 minutes! :< Especially after having tagged everything! :-/ > [1] Yes, I'm probably showing my age. The fact that you said *bell* (instead of *beep*) gave you away! (I think bells went away with the ASR33...) ;-)
From: VioletaPachydermata on 25 May 2010 21:03 On Tue, 25 May 2010 11:22:11 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >No. I just don't want to end up "being unlucky" and *chosing* >a symbology/format that I later discover some vendor is using >to label their parts; or their shipping containers; or their >invoices; or... Naw... that could never happen. How could you possibly think that a STANDARD format would be unique in your utilization of it? As I stated before. UID. Who cares who and where it gets used? ALL utilizations of it can be unique simply by your formatting of the data. The reading can be set up such that only that unique data structure and format gets read in, so "the vendor" with the same barcode would still NOT upset or cause a failure mode with your utilization. Pick one and use it, just use a unique data string composition. Easy, greasy, Japanezee.
From: VioletaPachydermata on 25 May 2010 21:51 On Tue, 25 May 2010 11:44:42 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >> have "SN" (Serial Number) as their first two characters? Field structures vary. Some have a <SN> 'field' followed by the actual s/n in the form <1234567> So you would read out <SN><1234567> and your computer would "see it" as something like 'comma separated ascii' or the like and load up the fields in a spreadsheet or database just fine or you could do it later and simply read it all into a single cell or field. You can segregate fields in that manner (the odd containment/segregation characters).
From: RockyG on 26 May 2010 02:31
>Hi Steve, > >Steve Watt wrote: >>> Rather, the problem is ensuring that the scanner doesn't >>> "hit" on a label that isn't "mine". >> <snip> >I've found some that will let you turn off the beep. >Some will even let you *drive* the beep (^G) with >an appropriate interface (i.e., duplex). <snip> >I think there's enough ways that I can "bend" the labels' >format and content that I should be able to drive the >probability of a "bogus read" into the mud. My biggest >fear is *picking* something (i.e., without careful >consideration) and discovering after-the-fact that >some supplier *also* uses that and there are conflicts >every 10 minutes! :< Especially after having tagged >everything! :-/ What happens if after the fact someone wants to make a 'unique' barcoding system and happens to choose (after the same thought processes) a code that is compatible with yours? Maybe it would be better to register? --------------------------------------- Posted through http://www.EmbeddedRelated.com |