Citaat van: jeroen74 op 23-07-2014 00:42:30
Ik geloof dat wij wat langs elkaar heen praten

Met een std sensor is het ook mogelijk verschillende AFRs te verkrijgen; ik weet haast zeker dat er niet altijd naar lambda=1 geregeld wordt. Wat nut zou anders een AFR target table hebben als het toch altijd 1 moet ziijn?

Omdat dat blijkbaar mogelijk is, zie ik niet wat voor voordeel een narrow band sensor biedt en waarom je uberhaupt het HEGO signaal moet "modificeren" om ook regeling bij hoge belasting te krijgen. Dat werkt al bij lage belasting en waarom zou het niet bij hoge belasting?

Een narrow band slaat (volledig)  om bij 14.7 (benzine) beter gezegd bij lambda 1, that's it.
Target lambda is dan ook bedoeld voor de situaties buiten de closed loop gedeelten.
In de closed loop gedeelten zal het systeem inderdaad altijd naar het omslagpunt van de sonde regelen en die is dus gewoon bij lambda=1 en nergens anders.

Het is dus te rijk of te arm wat de sonde betreft, valt helemaal niks aan te moduleren.
De sonde is een sensor, geen actuator die je met puls duur modulatie kunt regelen...

De enige manier om het "omslagpunt" te verleggen is met een wideband.

Citaat van: jeroen74 op 22-07-2014 23:05:32
Met de std narrow band kan toch ook gewoon geregeld naar verschillende AFRs?  Een kwestie van de verhouding tussen de arm en rijk periode (zeg een soort PWM)  waarbij de sensor een ijkpunt geeft.

Het enige wat je daarbij aan het meten bent is de overshoot van het closed loop systeem.

Maar de informatie die tijdens closed loop wordt vergaard (de benodigde injectortijd om Lambda=1 te verkrijgen, fueltrim?) wordt dan weer gebruikt om de openloop te calibreren neem ik aan ik aan?

Ik vraag me af of het wel verstandig is om met een apart kastje het omslagpunt te veranderen; voor je het weet heeft dat kastje bijna dezelfde complexiteit als de ECU vanwege alle input variabelen.

Komt de onherroepelijke vraag of je de boel dan niet aan het 'gold platen' ben. Het veel beter maken dan strict noodzakelijk (aangezien widesensors door bijna niemand gebruikt worden). Of heel veel werk met weinig voordeel.

Alleen de LTFT kan in open loop aangewend worden; of dat ook echt gebeurt, zet ik nog steeds vraagtekens bij. STFT niet; die wordt direct gevoed door de sensor. LTFT wordt opgeslagen; STFT niet (gegevens zijn kwijt bij herstart).

Wideband sensoren zijn gemeengoed aan het worden vanwege de hoge meetsnelheid. Dit stelt de fabrikant in staat het mengsel nog meer cilinderselectief te regelen waardoor emissies nog verder omlaag kunnen.

Citaat van: jeroen74 op 23-07-2014 11:58:18
Maar de informatie die tijdens closed loop wordt vergaard (de benodigde injectortijd om Lambda=1 te verkrijgen, fueltrim?) wordt dan weer gebruikt om de openloop te calibreren neem ik aan ik aan?

Nee, niet op een directe manier. Daarom kun je ook via de tabellen de afr's vrij nauwkeurig instellen op waardes die je wilt hebben.
LTFT is feitelijk bedoeld slijtage van onderdelen en/of veranderde omstandigheden op te vangen, het is niet onlogisch dat deze in de open loop meegenomen wordt door de ECU om ook daar de in de tabellen vastgelegde gewenste waardes te behouden.

Citeer
Ik vraag me af of het wel verstandig is om met een apart kastje het omslagpunt te veranderen; voor je het weet heeft dat kastje bijna dezelfde complexiteit als de ECU vanwege alle input variabelen.

Dat is maar net wat je complex vindt , qua electronica is een omslagpunt afhankelijk maken van de load niet echt ingewikkeld, vrij eenvoudig zelfs met een microcontrollertje. Met een paar componentjes en een beetje programmeren is zoiets eenvoudig te realiseren.

Citeer
Komt de onherroepelijke vraag of je de boel dan niet aan het 'gold platen' ben. Het veel beter maken dan strict noodzakelijk (aangezien widesensors door bijna niemand gebruikt worden). Of heel veel werk met weinig voordeel.

Tja zo geredeneerd hoef je nergens meer aan te beginnen... af fabriek is het motormanagement al veel en veel beter dan strikt noodzakelijk.

Dat iets niet zinvol zou zijn omdat het niet veel gebruikt wordt is een foutieve, onproductieve en omgekeerde redenering.

Met complexiteit bedoel ik uiteraard niet de electronica, die is triviaal.  Je moet echter wel zorgen dat zowel ECU en 'kastje' ten alle tijd gesynchroniseerd blijven. Het kastje zal op zijn minst toch dezelfde op dezelfde manier met dezelfde inputs de load moeten bepalen. Ik weet even niet hoeveel inputs er precies zijn, toerental en MAF? Correctie voor motortemperatuur?

Met een extra kastje op zo'n kritisch signaal verlaag je ook de betrouwbaarheid en bij problemen verhoogde complexiteit.

Juist om die reden blijf ik bij mijn vraag of fulltime closed loop nou echt veel beter is en voordelen biedt dat het opweegt tegen de nadelen? Zeker als blijkbaar open loop de boel ook al nauwkeurig bestuurd kan worden op basis van LTFT? Waaraan zou je het, meetbaar, aan moeten merken?

Overigens ter verduidelijking: ik heb het specifiek over Yits zijn situatie, over techniek in de toekomst ontwikkeld door fabrikanten met al hun resources zal het ongetwijfeld de wave of the future zijn.

Maar Yits heeft maar 1 motor waar ie heel zuinig op en voorzichtig mee is. Als ie hem door een lullig programmeerfoutje volkomen in de soep draait, zal ie staan te janken als een kind bij wijze van spreken terwijl ze bij Audi of wherever schouderophalend een nieuwe motor uit het rek trekken; x aantal exemplaren zijn voor gebudgetteerd.

nope... via het Tq signaal uit de ECU weet je de interne load van de ECU.
Ofwel je gebruikt de interne load van de ECU zelf, de zaak is dan vanzelf (intrinsiek) altijd in sync met de ECU
Niks complex aan.

Ik heb het ook specifiek over dit aankomende projectje.
Het hele zelf tunen heeft een risico in zich, maar dat is een kwestie van gezond verstand en voorzichtigheid.

En tja met een carburateur, puntjes en mechanische vervroeging kun je een  motor uiteindelijk ook goed laten lopen..

Aha, dat Tq signaal had ik even over het hoofd gezien Ja, dan is het haast lachwekkend triviaal.

Als je specs van dat Tq signaal weet, moet je zoiets in een avondje of 2 max in elkaar moeten kunnen knallen.

De echte uitdaging zit in de aanpassingen in de bin zelf met een good old assembler

Ik ga het niet in elkaar knallen. Ik ga het weldoordacht ontwerpen.

Ik geloof zozeer in dit idee dat ik er een printje voor laat maken. Ik heb zoals bekend een ontzettende hekel aan experimenteer printjes, hoe handig ze ook kunnen zijn. Het wordt gewoon weer professionele productie. Dus nu vrolijk bezig te katkammen met Altium Designer. Printje krijgt zekerheidshalve wat extra vrije eilandjes en een extra I/O connector voor eventuele extra wensen.

Resultaat definitie:
-Storingsvrije werking
-Zuiniger rijden onder deellast
-Exact definieerbare lambda waarde onder last en vollast
-Verhoogde tolerantie van het systeem voor de al eerder genoemde variabelen
-Perfecte injector matching onafhankelijk van de gekozen brandstof
-Vergrootte versimpeling van de tuning

Uiteraard zal ik het hele ontwerp automotive gebruik bestendig zijn. Dus met componenten die langdurig tegen hitte kunnen zijn, ompoling en nog veel meer.

Citaat van: PietDe echte uitdaging zit in de aanpassingen in de bin zelf met een good old assembler

En waarschijnlijk is de ECU software geschreven in assembly ook, ipv een hogere taal. Bij het eerste zal het wel enigzin te volgen zijn, compiler-gegenereerde code daarentegen is vrijwel onbegrijpelijk

Als je dan toch in die bin gaat hacken, kun je dan niet gewoon het hele 'kastje' vergeten en de hele handel regelen in de ECU zelf? Als de Lambda sensor op een analoge ingang zit, moet er haast wel ergens een stukje code zitten dat de spanning vergelijkt met een bepaalde threshold. Als je die threshold nu load-afhankelijk maakt, heb je helemaal geen 'kastje' nodig.

Of bedoel met de bin puur alleen de tabellen, ipv van de onderliggende code die ze gebruikt?

Gaat niet. de Ecu mist simpelweg de rekenkracht voor real time floating point berekeningen. Daarnaast, zoals al eerder gesteld, is de code in de ECU gebaseerd op een 0/1 of 1/0 overgang op een digitale input voor het lambda signaal.
Een complete code rewrite zie ik niet zo zitten.

Daarom is deze oplossing, als hij werkt, de ideale en simpelste benadering.

Je hebt toch ook geen floating point nodig... Zat er geen ongebruikte analoge input op? Die gebruik je nu toch om de wideband mee mee te loggen als ik me het herinner?

( Excuses dat ik te lui ben om deze hele thread door te lezen op zoek naar het antwoord op die laatste vragen )

Uiteraard is een complete rewrite onzin, maar bepaalde mensen zijn blijkbaar in staat om er hele stukken bij in te knopen om realtime te loggen en dat kost ook rekenkracht.

Dan moet een simpele compare op een analoge waarde ipv een digitale ingang lezen toch niet al teveel power kosten.

Jouw printje gaat toch niets anders doen dan op basis van het Tq signaal een referentiespanning uitsturen voor een comparator die het wideband sensor signaal omzet naar een digitaal signaal?

bin als afkorting van de binary, nee niet alleen de tabellen dus.
De code wordt gaandeweg anders toch al aardig ontrafeld hoor... zo zijn er aanpassingen gemaakt waardoor er met coil overs (COP) gereden kan worden in plaats van de enkele bobine mechanische verdeler combinatie.

De tegenwoordige pietmobiel (met copjes dus):
www.meditekst.nl/cop/COP.wmv

Jouw auto is toch meerdere poepies sneller dan de mijne

Bij mijn vorige auto had ik ook graag in de ECU code cq tabellen willen frutten, al was het maar om het stationair toerental wat lager te krijgen en de multiple discharge mode van de EDIS6 te enablen.

Jammer genoeg was er geen enkele informatie beschikbaar over de software van deze ECU (zeldzame motor), terwijl voor hetzelfde ECU systeem voor Amerikaanse auto's zoals Mustangs er ruim voldoende kennis, ervaring en tools was; maar die zijn dan ook heel wat minder zeldzaam

Ik heb echter nooit voldoende drang gevoeld om een van de vele J3 port tools te gebruiken om de code te downloaden, te disassemblen en dan lekker te hacken