Hallo, nachdem ich in meinem Projekt Modellfahrzeug Erkennung noch keine Zufriedenstellende Lösung gefunden habe, hoffe ich hier nochmals auf Ideen. Die Anforderung: - Eindeutige Erkennung von Modellfahrzeugen - Die Fahrzeuge sind beim überfahren des Sensors recht langsam - Aktuell Tendiere ich zu Infrarot - Sender Kompakte Bauform (relativ) - Betrieb mit 5V, da in den Modellfahrzeugen vorhanden - Reichweite < 10cm mehr als ausreichend - AVR Controller und mit avr-gcc Programmierbar, da ich alle Tools da habe Hintergrund: - Fahrzeug fährt auf eine Fläche und soll dabei erkannt werden. - Jedes Fahrzeug hat eine eindeutige ID hinterlegt, die vom Sender im Fahrzeug zum Empfänger im Boden übertragen wird. - Als ID dachte ich an ein einfaches Protokoll, 32 Bit Daten. => 24Bit ID, 8 Bit Prüfsumme. Wenn es sein muss noch ein 0x55 davor um ein "Einschwingen" zu erleichtern. Mein Aktueller Gedanke, wobei ich bezweifle dass dies Funktioniert... Sender: - Attiny 45 oder so - IR Sendediode mit Kathode und Widerstand an den PWM Pin. - PWM im CTC Modus und ca 38KHz, zur Träger Signal Erzeugung. - IR Sendediode mit Anode an einen zweiten PIN, bevorzugt Hardware UART ?! => Die Daten am zweiten PIN, vom UART, werden somit Automatisch mit 38khz moduliert - Die Eindeutige ID steht im Flash und wird beim Programmieren bereits festgelegt. - Senden der 32 Bit, 1 ms Pause, 32 Bit senden, 1 ms Pause, usw... Empfänger: Ich habe am Empfänger IC noch einen Hardware UART RX frei. Dort schließe ich einen TSOP IR Empfänger mit 38khz an. Mit etwas Glück müsste ich doch jetzt schon die Daten Empfangen können ?! Als Baudrate müsste 2400Baud, ggf. 4800 Baud möglich sein ? Oder hat jemand eine bessere Idee? Achja, der Empfänger ist ziemlich voll mit Interrupts, wenn es komplexer mit Auswerten wird, muss eben ein kleiner ATMega davor und den Empfang Regeln und an den Hauptprozessor weiter leiten. Aber vielleicht denke ich auch zu kompliziert und hoffe auf Eure Ideen :-) Gruss Juergen
:
Bearbeitet durch User
32bit bei 4800bd brauchen so knapp 7ms. Wie schnell ist das Auto, bzw. kann der Sender den Empfänger so lange bedienen? Wie gehst du damit um, das ein Auto evtl. nicht in der Spur ist?
Die TSOP Chips benötige eine relativ lange Zeit zum Einschwingen. Du
musst also zuerst einige Füllbytes senden und dass die eigentlichen
Nutzdaten.
Bei den Modellen für TV Fernbedienungen habe ich ausserdem beobachtet,
dass sie nach dem Einschwingen noch auf sehr schwache Signale reagieren.
Das könnte bei Dir zum Problem werden, wenn der Empfänger unerwünscht
auf Fahrzeuge reagiert, die längst woanders sind.
> Als Baudrate müsste 2400Baud, ggf. 4800 Baud möglich sein ?
Ja, wenn du einen dazu passenden TSOP auswählst. Schau ins jeweilige
Datenblatt, da steht drin, welche Anforderungen an das Nutzsignal
gestellt werden.
Jürgen S. schrieb: > - Fahrzeug fährt auf eine Fläche und soll dabei erkannt werden. > - Jedes Fahrzeug hat eine eindeutige ID hinterlegt, die vom Sender im > Fahrzeug zum Empfänger im Boden übertragen wird. > - Als ID dachte ich an ein einfaches Protokoll, 32 Bit Daten. > => 24Bit ID, 8 Bit Prüfsumme. Willst du 16 Millionen Fahrzeuge unterscheiden? > Wenn es sein muss noch ein 0x55 davor um > ein "Einschwingen" zu erleichtern. Das machen die Protokolle anders. > Mein Aktueller Gedanke, wobei ich bezweifle dass dies Funktioniert... > Sender: > - Attiny 45 oder so > - IR Sendediode mit Kathode und Widerstand an den PWM Pin. > - PWM im CTC Modus und ca 38KHz, zur Träger Signal Erzeugung. OK. > - IR Sendediode mit Anode an einen zweiten PIN, bevorzugt Hardware UART > ?! Muss man nicht, das kann man locker als Soft-UART in der ISR machen. > - Die Eindeutige ID steht im Flash und wird beim Programmieren bereits > festgelegt. > - Senden der 32 Bit, 1 ms Pause, 32 Bit senden, 1 ms Pause, usw... Trivial. > Ich habe am Empfänger IC noch einen Hardware UART RX frei. > Dort schließe ich einen TSOP IR Empfänger mit 38khz an. Geht so direkt möglicherweise nicht, die üblichen Empfänger sind für UART-Datenströme eher untauglich. Man sollte auf die bestehenden Kodierungen zurückgreifen. > Mit etwas Glück müsste ich doch jetzt schon die Daten Empfangen können > ?! > > Als Baudrate müsste 2400Baud, ggf. 4800 Baud möglich sein ? AFAIK geht es bei den Dingern eher in Richtung 1000Bit/s. > Oder hat jemand eine bessere Idee? > Achja, der Empfänger ist ziemlich voll mit Interrupts, Und was machen die? > wenn es komplexer > mit Auswerten wird, muss eben ein kleiner ATMega davor und den Empfang > Regeln und an den Hauptprozessor weiter leiten. Braucht man bei gescheiter Programmierung eher nicht. Der IRMP ist recht peppig und braucht nicht allzuviel CPU-Power. Wenn man den per Konfiguration auf ein Protokoll abspeckt, braucht der auch nicht viel Flash-Speicher. Den IRSND gibt es als Gegenstelle (Sender), fertig. > Aber vielleicht denke ich auch zu kompliziert und hoffe auf Eure Ideen Nutze bestehende Projekte und erfinde das Fahhrad nicht neu.
Falk B. schrieb: >> Achja, der Empfänger ist ziemlich voll mit Interrupts, > > Und was machen die? Bereits viel zu viel. Alle Timer und Co sind schon belegt und das sind Module die auch in anderen Applikationen genutzt werden. Irgendwann ist einfach Schluss und einen Code mit aller Gewalt tot Optimieren halte ich für Unsinning. Mir ist Code Lesbarkeit und Wiederverwendbarkeit wichtiger. Deswegen, ist es mit einem Hardware UART zu erschlagen, ok, alles andere wird zusätzliche Hardware. Vielleicht noch als Info: - IR Empfänger bräuchte ich, nach aktuellem Stand, maximal 30 Stück, Sender eher deutlich mehr. > >> wenn es komplexer >> mit Auswerten wird, muss eben ein kleiner ATMega davor und den Empfang >> Regeln und an den Hauptprozessor weiter leiten. > > Braucht man bei gescheiter Programmierung eher nicht. Auch da ist Irgendwann Schluss, wie gesagt. > > Der IRMP ist recht peppig und braucht nicht allzuviel CPU-Power. > Wenn man den per Konfiguration auf ein Protokoll abspeckt, braucht der > auch nicht viel Flash-Speicher. Den IRSND gibt es als Gegenstelle > (Sender), fertig. Viel zu viele Interrupts, laut Beschreibung zwischen 1000 und 2000 / Sekunde. Flash ist nicht das Problem, aber das bringt die anderen Interrupts vom Timing durcheinander. Und da ist das Timing Kritisch. Aber den Ir EMpfänger mit IRMP in einen kleinen ATmega / ATtiny, der das ausgibt als Seriellen Datenstrom ist nicht das Problem. Das kann IRMP ja wohl schon von Haus aus, bzw, einfach ein zu bauen. UART über so 40cm Leitung bei 9600 Baud oder so, brauch auch keine Pegel Wandler. 5V vom Hauptboard, mit UART ist soweit schon vorgesehen. - Zur Frage wieso 32 Bit. Zum einen möchte ich das Aufteilen in Hersteller und Laufende Seriennummer Und einfach Reserve, da ich es nachträglich nicht ändern kann, ohne Existierende Sender im Fahrzeug Inkompatibel zu machen. Angedacht etwa so: - 8 Bit Hersteller - 16 Bit Laufende Nummer - 8 Bit Prüfsumme Klar kann man an der Prüfsumme etwas sparen... Und so nebenbei, alleine ich habe 20 Fahrzeuge ;-) - Die Fahrzeuge fahren halbwegs mittig über die Fahrbahn. IR hat eine gewisse Streuung und daher sollte so 3cm links rechts kein Problem sein. Andere Lösungen mit NFC und Barcode usw sind bereits vom Tisch. Das möchte ich nicht nochmal durchgehen, da bitte ich um Verständnis. - Würde ich nun IRMP nehmen (Hatte ich gar nicht mehr auf dem Schirm) Das Samsung 32 Protokoll wäre ja eine gute Wahl scheinbar. ca 80ms für die Übertragung, alle 47ms Wiederholung senden. - Nicht zu vergessen, mache ich die Erkennung auf eine Extra Hardware, kann ich das Protokoll und Schaltung etc "offen legen" und so kann sich das jemand auch einfach Kompatibel nachbauen :-) Danke mal soweit. Ich sehe mir mal IRMP an. Baue mal einen einfachen Versuch auf und werde Berichten. Das wird aber sicher etwas dauern, da ich nur Basteln kann, wenn ich Zuhause bin. Gruss Juergen
Jürgen S. schrieb: > Angedacht etwa so: > - 8 Bit Hersteller > - 16 Bit Laufende Nummer > - 8 Bit Prüfsumme Meine Empfehlung wäre das extended NEC-Protokoll. Hat: 16 Bit Adresse, 8 Bit Code + 8 Bit invertierter Code als Prüfbyte. Das Prüfbyte kontrolliert IRMP bereits selbst, das sieht die Anwendung gar nicht. IRSND auf der Senderseite erstellt auch für das Senden selbsttätig das Prüfbyte. Du brauchst also nur reinzustecken: 16 Bit lfd-Nummer -> Adresse 8 Bit Hersteller -> Kommando-Code und am Ende kommen genau diese 16 + 8 Bit wieder raus. Okay, mit SAMSUNG32 wäre der Frame ca. 4,5msec kürzer wegen dem abgespeckten Startbit, geht also auch. Dann musst Du das mit dem Prüfbyte halt selber machen. > Und so nebenbei, alleine ich habe 20 Fahrzeuge ;-) Sind ja gerade mal 5 Bit. Meinst Du wirklich, Du brauchst 65536 laufende Nummern und auch noch 256 verschiedene Hersteller?
:
Bearbeitet durch Moderator
Hast du schon eine ganz andere Lösung mit RFID in Betracht gezogen? So ein RFID-Tag zum aufkleben kostet ein paar cent und eine Leseeinheit gibts auch spottbillig. Würde sich evtl lohnen, da mal für nen Fünfer was zu bestellen und zu testen.
Wie bereits mehrfach erwähnt, ist RFID, Barcode und Co bereits aus dem Rennen. Das möchte ich hier nicht nochmals durchgehen. Gruß Juergen
Dann solltest du im Eingangspost auch gleich schreiben, dass IR die ausschließliche Lösung ist, die du verfolgen willst. Denn da klingt das noch ganz anders.. "Aktuell TENDIERE ich zu Infrarot"
Jürgen S. schrieb: > Andere Lösungen mit NFC und Barcode usw sind bereits vom Tisch. > Das möchte ich nicht nochmal durchgehen, da bitte ich um Verständnis. Daher hatte ich das in einem späteren Post nochmals präzisiert. Was in meinen Augen dagegen Spricht: (Nur zur Info, wie gesagt, das ist vom Tisch) Ich habe hier schon längere Diskussionen geführt in Foren und mit Leuten die NFC und Barcodes Professionell Nutzen. Sollte IR nicht wie gewünscht klappen, kommen Barcode und NFC wieder in die Auswahl. Im Übrigen habe ich NFC Tests hier liegen. Die Reichweite war aber eher Bescheiden. Barcode: - zu Empfindlich - Verschmutzungs Empfindlich - Erforderte "Exakte" Überfahrt, je nach Barcode auch entsprechende Ausrichtung Leser zu Barcode etc - Lesegerät zeigt nach oben, und daher auch der Laser (LED Leser sind Erfahrungsgemäß nix), Gefahr für die Augen. - Sehr lange Lesezeit - Die Laserscanner sind relativ teuer und eher schwerer zu Adaptieren - muss im "Sichtbereich" unterm Fahrzeug sitzen und an allen Fahrzeugen etwa gleich ausgerichtet sein und auf einer ebenen Fläche. + keine Stromversorgung im Fahrzeug notwendig NFC: - knappe Reichweite - müssen ziemlich gut Ausgerichtet das Lesegerät überfahren, sonst starke Einschränkung der Reichweite - Die Fahrzeuge sind Teilweise aus Metall, dämpfen daher zusätzlich den Empfang - der NFC Chip muss Parallel zur Fahrbahn sein, sonst wieder starke Reichweiten Reduktion + keine Stromversorgung im Fahrzeug notwendig IR: - Benötigt Spannungsversorgung. - Beeinflussung durch Lichtquellen Möglich. + muss nur ungefähr den Boden treffen in der Mitte des Fahrzeugs + Relativ Schmutz unempfindlich + Einfache Montage, da Position im Fahrzeug relativ Unkritisch, kann auch oben im Fahrzeug sitzen und vor dem Fahrzeug den Boden treffen Vielleicht noch zur Info, hat ein Fahrzeug keine Automatische ID, kann der Benutzer diese, wie aktuell jetzt auch, in einer Android APP Auswählen. So, sobald ich ein paar Testergebnisse habe, melde ich mich wieder. Gruss Juergen
Jürgen S. schrieb: > - Beeinflussung durch Lichtquellen Möglich. Das sehe ich nicht so. Lichtquellen stören eigentlich kaum bis gar nicht, IRMP ist da ziemlich zuverlässig, was Störquellen angeht. P.S. Man kann auch noch einiges durch die Wahl der IR-LED optimieren. Diese gibt es mit großem als auch mit stark eingeschränktem Streuwinkel, bis runter auf nur 3° - für wenige Cent erhältlich.
:
Bearbeitet durch Moderator
Kauf dir mal einen RFID-Reader für Arduino - und einige passenden Chips (Karte/Transponder) dazu, um zu experimentieren ... kostet um die 10 Euro. Also meine Erfahrungen sind die, dass es etwa 5..6cm weit reicht und dabei spielt die genaue räumliche Lage nur eine untergeordnete Rolle. Am Unterboden eines Modellfahrzeuges ist das jedenfalls kein Thema, wenn dieses nicht gerade einen Salto macht ... https://www.amazon.de/dp/B076HTH56Q Die Transponder sind in dieser Form evtl. nicht optimal, weil zu groß? Aber wenn man mal einen opfert und so lange verkleindernd abkneift, bis man die Antenne beschädigt ... das sollte noch etwas möglich sein.
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.