Hallo, Zum Hintergrund: ich brauche eine Möglichkeit RC Fahrzeuge zu erkenne, die sind recht langsam zu dem Zeitpunkt. NFC fällt aktuell flach, daher kam ich auf die Idee, nen ATtiny zu nehmen, und mit 2 Pins eine IR LED zu modulieren, die einfach die ganze Zeit einen eindeutigen Code für jedes Fahrzeug sendet. Unten einen IR Empfängen und an den ATmega zum auswerten. Ein Kolleg brachte mich auf die Idee, hier gibt es doch die Transmitter RS163 von Robitronic. Klein Günstig und machen genau dass. Deren Empfänger sind zweigeteilt. Einmal ein "Einfacher IRDa Transiver", wo nur RX belegt ist, von da aus geht es per Kabel zur Auswertebox. Die Auswertebox hat USB, die kann ich nicht verwenden. Zudem läuft das ganze per Batterie, also ist Stromsparen angesagt. Ich würde das gerne in einen ATmega auswerten, den gibt es schon und der erfüllt alle anderen Aufgaben bereits perfekt. Ich habe hier das Signal vom IrDa Transceiver, vermutlich TFDU4101, auf dem Scope und komme nicht ganz dahinter. Es ist pulse shape codiert, das habe ich hier schon gelesen. Ich habe einen Transmitter, der den Code "5065" sendet, ob Hex oder Dez ist mir noch nicht bekannt. Ich hänge das Scope Bild mal an. 50ms/Div. Kann mir da einer dabei helfen ? Achja, ich will denen nicht das Geschäft streitig machen, im Gegenteil, die verkaufen dann halt mehr Transmitter :-) Danke Juergen
Angehängte Dateien:
-
scope.jpg
140 KB
Angehängte Dateien:
-
marked_scope.jpg
160 KB
Ok, etwas weiter bin ich. Scope setting ist 50us/Div, nicht wie oben geschrieben 50ms, sorry. Bei Irda bin ich somit bei ungefähr 10us/div. Laut https://www.vishay.com/docs/82513/physical.pdf Seite 6 sind das 19,2kBaud. Die Zahl muss Dezimal sein, die Software lässt keine Hexadezimal Eingaben zu. Ich habe mal im angehängten Bild markiert, was ich Interpretiert habe. Leider konnte ich Paint nicht dazu bewegen, die Zahlen so aus zu richten, wie die bei der Eingabe sind. Die schwarzen Linien sollen ungefähr einem Bit Abstand entsprechen. Leider habe ich aktuell nur einen Transmitter um meine Theorie zu prüfen. Somit wäre die Übertragung. Die Übertragene Zahl ist 5065 Dez oder 13C9 hex Startbit , 8 Datenbit, Even Parity (0, C9, 0) Startbit , 8 Datenbit, Even Parity (0, 13, 1) Startbit , 8 Datenbit, Even Parity (0, 0, 0) Startbit , 8 Datenbit, Even Parity (0, DF, 1) Und somit müssten meine Prüfsummen stimmen. Liege ich da richtig ? Juergen
Mein nächster Versuch wäre jetzt, einen I/O Pin nehmen und das Signal scannen. Als Testumgebung ein STK200 board mit einem ATmega16, hab ich halt gerade da. Ein Timer, der ca alle 11us feuert. (Timing mal an https://www.vishay.com/docs/82513/physical.pdf, Seite 6 angelehnt) In main (es ist ja nur ein Test) scanne ich den I/O Pin, der am RX des Empfängers hängt. Time läuft im CTC Mode bekomme ich einen "Low" (Startbit) setze ich den Timer auf null. bei einem Low, Timer zurück setzen, und eine "0" als Ergebnis schieben. Feuert der Timer, eine "1" als Ergebnis schieben. Nach 11 mal schieben habe ich ein Byte. Bin mal gespannt ob der ATmega das packt. Das Ergebnis soll zu debug zwecken erst mal per RS232 raus, später als SPI slave. Dann kann ich das mit dem bestehenden ATmega noch auslesen, da ich hier schon einen ISP master am laufen habe, der Zyklisch für neue IDs scannen kann. Es ist hier im übrigen Tatsächlich so, dass der Transmitter ohne Handshake oder overhead die ganze Zeit seine Information sendet. Zwischen jedem Paket gibt es eine kurze Pause. Der Receiver Empfängt die Pakete und gibt die 1:1 weiter. Diese Empfangenen Pakete sieht man auf meinen Scanns und das Will ich auslesen. Ich habe mehrere Links zu einem IRDA Tiny Stack gefunden, die laufen aber alle ins leere. Jemand schon mal IRDA RX in Software gemacht ? Gruss Juergen
Jürgen S. schrieb: > Ich habe einen Transmitter, der den Code "5065" sendet, ob Hex oder Dez > ist mir noch nicht bekannt. Sind das diese Transmitter ("Transponder") von http://www.dirtchampdesign.com ? Allerdings arbeiten diese mit 115200 Bd. Dafür gibt es eine Lösung, die auf einem ATTiny25 läuft.
:
Bearbeitet durch Moderator
Das sind die transmitter http://cs-shop.de/Robitronic-Personal-Transponder Ob es gleiche/kompatibel sind, weiß ich nicht. Mit meinen 19200 Baud liege ich glaube ich eh nicht richtig. Ich habe ca 10us pro Bit. Jürgen
JSachs schrieb: > Das sind die transmitter > http://cs-shop.de/Robitronic-Personal-Transponder Danke für den Link. Die sehen schön klein aus. Habe ich das richtig verstanden: Du suchst jetzt einen Empfänger, der diese Transponder dekodiert? > Mit meinen 19200 Baud liege ich glaube ich eh nicht richtig. > Ich habe ca 10us pro Bit. IRDA läuft mit 115200 Bd. Da wäre ein Bit 8,6µs breit, wenn ich mich nicht verrechnet habe. Ich hatte damals die DirtChamp-Dinger per BruteForce geknackt, um das Signal dann für einen Bekannten mit einem ATTiny nachzubilden. Die Original-Transponder wurden nämlich nicht mehr angeboten. Ich kann Dir anbieten, mit einem preisgünstigen STM32 ein Programm zu entwickeln, welches die Dinger eindeutig identifiziert, damit Du dann die Rundenzeiten messen kannst. In diesem Falle melde Dich per PN.
Vielleicht zur Aufgabe: Ich habe eine Waage gebaut, die das Gewicht von RC- Fahrzeugen, Hauptsächlich im Maßstab 1:14 misst. Diese kann das Gewicht Optional an eine Android APP per Bluetooth übertragen. Hier findet jede Menge Interaktion statt. Ziel ist die Erfassung der "Transportleistungen" pro Fahrzeug. Unter anderem mit folgenden Daten: - Fahrzeug + Fahrer - Leergewicht - Ladungsgewicht - Material Transportiert Ein früher status ist hier in einem Demo Video zu sehen. https://youtu.be/X-SfDrA7D3M?list=PLHTs0Pyh021bLe-w83jZPOix3GuqLb9HL Dazu muss man aktuell, bei gekoppelter Waage am Tablett noch Transportiertes Material und Fahrzeug auswählen. Die Auswahl des Fahrzeugs wollen wir jetzt noch Automatisieren. Nach einiger Recherche viel NFC aus. Da kam mir die Idee, einen kleinen IR Sender zu bauen, der in jedem Fahrzeug sitzt und eine Eindeutige ID Richtung Boden sendet. In die Waage kommt im Einfahrt bereich ein Empfänger, der dieses Signal Empfängt. Die Fahrzeuge sind, wie bereits erwähnt, recht langsam und somit sollte IR und Übertragungsstörungen relativ egal sein. Nun, diese Sender von Robitronic sind klein und auf ebay billig zu haben. Kann ich nun diese verwenden ohne deren Software und PC Interface, etc. habe ich schon 50% erschlagen. Ich habe einen Transmitter (Ich bekomme noch 2 Stück zum Testen) und einen Empfänger. Der Empfänger hat eigentlich nur einen IRDA Tranceiver, wobei die Transmit Seite nicht genutzt wird. Die Receive Seite gibt somit einfach den RAW Datenstrom des Transmitters im Fahrzeug aus. Dieses Signal will ich nun Auswerten und an meine APP senden. Darin geschieht der Rest. Sobald ich die ID Ausgewertet habe, ist der Rest ein Kinderspiel. Leider habe ich an meinem ATmega328p, der auf dem Funkmodul sitzt, nur noch die ISP Schnittstelle übrig. Diese bedient zwar schon ein Display, aber zwischendurch einen Prozessor ab zu fragen, der mir die ID liefert, ist ja kein Problem. Da ich hier einen eh einen kleinen Prozessor bräuchte, würde ich mir irgend welche IRDA Chips, die schwer zu bekommen sind, gerne sparen und alles in Software machen. So, und jetzt bin ich wieder bei dem Grund dieses Threads. Ich habe die RAW IRDA Daten von dem Tranceiver Chip, siehe auch Oszi Bilder, und will die nun auswerten. Da der Prozessor außer der Auswertung nichts machen muss und auf SPI reagieren, sollte das doch machbar sein. Ich hoffe es ist jetzt etwas klarer. Gruss Juergen
Jürgen S. schrieb: > Da ich hier einen eh einen kleinen Prozessor bräuchte, würde ich mir > irgend welche IRDA Chips, die schwer zu bekommen sind, gerne sparen und > alles in Software machen. IRDA-Transceiver sind nicht so schwer zu bekommen und sind ihr Geld wert. Eine Reichweite von 5 Metern sind da überhaupt kein Problem. Bei Deinen niedrigen Geschwindigkeiten würde ich jedoch auf IRDA (und damit auch auf die von Dir präferierten Transpondermodule) verzichten und stattdessen IRMP und IRSND (<--- einfach draufklicken) verwenden. Mit einem ATTiny45 und einer simplen IR-LED, Transistor und Widerstand kostet Dich dann ein Transponder weniger als 5 EUR, der stationäre Empfänger mit einem TSOP hält sich ebenso in diesem Rahmen. Die Software ist stabil und einfach einsetzbar. Einfach das NEC-Protokoll verwenden und einen festen (eindeutigen) Code pro Tansponder per IRSND raussenden und mit dem Empfänger und IRMP wieder empfangen. Der Code, um beide Software-Bibliotheken zu bedienen, sind dann nur noch 2-3 Zeilen Code.
Das war mein Plan. Aber hier spielen viele Faktoren mit rein. Bauteil Mäßig gebe ich dir recht. Versorgung aus dem BEC des Fahrzeugs (+5V) ATtiny + LED, Vorwiderstand, Pufferkondensator, und eine Leiterplatte. Ein kleiner Programm, Ein Pin moduliert die 38kHz und ist mit der Anode der IR LED verbunden, ein zweiter Bin mit der Kathode und gibt die Daten aus. Einfach zu Programmieren. Timer CTC für die Träger Frequenz und am IO Pin nur noch Roh Daten Raus takten. Unten einen IR Empfänger, bekomme die Rohdaten und TaDa. Aber: Dann muss ich einige "Produzieren" und auch "Verkaufen", auf Lager halten. Von der Waage gibt es aktuell schon 2 Stück und es sind mehr gefragt und ich mach das nur aus Spaß und non Profit. Kann ich die Fertigen Teile nehmen habe ich keinen Aufwand in der Produktion und Vermarktung etc etc etc der Transmitter. Nochmal um es klar zu machen, ich nutze den IRDA Tranceiver für den Datenempfang. Aber ich will keinen Chip verwenden, der mir das IRDA Protokoll (siehe https://www.vishay.com/docs/82513/physical.pdf Seite 6) wieder auf normales RS232 wandelt. Gruss Juergen
Jürgen S. schrieb: > Ok, > > etwas weiter bin ich. > Scope setting ist 50us/Div, nicht wie oben geschrieben 50ms, sorry. > > Bei Irda bin ich somit bei ungefähr 10us/div. > Laut https://www.vishay.com/docs/82513/physical.pdf Seite 6 sind das > 19,2kBaud. > > Die Zahl muss Dezimal sein, die Software lässt keine Hexadezimal > Eingaben zu. > > Ich habe mal im angehängten Bild markiert, was ich Interpretiert habe. > Leider konnte ich Paint nicht dazu bewegen, die Zahlen so aus zu > richten, wie die bei der Eingabe sind. > Die schwarzen Linien sollen ungefähr einem Bit Abstand entsprechen. > > Leider habe ich aktuell nur einen Transmitter um meine Theorie zu > prüfen. > Somit wäre die Übertragung. > Die Übertragene Zahl ist 5065 Dez oder 13C9 hex > Startbit , 8 Datenbit, Even Parity (0, C9, 0) > Startbit , 8 Datenbit, Even Parity (0, 13, 1) > Startbit , 8 Datenbit, Even Parity (0, 0, 0) > Startbit , 8 Datenbit, Even Parity (0, DF, 1) > Und somit müssten meine Prüfsummen stimmen. > > Liege ich da richtig ? > > Juergen Hallo Jürgen, Hast du zu diesen Robitronic Transponder und den gefundenen Werten, irgendwas an Code, mit dem man diese Erkenntnis bestätigen könnte ? Ich habe ein paar von den Teilen und würde die gerne erkennen können Greetz Mark
Ich konnte nichts neues ermitteln. Aktuell ist der Gedanke diese durch 125kHz long Range NFC zu ersetzen. Gruss Juergen
Wie bist du auf die konstanten Werte von 40 bit gekommen ? Nach deiner Beschreibung konnte ich dem nicht ganz folgen. Ich würde das gerne nachvollziehen können und hätte wirklich viele Transponder greifbar um die Auswertung und Interpretation verifizieren zu können. Greetz Mark
Mark J. schrieb: > Ich würde das gerne nachvollziehen können und hätte wirklich viele > Transponder greifbar um die Auswertung und Interpretation verifizieren > zu können. Hi, ich habe mir das Ganze mal angesehen und folgende Erkenntnisse: - es werden 3 Bytes Daten (24 bit Transponder-ID, Little Endian) + 1 Byte CRC-8 (über die vorherigen 3 Bytes) gesendet - die Übertragung ist ein asynchrones serielles Protokoll (wie serielle Schnittstelle) mit 1 Startbit, 8 Datenbits, 1 Paritybit, 1 Stoppbit -> es werden 44 Bit ausgegeben (inklusive Start, Parity, Stop) = total: 0,44 Millisekunden - die Baudrate beträgt exakt 100.000 bits/Sekunde - ein Bit ist genau 10 µs lang -> eine 1 wird durch einen 2µs On-Puls der IR-LED, gefolgt von 8µs Off signalisiert -> eine 0 wird durch 10µs Off singalisiert - nach einer kompletten Übertragung der ID wird eine zufällige Pause von 1,0-4,5 Millisekunden gemacht (um Kollisionen mit anderen Transmittern in der Nähe zu vermeiden) Grüße, JS
Angehängte Dateien:
-
GLA-2019-06-24.jpg
230 KB
Also mit nem Oszi konnte ich das dann doch jetzt in etwa nachvollziehen. Das Bild ist das Ergebnis für den ID 80175 ... so ganz sehen die Zahl kann ich noch nicht. Warum ich bisher noch gar nichts sehen konnte lag dann aber wohl daran, dass ich irgendwas mit dem IR-Empfänger falsch gemacht habe, oder müssen es spezielle Dioden sein ? Meinem Code auf dem Arduino würde ich schon trauen wollen. Ich habe das aktuell mit zwei Interrupt-Routinen gelöst. Ein Timer-Interrupt alle 10us: Index inkrementieren und eine 0 an die aktuelle Stelle schreibt. Ein Interrupt auf der Rising Flanke von Port 2: an die aktuelle Stelle eine 1 setzt Die 100kHz lassen ja leider aber auch nur wenig (zeitliche) Spielräume für weitere Test-Werte auf dem Arduino :D
Mark J. schrieb: > Also mit nem Oszi konnte ich das dann doch jetzt in etwa nachvollziehen. > Das Bild ist das Ergebnis für den ID 80175 ... so ganz sehen die Zahl > kann ich noch nicht. Hallo, ich weiß, dass ich hier uralte Geschichte ausgrabe. Ich hatte auch Interesse daran zu verstehen wie das Robitronic Protokoll funktionert und habe mir den Oszi Screenshot genauer angesehen. Ihr wart nah dran, habt aber nicht an little vs big endian und invertierte daten gedacht. Anbei eine Protokollbeschreibung. Vielleicht ist ja zwischenzeitlich noch jemand anderes dahintergekommen und hat auch herausgefunden, wie der CRC gerechnet wird.
Gibt es noch einen anderen Datensatz mit Checksumme? https://crccalc.com/ 0xaa 0xd0 0xc6 0xfe Mit 0xaa davor würde die passende Checksumme (0xb8) bei CRC-8/DVB-S2 rauskommen. Kann aber auch Zufall sein...
:
Bearbeitet durch User
Für das Beispiel "2F 39 01 47" (Hex Bytes vor dem Invertieren) findet RevEng diese CRC: width=8 poly=0x07 init=0x00 refin=false refout=false xorout=0x00 check=0xf4 residue=0x00 name="CRC-8"
Thread beobachten
Seitenaufteilung abschaltenBitte 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.