ODB2 und CAN beim Twizy... Es geht voran...

Hier wird's ja langsam richtig spannend!
Hab mir auch schon einen Adapter odb2 auf can gebastelt, nur zum loggen komm ich zeitlich noch nicht...

Ich habe übrigens eine Firma die freiprogrammierbare CAN Bus Displays und Steuerungen herstellt. Aktuell haben wir ein kleines display mit 3,5", 2 CAN und USB. Bin noch am überlegen wo ich das am besten in dem kleinen verbaue. Wenn jemand Interesse an so einem Display hat, kann er sich ja bei mir melden. Im Internet findet man uns unter Graf-syteco.de, das Gerät heißt D1000.

Weiß hier jemand ob man die Handschufachdeckel als Zubehör nachkaufen kann?

Viele Grüße
Fabian

Hallo,

ja jetzt gehts langsam ans Eingemachte.
Nur weiter so, Alex und Kollegen.
Übrigens gibts da bei den Verbrennern etwas was sich Scangauge nennt. Fürn Twizy wirds bestimmt nicht passen.

Viele Grüße:

Klaus

faxi schrieb:

Weiß hier jemand ob man die Handschufachdeckel als Zubehör nachkaufen kann?

Viele Grüße
Fabian

Zumindest als normalen Ersatztei-Artikel bei Renault bekommt man den.

andreas-m schrieb:

faxi schrieb:

Weiß hier jemand ob man die Handschufachdeckel als Zubehör nachkaufen kann?

Viele Grüße
Fabian

Zumindest als normalen Ersatztei-Artikel bei Renault bekommt man den.

Weist Du auch einen Preis?
Ich wüsste den seit Wochen gerne wegen der Cupholder-Geschichte

Soweit das Log nicht durch die Debug-Ausgaben durchbrochen war habe ich die Daten mal extrahiert und in eine OpenOffice-Tabelle gepackt.

Durch den AutoFilter auf die ID-Spalte kann man recht gut den Verlauf einzelner IDs betrachten. Die Spalten "Dn" sind die Dezimalwerte der Bytes -- next wäre zu schauen ob evtl. auch 16-Bit-Werte drin sein könnten. Bit-Flags sind definitiv vorhanden, bspw. bei ID 0x59B in Bytes 1+2.

Im Prinzip kann man damit auch den Verlauf eines Werts als Diagramm zeichnen lassen, das lässt sich ggf. besser mit der Fahrt korrelieren.

Hier der Link zum ZIP: docs.google.com/open?id=0B4KQUT5BY_r5T0g5ajRBUTBDR2s

Ich bin mir sicher für solche Analysen gibt es auch fertige Tools, aber ich bin absolut neu im CAN-Bereich, und diese Aufbereitung ging ja schnell. Nehme aber gern Tipps an, mein Logger ist noch nicht da.

Dexter schrieb:

Ich bin mir sicher für solche Analysen gibt es auch fertige Tools, aber ich bin absolut neu im CAN-Bereich, und diese Aufbereitung ging ja schnell. Nehme aber gern Tipps an, mein Logger ist noch nicht da.

Tools mag es vielleicht geben, aber eigentlich bleibt uns nichts anderes uebrig, als uns jeden Wert, den wir brauchen, muehsam zu suchen und zu erraten. Da gibt es sicher einige Tricks, z.B. der Kilometerstand sollte monoton wachsen und da man ihn ja auch kennt, findet man sicher schnell die Kodierung. Geschwindigkeit findet man sicher auch, bei Stroemen und Leistung wirds komplizierter, weil man die teilweise nur schwer oder gar nicht messen kann (s. o. RoadR). Manche Werte gibt es vielleicht gar nicht auf dem CANBUS, ausserdem koennte es mehrere Busse geben, die nicht miteinander ueber einen Gateway verbunden sind.
Wir sollten vielleicht mal diskutieren, was man mit den CANBUS Daten denn so machen sollte, da faellt mir so Brainstrom-maessig auf die Schnelle ein:
1) Nuetzliche Daten, die nicht im KI sind, auf einem kleinen Display darstellen.
2) OVMS. Twizy sagt per SMS Bescheid, wenn Akku voll.
3) Cruise Control (war ja schon mal Thema bei einigen)
4) SevCon Parameter auslesen
5) SevCon Parameter schreiben (halt ich fuer unwahrscheinlich)

Je nach Anwendung braucht man unterschiedliche Daten.

LG Thomas

Hallo Zusammen,

freut mich, das hier so viele mitdenken... In der Gemeinschaft sind wir stark!

Aber nun zum Thema. Ich war heute mit einem befreundeten Ingenieur zusammen. Da war der T. ein grosses Thema. Wir haben auch an bestimmten Punkten schon etwas laboriert, aber dazu später mehr.

Mein Vorredner hat schon recht, wir müssen uns die Bedeutung der ID's und Werte wohl experimentell erarbeiten. Über ein Reverse Engineering der CLIP Softe an die Infos zu kommen währe wohl ähnlich aufwendig.

Der Aufforderung meines Vorredners stimme ich zu: Ein oder mehrere Ziele müssen gesteckt werden.

Ich für meinen Teil habe drei Ziele, welche wohl auf unterschiedlichem Wege erreicht werden.

1. Display für relevante Parameter während der Fahrt und Aufzeichnung dieser für spätere Auswertung.
2. Tempomat
3. Sevcon MC Potential voll ausschöpfen.

Das Display scheint mir im Moment das realistischste Projekt zeitnah umsetzbar zu sein.
Darüber habe ich heute viel mit dem Ing. gesprochen.
Zur Ermittlung der Grössen aus den Daten vom CAN Bus haben wir ein paar Lösungsvorschläge.

Das finden der Spannung und des Stromes des Traktionsakkus werden wir wie folgt machen: Ich werde das HV Kabel vom Akku zum Sevcon ausbauen. Es wird genau vermessen damit ich es als Shunt (Messeinrichtung für die Strommessung) verwenden kann. Dann schaue ich, ob ich zwei dünne "Drähtchen" zum Messen mit in den Stecker bekomme packe dann entsprechende Messtechnik mit in den T. Darüber sollten sich sehr gut die entsprechenden Werte finden lassen.

Das decodieren der 12V Stromwerte werde ich mit einer elektronischen Last am Zigarettenanzünder vornehmen. Definiert verschiedene Ströme ziehen und mit den Hexwerten vergleichen. So sollte sich das auch finden lassen.

Tacho, Kilometerzähler usw. geht über definierte Messfahrten (1 Minute bei 30km/h, 50 usw...)

Beim Einbau der Innenbeleuchtung ist mir aufgefallen, das die Diagnose Buchse wohl nicht nur Diagnose CAN Bus hat sondern auch weiter PIN's belegt sind. Könnte der "alte" K-Bus oder J1850 oder was Renault spezifisches sein. Hatte mir blöderweise die PIN's nicht aufgeschrieben oder ein Foto gemacht. Hier lohnt nochmals ein genauer Blick.

Soviel erstmal zum weiteren Vorgehen zum Decodieren der Diagnose Buchse.

Zum Display:
Wenn es gelingt die wichtigsten Größen auf dem Diagnose CAN zu decodieren, lassen sich daraus fast alle Interessanten Parameter errechnen und darstellen. Daher würde ich das in einem getrennten Thema behandeln: "Wunschliste Anzeige"

Von der Hardware: Es gibt uC welche schon ein CAN Interface mit an Board haben und leistungsfähig genug sind, auch eine grafische Darstellung der Werte zu meistern (Renesas ist im Automotive Bereich da sehr beliebt) Da braucht es nicht viel drum herum. Für Renesas hätte ich auch zugriff auf fertige TFT Treiber, was die Entwicklungszeit sehr deutlich verkürzen würde.
Ebenso ist ein fertiger SD-Card Treiber verfügbar, der schnell auf das wegschreiben der Logdaten angepasst ist.

Die Frage wie groß und wohin mit dem eigentlichen Display haben wir heute praktisch ausprobiert. Bei den relativ engen Verhältnissen auf dem Armaturenbrett wird dies schwierig.
Optimal ist eigentlich ein Head-Up Display welches auf die Scheibe projiziert.
Allerdings geht das nicht low-cost mässig. Das haben wir heute versucht mit einem kleinen TFT.
Es ist am Tage zu dunkel und viel entscheidender: Die Windschutzscheibe sorgt für Doppelreflektion,
das Bild wird dadurch sehr unscharf.
Da muss ich mal bei einem anderen grossen Automobilhersteller aus München spionieren
Ausserdem kenne ich ein Ing. Büro das kürzlich erst für ein ähnliches Projekt entwickelt hat (sehr teuere Lösung), vielleicht haben die noch Tips.

Die Idee mit einem GSM Modul und SMS Benachrichtigung ist grundsätzlich gut. Es gibt solche Module auch zu kaufen. Allerdings ist die Frage, was darf ein solches Display kosten noch im Raum. Für 300-500 Euro geht da schon viel. Aber ist es soviel Geld auch Wert? Ich denke eher man sollte einen Preis unter 200.- Euro anstreben und der ist bei einer Kleinserie sehr schnell erreicht. Selbst wenn die Entwicklung hier und "Open-Source" stattfindet. Alleine den ODB Stecker habe ich noch nicht für unter 6,50 Euro gesehen.

Soweit ein paar Gedanken dazu....

Punkt 2: Tempomat
Das ist mit hoher Wahrscheinlichkeit realisierbar. Vorraussetzung meiner Einschätzung nach die Decodierung relevanter Größen wie Tacho-Signal auf dem CAN-Bus und Zugriff auf die Analogeingang des Sevcon MC.
Laut Manual des Sevcon erfolgt die Leistungssteuerung (Strompedal) über einen Analogeingang der MC. Ist die Frage ob der T- nur ein Poti im Gaspedal hat, welches direkt mit der MC verbunden ist oder ob Renault da noch etwas Elektronik dazwischen spendiert hat?
Aber ich denke in beiden Fällen könnte man sich dazwischen schalten. Ein entsprechendes Sicherheitskonzept vorausgesetzt, währe das durchaus Zulassungsfähig.
Die Regelhysterese zu Programmieren wird da schon etwas aufwendiger, zumindest wenn sie gut werden soll und wirklich Energiesparen soll...

Stellt sich dann noch die Frage nach der Bedienung. Ein Multifunktionslenkrad wird es für den T. wohl nicht geben. Ein passendes Gehäuse für das Lenkrad wie bei manchen Radios erhältlich wird teuer. Oder eine solche Radiofernbedienung einfach schlachten... Die Schalter irgendwohin pappen halte ich für wenig bedienerfreundlich...
Aber auch hier ist alles weitere Thema für einen anderen Thread...

Zum letzten Punkt:
Sevcon MC Möglichkeiten ausschöpfen. Wird hier vielfach gewünscht und würde auch mich sehr reizen. Aber mal realistisch gesehen: Welches Risiko verbirgt sich dahinter?
Zum einen ist der Akku ja Eigentum von Renault. Mit einem Wert von 3150.- Euro auch nicht gerade günstig.
Ich kann mir vorstellen, das Renault jedem Einzelnen kräftig auf den Schlips tritt, der daran etwas manipuliert.
Und darunter würde ich auch schon verstehen, zuviel Strom zu entnehmen oder einzuspeisen. Wenn Renault den Mietvertrag kündigt und seinen Akku wieder haben will, steht der T. und ist nur noch Modell.
Ist die Frage ob man wirklich dieses Risiko eingehen sollte? Ich für mich zweifle daran im Moment etwas.

Aber was würde überhaupt möglich sein?

In Sachen Tempo und Beschleunigung:
- Anhebung der V-Max sofern über den MC geregelt.
- Mehr Anfahrstrom und schnelleres ansprechen auf das Strompedal, sofern über den MC konfiguriert.

In Sachen Reku:
- Anhebung der Serienmässigen Reku Werte, sofern über den MC konfiguriert.
- Entwicklung eines zusätzlichen Reku Bedienelementes zur stufenlosen Rekupertation.

All diese Änderungen währen nicht ohne erhebliche Sicherheitsüberlegungen und Risiko für Mensch und Maschine machbar.

So, genug meiner geistigen Ergüsse für heute.....


Viele Grüße,

Alex

Hallo RoadR,

ich lasse deine Behauptung erstmal so als ein Fakt hier stehen dass das Strompedal auf einen analogen Eingang des Sevcon laufen müsste.
Dazu hab ich das Manual noch nicht intensiv genug gelesen.
Ich denke aber dass der Sevcon da sowohl die Möglichkeit eines Digitaleinganges als auch der Steuerung über den Canbus bietet. Für mich ist die Steuerung über den Canbus eigentlich gefühlsmä0ig wahrscheinlicher. Allerdings eventuell auch aus Kostengründen eher nicht....

Viele Grüße:

Klaus

Ich muss euch mal sagen, dass ich diesen Thread hochinteressant finde.
Ich kann zwar nichts technisches Beitragen, aber wenn irgendwo monitäre "Entwicklungshilfe" nötig ist, helfe ich gerne.
Mein Interesse geht in Richtung Daten loggen und Zusatzdisplay um genauer zu wissen, wie's dem Twizy geht. Schaue da neidisch auf die Vectrixfahrer, die genau über ihre Akkuspannung, Temperatur etc. Bescheid wissen.
Inwieweit das Thema "Powerrekuperationstaste" realistisch ist weiß ich nicht. Aber das stände aus meiner "Willhabenliste" gleich an zweiter Stelle.
Also, falls es irgenwo klemmt ...
Und weiter so !

Thorsten

@RoadR

Finde es echt gut, wie Du an die CAN-Bus-Analyse ran gehst. Als jemand der sich zwar mit dem CAN-Bus nicht im Detail auskennt, dafür aber recht gut mit elektrischen Antrieben und der dazugehörigen Messtechnik, würde ich zur Strommessung einen einfacheren Weg als den von Dir genannten vorschlagen: Nimm einen Hall-Sensor und führ das Batteriekabel dort durch, z.B den "LEM HTFS 200-P"

de.rs-online.com/web/p/products/5329205/..._Phrase&gclid=CJviksak_bECFUTxzAod7W0AJw

Damit kannst Du den Strom recht genau, berührungslos, galvanisch getrennt vom Twizy und preisgünstig messen. Setze ich in Elektroantrieben für ultraleichte Luftfahrzeuge ein. Funktioniert sehr gut.

Gruß, Uwe

Hallo,

so, mein ODB2 Adapter ist zusammengelötet... habe das gleich ausprobiert... funktioniert. (ODB2-Stecker => PCAN-USB).

Hier wurde ja schon viel Vorarbeit geleistet, was richtig motiviert - echt gut gemacht - Danke!

Folgendes konnte ich gleich Identifizieren:

Fahrstufe:
ID 59Bh - Byte(1): 20 = N // 80 = D // 08 = R



Hier muss ich mir noch einiges anschauen, um weitere, brauchbare Werte zu finden - mein Ziel ist die Entwicklung eines GSM Gateways um die Batteriedaten bzw. Reichweite von meinem Handy abrufen zu können - die Steuerung meines Tagfahrlichts und der Innenraumbeleuchtung mittels CAN und evtl. noch ein Soundgerator ;O)

Gruß, Uwe

Ich konnte es nicht lassen und habe gelernt, dass man nicht mit einem Notebook auf dem Schoß mit Maxspeed fahren sollte - hat sich aber gelohnt:

Interessant ist das Frame mit der ID 599 - hier steht die Reichweite und die exakte Geschwindigkeit (mit zwei Nachkommastellen ;O):

Auf Byte(6) steht die angezeigte Reichweite:
ID599: 00 00 0A 03 FF 37 00 00
... zu Beginn HEX:37 = Dezimal:55 = 55km in der Reichweitenanzeige

ID599: 00 00 0A 04 FF 2E 00 00
... nach der Fahrt HEX:2E = Dezimal:46 = 46km in der Reichweitenanzeige



Auf Byte(7) und Byte(8) steht die Geschwindigkeit:
Stillstand:
ID599: 00 00 0A 03 FF 37 00 00
... &H0000 im Stand - machmal auch &HFFFF - muss ich noch schauen

bei MAX-Speed
ID599: 00 00 0A 04 FF 2E 1F B2
... &H1FB2 = Tachoanzeige 84km/h = Dezimal:8114 = 81,14 km/h

Also weiß der Twizy ganz genau, dass er doch nicht 84 fährt ;O)

Gruß, Uwe

Hallo,

hab mir gestern mal die logs von RoadR angeschaut, in Ermangelung eines eigenen Twisys .
Die Werte Byte 7/8 in der Message 599 waren fuer mich auch Kandiaten fuer die Geschwindigkeit.
@Joggls Sandhausen:
Hast Du Dir mal die Message 5D7 angeschaut?
Byte 1/2 schein 'ne Kopie von der Geschwindigkeit zu sein.
Theorie zu den Bytes 4/5/6:
Koennte der km Stand sein (in 10/16 m):
Bei RoadR steht da bei Beginn hex 1D8100 und steigt monoton um 460m. Kaeme mit seiner Aussage hin, er waere ca. 400m gefahren.
der Werte 1D8100 staende dann fuer 1208.480 km.
Kannst ja mal nachpruefen, ob das bei Deinem KM Stand hin kommt.

Die Geschichte mit GSM hab ich auch im Sinn, hab' mir die Software von OVMS schon mal genauer angeschaut. Die Anpassungen bzgl. Twizy sind recht einfach, wenn wir die noetigen PIDs kennen.
Die Leute von OVMS bauen gerade eine neue Hardware(V2), die neben GSM auch ein GPS Modul beinhaltet. Die soll so um die $100 kosten. Sie sitzen in Hong Kong und lassen in China fertigen, daher der Preis. Kaeme wohl noch Mehrwertsteuer und Zoll drauf, also ich schaetze so 130 EUR muss man rechnen.
Infomaessig ist es da leider momentan recht still. Angeblich machen sie gerade die letzten Test, mal abwarten, was es gibt, hab ja auch noch keinen Twizy.
OVMS ist fuer den Tesla gedacht, wurde aber so designed, dass es prinzipiell fahrzeugunabhaengig ist. Es gibt auch schon Erweiterungen fuer den Ampera/Volt, da kaempft man gerade mit den vielen CANBUS Systemen im Ampera (5!) und es gibt zwei OBD2 Anschluesse, moeglichweise muss man beide auslesen, um an die benoetigten Daten zu bekommen. Das ist mit der Hardware natuerlich nicht so einfach moeglich, da bleibt wohl noch einiges an Arbeit.
Neben der Hardware wuerde man noch ein PICKIT Set (zum Schreiben der SW in den PIC Prozessor) benoetigen, ca. 50 EUR.

Ich halte Euch mal auf dem Laufenden, werde mir das Ding mal ordern, wenn es so weit ist.

LG Thomas

hm, angeregt von Euren Erkenntnissen hab ich auch mal eine Blick reingeworfen.

Zum Thema Geschwindigkeit:

meint ihr die Werte e23e entsprechen dann einer Geschwindigkeit von 57,918 km/h?

Männer, ich bewundere Euch.

Ich lese da wo Ihr §4B7R? lesen könnt nur eins.

BAHNHOF ;-(

Ich drück Euch trotzdem oder besser genau deshalb die Daumen, denn mit jedem Bit, das ihr da entzaubert steigt
meine Chance, daß der Traum vom Drittanbieterakku in 3 Jahren Wirklichkeit wird.

Solange niemand weiß, wie der Quitschie mit dem Akku spricht bleibt das sonst ein frommer Wunsch.

mfg

TC