 |
|
Aktuelle Zeit: So 24. Nov 2024, 05:32
|
Unbeantwortete Themen | Aktive Themen
| Autor |
Nachricht |
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
 Re: Project MG Bordcomputer Hab übrigens inzwischen ne Lösung gefunden, wie man den Bordcomputer wenn er fertig ist auf OBD-II-Fahrzeuge portieren kann. Es gibt von Sparkfun eine komplett fertige Platine, halb so groß wie ne Zigarettenschachtel, die man direkt an den OBD-II-Port anschließen kann: https://www.sparkfun.com/products/9555Per serieller Schnittstelle kann man dann direkt die ganzen Werte des OBD-II-Systems auslesen. Aber eben funzt das nur bei OBD-II. Bei OBD-I und somit allen MGF vor MEMS3 wird man nicht daran vorbei kommen, die ganzen Werte "selbst" zu erheben. Besonders, da weite Teile der Rover-Implementation von OBD-I immer noch nicht öffentlich sind. Und so Sachen wie Kühlwassertemperatur, Tankinhalt oder Fahrzeug-Geschwindigkeit liegen bei Rovers OBD-I ohnehin nicht vor.
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Do 20. Apr 2017, 18:13 |
|
|
|
Thorsten_EF
Registriert: Mo 5. Jan 2009, 15:06
Beiträge: 847
Wohnort: Erfurt
|
Re: Project MG Bordcomputer Dafür sind ja auch hintern Lenkrad so Dinger mit Zeigern .  
_________________
Gruß Thorsten
__________________
Home
52er DK /Bastuck/200 Zellen Metallkat/ Porsche Seitenblinker/S 2000 Startknopf/K-Tec Tachoscheiben im LE 500 Design
Vinyl
|
| Fr 21. Apr 2017, 15:39 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer Mensch... das sagst du mir jetzt erst?  Werd vielleicht nachher nochmal ein paar Experimente "am Objekt" machen. Hab es immer noch nicht geschafft, den Geschwindigkeits-Geber zum "sprechen" zu bringen, den ich nachgerüstet hab. MkI-Fahrzeuge haben ja nen mechanischen Tacho, der leider aber kein besonders gleichmässiges Rechtecksignal liefert. Also hab ich einen "ERA 550459A" nachgerüstet, der eigentlich einfach nur zwischen den Tacho-Anschluss am Getriebe und der MkI-Tachowelle eingebaut werden muss. So ähnlich wie der Geber von VDO von Dieter's MGF-Seite (den es aber nicht mehr gibt). Leider gibts keine Dokumentation zu dem Ding, und die Hersteller-Firma hat meine Fragen per e-mail bislang auch nicht beantwortet. Kennt sich damit vielleicht jemand aus? So sieht er aus:  Hat drei Kabel, ein schwarzes, ein blau/weißes und ein rot/weißes. Wurde original verbaut beim Daewoo Espero, Lanos und Nexia, von ca. 1995 bis 1999. Hat vielleicht von euch wer Stromlaufpläne von Daewoo oder so? Egal wie ich das Ding anschließe, ich kriege im Oszi einfach keine Messdaten. Nur ein konstantes Grundrauschen.
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Sa 22. Apr 2017, 19:41 |
|
|
|
kdupke
Registriert: Mi 6. Aug 2014, 19:09
Beiträge: 707
Wohnort: Laatzen
|
Re: Project MG Bordcomputer Das VDO-Teil hat einen Hall-Sensor eingebaut und gibt ein Impulssignal aus, wenn es denn an +12 und Masse angeschlossen ist und gedreht wird.
Leider ist die Tachowelle nicht wirklich genau und einigen Schwankungen unterworfen. Im Prinzip ist der Tacho dann der RC-Filter, der das glättet.
Also Werte aufsummieren über mehrere Zyklen.
gruss kai
_________________
Trophy 160 in gelb
|
| So 23. Apr 2017, 21:44 |
|
|
|
xpower
Registriert: Do 14. Mai 2009, 15:02
Beiträge: 4924
|
Re: Project MG Bordcomputer MGF74 hat geschrieben: Fahrzeug-Geschwindigkeit liegen bei Rovers OBD-I ohnehin nicht vor. doch gibt es... das übersetzt der Tacho in ein Signal für die Servolenkung
|
| So 23. Apr 2017, 22:06 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer So, habs heute abend nach eeeeewigem Rumprobieren (und zwischenzeitlichen Befürchtungen dass das Teil von vornherein kaputt ist  ) herausgefunden. Der Geber "ERA 550459A" von Era Spares macht das so: Er braucht +12V (rot/weißes Kabel) und Masse (schwarzes Kabel). Das eigentliche Signal liegt an am blau-weißen Kabel. Aber hier kommt der Clou - es ist kein einfaches +12V Rechtecksignal. Sondern der Geber schaltet auf dem Signalkabel immer einen Massekontakt an und aus. Und daraus wird dann ein Rechtecksignal. Ein angeschlossener Tacho oder Steuergerät muss also auf das blau/weiße Kabel selber 12 Volt anlegen. Das ist quasi genau umgekehrt wie z.B. das GALA-Geschwindigkeitssignal bei allen Autos von VW, das einfach nur +12V/0V hin und her schaltet. Da muss man erstmal drauf kommen...   Ich hatte den Geber hier zuhause auf meinen Dremel draufgesteckt und immer schön mit 500 U/min geguckt ob ich dem Ding ein Signal entlocken konnte... und durch Zufall hatte ich dann irgendwann die Kabel so auf meiner Breadboard-Platine gesteckt, dass sich was regte. Jedenfalls, nach ein bisschen Rumprobieren und Verfeinern hab ich diese Schaltung entworfen:  Der Optokoppler ILD74 stellt also die Verbindung her zwischen dem Geber-Signal und dem Mikrocontroller-Eingang. Schaltet der Geber auf Masse, liegen am Eingang des Controllers +5V an. Dreht der Geber sich weiter und der Massekontakt wird wieder geöffnet, kriegt der Controller-Eingang 0V. Wieder was gelernt... xpower hat geschrieben: MGF74 hat geschrieben: Fahrzeug-Geschwindigkeit liegen bei Rovers OBD-I ohnehin nicht vor. doch gibt es... das übersetzt der Tacho in ein Signal für die Servolenkung Ja... Problem ist nur, wenn man das Signal in der Zentralelektrik anzapft, dann fällt (zumindest bei meinem Wagen) ab und zu die Servolenkung aus... hab ich schon probiert...  Einer der Gründe warum ich halt das Geschwindigkeitssignal lieber über so nen Geber erzeugen möchte.
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Mo 24. Apr 2017, 02:03 |
|
|
|
kdupke
Registriert: Mi 6. Aug 2014, 19:09
Beiträge: 707
Wohnort: Laatzen
|
Re: Project MG Bordcomputer Oder das Signal mit einem FET abgreifen, dann ist der Einfluss viel geringer, als mit einem Optokoppler.
Zweck des Optokopplers ist der Störschutz?
gruss kai
_________________
Trophy 160 in gelb
|
| Mo 24. Apr 2017, 09:09 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer Ja, im Grunde Störschutz. Der Geber scheint 12V zu brauchen, hab ihn gestern jedenfalls nicht mit 5V zum laufen gekriegt. Und da er die 12V dann aus dem Bordnetz kriegt, inklusive Spannungsspitzen, ist es so besser, mit Optokoppler. Das Signal für die Servolenkung ist ausserdem beim MkI bedingt durch die mechanische Tachowelle besonders bei niedrigen Geschwindigkeiten sehr unregelmässig. Da hat man Schwankungen von über 30 Prozent zwischen den Impulsen. Der MkII hat ja selber nen elektrischen Geber am Getriebe, da könnte man vielleicht tatsächlich mit nem FET das Signal unterm Lenkrad abgreifen. Wobei es bei OBD-II ja dann sowieso als reine Daten-Information vorliegt... In meiner Schaltskizze war gestern noch ein kleiner Fehler... hab in der Skizze auf der Ausgangsseite des Optokopplers die Anschlüsse vertauscht... naja, war schon spät... 
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Mo 24. Apr 2017, 11:24 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer So, nachdem der Geber endlich funktioniert und ein Signal liefert, habe ich heute abend eine Testfahrt gemacht und dabei ein paar Werte zu erhalten für den Zusammenhang zwischen Pulsweite des Signals und der gefahrenen Geschwindigkeit. So sieht das Signal aus:  Also ein fast symmetrisches Rechtecksignal. Fast symmetrisch deswegen, weil das Längen-Verhältnis von LOWs zu HIGHs in etwa 1.05:1 beträgt. Das bedeutet, wenn man das mit nem Mikrocontroller misst, dann muss man sich an den Abständen zwischen zwei gleichartigen Flanken orientieren. Der Einfachheit halber werde ich den MC jeweils die Zeiträume zwischen den steigenden Flanken zählen lassen. Hier eine kleine Tabelle mit den Messwerten der heutigen Fahrt:  Die kleinste fahrbare Geschwindigkeit scheint bei meinem Wagen um die 8 km/h zu sein. Das heißt, wenn man den ersten Gang auf gerader Strecke drin hat und kein Gas gibt. Das könnte später im Programmcode dazu dienen, zu erkennen ob das Fahrzeug sich bewegt oder nicht. Unter 8 km/h ---> Verbrauch wird in Liter pro Stunde angegeben. Über 8 km/h ---> Verbrauchsangabe in l/100 km. So wie es moderne Bordcomputer auch darstellen. (es ist übrigens überraschend schwierig, über mehrere Sekunden eine wirklich laut GPS konstante Geschwindigkeit zu halten, die zur Erhebung von Messdaten taugt... ) Normalerweise würde man ja erwarten, dass sich die gemessenen Intervalle streng proportional zur Geschwindigkeit verhalten. Das ist aber nicht der Fall. Gibt man die Messwerte in ein Online-Tool zur Bestimmung einer Regressionsgeraden ein, sieht man sofort, dass dem nicht so ist:  Das sieht eher nach einer sauberen stetigen Exponentialfunktion aus. Kann ich mir im Moment nicht erklären. Weiß jemand, woran das liegen kann? Die Werte sehen eigentlich zu "sauber" aus, um einfach nur Messfehler zu sein. Also muss man irgendwie ne gute exponentielle Regression errechnen. Aber hab bisher heute abend noch kein Tool gefunden, das eine wirklich gute Übereinstimmung von Punktewolke und Regressionsgraph ergibt. Vielleicht hat ja von euch jemand ne Idee dazu. So eine Regressionsfunktion wird später dann direkt als Formel Eingang finden in den Programmcode. Und eine möglichst genaue Bestimmung der Geschwindigkeit wird unter anderem nötig sein für die Errechnung des Momentanverbrauchs und der Rest-Reichweite. Da ja offenbar die Frequenz des Rechteck-Signals nicht linear zunimmt mit steigender Geschwindigkeit, kann man also nicht einfach sagen, so und so viele Umdrehungen des Gebers entsprechen so und soviel gefahrenen Metern... sondern muss es immer in Relation zur gefahrenen Geschwindigkeit setzen.
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Fr 28. Apr 2017, 01:21 |
|
|
|
kdupke
Registriert: Mi 6. Aug 2014, 19:09
Beiträge: 707
Wohnort: Laatzen
|
Re: Project MG Bordcomputer Soviel Zeit möchte ich auch mal haben  Wenn Dein Graph bei kleiner Geschwindigkeit anfängt, hast Du dann ggf. Totzeiten zur ersten Flanke drin? Evtl. hast Du ja keinen Hallgeber, sondern einen kleinen Dynamo drin und die Umsetzungselektronik braucht Anlaufzeit. Allerdings sind mir bisher noch keine 6C33C in SMD untergekommen? Was spricht dagegen, das Signal im Ausgebauten Zustand auf linearität zu prüfen? Hm, oder Du hast ein reed relais, das hat doch selber eine Totzeit und mag irgendwann nicht mehr schnell genug loslassen. Geht quasi in Sättigung. Auf jeden Fall spannend das Ganze, gruss kai
_________________
Trophy 160 in gelb
|
| Fr 28. Apr 2017, 11:55 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer Ich werd mir tatsächlich nochmal ein paar Gedanken machen müssen, wie ich das ganze am besten bei sehr geringen Geschwindigkeiten hinbekomme. Grundsätzlich ist es ja so, dass jede noch so kleine Geschwindigkeit zu einer allmählichen Drehung des Gebers führt, und somit ein Signal generiert. Ich hab den Hersteller ERA in Italien schon mal vor nem halben Jahr angemailt und ihn gebeten, mir die Bauart/Funktionsweise inklusive Pinbelegung des Gebers zu erklären. Aber hab bis heute keine Antwort erhalten.  Kann also nur spekulieren, wie das Innenleben aussieht. Verbaut war der Geber im Original bei Autos von Daewoo Mitte bis Ende der 90er Jahre, also wird das Innenleben wohl eher "low tech" sein. Inzwischen habe ich ein Online-Tool gefunden um eine passende Regressionsfunktion zu berechnen: Wie man sieht, verbindet diese Funktionsgleichung sehr schön die einzelnen Messpunkte.  Nach leichter Term-Vereinfachung ist also das hier die Geschwindigkeits-Funktion in Abhängigkeit von der Pulsbreite bzw. vom Abstand zwischen gleichartigen Flanken: y = 107735800 / (1 + (x/0.00003249876)^1.125045)Recht kompliziert, aber dafür sehr exakt... Komplexe Fließkomma-Operationen wie die in dieser Gleichung verlangsamen allerdings die Ausführung des Codes auf dem Mikrocontroller. Sollte dies merklich der Fall sein, dann könnte man vielleicht ein lookup table machen. Also eine Tabelle (bzw. ein Array), wo zu jeder vom Controller gemessenen Pulsweite in Millisekunden die passende Geschwindigkeit von 0 bis 200 steht. Beispiel: Code: byte speedLookup[201][2] = {
// Links Signalbreite, rechts km/h
{0, 0},
{130, 1},
{125, 2},
// usw usf für alle Werte von 0 - 200 km/h
} Mit 402 Byte (bei maximal 200 km/h; der ganzzahlig gerundete Pulsweiten-Wert und die dazugehörige Geschwindigkeit hätten je ein Byte) wäre diese lookup table nicht einmal sehr groß. Der Zugriff auf einen bestimmten Wert in so einem Array dauert nur ein bis zwei Taktzyklen des Mikrocontrollers, während das Ausführen der obigen Gleichung leicht das drei- oder vierfache an Taktzyklen dauern kann. Und immerhin soll das Motordaten-Messmodul, in welchem die Geschwindigkeit errechnet wird, auch noch die Einspritzzeiten und das Kurbelwellen-Signal messen. Letzteres hat bei 7000 U/min nur eine Pulsbreite von 86 Mikrosekunden, also muss man zusehen dass der Controller das alles hinbekommt ohne sich zu verhaspeln. Um die ganzen Werte für alle Geschwindigkeiten von 0 bis 200 km/h aber vorher alle mal auszurechnen damit man am Ende die Werte für die lookup table hat, ist die Gleichung aber trotzdem hilfreich.
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Fr 28. Apr 2017, 13:55 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer Ich hab mir die Sache mit dem nicht-linearen Geschwindigkeits-Geber nochmal durch den Kopf gehen lassen... ich weiß nicht mehr wo ich das gehört habe, aber irgendwie hatte ich was im Hinterkopf, dass es bei Hallsensoren generell Nicht-Linearitäten geben kann. Und dann habe ich meine Notizen zum Kurbelwellensensor hervorgeholt und die Messwerte ebenfalls mal zu einer Regressionsanalyse eingegeben:  (X-Achse ist die Motordrehzahl, Y-Achse ist der Abstand in Mikrosekunden (!) zwischen zwei gleichartigen Flanken des Rechtecksignals des Hallsensors). Man kann sehen, dass auch hier kein streng linearer Zusammenhang vorliegt. Eine lineare Gleichung kann diese Punkte nicht miteinander verbinden. Und es deutet sich schon eine gewisse "Kurve" an. Auch beim Kurbelwellen-Sensor erhält man durch eine exponentielle Funktion einen sehr viel besseren "Fit":  Folglich muss es hier irgendeinen (physikalischen) Effekt geben, der dazu führt, dass die Werte "driften" und von einer Geraden zwischen den Messpunkten abweichen. Kenn mich damit aber leider nicht so in der Tiefe aus. Wenn jemand ne Idee dazu hat, immer her damit. Ich werde über die Feiertage vielleicht nochmal ein paar Messungen am Kurbelwellensensor bei höheren Drehzahlen machen, um das Bild zu vervollständigen. Ich hab ja nur zwischen 900 und 3000 U/min gemessen. Am Dienstag werd ich dann wohl mit Thorstens MkII am Zoo eine Testfahrt machen um mal seinen werksseitigen Geschwindigkeitsgeber genauso mit Messpunkten auszutesten. Wenn das stimmt was ich vermute, dann wird der Sensor im MkII (und TF) am Ende in ähnlicher Weise eine Kurve abbilden, und keine Gerade.
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| So 30. Apr 2017, 01:29 |
|
|
|
Tomcatciller
Registriert: So 13. Jul 2014, 00:58
Beiträge: 1130
Wohnort: Chemnitz
|
Re: Project MG Bordcomputer Ich glaube mich erinnern zu können das der Bordcomputer meines Focus ab ~10 km/h und darunter auf Liter/Stunde ausblendet und nur noch drehzahlabhängig anzeigt.
Erst beim Beschleunigen kommt wieder L/100 km.
Vielleicht kannst du den unteren Bereich so ausblenden?
|
| Di 2. Mai 2017, 06:45 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer Ja, das ist geplant. Ist auch im Code schon so eingebaut. Unter 10 km/h wird in der Tat auf l/h umgestellt. Wie ich weiter oben schon schrieb, ist um die 10 km/h (ca. 8 km/h real laut GPS) auch die niedrigste Geschwindigkeit die überhaupt auf gerader Strecke im ersten Gang möglich ist. Bietet sich also an.
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Di 2. Mai 2017, 13:54 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer So, nach ein paar Tests sieht es in der Tat so aus, dass es eeeeewig und drei Tage dauern würde, den Mikrocontroller jedesmal aus den Pulsen des Geschwindigkeits-Gebers eine Geschwindigkeit errechnen zu lassen. Mit der Formel y = 4.699208 + (764.6559 - 4.699208)/(1 + (x/1621.844)^1.24952)(für x = Intervall-Länge in Mikrosekunden, y = Geschwindigkeit in km/h)scheint es insbesondere bei langen Pulsen und somit geringen Fahrgeschwindigkeiten riesige Verzögerungen zu geben von bis zu einer Sekunde. Nur um jedesmal einen Geschwindigkeits-Wert auszurechnen . Somit führt kein Weg an einer Lookup Table vorbei. Für den ERA-Geschwindigkeitsgeber sieht die dann wie folgt aus: Code: unsigned long kphLookup_ERAsensor[243][2] = {
// kph speed lookup table - erster Wert jeweils Signal-Intervall-Länge in Mikrosekunden, zweiter Wert reale km/h
{2921, 250},{2935, 249},{2949, 248},{2964, 247},{2978, 246},
{2993, 245},{3007, 244},{3022, 243},{3037, 242},{3052, 241},{3067, 240},{3082, 239},{3097, 238},{3112, 237},
{3128, 236},{3143, 235},{3159, 234},{3175, 233},{3191, 232},{3207, 231},{3223, 230},{3239, 229},{3256, 228},
{3272, 227},{3289, 226},{3306, 225},{3323, 224},{3340, 223},{3357, 222},{3374, 221},{3392, 220},{3409, 219},
{3427, 218},{3445, 217},{3463, 216},{3481, 215},{3499, 214},{3518, 213},{3537, 212},{3555, 211},{3574, 210},
{3593, 209},{3613, 208},{3632, 207},{3652, 206},{3672, 205},{3691, 204},{3712, 203},{3732, 202},{3752, 201},
{3773, 200},{3794, 199},{3815, 198},{3836, 197},{3857, 196},{3879, 195},{3901, 194},{3923, 193},{3945, 192},
{3967, 191},{3990, 190},{4013, 189},{4036, 188},{4059, 187},{4082, 186},{4106, 185},{4130, 184},{4154, 183},
{4179, 182},{4203, 181},{4228, 180},{4253, 179},{4279, 178},{4304, 177},{4330, 176},{4356, 175},{4383, 174},
{4409, 173},{4436, 172},{4463, 171},{4491, 170},{4519, 169},{4547, 168},{4575, 167},{4604, 166},{4633, 165},
{4662, 164},{4692, 163},{4722, 162},{4752, 161},{4783, 160},{4814, 159},{4845, 158},{4877, 157},{4909, 156},
{4942, 155},{4974, 154},{5008, 153},{5041, 152},{5075, 151},{5110, 150},{5144, 149},{5180, 148},{5215, 147},
{5251, 146},{5288, 145},{5325, 144},{5362, 143},{5400, 142},{5439, 141},{5478, 140},{5517, 139},{5557, 138},
{5598, 137},{5639, 136},{5680, 135},{5722, 134},{5765, 133},{5808, 132},{5852, 131},{5897, 130},{5942, 129},
{5988, 128},{6034, 127},{6081, 126},{6129, 125},{6177, 124},{6227, 123},{6277, 122},{6327, 121},{6379, 120},
{6431, 119},{6484, 118},{6538, 117},{6592, 116},{6648, 115},{6704, 114},{6762, 113},{6820, 112},{6879, 111},
{6940, 110},{7001, 109},{7063, 108},{7126, 107},{7191, 106},{7256, 105},{7323, 104},{7391, 103},{7460, 102},
{7531, 101},{7602, 100},{7675, 99},{7750, 98},{7826, 97},{7903, 96},{7982, 95},{8062, 94},{8144, 93},
{8227, 92},{8312, 91},{8399, 90},{8488, 89},{8579, 88},{8671, 87},{8766, 86},{8863, 85},{8961, 84},
{9062, 83},{9166, 82},{9271, 81},{9379, 80},{9490, 79},{9603, 78},{9719, 77},{9838, 76},{9960, 75},
{10085, 74},{10213, 73},{10345, 72},{10479, 71},{10618, 70},{10760, 69},{10907, 68},{11057, 67},{11212, 66},
{11371, 65},{11535, 64},{11703, 63},{11877, 62},{12057, 61},{12242, 60},{12433, 59},{12630, 58},{12834, 57},
{13044, 56},{13262, 55},{13488, 54},{13722, 53},{13965, 52},{14217, 51},{14478, 50},{14750, 49},{15032, 48},
{15327, 47},{15633, 46},{15953, 45},{16288, 44},{16637, 43},{17002, 42},{17386, 41},{17787, 40},{18210, 39},
{18654, 38},{19122, 37},{19616, 36},{20138, 35},{20691, 34},{21277, 33},{21901, 32},{22565, 31},{23275, 30},
{24034, 29},{24849, 28},{25727, 27},{26675, 26},{27703, 25},{28821, 24},{30043, 23},{31383, 22},{32862, 21},
{34503, 20},{36335, 19},{38396, 18},{40733, 17},{43409, 16},{46506, 15},{50139, 14},{54467, 13},{59722, 12},
{66254, 11},{74623, 10},{85783, 9}, {0, 0}
}; Die Übereinstimmung zwischen meinen Messwerten von meiner Messfahrt und den errechneten Werten in der lookup table ist gut genug, um diese als Basis für die Geschwindigkeits-Berechnung zu nehmen. Bin mir noch nicht ganz im klaren wie der betreffende Code aussehen wird, aber im Grunde wird dann jeder gemessene Intervall-Wert mit der lookup table verglichen. Und dann wird derjenige km/h-Wert als Ergebnis ausgegeben, der zu dem Intervall-Wert gehört, der am nächsten an dem gemessenen Wert dran ist. Haben wir also eine Intervall-Länge von 37185 Mikrosekunden gemessen, dann liegt diese laut lookup table zwischen 36355 (19 km/h) und 38396 (18 km/h). Der Messwert ist näher dran an 36355, wird also 19 km/h zugeordnet. Muss man halt dann allerdings so machen, dass man dem Controller, den man ja gerade von einer schwer verdaulichen Exponentialfunktion befreit hat, nicht schon wieder zu sehr mit Anweisungen vollstopft.
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Di 2. Mai 2017, 18:53 |
|
|
|
kdupke
Registriert: Mi 6. Aug 2014, 19:09
Beiträge: 707
Wohnort: Laatzen
|
Re: Project MG Bordcomputer Die lookup-table optimieren und diese z.bs. in 5er-Schritten führen (ggf. auffüllen). Dann musst Du den Wert nur noch auf den nächsten 5er auf/abrunden, nachschauen, fertig. Oder Du hast nicht für jeden km/h-Wert eine Anzeige.
Keine Ahnung zu was für eine Fehlerabweichung das dann führt. Und für eine Anzeige ist es IMO egal, ob Du nun 11 oder 12 bzw. 88 oder 89 km/h fährst.
Ca. 16600 Werte zu speichern. Oder 6300, wenn Du erst bei 20km/h anfängst. Bzw. die Hälfte, wenn Du jeweils eine km/h-Zahl überspringst, bzw. den Messwert um ein Bit shiftest.
Wie groß darf die lookup-table denn sein?
Das Tastverhältnis ist immer gleich?
gruss kai
_________________
Trophy 160 in gelb
|
| Mi 3. Mai 2017, 12:38 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer Ich hab inzwischen ne Idee gehabt wie man das am besten löst. Das Bordcomputer-Display wird eine Aktualisierungsrate von 3 Sekunden haben. Also muss man auch nur alle drei Sekunden eine Geschwindigkeit berechnen. Ich gehe dabei so vor, dass nach drei Sekunden immer der Durchschnittswert der Zeitintervalle berechnet wird (im folgenden Code: kphIntervalAverage), die seit der letzten Aktualisierung passiert sind. Habe ich nach drei Sekunden diesen Durchschnittswert, dann wird ERST DANN in meiner Lookup Table geguckt, welcher km/h-Wert dazu passt: Code: for (j = 0; j <= 242; j++) { // Intervall-Wert vergleichen mit der lookup table
// Die ganze lookup table wird durchgegangen um den nächstgrößeren und nächstkleineren
// Wert für die Intervall-Länge zu finden
if (kphIntervalAverage >= kphLookup_ERAsensor[j][0] && kphIntervalAverage <= kphLookup_ERAsensor[j + 1][0]) {
// Durchschnittswert zwischen nächst-größerem und nächst-kleinerem Intervall-Wert in der Tabelle berechnen
intervalMean = (int) ((kphLookup_ERAsensor[j + 1][0] - kphLookup_ERAsensor[j][0]) / 2); //
}
}
// Hier kann man leicht durcheinander kommen, denn die km/h-Werte in kphLookup_ERAsensor[j][1] gehen runter
// während die Intervall-Längen in kphLookup_ERAsensor[j][0] ansteigen
// kleinerer km/h-Wert falls kphIntervalAverage grösser ist als das arithmetische Mittel
// aus nächst-kleinerem und nächst-größerem Tabellen-Wert
if (kphIntervalAverage >= intervalMean) kphValue = kphLookup_ERAsensor[j + 1][1];
// ...und kleinerer km/h-Wert wenn kphIntervalAverage kleiner ist
else kphValue = kphLookup_ERAsensor[j][1]; Es wird also geguckt, zwischen welchen beiden Tabellen-Werten mein Intervall-Wert von meinem Geschwindikgeitssensor liegt. Dann wird der Durchschnitt aus diesen beiden Tabellen-Werten gebildet, und wenn mein Messwert über diesem Durchschnittswert liegt, wird er dem größeren Wert zugeordnet, und liegt er unter dem Durschnitt, wird er dem kleineren Wert zugeordnet. Wenn man das nur alle drei Sekunden macht, dann hält sich die Beanspruchung des Controllers in Grenzen. Wie groß die lookup table sein darf? Nun, auf dem Chip sind maximal 32 Kilobyte Programmspeicherplatz...  In ihrer jetzigen Form hat diese Tabelle eine Größe von 1944 Bytes, also 1,89 Kilobytes. Ist also noch genug Platz für ähnliche Tabellen...
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Mi 3. Mai 2017, 14:07 |
|
|
|
kdupke
Registriert: Mi 6. Aug 2014, 19:09
Beiträge: 707
Wohnort: Laatzen
|
Re: Project MG Bordcomputer CPU-Zeit ist teuer, zumindest bei diesen kleinen Dingern. Wenn Du die Tabelle normierst, dann verlegst Du die CPU-Zeit auf Deinen Rechner und hast die CPU-Zyklen frei für anderes.
OK, wenn jemand konstant 18km/h fährt und dass über mehere Intervalle, und Dein lookup nur einen Wert für 19/20/17 hat, dann geht's falsch. Aber braucht es diese Genauigkeit? (Um mal gar nicht davon zu sprechen, dass das a kaum einer schafft und b dieser dann ja auch noch die echte Geschwindigkeit messen können muss/will)
gruss kai
_________________
Trophy 160 in gelb
|
| Mi 3. Mai 2017, 14:26 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer Man könnte auch eine "intelligente" Komponente einbauen, indem immer nach dem neuen Geschwindigkeits-Wert gesucht wird in der Nachbarschaft des vorherigen Wertes. Wenn du also zuletzt 50 km/h gefahren bist, dann wird nur zwischen 60 und 40 km/h in der Tabelle gesucht, oder so. Und erst wenn dort kein passender Wert gefunden wird, wird die Suche auf die ganze Tabelle ausgeweitet. Aber auch dadurch wird der Code ja wieder komplizierter. Außerdem wird der Code dann Probleme haben hinterher zu kommen, wenn du mal nen richtig ordentlichen Spurt hinlegst. Laut Datenblatt schafft der MGF 1.8i immerhin die 0-100 km/h in 8 Sekunden...
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Mi 3. Mai 2017, 14:38 |
|
|
|
MGF74
Registriert: Fr 26. Jul 2013, 00:15
Beiträge: 314
|
Re: Project MG Bordcomputer EDIT: Ansonsten finde ich es doch ganz gut, den Geschwindigkeits-Wert "genau" zu erheben. Immerhin dient der auch als Grundlage für Berechnungen zu Momentanverbrauch, Durchschnittsverbrauch und Reichweite.
_________________
'98er MGF 1.8i MPI 120 PS (Fun-, Sommer- und Schönwetterauto)
'99er Audi A4 1.8T Limousine 150 PS (Alltagshobel)
|
| Mi 3. Mai 2017, 14:42 |
|
|
Wer ist online? |
Mitglieder in diesem Forum: 0 Mitglieder und 14 Gäste |
|
Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.
|
|
|
