HEX String aufschlüsseln/auswerten

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?

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.

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!

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?

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?

Ich bin raus.
So wird das nichts.

Warum schreibt der Arduino nicht schon die lesbaren Werte?

Wie hast du die Hexwerte erzeugt?
Bitte keine Prosa, zeig den Code.

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.

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.

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.

1

      rxId = CAN0.getCanId();                    // Get message ID

2

      if (rxId == XXX)

3

      {

4

5

        drehzahl = die richtigen Bytes aus der CAN Nachricht zusammensetzen

6

7

        Serial.print( "Drehzahl: " );

8

        Serial.println( drehzahl );

9

      }

10

...

Wie sind denn die Bytes in der CAN Nachricht zusammengesetzt? Welches 
Byte enthält welche Information?

Ich würde ja jetzt auf einen CAN-Logger fürs KFZ tippen und dass es ihm 
mehr darum geht herauszufinden, was sich hinter den hex-Werten verbirgt.

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

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

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.

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.

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

1

Low - High

2

3

          dezimal

4

79 01     377

5

76 01     374

6

75 01     373

7

73 01     371

8

...

sind das irgendwie plausible Werte?

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?

Und woher weißt du, dass es die richtige CAN-Message ist?

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?

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.

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.

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.

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