Nou Razorx-Fijne Hokken: LV-NJ

[Piet]

Daar gaat de LTFT je niet bij helpen als je de STFT (mis)gebruikt om de lambda over het hele loadgebied te regelen. Sterker nog...... omdat die er voortdurend verschillende percentages, afhankelijk of je tevoren gecruist danwel gegast hebt, erbij optelt danwel aftrekt maakt je het de STFT alleen maar moeilijker om de lambda te regelen wat juist over of undershoot in de hand werkt.
De LTFT strooit alleen maar roet in het eten.
Je zal wat dat betreft het moeten hebben van de snelheid van de widebandsonde.

ik heb een variatie gemaakt op Yits zijn lambdacommander (die ik toevallig vandaag aan het uittesten ben, daarover later meer) die de AFR regelft door middel van de STFT aan de hand van een 16x16 load/RPM tabel.
Het systeem kan met de WB sonde om de 20ms een beslissing nemen of de afr te hoog of te laag is, de ECU ecu kan dat volgen. De over of undershoot kan door die snelheid in de hand worden gehouden, maar dan moet het LTFT systeem er juist niet doorheen komen "janken"

[razorx]

Ik ben heel benieuwd naar jouw bevindingen Piet.

De PID lambda regelaar van onze ECU wil ik me overigens ook in verdiepen.
Interessante kost.

In principe kan dit op elke auto toegepast worden, er is één maar:
Zonder aanpassing van de ECU werkt de unit dan alleen als brandstof bespaarder bij cruisen.
De WOT modus van die andere auto zal de wideband regeling immers uitschakelen bij hoge last.
Nog steeds niet verkeerd als besparing, maar niet zo mooi als die all over the load range lambda regeling die wij hebben.

[LouisXIV]

Een belangrijk verschil tussen LTFT en STFT is echter nog wel dat de LTFT wordt opgeslagen; de STFT niet. De laatste begint bij motorstart dus weer op 0% terwijl de LTFT van een opgeslagen waarde wordt genomen.
Ik heb ook het idee dat dit de reden is van het hebben van deze twee waarden.

Uitgaande van een motor met een probleem, zoals een luchtlekkage, wil je wel dat de motor kan lopen. Wanneer de LTFT op 20% staat en dan terug gezet wordt naar 0%, kan dit problemen opleveren.

long term fuel trim en short term fuel trim.

[Piet]

Al enige tijd spookte in de mist  in mijn hoofd het idee van een wideband lambdacontroller voor de M44  rond.
Na er een keer met Yits erover gehad te hebben, is die er met zo veel enthousiasme zeg maar.. gezond fanatisme...mee aan de slag gegaan dat het idee concretere vormen begon aan te nemen of liever gezegd... heeft hij het met veel kunde realiteit gemaakt.
Alhoewel het systeem zoals hij hem gemaakt heeft werkelijk prima voldoet, wilde ik er toch graag een wat fijner vanuit een 16x16 load/RPM tabel gestuurd systeem van proberen te maken.
Is dit nodig voor op de weg?... Ik denk het niet.
Maar voor fijntunen op een hudyno waarop je cel voor cel af kunt stellen wel prettig, voor de botersoepele loop van de motor.

Voor dat doel heb ik het fraaie door hem gemaakte printje wat moeten verkrachten door er wat uitbreidingen op te solderen:



Het gaat dan voornamelijk om het bijplaatsen van een EEPROM ten eerste om de AFR tabel in kwijt te kunnen, daar het niet meer in het geheugen van de microcontroller past en ten tweede omdat ik de tabel later ook "on the fly" aanpasbaar wilde maken, wat niet kan als de tabel in het geheugen van de microcontroller zelf zit.

Naast het analoge widebandsignaal heb ik dan ook een rpm en een load als input nodig. Het RPM signaal van de ECU naar de toerenteller via B21 bleek hier uitstekend geschikt voor.
Load was lastiger, ik hoopte dat het loadsignaal voor de automaat (die vreemd genoeg bij een handbak ook door de ECU geproduceerd wordt) hier geschikt voor zou zijn.
Maar na die meegelogd te hebben bleek de relatie tussen dit signaal en de load van de ECU hier niet sterk genoeg voor te zijn.
Nu wordt de load in de ECU berekend door de Airmass te delen door de RPM en die te vermenigvuldigen met een aantal constanten zoals bv, de injectorconstante.
Na de RPM, airmass en de load  in een grafiek in Excel te hebben uitgezet bleek er een duidelijk lineaire relatie te bestaan.
Dit maak het berekenen van de load uit het rpm en mafvoltage signaal vrij eenvoudig. Dit in een aantal logs nagerekend bleek de berekende load binnen een marge van een paar procent te kloppen met de load van de ECU.
Er moest dus ook een MAF tabel in de EEPROM die de relatie MAFvoltage - airmass weergeeft.
De standaard maftabel voldoet hiervoor, grotere mafs zijn hieruit weer te berekenen via reeds bekende conversiefactoren (zie volovospeed).

De benodigde signalen afgetakt uit de ECU, voorlopig voor het gemak nu later tak ik ze van de ECU voet af):


De bin aangepast: Alle cellen in de VE-map op 1, de load treshlod lambda control tabellen allen op maximaal, LTFT upper en lower limit beide op 0 om de LTFT uit te schakelen, de STFT upper en lower control range naar 50%.

De microcontroller geherprogrammeerd met mijn programma en de weg op.
Bij stationair en cruisen inderdaad de afr van 15.3 die ik gevraagd had (nog een beetje voorzichtige waarde).. Bij geleidelijk opvoeren van de load loopt de AFR mooi geleidelijk mee naar beneden.
Lijkt te werken dus. Geeen overshoot etc.
Alleen bij volgas volgt de AFR te langzaam, er moet nog aan gesleuteld worden dus. De reactie van de AFR moet sneller, moet kunnen gezien het resultaat van Yits.
Er moet nog veel gelogd en geanalyseerd worden dus......

[Maarten-t5]

Coherent verhaal yits. 1 kleine gedachte die ik had. Naar wat ik ervan begrepen heb streeft de ltft ernaar om de stft rond de 0 te laten oscilleren. Als de ecu dus merkt dat hij bij een stuk rijden te lang positief blijft gaat hij al oplopen. Hij hoeft niet eens over die grenswaarde van 25% heen om al een beetje te gaat lopen voor zover ik weet.

In principe denk ik ook dat de ltft met wideband control totaal overbodig/ nadelig is. Hij heeft geen functie meer, omdat dat systeem alleen werkt als de referentie altijd hetzelfde is(14.7). Nu past ie alleen maar een correctie toe op een waarde die constant iets anders betekend als het ware.

Eerlijkheid gebied mij ook te zeggen dat ik vrij sceptisch was toen je eraan begon. Ik vroeg me af of de stft snel genoeg zou corrigeren. Inmiddels is wel bewezen dat ie dat kan en ben ik vrij enthousiast over dit project en daarnaast ook over de koudestart verrijking tweak. Ik rijd heel veel korte stukjes (yes I know, slecht enzo, maar het is de realiteit). Ik denk dat ik veel profijt ga hebben van je bevindingen.

[classicT5]

Mooie uitleg van zowel yits als piet.  Wat een helden!

Ik heb zon wifi reader op mijn obd2 aangesloten, viel me op bij constante snelheid, bv 100 op cruise control, de stft toch steeds blijft bijregelen, vind dat raar moet toch op een gegeven moment constant worden.

[razorx]

@Maarten: Ik moest ook aanzien of de regeling snel genoeg zou zijn. Had de zelfde scepsis.
Maar hij is snel genoeg en preciezer dan de standaard setup.

@Piet: Top werk Piet!
Ik ben zo blij met je aanvulling.
Twee denken beter dan één en we vullen elkaar goed aan.
Technische zaken aangaande de microcontroller bespreken we toch al in onderonsjes.

Morgen ga ik testen met een volledig uitgeschakelde long term fuel trim, dus wideband zoals het volledig hoort.
Wat rest dan:
-PID regelaar van de ECU misschien optimaliseren. Kan wiskundig, kan met vakmanschap en met vuistregels.
Laatste methode kost meer tijd maar is in de praktijk vaak nauwkeuriger. Helemaal tegen mijn principes, maar er spelen meer  onbekenden mee.
Hiermee kan de snelheid en de precisie van de regeling verder verbetert worden.

Wat die laatste regel aangaat: Het is mijn ervaring dat een snellere en nauwkeurigere regeling van de lambda waarde een zeer positief effect heeft op zowel de doseerbaarheid, als ook de alertheid bij het hanteren van het gaspedaal.

-Neven handelingen van de ECU zoals de acceleratie verrijking volledig begrijpen en onder controle hebben.

Anyway: Het plezier gaat door!

[razorx]

Mooie uitleg van zowel yits als piet.  Wat een helden!

Ik heb zon wifi reader op mijn obd2 aangesloten, viel me op bij constante snelheid, bv 100 op cruise control, de stft toch steeds blijft bijregelen, vind dat raar moet toch op een gegeven moment constant worden.

Nee dat is zijn taak juist. Hij moet continu corrigeren om de lambda waarde op de juiste cruise waarde te houden. Dat gebeurt in iedere auto.
Ietsje verrijken, ietsje verarmen, rond de optimale waarde. Bij WOT gaat die regeling standaard uit. Dat willen wij juist niet.

[classicT5]

Ik bedoelde meer dat je zon zaagtand effect ziet. Ik zou verwachten dat dat effect vermindert en richting 0 moet gaan bij constante belasting.

[razorx]

@classicT5: Dat klopt. bij konstante belasting oscilleert de STFT om de 0.
(Mits de ECU op de injectoren gecalibreerd is)

Het weer zat mee, dus maar lekker aan beide auto's gesleuteld.
Van de R de voor remblokjes vervangen en omdat ik toch met koperpasta bezig was meteen de stuuruitslag begrenzers een likje gegeven.

Meteen even naar de bandenboer in de straat gegaan om twee Potenza's te bestellen. Achter had ik die al.
De reden: Voor zitten twee Conti Sportcontacts uit 2010. Kreeg ik bij aanschaf van de auto.
Dit is hun toestand na vier jaar zowel links als rechts:


Ni vind ik de Sportcontacts van Conti toch al een veel te zachte wang hebben voor een zware snelle wagen, dus dit was de spreekwoordelijke druppel. Dan maar liever die veilige en stugge Potenza's met hun heerlijke grip.

Bij Saskia haar wagen een oliewissel gedaan en meteen de ABS controller vervangen door het exemplaar van Thomas. Nog bedankt!

Op de terugweg van mijn moeder even langs gegaan bij StefanCJ voor een hondenrek. Ook jij bedankt!

We bleven daar schandalig kort. Ik zat weer eens met een brainwave en dan wil ik daar zo snel mogelijk mee aan de gang.
Wat Piet doet met zijn RPM-load tabel is toch wel netter om de lambda waarde te dicteren dacht ik. Eén gedachte.

OK ik gebruik de LMM spanning. Die is gelijk aan konstante*load*rpm. Komt in de buurt, maar minder puur.
Piets way of lambda regeling betekent voor mij de keuze voor een processor met wat meer RAM geheugen om de tabel of tabellen in op te slaan. Kijken wat ik aan pin compatible processor kan vinden. Microchip processoren zijn over het algemeen zeer pin compatible.

Tegelijk knaagde de curve van de LMM aan me. Bij mijn grotere LMM komt 2,19V overeen met een load van 4. 0,1V lagere output van de LMM betekend in dat gebied al een aanzienlijk lagere load. Bevalt me niet. Goed, de Ecu moet het er ook mee doen, maar toch.

Een andere gedachte was dat je wel via een afgetapt LMM signaal en een afgetapt RPM signaal uiteindelijk naar een load versus rpm tabel kan werken voor aansturing van de lambda waarde, maar waarom niet de load en de RPM rechtstreeks uit de ECU lezen via de data logging output?
Wel zo puur, en je hebt er meteen een hoop andere real time parameters bij. Je weet maar nooit hoe die van pas gaan komen later.

Zo al fantaserend op de terugrit van StefanCJ naar huis bleef het in mijn hoofd malen. Zou het niet mogelijk zijn de lambda output van mijn printje rechtstreeks te "injecteren" in de ECU. Scheelt gefrot aan de bestaande bekabeling. Het is maar een gedachte.

[V70geRwin]

Aparte plek voor droogtescheurtje 
Welke versie van de sportcontact is dit Yits?
Bedoel je met Potenza's de RE050A ?

[razorx]

Het eerste zal ik morgen checken.
Wat de Potenza's aangaat: Inderdaad de RE050A.

[Piet]

Een nadeel van het opslaan van de tabellen in het ramgeheugen is dat je ze dan niet meer kunt wijzigen "on the fly" omdat je om de tabellen te wijzigen de micocontroller in zijn geheel moet herprogrammeren.
Opgeslagen in een EEPROM moeten ze via de usb en via een interruptroutine te wijzigen zijn terwijl de microcontroller door kan blijven gaan met de lambda te regelen.

Het is vrij eenvoudig de load en rpm via het logsysteem binnen te halen, de reden dat ik dat niet doe is, naast dat dat veel te langzaam is, ook lang niet betrouwbaar genoeg is.  Het mafsignaal  en het rpm signaal voor de toerenteller zijn vele malen betrouwbaarder.

Het werkt nog niet helemaal zoals het moet. Bij geleidelijk opvoeren van de load volgt de afr prima echer bij wot gaat hij achter lopen.
Om er achter te komen waar dat aan ligt heb ik "eyes and ears" nodig voor de microcontroller die daar nu onbespied in het vooronder bezig is.
Hiervoor is een marriage nodig tussen de microcontroller en de arduino die ik voor het loggen gebruik.
Eyes is dan de arduino, ears is de seriele verbinding tussen de arduino en de microcontroller.
We laten dan de verschillende parameters waar de microcontroller mee werkt in de logframes van de ecu naar tunerpro meesturen. Ik kan dan in 1 oogopslag zien of de berekende load overal overeenkomt met de ECU load, de berekende airmass klopt met de airmass vlgs de ecu, of de requested lamba overeenkomt met de door mij bedachte lambda etc.
Maarten (was zijn idee om het zo serieel te doen) en ik werken er samen aan en we hebben het praktisch werkende, helaas te laat geworden om in de auto uit te testen.
Moet nog maar even tot morgen wachten .....

[razorx]

Weer uitstekend bezig Piet.

Inderdaad RAM is onhandig. EPROM is niet user programmable, de interne EEPROM is met 256 bytes bruikbaar voor één tabel. Zou net kunnen.
Vind dat te krap voor eventuele toekomstige wensen. Jouw keuze voor een externe seriële EEPROM is dus uitstekend.

Op het moment dat ik dat typ zou je achterover moeten gaan zitten een trekje van een sigaar nemende, terwijl je niet rookt, en droog op moeten merken: Uiteraard.

Geintje.
Die eyes en ears met die Arduino er naast is geen gek idee.

Die data tap is inderdaad te langzaam. Staarde me blind op de baud rate en niet op de snelheid van die 8051 processor variant in onze ECU.

OK je hebt de juiste keuzen gemaakt. Fantaseerde nog even over direct memory reads and writes naar de ECU, maar dat wordt te gevoelig en te complex denk ik.

-edit- De snelheid van het bereiken van de juiste lambda waarde heb ik juist wel weer onder controle. Interessant. Ben benieuwd waar het verschil in zit. Nooit te oud om te leren.

[V70geRwin]

Het eerste zal ik morgen checken.
Wat de Potenza's aangaat: Inderdaad de RE050A.

Was ook altijd mijn band, nu de sport contact 5 en die is idd iets zachter maar wel erg goed en met name beter in de regen.
Maar naast de potenza is elke band zacht, wat een krengen om erom te leggen.