Forum: Mikrocontroller und Digitale Elektronik Einfache Lösung für das Senden einer 32 Bit Zahl per Infrarot


von Jürgen S. (jsachs)


Lesenswert?

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
von Jens M. (schuchkleisser)


Lesenswert?

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?

von Walter T. (nicolas)


Lesenswert?

Jürgen S. schrieb:
> Oder hat jemand eine bessere Idee?

Mal einen Strichcode drunter.

von Stefan F. (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von Jürgen S. (jsachs)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Schlumpf (Gast)


Lesenswert?

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.

von Jürgen S. (jsachs)


Lesenswert?

Wie bereits mehrfach erwähnt, ist RFID, Barcode und Co bereits aus dem 
Rennen.

Das möchte ich hier nicht nochmals durchgehen.

Gruß
Juergen

von Schlumpf (Gast)


Lesenswert?

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"

von Jürgen S. (jsachs)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

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.

von Thomas E. (thomase)


Lesenswert?


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
Noch kein Account? Hier anmelden.