gemellocattivo.com
http://gemellocattivo.com/forum/

MAP Sensing
http://gemellocattivo.com/forum/viewtopic.php?f=19&t=167
Page 1 of 2

Author:  apalrd [ Mon Oct 26, 2015 7:17 pm ]
Post subject:  MAP Sensing

Innovate's WB controllers operate very differently from everyone else.

Most use either a DAC to drive the pump (and measure the current) or some other constant-current type driver. Including the CJ125/135/136 family and ST L9780 (the only wideband chips I know of). They have some sort of software or ASIC feedback loop on pump current which is something like PID based (it varies a bit, but it's a feedback loop which targets a Nernst voltage). The chip either allows you to read the pump current and Nernst voltage directly (with an ADC) or over SPI. Then the micro can calculate lambda.

Innovate uses what they call 'direct digital' control. Basically they have two comparators set on either end of the stoich portion of the Nernst cell. They then have essentially a bang-bang hystersis controller which flips between a positive and negative constant-current source. So the pump is turned full-on positive, when it reaches just a little past rich (or lean, I don't remember the polarity) it switches to full-on negative, goes just a little past stoich the other way, and this continues indefinitely. What they actually measure is the duty cycle of these oscillations. In a stoich environment the pump will have a duty cycle of 50%, it will go up or down when rich or lean. I believe they are the only company to do anything like this. That doesn't make their method good, it's just different.


I know the V8 engines (which have pulses hitting the O2 sensor very unequally due to the uneven firing order within the bank as well as the unequal runner length of a log manifold) don't usually do individual cylinder fueling above about 2600 rpm. They learn the errors at idle and cruising and assume they apply upwards. With fewer cylinders and totally even pulses you can probably push the RPM quite a bit higher.

Above 1khz you might be hitting the response limit of the NB sensor. If you're sampling on the ECU you could sample it angularly. I'm not sure if EngineLab can do that. For O5E you could setup one of the last 4 eTPU channels as a knock window which can trigger eQADC to advance in it's sample queue, if you do it right you end up with an ISR at each sample event with new data and perfectly synchronized sampling.

Author:  mk e [ Mon Oct 26, 2015 8:17 pm ]
Post subject:  Re: FrankenFerrari - V12 ferrari 308 part 3

apalrd wrote:
Most use either a DAC to drive the pump (and measure the current) or some other constant-current type driver. Including the CJ125/135/136 family and ST L9780 (the only wideband chips I know of).


Enginelab has a cj125.....if I can figure out how to make it work. I'm going to start with the innovate because I know it works

apalrd wrote:

I know the V8 engines (which have pulses hitting the O2 sensor very unequally due to the uneven firing order within the bank as well as the unequal runner length of a log manifold) don't usually do individual cylinder fueling above about 2600 rpm. They learn the errors at idle and cruising and assume they apply upwards. With fewer cylinders and totally even pulses you can probably push the RPM quite a bit higher.


Math says with 3 evenly spaced cylinders 10k should work. My plan is do any required cylinder trim at or near stoich and assume it holds as it gets richer and I lose the NB accuracy. Mostly I want to know there are differences because that means I did something wrong.....everything SHOULD be matched other than low throttle where I can adjust the TBs so we're back to everything should be matched.

apalrd wrote:
Above 1khz you might be hitting the response limit of the NB sensor. If you're sampling on the ECU you could sample it angularly. I'm not sure if EngineLab can do that. For O5E you could setup one of the last 4 eTPU channels as a knock window which can trigger eQADC to advance in it's sample queue, if you do it right you end up with an ISR at each sample event with new data and perfectly synchronized sampling.


Enginelab does not have an angular sensing function and in o5e we don't have knock window working right. Jon had it working but all timed channels went off-line when angle was on.....something to fix:(

I can just sample and then filter to an angle window, that would work for now though I have one in each pipe so none of this matters I guess :)

Author:  apalrd [ Mon Oct 26, 2015 11:30 pm ]
Post subject:  Re: FrankenFerrari - V12 ferrari 308 part 3

mk e wrote:
Enginelab does not have an angular sensing function and in o5e we don't have knock window working right. Jon had it working but all timed channels went off-line when angle was on.....something to fix:(

I can just sample and then filter to an angle window, that would work for now though I have one in each pipe so none of this matters I guess :)


The lack of angular sensing and control is the reason I ended up not switching to EngineLab (I talked to their head last week at a trade show, for almost an hour). Even if the processor is fast enough to sample many times at moderate RPM, it seems to work best for really odd firing engines (like my 1-cyl) when I sample at specific crank angles. Even <shudder> Megasquirt can sample MAP angularly.

I might have to look at the knock window function. I have a 5634M board, but it's too difficult to work from my Mac. I'll have to get that to work first.

Knock Window function is useful for a lot more than just knock windows. It would be good to get those working.

Author:  mk e [ Tue Oct 27, 2015 6:07 am ]
Post subject:  Re: FrankenFerrari - V12 ferrari 308 part 3

apalrd wrote:
mk e wrote:
Enginelab does not have an angular sensing function and in o5e we don't have knock window working right. Jon had it working but all timed channels went off-line when angle was on.....something to fix:(

I can just sample and then filter to an angle window, that would work for now though I have one in each pipe so none of this matters I guess :)


The lack of angular sensing and control is the reason I ended up not switching to EngineLab (I talked to their head last week at a trade show, for almost an hour). Even if the processor is fast enough to sample many times at moderate RPM, it seems to work best for really odd firing engines (like my 1-cyl) when I sample at specific crank angles. Even <shudder> Megasquirt can sample MAP angularly.

I might have to look at the knock window function. I have a 5634M board, but it's too difficult to work from my Mac. I'll have to get that to work first.

Knock Window function is useful for a lot more than just knock windows. It would be good to get those working.



You're right that with less than 3 cylinders there is a benefit to angular readings but most aftermarket ECUs don't do that, at least not that I've seen, MS is the only one yet they all will run a 1 cylinder just fine so I suspect the others are doing some averaging on things like MAP. o5e needs a few things fixed including knock window all the same.

You spoke to Jim? He seems quite helpful.

The best I can tell the program threads run in just a few usec so so angular window readings can be created with an if/else on crank position and average within the window. I''m pretty sure that would work. I'm talking to Jim today about an issue I'm having a few features that I feel enginelab is lacking....prober windowing is on my list

Author:  apalrd [ Tue Oct 27, 2015 12:12 pm ]
Post subject:  Re: MAP Sensing

I'd imagine angular sampling would be useful for any odd-firing engine or any engine with 3 or fewer cylinders per throttle body (e.g. ITB or two TB's on a V6 or crossplane V8). That's why it's such a critical feature for me with the I1 (is it really inline? Maybe it's a V1?) and I2 odd-fire.

Doing all of the math angularly is just a side effect of sampling everything angularly, and there's not a lot of sense in calculating everything many times with the same set of data.

MS has the angle-sampling but unfortunately they can't sync reliably to the I1 with a 12-1 VR sensor. The cranking pulses are so big that most ECU's including MS will incorrectly detect tooth gaps as missing teeth (or miss the missing tooth). We fought with a Pi Innovo module for a bit since one of our students worked there, it was not very happy with the lack of a cam sensor and the erratic crank pulses at starting and idle.

For O5E, I believe the crank channel sends a link to all other channels when the crank changes state and in some cases they will reset and require the host to re-schedule the pulses (but not fully re-initialize the channel). In general, scheduling the pulses once per cycle is a good idea anyway. That could be your issue.

Author:  mk e [ Tue Oct 27, 2015 3:42 pm ]
Post subject:  Re: MAP Sensing

apalrd wrote:
I'd imagine angular sampling would be useful for any odd-firing engine or any engine with 3 or fewer cylinders per throttle body (e.g. ITB or two TB's on a V6 or crossplane V8). That's why it's such a critical feature for me with the I1 (is it really inline? Maybe it's a V1?) and I2 odd-fire.

Doing all of the math angularly is just a side effect of sampling everything angularly, and there's not a lot of sense in calculating everything many times with the same set of data.

MS has the angle-sampling but unfortunately they can't sync reliably to the I1 with a 12-1 VR sensor. The cranking pulses are so big that most ECU's including MS will incorrectly detect tooth gaps as missing teeth (or miss the missing tooth). We fought with a Pi Innovo module for a bit since one of our students worked there, it was not very happy with the lack of a cam sensor and the erratic crank pulses at starting and idle.

For O5E, I believe the crank channel sends a link to all other channels when the crank changes state and in some cases they will reset and require the host to re-schedule the pulses (but not fully re-initialize the channel). In general, scheduling the pulses once per cycle is a good idea anyway. That could be your issue.


I'm not convinced. Way back when o5e started I was on the doing things by cycles band-wagon...but the more time I spent looking at it the less sense it made. The eTPU fuel function can update mid-cycle so why not give it the most current info? Sensors have noise so way not sample at or near the sensor's response frequency and have the best data set you can have?

MAP on 1 cylinder engines is a tricky one for sure though. I did some quick code today that opens a sampling window to read a sensor then does a running average on all data collected in the window. It's needs a little more work before it's ready for prime-time....but I think it works for my O2 signal and would work for a MAP signal, particularly when there's a turbo smoothing things out :)

I spent almost 2 hours on the phone with Jim from enginelab today and one thing we discussed was event based functions. His position is he can add it...but in 7 years no one has asked for it. We talked about my NBO2 idea and he pretty much thought I was nuts but if I could come up with an solid reason why I needed a function he'd be happy to add it which I think is more than fair...but I think the code I'm working on will be enough to do what I'm thinking I want to do. What I will push him on are a few little things to make it easier/cleaner to use over-all

You must have seen the lasted version which is not yet released....I guess they've added a lot so I can't wait to see it.

Below
Red = sensor voltage (no idea what the skipping is about...something in the simulator)
Green = crank angle
Orange = NBO2 reading for cylinder 1

You can see I changed the sensor voltage but the NBO2 reading doesn't change outside the crank angle window I set. in the bottom I turned on some signal smoothing so you see damped transitions. It works.

Attachments:
NBO2 filtering.JPG
NBO2 filtering.JPG [ 68.63 KiB | Viewed 22491 times ]
NBO2 filtering w_filtering.JPG
NBO2 filtering w_filtering.JPG [ 66.69 KiB | Viewed 22491 times ]

Author:  apalrd [ Tue Oct 27, 2015 7:42 pm ]
Post subject:  Re: MAP Sensing

Does the code run as fast on a real ECU as it does on the simulator?



As for by the cycles, to me it makes it easier to calculate everything at the right angle (just before it is 'due'), since I know that a single iteration of the code equals one cylinder's cycle, so things like air models can take a running mass estimate and subtract the current air charge from the manifold mass estimate every time they run (cyclically) without having to convert it to a flow and slowly pull the flow out. In that example, the model then handles things like uneven firing correctly. For transients, the delay between the sensing, calculation, and actuation is fixed so the calibration of prediction things is easier. Little things like that.

It's also important to calculate things as infrequently as possible if the processor is loaded. I worked on a MPC5674F (260mhz dual issue single core) and we had the processor pretty hammered with an advanced I4 engine (which is currently in production), due to the calculations required, and we were only doing them once per cycle per cylinder.

Author:  mk e [ Tue Oct 27, 2015 8:35 pm ]
Post subject:  Re: MAP Sensing

apalrd wrote:
Does the code run as fast on a real ECU as it does on the simulator?


As far as I can tell it does...but I haven't done back to back runs ECU vs sim. At the moment I have everything set to a 128 priority on a 0-255 scale and everything is 1 big thread.....once I have a fairly complete model I'll look at thread run and sleep times and start moving stuff around to get reasonable times on it all. Get it working first them optimize where possible.


apalrd wrote:
As for by the cycles, to me it makes it easier to calculate everything at the right angle (just before it is 'due'), since I know that a single iteration of the code equals one cylinder's cycle, so things like air models can take a running mass estimate and subtract the current air charge from the manifold mass estimate every time they run (cyclically) without having to convert it to a flow and slowly pull the flow out. In that example, the model then handles things like uneven firing correctly. For transients, the delay between the sensing, calculation, and actuation is fixed so the calibration of prediction things is easier. Little things like that.

It's also important to calculate things as infrequently as possible if the processor is loaded. I worked on a MPC5674F (260mhz dual issue single core) and we had the processor pretty hammered with an advanced I4 engine (which is currently in production), due to the calculations required, and we were only doing them once per cycle per cylinder.


I'm at about 1% loaded right now I think.

On a 1 cylinder you have the full cycle time to do you work....on a 12 its another story.

What I do is run a simple cycle clock in the code and try anything that is truly cycle dependent to that. So the x-tau calculates stored fuel by cycle, but the code may come up any number of times within a cylce and skip through because it's not due.

Other stuff I think it best to update when the info is available....like throttle or traction control, you just do it.

There is no right for most of this stuff, at least not that I've found, you just adapt to get the most from the system you're working with. The enginelab system is one of the most powerful I've worked with, but it's not without its quirks and limits. Jim is concerned about trying to load to much into the low-level time critical world when it's really not time critical, I think he's probably over concerned but so far I can live happily within the rules I think, its a lot of bang for the buck compared to other options.

Author:  apalrd [ Tue Oct 27, 2015 10:16 pm ]
Post subject:  Re: MAP Sensing

CPU load is an interesting topic.

Part of the CPU loading concern for OEM type ECU's is that they calibrate using a 'memory emulator'. The latest parallel products are the ETAS XETK and ATI M6/M6V. Some also work on NEXUS alone but with limited functionality.
http://www.etas.com/en/products/xetk_v1.php
https://www.accuratetechnologies.com/ECUInterfaces/M6

Memory emulators originated as a way to emulate a data PROM for calibration purposes. Now, since the micro has on-chip flash, the data ROM is redirected to an external memory bus which connects to the memory emulator. It dual-port RAM which contains multiple copies of data ROM (which you can switch between from the computer), and a data acquisition region to store data samples.

When the ECU is running with a memory emulator attached, const data loads are remapped with the MMU to the external memory bus. The code will run slower when in emulation because all of the tables are in slower external RAM and not cached.

Data acquisition is done using the rest of the dual-port RAM to create lists of memory addresses that the user wants to capture, and the CPU or DMA will copy the data at those addresses into DAQ lists which the memory emulator sends to the laptop for logging. It's incredibly fast and can transfer a huge volume of data.

As a computer engineer I like to get into the fine details of why different algorithms use more/less CPU. Really fine programming can make things slightly more efficient, but it takes more programmer's time.

I think EngineLab likes to use a very powerful CPU to run relatively small models, with the idea that if you run them fast enough it doesn't matter what angles you calculate at. This is fine. When the models get more and more complex, and need to calculate so many cylinders separately, there will be more CPU loading issues and it will be more important to more finely control the execution and code efficiency. I think the O5E 5634M will hit that before EngineLab, but the 5674F is more powerful than EngineLab's processor.

Author:  mk e [ Wed Oct 28, 2015 8:35 am ]
Post subject:  Re: MAP Sensing

apalrd wrote:

I think EngineLab likes to use a very powerful CPU to run relatively small models, with the idea that if you run them fast enough it doesn't matter what angles you calculate at. This is fine. When the models get more and more complex, and need to calculate so many cylinders separately, there will be more CPU loading issues and it will be more important to more finely control the execution and code efficiency. I think the O5E 5634M will hit that before EngineLab, but the 5674F is more powerful than EngineLab's processor.


That is absolutely what they do. They have no control of what the model the user creates looks like but they have given you the tools to optimize run time with 256 priority levels and 8 threads. They're main goal it to provide a system that a mechanical or systems person and setup so they know they are giving up efficiency...so they add processing power....it's probably 2 full orders of magnitude more than MS uses.

OEMs have gotten very sophisticated in the name of emissions and this is what we've been talking about with model based work replacing MUCH less processor intensive table based systems....but that's not where race engines are. Didn't you tell me you're currently using a 5? gen old processor in your ECU quite happily? o5e is using the 5634 which is designed as a low end emerging market 4cyl ECU.......but I've benched it with 12 fuel, 12 spark, 4 wheel speeds and a couple other outputs consuming every eTPU output and couldn't find any hint of a latency issue. Motec just released the M1xx stuff with a 5566 (I think) which is now 3 gen old and MS3 worth with a 6? gen old processor....although I would argue it's WAY over loaded at this point.

I guess its easy to get caught up in wanting the latest and greatest.....but looking carefully at what you actually need is probably a better way to look at this stuff and for race or team type applications ease of use is normally the most important item vs OEMs were compliance is #q followed closely by and cost.

Page 1 of 2 All times are UTC - 5 hours [ DST ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/