VesCom

Inhalt:

Dieser Artikel befasst sich mit dem von Henning "dare" Groß entwickelten open source Boardcomputer VesCom sowie dem Folgemodell VesCom2.

Copyright

Alle hier veröffentlichten Informationen sind ausschliesslich zur nichtkommerziellen Nutzung freigegeben. Jeder ist eingeladen Soft- und Hardware zu optimieren und an seine Bedürfnisse anzupassen. Jegliche Verbreitung und Vermarktung auch in Auszügen ist untersagt.

Entstehungsgeschichte

Mit den Jahren wurden meine Motoren immer leistungsfähiger und ich immer schärfer auf einen Drehzahlmesser. Zusatzinstrumente hatte ich bei meinem Rahmen nicht vorgesehen und das Originaltacho taugt ohnehin nicht viel. Nachdem ich immer mal wieder recherchiert habe was es so gibt und was so geht habe ich mich dann irgendwann für einen Mikrocontroller aus dem Hause Atmel entschieden. Irgendwann bin ich dann tatsächlich losgelaufen und habe mir bei Conrad Bauteile für exorbitante Preise geleistet und mir einen Programmieradapter bestellt. Es folgten erste Experimente mit dem Programmierdapter, der Entwicklungsumgebung (C unter AVR Studio) etc.. Leider war gleich mein erstes LCD-Display und mein zweiter Atmega defekt, so dass ich viel Zeit für die Fehlersuche vergeudete. Nachdem ich mich dann an die Mikrocontroller-Eigenheiten gewöhnt und die Ausgabe auf dem LCD im Griff hatte machte ich mich an das Experimentieren mit den Messschaltungen. So viele Schaltungen für Drehzahlerfassung im Internet kursieren, so viele waren ohne größere Modifikationen ungeeignet. Ob über das Lichtmaschinensignal, über das Zündkabel – wie ichs probiert habe - es verseuchte mir stets die ganze Schaltung. Die Folge waren Störungen des Messwertes, der Displayausgabe oder gleich resets des Mikrocontrollers. Ich hätte es mit Entkoppelung versuchen können etc. aber meine Laborumgebung (Esstisch, Multimeter, kein Oszi) machte weitergehende Tests erst einmal unmöglich. Wenn man sich das Signal nicht ansehen kann, dann kann man den Haken an der Sache auch schwer finden. Irgendwann stolperte ich über Hallsensoren. Diese messen Änderungen von Magnetfeldern und werden als fertige IC´s verkauft. Mit 2 Kondensatoren und einem Widerstand ergibt das eine kleine Platine welche auf der Zündgrundplatte befestigt und von den Magneten des Lüfterrads getriggert wird. Die Idee von einem Fremdkörper auf der Zündgrundplatte erscheint im ersten Moment etwas störend, stellt aber eine eher unproblematische und einfache Operation dar. Jemand hat einen Haltebügel aus Blech skizziert welcher auf der ZGP befestigt wird. Ich habe mir das Ding einfach zwischen zwei Spulen geklebt. Mittlerweile hatte ich auch eine Tacho-Schaltung mit einem Timer-IC gefunden und für gut befunden. Außerdem habe ich mithilfe eines MAX6675 ICs ein Thermoelement zur Messung der Abgastemperatur mit dem Mikrocontroller verbunden. Inzwischen schlug das dritte Herz in dem Computer. Von Atmega8 war ich über Atmega16 beim Atmega32 gelandet. Die Programmierweise in Mikrocontroller-Anwendungen unterscheidet sich von gewöhnlicher Programmierung. Auch hieran musste ich mich erst einmal gewöhnen und somit probierte ich verschiedenste Messverfahren (Zeit zwischen zwei Signalen messen und hochrechnen, x Signale messen und hochrechnen, eine Zeit lang messen und die gezählten Signale hochrechnen, ...) bis ich akzeptable refresh-Raten und lauffähige Software hatte. Damit der Tacho seinen Stand nicht vergisst (die Verbandelung von Geschwindigkeitsmesser und Distanzmesser nehmen wir allzu selbstverständlich hin aber vom einem zum anderem dauerte es auch noch ein wenig) lernte VesCom Daten im internen EEPROM zu speichern. Nur wann macht man das. So ein EEPROM kann 100.000 mal beschrieben werden. Wie wählt man also den Intervall damit der Controller lange lebt aber nichts verpasst? Wenn ich nur 1*pro Minute speichere dann verpasse ich uU etliche Meter. Einmal pro Sekunde verkürzt die Lebenszeit auf 27 Stunden. Irgendwie konnte ich so keinen Kompromiss finden. Ein Glücksfall war dann, dass der Mikrocontroller in der Lage ist ein Ereignis auszulösen wenn eine von zwei angeschlossenen Spannungen unter die andere fällt. Bis ich das lauffähig hatte floss allerdings auch einiges Wasser den Rhein herunter. Der Ansatz war, alle zum Speichern wichtigen Verbraucher mit einem großen Pufferkondensator von den übrigen Verbrauchern zu entkoppeln. Hierzu verwende ich einfach eine Diode. Das Problem war nun das ich je nach Konfiguration ein viel zu sensibles System hatte (Ereignis wurde ständig ausgelöst) oder eins das nicht zuverlässig funktionierte. Ich probierte etliches. Ich lies den Controller x mal überprüfen ob die Spannung noch immer unter der Vergleichsspannung lag und spendierte den Verbrauchern ebenfalls einen Pufferkondensator. Ich weiss gar nicht mehr wie lange und wie viel ich getestet habe, bis ich dann auf eine pragmatische (und vielleicht nicht besonders edle) Lösung kam: Ich reduzierte die Sollspannung über einen Spannungsteiler. Somit wurde das Ereignis erst deutlich später ausgelöst und kleine Schwankungen der Ist-Spannung machten nichts mehr aus. Der Bordcomputer konnte Daten speichern. Nun hat man also einen Tacho, einen DZM, Messung der Abgastemperatur – und das alles auf einem 2*16 Zeichen LCD-Display. Weitere Funktionen wurden implementiert. Eine Warnfunktion welche die Displaybeleuchtung blinken lässt wenn die Temperatur zu hoch ist, ein Menu zur Konfiguration des Reifenumfangs, Speichern der höchsten Temperatur und Rücksetzen im Menu etc. Irgendwann kam level auf die Idee eine SD-Karte anzuschliessen. Ich hatte bereits darüber nachgedacht und somit machten wir uns an die Aufgabe. Es dauerte etwa eine Woche bis wir dem Bordcomputer das Datenloggen beigebracht hatten. Mittlerweile war die vierte Software-Version im Einsatz. Die ersten ausgelieferten Controller waren aber immer noch mit der ersten beschrieben. Die Benutzer müssten für jedes Update Ihre Controller zu mir schicken was Arbeit und Portokosten bedeutet. Außerdem Wartezeit. Ich integrierte also noch einen Bootloader welcher die Firmware über SD-Karte updatet. Die Software-Version 1.14b mit der entsprechenden Hardware kann die Abgastemperatur messen, Höchsttemperatur speichern, ab einer konfigurierbaren Temperatur warnen, VesCom kann die Geschwindigkeit messen und hat einen Tageskilometerzähler. Der Computer erfasst die Drehzahl. Er loggt die Daten auf Wunsch auf und lädt Updates von SD-Karten (Fat16 und Fat12). Das sind deutlich mehr Funktionen als ursprünglich angekündigt und es ist noch kein Ende in Sicht. Vom Prototypen der unzuverlässig Drehzahl und halbwegs brauchbar die Geschwindigkeit messen konnte wurden etliche bestellt. Die 20 bestellten Platinen waren bald ausverkauft. Die Käufer bewiesen nicht nur den richtigen Riecher sondern auch große Leidensfähigkeit. Die meisten bestellten Bausätze und machten/machen erste Erfahrungen mit SMD-Technik etc. Auch wenn sich an der Hardware nicht viel änderte stellt der Zusammenbau des Bordcomputers schon eine Herausforderung dar. Einige engagierten sich über dieses Maß hinaus. Badbull entwickelte eine Tachoabdeckung (zT nach meinen Vorgaben) für den ET3-Lenker welcher das Display abdeckt und die Taster aufnimmt. Level stürzte sich in Mikrocontroller-Programmierung, arbeitete mit mir am SD-AddOn und lernte mal eben nebenbei wie man Platinen layoutet und ätzt. Andere haben mir viel Input gegeben und sich in die Auswertung der Logdaten gestürzt. Der Atmega32 hat noch 8k von seinen 32 frei. Wenn sich jemand an die Optimierung des Codes macht wird da sicher noch einiges frei. Platz für Verbesserungen. Aber auch nicht mehr allzu viel davon. Der VesCom1 - Support durch mich wird sich zukünftig nur noch auf Bugfixes beschränken. Ich bin an der Entwicklung der Version2 welche nicht als open-source-Projekt gedacht ist. Wer Platinen für VesCom 1 fertigen (lassen) oder das ganze nachbauen will etc. kann dies gern tun. Für private Nutzung können Spenden an [email protected] (paypal) übermittelt werden. Wer irgendwas davon weiterverkaufen möchte der kontaktiert mich bitte unter der Mail-Adresse [email protected] und/oder im GSF.

Bilder

Hauptplatine bestückt

Display

Tachoabdeckung/Displayaufnahme (noch ohne Taster)

Drehzahlsensor an Zündgrundplatte

SD-Karten-Zusatzplatine

Hardware und Schaltpläne

Die Hardware basiert auf einem Atmega32 mit 4MHz Takt.

Die Layouts/Schaltpläne können hier eingesehen werden: http://kulturserver-nrw.de/home/dare/vescom/sch.html

[Baustelle: Das Layout der Hauptplatine hat da rot die nötigen Nachbesserungen eingezeichnet. Level hat ein neues Layout gezeichnet in welchem die Änderungen bereits berücksichtig wurden. Fragt ihn, vielleicht stellt er sie hier ein]

Software

[Baustelle: hier gehören noch die Quelltexte und die .bin-Datei von VesCom 1.14b hin. Wer etwas optimiert oder hinzufügt kann dann hier seinen Code zusätzlich posten]

Aussicht auf VesCom2

VesCom wird nicht mehr aus so arg zerpflückten Schaltungen bestehen. Es wird eine Platine für die Spannungsversorgung geben und eine für den Rest. Format von beiden vermutlich 50*80. Die Zusatzoption GPS besteht aus einer 30*30 kleinen Platine. Auf der Wunschliste stehen Lambdasonden-Auswertung, GPS Datenerfassung, Tankgeber, ,Akkustützung, Auslasssteuerung, Zündverstellung, Alarmanlage, etc... VesCom2 erhält vermutlich 2 Controller, einen höheren Takt und deutlich mehr Schnittstellen/Funktionen. Es wird kein Open Source-Projekt und ich lege die Entwicklung darauf aus, dass es als fertiges und lauffähiges System verbaut werden kann. Wann es so weit sein wird ist derzeit noch unklar - ich arbeite aber mit Nachdruck daran. Das System wird vermutlich etwas teurer als das alte. Zumindest gilt das für die nicht-Bausatz-Version mit allen Features. Vielleicht baue ich auch noch eine Sparversion. Neuigkeiten gibt es dann im Germanscooterforum unter der Rubrik GSF Projekte in meinem Topic (http://www.germanscooterforum.de/GSF_Projekte_f24/Vescom_t138758.html).

Info

http://www.germanscooterforum.de/GSF_Projekte_f24/Vescom_t138758.html

http://kulturserver-nrw.de/home/dare/vescom/

[email protected]

Dank

• Peter Fleury für die LCD-Lib
• Holger Klabunde für die SD-Lib und Hex2Bin
• Stefan Seegel für den Bootloader
• nach Aachen für die Inputs zu EGT Lambda, außerdem für das zur Verfügung stellen des Entwicklungs-TE und wichtiger noch für das Übernehmen des Themas Logfile-Auswertung
• Level für das Drängen auf SD-Karte und den Einsatz den er bringt
• Badbull für die Tachoabdeckungen
• Bitburger, Telepizza und Philipp Morris für die wichtigsten Entwicklungswerkzeuge
• May (Meine Freundin). Dafür das Sie mich noch immer nicht verlassen hat obwohl ich schon seit Monaten öfter den Lötkolben in der Hand hab als Dinge, die mich eigentlich mehr interessieren sollten
• auch an all die mutigen die ihr Geld in dieses Projekt gesteckt haben und nun mit einem Haufen Bastelarbeit zu hause sitzen. Wenn das Interesse nicht so groß gewesen wäre, dann hätte ich es vermutlich nicht so weit entwickelt