Hacking into Zoe's CANbus

[AbRiNgOi]

Hi,

Nachdem hier viel Experten unseres CAN Buses sitzen, ich hab eine Frage zu der Anzeige Time to full, aus dem CanZE program sieht es so aus:

case SID_TimeToFull: // time to full
tv = (TextView) findViewById(R.id.textTTF);
if (field.getValue() >= 1023) {
tv.setText("--:--");
tv = null;
}
break;

Das kann ich für mein Twizplay/SIM800 Projekt mal so übernehmen, hab ich auch. Aber was ich mich frage wäre, diese 1023 werden nun immer dann am Bus gesendet, wenn in der Anzeige --:-- erscheint, sodass man im CanZE dies übernommen hat.
(weil ich noch ein 8-Bit Datenproblem habe steht bei mir jetzt 04:15... egal)
Wenn ich mir den Datenbereich so ansehe wäre das maximale was hier angezeigt werden kann 17 Stunden und 3 Minuten.
Zugegebnermaßen habe ich es noch nie probiert meine ZOE so zu laden, dass eine Anzeige von über 17 Stunden notwendig gewesen wäre, weil bei 10A und leerem 22kWh Akku geht es zumindest in 16 Stunden.

Daher meine Frage: wenn ich denn wirklich noch jemals meinen 40kWh Akku bekomme, dann wäre doch 17 Stunden zu wenig, wie ist das Problem dort gelöst? Gibt es für die 40er Version eine eigene CAN Matrix ??

[UliZE40]

Nein ist bei ZE40 ist genauso. Generell gelten bei vielen anderen Werten auf dem Bus "alle Bits gesetzt" als NULL.
Korrekt würde die Abfrage in CanZE übrigens eher "if not value == 0x3FF" bzw. "if value < 0x3FF" heissen.

Ich hab's so gelöst:
https://github.com/premultiply/ZOEdispl ... n.ino#L517

[AbRiNgOi]

cooles Program, gefällt mir besser als die CanZE Progammiererei..

Da ich aber grundlegend ein anderes Konzept gewählt habe, kann ich Sonderformen in der Umrechnung nur schwer umsetzen.
Ich habe ein Include File mit der CAN Matrix, wo jeder Kanal mit CAN id, Start Bit, Stop Bit und Umrechnung definiert ist. Dieses könnte man je nach Fahrzeug austauschen oder mehrere zur Auswahl stellen. Das Umrechnen auf physikalischen Wert erfogt zentral, sodass die Bildschirme jeden Kanal als float vorliegen haben. Der Wert 1023.00 kommt nun über diesen Kanal herein. (ich könnte aber einen Overflow Wert in der Matrix definieren und dann auf einen Vorgabewert setzen... )
Da die Uhr sowieso nur alle 5 Minuten umspringt, hätte ich erwartet, dass die Matrix einfach nur die Umrechnung ändert und zum Beispiel ein Bit = 5 Minuten wäre.. hier geht es aber scheinbar um Abwärtskompabilität...

Danike für Infos!!!!

So hab ich es nun drinnen, Output ist aber nicht der screen weil diese Info hab ich eh auf der Fahrzeuganzeige, sondern die Serielle Schnittstelle zum SIM800L um eine SMS zu generieren...

Code: Alles auswählen

				hours = (uint16_t)CanX.CAN_chanal[caT2F]/60;
				minutes = (uint16_t)CanX.CAN_chanal[caT2F]-hours*60;
				if ((uint16_t)CanX.CAN_chanal[caT2F] < 1023)
				{
					snprintf (string_loc, 30, "Ladedauer: %02d:%02d ",hours,minutes );  //  17 Zeichen
				}
				else
				{
					snprintf (string_loc, 30, "Ladedauer: --:-- ");  //  17 Zeichen
				}
				UARTx.puts(string_loc);

[UliZE40]

Ich habe ein Include File mit der CAN Matrix, wo jeder Kanal mit CAN id, Start Bit, Stop Bit und Umrechnung definiert ist.

Ja, ich hab mir das Leben viel einfacher gemacht: Die (bis zu) 8 CAN-Datenbytes werden einfach einfach in einen 64-bit unsigned Integer geschrieben (in der richtigen Reihenfolge) so dass man da ganz bequem und maximal performant mit Shift-Operatoren und Bitmasken arbeiten kann. Dabei spielt dann auch die Bitlänge der einzelnen Rohdatenwerte auf dem Bus keine Rolle.

Output ist aber nicht der screen weil diese Info hab ich eh auf der Fahrzeuganzeige, sondern die Serielle Schnittstelle zum SIM800L um eine SMS zu generieren...

Ich nutze die geschätzte Ladedauer auch nur um damit die Uhrzeit des Ladeendes zu berechnen damit man sofort sieht wann man ungefähr wieder am Wagen sein sollte. Erspart ein kleines bisschen das Kopfrechnen.

Das dämliche bei der ZOE ist nur, dass die Berechnung sofort gekillt wird wenn die Anzeige auf SOC 99% im Display springt. Völlig egal wie lange die Berechnung noch bei 98% (sogar einigermaßen realistische) vorhergesagt hat. Wenn ich mal nochmal langeweile habe will ich das auch noch umschiffen so dass bei 99% die "Berechnung" ignoriert wird. Bei Überschreitung wird ohnehin bereits mit Realzeit gestreckt und im Moment des Ladeendes korrekt protokolliert.

[BinKino]

Nein ist bei ZE40 ist genauso. Generell gelten bei vielen anderen Werten auf dem Bus "alle Bits gesetzt" als NULL.
Korrekt würde die Abfrage in CanZE übrigens eher "if not value == 0x3FF" bzw. "if value < 0x3FF" heissen.

Ich hab's so gelöst:
https://github.com/premultiply/ZOEdispl ... n.ino#L517

Die genannten benötigten Teile sind ja auch schon eine Weile nicht mehr verfügbar, stolpere eben wieder drüber und welcher der beiden Displays soll man nehmen ...

Wie wäre es mit einem "Workshop" - das Interesse ist ja definitiv da.
Klare Hardwarevorgaben und ein Hauzu, dann kann das doch eigentlich jeder von uns.
Beim OVMS kann man auch die Hoffnung aufgeben? Was sehr schade ist.

CanZE ist vom Grund her genial, aber läuft nur instabil und die Engstirnigkeit der Macher leider breit.
Versuche, CanZE auf nem Smartie laufen zu lassen, auf das man dann per Teamviewer o.ä. zugreift ... man fällt auch hier doch immer wieder den großen Worten zum Opfer, was da ja alles so super toll machbar ist. Spätestens Google wirft einem von Version zu Version neue Knüppel zwischen die Beine.
Es macht keinen Spaß mehr!

Soll ja auch keiner etwas fer umme tun ... aber Reno können wir doch an die Wand heften. Macht doch so wirklich keinen Spaß mehr.

Die Daten auslesen, auf einem kleinen Farbdisplay anzeigen, wie beim Twizplay, und ein GSM Modul mit SIM Karte, damit man die Daten abrufen kann.

Github ist eh eine Zumutung. Und man kann sich nicht alles unklare aus der Nase zaubern

[UliZE40]

Doch, die Teile gibt es noch.
Vom Display und vom CAN-Bus-Shield gibt es neue, verbesserte Versionen.
Das CAN-Bus-Shield hat jetzt z. B. einen SD-Karten-Slot.
Ansonsten sollte das alles weiterhin miteinander spielen.
Ggf. braucht man minimalste Code-Anpassungen.

Zudem arbeitet Erich gerade an einer neuen Lösung auf ESP-Basis mit Touchscreen und WLAN (z. B. für MQTT) die komplett und passgenau mit einem gedruckten Einleger in der Ablage über dem OBD-Port verschwindet.
Da freue ich mich schon drauf!

[BinKino]

Doch, die Teile gibt es noch.
Vom Display und vom CAN-Bus-Shield gibt es neue, verbesserte Versionen.
Das CAN-Bus-Shield hat jetzt z. B. einen SD-Karten-Slot.
Ansonsten sollte das alles weiterhin miteinander spielen.
Ggf. braucht man minimalste Code-Anpassungen.

Ok, ja Nachfolger gibts meist - nur was man dann was mit wem und wo welche Änderungen ...
Da will und kann man leider nicht alles studieren und möchte gerne auf einen fertigen Zug aufspringen

Zudem arbeitet Erich gerade an einer neuen Lösung auf ESP-Basis mit Touchscreen und WLAN (z. B. für MQTT) die komplett und passgenau mit einem gedruckten Einleger in der Ablage über dem OBD-Port verschwindet.
Da freue ich mich schon drauf!

Ja ok, das hört sich ja super an, reihe ich mich mit ein
So lange man nicht programmieren muss ich habe es mitm UNO mal probiert. Da fehlt mir mittlerweile einfach die Energie dazu, sich noch mal in was rein zu studieren.

Wlan reicht auch vollkommen

[Mittelhesse]

ich warte ja noch immer auf die ZOE Adaption vom OVMS 3, die Entwicklung geht weiter, hoffentlich findet sie bald Einzug in's offizielle release.

https://github.com/openvehicles/Open-Ve ... 3/pull/160

[AbRiNgOi]

Ich habe nun ein neues Projekt gestartet.

Auf eine sehr billigen Basis (19,90) dem DSO150 ...

Das ist im Grunde ein billiges Digitaloszilloskop. Aber was soll's, es ist fast alles drauf was man so braucht.

Ein Display, super Auflösung und Farbe.
Ein 32Bit Prozessor mit CAN Modul.
Ein gutes Gehäuse mit 4 Tasten, einem Drehknopf auch zum Drücken.

Was fehlt: Programmierschnittstelle USB (10€), CAN Treiber (10€)

Ich hab mir das Ding einmal zugelegt und aufgebaut. Den Analogteil kann man gleich auf die Seite legen, macht 20 Bauteile weniger zum Aufbauen. Das Display macht einen sehr guten Eindruck, ist aber wie beim Handy ungeschützt nach außen verbaut... eventuell klebe ich noch eine Panzerscheibe auf.
Auf GitHub habe ich eine Software gefunden, die angeblich die SW des orginal ersetzt, egal, um die Initialisierungen und die Display Treiber zu übernehmen reicht es. Die Programmiereinheit bekomme ich am Dienstag, dann wird sich zeigen, ob HalloWolrd noch diese Woche am Display steht...

Natürlich wird auch noch ein SIM800l eingebaut, damit mir das Ding eine SMS schreibt wenn die Ladung abbricht... Aber eins nach dem Anderen.

Möchte wer mit programmieren? Programmierstudio ist kostenlos erhältlich (Editor, Compiler, Debugger), Start Software auf GitHub...

... am mitlesen ...