Lesen vom COM Port teils Fehlerhaft bitte um hilfe

Warum machst du keinen Screenshots von der VM - dann kann man wenigsten alles klar erkennen

ich habe doch jetzt schon einige möglicherweise relevante Stellen im Protokoll aufgezeigt (viele davon bewegten sich z.B. in deinen angegebenen Temperaturbereich ) - nimm doch dieses Wissen und probiere ob du weitere Werte findest

der DocShoe hat die Sache herausgefunden das die Nr ganz vorne im Protokoll möglicherweise keine Laufnummer sondern Typkennung ist - weil wie du im meinem Sortier-Post gesehen hast sind dann die hintern 18 Bytes sehr homogen - die folgende 2 bytes sind wohle ein CRC16 oder sowas

du hast rumgespielt mit direktem schreiben um dann mit der 1982-Software zu prüfen

es gibt also echt einige Sachen die du machen kannst

btw: schreib mir doch mal eine mail an 35b_1p44v44y7ned@byom.de am besten mit Telefon-Nr

chirolog

Hab die Mail rausgeschickt

55 55 die (01 50) ergab die 80 und die 1. 80 könnnte die Kontrollernummer sein was die 1 darstellt frage.

ich habe ehrlich gesagt keine Ahnung was du da machst - nicht alle Daten in dem Protokoll sind 16Bit- wiso denkst du das [01 50] zusammengehört

wieder keine Antwort

chirolog

Ich dachte ein Protokoll kann nur eine bestimmte länge von Daten haben. Meiner Meinung nach wäre es nicht sinnvoll und fast unmöglich es so zu realesieren das 8 bit lange und 16 bit lange daten gemischt versand werden.
Kamm bisher in meiner Praxis noch nicht vor, zumindest nicht bei so alten system und bie so alten Protokolen, mann muss bedenke es ist auch ein altes gerät.

es wird und wurde immer gemischt - weil es einfach keinen Nachteil hat den passenden Typ zu wählen, das Protokoll wird dann einfach kleiner

ich habe noch nie ein Nicht-Daten-Variantes Protokoll gesehen - es macht auch einfach keinen Sinn, Wir sprechen hier von Inhalt nicht der Blockgrösse (welche hier ja fix ist) - aber selbst die Blockgrösse ist sehr häufig auch Variant
bei sehr trivialen Protokollen ist es so - aber nicht als Strategie, sondern weil die Daten eben alle gleich gross sind

chirolog

Du willst sagen das wir hier eine folge gemischter längen haben können ?
Sprich mal sind es 8 bit mal sind es 16 bit, mal sind es 32?
Dann verstehe ich nicht die Aussage von vorhin, sprich ich dachte das die letzten 2 Bytes Prüfsummen sind von CRC16 und ich versuche die jetzt zu überprüffen. Mit dem x^16Polygon und den Rest.
Also bin jetzt ganz verwirt, leider kommm ich mit den Zahlen kein stück weiter.
soll ich noch ergebnisse aufnehmen und zusenden.
ich verstehe nicht wieso wir die 22158 also die serien nummer so klar sehen und alles andere so schwär ist.
Wer hat eine idee wie die negativen zahlen abgebildet werden können.
Und die nachkomamma stellen.
Schreibt es mir hier rein ich google oder prüffe es selber solange mein wissensstand reicht.
Oder führt mir beispiele hier auf, oder vermuttungen ich überprüffe dann alles.

wir haben uns falsch verstanden...

ich meinte nur das ein Datensatz aus verschiedenen Datentypen bestehen kann

z.B. [uint8][uint8][uint16][uint32][uint16]...

d.h. die Struktur/Offsets der Inhalte in einem Datesatz sind wohl schon fix/stabil

ich habe das nur angesprochen weil du in deinem Post die 0x01 vor dem 0x50 fuer den Kontroller (falls es das ist) in eine Variable reingesteckt hast - oder deine Schreibweise war einfach nur verwirrend

ich verstehe nicht wieso wir die 22158 also die serien nummer so klar sehen und alles andere so schwär ist.
Wer hat eine idee wie die negativen zahlen abgebildet werden können.

deswegen ist es wichtig ueber Wert-Änderung z.B. nur die Betriebsstunden herauszufinden welche Bytes die Betriebsstunden sein müssen UNABHÄNGIG ob wir den Inhalt dann schon verstehen, z.B. koennten die Betriebsstunden ja auch eine Fließkommawert sein (den man ja in zig Arten kodieren kann) - alleine die Position waere schonmal wunderbar

hustbaer

3.die komplexitet ist nicht sehr groß und schwehr ich brauche auch nicht mehr als 10 bis 15 werte.
4. die erwarteten werte kann ich aus einem alten programm raussehen, welches von 1982 ist dies hab ich auf einem anderen rechner drauf es zeigt mir halt die werte an seriennummer , neigung , rollung, temperatur u.s.w das problem ist als neigung hab ich ein komma wert der mit - sein kann und wie der jetzt ausgelesen wird ist für mich auch eine frage, die werte können sich ändern dynamisch halt hängt von der position neigung u.s.w des läsers ab.

bist du sicher dass "der laser" die werte selbst berechnet? ich würde nämlich eher davon ausgehen dass der PC das macht. also "das programm von 1982".
d.h. durch "inspektion" des protokolls alleine wirst du nie draufkommen wie du die nötigen werte erhältst.
wenn dann bräuchtest du den source des DOS programms, oder müsstest dieses zumindest mit nem disassembler auseinendernehmen.

chirolog

bist du sicher dass "der laser" die werte selbst berechnet? ich würde nämlich eher davon ausgehen dass der PC das macht. also "das programm von 1982".
d.h. durch "inspektion" des protokolls alleine wirst du nie draufkommen wie du die nötigen werte erhältst.
wenn dann bräuchtest du den source des DOS programms, oder müsstest dieses zumindest mit nem disassembler auseinendernehmen.

Der Laser ist nicht mit mir verbunden. Ich bin mit der Zieltaffel verbunden sieh Bild Testversuch oben. Ja es kann sein dass die Zieltaffel Werte ausgibt und diese im Programm berechnet und interpretiert werden, vielleicht auch berechnet.
Aber die serriennummer wird so übertragen, und ich denke die werte von roll und nick winkel müssen auch so übertragen werden da dort sensoren diese als pegel rausgeben(stimmt könnte sein das diese auch berechnet werden).
Ja was mach ich den jetzt.
Ich frag mal gezielt wieso gibt er die serriennummer 22158 so raus und alle anderen nicht. Besteht die möglichkeit dass alle anderen berechnet werden?

Ich frag mal gezielt wieso gibt er die serriennummer 22158 so raus und alle anderen nicht.

die Seriennummer laesst sich nicht berechnen - darum kommt sie auch direkt

Besteht die möglichkeit dass alle anderen berechnet werden?

klar warum nicht?

Ja was mach ich den jetzt.

jetzt zum 10. mal - alle Werte so weit es geht ruhig stellen und schauen wo sich die bytes veraendern wenn du einen einzelnen Wert beeinflusst - solange den einzelnen Wert beeinflussen bis du sicher bist das byte n..m dadurch geaendert werden - dann kannst du dich genau auf diese paar bytes konzentrieren wie da wohl der wert drinn steckt

Hier sagt niemand das du schnell zur Lösung kommst - das kann Wochen dauern

hustbaer

chirolog schrieb:

Aber die serriennummer wird so übertragen,

s.u.

chirolog schrieb:

und ich denke die werte von roll und nick winkel müssen auch so übertragen werden da dort sensoren diese als pegel rausgeben(stimmt könnte sein das diese auch berechnet werden).

wieso gehst du davon aus? geh mal lieber davon aus dass die messwerte zumindest noch irgendwie gefiltert werden. bzw. ich behaupte mal: da ist gar kein sensor drauf der direkt nen winkel messen kann. d.h. der winkel muss aus irgendwelchen anderen messwerten berechnet werden.
kann jetzt natürlich sein dass du ganz ganz viel glück hast, und diese berechnung in der zieltafel gemacht wird. ich würde aber, speziell bei einem so alten system, eher davon ausgehen dass die berechnung im PC gemacht wird.
bzw. ich würde das sogar heute noch so implementieren, da es flexibler ist: man muss nicht extra ein firmware update machen wenn z.B. mit einer neuen softwareversion etwas an der berechnung verbessert wird.

chirolog schrieb:

Ja was mach ich den jetzt.

keine ahnung. weinen?

ich hab jetzt nicht die ganzen 8 seiten hier gelesen, also sorry falls du das schon beantwortet hast...: warum willst du das ding überhaupt mit ner neuen software auslesen?

chirolog schrieb:

Ich frag mal gezielt wieso gibt er die serriennummer 22158 so raus und alle anderen nicht.

WIE soll er die seriennummer denn sonst ausgeben??? soll er die extra verhunzen nur damit sie nicht so einfach erkennbar ist? wozu sollte das gut sein?

chirolog schrieb:

Besteht die möglichkeit dass alle anderen berechnet werden?

JA! siehe oben. irgendwo müssen die werte berechnet werden, da es mit an sicherheit grenzender wahrscheinlichkeit nicht einfach 1:1 ungefilterte messwerte sind. und da so ein PC einfacher zu programmieren ist als irgend ein kleines mess-kasterl, und es wie schon gesagt flexibler ist, hätte ich persönlich die berechnung ganz sicher im PC gemacht. und nicht im messkasterl.
was u.a. auch erklären würde wieso für eine messung so viele daten übertragen werden. weil er sich mehrere samples holt und dann filtert und rumrechnet.

chirolog

Ja aber wäre dann unsere vermutung nicht falsch, wo wir angenommen haben das die letzten 2 Bytes CRC16 Prüffsumme der übertragung wären?

chirolog

So nun mal paar antworten, wieso den winkel berechnung, wir haben eine spanung von -15 bis 15 z.B. in der Zieltaffel sind zwei wasserwagen, je nach neigung werden die werte anders angezeigt und übermittelt, so ungefähr, klar könnte ich noch ins detail gehen, aber ich denke für die meisten wird es verständlich sein.

JA! siehe oben. irgendwo müssen die werte berechnet werden, da es mit an sicherheit grenzender wahrscheinlichkeit nicht einfach 1:1 ungefilterte messwerte sind. und da so ein PC einfacher zu programmieren ist als irgend ein kleines mess-kasterl, und es wie schon gesagt flexibler ist, hätte ich persönlich die berechnung ganz sicher im PC gemacht. und nicht im messkasterl.
was u.a. auch erklären würde wieso für eine messung so viele daten übertragen werden. weil er sich mehrere samples holt und dann filtert und rumrechnet.

Das ist eine gute Vermuttung, ich hab heute gemerkt wenn ich selber so ein Datenstring über die rs232 schicke, immer wider den selben, dann pendelt sich der nick wert erst mit der zeit ein, z.B. er war auf 10,7 und ich schick im den string mit der 9,4, dann zeigt er zuerst die 9,8, dann die 9,6 dann die 9,5 und dann erst die 9,4, es hab ich erst heute gemerkt. Aber die Temperatur und all die anderen standart sachen ändern sich sofort. Ich hab ja geschrieben das ich eine 2 bis 3 sekunden verzögerung merke.
Ich werde morgen vom morgens die versuche durchlaufen lassen, alles aufzeichen , protokolieren und euch jede stunde die ergebnisse rausstellen.
Vielen Dank für die Tips.
Ich bedanke mich würklich bei allen die dabei sind und mir helfen ich hätte es nicht glauben können.

Ja aber wäre dann unsere vermutung nicht falsch, wo wir angenommen haben das die letzten 2 Bytes CRC16 Prüffsumme der übertragung wären?

Was hat das eine mit dem anderen zu tun - die Checksumme (wenn es denn eine ist - kann auch ganz was anderes oder eine andere hausgemachte Checksumme sein) interessiert sich doch normalerweise nie für den Inhalt der mit Ihr validiertbar gemacht wird

hustbaer

genau.

nur dass die komplizierten berechnungen nicht im mess-kasterl gemacht werden heisst ja nicht dass das mess-kasterl nicht mal fähig ist eine CRC zu berechnen.
und da ne CRC, speziell bei einer so unsicheren übertragungsart wie RS232, eine tolle sache ist, ... schickt das mess-kasterl halt ne CRC mit.

also kein widerspruch.

hustbaer

ps: wenn du da eh aufgezeichnete daten reinschicken kannst, dann kannst du ja auch "geschummelte" daten reinschicken.

=> hast du schon probiert einfach mal das eine oder andere byte in einer aufgezeichneten messkasterl-message zu ändern, und diese geänderte message reinzuschicken?

dabei könnte dich natürlich eine evtl. vorhandene prüfsumme stören. was aber schonmal ein guter test wäre um rauszufinden ob die kommunikation irgendwie abgesichert ist.

chirolog

Ja ich hab versuche eine message zu schicken und ja es gibt eine Prüffsumme.
Bei einer veränderten message schreibt mir das Programm, übertragen daten Fehlerhaft.

chirolog

Ich versuche mit dem Umrechner die RCR zu ermitteln für meine Daten, leide ohne erfolg, was sagt Ihr dazu.
http://www.lammertbies.nl/comm/info/crc-calculation.html
z.B.

ff ff ff ff 07 81 00 00 48 7d 01 50 8e 56 03 08 09 00 10 00 0a 00 12 00 08 00 10 00 0a 00 10 00 10 00 0f 00 12 00 10 00 12 00 0f 00 12 00 0e 00 12 00 0e 00 10 00 0c 00 00 00 00 00 00 00 ff 0f 00 00 22 00 ff 0f 00 00 00 00 53 00 09 03 38 09 ff 07 02 00 00 00 00 00 00 00 a6 e2 df c1 57 b2 e4 3b 05 81 73 32 e1 a6 ad af 81 7f

Der Gedanke war dass die 81 7f die Prüfsumme ist.

Bei einer veränderten message schreibt mir das Programm, übertragen daten Fehlerhaft.

Poste mal die 100% exakte Fehlermeldung - oder besser einen Screenshot davon, moeglicherweise findet man die in der EXE