Hallo zusammen,
es geht um folgendes:
Ich habe hier von einem Bekannten 3 sogenannte "IR-Transponder" zur
Ansicht bekommen. Diese senden zyklisch ein IRDA-Signal aus mit
folgenden Daten:
B1 B2 B3 B4 B5 B6
Transponder ID 2308 = 0D 0A 09 04 16 73
Transponder ID 2371 = 0D 0A 09 43 02 C7
Transponder ID 2259 = 0D 0A 08 D3 7D 07
Die Telegramme fangen also immer mit 0D 0A (CR LF) an. Die auf den
Modulen aufgedruckte Transponder-ID findet sich in B3 und B4 wieder
(z.B. 2308 = 0x0904)
Rätselhaft sind aber die Bytes B5 und B6, die wahrscheinlich eine CRC
bilden.
Da die Module schon seit längerer Zeit nicht mehr hergestellt werden,
ist die Idee, diese selbst mit ATTinys zu realisieren. Um aber eine
beliebige Transponder-ID zu reproduzieren, müsste man die Bytes B5 und
B6 "entschlüsseln". Ich selbst habe bereits die CCITT-CRC16 und auch die
CRC16, die in der avr-libc enthalten sind, mit allen 65536 möglichen
Startwerten durchprobiert. Leider kann ich nicht alle 3 CRCs mit
demselben Startwert reproduzieren.
Vielleicht hat sonst jemand eine Idee dazu? Leider stehen mir nicht mehr
als diese 3 Transponder zu Verfügung.
P.S.
Es geht hier konkret um Transponder, die man in kleine ferngesteuerte
Renn-Autos einbaut, um Rundenzeiten zu messen. Es handelt sich hier um
kein kommerzielles Anliegen, sondern nur eine Hilfe für eine kleine
Interessen-Gemeinschaft (Verein), die ihr Rundenmess-Gerät, welches sie
sich vor ein paar Jahren angeschafft haben, weiter nutzen möchten.
Die Hersteller-Seite existiert noch:
http://www.dirtchampdesign.com/newsite/
Nur leider kann man da (obwohl ein Web-Shop dort existiert) weder Module
nachbestellen noch reagiert der Hersteller auf Mails. Vermutlich sind
die einfach pleite, denn auch Distributoren haben diese Module aus ihrem
Angebot genommen.
:
Bearbeitet durch Moderator
na dann ruf doch mal bei den Schweden direkt an ....
irgendwo steht eine Kontaktadresse auf deiner genannten Webseite.
das etwas verkürzt in google eingegeben:
DCD Racing Enköping Sweden
liefert interssante Infos. In "annelundsgatan 17c" in Enköping scheint
viel los zu sein:
http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=9&cad=rja&uact=8&ved=0CGAQFjAI&url=http%3A%2F%2Fwebshop.minicars.se%2F&ei=OoQnVZqAIIOpsgHAyIAw&usg=AFQjCNF9vV1mJn4XHYeeulpjA09ABqcwWA&bvm=bv.90491159,d.bGg
--> "Minicars Distribution" ? Die sollten sich wohl auch auskennen?
http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&cad=rja&uact=8&ved=0CEsQFjAF&url=http%3A%2F%2Fwww.hitta.se%2Fannelundsgatan%2B17c%2Benk%25C3%25B6ping%2Ff%25C3%25B6retag%2F2&ei=OoQnVZqAIIOpsgHAyIAw&usg=AFQjCNEeREZibD_SPNP2mOPsr8vZeD8NWA&bvm=bv.90491159,d.bGg
--> ach? Würth residiert unter gleicher Adresse?
hast du denn probiert, ob der CRC möglicherweise nur über die beiden Bytes gebildet wird, oder irgen eine andere Art Abhängigkeit zu diesen besitzt? zB XOR, bitreverse, oder irgend andere bitmanipulationen... Ich würde zB die Checksumme nicht über den Prefix bilden, der nur dem Empfänger signalisieren soll, gleich kommt irgendwas.
Vlad Tepesch schrieb: > hast du denn probiert, ob der CRC möglicherweise nur über die beiden > Bytes gebildet wird, Ja, ich habe CRC sowohl über die ersten 4 Bytes als auch über die 2 Bytes der Transponder-ID probiert. > oder irgen eine andere Art Abhängigkeit zu diesen > besitzt? zB XOR, bitreverse, oder irgend andere bitmanipulationen... Ich habe mir die Bitmuster angeschaut (besser gesagt: lange Zeit angestarrt) und versucht, irgendwelche Bitmanipulation-Muster zu erkennen. Leider habe da kein Erfolg gehabt. > Ich würde zB die Checksumme nicht über den Prefix bilden, der nur dem > Empfänger signalisieren soll, gleich kommt irgendwas. Ja, diesen Gedanken hatte ich auch schon. Aber wenn man genauer drüber nachdenkt: Wenn ich sowieso alle 65536 Startwerte einer CRC probiere, dann ist es doch egal, ob ich am Anfang bei Byte B1 anfange, die Checksum zu bilden, oder erst bei bei Byte B3 "einsetze". Eine CRC-update-Funktion kennt ja die Vorgeschichte auch nicht.
Wegstaben Verbuchsler schrieb: > na dann ruf doch mal bei den Schweden direkt an .... Ja, werde ich im Notfall auch machen. Aber wenn ich mir den Preis anschaue, wird mir ganz schwindelig: 50 EUR das Stück plus 29 EUR Versandkosten plus MwSt sind fast 100 EUR für ein Stück Platine nebst eingebetteten µC und eine IR-LED... > --> "Minicars Distribution" ? Die sollten sich wohl auch auskennen? Ja, wahrscheinlich haben die sich ein neues Geschäftsfeld gesucht.
vielleicht ist es auch ein crc 8 oder 4 oder was ganz und gar selbst gestricktes. Ohne größere Datenmenge sehe ich da wenig Chancen, eine Vorschrift abzuleiten. Wie sieht denn der Empfänger aus? Vielleicht kannst du ja den ersetzen und mit Eigenbau-Transpondern kompatibel machen und für die bestehenden 3 eine Sonder-Berücksichtigung implementieren. Möglicherweise ist die Empfangsanlage (weiß ja nicht, was sie noch alles tut) ja auch so modular, dass die die Detektion, die die IDs liefert unabhängig von dem Rest ist und ersetzt werden kann. Vielleicht ist auch ein auslesbarer µC drin.
:
Bearbeitet durch User
Vlad Tepesch schrieb: > vielleicht ist es auch ein crc 8 oder 4 oder was ganz und gar selbst > gestricktes. Wahrscheinlich ist es was selbstgestricktes. Ich habe gestern abend auch nochmal sämtliche möglichen CRC-Polynome (65536 Möglichkeiten) über alle 65536 Startwerte durchgerechnet, also alle 4 Milliarden Möglichkeiten. Der Rechner hat sich dabei zwar eine halbe Stunde damit beschäftigt, konnte aber auch keine Übereinstimmung mit den obigen 3 CRC-Werten ermitteln - jedenfalls nicht bei gleichem Startwert und gleichem Polynom. > Ohne größere Datenmenge sehe ich da wenig Chancen, eine Vorschrift > abzuleiten. Ich bekomme ja schon bei den dreien keine Gemeinsamkeit bzw. Vorschrift heraus. Wie soll das bei mehr Daten - die die Menge aller in Frage kommenden Vorschriften nur einengen können - besser gehen? Sag mir doch mal bei den dreien eine mögliche "Rechenregel". Ich kenne leider keine einzige. ;-) (Aber Du hast schon recht: man könnte vieleicht "Muster" der Operationen erkennen). > Wie sieht denn der Empfänger aus? Siehe Bild. Dafür wurde er extra auseinandergenommen, um mir ein Bild zuzuschicken. Das Gerät ist wohl ziemlich aufwendig - AT91SAM mit Bluetooth-Kommunikation zu Windows-PC, auf welchem dann die Messergebnisse in Tabellen (schnellste gefahrene Runde, Platzierungen etc) präsentiert werden. Die IR-Daten vom Transponder zum Empfänger werden auch nicht in TV-Fernbedienungs-Geschwindigkeiten geschickt, sondern vielfach schneller, nämlich mit ca. 115200 Baud über bis zu 5 Meter. Ausserdem funktioniert das System auch noch, wenn sich mehrere Autos nahe beieinander befinden. Das machen die durch geschicktes Anordnen von Sendelücken, in die sich dann ein anderes Auto "schieben" kann. Der Frame an sich dauert auch nur 500µs. Das geht alles ziemlich flott ab.... > Vielleicht kannst du ja den ersetzen und mit Eigenbau-Transpondern > kompatibel machen und für die bestehenden 3 eine Sonder-Berücksichtigung > implementieren. Wenn, dann würde ich das sowieso komplett neu machen. Ist aber eine Menge Arbeit - es ist ja nicht nur µC-Programmierung, sondern auch noch die ganze Präsentations-Software für den PC... Insgesamt hat der Verein wohl mindestens 10 Transponder. Sie haben mir halt 3 davon zur Analyse zur Verfügung gestellt. Die anderen sind in den Fahrzeugen fest eingebaut. Der Verein ist auch nicht gerade um die Ecke. Das sind mehrere hundert Kilometer. Auch können sie mir nicht alle Autos in eine Kiste packen und mir schicken... dann sind sie ja für mehrere Wochenenden unterbeschäftigt ;-) Irgendwann wird auch der Empfänger kaputtgehen. Dann muss sich der Verein sowieso nach einem neuen System umsehen... die kosten schon mal so um die 2000 EUR. Ja, es wäre sinnvoll, diese Original-Transponder bei der Entwicklung eines neuen quelloffenen Empfängers mit zu berücksichtigen. Mich juckts schon in den Fingern. Ein STM32F411-Nucleo-Board + ESP8266 als WLAN-AP (statt Bluetooth) + IRDA-Transceiver... und dann fängt der Spaß an :-) Trotzdem wäre es erstmal sinnvoll, das IR-Protokoll zu hacken. Dann hat der Verein erstmal keine Transponder-Knappheit mehr und man könnte die Entwicklung eines neuen Emfängers gemütlicher angehen. > Möglicherweise ist die Empfangsanlage (weiß ja nicht, was sie noch alles > tut) ja auch so modular, dass die die Detektion, die die IDs liefert > unabhängig von dem Rest ist und ersetzt werden kann. > Vielleicht ist auch ein auslesbarer µC drin. Ja, vielleicht. Ich habe aber auch keinen Zugriff auf den Empfänger, lediglich das Bild.
So mal gefragt: Bist du sicher das der Datenkanal eine Einbahnstraße ist? Oder könnte da auch ein Startwert vom Empfänger zum verwursten auf Request kommen. Das IR modul ist ein klassischer IRDA Transciver mit welchem ich mir vor Jahren einen preiswerten IRDA RS232-Adapter selbst gestrickt habe. Ich bin fast sicher das die Kommunikation in beide Richtungen läuft Halbduplex und die letzten beiden Werte aus mehr als einem konstanten Startwert und dem konstnten Gap und den spezifischen TransponderIDs gebildet werden. Sei es, dass der Startwert auf Request vorgegeben wird oder vom letzen Telegramm stammt oder außer der Seriennummer noch ein Identcode .... Der kann ja in einer Tabelle stehen ohne jeden mathematischen Bezug zur Seriennummer? Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > So mal gefragt: Bist du sicher das der Datenkanal eine Einbahnstraße > ist? Das habe ich mich auch schon gefragt. Dem scheint aber nicht so zu sein. Ein Versuch, mit einer Handy-Kamera, welche auf IR reagiert, zeigt, dass der Transceiver tatsächlich nur als Empfänger verwendet wird. > Oder könnte da auch ein Startwert vom Empfänger zum verwursten auf > Request kommen. Ja, ähnliche Gedanken hatte ich schon alle. Man muss aber auch bedenken, dass die Autos bis zu 60km/h fahren und der Empfänger ein ungefähres Sichtfeld auf die Strecke von max. 25cm hat. Da bleibt nicht viel Zeit für lange Gespräche: 60 km/h = 16m/s = 1m / 0,0625sec = 25cm in 16msec Und wie gesagt: Es ist keinerlei Sendeaktivität am Empfänger festzustellen. > Ich bin fast sicher das die Kommunikation in beide Richtungen läuft > Halbduplex und die letzten beiden Werte aus mehr als einem konstanten > Startwert und dem konstnten Gap und den spezifischen TransponderIDs > gebildet werden. Sei es, dass der Startwert auf Request vorgegeben wird > oder vom letzen Telegramm stammt oder außer der Seriennummer noch ein > Identcode .... Ja, Deine Gedanken habe ich alle schon durchlebt und mittlerweile verworfen. > Der kann ja in einer Tabelle stehen ohne jeden mathematischen Bezug zur > Seriennummer? In einer Tabelle bis zu 9999 mögliche Transponder-IDs abgleichen, um dann die letzten beiden Bytes zu prüfen? Hm, ziemlich unwahrscheinlich. Wenn da 3 Autos fast gleichzeitig über die Ziellinie fahren, käme der AT91SAM dabei arg ins Schwitzen... EDIT: Auf 9999 statt theoretisch 65536 IDs komme ich nur deshalb, weil bisher nur dezimale Transponder-IDs bekannt sind und noch niemand welche mit Hex-Zahlen in die Finger bekam...
:
Bearbeitet durch Moderator
Frank M. schrieb: > Die Telegramme fangen also immer mit 0D 0A (CR LF) an. Die auf den > Modulen aufgedruckte Transponder-ID findet sich in B3 und B4 wieder > (z.B. 2308 = 0x0904) > > Rätselhaft sind aber die Bytes B5 und B6, die wahrscheinlich eine CRC > bilden. Hast du schon verschiedene Spannungen angelegt, es könnte in einem Byte die Spannung kodiert sein. Hier ist übrigens ein Bild vom Transponder: http://cs-shop.de/DCD-Transponder
Alexander Schmidt schrieb: > es könnte in einem Byte die Spannung kodiert sein. Welchen Sinn sollte das haben?
Akkustand der Fahrzeuge? Wobei ein Byte da vielleicht etwas gering abgestuft wäre... /Hannes
Das ist doch reichlich spekulativ... Besser als die Funktion der Bytes zu erraten, wäre doch ein Versuch: - werden sie überhaupt ausgewertet? - wenn ja: was passiert wenn sie falsch übertragen werden? - wenn falsche Bytes zu einem Übertragungsfehler führen, kann man einfach eine neue ID wählen und alle Möglichkeiten durchprobieren
:
Bearbeitet durch User
Johannes S. schrieb: > Akkustand der Fahrzeuge? Wobei ein Byte da vielleicht etwas gering > abgestuft wäre... Ich seh da den Sinn noch nicht wirklich. Der Akkustand interessiert den Fahrer/Piloten. Aber doch nicht die Zeitnehmung. Denen ist das doch völlig wurscht, ob ein Auto in der nächsten Runde wegen leerem Akku liegen bleibt oder nicht.
Uhu Uhuhu schrieb: > Das ist doch reichlich spekulativ... > > Besser als die Funktion der Bytes zu erraten, wäre doch ein Versuch: > - werden sie überhaupt ausgewertet? Wäre interessant. Ich denke allerdings die werden ganz sicher ausgewertet. Denk einfach mal an den Fall, wenn mehrere Fahrzeuge mehr oder weniger glichzeitig über die Linie gehen und sich mit ihrem Geblinke gegenseitig ins Gehege kommen. Der Empfänger braucht dann eine Mögllichkeit festzustellen, dass die ID, die er gerade dekodiert hat, komplett falsch ist.
Karl Heinz schrieb: > Ich denke allerdings die werden ganz sicher ausgewertet. Vermute ich auch, aber Vermutungen, die Konsequenzen für das weitere Vorgehen haben, muss man überprüfen, bevor man sie als wahr annimmt.
warum nicht einfach mit BruteForce ermitteln.. also sender bauen der alle 0xFFFF möglichkeiten probiert.. solange bis der empfänger anzeigt dass ein auto durch ist..
Alexander Schmidt schrieb: > Hast du schon verschiedene Spannungen angelegt, es könnte in einem Byte > die Spannung kodiert sein. Das glaube ich nicht, da die Spannung nirgendwo abgefragt werden kann. Außerdem habe ich sie alle 3 an derselben Spannungsquelle betrieben. Da sollten die Werte gleich oder wenigsens ähnlich sein.
Uhu Uhuhu schrieb: > Das ist doch reichlich spekulativ... Ja. > Besser als die Funktion der Bytes zu erraten, wäre doch ein Versuch: > - werden sie überhaupt ausgewertet? Ich schätze schon, sonst wären sie nicht da. Ausserdem dienen sie wahrscheinlich auch einer Kollisionserkennung. Aber wie ich nach Rücksprache erfahren habe, kann man neben der automatischen Erkennung auch Transponder anlernen. Ich werde also meinem Bekannten zwei ATTinys schicken: eins mit der 1:1 Kopie des Signals für ID 2308 und ein weiteres mit der ID 2308 und einer Phantasie-CRC. Vielleicht kann er letzteren zumindest anlernen. Dann werden wir das klären können. > - wenn ja: was passiert wenn sie falsch übertragen werden? Ich schätze, dass sie verworfen werden. In vielen IR-Protokollen ist Redundanz eingebaut, um die Sicherheit der Übertragung zu gewährleisten. Glaub mir, als Autor von IRMP kann ich da ein Lied von singen. > - wenn falsche Bytes zu einem Übertragungsfehler führen, kann man > einfach eine neue ID wählen und alle Möglichkeiten durchprobieren Ja, dann muss man wahrscheinlich stundenlang vor dem Empfänger sitzen und warten, dass der Kopie-Transponder alle 65536 möglichen CRCs durchgespielt hat. Muss ich mal ausrechnen, wie lange das dauert....
Robert L. schrieb: > warum nicht einfach mit BruteForce ermitteln.. > > also sender bauen der alle 0xFFFF möglichkeiten probiert.. > solange bis der empfänger anzeigt dass ein auto durch ist.. Ja, das wäre aber das letzte Mittel der Wahl. Wenn ich jede Sekunde eine neue CRC schicke, dann dauert das 65536/3600 = 18 Stunden. Solange muss man vor dem Empfänger hocken und zuschauen. Okay, man kann das schneller durchprobieren. Bis man aber reagiert und den Transponder stoppt, wird man ein paar hundert CRCs weiter sein. Man muss dann das Problem per Intervallschachtelung lösen, also sich der CRC erst schnell, dann immer langsamer annähern. Denn das einzige Messgerät wäre das Auge...
Oder du leitest den Zählimpuls des Empfängers aus und stopst den Suchlauf automatisch, bzw. läst ein Protokoll mitlaufen welches das Erbsenproblem für dich löst und dir eine Liste gültiger Kombinationen auswirft. Wenn es allerdings einen Anlernmodus gibt würde ich mir zunächst den Anlernalgorythmus näher unter die Lupe nehmen (auch in Bezug auf das halbduplexverfahren).Das ist imho noch nicht vom Tisch. Eventuell steckt ja das Geheimnis des dritten Wortes darin, dass beim Anlernen dieses als Kontrollwort dem Transponder einmalig zugeteilt wird? Namaste und good luck
Winfried J. schrieb: > Wenn es allerdings einen Anlernmodus gibt würde ich mir zunächst den > Anlernalgorythmus näher unter die Lupe nehmen (auch in Bezug auf das > halbduplexverfahren).Das ist imho noch nicht vom Tisch. Eventuell steckt > ja das Geheimnis des dritten Wortes darin, dass beim Anlernen dieses als > Kontrollwort dem Transponder einmalig zugeteilt wird? kan nich mir nicht vorstellen. Das würde heißen, dass man nur dafür den Transponder auch das Receiven beibringen müsste. Da er scheinbar auch nur die Sende-LED da dran hat, müsste die Kommunikation in diese Richtung sehr viel langsamer ablaufen, wenn man versuchen würde, die LED als Empfänger zu benutzen.
Frank M. schrieb: > Ja, das wäre aber das letzte Mittel der Wahl. Wenn ich jede Sekunde eine > neue CRC schicke, dann dauert das 65536/3600 = 18 Stunden. Solange muss > man vor dem Empfänger hocken und zuschauen. Ich dachte, den Empfänger hast du gar nicht. Falls doch, gehört doch zu dem EMpfänger irgend eine Anzeigeeinheit, deren Reaktion du automatisiert begutachten könntest. Läuft das ganze über PC, hängst du deinen simulierten Sender auch an den PC und schreibst ein Programm, was Screenshots des Mess-Programms anfertigt und schaut, ob es eine Rundenzeit bekommen hat und den Sender koordiniert. Bei einer halben ms pro frame sollte es Problemlis möglich sein, dem Empfänger 20 Versuche/s vorzusetzen. Wenn du alle 2s das Empfangsprogramm checkst, hast du zumindest grobe bereiche, in denen was sein muss.
:
Bearbeitet durch User
Vlad Tepesch schrieb: > Ich dachte, den Empfänger hast du gar nicht. Habe ich auch nicht. Ich müsste meinem Bekannten einen ATTiny zuschicken, damit er das testen kann. > Falls doch, gehört doch zu > dem EMpfänger irgend eine Anzeigeeinheit, deren Reaktion du > automatisiert begutachten könntest. Ich kenne das Protokoll zwischen PC und Empfänger (Bluetooth) leider nicht. Kann ich ohne Empfänger auch schlecht erraten. Aber wenn, dann würde ich dort ansetzen. > Läuft das ganze über PC, hängst du deinen simulierten Sender auch an den > PC und schreibst ein Programm, was Screenshots des Mess-Programms > anfertigt und schaut, ob es eine Rundenzeit bekommen hat und den Sender > koordiniert. Ziemlich viel Aufwand, oder? Für eine Rundenzeit brauche ich schon 2 Messwerte. Ich müsste also jeden möglichen Wert zweimal senden - mit einem gewissen Abstand, sonst würde das Gerät die Rundenfahrt nicht als solche akzeptieren, sondern die Messung als Doppelempfang werten - was ja durchaus in der Realität vorkommen könnte. Ich weiß leider nicht, was die Mindestzeit für eine Runde ist. Aber bestimmt müssen die beiden Werte schon in einem gewissen Abstand kommen, damit sie als volle Rundenfahrt akzeptiert werden. > Bei einer halben ms pro frame sollte es Problemlis möglich > sein, dem Empfänger 20 Versuche/s vorzusetzen. Wenn du alle 2s das > Empfangsprogramm checkst, hast du zumindest grobe bereiche, in denen was > sein muss. Ja, so ähnlich könnte man das machen. Aber ohne Empfänger zum Testen ist das alles nicht so einfach.
Hallo, wenn man 16 Codes hätte könnte man doch ein Gleichungssystem der Art: A*G = crc Wobei A wahlweise die ersten 2 oder ersten 4 Bytes sind und CRC die letzten 2 Bytes. Dadurch sollte man doch alle linaren codes herausbekommen oder bin ich da gerade auf den Holzweg? Wie löst man so ein Gleichungssystem in der binären Algebra? Gruß Peter
Frank M. schrieb: > Ziemlich viel Aufwand, oder? Wie wärs, wenn du dir einfach mal die CRC-Mathematik etwas genauer ansiehst, statt nur zu heulen? Dann würde dir nämlich auffallen, dass du mit 3 bekannten Datensätzen keine Chance hast, das Generatorpolynom zu berechnen - ausgenommen, es handelt sich um ein Polynom 3. Grades. Es bleibt also nur der vorgeschlagene Weg einer Brute Force Attacke - oder hoffen auf ein Wunder, wenn es nicht gelingt, beim Hersteller an die Information zu kommen...
Frank M. schrieb: >> Läuft das ganze über PC, hängst du deinen simulierten Sender auch an den >> PC und schreibst ein Programm, was Screenshots des Mess-Programms >> anfertigt und schaut, ob es eine Rundenzeit bekommen hat und den Sender >> koordiniert. > > Ziemlich viel Aufwand, oder? keine ahnung. Vielleicht hat das Tool auch einen Modus, in dem man vor dem Rennen alle Fahrzeuge bekannt macht, indem man sie kurz davorhält. Da muss es ja auch irgend eine Reaktion geben. Aber das ist alles spekulation. Ich würde um den Empfänger bitten, das Programm installieren (vorausgesetzt es ist nicht rechnergebunden) und mal schauen, was die einfachste auswertbare Reaktion des Programms (am einfachsten, sich öffnender Dialog, oder etwas schwieriger bestimmte, sich änderne Statusanzeigen) ist. Eventuell isses auch viel einfacher, weil der Empfänger überhaupt nur bei gültigen Daten diese an den PC weiterleitet (was ich durchaus plausibel fänd). Dann braucht das BT Protokoll nicht mal verstanden werden, oder der Klassiker eine Uart, irgendwo auf der Platine.
:
Bearbeitet durch User
Uhu Uhuhu schrieb: > Frank M. schrieb: >> Ziemlich viel Aufwand, oder? > > Wie wärs, wenn du dir einfach mal die CRC-Mathematik etwas genauer > ansiehst, statt nur zu heulen? Ich weiß, dass ich mit 3 Datensätzen keine Chance habe. Es ging mir nur darum, ob irgendein geschultes Auge der geschätzten Leserschaft ein Bitmuster (und damit eine simple Bitmanipulation) erkennen kann, die ich bisher übersehen habe - sonst nichts. Denn wie gesagt: Ich habe alle möglichen CRC16-Polynome bereits durchgerechnet. Scheinst Du überlesen zu haben - und damit auch die Intention dieses Threads missverstanden zu haben. Ich danke Dir vielmals für Deinen Beitrag.
Vlad Tepesch schrieb: > Vielleicht hat das Tool auch einen Modus, in dem man vor dem Rennen alle > Fahrzeuge bekannt macht, indem man sie kurz davorhält. Da muss es ja > auch irgend eine Reaktion geben. Aber das ist alles spekulation. Ja. Leider weiß ich da auch nicht mehr über den Empfänger und dessen Handhabung. Ich werde da noch mal nachfragen. > Ich würde um den Empfänger bitten, das Programm installieren > (vorausgesetzt es ist nicht rechnergebunden) und mal schauen, was die > einfachste auswertbare Reaktion des Programms (am einfachsten, sich > öffnender Dialog, oder etwas schwieriger bestimmte, sich änderne > Statusanzeigen) ist. Das wäre eigentlich der richtige Weg, aber ich glaube nicht, dass der Verein den Empfänger für längere Zeit entbehren kann. Ich schicke erstmal eine 1:1-Kope (realisiert mit einem ATTiny) und eine weitere Version mit abweichender ID und Phantasie-CRC. > Eventuell isses auch viel einfacher, weil der Empfänger überhaupt nur > bei gültigen Daten diese an den PC weiterleitet (was ich durchaus > plausibel fänd). Dann braucht das BT Protokoll nicht mal verstanden > werden, oder der Klassiker eine Uart, irgendwo auf der Platine. Ja.
Wegstaben Verbuchsler schrieb: > hast du denn mal die Schweden kontaktiert, ob diese Infos rausrücken? Ja, per Mail. Keine Antwort bisher.
Kurt Bindl schrieb: > Vill. ist nur das letzte Byte die Prüfsumme. Aha. Und das vorletzte Byte ist die Zimmertemperatur in Buxtehude?
Frank M. schrieb: > Kurt Bindl schrieb: >> Vill. ist nur das letzte Byte die Prüfsumme. > > Aha. Und das vorletzte Byte ist die Zimmertemperatur in Buxtehude? Oder die Übertagungsnummer damit der MC erkennen kann wie alt die Daten schon sind. Kurt
Kurt Bindl schrieb: > Oder die Übertagungsnummer damit der MC erkennen kann wie alt die Daten > schon sind. Dann sind sie immer gleich alt. Ich bekomme nämlich von jedem Transponder zu jeder Tages-/Nachtzeit immer dieselben 6 Bytes - siehe Eröffnungsposting.
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.