Begrijp hem helemaal haha! WB mod werd volgens mij normaalgesproken door de 'leveranciers' geconfigureerd. Dus inderdaad even aan Aaron vragen dan. Ik weet dat de Nederlandse kant de VE tabel als gecombineerde AFR target gebruikte, dus daar ging ik in mijn advies van uit.

Ik zou die vraag vooral bij Aaron neerleggen, hoewel de basis van de WB mod bij alle m4.4 bins gelijk is, kan de implementatie verschillen. Met name welke tabel door de logica gebruikt wordt. Dat is door 'hobbyisten' (maar wel aardig professioneel) allemaal ge-reverse-engineerd en door eenieder die dat spul levert weer een eigen naam gegeven. Dan zwerven er ook nog allerlei aangepaste bins/xdf's van individuele gebruikers rond die hier en daar eea naar eigen wens hebben vernoemd. ChatGPT is zeker handig, maar gaat over M4.4 geen betrouwbare kennis kunnen delen.

Praktische WB logging conversie

In het kader van een bijdrage leveren wil ik delen hoe je de praktische conversion voor Wideband Logging kan verkrijgen. Deze kan namelijk afwijken van de theoretische conversie.

Ik heb een Spartan 3 Lite Wideband controller waaraan een LSU4.9 hangt. Volgens specs is 0V gelijk aan 10 AFR en 5V gelijk aan 20 AFR. Analoge ADC Input ECU is 8bits (ik heb Rear O2 genomen), oftewel hoogste getal is 255 decimaal. We doen aanname dat zowel WB controller als ADC input 0-5V doet. In geval van Spartan moet zowel Gauge als Linear Output zelfde ground op ECU hebben, en dat heeft deze bij mij dan ook.

De theoretische conversie formule x*((Max AFR - Min AFR)/ 255)+Min AFR => x*0.0392156863+10
Nu ben ik gaan loggen wat voltages doen op zowel Wideband Gauge (het metertje) als raw data in Tuner Pro. Raw data is makkelijk. Onder conversion houdt je alleen maar waarde 'x'. Tuner Pro Dashboard zal nu waardes tussen 0 en 255 weergeven (denk aan 8bits, oftewel 2⁸)

Gisteren ff een tabeltje gemaakt. Dat alleen om zeker te weten dat het ook echt lineair signaal is aldus specificaties. Aan ja dat is het. Alleen 0V en 5V kolommen zijn van belang;

Volts:	0	1	2	3	4	5
Raw Data ECU:	2	52	102	153	204	254
Gauge AFR:	10	11.9	13.9	15.9	17.9	19.8

Wat valt erop aan de gemeten waardes?!

• Raw Data ECU begint bij 2. Niet bij 0 aldus theorie
• Raw Data ECU eindigt bij 254. Niet bij 255 aldus theorie
• Gauge AFR eindigt bij 19.8. Niet bij 20 AFR aldus specs

Wat houdt dat in? Raw data zal maximaal 252 verschillende waardes hebben ipv. theoretische 255 (8bits). Max. waarde Gauge AFR valt ook 0.2 lager uit. Raw data minimale waarde is 2 en geen 0. Dit heeft consequenties voor formule. Ik wil Raw data naar AFR omzetten gezien Spartan Gauge alleen AFR kan weergeven (voor Lambda hele zooi aan eind door 14.7 delen)

Ik ben tot de volgende formule gekomen voor praktische conversie;
x* ((Max Gauge AFR – Min Gauge AFR) / (Max Raw Data ECU – Min Raw Data ECU)) + (Min Gauge AFR – ((Max Gauge AFR – Min Gauge AFR) / (Max Raw Data ECU – Min Raw Data ECU)* Min Raw Data ECU))
oftewel aan de hand van data;

x*((19.8-10)/(254-2)) + (10-(((19.8-10)/(254-2))*2)) =>
x*0.03889 + (10-(0.03889*2)) =>
x*0.03889 + 9.922

De waardes achter '+' zijn omdat raw data 0 onder de 10 AFR ligt. 9.922 AFR wel te verstaan. Gezien deze nooit (bij mij) zal worden weergegeven gezien 0V gelijk is 2 Raw Data ECU is en 10 AFR Gauge. Voer maar waarde 2 in bij x. He dat is 10 oftewel 10AFR. Mooi!

Wat maakt theoretisch met praktisch uit?
175 raw theoretische conversie: 175*0.0392156863+10 = 16.86 AFR => 16.9 Tuner Pro
175 raw praktische conversie: 175*0.03889 + 9.922 = 16.73 AFR => 16.7 Tuner Pro
Wat het bij jouw setup kan schelen....

Inmiddels het ik reactie van Aaron. Nu weet ik zeker dat ik de conversie in .ADX en .XDF op juiste plekken heb doorgevoerd. De vraag mbt. functie van "AFR (VE) Map Part load" blijft onbeantwoord. Laat ik het zo formuleren dat documentatie nihil is afgezien van wat/waar/welke weerstanden voor COP conversie solderen. Enfin doodlopende weg... dan maar zelf pielen en hopelijk zonder te slopen....

Inmiddels trek ik de conclusie dat tabel "AFR (VE) Map Part load" gevraagde fueling is (duhhh) in AFR uitgedrukt. Dus heb ik deze tabel hernoemd naar "Requested AFR" in .XDF gezien dit voor gehele Load bereik geldt. Deze getallen zeggen denk ik ook niet zo heel veel omdat het op basis gaat van VE van 100% gemikt op stoich. Dat (nagenoeg) niet het geval zal zijn. Volgens mij is het in Jip-en-Janneke-taal; Je stopt een waarde in "Requested AFR" dat idealiter zich zal vertalen naar "Target AFR" in open-loop als je op je WBO2 Gauge of logging/Dashboard van Tuner Pro kijkt.

Om een goed start te maken heb ik een .bin met Requested AFR tabel een aantal cellen op 14.7 gezet (lage RPM, lage Load) om Injectoren nog eens te calibreren (verschilt met narrowband). Welke load met welke RPM een VE van 100% geeft is voor mij giswerk. Ik heb rond 3K RPM genomen met Load van ergens rond de 2ms (High Performance Academy EFI course adviseert rond 3K voor calibratie Injector constante). Voor dead times is dat stukken makkelijker.

Met wat prutsen en loggen lijkt mij closed-loop WB Mod Target AFR na te jagen. Klinkt best logisch. Jammer dat "Requested AFR" (oude VE Map) niet in data-stream wordt meegestuurd. Dan zou namelijk met MegaLogViewer HD een geupdate AFR tabel dmv. Custom Field in Histogram een koud kunstje zijn geweest. Sleur en pleur in Tuner Pro in men zou klaar zijn voor volgende ronde loggen. Enfin dat gaat niet. Voor analyse is MLV HD wel the bomb. Nu heb ik een custom field van [Target AFR]/[WBO2 Curr. AFR] gemaakt en de rest moet per cell met de hand. Dat wordt dan [Target AFR]/[WBO2 Curr. AFR]  * Requested AFR = New Requested AFR.

Eerst maar eens een realistische Target AFR tabel maken. Standaard geleverde bin schiet voor vrij rijk, denk ik wegens liability redenen.

Any thoughts?

Lijkt erop dat je dan een split-table AFR mod hebt. Als ik je goed begrijp, noem jij de VE tabel nu "Requested AFR" in de zin van "dit is wat ik wil nastreven", en is jouw "Target AFR" tabel de map die daadwerkelijk door de WB mod wordt nagestreefd.

Denk dat je een eind in de goede richting zit. Megalogviewer is inderdaad een hele krachtige tool, als je die goed gebruikt kan dat een hoop giswerk schelen.

Dat er geen documentatie is, is (helaas) een logisch gevolg van het ontstaan van M4.4 tuning. Namelijk verschillende individuen die in de DAMOS zijn gaan grasduinen en zelf modificaties hebben geschreven, waar dan niet iedereen het altijd eens is met de implementatie en er dus geen 'master project' loopt om het zo maar te zeggen. Dus er zijn meerdere 'forks', met ieder een eigen modpakket en naamgevingen. Zo heeft de Nederlandse tak bij de WB mod implementatie de VE tabel tegelijkertijd als Target tabel ingezet door 1.00 te normaliseren op 14.7. Daar komt het 'uitdrukken in AFR' van de VE tabel vandaan, en ik denk dat dat in jouw tune daar gewoon een overblijfsel van is.

De Amerikaanse tak (VAST Tuning) heeft daar een aanpassing op gemaakt door de VE tabel intact te laten en een losse Target AFR tabel te gebruiken. De beredenering hierachter is dat er geen fysisch sluitende reden was om aan te nemen dat normalisering naar 14.7 ook betekent dat de schaling van die tabel rechtevenredig gelijk schaalt met AFR. Dwz, 1.3000 VE komt niet zomaar overeen met (1/1.3*14.7=) 11.3 AFR. Normaalgesproken is de VE tabel namelijk bedoeld om te corrigeren voor de volumetrische efficientie op basis van toeren en load, wat ook weer sterk samenhangt met je inlaat setup en uitlaat setup, nokkenastiming, etc. Dus als je daarvoor wil kunnen blijven corrigeren, moest je de Target AFR uit een andere tabel halen. Het ene kamp vond dat onzin omdat de WB mod 'het in principe prima doet zo', en het andere kamp vond dat weer onzin omdat de STFT's daarbij rustig +-10 tot +-20% aan het heen-en-weer schommelen waren om de targets te halen.

Zelf ben ik het met die Amerikaanse implementatie eens - een losse Target AFR map waar je instelt op welke RPM en load je welke AFR wil zien, met daarbij een losse VE map zodat je die daarna kan fine-tunen om over het gehele bereik een STFT te realiseren die zo dicht mogelijk rond de 0 schommelt. Zelf noem ik die gewoon nog steeds "VE map" en normaliseer ik hem ook niet naar 14.7 omdat ik daar geen fysische sluitende basis voor kon bedenken en het imo alleen maar extra verwarring zaaide.

Als je Megalogviewer hebt, kun je heel mooi de STFT gebruiken om je VE map te itereren naar je gewenste Target AFR. STFT is namelijk wel gewoon rechtstreeks een %-multiplier, die je theoretisch rechtstreeks op je VE tabel kan toepassen na een fatsoenlijk datalog. Paar iteraties en je zou een hele nette strakke VE moeten kunnen krijgen. Nadeel: als je je Target AFR map verandert, zul je ook je VE map weer moeten aanpassen.

"Requested AFR" is niet zo zeer wat ik wil nastreven. Als dat zou gaan zijn er geen 2 tabellen meer nodig. Volgens mij maakt het niet zoveel uit of je het een VE of een Requested AFR table noemt. Raw data ECU blijft gelijk.

Maar goed wat ga je dan doen bij tuning? Eerst alleen Requested AFR/VE Map aanpassen in open-loop en dan Target AFR hierop voor closed-loop? Of eerst Target AFR en dan Requested AFR/VE Map hierop? Hardop denkend vermoed ik dat 2de optie makkelijker is icm. logging en op de weg tunen. Ik vermoed dat dit ook een kwestie van voorkeur is.

Idd. is het mooi dat met "USA WB Mod stroming" 2 verschillende tabellen een fueling doel vooraf kan opgeven ipv. een correctie dmv. LTFT/STFT achteraf.

Puntje bij paaltje is het allemaal voorkeur, zowel in hoe je tunet als in hoe je je tabellen noemt. In beide gevallen zul je moeten uitzoeken welke AFR bij bepaalde RPM/Load het 'beste' is, of je dat nou open-loop in VE of closed-loop in Target AFR doet is maar net wat jij het fijnst vindt werken.

Citaat van: VolvoFreak89 op 29-07-2025 02:26:43Als je Megalogviewer hebt, kun je heel mooi de STFT gebruiken om je VE map te itereren naar je gewenste Target AFR. STFT is namelijk wel gewoon rechtstreeks een %-multiplier, die je theoretisch rechtstreeks op je VE tabel kan toepassen na een fatsoenlijk datalog. Paar iteraties en je zou een hele nette strakke VE moeten kunnen krijgen. Nadeel: als je je Target AFR map verandert, zul je ook je VE map weer moeten aanpassen.

Dit is inderdaad een goede Kan ook zo op Requested AFR toegepast worden. Aan principe verandert niets.  Ik denk dat ik dat ga doen als ik er een eind ben en het spul weer in closed-loop draait. Target AFR aanpassen is idd. wel een nadeel. Elk voordeel heb z'n nadeel.