HEX String aufschlüsseln/auswerten

[ti123 (Gast)]

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

[Peter II (Gast)]

einfach ein Programm schreiben, was die Daten auswertet.

wo ist genau dein Problem?

[ti123 (Gast)]

Wie ich das Programm schreiben muss.

Bin relativ neu auf diesem Gebiet.

[Peter II (Gast)]

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.

[Karl H. (kbuchegg)]

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

  ... 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 (Gast)]

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?

[Karl H. (kbuchegg)]

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 (Gast)]

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.

[Karl H. (kbuchegg)]

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!

[ti123 (Gast)]

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

[Karl H. (kbuchegg)]

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?

[Nil (nilsnilss)]

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.

[ti123 (Gast)]

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 (Gast)]

Ausgabe ist eigentlich egal..

ob LCD oder TFT.. das bekomm ich ja auch schon hin..

[Cyblord -. (cyblord)]

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?

[Peter II (Gast)]

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.

[Karl H. (kbuchegg)]

Ich bin raus.
So wird das nichts.

[Dirk B. (dirkb2)]

Warum schreibt der Arduino nicht schon die lesbaren Werte?

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

[Karl H. (kbuchegg)]

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 (Gast)]

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.

[Karl H. (kbuchegg)]

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

[Frank M. (ukw) (Moderator)]

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.

[Karl H. (kbuchegg)]

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.

[klausb (Gast)]

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

[Dirk B. (dirkb2)]

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 (Gast)]

Hallo klausb

hier ist mein Programm:

#include <mcp_can.h>
#include <SPI.h>

long unsigned int rxId;
unsigned char len = 0;
unsigned char rxBuf[8];

MCP_CAN CAN0(10);                               // Set CS to pin 10


void setup()
{
  Serial.begin(115200);
  CAN0.begin(CAN_500KBPS);                       // init can bus : baudrate = 500k 
  pinMode(2, INPUT);                            // Setting pin 2 for /INT input
  Serial.println("TEST 1 2 3...");
}

void loop()
{
    if(!digitalRead(2))                         // If pin 2 is low, read receive buffer
    {
      CAN0.readMsgBuf(&len, rxBuf);              // Read data: len = data length, buf = data byte(s)
      rxId = CAN0.getCanId();                    // Get message ID
      if (rxId == XXX)
        {
      Serial.print("ID: ");
      Serial.print(rxId, HEX);
      Serial.print("  Data: ");
      for(int i = 0; i<len; i++)                // Print each byte of the data
      {
        if(rxBuf[i] < 0x10)                     // If data byte is less than 0x10, add a leading zero
        {
          Serial.print("0");
        }
        Serial.print(rxBuf[i], HEX);
        Serial.print(" ");
      }
      Serial.println();
    }
}
}

im serial Monitor wird folgendes abgebildet:

ID: XXX  Data: 00 00 F8 79 01 00 7E 41
ID: XXX  Data: 00 00 F8 76 01 00 93 41 
ID: XXX  Data: 00 00 F8 75 01 00 93 41 
ID: XXX  Data: 00 00 F8 73 01 00 A8 41 
ID: XXX  Data: 00 00 F8 72 01 00 BD 41 
ID: XXX  Data: 00 00 F8 71 01 00 D2 41

Daraus möchte ich jetzt gerne den Wert für eine Drehzahl von einem Pkw 
ermitteln.

[Karl H. (kbuchegg)]

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

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

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.

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

        drehzahl = die richtigen Bytes aus der CAN Nachricht zusammensetzen

        Serial.print( "Drehzahl: " );
        Serial.println( drehzahl );
      }
...

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

[Jens E. (surfjenser)]

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.

[klausb (Gast)]

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?

[Peter D. (peda)]

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.

[Jens E. (surfjenser)]

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 ;-)

[Frank M. (ukw) (Moderator)]

ti123 schrieb:
> hier ist mein Programm:

Prima, geht doch!

> im serial Monitor wird folgendes abgebildet:
>

> ID: XXX  Data: 00 00 F8 79 01 00 7E 41
> ID: XXX  Data: 00 00 F8 76 01 00 93 41
> ID: XXX  Data: 00 00 F8 75 01 00 93 41
> ID: XXX  Data: 00 00 F8 73 01 00 A8 41
> ID: XXX  Data: 00 00 F8 72 01 00 BD 41
> ID: XXX  Data: 00 00 F8 71 01 00 D2 41
>

> 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"?

[Jens E. (surfjenser)]

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

[Karl H. (kbuchegg)]

ID: XXX  Data: 00 00 F8 79 01 00 7E 41
ID: XXX  Data: 00 00 F8 76 01 00 93 41 
ID: XXX  Data: 00 00 F8 75 01 00 93 41 
ID: XXX  Data: 00 00 F8 73 01 00 A8 41 
ID: XXX  Data: 00 00 F8 72 01 00 BD 41 
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.

7E 41  = dez 16766
93 41  =     16787
93 41  =     16787
A8 41  =     16808
BD 41  =     16829
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 H. (kbuchegg)]

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.

[Frank M. (ukw) (Moderator)]

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.

[ti123 (Gast)]

> 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

[Karl H. (kbuchegg)]

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.

[Karl H. (kbuchegg)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Karl H. (kbuchegg)]

ID: XXX  Data: 00 00 F8 79 01 00 7E 41
ID: XXX  Data: 00 00 F8 76 01 00 93 41 
ID: XXX  Data: 00 00 F8 75 01 00 93 41 
ID: XXX  Data: 00 00 F8 73 01 00 A8 41 
ID: XXX  Data: 00 00 F8 72 01 00 BD 41 
ID: XXX  Data: 00 00 F8 71 01 00 D2 41

Low - High

          dezimal
79 01     377
76 01     374
75 01     373
73 01     371
...

sind das irgendwie plausible Werte?

[ti123 (Gast)]

Die Infos habe ich von einem CanAnalyzer Tool.

Dort Steht bei Drehzahl:
Startbyte 4
Startbit 0
Signallänge 12

mehr habe ich leider nicht.

[Frank M. (ukw) (Moderator)]

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?

[ti123 (Gast)]

Die Drehzahl müsste ein bisschen über Leerlauf drehzahl sein.
Sprich ca. 1000 1/min

[Jens E. (surfjenser)]

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

[Udo S. (urschmitt)]

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.

[Karl H. (kbuchegg)]

@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

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.

[Karl H. (kbuchegg)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Cyblord -. (cyblord)]

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?

[npn (Gast)]

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.

[Dirk B. (dirkb2)]

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.

[ti123 (Gast)]

>Ist das "XXX" immer die gleiche ID

ja das ist immer die gleiche ID, der Fahrzeugtyp spielt in dem Fall 
keine rolle

[Karl H. (kbuchegg)]

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.

[Karl H. (kbuchegg)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Frank M. (ukw) (Moderator)]

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.

[ti123 (Gast)]

@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

[Fischhändler (Gast)]

Hat hier jemand einen Fisch bestellt?

Langsam wird es doch albern.

[npn (Gast)]

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.

[Christopher B. (chrimbo)]

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

[Frank M. (ukw) (Moderator)]

Christopher B. schrieb:
> Die Drehzahl errechnet sich dann aus ((Byte4 * 256)+Byte5)/4

Ziemlich unwahrscheinlich bei:

ID: XXX  Data: 00 00 F8 79 01 00 7E 41
ID: XXX  Data: 00 00 F8 76 01 00 93 41 
ID: XXX  Data: 00 00 F8 75 01 00 93 41 
ID: XXX  Data: 00 00 F8 73 01 00 A8 41 
ID: XXX  Data: 00 00 F8 72 01 00 BD 41 
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.

[Dirk B. (dirkb2)]

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.

[Christopher B. (chrimbo)]

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.

[Bvb1909 (Gast)]

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

[Frank M. (ukw) (Moderator)]

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.

[npn (Gast)]

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.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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

[Frank M. (ukw) (Moderator)]

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 
;-))))

[Christopher B. (chrimbo)]

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