SAS hatte sich ja die Mühe gemacht, detaillierte Kommentare und Vorschläge aufzuschreiben. Auf die wollte ich noch eingehen:
SAS hat geschrieben: ↑So 25. Dez 2022, 19:36
Bei dem vorliegenden Projekt wird eine rote leistungsstarke LED, die zwar bis in den IR Bereich arbeitet, verwendet. Aber somit auch locker diverses
Lochstreifenpapier regelrecht röngt.
Hier wäre es angebracht einen IR-Filter zu setzen oder wenn man hat belichtetes, entwickeltes, Filmaterial als Filter einzusetzen.
Am besten auf beiden Seiten.
Wie schon erwähnt, trifft diese Annahme nicht zu. Die Vorwiderstände der LEDs sind so gewählt, dass die Phototransistoren nicht übersteuern, selbst wenn sie direkt (durch ein Loch im Papier) angeleuchtet werden. Von roten auf infrarote LEDs umzusteigen und spektrale Filter vor die Detektoren zu setzen, bringt keinen Vorteil.
Da der o. g. Umstand ein Problem darstellt hat, umgeht man diverse Probleme via Justage bzw. Kalibrierung über den Taster "Kalibrierung".
Das zwingt einen aber das schlechteste Lochstreifenmaterial zu verwenden um eine vernünftige Justage zu erreichen.
Da fühle ich mich, und die Intention dieses Projekts, jetzt aber sehr missverstanden. It's not a bug, it's a feature! Die analoge Detektion und die Möglichkeit, Lochstreifen-spezifisch zu kalibrieren, ist kein Workaround für irgendeinen (nicht vorhandenen) Fehler im optischen Design. Sondern sie ermöglicht erst, kontrastschwache Lochstreifen einzulesen.
Klassische optische Lochstreifenleser sind so aufgebaut, wie von Dir unten beschrieben -- mit festen Detektionsschwellen über Schmitt-Trigger. Dazu benötigen sie regelmäßig handverlesene Widerstände, die (in der Fertigung) für jeden Kanal einzeln an die unterschiedlich empfindlichen Phototransistoren angepasst wurden. Und regelmäßig können sie nur Lochstreifen lesen, die dunkel genug sind, um die in der Fertigung gewählten Schaltschwellen zu erreichen.
Diese beiden Nachteile wollte ich vermeiden. Mit einer einzigen, festen Kalibrierung für einen "üblichen", dunklen Lochstreifen erreicht man die gleiche Lesesicherheit wie ein konventioneller optischer Leser, erspart sich aber das Hand-Verlesen der Widerstände. Und mit der Möglichkeit, auf sehr helles Lochstreifenmaterial individuell zu kalibrieren, kann man Streifen lesen, die andere optische Leser gar nicht abtasten können. "Kalibrieren" klingt großartig, ist aber in 5 Sekunden erledigt: Kalibriertaster zweimal drücken und 30 cm Lochstreifen durchziehen, fertig.
Besieht man sich die Software, wird man auch gleich ein bekannten Problem erkennen.
Das Nutzen des EEPROM Datenbereich "0". ATMEL empfiehlt diesen nicht zu nutzen da unter bestimmten Bedingungen,
das konnte ich auch schon nachvollziehen, dieser auchmal überschrieben wird - und die Fehlersuche müßig ist!
Na ja, wenn mitten im EEPROM-Beschreiben der Strom ausfällt, kann Byte 00 überschrieben werden, bevor der Atmel ganz in die Knie geht. Ist mir noch nie passiert und sicher nicht die Ursache von Patricks Leseproblem. Andererseits ist es leicht zu vermeiden, indem man einfach erst ab Adresse 1 zu schreiben beginnt. Merke ich mir, danke!
Das Abspeichern der Justage/Kalibrierungswerte für die softwaremäßige Umsetzung eines Schmit-Triggers, sorgt für Latenz.
Rechenzeit/Laufzeit ...
Mein Vorschlag für die vorhandene Schaltung und Programmierung:
- Verwendung reiner IR-LED und Fototransistoren,
- keine Analogwandlung der Signale von den Fototransistoren, sondern digitale Umsetzung
- das Verwenden der Transportspur zur Abfrage der 8 Kanäle, Interrupt-gesteuert,
- verwenden einer Software-Maske entsprechend der Forderung 5- 6- 7 Kanäle,
Klar, die analoge Detektion bedeutet, dass dies nicht der schnellste aller Lochstreifenleser ist. Das steht ja auch gleich auf Seite 1 meiner Projektbeschreibung. 500 Zeichen/Sekunden, also über 1 Meter/Sekunde, schafft er aber problemlos, und mehr ist bei Handdurchzug auch wirklich nicht ratsam. (Viele klassische, motorisierte optische Leser sind übrigens langsamer.)
Die Transportspur wird natürlich zur Synchronisierung der Datenkanäle genutzt. Nicht interrupt-gesteuert, aber das ist in den 500 Zeichen/s bereits eingepreist. Und Software-Maskierung auf die gewünschte Bitzahl ist auch implementiert. Lästiger ist, dass man eine "mechanische Maskierung", also angepasste seitliche Führungen, braucht, um den Lochstreifen mechanisch zu führen. Da sind die motorisierten Leser im Vorteil, die die Transportsour (auch) zum Transport und zur Zentrierung des Streifens nutzen.
Sorry für den langen Post, aber die Missverständnisse auszuräumen, lag mir dann doch am Herzen. Wie gesagt, ich helfe bei Bedarf gern beim Troubleshooting!
