Open Vehicle Monitoring System (OVMS)

Erste Version des GPS-Supports ist fertig.

Wer testen mag:
github.com/dexterbg/Open-Vehicle-Monitoring-System

Ich hab vorhin eine erste Runde gedreht und hatte trotz der dicken Antenne ziemlich viele Stockungen in der Datenverbindung. Die Antenne war noch nicht optimal platziert, aber das hätte schon besser als mit dem Handy funktionieren müssen. Ich hab gerade das E-Plus-Netz im Verdacht (hab eine Blau-SIM drin). Weiss jemand ob mobile Datenverbindungen im D-Netz besser funktionieren?

Hallo Dexter,

hatte auch mal nen Aldi (E-Plus) Stick. Kann nur für den Rheingau westlich von Wiesbaden sprechen, aber da kannst Du froh sein, damit telefonieren zu können
O2 ist HIER perfekt, und mit meinem Congstar- Affen im Handy (D1) gibt es zwar Schwankungen, aber immer 3G und mind. 1 Balken!
Das ist auch der Grund für mein D1 im Handy: fast überall bundesweit stabil.
E- Plus und Daten - neee

Marioderzweite schrieb:

Hallo Dexter,

hatte auch mal nen Aldi (E-Plus) Stick. Kann nur für den Rheingau westlich von Wiesbaden sprechen, aber da kannst Du froh sein, damit telefonieren zu können
O2 ist HIER perfekt, und mit meinem Congstar- Affen im Handy (D1) gibt es zwar Schwankungen, aber immer 3G und mind. 1 Balken!
Das ist auch der Grund für mein D1 im Handy: fast überall bundesweit stabil.
E- Plus und Daten - neee

Das bestätigt so auch der aktuelle Connect Netztest, guckst Du hier: www.connect.de/ratgeber/mobilfunk-netztest-2012-1427666.html

Grüße

Rene

Bzgl. Netzwahl: habe jetzt eine Congstar-Karte im Einsatz, funktioniert wesentlich besser als E-Plus. Achtung: Congstar taugt nur mit Datenflat, Volumen-Datenverbindungen sind da extrem teuer. Alternativ würde es vermutlich auch die T-Mobile "Xtra Click" + "Xtra Flat-Daten" tun, mit 4,95 pro Monat noch etwas günstiger, dafür sind die SMS da teurer.

Da eine einzelne SMS auch bei Congstar mit 9 Cent fast soviel wie eine halbe kWh "kostet" werde ich aber wohl auch wann immer möglich die App nutzen.

Ich bin mit der Firmware ein gutes Stück voran gekommen und habe vor allem auch die Status-Flags für das Ladegerät auf dem Bus gefunden. Die Doku im Google-Sheet trage ich noch nach.

Hier die letzten Änderungen:
github.com/dexterbg/Open-Vehicle-Monitoring-System/commits/master

Eine Löthilfe für das Kabel ist auch dabei, aber wir finden auch noch eine Lösung für die Nichtlöter.

Aufruf zur Mithilfe

Wir brauchen Twizy-Bilder für die App. Hier gibt's doch bestimmt jemanden, der prima photoshoppen oder gimpen kann

Hier die Anfrage und Spezifikation von Mark:

lists.teslaclub.hk/pipermail/ovmsdev/2012-November/000548.html

lists.teslaclub.hk/pipermail/ovmsdev/2012-November/000549.html

Wenn jemand von euch helfen kann, meldet euch bei mir oder schreibt am einfachsten direkt an Mark.

Danke!

Juhu! Meine OMVS mit Antennen und Progammer haben endlich den Weg von China zu mir gefunden! Kann aber leider nur auf einer Hochzeit tanzen - zuerst das Twizplay... und morgen von 8-16 Uhr Seminar... da ist das Wochenende auch schon fast im Eimer.

Die Status-Flags des Laders würden mich sehr intessieren - ich brauche noch "Event" an dem ich die Ladernddaten ins EEprom schreibe...

Gruß, Uwe

Doku ist jetzt wieder up-to-date mit meinen neuen Erkenntnissen:

docs.google.com/spreadsheet/ccc?key=0AoKQUT5BY_r5dGJ4c0c2dTBPeGRzMnJWRXFBSC1RUVE

...und neuen Fragen

Sorry, schon wieder ein Update

github.com/dexterbg/Open-Vehicle-Monitor...0a70e483baf182f4226d1a1afc8d0734c2fa48d9

Primär neu sind die Features:

SMS "FEATURE 10 <prozent>" => Twizy sagt Bescheid wenn der Akku so voll ist

SMS "FEATURE 11 <km>" => Twizy sagt Bescheid wenn der Akku voll genug für diese Reichweite ist

SMS "FEATURE 12 <max_km>" => Twizy rechnet maximale Reichweite auf dieser Basis aus

dexter schrieb:

Sorry, schon wieder ein Update

github.com/dexterbg/Open-Vehicle-Monitor...0a70e483baf182f4226d1a1afc8d0734c2fa48d9

Primär neu sind die Features:

SMS "FEATURE 10 <prozent>" => Twizy sagt Bescheid wenn der Akku so voll ist

SMS "FEATURE 11 <km>" => Twizy sagt Bescheid wenn der Akku voll genug für diese Reichweite ist

SMS "FEATURE 12 <max_km>" => Twizy rechnet maximale Reichweite auf dieser Basis aus

Nabend,

ich habe festgestellt, dass mein T während der Ladung die prognostizierte Reichweite nicht neu rechnet. Dieses erfolgt erst dann, wenn der Schlüssel umgedreht wird.

Rechnest Du die maximale Reichweite mit dem OVMS ?

Gruß, Uwe

Ja, mach ich selbst, genau deshalb.

Ich rechne einerseits die letzte vom Twizy gemeldete Reichweite per SOC-Zuwachs seit Ladestart hoch, und mit dem aktuellen Update zusätzlich einen Absolutwert als Idealreichweite aus.

Die Hochrechnung der letzten gemeldeten Reichweite entspricht natürlich noch nicht der Reichweite nach dem nächsten Einschalten, das ist ja dann die der letzten 150 km. Ich könnte den Schnitt über 150 km ebenfalls mitführen, aber ich überlege eh, eine ganz eigene Reichweitenberechnung einzubauen; unter Einbeziehung der GPS-Höhendaten sollte es besser gehen als mit der eingebauten.

Moin,

das Thema Reichweitenprognose unter Berücksichtigung des Höhenprofils ist ein Thema, was mich auch beschäftigt.

Wenn man alle Daten hat, dann ist es ja fast schon einfach... Das GPS liefert die Position und Höhe - das ist schon einmal die halbe Miete ;O) Aber man muss wissen, wo es hingeht, weil die absolute Höhe ist nicht wirklich wichtig - wir brauchen den Höhenunterschied um die Hubarbeit zu berechnen. Die Gravitation ist ja zum Glück konstant ;O) Gehen wir mal von folgenden Werten aus:

Gesamtgewicht Twizy: 500 kg
Höhenunterschied der Strecke: 100 m

500 kg * 9,81 m/s² * 100 m = 490500 J = 490,5 kJ

kJ lässt sich ha schön in kWh umrechnen:

490,5 kJ * 0,000278 = 0,136359 kWh

Also kann man für diese Strecke mit den 100m Höhenunterscheid schon einmal die 0,14kWh zum Verbrauch addieren... weil fahren muss man da trotzdem

Gruß, Uwe

Joggls Sandhausen schrieb:

Moin,

das Thema Reichweitenprognose unter Berücksichtigung des Höhenprofils ist ein Thema, was mich auch beschäftigt.

Wenn man alle Daten hat, dann ist es ja fast schon einfach... Das GPS liefert die Position und Höhe - das ist schon einmal die halbe Miete ;O) Aber man muss wissen, wo es hingeht, weil die absolute Höhe ist nicht wirklich wichtig - wir brauchen den Höhenunterschied um die Hubarbeit zu berechnen. Die Gravitation ist ja zum Glück konstant ;O) Gehen wir mal von folgenden Werten aus:

Gesamtgewicht Twizy: 500 kg
Höhenunterschied der Strecke: 100 m

500 kg * 9,81 m/s² * 100 m = 490500 J = 490,5 kJ

kJ lässt sich ja schön in kWh umrechnen:
490,5 kJ * 0,000278 = 0,136359 kWh

Also kann man für diese Strecke mit den 100m Höhenunterscheid schon einmal die 0,14kWh zum Verbrauch addieren... weil fahren muss man ja trotzdem

... ich saß in Physik aber immer in der letzten Reihe...

Gruß, Uwe

Hallo zusammen,

so langsam brauche ich mal ein paar Betatester

Und zwar für mein neues Batterie-Monitoring:

github.com/dexterbg/Open-Vehicle-Monitor...b42b4f2741ab4d85a5b863ada9a36502102ccdc0

Leider noch ohne App-Support, daher erst mal nur auf SMS-Basis.

Hier mal mein aktueller Output der 5 wesentlichen SMS-Befehle:

"BATT":...das bedeutet Zelle 1 lag maximal 15 mV über dem Durchschnitt = Alarm, und Modul 1 max. 1,1 °C drüber = verdächtig.
Verdacht besteht bei Abweichung > Standardabweichung, Alarm bei > 2 * Standardabw.

"BATT V":...das sind die aktuellen Spannungslevel der 14 Zellen + Marker "!" für Alarm / "?" für Verdacht.

"BATT VD":...das sind alle maximalen Spannungs-Abweichungen des aktuellen Nutzungszyklus' (seit letzter Vollladung).

"BATT T":...das sind entsprechend die aktuellen Temperaturen der 7 Zellmodule.

"BATT TD":...und das sind entsprechend deren Temperaturabweichungen.


Ich bräuchte mal andere Messwerte, um die Levels für "Verdacht" und "Alarm" zu justieren.

Vermutlich sind die Trigger aktuell noch zu scharf, aber die Frage ist ob ein höherer Faktor her muss oder eine Mindestabweichung, oder eine Kombi aus beidem. Vielleicht ist auch die Standardabweichung nicht der korrekte Bezugswert. Um das heraus zu bekommen brauche ich mehr Messwerte, am besten von anderen Twizys.

Also, wenn hier jemand schon das OVMS einsetzen kann, würde ich mich über Daten sehr freuen

Ach ja... Kommentare a la "ist doch eh nicht unsere Batterie" sind hier überflüssig. Ich mach das weil's möglich ist, interessant, und mir Spass macht. Außerdem können diese Messungen später ggf. auch Reichweiten-Einbrüche erklären. Meine Zellen sind aktuell wie man sieht super auf einer Linie (+/- 15 mV ist so gut wie nix), aber das wird ja nicht immer so bleiben.

Werde ich sofort testen, wenn die ersten Twizplays geliefert sind...also noch vor Weihnachten - die OMVS stehen da...ich hatte noch keine Minute Zeit, mir die Dinger genau anzuschauen...

dexter schrieb:

Hallo zusammen,

so langsam brauche ich mal ein paar Betatester

Und zwar für mein neues Batterie-Monitoring:

github.com/dexterbg/Open-Vehicle-Monitor...b42b4f2741ab4d85a5b863ada9a36502102ccdc0

Leider noch ohne App-Support, daher erst mal nur auf SMS-Basis.

Hier mal mein aktueller Output der 5 wesentlichen SMS-Befehle:

"BATT":

Volts: !C1:+15mV Temps: ?M1:+1.1C

...das bedeutet Zelle 1 lag maximal 15 mV über dem Durchschnitt = Alarm, und Modul 1 max. 1,1 °C drüber = verdächtig.
Verdacht besteht bei Abweichung > Standardabweichung, Alarm bei > 2 * Standardabw.

"BATT V":

P:57.80V !1:4.140V 2:4.125V 3:4.130V 4:4.125V 5:4.130V 6:4.125V 7:4.130V 8:4.125V 9:4.130V 10:4.130V 11:4.130V 12:4.125V 13:4.125V 14:4.135V

...das sind die aktuellen Spannungslevel der 14 Zellen + Marker "!" für Alarm / "?" für Verdacht.


"BATT VD":

P:57.80V !1:+15mV 2:+5mV 3:+5mV 4:+5mV 5:+5mV 6:+5mV 7:+5mV 8:+5mV 9:+5mV 10:-5mV 11:+5mV 12:-5mV 13:-5mV 14:+15mV

...das sind alle maximalen Spannungs-Abweichungen des aktuellen Nutzungszyklus' (seit letzter Vollladung).

"BATT T":

P:11.1C (10.0C..11.6C) ?1:11.6C 2:11.1C 3:11.1C 4:11.1C 5:11.1C 6:11.1C 7:11.1C

...das sind entsprechend die aktuellen Temperaturen der 7 Zellmodule.

"BATT TD":

P:11.1C (10.0C..11.6C) ?1:+1.1C 2:+0.5C 3:+0.5C 4:+0.5C 5:+0.5C 6:+0.5C 7:+0.5C

...und das sind entsprechend deren Temperaturabweichungen.


Ich bräuchte mal andere Messwerte, um die Levels für "Verdacht" und "Alarm" zu justieren.

Vermutlich sind die Trigger aktuell noch zu scharf, aber die Frage ist ob ein höherer Faktor her muss oder eine Mindestabweichung, oder eine Kombi aus beidem. Vielleicht ist auch die Standardabweichung nicht der korrekte Bezugswert. Um das heraus zu bekommen brauche ich mehr Messwerte, am besten von anderen Twizys.

Also, wenn hier jemand schon das OVMS einsetzen kann, würde ich mich über Daten sehr freuen

Ach ja... Kommentare a la "ist doch eh nicht unsere Batterie" sind hier überflüssig. Ich mach das weil's möglich ist, interessant, und mir Spass macht. Außerdem können diese Messungen später ggf. auch Reichweiten-Einbrüche erklären. Meine Zellen sind aktuell wie man sieht super auf einer Linie (+/- 15 mV ist so gut wie nix), aber das wird ja nicht immer so bleiben.

Interessante Infos. Für mich ist es schon mal wichtig zu wissen, dass der Akku aus 14 Zellen mit 4,2 V Ladeschlußspannung aufgebaut ist. Also müsste sich ein Akku für die Reichweitenverlängerung aus 16 Zellen LiFePO4 (Ladeschlußspannung 3,65V pro Zelle) durch einfache Parallelschaltung zum eingebauten Akku aufbauen lassen.

Gruß, Uwe

Twizy-Modul Version 2.1:

github.com/dexterbg/Open-Vehicle-Monitor...e527b90883353f32da0f60d09c871333dc2c4646

- Temperaturen werden nun nach der neuen Formel berechnet

- Alarm wird nun nicht mehr bei > 2 * StdAbweichung ausgelöst sondern
bei absoluter Abweichung eines Moduls um 3 °C bzw. einer Zelle um 100 mV.
Die Verdachts-Marker werden weiterhin bei > StdAbw gesetzt.

- Alle Min+Max+Marker werden nun beim Einschalten des Twizy zurückgesetzt,
nicht mehr nur beim Beginn eines neuen 100%-Nutzungszyklus'.

- Mittelwerte und Abweichungen werden nun gerundet.

- Der Batterie-Alarm in Textform wird nun außerdem per Internet
an Server/App versendet, außerdem sofort bei Erreichen einer
Änderung an den Alarm-Markern.

- Die gesamte Batterie-Monitor-Funktion muss nun explizit beim
Kompilieren per Compilerswitch OVMS_TWIZY_BATTMON aktiviert
werden. Der aktuelle Ressourcenbedarf liegt bei 6% RAM (193 byte)
+ 10% ROM.