Barcode-Pen mit RAW-Output

Ich habe auch schon mal mit dem Gedanken gespielt, so etwas zu bauen.

Meine Idee war, in den Akku-Halterungen selbst die Akkus zu 
identifizieren.
Dazu hätte ich mehrere grobe Ansätze. Kriterien sind:

1. Markierung soll "einfach" d.h. mit Bastler-Haushaltsüblichen Mittel 
erstellbar sein. Also etwa Drucker bzw. Labeldrucker (Brother Ptouch 
kann Barcodes als auch Symbole).

2. Markierung soll "haltbar" sein. D.h. das Merkmal muss auch 
langfristiges Hantieren überstehen. Gerade bei Papierlabels sehe ich die 
Gefahr, dass durch häufiges Berühren die Erkennbarkeit leidet. Als 
Alternative habe ich z.B. so etwas wie hier: 
http://www.pearl.de/a-PE8352-2010.shtml;jsessionid=oaaUI0D5ho9_t9nSj_Y7u 
ins Auge gefasst. (Nur gerade der erste sinnvolle Treffer bei Suche 
nach: "laserdrucker kunststoff klebefolie undurchsichtig".

3. Code soll Redundanz bzw. Prüf- oder sogar Korrekturinformationen 
enthalten.

Mit einigen Einschränkungen schienen mir 2 gleichartige Lösungen 
sinnvoll:

a) Eine Reihe von LEDs und Fotodioden oder Transistoren.
b) Eine kleine CCD-Zeile.

Beide Lösungen haben den Nachteil, dass man entweder eine handelsübliche 
Akku-Aufnahme "modden" muss oder sich eine anfertigen lassen muss. Was 
früher nicht ging, aber heutzutage mit 3D-Druck einfach und recht 
günstig geht.

Was hälst Du davon?

Die Idee das ganze in jede Ladeschale einzeln zu bauen hatte ich auch 
schon, daher zuerst die Idee mit RFID. Leider tragen diese zu dick auf. 
Im Ladegerät ist das kein Problem, aber in einer Maglite-AA oder 
ähnlichem könnte der etwas dickere Tag schon zum verhaken führen.

LED's & Photozellen schaffen wohl keine ausreichende Auflösung. Aber das 
mit der CCD-Zeile hört sich interessant an. Man könnte aber auch eine 
einzelne "Dummy-Ladeschale" machen, wo der Akku eingelegt und erfasst 
wird, und dann mit einer LED oder so eine freie Ladeschale angezeigt 
wird, wo der Akku zum laden rein kommen soll.

Die selbe Idee hatte ich schon mit einem Laser-Barcodescanner, aber da 
scheint der Laser dann ja aus dem Gerät raus, und man könnte eventuell 
reingucken -> nicht schön.

Schön wäre es trotzdem, den Barcode-Pen irgendwie zum laufen zu bekommen 
;-)

Joe F. schrieb:
> Nummer von 1 bis 50 mit Edding draufschreiben.

das ist keine Option, da in der ID diverse Sachen wie Typ, Hersteller 
und so Sachen eingebaut werden sollen um auch neue Akkus automatisch als 
Datenbankeintrag auf der SD-Karte anzulegen.
Das Ladegerät soll nämlich auch von absoluten Vollpfosten bedienbar 
sein. Akku scannen -> eventuell Reinlegen wo es leuchtet -> macht 
alleine

Marcel P. schrieb:
> ...
> LED's & Photozellen schaffen wohl keine ausreichende Auflösung.

Ich denke das könnte schon reichen. Eine AAA-Zelle ist ca. 43mm hoch 
(Wikipedia), Das wären bei einem 8-Bit-Code 5mm pro Zeichen. Es gibt ja 
3mm LEDs oder SMD. (Natürlich existiert damit dennoch eine Untergrenze 
für die Grösse).

> Schön wäre es trotzdem, den Barcode-Pen irgendwie zum laufen zu bekommen
> ;-)

Verstehe. Ob ein AVR das packt, weiss ich nicht definitiv, aber ich 
denke der sollte das können. Schon mal nach fertigem Code gesucht?

Marcel P. schrieb:
> ... da in der ID diverse Sachen wie Typ, Hersteller
> und so Sachen eingebaut werden sollen um auch neue Akkus automatisch als
> Datenbankeintrag auf der SD-Karte anzulegen.
> Das Ladegerät soll nämlich auch von absoluten Vollpfosten bedienbar
> sein. Akku scannen -> eventuell Reinlegen wo es leuchtet -> macht
> alleine

Ach so! Dann klappt meine 8-Bit-Lösung natürlich so nicht.

Wieviel Bits willst Du denn ablegen? Was für einen Code willst Du 
verwenden?

Klaus schrieb:
> Verstehe. Ob ein AVR das packt, weiss ich nicht definitiv, aber ich
> denke der sollte das können. Schon mal nach fertigem Code gesucht?

Halbherzig ja. Ich dachte daran EAN-Code zu verwenden, leider habe ich 
dazu wenig bis gar nichts gefunden, was sich mit einem 8-biter 
beschäftigt. Meist geht es in Richtung PS2-Auswertung oder eben 
Auswertung mit CCD-Zellen.

Schau mal hier rein:
http://zbar.sourceforge.net/
https://github.com/zxing/zxing

Ansonsten mal suchen nach:
Symbology Decoding Algorithm

Karl H. schrieb:
> Marcel P. schrieb:
>
>> Das Ladegerät soll nämlich auch von absoluten Vollpfosten bedienbar
>> sein.
>
> Egal was du tust, der Vollpfosten wird immer einen Weg finden wie er
> dein hübsch ausgedachtes Konzept aushebeln kann. Je 'technisch
> komplexer' du das machst, desto mehr Wege wird er finden.

Es ist ohnehin zu vermuten, dass das Konzept eines "DAU-sicheren" 
Gerätes von einem DAU stammt. :-)


Aber mal im Ernst:

@ Marcel

Einerseits schreibst Du das im Code die Informationen über Kapazität, 
Hersteller etc. vorhanden sein sollen, dann aber schreibst Du von "EAN" 
(GTIN).
Es ist aber schon klar, dass Du bei Verwendung der GTIN eine externe 
Datenbank benötigst um Kapazität etc. aus der GTIN erst zu ermitteln, 
oder? Oder die Datenbank ist (zumindest die Public Domain DBs) 
potentiell unvollständig oder falsch und daher nicht DAU-sicher. Ist das 
soweit akzeptabel für Dich?

Zxing ist wohl eher ungeeignet für einen 8-biter...

@kbuchegg
Das ist klar das es immer einen noch größeren DAU gibt. Aber dafür gibt 
es dann auch den 1200mm-Holz-Patch !
Die Zielgruppe, welche ich da im Kopf habe, sind froh um jedes Knöpflein 
das sie weniger drücken müssen.

Ich werde wohl für das Ladegerät-Projekt auf einen anderen 
Barcode-Reader mit PS2 oder Seriellem Output gehen müssen, denn ich 
möchte nicht allzuviel Zeit in den Eingabeteil investieren. Die 
Lade-Funktionen werden genug Zeit fressen.

Aber ich will den Pen trotzdem irgendwie zum laufen bekommen, auch 
unabhängig von dem Ladeprojekt.

Hm. Ich hielt es für eher unwahrscheinlich aber mit "barcode pen 
mikrocontroller decoder" fand ich folgenden Eintrag: 
https://courses.cit.cornell.edu/ee476/FinalProjects/s2004/mtf23/BarcodeScanner/index.htm

Ist das was für Dich?

@Marcel

Du hattest den Beitrag schon gelesen und auch verinnerlicht?

Klaus schrieb:
> Einerseits schreibst Du das im Code die Informationen über Kapazität,
> Hersteller etc. vorhanden sein sollen, dann aber schreibst Du von "EAN"
> (GTIN).
> Es ist aber schon klar, dass Du bei Verwendung der GTIN eine externe
> Datenbank benötigst um Kapazität etc. aus der GTIN erst zu ermitteln,
> oder? Oder die Datenbank ist (zumindest die Public Domain DBs)
> potentiell unvollständig oder falsch und daher nicht DAU-sicher. Ist das
> soweit akzeptabel für Dich?

Mit dem eintippen kann es aber auch wieder zu Bedienfehlern kommen 
(falscher Akku zugeordnet).

Hintergrund der ganzen Aktion:

Die Nummern-Zuweisung der Akkus gibt es schon und funktioniert aktuell 
so, das wenn die Akkus gekauft werden (was über eine zentrale Stelle 
geschieht) denen eine eindeutige ID gegeben wird. Protokolliert wird das 
alles momentan händisch mit Stift & Papier. Und da geschieht genug 
murks...
Wir haben Akkus die Hochstrom-geeignet sind, und andere die 
Langzeit-geeignet sind. Daher dürfen manche auch mit 2C geladen werden 
andere nur mit 0,2 C
Die Akkus werden in diversen Messgeräten, Datenloggern und Steuerungen 
als Puffer eingesetzt, welche wiederum im Versuchsbetrieb genutzt 
werden.

Das die ganze Akku-Geschichte protokolliert werden muss ist nicht meine 
Entscheidung, aber das ganze Loggen soll nun mit dem Laden kombiniert 
und  dadurch vereinfacht werden, daher ID-Barcode und Scanner in irgend 
einer Form und RFID-Tags sind schlicht zu teuer pro Akku.

wenn irgend eine andere Möglichkeit der eindeutigen Erkennung/Markierung 
günstig zu machen ist, dann bin ich dafür auch offen.

@Klaus - Der Link ist einfach genial ! Vielen Dank
@Bestromer
mit EAN meinte ich nur die Codierung EAN-13

die Nummer auf dem Akku sollte folgendermaßen aufgebaut werden:

Zahl 1 bis 6 -> ID
7,8 -> Ladestrom in 100 mA
9-12 Optionscodes

Das hier eine DB in irgend einer Form vorliegen muss, die mit die 
Nummern entsprechenden Daten zuordnet ist klar.

Marcel P. schrieb:
> @Klaus - Der Link ist einfach genial ! Vielen Dank
Bitteschön.

> @Bestromer
> mit EAN meinte ich nur die Codierung EAN-13
>
> die Nummer auf dem Akku sollte folgendermaßen aufgebaut werden:
>
> Zahl 1 bis 6 -> ID
> 7,8 -> Ladestrom in 100 mA
> 9-12 Optionscodes
>
> Das hier eine DB in irgend einer Form vorliegen muss, die mit die
> Nummern entsprechenden Daten zuordnet ist klar.

Ich feiere jetzt mal wieder meinem inneren Erbsenzähler. :-)

[Erbsenzählermodus]

Du meinst nicht EAN (die heisst inzwischen "GTIN") insofern als diese 
Bezeichnung auch den Dateninhalt benennt. Vielmehr meinst Du ISO/IEC 
15420, die sich auf die physischen Merkmale beschränkt.

[/Erbsenzählermodus]

Den Unterschied zu kennen könnte zumindest im Gespräch mit 
Einkaufsleitern/Vorgesetzten etc. ein wenig Eindruck machen. :-)


Wenn Du dem Code eine eigene Bedeutung hinterlegst die unter anderem den 
Ladestrom enthält, dann benötigst Du auch keine Datenbank. Oder verstehe 
ich da was falsch?

Klaus schrieb:
> Ich feiere jetzt mal wieder meinem inneren Erbsenzähler. :-)
>
> [Erbsenzählermodus]
>
> Du meinst nicht EAN (die heisst inzwischen "GTIN") insofern als diese
> Bezeichnung auch den Dateninhalt benennt. Vielmehr meinst Du ISO/IEC
> 15420, die sich auf die physischen Merkmale beschränkt.
>
> [/Erbsenzählermodus]

genau die meine ich...

> Den Unterschied zu kennen könnte zumindest im Gespräch mit
> Einkaufsleitern/Vorgesetzten etc. ein wenig Eindruck machen. :-)

Bei meinem Vorgesetzten hört es beim Ohmschen Gesetzt schon auf...

>
> Wenn Du dem Code eine eigene Bedeutung hinterlegst die unter anderem den
> Ladestrom enthält, dann benötigst Du auch keine Datenbank. Oder verstehe
> ich da was falsch?

Da ist richtig.. Dann ist mein Quellcode eben die "Datenbank" ;-)

Für die Thermo-Labeldrucker gibt es auch Spezialetiketten die abrieb- 
und wasserfest sind und noch dazu selbst wenn man will fast nciht wieder 
runter zu bekommen sind. Zum Beispiel zum beschriften von Chemikalien...

Bleiben noch schlecht lesende Pens oder Dreck zu lösen!

Die Idee mit dem automatischen Akku-Ladegerät gefällt mir sehr gut!

Für Programmierer, die ein paar Bitmuster der Länge 95 Bits   und Codes 
testen wollen, siehe Anhang.

Zum oben genannten EAN13-Software-Decoder:
https://courses.cit.cornell.edu/ee476/FinalProject...
Naja, ob der Softwerker Wyatt Schweizer immer wusste, was er tut?
Mit einem 16MHz-Atmega32 schafft er keine zuverlässigen Scans und
auch nur UPC-A, bei EAN13 gibt es Probleme.
Da gibt es Verbesserungspotential:
Ich würde PIN-Change-Interrupt verwenden und die Timer-Ticks messen oder 
Capture-Mode.
Bei seiner Lösung läuft der Timer viel zu langsam. Er schafft nur 2-4 
Samples pro EAN-Bit.

Because so few samples are taken, there is an interesting problem 
created by integer math; often the numbers will not work out perfectly 
and adjustments will need to be made.
...
NOTE: Due to error correction considerations, our barcode scanner will 
only read UPC-A Barcodes, which are a subset of EAN-13 Barcodes. This 
simplifies one dimension of the encoding allowing for more accurate 
error correction.
...
This immediately suggested the necessity of a state machine driven by a 
compare match interrupt on Timer1 running as fast as possible, 
effectively running as software polling.  To get optimal performance, we 
deactivated the register save on both the ISR and the state machine 
update and designed them such that they used only global variables. 
Therefore we needed only to save and restore the status register on each 
call, saving approximately 60 cycles per call.
...
Results vs. Expectations:

Our results met our expectations reasonably well.  We maybe expected a 
little more consistency with our accuracy, but we did not foresee the 
limitation on our ability to sample quickly over such small physical 
features while moving the wand at a steady but quick pace.  After 
realizing we would need to switch to the wand-based scanner, our 
expectations were lowered.  We rebounded well with our error correction 
schemes and were able to easily meet our adjusted expectations from that 
point.  If we were to approach this problem again we may consider 
writing in assembly all of the code must be executed on each read.  We 
might first analyze the situation again to be certain that code speed is 
indeed the problem, considering that there is not too much code that 
executes on each interrupt.

Conformity to standards:

We had no difficulty in conforming to the RS232 standard, as it is very 
straightforward.  We were also able to successfully implement our UPC-A 
standard barcode scanner.  Our efforts to internationalize the design 
for the EAN-13 standard, a superset of UPC-A greatly hindered our 
accuracy.  EAN-13 does not guarantee uniform parity of the left-hand 
digits, which greatly tied the hands of our error correction algorithm 
by doubling the set of valid bit strings.


Dieser Ansatz gefällt mir ganz gut:
Beitrag "Re: Kugelschreiber mit Barcodescanner bei Pollin"

EAN-13 ist (ohne leading- und trailing-zone) immer 95 bit breit:
Im Anhang die Beispiele, bei denen man genau sieht, wie decodiert wird.

Was mir zum beschriebenen Projekt noch eingefallen ist:
Barcode sollte auch von hinten scanbar sein.

EAN-Spezialist schrieb:
> Barcode sollte auch von hinten scanbar sein.

Ich frage mich sowieso ob der Aufwand lohnt. Wahrscheinlich sind 50% der 
Rundzellen mit dem Etikett nach hinten eingelegt und damit unlesbar. 
Weiterhin sollte man wissen, daß z.B. manche AA Varta-Akkus nur 1/10 mm 
dicker sind und schon OHNE Dein zusätzliches Etikett nicht in alle 
Geräte passen. Wenn Du schon per ttf den Barcode aufdruckst, sollte 
darunter als Ergänzung in kleiner Schrift eine lesbare Übersetzung dazu 
stehen. Sonst kann kein Dau das später lesen.

Wenn Du es wirklich realisieren möchtest, dann drucke Dir mit dem 
Laserdrucker über Word einige A4-Blätter mit gewünschten Etiketten in 
passender Größe aus (Every Nr ..., Zweckform usw.) z.B. 
https://www.etikettenversand.de/

Frank E. schrieb:
> Wenn die Barcodes oder QR-Codes eine Weile lesbar sein sollen (also
> professionell), so druckt man die auf Vorrat bei einem Dienstleister auf
> lösungsmittel- und wasserfeste selbstklebende Vinylfolie ... ist auch
> dünn genug.

So was Aehnliches hatt ich auch mal getestet.
Allerdings werdenAkkus beim Laden auch warm, manchmal auch sehr warm.
Da waren dann die Aufkleber sehr schnell wieder ab und ich habe das 
Ganze aufgegeben.

wendelsberg

Frank E. schrieb:
> ziemlicher "Büro-Hengste-Pfusch"
> lesbar sein sollen (also professionell),

Mein Profi >1000€ Etikettendrucker (Thermotransferverfahren) hat 
wunderschöne silberne Etiketten erzeugt. Leider haben auch diese nicht 
den Abrieb widerstanden. Daher Aufwand und Nutzen abwägen und mit 
Laseretiketten erst mal anfangen. Im einfachten Fall: Kopierpapier und 
Tesafolie drüber. Steigern könnt Ihr Euch immer. Es gibt A4- Papier-, 
Plaste-, Metall-Etiketten. Zur Übung reicht Papier+Tesa!

Frank E. schrieb:
> dir einen "richtigen" Barcodereader
> mit USB- oder MC-freundlichem PS/2-Anschluss kaufen, gibts ab 20...30
> Euro.

Schliesse mich an, bei den Dingern brauchst du nicht mal Software: die 
geben den Text des Barcodes ein, als ob er auf der Tastatur getippt 
worden wäre, auf Wunsch plus CR. Z.B. in ein Windows-Eingabefeld klicken 
und auf den Knopf der Pistole drücken, da steht der Code. Hat sich bei 
uns im Firmeneinsatz bewährt (Auftragszettel einlesen).

Die Stifte sind eigenlich längst ausgestorben, selbst mit 
Auswerteelektronik. Da hast du jemandem eine grosse Freude gemacht, dass 
er sein altes Zeug noch losgeworden ist.

Georg

Bernd R. schrieb:
> Als Etiketten sieh dir unbedingt die P-Touch-Systeme von Brother an. Hab
> mir gerade für ca. 50€ einen PT-2100 geholt, der druckt auch Barcode und
> die dünnen aber laminierten Etiketten kleben wie "Scheiße am Handtuch".

Genau das hatten meine nicht gemacht.
Kalt schon, aber bei ca. 60-80°  nicht mehr.

wendelsberg

>> kleben wie "Scheiße am Handtuch"
WO? Auch auf kleinen Radien wie bei AAA?

> Genau das hatten meine nicht gemacht.
> Kalt schon, aber bei ca. 60-80°  nicht mehr.

Alte Boeder-Papieretiketten kebten auch ewig. Kleben garantiert leider 
noch nicht, daß sie ewig LESBAR sind. Was nützt uns ein Etikett ohne 
Schrift? Wahrscheinlich ist die ganze Mühe für die Katz.