Guten Tag zusammen,
ich habe meinen Mikrocontroller so programmiert das er mir einen HEX
String auswirft.
Nun möchte ich diesen HEX String auswerten.
In der 8 Byte Nachricht z.B. 01 02 03 04 05 06 07, stehen ja mehrere
Werte drin die man auswerten kann und diese Werte verändern sich auch.
Hat jemand einen Tipp wie ich nun an einen bestimmten Wert komme bzw ihn
auswerten kann.
Wäre euch sehr dankbar für eine hilfreiche Anwtwort
mit freundlichen Grüßen
ti123 schrieb:> Wie ich das Programm schreiben muss.
genauso wie du es bei deinen Mikrocontroller gemacht hast.
Man entscheidet sich für eine Programmiersprache und besorgt sie die
Passenden Tools und fängt einfach an.
ti123 schrieb:> Guten Tag zusammen,>> ich habe meinen Mikrocontroller so programmiert das er mir einen HEX> String auswirft.
wohin?
LCD? UART?
Wo?
> Nun möchte ich diesen HEX String auswerten.
Na dann mach das. Ein String ist ein String. Also erst mal eine
Ansammlung von Zeichen. D.h. man könnte da mit Textfunktionen ranngehen.
> In der 8 Byte Nachricht z.B. 01 02 03 04 05 06 07, stehen ja mehrere> Werte drin die man auswerten kann und diese Werte verändern sich auch.
Nachricht ist schön. Aber woher weisst du zb, wo ein Nachricht anfängt
und wo sie aufhört? Wenn du das noch nicht gemacht hast, dann ist das
zunächst mal eine ziemlich gute Idee, den Empfänger in die Lage zu
versetzen, dass er genau das kann: rausfinden, wann eine neue Nachricht
anfängt. Datenübertragung beinhaltet immer auch eine gewisse Metaebene,
in der man die eigentlich zu übertragenden Daten mit Zusatzinformation
ergänzt, die den Empfänger leiten können. Denn ohne diese Metadaten
steht der im Regen, dass er bei
1
... 04 05 BC 85 45 EF A4 B2 29 45 03 08 ....
keine Ahnung hat, wo eigentlich eine Nachricht anfängt. Stell dir das so
vor, dass du dich in eine bereits laufende Unterhaltung am Telefon
einklinkst und aus dem Gehörten irgendeinen Sinn machen musst. Ohne
Metaebene (zb Sprechpausen oder Betonung, die dir sagt wann ein Satz zu
Ende ist) ist das schwierig.
Dann natürlich noch die Frage: Wer wertet bei dir eigentlich aus? Wer
ist der Empfänger?
mochte die richtigen Werte ja dann auf einem Monitor ausgeben, direkt
über den Mikrocontroller..
es ist ja sicher nicht ganz so einfach, einfach ein Programm zu
schreiben welches die Werte dann so auswertet und direkt anzeigt.
oder denke ich ja zu kompliziert?
Was gibt es denn für Tools?
ti123 schrieb:> oder denke ich ja zu kompliziert?
Ich denke schon.
Wenn du ans andere Ende deiner UART zb einen PC mit einem
Terminalprogramm hängst, dann kann der µC alles was 'zu sagen hat' im
Klartext ausgeben und das steht dann auch genau so am Terminal.
Alles in allem ist deine Fragestellung mehr als verworren.
Gebe zur Zeit nur über den Serielen Monitor der Arduino Software aus.
tut mir leid für die nicht gut ausgedrückte Fragstellung..
Wo mein startbyte anfängt kann ich aus einem Datenblatt entnehmen.
Dieses beinhaltet dann auch das Startbit und die Signallänge.
ti123 schrieb:> Gebe zur Zeit nur über den Serielen Monitor der Arduino Software aus.>> tut mir leid für die nicht gut ausgedrückte Fragstellung..
Ok, brauchst dich nicht entschuldigen. Das Stichwort 'Arduino' sagt
bereits alles.
> Wo mein startbyte anfängt kann ich aus einem Datenblatt entnehmen.
?
welches Datenblatt?
Ich denke 'DEIN PROGRAMM' erzeugt die Nachricht.
Du wirst doch wissen, was du programmiert hast!
Ja das ist richtig, dass mein Programm die Nachricht erzeugt, also den 8
Byte HEx string.
Weiß nur nicht wie ich Nachricht jetzt anhand von Startbyte, Startbit
und so aufschlüsseln kann bzw wie ich das programmieren soll in der
Arduino Software.
Das programmieren bis zum Erhalten der HEX Nachricht war ja noch realtiv
nachvollziehbar alles
Ehrlich.
Ich kenn mich immer noch nicht richtig aus, wonach du eigentlich
wirklich fragst.
Zeig doch mal, was du bis jetzt hast. Sonst wird das in 2 Wochen immer
noch nichts, wenn du weiter um den heissen Brei rumredest.
> mochte die richtigen Werte ja dann auf einem Monitor ausgeben, direkt über den
Mikrocontroller..
So ein Monitor steht ja nicht im luftleeren Raum.
Ist der an deinen Arduino angeschlossen? Wie wird der angesprochen?
Jetzt schreib doch bitte nochmal genau was du willst.
So wie du es bisher beschreibst, hast du die Aufgabe erfüllt: Du willst
einen String auf einem Monitor ausgeben, was du ja durch den
Arduino-SerialMonitor bereits machst.
Wenn du aber mit Monitor beispielsweise ein LCD meinst, musst du nicht
über die UART sondern über die LiquidCrystal-Library den Text
darstellen.
Willst du das ganze auf einem PC-Monitor ausgeben, musst du auf dem
entsprechenden PC in der Programmiersprache deiner Wahl ein Programm
schreiben, das dir von der Seriellen die Daten holt und entsprechend
formatiert darstellt.
Der HEX String enthält mehrere Informationen von denen ich nur bestimmte
herausfiltern möchte und dann nicht im HEX darstellen möchte sondern als
einen reelen Wert:-)
Z.B 2500 1/min
ti123 schrieb:> Ausgabe ist eigentlich egal..>> ob LCD oder TFT.. das bekomm ich ja auch schon hin..
Was du alles kannst. Und dann scheiterst du am Umrechnen eines
Hex-String?
ti123 schrieb:> Ausgabe ist eigentlich egal..>> ob LCD oder TFT.. das bekomm ich ja auch schon hin..
du kannst nicht mal richtig dein Problem beschreiben.
Dirk B. schrieb:> Warum schreibt der Arduino nicht schon die lesbaren Werte?
:-)
Soll ich raten?
Weil das hier
> ich habe meinen Mikrocontroller so programmiert
sagen wir mal eine freie Interpretation von
"Ich habe im Web ein Programm gefunden, welches genau das macht und es
auf meinen Arduino gebrannt und jetzt weiss ich nicht mehr weiter"
ist.
Wir gehen natürlich davon aus, dass er das Programm geschrieben hätte.
Nur ist dem nicht so. Und so redet man dann seit ein einhalb Stunden
aneinander vorbei. Eben das 'Arduino-Dilemma' in Reinkultur.
Naja hätte ja sein können das mir echt mal jemand helfen kann.
Finde habe mich gar nicht so unverständlich ausgedrückt.
Und kopiert ist schonmal gar nichts @ Karl Heinz
danke euch trotzdem.
ti123 schrieb:> Finde habe mich gar nicht so unverständlich ausgedrückt.
So wie ich das sehe, bist du der einzige mit dieser Meinung.
> Und kopiert ist schonmal gar nichts @ Karl Heinz
:-)
Wenn du nach ein einhalb Stunden immer noch nicht mit deinem Code
rausrückst, dann spricht das eine deutliche Sprache. Du bist nicht der
erste, der hier Hilfe sucht.
Auch wenn Eltern nichts sagen, wenn ihr Nachwuchs nicht ganz bei der
Wahrheit bleibt, sie wissen es immer. So ähnlich auch hier. Im Laufe der
Jahre haben die Dauergäste hier schon ein gewisses Gespür dafür
entwickelt, wann etwas faul ist und wann sich Informationen in der
Fragestellung beissen. Auf der einen Seite stehen die tollsten
Programme, die angeblich selbst geschrieben wurden, auf der anderen
Seite stehen dann Fragen nach trivialen Dingen. Das ist, wie wenn ein
angeblicher Herzchirurg danach fragt, wie rum man ein Heftpflaster
aufkleben muss.
Spiel mit offenen Karten, zeig her was du hast, zeig den Systemaufbau,
benenne Dinge (wie zb welchen Monitor du hast oder was du dir als
Monitor vorstellst) und die ganze Sache sieht ganz anders aus. Denn aus
dem Gestammel, das du bisher von dir gegeben hast, kann man nichts
entnehmen ausser einer gewissen Absichtserklärung "Ich will .."
Karl Heinz schrieb:> Wenn du nach ein einhalb Stunden immer noch nicht mit deinem Code> rausrückst, dann spricht das eine deutliche Sprache.
Ich sehe das genauso. Er schreibt zwar, dass er eine Hex-Ausgabe macht
(wohin eigentlich?), aber er lässt offen, ob
a) das einfach 8 Bytes in Rohform <01><02>...<08>
oder
b) ein formatierter, terminierter String "0102030405060708"
ist.
Ich tippe auf a), denn ich vermute, dass der "Arduino Monitor" die
Zeichen in einen String mit Hex-Zahlen umwandelt und nicht sein
Programm.
Aber ohne diese genaue Info wird das nichts.
Zudem fehlt die Angabe, ob es sich hier um
A) 8 8-Bit-Zahlen mit dem Wertebereich 0...255,
B) 4 16-Bit-Zahlen mit dem Wertebereich 0...65536,
C) 2 32-Bit-Zahlen mit dem Wertebereich (selber ausrechnen ;-) )
handelt und wie diese angeordnet sind - Stichwort Endian. Deweiteren
fehlt die Angabe, ob diese Zahlen vorzeichenbehaftet sind oder nicht.
@TO: Deine bisherigen Infos haben daher den Informationsgehalt nahe
Null.
Wenn Du es nicht besser beschreiben kannst, ist das auch kein Programm,
welches Du selbst entwickelt hast.
Frank M. schrieb:> Ich sehe das genauso. Er schreibt zwar, dass er eine Hex-Ausgabe macht> (wohin eigentlich?), aber er lässt offen, ob>> a) das einfach 8 Bytes in Rohform <01><02>...<08>>> oder>> b) ein formatierter, terminierter String "0102030405060708">> ist.>> Ich tippe auf a), denn ich vermute, dass der "Arduino Monitor" die> Zeichen in einen String mit Hex-Zahlen umwandelt und nicht sein> Programm.
Erhebt sich ja auch die Frage, was das für Werte sind, woher die kommen
und warum man die über ein Hex-Binär-Text (such dir was aus) Telegramm
ausgeben muss (wo auch immer) und nicht ganz einfach in Textform im
Klartext an der UART bzw. vom Programm aus gleich direkt auf ein LCD
schreibt. Es mag ja gute Gründe dafür geben, das nicht direkt vom
Arduino aus zu machen. Nur bis jetzt seh ich die nicht.
Heck, bis jetzt weiss ich ja noch nicht mal, ob die Absicht jetzt darin
besteht einen 2-ten Arduino einzusetzen, der denn am Monitor die Anzeige
macht, oder ab da ein PC dafür abgestellt werden soll oder wie oder was.
Lieber ti123
Kommunikation beruht auf Verständigung. Du must Dich verständlich
machen. Niemand ist hier bösen Willens.
Zeig Dein Programm, schäm dich nicht. Wir haben Alle mit unserem ersten
Programm angefangen.
Zeig was Du gebaut und programmiert hast.
Wenn das gezeigte HEX String Dein Zwischenergebnis ist zeige uns was Du
als Endergebniss haben willst.
Also textlich die Koversion Deiner Hex Zechen in ja was?
Nix für ungut
Klausb
ti123 schrieb:> Finde habe mich gar nicht so unverständlich ausgedrückt.
Da ist nichts verständlich!
Um bei deinem Beispiel zu bleiben:
Wie hast du die 2500 1/min in die Hexziffern gewandelt?
Zeig es, und wir zeigen dir wie du es wieder zurück wandelst.
ti123 schrieb:> Daraus möchte ich jetzt gerne den Wert für eine Drehzahl von einem Pkw> ermitteln.
Dann ist es das vernünftigste, gar nicht erst die Nachricht in Hex zu
übertragen, sondern hier
1
rxId=CAN0.getCanId();// Get message ID
2
if(rxId==XXX)
3
{
4
...
bereits die Auswertung zu machen und aus den Bytes in der CAN-Nachricht
den Zahlenwert zusammenzusetzen und den dann ganz einfach mit einem
Serial.println auszugeben.
Das ist doch ein Fortschritt.
Jetzt sag uns noch was soll z.B. aus 00 00 F8 79 01 00 7E 41
werden? Hat jedes Beyte eine eigene Bedeutung oder nur jede Zeile.
Welche?
ti123 schrieb:> Daraus möchte ich jetzt gerne den Wert für eine Drehzahl von einem Pkw> ermitteln.
Dann wende Dich an den Fahrzeughersteller, er soll Dir die
Protokollbeschreibung zusenden.
Peter Dannegger schrieb:> ti123 schrieb:>> Daraus möchte ich jetzt gerne den Wert für eine Drehzahl von einem Pkw>> ermitteln.>> Dann wende Dich an den Fahrzeughersteller, er soll Dir die> Protokollbeschreibung zusenden.
Optimist ;-)
ti123 schrieb:> hier ist mein Programm:
Prima, geht doch!
> im serial Monitor wird folgendes abgebildet:>
1
> ID: XXX Data: 00 00 F8 79 01 00 7E 41
2
> ID: XXX Data: 00 00 F8 76 01 00 93 41
3
> ID: XXX Data: 00 00 F8 75 01 00 93 41
4
> ID: XXX Data: 00 00 F8 73 01 00 A8 41
5
> ID: XXX Data: 00 00 F8 72 01 00 BD 41
6
> ID: XXX Data: 00 00 F8 71 01 00 D2 41
7
>
> Daraus möchte ich jetzt gerne den Wert für eine Drehzahl von einem Pkw> ermitteln.
Das sind offenbar CAN-Daten. Hier wird die eigentliche Drehzahl in einen
CAN-Frame eingebettet. Was davon jetzt Nutzdaten sind, entzieht sich
meiner Kenntnis. Man müsste jetzt erstmal wissen, welche dieser 8 Zahlen
für den eignetlichen Drehzahl-Wert stehen.
Dann ist es ganz einfach. Also heraus mit den Infos: Welche der 8
Zeichen beinhalten die eigentliche Nutzinformation "Drehzahl"?
Um welchen Wagen geht es denn? Und an welchem CAN-Bus loggst du?
Hat es einen tieferen Sinn, dass bei den IDs nur XXX steht?
Zu VAG findet sich einiges unter www.canhack.de
mal ein bischen mit den Werten gespielt.
Die letzten 2 Bytes könnten ein 16 Bit Wert mit Little-Endianess sein.
1
7E 41 = dez 16766
2
93 41 = 16787
3
93 41 = 16787
4
A8 41 = 16808
5
BD 41 = 16829
6
D2 41 = 16850
dazu fällt mir nur ein, dass es sich ev. um einen Fixed Point Wert mit
einer Nachkommastelle handelt. 16766 könnten 1676,6 U/min sein. Könnte
aber auch ganz was anderes sein. Auffallend ist natürlich, dass die
Werte aufsteigend sind, was man bei einer Drehzahl nicht unbedingt
erwarten würde.
@TO wäre dieser Wert denn plausibel?
Um das zu entschlüsseln, wäre natürlich gut, wenn man ungefähr wüsste
was rauskommen soll (wenn man es überhaupt schaffen kann). D.h. man
braucht Datensätze, von denen man schon weiss, welche Daten prinzipiell
drinn stecken müssten.
Karl Heinz schrieb:> dazu fällt mir nur ein, dass es sich ev. um einen Fixed Point Wert mit> einer Nachkommastelle handelt.
Könnte natürlich auch genausogut eine Checksumme sein.
Karl Heinz schrieb:> Die letzten 2 Bytes könnten ein 16 Bit Wert mit Little-Endianess sein.> [...]> dazu fällt mir nur ein, dass es sich ev. um einen Fixed Point Wert mit> einer Nachkommastelle handelt.
Das ist aber schon ziemlich weit hergeholt, oder? ;-)
Der TO sollte wenigstens sagen, welche Drehzahl der Motor zum Zeitpunkt
der Aufzeichnung hatte. Dann kann man vielleicht auf die Position der
Bytes und auf den Wertebereich schließen.
> Welche der 8 Zeichen beinhalten die eigentliche Nutzinformation "Drehzahl"?
das wäre das 4.Byte wo die Drehzahl drin stehen soll.
Starbit = 0
Signal Länge 12
Frank M. schrieb:> Karl Heinz schrieb:>> Die letzten 2 Bytes könnten ein 16 Bit Wert mit Little-Endianess sein.>> [...]>> dazu fällt mir nur ein, dass es sich ev. um einen Fixed Point Wert mit>> einer Nachkommastelle handelt.>> Das ist aber schon ziemlich weit hergeholt, oder? ;-)
Natürlich ist das weit hergeholt.
Du hättest durchaus auch den Begriff 'Spekulation' benutzen können.
ti123 schrieb:>> Welche der 8 Zeichen beinhalten die eigentliche Nutzinformation "Drehzahl"?>> das wäre das 4.Byte wo die Drehzahl drin stehen soll.
Zeig doch mal die Quelle, von der du diese Information hast.
> Starbit = 0> Signal Länge 12
Das ergibt keinen Sinn. Der Begriff 'Startbit' ist hier so nicht
anwendbar und hat normalerweise eine ganz andere Bedeutung in einem ganz
anderen Zusammenhang.
Zeig deine Quelle und spiel nicht schon wieder das Versteck-Spielchen.
ti123 schrieb:>> Welche der 8 Zeichen beinhalten die eigentliche Nutzinformation "Drehzahl"?>> das wäre das 4.Byte wo die Drehzahl drin stehen soll.> Starbit = 0> Signal Länge 12
Bei einer Länge von 12 Bits(?) wären es eher 8 Bit vom 4ten Byte und
weitere 4 Bit vom 5ten Byte in Little-Endian:
ID: XXX Data: 00 00 F8 79 01 00 7E 41 -> 7901 -> 0179 -> 377 U/s
ID: XXX Data: 00 00 F8 76 01 00 93 41 -> 7601 -> 0176 -> 374 U/s
Scheint mir arg niedrig zu sein für ein Auto.
Wenn es allerdings 4 Bit vom 3ten Byte und 8 Bit vom 8ten Byte sind,
dann kommt da raus in Big-Endian:
ID: XXX Data: 00 00 F8 79 01 00 7E 41 -> 0879 -> 2169 U/s
ID: XXX Data: 00 00 F8 76 01 00 93 41 -> 0876 -> 2166 U/s
Jetzt verrate bitte noch die eigentliche Drehzahl, dann geht das Raten
einfacher.
ti123 schrieb:> mehr habe ich leider nicht.
Verdammt, Du wirst doch wohl noch die ungefähre Drehzahl sagen können,
oder nicht? War das Standgas oder bei 280km/h auf der Autobahn?
Jedes bischen Info erst nach 10fachem Nachfragen.
Was für ein Auto?
Warum kommst du zu dem Schluss das in den Can Daten eine Drehzahl
stecken soll?
welche Drehzahl hat zu dem Masszeitpunkt der Drehzahlmesser angezeigt?
...
Sag mal arbeitest du für eine Autoknackerbande oder warum bist du so
geheimnisvoll?
Wie soll man dir da helfen? Karl Heinz hat heute echt wieder seinen
gutmütigen Tag.
@ti
Dir scheint nicht klar zu sein, dass es jetzt darum geht, ein Rätsel zu
lösen. So ungefähr wie bei den Hyroglyphen. Noch weiss niemand, wie die
Bits oder Bytes zusammen gehören (ausser zufällig hat das schon mal wer
gesehen. In dem Fall: bitte vortreten).
Noch kann in diesen Daten alles oder nichts drinnen sein. Es geht darum
Zusammenhänge zu finden, die in den Daten stecken. Dazu muss man aber
wissen was rauskommen muss.
Welche Drehzahl ist hier drinn
1
ID: XXX Data: 00 00 F8 79 01 00 7E 41
versteckt? Welcher Zahlenwert muss rauskommen, zumindest ungefähr. Dann
kann man mal Hypothesen bilden, wie da die Zusammenhänge sein könnten.
ti123 schrieb:> Die Drehzahl müsste ein bisschen über Leerlauf drehzahl sein.> Sprich ca. 1000 1/min
Zurück zum Auto.
Drehzahl auf 2000 U/min und Daten aufzeichnen.
3000 U/min und Daten aufzeichnen.
Wie gesagt: Es gilt ein Rätsel zu lösen. Jedes Fitzelchen Information
kann dazu beitragen.
ti123 schrieb:> Die Drehzahl müsste ein bisschen über Leerlauf drehzahl sein.> Sprich ca. 1000 1/min
Okay, dann unteres Nibble vom 3ten Byte und 8 Bit vom 4ten Byte geteilt
durch 2:
ID: XXX Data: 00 00 F8 79 01 00 7E 41 -> 0879H -> 2169 -> 1084,5 U/s
ID: XXX Data: 00 00 F8 76 01 00 93 41 -> 0876H -> 2166 -> 1083,0 U/s
Bau das folgendermaßen ein ins Programm:
int drehzahl = (((rxBuf[2] & 0x0F) << 8) | (rxBuf[3])) / 2;
Serial.println( drehzahl );
und teste, ob die Werte plausibel sind.
Wenn ich mir die jetzigen Infos und die wirkliche Problemstellung
angucke, und dann den Eingangspost, dann frage ich mich wirklich welche
Antwort der TE denn da bitte erwartet hatte?
Eine wichtige Frage ist immer noch offen: Ist das "XXX" immer die
gleiche ID, oder sind das unterschiedliche IDs? So viel Rätselraten
hatten wir lange nicht...
Verrate bitte, was hinter den XXX steckt und um welchen Fahrzeugtyp es
sich handelt. Sonst stochern wir in einem halben Jahr immer noch im
Nebel.
Frank M. schrieb:> Okay, dann unteres Nibble vom 3ten Byte und 8 Bit vom 4ten Byte geteilt> durch 2:
12 Bit gibt max. 4095
Durch 2 bleiben 2048. Für mein Gefühl ist das ein bisschen wenig.
npn schrieb:> Eine wichtige Frage ist immer noch offen: Ist das "XXX" immer die> gleiche ID, oder sind das unterschiedliche IDs? So viel Rätselraten> hatten wir lange nicht...
Hab ich mich schon gefragt, warum er die Id unleserlich gemacht hat.
Aber - eigentlich - Ich glaub, ich will es gar nicht wissen.
ti123 schrieb:>>Ist das "XXX" immer die gleiche ID>> ja das ist immer die gleiche ID, der Fahrzeugtyp spielt in dem Fall> keine rolle
sag mal hast du sie noch alle?
Seit 3 Stunden kämpfen wir hier um jedes kleine bischen Information, das
auch nur irgendwie hilfreich sein könnte und alles was von dir kommt,
ist ein 'spielt keine Rolle'.
Wenn du das alles so genau weisst, dann mach doch deinen Scheiss
alleine. Ich kann mir wirklich Besseres vorstellen, als deine Rätsel zu
lösen und dann auch noch von dir Prügel zwischen die Beine zu bekommen.
Dirk B. schrieb:> Durch 2 bleiben 2048. Für mein Gefühl ist das ein bisschen wenig.
Da hast Du verdammt recht. Aber was soll ich anderes mit der Information
"Länge 12" anfangen? Da gehts nicht weiter als bis 2048.
Ich wollte dem TO auch eher die Sinnlosigkeit verdeutlichen, in einem
unbekannten Datenwust herumzustochern.
Vielleicht zeichnet er auch nur die Außentemperatur auf und weiß es
nicht...
Da hilft nur das, was Karl Heinz sagte:
- Aufzeichnung der Daten über einen größeren Meßbereich
- Vergleich der Daten mit den Drehzahlen
Dann kommt man vielleicht dahinter.
ti123 schrieb:> ja das ist immer die gleiche ID, der Fahrzeugtyp spielt in dem Fall> keine rolle
Doch, denn jeder Hersteller macht das anders. Meinetwegen multipliziere
doch alle 8 Meßwerte miteinander, ziehe die Wurzel, subtrahiere die
Außentemperatur, teile sie durch die Sekunden seit dem 01.01.1970 und
addiere letztendlich Dein Alter dazu.
Vielleicht kommt dann ja was sinnvolles raus.
@Karl Heinz
bin dir doch auch schon sehr dankbar für deine Tipps.
bin halt richtiger neuling auf diesem Gebiet und habe nicht viel
erfahrung mit sowas.
kann ja keiner wissen das das so zahlreich diskutiert wird hier, weil
sonst eher weniger leute antworten.
werde nochmal weitere Infos versuchen zu sammeln.
will doch selber keine Rätselraten hier sondern eine Lösung, aber zur
ZEit habe ich noch nicht mehr.
Danke euch trotzdem sehr..
grüße
ti123 schrieb:> bin halt richtiger neuling auf diesem Gebiet und habe nicht viel> erfahrung mit sowas.>
Na dann beantworte doch endlich mal die Fragen der Leute, die dir helfen
wollen. Wie soll man das sonst machen, wenn du immer nur sagst "das
spielt keine Rolle"? Klar spielt es eine Rolle, sonst würden wir ja
nicht fragen!
> kann ja keiner wissen das das so zahlreich diskutiert wird hier, weil> sonst eher weniger leute antworten.
Du bist auf dem besten Weg dazu, daß hier auch alle abspringen, die dir
bisher helfen wollten. Sei froh, daß so viele helfen wollen. Aber du
schlägst uns permanent einen Stock zwischen die Beine...
>> werde nochmal weitere Infos versuchen zu sammeln.> will doch selber keine Rätselraten hier sondern eine Lösung, aber zur> ZEit habe ich noch nicht mehr.
Das stimmt doch nicht. Zum Beispiel die ID hast du mit "XXX" versteckt.
Warum? Die hast du auf jeden Fall, weil du ja sagst, die bleibt immer
gleich. Und die braucht man, um in Verbindung mit dem Fahrzeugtyp
herausbekommen zu können, was die Bedeutung der einzelnen Bytes bei
dieser ID ist. Also mach kein Geheimnis draus, sonst bin ich auch weg,
so wie viele andere.
Die XXX werden 7E8h sein.
Ob deine Nachricht tatsächtlich die Drehzahl ist kommt nicht über die ID
sondern über das 2. Datenbyte, wenn das 0Ch ist, sollte das die Drehzahl
sein, die dann in Byte 4 und 5 kodiert ist.
Die Drehzahl errechnet sich dann aus ((Byte4 * 256)+Byte5)/4
zumindest soweit ich das aus dem SAE Standard rauslesen kann. Und darum
geht es doch, ein Auto mit OBD-Interface, richtig?
Nachtrag: An deiner Stelle würde ich mir nen ELM327 besorgen und den
über den UART deines Arduinos ansprechen. Ich hätte zu sehr Angst, dass
ich irgendwas falsches Sende oder den Bus zum abstürzen bringe.
LG
Christopher
Christopher B. schrieb:> Die Drehzahl errechnet sich dann aus ((Byte4 * 256)+Byte5)/4
Ziemlich unwahrscheinlich bei:
1
ID: XXX Data: 00 00 F8 79 01 00 7E 41
2
ID: XXX Data: 00 00 F8 76 01 00 93 41
3
ID: XXX Data: 00 00 F8 75 01 00 93 41
4
ID: XXX Data: 00 00 F8 73 01 00 A8 41
5
ID: XXX Data: 00 00 F8 72 01 00 BD 41
6
ID: XXX Data: 00 00 F8 71 01 00 D2 41
Was hier auffällt, dass sich Byte4 ändert, Byte5 sich aber nicht. Das
spricht eher dafür, dass Byte4 ein niederwertiges Byte ist. Ich glaube
nicht, dass die Drehzahl in diskreten Stufen von 256 (bzw. 256/4)
springt.
Christopher B. schrieb:> sondern über das 2. Datenbyte, wenn das 0Ch ist, sollte das die Drehzahl> sein, die dann in Byte 4 und 5 kodiert ist.
Die Daten von ti123 passen nicht zu dieser Aussage, da das 2. Datenbyte
nicht 0x0C ist.
Dirk B. schrieb:> Die Daten von ti123 passen nicht zu dieser Aussage, da das 2. Datenbyte> nicht 0x0C ist.
Das ist richtig. Das heißt wenn es sich tatsächlich um ein neueres Auto
(BJ98-07, AFAIK) handelt, dann sollte es das SAE Protokoll sein, was
wieder im Umkehrschluss bedeutet, dass seine Daten die er da gepostet
hat gar keine Drehzahl enthalten.
Und das scheint mir gar nicht so abwegig. Offensichtlich weiß er ja gar
nicht was er da tut.
> Die Daten von ti123 passen nicht zu dieser Aussage, da das 2. Datenbyte> nicht 0x0C ist
bei 0xOC würde er ja wahrscheinlich direkt über den OBD Anschluss gehen.
0C --> festgelegter PID für die Drehzahl.
Hier ist es ja wahrscheinlich so das er direkt an den CAN geht..
Christopher B. schrieb:> Und das scheint mir gar nicht so abwegig. Offensichtlich weiß er ja gar> nicht was er da tut.
Sehe ich genauso. Das lässt schon die Entwicklung dieses Threads
erkennen. Am Anfang wollte er nur wissen, wie man aus Hex-Zahlen, die in
einem String stehen, einen numerischen Wert generiert. Tatsächlich geht
es aber um die Tiefen von irgendwelchen CAN-Protokollen.
Blauäugiger geht es nicht.
Frank M. schrieb:> Blauäugiger geht es nicht.
Richtig. Vor allem, weil er ja immer noch nicht verraten hat, um welche
CAN-ID es sich handelt und um welchen Fahrzeugtyp. Ich verstehe nicht,
warum er so ein Geheimnis draus macht. Er weiß es ja auf jeden Fall,
sagt es aber nicht.
Christopher B. schrieb:> Nachtrag: An deiner Stelle würde ich mir nen ELM327 besorgen und den> über den UART deines Arduinos ansprechen. Ich hätte zu sehr Angst, dass> ich irgendwas falsches Sende oder den Bus zum abstürzen bringe.
Nein, das kann und darf nicht möglich sein. Eine der wichtigsten Specs
der OBD-II Schnittstelle sagt aus, das selbst Unsinn an dieser
Schnittstelle die Sicherheit und Funktion des Kfz nicht beeinflussen
dürfen.
Generell bewundere ich mal wieder die Geduld und Ruhe der meisten
Antwortenden hier. Ich hätte den Kunden wahrscheinlich schon über den
Tisch gezogen und kräftig auf den Kopf geklopft :-)
npn schrieb:> Richtig. Vor allem, weil er ja immer noch nicht verraten hat, um welche> CAN-ID es sich handelt und um welchen Fahrzeugtyp. Ich verstehe nicht,> warum er so ein Geheimnis draus macht. Er weiß es ja auf jeden Fall,> sagt es aber nicht.
Es ist bestimmt ein Auto, das erst in 2 Jahren auf den Markt kommt. Und
er hat den Auftrag, die Anzeige des Drehzahlmessers dafür zu entwickeln
;-))))
Matthias Sch. schrieb:> Nein, das kann und darf nicht möglich sein. Eine der wichtigsten Specs> der OBD-II Schnittstelle sagt aus, das selbst Unsinn an dieser> Schnittstelle die Sicherheit und Funktion des Kfz nicht beeinflussen> dürfen.
ok, das war mir nicht bewusst. Danke dafür. :-)
Thread beobachten
Seitenaufteilung abschalten