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

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

Author:  apalrd [ Wed Oct 28, 2015 11:07 am ]
Post subject:  Re: MAP Sensing

We're using the 565 (which was the top of the line in its generation, 4 gen old) for a 2 cylinder engine, but I did run out of 36k internal RAM. Woodward sells modules with the an optional 512k external SRAM and 64k parallel EEPROM which solved that problem. I'm happy with the PowerPC but pretty unhappy with the TPU3, it's quite limiting in what it can do with complex pulses. An eTPU would solve that.

Table lookups still represent a pretty big chunk of processor time, even with model-based systems. The tables are different but there are still a lot of them.

eTPU latency is usually very small, a few uS at worst (it's dependent on the exact configuration and microcode but I believe 7 uS worst-case latency was measured on a project). How many of the calcs are done separately per cylinder in O5E? Calculating everything per cylinder instead of per engine or bank makes a HUGE difference in CPU loading, and that's where quite a bit of the OEM loading comes from. OBD diagnostics are also huge, but are run slower so their CPU usage hit is lower but memory usage can be quite high, especially for complicated diagnostics.


But you're right, any of the 5000 series powertrain processors should be sufficient for this. I do think MS has reached the capability limit of their micro and should consider something modern.

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

The timed sampling's a little better...not quite done but almost.

Attachments:
NBO2 filtering2.JPG
NBO2 filtering2.JPG [ 79.71 KiB | Viewed 12228 times ]

Author:  mk e [ Wed Oct 28, 2015 9:06 pm ]
Post subject:  Re: MAP Sensing

apalrd wrote:

How many of the calcs are done separately per cylinder in O5E? Calculating everything per cylinder instead of per engine or bank makes a HUGE difference in CPU loading, and that's where quite a bit of the OEM loading comes from. OBD diagnostics are also huge, but are run slower so their CPU usage hit is lower but memory usage can be quite high, especially for complicated diagnostics. .


That's my point exactly. For most all projects cylinder and bank calculation are mostly not needed nor is real ODBII. It's best to look at the big picture and only look at details with what's left.

On o5e I was ALMOST to cylinder trims but that was (maybe is) to be the full extent of the cylinder math. Nothing more SHOULD be needed.

Author:  apalrd [ Thu Oct 29, 2015 10:22 am ]
Post subject:  Re: MAP Sensing

For my I2, my individual cylinder controls have a single trim surface for airflow, and the rest of the code operates on vectors for each cylinder. So even with only one per-cylinder trim, a lot of the math is done multiple times at the different points.

Author:  mk e [ Thu Oct 29, 2015 12:54 pm ]
Post subject:  Re: MAP Sensing

apalrd wrote:
For my I2, my individual cylinder controls have a single trim surface for airflow, and the rest of the code operates on vectors for each cylinder. So even with only one per-cylinder trim, a lot of the math is done multiple times at the different points.


Fair enough, but a LOT of stuff can be done pretty slow....for example coolant temp corrections you could go in 1 minute step and be plenty fast, or how far will a throttle pedal move in under a 1/10th of a second which is an eternity in processor cycles. Cylinder trims are just that, trims that should be caused by stuff that applied everywhere (air flow, injector flow, etc) so again 0.1 sec for the lookup is probably more than plenty fast and applying a simple trim is ...10 or 12 clock ticks per cylinder? not much.

My point is that while its easy to get wrapped around the "wouldn't it be better" axle, a lot of efficiency can be had by thinking in terms of you you need vs what you might like. Race engines that are tuned for the parts they actually have can tolerate a lot more part to part variation and error from the control system than OEMs who need every combination of components to work within specification not just 1 specific set of components to work well....different worlds, different requirements, different systems needs.

Author:  mk e [ Thu Dec 05, 2019 8:24 pm ]
Post subject:  Re: MAP Sensing

Not sure why there aren't multiMAP pics on this thread

Attachments:
1547835560_2010-05-29-001_mmthumb.jpeg
1547835560_2010-05-29-001_mmthumb.jpeg [ 29 KiB | Viewed 8321 times ]
1547835575_2010-05-29-002_mmthumb.jpeg
1547835575_2010-05-29-002_mmthumb.jpeg [ 29.67 KiB | Viewed 8321 times ]

Author:  TheDarkSideOfWill [ Mon Dec 09, 2019 10:29 am ]
Post subject:  Re: MAP Sensing

Where's #12?

Author:  mk e [ Mon Dec 09, 2019 11:33 am ]
Post subject:  Re: MAP Sensing

TheDarkSideOfWill wrote:
Where's #12?


When I snapped that pic #12 was soldered to board one that failed testing...it was missing some traces. This is board 2 with everything right waiting for a replacement #12. There is a space for a baro sensor too if one were inclined to add a 13th sensor instead of the the 5V doubling bits....so 12V supply needed with the 13th sensor.

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