Hallo Zusammen, ich habe nun schon eine weile die Idee im Kopf und auch schon etwas recherchiert, aber leider noch keinen konkret passenden Hinweis gefunden, ob sowas überhaupt mit derzeit erhältlichen Bauteilen im Bastelbereich(!) machbar ist. Was ich möchte: - Einen s/w QR-Code in einfachster Form, also ohne mögliche "Schnörkel" mit einem günstigen Kamera-Modul und einem ATMega oder STM32F1 Controller einlesen - Die Informationsmenge im QR Code sollte so ca. 32 Zeichen sein, was in meinem Beispiel (siehe Anhang) zu einem Bild mit 25x25 Pixel führt (Bild im Anhang ist absichtlich mit mehr Pixel um es besser zu erkennen ;-) ). Das ganze soll als Konfigurationshilfe für Spiele dienen, der QR-Code bietet hier den Vorteil, dass er sich einfach erzeugen lässt und entweder direkt auf Spiel-Bestandteile gedruckt wird, oder auf einen Aufkleber und dann auf eine Plane Fläche einen Spiel-Bestandteils. Ziel wäre dass die Hardware für das Einlesen des QR-Code bei den einschlägigen EBay oder dt. Händlern für unter 20€ zu haben ist. Die Erkennung des Qr-Codes sollte unter 3 Sekunden liegen Das Gebiet der Kameramodule ist für mich noch sehr neu, weswegen ich hier keine Erfahrung habe, worauf ich für mein Vorhaben achten sollte. Wenn ich es richtig Verstanden habe bekomme ich von solch einem Kameramodul die Pixel zeilenweise seriell oder in Pakteten zu einigen Bit geliefert. Beim einlesen der Pixel würde ich dann erst mal versuchen, zu erkennen in welchem Bereich des Gesamtbildes der QR Code liegt (Vorgabe wäre dazu, dass im gesamten Sichtbereich der Kamera nur der QR Code ist und drumherum alles weis (ich weiß, dass es der Kamera als Grau erscheinen wird). Den Code selbst würde ich dann mit 100x100px in den Speicher legen und dann diesen Speicher analysieren. µC mäßig habe ich eigentlich die ganze Palette da, also vom Arduino Nano über ATMega128A Development-Boards (Viel I/O) zum STM32F103 Blue-Pill Board. Nun die Frage, mit welchem Kamera-Modul fange ich am besten an? Und hat jemand mit dem Thema schon Erfahrung oder ggf. Links? Danke schon mal
Angehängte Dateien:
-
static_qr_code_without_logo.png
415 Bytes
Hi Hast du kein Handy? Ein QR-Code Leser war die erste und einzige App die ich mir geholt habe. MfG Spess
spess53 schrieb: > Hast du kein Handy? Ok sorry kam wohl nicht klar rüber, mir geht es nicht darum, den QR Code "irgendwie" zu lesen, sondern mit dem µC, damit ich die Information im QR Code für die Basteleien mit dem µC nutzen kann. z.B. um einfach die Spielernamen einzulesen, ohne lange mit einem Rotary Encoder die einzelnen Buchstaben einzustellen.
Das dekodieren des QR-Codes selbst ist nicht schwierig. Schwierig ist die Bilderkennung. Dafür brauch man schon ein bisschen mehr Rechenleistung. Häufig werden Neuronale Netze angewendet, die darauf spezialisiert sind, QR-Codes im Bild zu erkennen. Nachdem die Position und Ausrichtung des QR-Codes im Bild bekannt, wird es extrahiert und in eine Bitfolge umgewandelt. Die Google-Goggles-App kann jede menge Barcodes erkennen und dekodieren.
Christian K. schrieb: > Schwierig ist die Bilderkennung. Es würde mir reichen, wenn ich zusätzlich noch einen Knopf drücken muss um zu sagen, dass nun ein relativ(!) gut ausgerichteter QR Code vor der Kamera ist, d.h. im Prinzip kann dann einmalig das Bild eingelesen werden und dann verarbeitet. Ist zwar nicht gerade ergonomisch, aber für meinen Einsatzbereich ausreichend. Mir geht es auch drum erst mal zu wissen auf welche Eigenschaften ich bei den Kameramodulen achten muss. @pegel: Danke für das Video schaue es mir gleich an, auch wenn es vermutlich oversized für meine Anwendung ist, kann ich vielleicht Grundlagen-Infos rausziehen
Angehängte Dateien:
-
Gnuffel.jpg
150 KB
Hier noch ein Bild, eines meiner Spiele, wofür ich es gerne einsetzen würde. Ist ist eine Variante des Würfelspiels Kniffel und hier wäre es toll, wenn immer dran steht welches Spieler als nächstes dran ist und nicht nur Spieler 1, 2...
Einen EAN-128, GS1-128, Code-128 stelle ich mir da einfacher vor.
Für das STM32F4Discovery gibt es ein Extension Board mit Camera Interface. Da kannst du dann z.B. so eine OVF mit ~1MP dranhängen. Hier kann man dann diverse Auflösungen konfigurieren z.B. 120x160. Per DMA lassen sich dann locker 30 FPS damit einlesen. Über Schwellwertbildung lässt sich dann auch super so ein QR Code einlesen. mfg
Ein 1D-Barcode ist deutlich einfacher zu lesen. Der muss ja nicht so kurz sein wie ein typisches Warenetikett; wenn Du da einen Papierstreifen in A4-Breite bedruckst, kannst Du einen einfachen "Durchzugscanner" konstruieren, bei dem Dein Selbstbaugerät wenig mehr als 'ne Reflexlichtschranke zum Scannen benötigt. Wenn Du auf dem Papierstreifen parallel zum Barcode ein konstantes schwarz/weiß-Muster anbringst, kannst Du mit einer zweiten Reflexlichtschranke daraus sogar den Takt zurückgewinnen, um das Auslesen des eigentlichen Barcodes zur Durchzugsgeschwindigkeit zu synchronisieren.
Rufus Τ. F. schrieb: > Ein 1D-Barcode ist deutlich einfacher zu lesen. volle Zustimmung. > wenn Du da einen > Papierstreifen in A4-Breite bedruckst, kannst Du einen einfachen > "Durchzugscanner" konstruieren, bei dem Dein Selbstbaugerät wenig mehr > als 'ne Reflexlichtschranke zum Scannen benötigt. vielleicht muss ja nicht alles komplett Selbstbau sein. Einen gebrauchten 1D-Barcodescanner bekommt man bei ebay für unter 5 EUR wenn man ein wenig die Augen aufmacht. Die können meist entweder per RS232 oder als PS/2-Tastatur angeschlossen werden, beides ist mit einem µC einfach zu realisieren.
Skyper schrieb: > Für kleines Geld gibt es QR-Code Scanner auch neu mit RS232... > > https://www.aliexpress.com/item/2D-QR-Barcode-scanner-YK-M4-at-big-discount-Free-shipping-usb-interface/32719373549.html?spm=2114.01010208.3.10.EKmkqf&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_10068_5010017_10136_10137_10060_10138_10155_10062_437_10154_10056_10055_10054_10059_303_100031_10099_10103_10102_10101_10096_10052_10053_10107_10050_10142_10051_5030018_10084_10083_10119_10080_10082_10081_10177_10110_519_10111_10112_10113_10114_10180_10182_10185_10184_10078_10079_10073_10186_10123_10120_10189_142-10119,searchweb201603_13,ppcSwitch_5&btsid=a910b8c5-4fcf-43dd-8aa6-2d1e6dd2ad92&algo_expid=d81ebcf8-273e-48cb-acd6-f8c054f41784-1&algo_pvid=d81ebcf8-273e-48cb-acd6-f8c054f41784 ARGH... hat auch USB und einen virtuellen COM-Port... Sorry
Rufus Τ. F. schrieb: > Ein 1D-Barcode ist deutlich einfacher zu lesen. Ich denke darauf wird es auch tatsächlich hinauslaufen. Mir geht es vor allem drum, dass die "Lese-Einheit" möglichst kompakt ist, weswegen auch die Standard-Hand-Barcodescanner ausscheiden. Den QR-Code hatte ich deswegen ausgewählt, weil er eben schon von sich aus kompakt ist durch seine Form und per Aufkleber an verschiedenen "Spiel-Elementen" zu befestigen. Aber auch der 1D Barcode mit Taktspur ist einfach zu drucken und kommt dann eben auf längliche Aufkleber drauf und Du hast völlig recht, die Auswertung ist dann schon sehr einfach. Ich muss dann nur mechanisch schauen, wie ich sicherstelle, dass die richtige Spur an der richtigen Stelle vorbeigezogen wird.
Naja, wenn schon PS/2 für den Barcode-Leser, dann kann man da auch eine PC-Tastatur dranbasteln... Zumal ich "Barcode ausdrucken" irgendwie unhandlich für Spielernamen finde. :-)
:
Bearbeitet durch User
Gerd E. schrieb: > vielleicht muss ja nicht alles komplett Selbstbau sein. > > Einen gebrauchten 1D-Barcodescanner ... wird man aber nicht beliebige Barcodes mit der eingangs erwähnten Informationsmenge lesen lassen können. Der QR-Code da am Anfang soll 32 Byte speichern können, welcher der üblichen 1D-Barcodes kann das? Der selbstgestrickte Lochstreifenlesernachbau kann das.
Ralf M. M. schrieb: > Mir geht es vor allem drum, dass die "Lese-Einheit" möglichst kompakt > ist, weswegen auch die Standard-Hand-Barcodescanner ausscheiden. Es gibt auch Barcodescanner die für den Festeinbau gedacht sind, z.B. an Förderbändern, Selbstbedienungsterminals etc. Das sind meist kleine Kästen, so vielleicht 3x6x6cm. Z.B. sowas hier: http://www.ebay.de/itm/182598556235 http://www.ebay.de/itm/332245918859 Da kann man dann den Barcode vorhalten und er wird gescannt.
Rufus Τ. F. schrieb: > Gerd E. schrieb: >> vielleicht muss ja nicht alles komplett Selbstbau sein. >> >> Einen gebrauchten 1D-Barcodescanner > > ... wird man aber nicht beliebige Barcodes mit der eingangs erwähnten > Informationsmenge lesen lassen können. Ich habe mit Code-128 eigentlich ganz gute Erfahrungen gemacht. > Der QR-Code da am Anfang soll 32 Byte speichern können, welcher der > üblichen 1D-Barcodes kann das? Nein, 32 alphanumerische Zeichen. Das reduziert die Datenmenge schon auf 6 Bit pro Zeichen. Gute Barcode-Symbologien können das ausnutzen. Außerdem sehe ich an der Stelle noch viel Optimierungspotential: man könnte z.B. auf Groß- und Kleinschreibung verzichten, die Daten mit üblichen Komprimieralgorithmen komprimieren oder sogar nur Indexnummern im Barcode ablegen ("Spieler 17") und dann die Verknüpfung Indexnr. auf vollständigen Namen im Flash des µC ablegen. Oder in einer SD-Karte, die auf dem selben PC beschrieben wird, den man ja sowieso schon braucht um die Barcodes zu erstellen.
Noch ne ganz andere Idee: NFC-Karten oder -Token verwenden statt Barcodes. Da ist die Technik zur Auswertung in noch deutlich kleiner machbar. Auch können deutlich mehr Daten in den gängigen Karten gespeichert werden. Aber die Karten sind natürlich etwas teurer als ein gedruckter Barcode.
Erst mal Danke für die vielen sehr produktiven Vorschläge, welche ich mir in Ruhe noch anschauen werde! Aber nochmals zu dem was ich eigentlich suche, es geht nicht darum einen Spieler eindeutig zu identifizieren also kein ID-Tag, sondern es geht darum, dass ich in den Programmcode des Spieles eben nicht alle möglichen und unmöglichen Jungens und Mädels Namen aufnehmen möchte sondern beim Spiel Start wird der Namen des Spielers als Barcode eingelesen. Ich habe eigentlich überall wo ich bisher meine "Spielsachen" einsetze einen Drucker zur Verfügung. Den QR Code dachte ich mir, weil ich dann sogar ein Smartphone als QR Code Ausdruck "missbrauchen" könnte, sprich eine App nehmen welche mir auf dem Smartphone den QR Code anzeigt. Dies geht jedoch nicht mit den Reflexionssystemen sondern nur mir Lichteinfallmessenden Systemen. Also nochmals Konkret, wenn ich nun weiß, dass die neue Freundin meines Neffen Jacqueline heißt, dann kann ich schon vorab kurz eine Karte mit QR oder eben einem noch zu findenden Code ausdrucken und muss nicht mein Spielsystem anpassen. Und schon kann sie beim nächsten Spieleabend namentlich mitspielen. Ich hoffe das verdeutlicht die Aufgabenstellung nochmals
:
Bearbeitet durch User
Ralf M. M. schrieb: > Aber nochmals zu dem was ich eigentlich suche, es geht nicht darum einen > Spieler eindeutig zu identifizieren also kein ID-Tag, sondern es geht > darum, dass ich in den Programmcode des Spieles eben nicht alle > möglichen und unmöglichen Jungens und Mädels Namen aufnehmen möchte > sondern beim Spiel Start wird der Namen des Spielers als Barcode > eingelesen. > > Ich habe eigentlich überall wo ich bisher meine "Spielsachen" einsetze > einen Drucker zur Verfügung. Also wäre der Workflow: - Proband tippt seinen Namen per Tastatur in den Computer ein - Computer rechnet heftig und verbraucht dabei einen Haufen Strom - Computer schickt das Ergebnis seiner Berechnungen als Bild an den Drucker - Drucker rechnet wiederum heftig und verbraucht dabei einen Haufen Strom - Drucker bringt das Ergebnis zu Papier und verbraucht dabei super überteuerte Tinte oder gemäßigt überteuerten Toner - Proband entnimmt das Ergebnis dem Drucker - Proband fummelt den Ausdruck "passend" unter die Kamera - Zielsystem betreibt relativ aufwendige Bildverarbeitung, um den Code zu erfassen - Zielsystem entnimmt dem Code (mit etwas Glück) erfolgreich den Spielernamen - Zielsystem ordnet den Namen der nächsten freien Spieler-ID zu Also wem das jetzt nicht völlig idiotisch vorkommt angesichts der Möglichkeit: - Proband tippt seinen Namen per Tastatur in's Zielsystem ein - Zielsystem ordnet den Namen der nächsten freien Spieler-ID zu dem ist wohl nicht zu helfen. Ja klar, man muss dazu entweder eine Tastatur in's Zielsystem integrieren oder zumindest eine Anschlussmöglichkeit für eine handelsübliche Tastatur schaffen. Aber beides ist doch wohl um vieles einfacher zu realisieren als der ganze Bullshit von oben und auf Dauer im Betrieb auch sehr viel günstiger. Von der Entlastung des Probanden mal ganz zu schweigen...
Also der Programmieraufwand zur 2d-codeerkennung aus einem Kameradatenstrom dürfte die Möglichkeiten eines jeden 8-bit-AVR sprengen. Ein 2D-Barcodeleser hat neben dem Kameramodul gleich die Erkennungslogik als chip onBoard. Ich kann mich an ehemalige motorola-Scanner erinnern, die zum Einbau in größere Anlagen (förderbänder o.ä) gedacht waren, wo das Logic-board etwa das doppelte des Preises der Kameraplatine kostete. Bleibt nur der Fertigkauf eines 2d-scanners: hierbei wären Scanner(-module) unter 100euro ein echtes Schnäppchen! Ein Selbstbau auf einem STMF4 o.ä. könnte glatt die Grundlage einer Doktorarbeit in Info sein ;) Im 1D-Bereich siehts viel besser aus: wenn man altertümliches wie Code39 u.ä. weglässt und sich gleich auf Code128 bzw. vergleichbares stürzt, bekommt man auch so recht kompakte Barcodes die noch immer mit 5-Eur-gebraucht-LED-CCD-Scannern aus der Grabbelkiste in einem Rutsch gescannt werden können. Wenn du ein besonders blindes Exemplar erwischt, tuts auch ein zweizeilig geteilter Barcode der halt 2x scannen erfordert. Zumindest 15 alhpanumm. Zeichen in Code128 gepackt scannen wir problemlos mit 10 jahre alten PS/2-Scannern aus 5-35cm entfernung sehr zielsicher (99,9%?) in einem Projekt. Diese alten CCD-Scanner kannst du auseinandernehmen und deren kleines Innenleben in eine Steichholzschachtel oder in dein Gerät mit hinein umziehen. Achja: in den meissten Fällen musst du einem gebrauchten Scanner erst beibringen, Code128 zu lesen. Die Anleitung zu haben, ist also ein Muß.
c-hater schrieb: > Also wäre der Workflow: [Ausführlicher Workflow, welcher in dieser Form in der Praxis in der konkreten(!) Umgebung nicht auftritt] Es geht darum, dass es mehrere sehr verschiedene Spiele gibt aber nur wenige und selten wechselnde Spieler, d.h. die Codes (übrigens per Thermodrucker) werden selten gedruckt aber häufig eingesetzt. Beispiel: Spiel 1. Es entschließen sich 3 Spieler in der gewünschten Reihenfolge ihre Codes vor die Erkennung zu halten, währenddessen sitzen am Spiel 2 4 Spieler und machen das selbe mit Ihren Codes. Die Namen dienen dazu anzuzeigen wer an der Reihe ist und wer wie viele Punkte hat. Eine Tastatur halte ich für Oversized nur um diese wenige Zeichen zu erfassen, das einzige was ich derzeit evtl. als Alternative überlege ist per Bluetooth die Eingabe zu machen von einem Smartphone aber dann ist wieder eine Abhängigkeit mehr drin.
Wie wäre ein biologischer Scanner für verschiedene Spieler? z.B. ebay 142059094819 Funktionieren erstaunlich gut. Wenn du allein spielst geht auch Zeigefinger gegen Mittelfinger ;)
Andy schrieb: > Diese alten CCD-Scanner kannst du auseinandernehmen und deren kleines > Innenleben in eine Steichholzschachtel oder in dein Gerät mit hinein > umziehen. Hört sich sehr interessant an, muss mich mal auf die Suche machen
pegel schrieb: > Wie wäre ein biologischer Scanner für verschiedene Spieler? Nochmal, es geht nicht darum einen Spieler zu Identifizieren, das geht auch per NFC, sondern ich will einfach nur den Namen das Spielers anzeigen wenn er dran ist und auf der Punkte-Liste, mehr nicht. Und suche eben ein System mit welchem ich auf einfache Art und Weise diesen Namen ins System bekomme, möglichst in einer Form, dass die Quelle des Namens mit Hausmitteln erstellt werden kann, wobei bei ich einen Drucker nebst PC als Hausmittel ansehe in der Umgebung in welcher die Spiele zum Einsatz kommen.
Ralf M. M. schrieb: > Nochmal, es geht nicht darum einen Spieler zu Identifizieren, das geht > auch per NFC, sondern ich will einfach nur den Namen das Spielers > anzeigen wenn er dran ist und auf der Punkte-Liste, mehr nicht. ja, das habe ich schon so verstanden. > Und suche eben ein System mit welchem ich auf einfache Art und Weise > diesen Namen ins System bekomme, möglichst in einer Form, dass die > Quelle des Namens mit Hausmitteln erstellt werden kann, wobei bei ich > einen Drucker nebst PC als Hausmittel ansehe in der Umgebung in welcher > die Spiele zum Einsatz kommen. Ich behaupte mal wo ein PC mit Drucker "Hausmittel" ist, ist auch ein SD-Card-Leser nicht weit. Also bei neuem Mitspieler: - SD-Karte in PC - Texteditor auf - Neuen Namen mit Zeilennummer davor in die Liste eintragen - Speichern, Ordnungsgemäß unmounten - SD-Karte ins Spiel stecken Jetzt kannst Du verschiedene Varianten machen: 1. 1D-Barcodes der Spieler vor einen kleinen Barcodeleser halten. Die Barcodes müssen jetzt nur noch die Spielernummern enthalten, also "12", "4", "23" etc. und sind damit sehr klein 2. Die Nummern der Mitspieler im Spiel selbst einmal per Drehencoder oder Nummernblock eingeben 3. Auf die Nummern ganz verzichten und im Spiel einfach alle Namen anzeigen, Auswahl per Drehencoder. Wer mitspielt wird einmal per Druck auf den Drehencoder ausgewählt.
Man kann natürlich auch einfach für jede Spielerposition einen (µ)SD Kartenschlitz vorsehen. Nach Abschluss des Spiels kann dann sogar jeder seine Statistik mitnehmen. Und so teuer sind die auch nicht mehr.
Ralf M. M. schrieb: > Es geht darum, dass es mehrere sehr verschiedene Spiele gibt aber nur > wenige und selten wechselnde Spieler, d.h. die Codes (übrigens per > Thermodrucker) werden selten gedruckt aber häufig eingesetzt. Auch dann ist eine (wie auch immer realisierte) Tastatur für jedes Zielsystem immer noch die mit weitem Abstand beste Lösung. Unter den gegebenen Randbedingungen würde man nämlich einfach den Zielsystemen einen Datenbank mit Nutzernamen verpassen, die (da es nach deinen Angaben nur wenige sind und obendrein selten wechselnd) problemlos lokal auf den Zielsystemen gehalten werden können. Mit einer Tastatur könnte man nun sehr komfortabel aus den verfügbaren Benutzernamen wählen und auch neue Benutzer ohne jegliche Umstände anlegen. Das einzig Böde wäre nur, das die Neuanlage eines Benutzers für jedes Spiel wieder erneut erfolgen müßte. Aber auch das ließe sich sehr viel effizienter lösen als nach der von dir angedachten "Lösung". Nämlich: man schafft eine Möglichkeit um die "Spiele" untereinander zu verbinden, so dass sie ihre neuen Erkenntnisse bezüglich der Benutzerdatenbank einfach mal weiterreichen können. Und lustigerweise muss man dazu nichtmal irgendein aufwendiges Netzwerkprotokoll oder sowas beschäftigen. Man würde statt dessen einfach jedem Spiel die Fähigkeit geben, virtuell die Tasten eines jeden anderen Spiels zu drücken, sprich: ein replay der Anmeldung des Benutzers abzuspielen.
Gerd E. schrieb: > Ich behaupte mal wo ein PC mit Drucker "Hausmittel" ist, ist auch ein > SD-Card-Leser nicht weit. Hmm, das ist auf alle Fälle eine gute Alternative zumal ich einen USB SD-Card-Leser ja immer mitnehmen kann und es diese sogar für USB OTG gibt. pegel schrieb: > Zum Beispiel einen Sack voll davon: > > ebay 162502787229 und dann sind die ja auch wirklich günstig und vor allem auch einfach einzubinden. Danke für diese weiteren Ideen
Ralf M. M. schrieb: > Nochmal, es geht nicht darum einen Spieler zu Identifizieren, das geht > auch per NFC, sondern ich will einfach nur den Namen das Spielers > anzeigen wenn er dran ist und auf der Punkte-Liste, mehr nicht. Nimm ein Bluetooth Module und Programmiere eine kleine Smartphone App, welche die Spielernamen deinem Spiel beibringt, die können dann ja persistent in einem EEPROM abgelegt werden.
c-hater schrieb: > Unter den gegebenen Randbedingungen würde man nämlich einfach den > Zielsystemen einen Datenbank mit Nutzernamen verpassen Ja, diesen Gedanken werde ich nun aufgreifen für meine weiteren Überlegungen und diese Datenbank in Form einer SD Karte nutzen, bzw. natürlich einer Textdatei auf dieser. c-hater schrieb: > Auch dann ist eine (wie auch immer realisierte) Tastatur für jedes > Zielsystem immer noch die mit weitem Abstand beste Lösung. Ja, diese gibt es tatsächlich eigentlich immer, meist als Rotary-Encoder mit zusätzlich Druckschalter oder mind. 3 Tastern für ein Menü. Und da in der Datenbank, dann nur noch wenige Namen sind, ist dies eine Möglichkeit. Ich hatte die nur zuerst verworfen, weil wenn ich sie in die Firmware genommen hätte, dann hätte ich da einige zig Namen aufnehmen müssen und dann wäre die Auswahl zu langwierig, aber an SD Karten hatte ich gar nicht gedacht
Christian K. schrieb: > Nimm ein Bluetooth Module und Programmiere eine kleine Smartphone App, Ja das ist Plan-B
Einen QR-Code zu lesen, auch wenn das Bild perfekt vorielgt, ist nicht-trivial, da steckt ein ordentlicher Sack Mathematik drin. Das ist vor Allem durch die eingebaute Fehlerkorrektur nach Reed-Solomon bedingt ... Es gibt fertige OEM-Module, die per serieller Schnittstelle die gelesenen Daten ausliefern.
Frank E. schrieb: > Einen QR-Code zu lesen, auch wenn das Bild perfekt vorielgt, ist > nicht-trivial Ja ich denke, dass ich hier zu naiv an die Sache herangegangen bin, aber dank' der Unterstützung hier im Forum werde ich es nun in Richtung SD Card durchdenken
Also normale 1D Barcodes sind da generell aber trotzdem die interessantere Wahl. Wenig aufwand, leicht auszulesen. Allerdings lohnt es sich dann nich mehr so wirklich da was selbst zu bauen. Selbst professionelle Modelle bekommst du für um die 30€: https://www.michaelkrug.de/ccd-led-hand-barcodeleser-barcodescanner und für deine zwecke sollte das wirklich völlig ausreichen.
Ralf M. M. schrieb: > den QR Code "irgendwie" zu lesen, sondern mit dem µC, damit ich die > Information im QR Code für die Basteleien mit dem µC nutzen kann. Schließ einen passenden Barcodescanner an die serielle Schnitte des uC an.
Lothar M. schrieb: > Schließ einen passenden Barcodescanner an die serielle Schnitte des uC > an Leider habe ich noch keinen für meine Aussgangsfrage passenden Barcodescanner gefunden, denn er sollte ja sehr klein sein ... und in dem Moment als ich es aus meinem Post zitieren möchte fällt mir auf, dass ich in die selbe Falle getappt bin wie viele andere TOs auch und nicht alle Anforderungen aus dem Kopf in den Post gebracht habe. Ich war mir sicher, dass ich geschrieben hatte, dass das ganze sehr kompakt sein soll, deswegen ja die kompakten Kameramodule, also die "Leseeinheit" max. 5x5x5cm³ Also ein Sorry an alle, welche nun Tipps geben haben, welche auf meinen fehlenden Angaben beruhten :-/
:
Bearbeitet durch User
Frank E. schrieb: > Einen QR-Code zu lesen, auch wenn das Bild perfekt vorielgt, ist > nicht-trivial, da steckt ein ordentlicher Sack Mathematik drin. Das ist > vor Allem durch die eingebaute Fehlerkorrektur nach Reed-Solomon bedingt > ... Die Mathematik lässt sich reduzieren indem man RS einfach nicht nimmt. Also Micro-QR-Code plus Kamera plus ATMega/STM32F1 - Reed-Solomon-Codierung.
Ich dachte die SD Variante ist schon beschlossen? Falls nicht, es gibt fertige QR Scanner Module z.B.: http://winson.gmc.globalmarket.com/products/details/small-size-2d-barcode-scanner-reader-data-collect-engine-module-2680724.html Ist ja eigentlich einem Fingerabdruck Sensor recht ähnlich. Vielleicht gibt es da einen Ansatz.
Wie wäre es mit Chip-Tan-ähnlicher Übertragung? Also Zeit als 2. Dimension. Ein paar Photodioden/Reflexlichtschranken parallel nebeneinander. Die erste liest nur die 'Clock', also ständig an/aus. Auf den restlichen Positionen wird synchron dazu der Datenstrom -passend codiert- eingelesen. Generierung des Codes entweder am Smartphone, dort als Folge von schwarzen/weißen Balken, die sich mit der Zeit ändern. Oder am PC ähnlich anzeigen, wenn du das Spiel vor den Monitor halten kannst. Oder am PC generieren, ausdrucken (ein Muster pro Zeile) und den Streifen dann am Sensor vorbeiziehen. Geschwindigkeit sollte dank der 'Clock'-Balken nicht so kritisch sein.
pegel schrieb: > Ich dachte die SD Variante ist schon beschlossen? Ja ist sie und die Module zum Testen sind auch schon da, nur fehlt im Moment die Zeit Aber da sich hier noch einige die Mühe gemacht haben mir weitere Tipps zu geben, werde ich natürlich gerne weiter Antworten, alles andere ist in meiner Sicht unhöflich und as möchte ich nicht
Markus M. schrieb: > Wie wäre es mit Chip-Tan-ähnlicher Übertragung? > Also Zeit als 2. Dimension. Es geht hier nicht darum Daten zu übertragen, sondern mehr ausgedruckte konstante Werte (z.B. Spielernamen) ins System zu übertragen. Es geht ausdrücklich um gedruckte Daten, also auch kein NFC etc. Aber wie oben geschrieben ist die SD Card eine gute Alternative. (Sobald mein "Spiele-System" etwas mehr Form angenommen hat, werde ich es hier im Forum mal vorstellen, was aber sicherlich noch einige Wochen dauern wird)
Ralf M. M. schrieb: > Markus M. schrieb: >> Wie wäre es mit Chip-Tan-ähnlicher Übertragung? >> Also Zeit als 2. Dimension. > > Es geht hier nicht darum Daten zu übertragen, sondern mehr ausgedruckte > konstante Werte (z.B. Spielernamen) ins System zu übertragen. > Es geht ausdrücklich um gedruckte Daten, also auch kein NFC etc. Genau. Funktioniert ja wie ein QR-Code. Nur, dass du keine zweidimensionale Grafik aus einem Foto identifizieren musst, sondern der Code am Sensor (nur eine Zeile Fotozellen) vorbeigezogen wird. Oder eben automatisch nacheinander abläuft, wenn ein Smartphone zur Verfügung steht. Vielleicht für das nächste Projekt :) > Aber wie oben geschrieben ist die SD Card eine gute Alternative. Das ist aber dann schon ein stück weg von 'gedruckt' ;) > (Sobald mein "Spiele-System" etwas mehr Form angenommen hat, werde ich > es hier im Forum mal vorstellen, was aber sicherlich noch einige Wochen > dauern wird) Ich bin gespannt :)
Markus M. schrieb: >> Aber wie oben geschrieben ist die SD Card eine gute Alternative. > Das ist aber dann schon ein stück weg von 'gedruckt' ;) Ja das stimmt. Anfangs wollte ich es an allen Orten machen können, wo ich die Systeme normalerweise einsetze und ich weiß dass dort immer ein PC/Notebook vorhanden ist und bin altmodisch davon ausgegangen, dass da auch ein Drucker ist, deswegen die Anforderung gedruckt. Aber zum einen habe ich inzwischen bemerkt, dass Drucker gar nicht mehr so verbreitet sind, deshalb fand ich dann die Idee mit der SD Card sehr gut, da ich einfach einen Adapter SD auf USB mit dabei haben muss und dann die Namensliste einfach in z.B. Notepad ergänzen kann und die SD Card dann wieder ins Spiele System stecken
Es gibt ganz niedliche kleine OEM-Module .... Dieses hier habe ich für Tests mit einem Bon-Leser im Einsatz, kostet ca. 30 Euro. https://ae01.alicdn.com/kf/HTB1abuLQVXXXXcWXFXXq6xXFXXXV/CHEAP-LV12-1D-CCD-High-Sensitive-OEM-Barcode-Reader-Scanner-Module-with-RS232-USB-KB-interface.jpg
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.