Eeeh Yits,

4 jaar met Sportcontact2 op de vooras van ongeveer 270pk?

Geef een gas joh.

Die moeten er met max een jaar af liggen 

Citaat van: Lunadust op 18-10-2014 22:26:14
Eeeh Yits,

4 jaar met Sportcontact2 op de vooras van ongeveer 270pk?

Geef een gas joh.

Die moeten er met max een jaar af liggen 

Die potenza's deden met chip en bbk toch nog 35k, niet verkeerd.

Ben ondanks de huidige 310 pk, voor wat dat waard is, een rustige rijder.
Daarnaast lagen ze tot een week terug achter. Verder niet interessant, behalve het snelle en gevaarlijke verval.

Hoe oud waren ze? (productiedatum?)

Citaat van: razorx op 18-10-2014 22:06:47
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.

Mja, die externe eeprom is voor nu even een snelle en makkelijke keuze.
Uiteindelijkl ligt een ander microcontroller met meer interne eeprom weer meer voor de hand.

Citaat van: razorx op 18-10-2014 21:15:52
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.

Dat valt nog te bezien.
Elegantie zit vaak in de eenvoud, voorlopig lijkt jouw methode in de praktijk goed te voldoen.
Er zit hier overigens een typo in je tekst het is:  konstante*load/rpm

Citeer
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.

Rest assured..... je maakt een rekenkundige slip of the mind hier:
Load=54*Airmass/RPM
2.19 volt komt bij een S90 MAF overeen met 178.89 kg/hr en 2.09 volt komt overeen met 160.8 kg/hr
Bij 2415 RPM betekent dat een load van 4 ms bij een mafvoltage van 2.19 volt en een load van 3.6 ms bij een mafvoltage van 2.09 volt
Over de resolutie van een grotere maf hoef je je dus absoluut geen zorgen te maken, al zet je er een 6" rioolpijp maf op.

Je zit hier trouwens ook al in het steilere gedeelte van de curve.
Onder deze voltages, daar waar de resolutie er steeds meet toe gaat doen  (in het vlakke eerste gedeelte van de curve) worden de verschillen ook nog eens een stuk kleiner.
Ik merkte bij een 3.25" maf dan ook totaal niks van een eventueel resolutieverlies.
Dat een grotere maf gepaard zou gaan met een merkbaar verlies aan resolutie is 1 van die vele forummythes

Op de slip of the mind na ben ik het volledig met je eens.
Aangezien Load=54*Airmass/RPM is, volgt hieruit dat
Airmass = Konstante * load * RPM

Daarom is dat LMM signaal zo leuk.

Volgens mij heeft de adc van die pic toch een resolutie van 10 bit?
Dan kan ie die 0.1 volt in stappen van 0.0049 volt meten (onzekerheid negerend). Dmv interpolatie zou ie de load dan op zich wel redelijk nauwkeurig moeten kunnen bepalen.

Citaat van: Vulk op 19-10-2014 08:42:53
Hoe oud waren ze? (productiedatum?)

2010.

@Maarten: Dat interpoleren is een goed idee. En inderdaad de ADC is 10 bits.

Citaat van: razorx op 19-10-2014 12:41:27
Op de slip of the mind na ben ik het volledig met je eens.
Aangezien Load=54*Airmass/RPM is, volgt hieruit dat
Airmass = Konstante * load * RPM

Daarom is dat LMM signaal zo leuk.

Je bedoelt dat met die typo hier?
Ik heb inderdaad licht leesblind te vluchtig over je formule waar je de termen verwisselt had heen gelezen. Die klopt uiteraard wel.

Dat de load niet al te veel met een mafspanningsverschil van 0.1 volt verschilt en dus de resolutie hoog genoeg is ben je wel met me eens?

Citaat van: razorx op 19-10-2014 14:07:27

@Maarten: Dat interpoleren is een goed idee. En inderdaad de ADC is 10 bits.

Zelfs als je hem in een byte inleest is de resolutie nog hoog genoeg 5volt/ 255 = 0.02 volt

Volledig mee eens Piet.
(Beide posts)

Het via de arduino meeloggen van de waarden waar de microcontroller intern mee werkt zoals de rpm die hij meet, de actule AFR die hij meet, de  load die hij berekent en de gewenste AFR die hij daarbij wil zien is goed gelukt.
Scheelt  een hele hoop bij het debuggen...... en yep.... er is nog werk aan de winkel... maar ach bugs en debuggen zijn bij dit soort projecten  niet te vermijden.

Eyes and ears....de bevindingen


Met de seriele verbinding tussen de lambdacontroller en de arduino kon ik zien wat er zich in de controller afspeelt en vergelijken met de waardes in de ECU.

De RPM vlgs de controller was exact hetzelfde als die vlgs de ECU, wat niet zo gek is daar de controller deze berekent aan de hand van een door de ECU geproduceerd signaal voor de toerenteller.
Bovenste grafiek.

Ook het MAFvoltage vlgs de controller stemde overeen met die vlgs de ECU
Onderste grafiek.

Dan de load die ik de controller liet bereken vlgs de formule load=54.7*airmass/rpm
De airmass liet ik de controller opzoeken in een maftabel opgeslagen in de EEPROM aan de hand van het MAf voltage.
De zo berekende load bleek behoorlijk goed te kloppen met de load vlgs de ECU
Middelste grafiek.


Op de onderste grafiek is te zien dat het door de controller geproduceerde signaal op de front lambda input van de ECU (blauw) netjes direct reageert op de verschillen tussen de requested AFR (lichtblauw) en de actuele AFR (groen).
actuele AFR > requested AFR (te arm) : lambdasignaal laag
actuele AFR < requested AFR (te rijk): lambdasignaal hoog
Reageert instantaan op de wisselingen.

De controller doet zijn werk, zoals dat van hem verwacht wordt.

Op de bovenste grafiek is de reactie van de STFT zichtbaar die naar mijn zin niet snel genoeg en niet fanatiek genoeg is.
Je ziet de AFR de requested AFR toch wel redelijk goed volgen, maar dat is pas nadat ik de VE tabel ook dezelfde waardes had gegeven als de requested afr waardes in de controller.
Met alle waardes in de VE tabel op lambda 1 zie je dat de AFR wel mee wil gaan met de requested afr maar hierin faalt ten gevolge van de STFT die niet fantiek genoeg reageert.

Geholpen door een wel ingevulde VE tabel, de ecu weet dan direct hoeveel benzine hij ongeveer in moet spuiten bij een bepaalde load/RPM lukt het wel beter.
De STFT hoeft dan alleen nog maar te corrigeren voor kleine verschillen.
Met alle waarden in de VE tabel op lambda 1 moet de STFT van te ver komen om goed te regelen, je ziet hem wel pogingen doen. Maar hij haalt het niet.
Er moet dus naar instellingen in de ECU worden gezocht die de snelheid en mate van de STFT reactie regelen.


 
Een opvallend effect waar rekening gehouden moet worden is dat indien er sprake is van knockenrichment de STFT door de ECU uitgeschakeld wordt, zoals hiet boven te zien.
Rood is knock enrichment groen is de STFT
Dat is ook wel logisch daar als er in de normale situatie  knock optreedt in het gebied waar in de lamdacontrole actief is, de ECU wil verrijken bovenop de waarden in de VE-tabel, maar hier nogmaal gesproken in tegengewerkt zou worden door de STFT die hem juist naar de waarde vlgs de VE tabel wil regelen.

Bij regeling door de  lambacontroller heeft dit dan juist een averechts effect, zeker als de waarden in de VE tabel lambda 1 zijn, daar dan de hele lambdaregeling wegvalt en de AFR terugvalt naar die lambda 1 in de tabel wat door
de fuel enrichment niet te compenseren is.
De AFR loopt daardoor dus juist op in plaat van dat die om laag gaat!!
Er valt dus een zeer belangrijke bescherming bij knock weg!!!
Sterker nog die werkt door verarming knock juist meer in de hand!!
Vooral ook omdat we de STFT nu over het hele gebied laten werken.
Het is dus sowieso verstandig de VE tabel niet op een waarde van 1 te zetten ook als zou de STFT snel genoeg zijn om dan de AFR goed te kunen regelen, hij wordt immers domweg uit gezet.

Nog een plaatje waar het lambdasignaal (blaue) en de raectie van de STFT (groen) over elkaar geprojecteerd zijn.
Ook het effect kwa AFR (blauwe neergaande lijn) t.o.v. de rquested afr (roze)

De middelste grafiek geeft de RPM weer.

De bovenste grafiek laat de fuelenrichment zien (rood) en de sum of knockretard (blauw)
Op het moment dat de fuelenrichment wat gaat doen gaat de STFT direct naar 0.

Nuttig werk weer Piet.
Je hebt hier hard mee aangetoond dat de VE map de wenswaarden moet bevatten.
Niet alleen voor een snelle regeling, maar ook om een door knocking tijdelijk uitgeschakelde stft te ondervangen.