CVM IV - Verdecköffnen während der Fahrt ohne Zusatzmodul + NCS Exkurs

Vielen Dank an @elkloso und seine Helfer.
Laut git funktioniert es einwandfrei.

Im NCS-DUMMY
bezüglich GUESCH_PREFUNG
Ich muss wert_1 + nicht_ aktiv ankreuzen
Es ist normal ?
Vielen Dank
 
Mit NCS Expert / NCS Dummy würde ich empfehlen, alles ganz genau zu schreiben (GUESCH_PREFUNG => GESCHW_PRUEFUNG, wert_1 => wert_01).
Die Codierung verzeiht nichts und lässt sehr schnell den Zetti stehen! ;)

Es gibt manchmal für einen Parameter zwei "Stichwörter", die den gleichen Wert bedeuten.
Die modifizierten Daten erhalten hier als Ergänzung etwas einfacher zu verstehen (nicht_aktiv) aber beim Einlesen kann es sein, dass der originale Wert wert_01 mit der gleichen Bedeutung angezeigt wird.
Ein Wert pro Parameter reicht für codieren.
 
Zuletzt bearbeitet:
Das kommt ganz drauf an, was du setzen möchtest. Für eine Öffnung bis 36km/h solltest du die Werte wie folgt setzen, nachdem du die Daten in den Ordner verschoben hast:

GESCHW_VERDECK_AKTIV = wert_04
GESCHW_PRUEFUNG = nicht_aktiv
CHECK_BLOCK_4 = wert_04
 
wert_1 wert_01 es tut mir leid.
---
meine firmware ist in c04
(ich kodiere für 36km/h)
auch nach werkseitiger Neucodierung
Ich kann nicht per Dummy oder in trc > man direkt
etwas anderes haben als
GUESCH_PREFUNG
wert_01
nicht_aktiv

Es funktioniert, aber ich habe es nicht beim Fahren über 36 km / h getestet.
 
Als Bemerkung, ist für mich GESCHW_PRUEFUNG mit wert_01 und nicht_aktiv (in die Codierdatei hinzugefügt) in der entsprechenden Codierdatei keine Verbesserung aber mehr ein Grund für Codierungsfehler.
Das Ziel hiermit (meiner Erfahrung) ist nicht die Codierung einfacher zu verstehen zu bekommen aber die Coderiungsprobleme zu vermeiden.
Ein zusätzlicher Wert mit der gleichen Bedeutung als der originale Wert ist nett gedacht aber leider nicht nötig. Du hast bei jedem Einlesen zwei Werte, die nicht immer bei wieder codieren akzeptiert werden.
Nur mein Input dazu, um die Kollegen helfen zu können: Bitte lieber nur wert_01 schreiben und nicth nicht_aktiv.
 
Zuletzt bearbeitet:
In dem Fall müsstest du dann aber die Checksum vermutlich anpassen

Ich würde, wenn ich noch nicht ganz tief im Thema drin bin, einfach die getesten Values aus meinem Repo nehmen. Wenn du die selbst schreiben willst, kannst du dir die Excel zur Hilfe nehmen und alles berechnen.

GESCHW_PRUEFUNG muss auf 00 gesetzt werden. Sobald das auf 01 steht, interessieren ihn die GESCHW_VERDECK_AKTIV Werte nicht mehr.
Dann die GESCHW_VERDECK_AKTIV setzen. Grob kann man da sagen (Geschwindigkeit / 20) = DATA Value. 40km/h = 20 DATA
Dann die Checksumme berechnen (Bitwise XOR) und dann kannst du mit den Daten in deinen Coding-Files arbeiten.

Statt 36km/h würde ich einfach die 40km/h File nehmen und dann kannst du direkt mit meinen Daten arbeiten
 
Was ich hiermit meine, ist nur, dass man nicht immer wieder reinschreiben kann, was man direkt gelesen hat, wenn zwei Werte die gleiche Bedeutung haben.
Das ist hier nur mein Hinweis an Euch: Nicht unnötig Werte verdoppeln (wie zum Beispiel wert_01 und nicht_inaktiv, die beiden 00 als Wert bedeuten), um Codierungsfehler zu vermeiden.
Ich meinte nicht, dass ich so etwas gemacht habe. ;-)
Beste Grüße
 
Zuletzt bearbeitet:
Ja, das auch. Ich weiß auch nicht wie failsafe der Compiler von NCS ist. Normalerweise sollte er damit klar kommen. Aber allein schon aus einer einheitlichen Benennung, würde ich da auf Wert_01, Wert_02,.. usw gehen und nicht zwei Naming Conventions mischen.

Ich bezog mich jetzt auch auf Kerven nochmal. Wenn er das auf 36km/h stellen will
 
RobbiZ4 schrieb:
[...]So was Ähnliches benötigen wir für den E89 auf der CAN-Bus Ebene. Dort stecken noch einige Unbekannte in der Kommunikation mit dem Fahrzeug.
Zum Vergrößern anklicken....
Moin.
Ich hatte vor Jahren ja schon mal angedeutet, daß ich das Thema für den E89 irgendwann mal aufgreifen muß. So langsam bewegen ich mich in diese Ecke und ein erster Programmier-Stack mit E89 Steuergeräten ist im Aufbau.

Frage an @elkloso:
Hast Du Dich schon mal mit dem Fußraummodul FRM beschäftigt und kannst Du Dir vorstellen, daß z.B die Standard-Blinkerperiode (640mS) bei den BMW's als Parameter hinterlegt ist oder in der von Dir beschriebenen Weise als Byte/Word geändert werden kann?

Ziel dieser Spielerei wäre eine Verlangsamung des Blinkers für mein folgendes Projekt:

RobbiZ4

Beitrag im Thema 'Dynamische Blinker'

Diese Tage habe ich eine neue Blinkervariante von AUDI über insgesamt 4 Blöcke (mit 3 Unterbrechungen) gesehen. Dabei werden ca. 16 LED's in Teilgruppen angesteuert. Allerdings sind die dunklen Abschnitte unbeleuchtet Bereiche im Rücklicht und keine abgeschalteten LEDs.
AUDI_2025.jpg

Auch diese neue Variante werde ich dann mal in meine Dynamischen Blinker integrieren und ausprobieren. :D

Bisheriger Ablauf der AUDI-Variation mit gedimmten LED's bei meinem E89:
528667-5b135798690b51e28ffd70c71f54b234.jpg


Aufgrund der Gruppierung...
  • Like
  • Wow
  • Haha

Zielsetzung:
AUDI verwendet für seine Dynamischen Blinker einen deutlich langsameren Ablauf, der harmonischer aussieht. Mein Dyn.Blinker wirkt durch die bisherige 640mS Periode etwas zu hektisch, das würde ich gerne korrigieren.
 
Zuletzt bearbeitet:
FRM kenne ich, aber habe ich nicht so intensiv auseinander genommen, wie das CVM und GM5. Einfach, weil ich keinen E89 aktuell habe :D

Die Blinkperiode ist ziemlich sicher im Steuergerät als Parameter (Bytes) hinterlegt. Da ist so gut wie alles in der Form hinterlegt, beim ABS sogar die Hydraulischen Zyklen. Daher würde mich wundern, wenn es beim Blinker nicht so wäre. Ggf. hast du mit dem FRM sogar das Glück, dass es sich ohne Checksumme ändern lässt.

Hast du es mal mit NCS gedumpt und dir die Daten angeschaut?
 
elkloso schrieb:
Hast du es mal mit NCS gedumpt und dir die Daten angeschaut?
Zum Vergrößern anklicken....
Nee, noch nicht.
Das wäre der nächste Schritt.

Das FRMx ist vermutlich um 2000 entwickelt worden und dürfte intern nicht völlig anders arbeiten als das CVM. Die/Wir Entwickler sind schließlich faul und beharren auf einer gewissen Kontinuität. :D

Angenommen, 640 steht irgendwo als Parameter. Würdest Du nach einem Word suchen oder könnte das auch komprimierter abgelegt sein?
 
Btw,
Hier gab es eine vergleichsweise ähnliche Aktivität beim E89:
GuidoS

Beitrag im Thema 'Lauter Blinker'

Was lange währt...
Nach langen abwarten, viel recherchieren und Geduld verdanken wir Bimmer Code, die nun auch die E-Modelle bearbeiten können, endlich einen ruhigeren Blinker. Hurra!!!
Im KOMBI ins Expertenmenü gehen und bei 3106 Akustik_Klang sind diverse Möglichkeiten zum Anpassen des Geräuschs.
Ich habe mich bisher auf die Lautstärke beschränkt, welche wie von F-Modellen bekannt, geschwindigkeitsabhängig manipulierbar sind.
Bei Akustik_V_Y_C08 stehen 4 HEX-Werte zur Verfügung. Soweit ich weiß bestimmen diese die Lautstärke bei 0 km/h, 0 bis 6 km/h, 6 km/h bis 50 km/h oder 70 km/h und >...
  • Like
  • Wow
 
Das wird vermutlich als "Wert_01" oder so auftauchen. Du kannst es dir aber mit NCS Dummy dann anschauen bzw. im Hex Editor und dann wird es mehr Sinn machen. Normalerweise ist das dann auf 0-255 gemappt, weil Hex. Lässt sich aber meist sinnvoll zurückrechnen, weil es linear umgerechnet ist. Fiktives Beispiel: 640 auf 150 gemappt. Dann wäre 255=1088 Frequenz.
Aber alles nur Theorie. Wenn du den Dump hast, kannst du ihn gerne mal schicken, dann kram ich mal meinen Windows Laptop hervor :D
 
RobbiZ4 schrieb:
Btw,
Hier gab es eine vergleichsweise ähnliche Aktivität beim E89:
GuidoS

Beitrag im Thema 'Lauter Blinker'

Was lange währt...
Nach langen abwarten, viel recherchieren und Geduld verdanken wir Bimmer Code, die nun auch die E-Modelle bearbeiten können, endlich einen ruhigeren Blinker. Hurra!!!
Im KOMBI ins Expertenmenü gehen und bei 3106 Akustik_Klang sind diverse Möglichkeiten zum Anpassen des Geräuschs.
Ich habe mich bisher auf die Lautstärke beschränkt, welche wie von F-Modellen bekannt, geschwindigkeitsabhängig manipulierbar sind.
Bei Akustik_V_Y_C08 stehen 4 HEX-Werte zur Verfügung. Soweit ich weiß bestimmen diese die Lautstärke bei 0 km/h, 0 bis 6 km/h, 6 km/h bis 50 km/h oder 70 km/h und >...
  • Like
  • Wow
Zum Vergrößern anklicken....
Der Weg von Guido über BimmerCode's Expertenmodus (habsch auch :) :-)) ist insofern interessant, daß diese App möglicherweise bereits die erforderlichen Prüfungsummen berechnet. Das würde die Codierung vereinfachen.
 
Kann man auch mal probieren, aber ich würde erstmal schauen, ob das FRM überhaupt noch eine Checksumme braucht. Das CVM ist afaik das einzige, was sowas verlangt. Selbst DSC und co wollen keine, wenn man die Sperre codiert.

Im Zweifel bin ich da Oldschool und mache es lieber über NCS statt einer App, einfach weil man da mehr Kontrolle hat, was man wirklich codiert. Aber das ist geschmacksssache
 
RobbiZ4 schrieb:
Hab's zur Veranschaulichung umgerechnet:
Anhang anzeigen 695654
Zum Vergrößern anklicken....
Mein Gefühl ist, dass es anders umgerechnet wird, weil Decimal nur bis 255 geht. Das wäre in Hex FF und mehr passt in ein Byte nicht rein. Binary wäre das 11111111.
Also werden die das runterkürzen. Durch 10 oder einen anderen Faktoren, dass nach oben und unten Spielraum ist
 
RobbiZ4 schrieb:
Deswegen ja schon meine obige Frage, ob die Entwickler Werte auch als Word (2-Byte) oder eher nur als Byte speichern. :D
Zum Vergrößern anklicken....
Achso :D
Ja, ich gehe davon aus, dass die nur einen Byte belegen, weil der Speicher echt begrenzt ist.
Allerdings sehe ich z.B. dass es RAMP_AUS_BLK mit 05 und RAMP_EIN_BLK mit 08 gibt. Ggf. haben sie das Intervall auch darüber gelöst. Mehr finde ich in NCS Dummy gerade auch nicht
 
Ja genau, also in NCS kannst du dir ja auch ohne die Tracefile normalerweise die Einträge anschauen
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten