Pages: 1 ... 12 13 [14] 15 16 ... 26
Author Topic: ME7.9.10 - Understanding the torque model  (Read 177444 times)
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #195 on: May 12, 2018, 02:10:35 PM »

I do have read out averaging (but only for 4 of them, let me not dive into this now) and plausibility checks / DTC / check-engine things. For a directly connected sensor it is much simpler, either the signal is there, or not. If not, for 2 seconds or so, the ECU limits the load to safe ranges. It's just about stabilising the readout on start up due to air pockets. The idea of EEPROM storage has crossed my mind, but then this is good for stable fuel type usage (you run on E85 only and you use the sensor to compensate for the seasonal ethanol content variations). My use case is frequent fuel switching, the EEPROM value becomes irrelevant when you fuel up with different fuel. Or so I think.
Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #196 on: May 12, 2018, 02:21:57 PM »

It takes a little while after changing ethanol mixture for the new fuel to reach the injectors, at least on a returnless system like the ones I'm targeting. OEMs model the dead space between the sensor and injectors, even if both are located in the engine bay, but I did not think that was necessary. I think the biggest danger with flex fuel sensors is changing the value too rapidly rather than too slowly. It is not a variable that actually changes that quickly on my targets (eg change from E40 to E60 and it may take 100 seconds to stabilise, so ~10000 samples for the value to increase by relative 50%).

Another caution you may have considered or not... What happens if your signal line is shorted to ground or 5V? I also noticed when testing a microcontroller with a function generator that a disconnection of even a fairly short ethanol content wire, if the pull up resistor was not present the wire became an antenna and picked up high frequency noise that if triggering an interrupt without filtering could potentially crash the ECU given the frequencies, depending on how much you do in the interrupt and the actual frequency.

The use of EEPROM was more to use the same variable as a map switcher that would not need rewriting when the ECU was restarted.
« Last Edit: May 12, 2018, 02:31:03 PM by jcsbanks » Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #197 on: May 12, 2018, 02:30:39 PM »

OK then, seems I will have to reconsider the EEPROM storage.

I do have signal debounce, if I get interrupts more often than 0.25ms I quit the routine right away. And otherwise it is very time optimised (hence the 4 readout averaging, I do it without muls/divs). And with low enough interrupt priority to allow the other important things run first. Preliminary tests with giving it high priority crashed the bench ECU right away with no engine attached, could not even keep the CAN communication.
Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #198 on: May 12, 2018, 02:47:18 PM »

Although it is cool to trigger an interrupt, it would make me lie awake thinking about it. I could not give an external input in a noisy environment that influence over my ECU, but I consider any link of any sort as potentially dirty/unsafe/compromised. Because it is quite a slow signal, how about connecting the input pin to a timer/counter and reading the value every two seconds? Then you'd only have 1% error, less than the sensor itself, very low computation requirement, no interrupt load and inherently increased safety?

For higher frequency, you'd want to use a timer and DMA to sweep low/high period pairs into a buffer and filter/average them in a slower task. This is how I'm doing it in the external device. Still no interrupt load though.
« Last Edit: May 12, 2018, 02:51:17 PM by jcsbanks » Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #199 on: May 12, 2018, 03:26:53 PM »

But then again, if it is low frequency, what's the danger with proper interrupt? Same load as with counters (these have to be serviced some time too, no?). These things are programmed and designed with slack, and honestly, an interrupt routine with literally a handful of instructions (it essentially records quadruples of periods / frequencies) with each instruction =~cycle should not do any harm. The actual signal processing / conversion / fault recording is done periodically every 100ms, not in the interrupt routine. I talked to an electronics engineer about this earlier on, and he said 50 to 150 Hz is not a frequency Wink I have done much more risky things on much more stringent architectures Wink

But, let's leave the conclusion until I am sure it all actually works in all conditions, right now it is an academic talk Wink
Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #200 on: May 12, 2018, 03:48:50 PM »

No danger with 150Hz interrupt. No danger with lots of things when they work.

I'm worried about a unlimited interrupt frequency in a fault situation with no recovery potential. That is not academic and needs to be part of the design IMHO, even for you only driving it. Bake in safety as part of the design.

I tested 0.25ms interrupts on 180MHz Tricore and they were OK on the bench by 100% loading the CAN bus with frames. I'm going to test them in the car too whilst the engine is running at red line to be sure even though my intended rate is a fraction of that because one "babbling idiot" on my CAN bus cannot be allowed to bring down a drive by wire ECU. My application has a cap on its maximum interrupt frequency due to the nature of the trigger. Yours is unlimited.
Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5789


« Reply #201 on: May 13, 2018, 11:54:29 AM »

I don't know how it is on your car.

But ME7 on many VAG runs the pump when a door is opened in the vehicle - a priming pulse.
All that is needed is extending that priming pulse until a stable signal is there...

Shutdown EEPROM storage and purely depending on that is a horrible idea, because the car could have been fueled up in the meanwhile.
If you have fuel tank level in ECU, then no problem, you can check for this condition, but if not, you will have a no-start every time you change fuel.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #202 on: May 13, 2018, 12:17:47 PM »

I have given it a lot of thought since yesterday. Came to the conclusion that there are two culprits in this: (a) have a close guess initial value when the ECU boots (with the assumption that the first readings are going to be inevitably skewed, no matter how well I filter / extrapolate / what not). (b) when the pump is off readings have to be suspended and last known good value has to be used. For (a), jcsbanks, hat off to you, no way around it, EEPROM storage that is. For (b), grace time of 1.5 seconds after the fuel pump activates seems to do the trick, will have to see if that's sufficient under different conditions, long stay, cold / hot, more / less E85, etc. prj suggests to register readings only after they get stable, but as much as I agree, I cannot compose myself to implement this at the moment (mostly because I have to pin down "stable" in this context). With previous value EEPROM storage the wait time after pump on can be relatively long, so the result should be the same.

Anyhow, stability detection or not, EEPROM store / restore is a must, so I implemented it, nice and stable now with sufficient wait time: https://youtu.be/PDg0wn9WpE4

I also now activated fuel corrections based on E-content, mostly to see that the code actually works on the car (it did on the bench, but one cannot be more careful with this Wink). WBO in and I can fill some E85 up.

Also, while I was typing it, prj replied too - to the best of my knowledge the ECU in my car does absolute zero with the fuel / ignition system until I turn the ignition. But since the ECU is from the same family, I will have to double check that as I actually had no idea cars do that. And as I just said above, the EEPROM storage is just to get the initial value. Whatever happens during fill up, the mix will get a while to settle in, and I need the previously stored value for about 2 seconds. A previously stored value is a much better guess than a random / default one of, say 5%.

EDIT: I have actually once found a video on youtube that shows how slow the sensor reacts to fuel change in the tank. Cannot find that particular one, but here is another: https://youtu.be/JUdN4w1ByEU

EDIT2: Found more videos of this sort, rough estimation is 5-10 seconds before the new composition hits the fuel rail. That should really not be a problem.
« Last Edit: May 13, 2018, 12:50:18 PM by woj » Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #203 on: May 13, 2018, 02:06:48 PM »

Dwelled a bit on prj comment about fuel tank level. Found the variable that stores it, I could possibly make the wait time on the fuel pump dependent on fuel up. Fueled up - short wait time - the car most likely was just running (when you fuel up you typically just drove to the station) and there should be fuel in the line, so no need to wait that long for a correct reading. Not fueled up - wait longer, but instead rely on previously stored E-content in EEPROM. There is just one problem - the fuel level information is received through CAN, and I do not know when, not sure I'd have it available when I needed it - essentially right away after boot. Will have to devise a way to test it, cannot do that on the bench.
Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #204 on: May 13, 2018, 03:51:11 PM »

Hopefully you can sort something nice that handles the dynamics of your fuel system. 370Z is also returnless and changes slowly, but mine are also DI so further dead volume still. In this scenario I would rather use a consistent gradient limited ethanol content reading that is live in time for engine start, or use the last known good stored in EEPROM and then show a CEL after programmable delay.
Logged
amd is the best
Sr. Member
****

Karma: +11/-5
Offline Offline

Posts: 268



« Reply #205 on: May 14, 2018, 06:21:10 AM »

This is excellent man. Nice work. Something I've wished for for ME7.5 for a long time. Keep it up!
Logged

2012 Golf TDI
2001 Audi A4 2.8 30v Supercharged
1991 Audi 200 20v
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #206 on: May 14, 2018, 09:36:29 AM »

I am trying Wink I wish I had more resources for this, it would have been all sorted out ages ago. My added difficulty (so it happens I do all my car projects this way) is that the car has to stay on the road at all times (no spare), hence all is done in small verifiable episodes.

Right, so WBO is wired in (strong word for just pulling the cable through the firewall and sticking it into a prepped Zeitronix Smiley), I am actually surprised with two things. That the post-cat readings seem to be accurate (I expected some skew due to the cat). And how well these ECUs keep the stoich AFR, so much that I suspected there's no reading, only a default value. My earlier experience was with a single lambda batch injection system, nice upgrade here Smiley. Only downside is that there is visible delay in AFR readings (could be a slow sensor too? this one has done upside of 60kkm). I also implemented the fuel level checking from key-on to key-on and according E85 readout treatment on start up, further analysis of the code showed I should have a ready fuel level value when my procedure kicks in (there are other procedures that already rely on it before mine gets executed). Will know if/how well this works when E85 gets in.

So, the car is fully E85 prepped, but still some tank emptying to be done. Drove it a bit today looking at the gauges to make sure nothing is amiss. Yet, I will do some more idle driving before E85, just to give my brain some days to dig out things I could have totally messed up before I find out about them the hard way.
 
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #207 on: May 16, 2018, 04:20:23 AM »

First fill up of E85 done, 11 litres into the 45 litre tank. I cannot remember last time I was so anxious Wink In the end that resulted in 22-24% ethanol content. All looks good so far. First, my fill up detection seems to work. I made an ECU internal log of first 10 seconds of E-content readouts and got them out through CAN later, so 100 samples altogether from boot (they are suspended when the fuel pump is not running and 1 second after it starts):

4.0, 4.1, 4.7, 4.7, 4.7, 4.7, 4.7, 5.0, 5.1, 5.0, 5.0, 5.0, 5.0, 5.0, 5.0, 5.0, 4.8, 4.9, 4.8, 4.8, 4.8, 4.8, 4.8, 4.8, 5.0, 5.1, 5.1, 5.1, 5.1, 5.1, 5.0, 5.0, 5.0, 5.0, 4.9, 4.9, 4.9, 4.9, 5.4, 5.3, 5.3, 5.1, 5.1, 5.4, 5.8, 5.7, 5.8, 5.9, 6.1, 6.7, 6.8, 7.2, 7.7, 8.2, 8.8, 8.9, 9.4, 9.6, 10.0, 10.5, 10.8, 11.1, 11.4, 11.8, 12.0, 12.3, 12.7, 12.8, 13.3, 13.5, 13.7, 14.0, 14.3, 14.5, 14.8, 15.1, 15.3, 15.5, 15.8, 16.0, 16.2, 16.5, 16.7, 16.8, 17.0, 17.1, 17.2, 17.4, 17.5, 17.6, 17.6, 17.7, 17.8, 17.8, 17.9, 17.8, 17.8, 17.9, 18.0, 17.9

The first 4.0 is the previous value from EEPROM, the next one the first reading after 1s of fuel pump priming and around next 10 are also from the priming phase. Then I was setting up my stuff with the ignition on, when I started the engine there was another 1s wait to get the readouts and then they continued. So, to cut the story short, I had about almost ~2(prime)+4(start) seconds of the new mix not hitting the rail, then it started, aggressively. At this stage I declare my method working, but obviously more verification is needed.

Short term trims and long term multiplicative trim look acceptable also. The latter got from 1.001 to 1.002 (momentarily to 1.003) only after several minutes of running / driving. (Stupidly, I do not log additive short fuel trims, I will rectify this tonight, they are the whole point as the drive was rather light). The only thing is the relatively large STFT drop down to 0.9 or below. Both spots happen when the car was idling at traffic lights. Since I never made a log like this with regular fuel (should have done that), I am not sure if it is normal (it is also relatively hot around here, ~26*C). Higher load (short spell only for the first test) AFR seems good too.

Complete log from the first drive and magnified lines of interest attached Wink

To be continued...
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #208 on: May 16, 2018, 04:55:15 AM »

Actually, found an older log with regular fuel, it is not that much different when it comes to stfts, yet a tiny bit less. I have to see what is going on with additive ltfts.
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #209 on: May 16, 2018, 10:12:29 AM »

Either I am logging the wrong variable for additive ltft (rka_w), which is unlikely (but possible), or everything is spot on. Additive correction is absolutely minimal, 0/-1 once -2 in unconverted values, the multiplicative one stays in 0.999-1.002. All that after adaptation reset (due to another flash). The overall stft variates ~0.95-1.05 in most cases, in places ~0.9-1.1. I guess it simply is this way. I'll spare you the log, it is 19 minutes and 3.2MB in size, but a picture overview shot of the stft correction instead.
Logged
Pages: 1 ... 12 13 [14] 15 16 ... 26
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.03 seconds with 17 queries. (Pretty URLs adds 0s, 0q)