Hallo,
Ich habe einen seriellen Stream, wo am Ende eines Blocks eine Prüfsumme
mitgesendet wird.
Ich komme einfach nicht auf die Berechnungsgrundlage dieser Prüfsumme
und wäre für jeden Tip dankbar. 3 verschiedene Blöcke dieses Streams
habe ich unten aufgeführt.
Es ist weder XOR noch Quersummenberechnung. Ich habe keine Idee mehr.
Grüße
Klaus
Dezimal, Startbyte und Endbyte (beides 192) habe ich weggelassen.
4 126 1 2 16 5 0 0 0 0 25 12 1 2 3 4 5 6 7 8 9 10 11 12 0 0 Prüfsumme:
28
4 119 0 1 2 7 0 0 Prüfsumme: 6
4 120 0 1 2 7 0 0 Prüfsumme: 12
Hallo Joe,
es geht um die Kommunikation zwischen einem Prozessor und einem
Digitaltuner.
Ich möchte den Tuner extern steuern, bzw in ein Projekt einbinden. Dazu
muss ich wissen, wie er angesteuert wird. Er ist von Frontier Silicon
und es gibt absolut keine Datenblätter im Netz. Initialisierung, Band
scannen konnte ich so übernehmen. Aber ich benötige für eigene
Programmmethoden den Befehlssatz, den ich zZt. entkrypte.
Gruß
Klaus
Aus jeder Menge Recherche:
Start/Stopbyte war eine Annahme, bis ich einen kompletten Befehlssatz
zusammen hatte und diesen erfolgreich an den Tuner gesendet habe. Auch
die Checksum war erst Annahme, bis ich durch Zufall in einer Diy-Zeitung
über ein Projekt mit diesem Tuner gelesen habe. Das wars dann aber auch,
alles andere habe ich durch viel Ausprobieren, Try/Error
Klaus schrieb:> Aus jeder Menge Recherche:>> Start/Stopbyte war eine Annahme, bis ich einen kompletten Befehlssatz> zusammen hatte und diesen erfolgreich an den Tuner gesendet habe. Auch> die Checksum war erst Annahme, bis ich durch Zufall in einer Diy-Zeitung> über ein Projekt mit diesem Tuner gelesen habe. Das wars dann aber auch,> alles andere habe ich durch viel Ausprobieren, Try/Error
Tja, klingt mühsam.
Evtl. wäre ja der Autor des DIY Artikels ein Ansprechpartner...
Oh ja, mühsam:
Tuner aus Radio extrahiert, eigene Schaltung mit Stromversorgung
(3,3V/1,2V), Pegelwandler und Atmega gebaut, das Radio an den Atmega,
Atmega an Tuner und jede Menge seriell "geschnüffelt"..mehrmals in den
letzten 3 Monaten eingelagert und bei Lust wieder aufgebaut. Zeitung
anschreiben bringt nix, jeder, der mit dem Tuner arbeiten will, muss bei
Frontier Silicon ein Agreement unterschreiben und ist bei Strafe zur
geheimhaltung verpflichtet. Ausser Andeutungen oder abgeschwächte
Beschreibungen des Protokolls findet man nix...Ich habe z.B. eine
Stationstaste gespeichert, dann beim Streaming mitgeschnitten und
analysiert. Dann konnte ich den aufbereiteten Befehl erfolgreich an den
Tuner schicken und so habe ich fast alles rausbekommen: Blocknr,
Befehlstyp, Platzhalter usw...nur, um ein Programm zu schreiben, wo ich
mein Speichermanagement, Senderliste usw handle, muss ich wissen, wie
für den eigenen Befehlsblock die Checksumme lautet...
Verständlich.
Die zwei kürzeren Datensätze sind ganz interessant, da sich nur ein Byte
in den Nutzdaten geändert hat.
Ich denke es wäre hilfreich möglichst viele solche Beispiele zu haben.
Differenz der Summe der Daten ist eins, Unterschied der Prüfsummen ist
Faktor 2, könnte ein Bitshift um 1 nach links bedeuten. Ist aber mangels
Datenmenge erstmal reine Spekulation...
Ansonsten trifft man auf viele Beispiele für das "SLIP" Protokoll, wenn
man im Netz nach Protokollen mit delimiter 0xC0 (dec 192) sucht.
Evtl. ist dein Protokoll eine Abwandlung davon...
Was passiert eigentlich wenn die Checksumme falsch ist? Wird das
Kommando dann ignoriert?
Hi, Tobias.
Kann ich auch ausschließen, weil bei fehlerhafter Prüfsumme der Tuner
nicht reagiert und einfach stumm bleibt und bei der
Vorwärtsfehlerkorrektur wenigstens irgendwas vom Tuner zurückkommen
würde. Habe heute nochmals mit kompletten Block und danach Addition der
einzelnen Bytes nochmals crc durchprobiert...256 Möglichkeiten für das
Generatorpolynom...puh..nichts. Und wenn ich bei der Berechnung die
Checksumme als Ergebnis hatte und einen anderen Block mit dem
Generatorpolynom berechnet habe, passte wieder nix. Jetzt fängt`s an zu
nerven, werde das Projekt wohl erstmal einmotten...
Diese Firmwareentwickler von Frontier sind aber auch ein gehässiger
Haufen...:)
Gruß
Klaus
Klaus schrieb:> Habe heute nochmals mit kompletten Block und danach Addition der> einzelnen Bytes nochmals crc durchprobiert...256 Möglichkeiten für das> Generatorpolynom...puh..nichts.
Neben den 256 Polynomen musst du noch 256 Startwerte und 256 XOR-Werte
(also insgesamt 16777216 Möglichkeiten) durchprobieren. Mit RevEng geht
das auch ohne "puh" :)
Du könntest ja auch jedes Kommando einfach 256 mal (mit
unterschiedlicher "Prüfsumme") schicken.
Eine Kombination muss ja dann richtig sein, und die wird der Tuner dann
fressen...
Nicht besonders elegant, aber "works for me"...
Das zweite Byte sieht aus wie ein Frame Zähler. Es könnte sein, dass
damit aus einer Lookup Tabelle noch ein weiteres unbekanntes Byte in den
CRC gepackt wird.
Ebenso könnte der Frame Zähler nur bei korrektem Zählen zu einem
erfolgreichem Frame führen.
Joe F. schrieb:> Du könntest ja auch jedes Kommando einfach 256 mal (mit> unterschiedlicher "Prüfsumme") schicken.> Eine Kombination muss ja dann richtig sein, und die wird der Tuner dann> fressen...> Nicht besonders elegant, aber "works for me"...
Das würde bei einem Frame Zähler nicht funktionieren, da ich für jeden
Zählerwert den genauen CRC Wert (bei ansonstem gleichem Inhalt) kennen
müsste. Wären als 2^16 Möglichkeiten ;)
Erik B. schrieb:> Das würde bei einem Frame Zähler nicht funktionieren
Das stimmt zwar, wenn ich mir die Kommandos von Klaus zur Senderauswahl
angucke, glaube ich allerdings nicht, dass das ein Zähler ist.
Beim Starten des Gerätes werden hier vermutlich Register gesetzt, die in
dem Fall eben alle in aufeinanderfolgender Reihe angesprochen werden.
Moin,
Wird wohl die Frage sein, warum der Tunerhersteller den Affenzirkus mit
extra Byte veranstaltet: a.) Um sicherzugehen, dass die Nachricht
richtig empfangen wurde oder b.) Um sicherzugehen, dass nur
Unterschreiber des NDAs "richtige" Nachrichten erzeugen koennen.
Also ob das Extrabyte eher eine Fehlererkennung/korrektur oder eher eine
Signatur darstellt.
Fuer eine Fehlererkennung waere wohl CRC oder irgendwelche Pruefsummen
das Mittel der Wahl.
Fuer Signatur koennte man sich so beliebigen, fiesen Kram ausdenken,
dass es da ziemlich chancenlos ist draufzukommen; sogar wenn man die
Algorithmen wuesste.
Gruss
WK
Das mit dem extra Byte ist ja nur eine Idee.
Ich würde mal versuchen ein paar Frames mit evtl Zusatz-Byte in das oben
verlinkte CRC Reverse Tool zu packen.
Moin, Leute.
Joe seine Idee funktioniert, hatte das am Anfang ausprobiert. Bei
115200Baud wäre es auch nicht soo viel Zeit, bis der Tuner antwortet,
aber eben -wie Joe schrieb - nicht gerade elegant. Wäre aber meine
letzte Idee.
Die ersten beiden Byte sind tatsächlich nur Zähler, wenn das 2te Byte
"voll" ist, gibt es einen Übertrag ins erste Byte und Byte 2 fängt
wieder mit 0 an.
Ist Byte 1 auch voll, geht alles bei 0 wieder los. Der Tuner hat einen
Befehlsbuffer und der Zähler dient dazu, den ausgeführten Befehl vom
Proz zu identifizieren, der Tuner quittiert den Befehl mit dem
Zählerwert:
Beispiel:
Prozessor sendet:
c0 0 2 4 1 2 1 0 0 0 1 1 5b c0
Tuner antwortet:
c0 0 2 84 1 0 11 c0
Da ich diese Kontrolle nicht brauche/nutze, ist es relativ egal, was für
ein Zählerstand vorn steht.
Tatsächlich sind die Werte der ersten 2 Byte egal für den Befehl, wenn
die Checksum passt. Ich habe irgendwo mal gelesen, dass die 2 ersten
Byte auch Serial oder Serials genannt werden, kenne aber diese
Begrifflichkeit nicht in diesem Zusammenhang.
Gruß
Ich werfe einfach mal das hier in den Raum:
"fsapi - Frontier Silicon API for PHP"
https://github.com/flammy/fsapi
und
"fsapi-remote"
https://github.com/flammy/fsapi-remote
Ohne allerdings genauer gelesen zu haben, ob es dort Informationen gibt,
die die CRC-Berechnung beschreiben, aber vielleicht hilft Dir das ja
weiter...
Ich habe folgenden Text mal aus der DIY-Zeitung (Silicon Chip Online,
11/2010)rausgekramt:
The serial port runs at 115,200 bps and uses an 8-bit word with one stop
bit and no parity. The microcontroller sends commands to the Venice 7
module and receives data back from it. Error detection is accomplished
using a checksum appended to each packet sent.
Das was dann auch mit der Info im Netz.
Aus einer Examensarbeit,
Integrating FM/RDS/DAB in off-highway vehicles:
4.1.3 Communication protocol
The communication with the radio module is done by sending a series of
bytes. Depending on the structure different commands will be carried
out.
Since these commands are confidential and only for the consumers of
these radio modules I will not describe in detail the exact bytes being
used and only the structure.
Bissl Offtopic:
So ein Alarm gabs bei den analogen Tunern nicht. Der sehr gute
Sony-Tuner damals, I2C Protokoll, Datenblatt gezogen und losgelegt. Ich
kapier das nicht, was der Hersteller davon hat. Keystone zum Beispiel
verkauft ihren DAD-Tuner ab 5 Stück. Nach Vorlage des Kaufbeleges
bekommt man auch Datenblätter. Frontier Silicon wälzt bei Anfrage auf
den Radiohersteller ab.
Naja...und der muss die Klappe halten. Leider ist der Frontier-Tuner
nunmal von den Werten, Abschirmumg, Empfindlichkeit usw. der ideale
Tuner für meine Basteleien..und ich hab einige davon.
Hallo Wolfgang, danke für Deine Mühe.
Dabei geht es um Internetradio und Frontends usw. Frontier ist auch
irgendwie Anbieter für Internetradio-Tuner und betreibt einen
"Senderpool", kenne mich in dem Metier nicht so aus.
Gruß
Klaus schrieb:> der Tuner quittiert den Befehl mit dem> Zählerwert:
(...)
> Da ich diese Kontrolle nicht brauche/nutze, ist es relativ egal, was für> ein Zählerstand vorn steht.
Das ist ja noch besser.
Dann verwende doch immer den gleichen Zähler, wenn das den Prozessor
nicht stört.
Für "neue" Kommandos probierst du alle 256 mögliche Prüfsummen durch,
bis der Prozessor das Kommando quittiert.
Diese Prüfsumme merkst du dir dann für zukünftige Aufrufe des gleichen
Kommandos.
Das ist lustig, Joe:
Hatte nach Deinem letzten Post den selben Gedanken. Ich suche grad nach
einer Möglichkeit, irgendeine wiederkehrende Reaktion auf einen Fehler
zu bekommen. Sei es Datentechnisch, oder Elektronisch. Wenn schon
unelegant, dann aber elegant unelegant :)
Dann werde ich ein kleines Prog basteln, was mir Sendeplätze (Befehle)
generiert..von Speicherplatz 1 bis nn.
Da ich ja soweit bin, dass der Tuner beim Anschalten automatisch alle
Bereiche durchscannt, kann ich nach dem Scan die Sender abfragen. Die
Antwort für einen aktiven Sender vom Tuner kenne ich. Diese schreibe ich
ins EEPROM und habe so meine Senderliste.
Auf alle Fälle wieder was zum "Anfassen", gehe ich eben diesen Weg...
OK, ich habs geknackt :-)
Es ist eine Flechter Sum, und die beiden Resultate werden mit XOR
verknüpft.
Du brauchst zwei unsigned 8-Bit Zähler (A und B).
In A summierst du jedes Eingangsbyte auf (modulo 256) in B den
jeweiligen Wert von A.
Am Ende noch A XOR B, das ist die Checksum.
Das ist der Hammer....
Wär ich niee drauf gekommen, ist für mich immer nur eine TCP-lastige
rechnerei gewesen. Boah, vollsten Respekt.
Kannst Dir nicht vorstellen, wie ich mich freue, nach dieser Hürde
wieder voll weitermachen zu können. Werde das nachher
umsetzen...freufreu
Vielen Dank
Klaus
Scyte R. schrieb:> Ich finde es auch cool, wie bist du darauf gekommen?
Mit ziemlich viel Glück... ;-)
https://de.wikipedia.org/wiki/Prüfsumme
Darin von Flecher's Checksum gelesen, von der ich noch nie was gehört
habe.
https://de.wikipedia.org/wiki/Fletcher’s_Checksum
Das dann in Excel mal mit den vorhandenen Daten ausprobiert, und
geguckt, ob es für die beiden Summen irgendeine Operation gibt, um es
auf das 1 Checkbyte zu reduzieren (aufsummieren, subtrahieren, XOR). XOR
war dann ein Treffer.
2, 3 andere Datensätze ausprobiert, Resultat stimmte jeweils, done. ;-)
WOW, mal schnell Wikki und umgesetzt...Ich hatte Manchestercodierung,
Flechter usw mal in der Technikerschule...Gekonnt wechgehört. Hatte das
irgendwie in der TCP-Schublade....is ja auch schon ne Weile her. Nie
gebraucht. Weiß noch, dass das irgendwie in 3(?) oder vierte ISO-Schicht
gehört..
Achso, ich habe ich mal eins meiner Basteleien in "Zeigt her eure
Kunstwerke " in Projekte gepostet. Nur fair, nach soviel Hilfe.
Gerne, war eine nette kleine Übung.
Das "int main(int argc, char **argv);" brauchst du in der loop()
Funktion natürlich nicht (wirft vermutlich auch eine Compiler Warnung).
Das kennt ihr Arduino-Nutzer nicht mehr, aber main() ist die
Hauptfunktion eines jeden C-Programms. Ist in der Arduino-Umgebung schon
vordefiniert und vor euch versteckt...
Naja, in der ersten Hibbeligkeit erstmal ausprobiert und später
aufgeräumt. Ist schon in meinem Prog eingebunden, läuft super. In einem
Array ist der Grund-Datensatz, der durch eine Zählschleife die Bytes an
das data Array übergibt. So kann ich an jeder beliebigen Stelle meinen
Wert übergeben, am Ende wird die Prüfsumme berechnet. Dann alles in 192
verpackt und an den Tuner gesendet. War nen Kick, das Erste mal
umschalten und einen anderen Sender hören.
Die Arduino IDE bietet sich für mich an, für meine Elektronik-Projekte.
Die Programmerhardware natürlich selbst gebaut, Ehrensache :)
Jetzt, wo ich als Rentner aus Lust an der Sache progge, meistens
Phyton(ist so schön zickig :) oder für Microsoftrechner C#.
Gruß