sorry habe deinen Post irgendwie voll übersehen. Deshalb erst jetzt die Anwort: Schaue mal auf die erste Seite von dem Thread, da sind mehrere Bilde von der Montage vom Bluetooth Modul.ChristianK hat geschrieben:Kannst Du mal ein Bild online stellen, wo Du das BT-Modul verbaut hattest? Ich baue die MS3 jetzt ein wenig um und setze den Lambdacontroller und das Can egt Board mit ins Gehäuse. Das mainboard kommt dann in die oberste einschubreihe des unteren Gehäuses und die zusatzboards ganz nach unten. Wenn es Probleme gibt, werde ich diesen Part mittels einer CU-Platte abschirmen.
Momentan sitzt mein BT-Modul unter dem Mainboard. Da müsste es für den Schirm aber weg. Sollte aber am liebsten trotzdem innerhalb da Gehäuses bleiben. Abe halt nicht da, wo du es hattest.
Vielleicht lagen deine Probleme garnicht am Modul, sondern am begrenzten Bauraum beim Moped und der daraus resultierenden Nähe zu den Spulen ?
Mit den Spulen könnte natürlich auch sein, aber selbst wenn der Motor nicht läuft und ich über BT verbunden bin, habe ich nur noch so um die 10Hz Datenrate.
Evtl würde es helfen wenn man die Bluetooth Antenne aus dem Gehäuse rausverlegt. Komplett ohne Gehäuse im Test und unmittelbarer Nähe habe ich dann max 20 Hz. Also das wäre so das Maximum was sich rausholen lässt.
------------------------------------------------------------------------------------
Habe mir gestern bzw. zu letzt auch noch paar Gedanken bzgl Flow-Rate und dem hohen Kraftstoffdruck gemacht.
Da die Sache mit den zwei Düsen eh noch länger dauern wird, wollte ich schon eine Übergangslösung.
Geht aber nur über Firmware Modifikation.
Mein Ziel war es über eine Table den Soll-Kraftstoffdruck (relativ zu MAP) anzugeben. Bisher geht das ja nur über einen einzigen Wert und eben nicht über ein Table.
Folgend bei Leerlauf sehr hohe Flow-Rate die ggf zu einem unruhigen Leerlauf führt, da es schwierig wird diese Kleinmassen korrekt einzuspritzen. Vor allem wenn die Deadtime nicht 100% passt und auch perfekt spannungskorrigiert ist.
Deshalb habe ich dann das Open-Close Fuel Pump Duty Table dafür missbraucht. Hier kann man normal Werte von 0-100 eintragen. Also eben den "blinden" Duty-Cycle der Pumpe.
Das habe ich zuerst in der TunerStudio .ini aktiviert, dass diese Tabelle auch bei Closed-Loop Modus editierbar ist (normal ausgeblendet).
Hier trage ich dann den Solldruck in bar ein.
Die nächste Änderung ist dann direkt im Closed-Loop Teil der Firmware. Anstatt dem bisherigen Target Pressure wird jetzt der interpolierte Wert aus der Duty-Table genommen.
Bzw. vorher wird der Wert noch mit 100 multipliziert, um von bar auf kPa zu kommen. Da die anderen Werte eben alle kPa sind.
Zuerst wollte ich auch gleich in die Table die kPa Werte eintragen, aber die Variable ist U08. Die Werte gehen also nur von 0-255.
Und das einfach auf U16 zu ändern ist komplizierter als man denkt, da hängt immer so viel aneinander.
Um die Abstufung der Werte bzw. die Genauigkeit zu verbessern habe ich den Maximaldruck auf 10bar festgelegt. So konnte ich dann eine kleinere Schrittweite ermöglichen.
Die Differenzberechnung zum MAP-Wert habe ich sozusagend gleich fest mit einprogrammiert. Normal kann man das ja noch auswählen, je nachdem welchen Sensor man hat etc. Aber das wäre wieder in einer anderen Schleife gewesen usw.
Deshalb habe ich mich jetzt für die einfachere Lösung entschieden.
Im Endeffekt bin ich jetzt immer um den eingegebenen Wert über dem MAP-Druck.
Also Beispiel Leerlauf 65kPA und Table-Wert=3bar, folgt daraus ein Absoluter-Kraftstoffdruck von 3,65bar. Also genau 3 bar oberhalb.
Bei Volllast MAP=100kPA ist der Absolutkraftstoffdruck dann bei einer Eingabe von 5bar = 6bar.
Und bei MAP>Baro, also RAM-Air steigt dann der AbsolutKraftstoffdruck noch weiter.
Nur mal als Beispiel.
Testen kann ich es dann erst nächste Woche, wenn ich wieder daheim bin. Bräuchte aber eigentlich noch ein leistungsstarkes Netzteil mit bis zu 10A. Damit ich alles perfekt und auch bei verschiedenen Spannungen messen könnte.
Aber die Teile sind immer so teuer
Jedenfalls gab es beim Kompilieren schon mal keine Fehler, das ist schon mal ein gutes Zeichen
So sieht das ganze jetzt TunerStudio mäßig aus. Habe der Table noch den schönen Namen "target rail differential fuel pressure table" gegeben Habe in der Firmware auch gleich noch eine zweite Änderung für die Traktionskontrolle vorgenommen.
Denn die VSS-Slip Traktionskontrolle mit externem Eingang ist im Prinzip so wie sie ist ziemlich unbrauchbar. Da der aktuelle/veränderliche Wert für die Schlupfgrenze nicht mit übertragen wird und somit beim Data-Logging nicht zur Verfügung steht. So nützt das einem echt nichts. Habe auch schon im msextra Forum in mehreren Thread darum gebeten. Aber wie jedes mal ohne jegliche Rückmeldung von James.
Habe erst versucht zusätzliche output Variable einzfügen. Aber hat nicht geklappt. Habe echt alles getestet, aber kamen immer Fehler. Kenne mich aber auch mit der Programmiersprache überhaupt nicht aus und der Umfang einer Motorsteuerung machts natürlich nicht einfacher.
Letztlich habe ich in einem alten Thread einen Post gefunden, dass wohl zwei Status Variablen quasi unbenutzt sind und nur fürs debugging gebraucht werden. Und das man die eben benutzen könnte.
Deshalb habe ich die aktuelle Schlupfgrenze einfach im Status4 übertragen. Hat soweit keine Fehler rausgeschmissen, muss ich dann nur noch testen. In der TS Ini könnte ich dann die Größe auch umbennen und Einheiten ändern etc. Da noch nicht mal der aktuelle Schlupf übertragen wird, habe ich den dann noch in die andere freie Größe gelegt.
Gut den könnte man wenigstens noch nachträglich berechnen. Aber ich denke mir, wozu noch berechnen wenn man den tatsächlichen Schlupf mit dem auch die MS gerechnet hat auch übertragen kann.
Im Grunde sollte so jetzt die TC schon mal brauchbar sein.
Im Idealfall möchte ich nur noch gerne mehrere Stützstellen für den externen Eingang haben und hier auch negative Werte ermöglichen.
Denn die Eingangsgröße ist bei mir ja die Schräglage vom Motorrad (Aufgrund der veränderten Reifenumfangs in Schräglage).
Würden hier negative Werte gehen, dann könnte ich die TC für Links und Rechtskurven anders abstimmen. Dürfte ganz nützlich sein bei Strecken die z.B. sehr linkslastig sind.
Als Folge bräuchte ich dann eben auch mehr Stützstellen. Da die jetzigen 9 Stück dann zu wenig sind.
Aber das ist zumindest für mich wieder sehr schwierig umzusetzen.
Hier auch nochmal kurz ein Bild zur TC. Passt jetzt noch nicht alles von der Beschriftung etc. Aber nur damit ihr euch das mal besser vorstellen könnt. Ist halt trotzdem keine saubere Lösung. Im Idealfall würde mal die Reifenkontur hinterlegen und würde dann nur den eine "echte" Schlupfgrenze festlegen.
Ich lebe jetzt quasi erstmal damit, dass mir hier Schlupfwerte angezeigt werden, die nicht dem echte Schlupf entsprechen (Eben aufgrund der Reifenkontur).
Aber im Grunde ist das ja egal, kommt ja nur darauf an ob die gesetzte Schlupfgrenze überschritten wird oder nicht.
Bei der EInstellung von dem ganzen würde ich erstmal ohne TC nur die Schlupfwerte über die Schräglage aufzeichnen. Natürlich möglichst ohne, dass es schon hier zu Rutschern etc gekommen ist.
Dann nehme ich darauf einfach etwas Abstand und lege das als Schlupfgrenze fest. Sollte also zumindest in der Theorie ganz einfach sein.
Und wenn ein anderer Reifen draufkommt (andere Kontur) muss ich eben nur wieder die Aufzeichnung anschauen und dementsprechend verändern.
Vorteil ist, dass man alles direkt auf real gemessenen Werten einstellt.
Im Idealfall möchte ich es noch schaffen beispielsweise VSS als weiteren Parameter mit reinzunehmen. Da sich bei hohen Geschwindigkeiten aufgrund der Fliehkraft die Umfänge wieder ändern.
Muss ich aber mal schauen wie/ob sich das in der Praxis dann tatsächlich auswirkt.