für ein Entwicklungsprojekt bin ich auf der Suche nach einem Single-Chip Barcode Decoder, möglichst im DIP-28 Gehäuse, innerhalb der EU zu kaufen. Eigentlich muss er nur Code-39 können ...
Google hat (für mich) irgendwier nichts Brauchbares geliefert, dershalb wäre ich dankbar für Tips (Typ und >Bezugsquelle). Danke.
Wieso nicht einfach einen billigen Mikrocontroller mit integriertem RC-Oszillator, dem Du ein Decoder-Programm einpflanzt. Atmel AVR ATMega8 z.B. kommt im DIP28 daher und ist f=C3=BCr sowas eigentlich schon total =C3=BCberdimensioniert.
die gibts sporadisch bei ebay.de billig und häufiger ebay.com etwas teuerer. Problem, daß das Datenblatt und insbesondere das Handbuch oft nichtmehr aufzutreiben ist.
Danach gabs Nachbauten: "ST9600 Decoder Chip" von "Advanced Data Capture"
formatting link
"DB2000" von "Custom Sensors Inc."
formatting link
"AT-DC-E32" von
formatting link
formatting link
"DL3 Chip decoder" von Datalogic
formatting link
Es dürfte frustrationsfreier sein sich einzelne Chips aus den USA zu beschaffen.
Sporadisch werkle ich für den GP32 an Auswertung für Lesestift. Nominell benötigt man nur 16 Bit Timer der auf Flanken Capture machen kann.
man muß aber alle Striche ins RAM einlesen: die verfügbaren 256 Byte des GP32 sind da oft schon zu knapp, 1k wären besser.
das Timing variiert erwartungsgemäß beim durchziehen:
formatting link
Man sieht da auch, daß schwarze und weisse Striche unterschiedlich "breit" sind, gibt der HP-Stift so aus. Das wird bei Codes mit mehr als 2 Strichstärken noch viel unangenehmer.
wenn man die Decodierung in HLL mit 16 Bit macht und allerlei Divisionen u.ä. hat bzw. den Datensatz mehrfach mit veränderten Parametern durchwurstelt weil man Parity-Fehler erkennt, sollte auch die Rechenleistung höher als 2,56 MHz Busfrequenz auf einer 8 Bit CPU sein. Beim GP32 kann man dann zeitweise auf 8 MHz hochschalten, etwas mehr wäre auch noch etwas angenehmer.
danke für die Tips. Am liebsten wäre mir ja ein DL1, leider nicht mehr aufzutreiben. Aber bei meinen Recherchen bin ich auf "
formatting link
" gestossen. Sieht erfolgversprechend aus, leider keine Ahnung, welche Preise die machen (man muss einen Preis vorschlagen) und ob die auch Einzelstücke versenden.
Ich habe zwei HBCR-2010 (OKI) bestellt ... mal sehen ob es was wird.
Ich lass ich gerne überzeugen, aber ich glaube du unterschätzt das. Das Dekodieren ist ziemlich komplex, wenn es eingermaßen zuverlässig klappen soll. Damit sind mittlere DSPs ganz gut ausgelastet (Bildstörungen, Verdrehung, Verzerrung, ungleichmäßige Lichtverhältnisse u.v.a). Das Signal kommt seriell aus einer Fotodiode, die manuell am (1D)-Barcode entlang geführt wird ...
Falls es da eine Software für Mega8 geben sollte, würde mich das sehr interessieren, aber ich glaube da reicht die Power nicht ...
Wie man das prinzipiell macht, ist mir schon ungefähr klar. Ich habe mal zum Zwecke der Erkenntnisgewinnung ein Realbasic-Projekt auf dem Mac programmiert, das Barcodes aus einem Bild lesen soll.
Da habe ich zunächst mit einer Handykamera einen Barcode aufgenommen und den dann in Photoshop noch ein wenig versaut (Rauschen, Verzerrungen, seitlich Abgedunkelt), damit es nicht zu einfach wird.
Dann habe ich nach und nach ganz tief in dei Trickkiste der Bildverarbeitung geriffen (lokaler Kontrastausgleich, Rauschfilter usw.). Dann die lokale Diskriminierung der Streifenbreite (zwischen den Flankenwechseln), zum Ausgleich der perspektivischen Verzerrung usw. ...
Das eigentliche Auffinden der Symbole im resultierenden String habe ich noch nicht begonnen.
Auch wenn man viele der genannten optischen Probleme bei einem Lesestift gar nicht erst hat ... wie ich das in einen ATMega8 unterbringen sollte ... schwer vorstellbar.
Maskenprogrammierte 8051-Derivate die Oki für HP hergestellt hat, sind auch in HP-Broschüren mit Oki-Logo abgebildet. HP hat erst später eigene ( Agilent-)Logos draufgemacht.
1611 PLCC, 2211 PLCC hätte ich hier auch noch einige hier.
Problem wie gesagt das "Application Manual". Ich habe hier nur das "HBCR-1000 Series Component Bar Code Readers Users Manual" für HBCR-1000,1022,1024,1025,1043,1044
Anderes Schrifttum von HP das google eventuell noch findet "Elements of a bar code System" Application Note 1013 ( d.h. Einführung in Barcodes ) "ESD Control in Portable Bar Code Readers" Application Bulletin 75
Leseköpfe mit Saphir und etwas Elektronik gäbs bei
formatting link
Die alten HP-Reflexsensoren kriegt man auch noch bei ebay.com zu moderaten Preisen ( billig waren die nie ).
Danke. ich versuche erstmal an DIP-Modelle zu kommen. PLC ist für einen Gelegenheitslöter wie mich zu fummelig. Wenn ich Nichts bekomme, komme ich gerne nochmal darauf zurück. Ein Datenblatt von OKI habe ich gefunden.
Nur zum Test ob der HBCR-1611 ( von dem ich noch einige habe ) in der Applikation tut könnte ich auch leihweise mein breadboard samt Netzeil & Stift schicken:
formatting link
Den GP32-Controller ( DIL40 links ) kann ich noch durch Drahtbrücken ersetzen, dann sendet der HBCR-1611 direkt auf die V24 zum PC wo ein Terminalprogramm zum Empfang genügen sollte. Links ist noch ein Board angeflanscht das Analogteil für die HP-Reflexoptokoppler hat, wird aber für Stift nicht benötigt, da der TTL-Ausgang hat.
ich habe so etwas letztes Jahr für einen Kunden gemacht. Dort wird ein Streifen von Hand über eine Lichtschranke geschoben. Die Andruckfedern, für den Streifen bremsen unterwegs noch den Streifen ab und dann gehts wieder schneller bis zum Anschlag. Du hast es da mit Varianz in der Geschwindigkeit und Pegel zu tun. Der Pegel ändert sich wenn du den Abstand zum Barcode änderst und das sieht dann wie eine Gleichstromüberlagerung aus und deshalb würde ich keine Hardwaretrigger mit festen Pegeln nehmen. Mein Barcode war 2 aus 5 interleaved mit CRC und Forderung war kein falsch gelesener gültiger Code und Erfolgsquote von ungeübtem Personal über 95%. Ich habe über AD Wandler in den Speicher gesampled und die Flankenerkennung schwarz/weiss über minimale Pegeldifferenz gemacht. Schwieriger wird die Strichbreitenerkennung. Du hast erst mal einen Weissen Rand und dann den Start oder das Ende des Codes. Bekannt sind: Der Strichkode für Start und Ende Kennung und dass ein breiter Streifen/Lücke 1,5 mal breiter wie ein schmaler Streifen/Lücke ist. Du kannst die Auswertung im AD-Wandler Interrupt machen aber besser ist komplett einlesen, (z.B. 2sec in Ringbuffer) dann kannst du versuchen deinen Speicher vor und rückwärz zu dekodieren. Bei der Breitenbestimmung nimmt man noch die Historie von den zuletzt dekodierten Strichen gewichtet dazu.
Das ganze läuft auf einem ARM7 und der ist nicht am Anschlag ;-)
Der Code ist nicht öffentlich und ich kann ihn dir nicht geben.
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.