CRC-Rätsel (IRDA)

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.

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.

Sorry, Bild vergessen.

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

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...

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

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...

Ist die ID vielleicht 4 Byte lang, aber nur 2 Byte aufgedruckt?

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.

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.

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.

hast du denn mal die Schweden kontaktiert, ob diese Infos rausrücken?

Wegstaben Verbuchsler schrieb:
> hast du denn mal die Schweden kontaktiert, ob diese Infos rausrücken?

Ja, per Mail. Keine Antwort bisher.

Frank M. schrieb:

...

Vill. ist nur das letzte Byte die Prüfsumme.

 Kurt

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.