gemellocattivo.com

Which means "Evil Twin". Lets see your projects where you change boring into fun or create the fun from scratch.
It is currently Tue Sep 29, 2020 10:32 pm

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: MAP Sensing
PostPosted: Mon Oct 26, 2015 7:17 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
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.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
PostPosted: Mon Oct 26, 2015 8:17 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 3117
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 :)


Top
 Profile Send private message  
 
PostPosted: Mon Oct 26, 2015 11:30 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
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.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
PostPosted: Tue Oct 27, 2015 6:07 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 3117
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


Top
 Profile Send private message  
 
 Post subject: Re: MAP Sensing
PostPosted: Tue Oct 27, 2015 12:12 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
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.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: MAP Sensing
PostPosted: Tue Oct 27, 2015 3:42 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 3117
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 12808 times ]
NBO2 filtering w_filtering.JPG
NBO2 filtering w_filtering.JPG [ 66.69 KiB | Viewed 12808 times ]
Top
 Profile Send private message  
 
 Post subject: Re: MAP Sensing
PostPosted: Tue Oct 27, 2015 7:42 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
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.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: MAP Sensing
PostPosted: Tue Oct 27, 2015 8:35 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 3117
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.


Top
 Profile Send private message  
 
 Post subject: Re: MAP Sensing
PostPosted: Tue Oct 27, 2015 10:16 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
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.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: MAP Sensing
PostPosted: Wed Oct 28, 2015 8:35 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 3117
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.


Top
 Profile Send private message  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group