Any general discussion around the firmware, what is does, how it does it etc.
#57936
i was just wondering on the filter algorithm or procedures for taking MAP measurements during the 720 deg of a single cylinder ITB based engine

basically there are only about 180 deg of intake time during one completed 4 stroke cycle and during 540 deg of the whole 720 deg cycle nothing really happens in the intake portion of the engine. maybe some resonance at high air velocities.

i would think it would be advantageous to just take some defined count of measurement points (i.e. 8 as a guess) during those 180 degs of intake time and average the result to get a more reliable MAP. caution needs to be taken to sync those measurements to the crank position teeth, as well as the sampling of those readings would need to be spaced apart to match the actual RPM

i realize that those MAP readings would only work for low power to mid power values and not full throttle, but at full throttle the overall air pressure and temp in accordance with a fill factor at high RPM should lead to acceptable inject time values. those reading might not be as precise as wanted but they would represent a stable value for the VE table correction values

my question now would be : how does the speeduino deal with the above mentioned issues for cylinder ITB based engines and partial MAP injection (speed density) control, as compared to to 100 % alpha N control. a reasonable powerful CPU should easily be able to process the above mentioned data volume

i hope my question makes sense and i appreciate an answer explaining my mentioned scenario

cheers Klaus
#57940
Reasonable assumptions, and I recall somebody did that a few years ago with an accessory board. Another did stand-alone sampling for delta peak detection instead of averaging. It was a by-product of using MAP as a cycle signal, but showed promise.

The issue with a 2560 with current code is the sampling is too slow for stuff like MAP, TPS, etc, and a rewrite would probably be a big effort. Teensy types are not easily available, but an STM could likely do it. I would test the idea with a separate board (even a slow one should do) to prove it out easily, without messing with all the current code. If it proves, then you know it's worth hacking it up to add it in. Just thinking out loud. :lol:
#57963
hi digmorepaka :

could you please describe the current map sensor measurement and filtering options a bit more in detail

MAP is sampled per loop -> done in the main loop, cycle time would be cpu load dependent unless qualified with a timer event, but still handled in main loop ???

"cycle minimum" option ???

bit of a bandaid compared to proper sample-at-given-angle but there really aren't many other things that would cause the vacuum to dip lower than the intake stroke -> vacuum to dip lower than the intake stroke : does this mean that you sample at the intake stroke time (hopefully the middle) which would imply to me that it's being sampled at a defined angle ???

please i would really appreciate more details ... this is my main concern about my ITB application for several projects of mine and friends

also are there differences in code execution and measurent strategy between 8 bit atmega and 32 bit cortex implementation

since i did bare metal firmware development for the past 30 years starting with 68k asm in 1985 on a mac development setup up to C++ with embedded C++ eclipse for nrf52 BLE applications i would appreciate maybe a few hints where to find map related code in all those 50 plus source files

i don't like the megasquirt and was initially enthused about the C++ supported speeduino (especially the cortex option), but i need to get more overall info to find if it would fit my narrow use needs, i could try to avoid writing one from scratch using some of my code and written libs, especially using a cpu with new peripherals, I mostly used NXP LPC cpus and nrf52 which are somehow timer and event limited, besides the high prio BT interrupt if u use BLE with their hex file BLE stack
#57971
efiNick wrote: Fri Jul 29, 2022 8:00 pm MAP is sampled per loop -> done in the main loop, cycle time would be cpu load dependent unless qualified with a timer event, but still handled in main loop ???i would appreciate maybe a few hints where to find map related code in all those 50 plus source files
Here is where sensor sampling starts. MAP is sampled per loop, rest of the sensors are sampled at a set frequency - yes MAP sample depends on CPU speed, but even on atmega it's plenty fast.
https://github.com/noisymime/speeduino/ ... o.ino#L241

efiNick wrote: Fri Jul 29, 2022 8:00 pm "cycle minimum" option ???

does this mean that you sample at the intake stroke time (hopefully the middle) which would imply to me that it's being sampled at a defined angle ???
It's exactly what it does not do and why it's a bandaid with the result being pretty much the same. You get samples per loop. say hypothetically there was 10 loops per cycle(there's a LOT more than that) and you got a data set of "70, 70, 60, 50, 45, 60, 70, 70, 70, 70". Out of that dataset cycle average would give you 63, which is wrong for a 1cyl ITB, cycle minimum would give you 45 because that's the lowest value recorded, this value also normally occurs during the intake stroke and therefore is correct.
#57975
Verify real-world in your calculations. I just reviewed another typical log where loops were under 900Hz. That indicates a maximum of 9 reads per cycle, or every 80°, at only 3000 rpm. I would expect some jitter, though I'm assuming worst-case, such as large ITB, not plenum buffering. That means it could miss the intake pulse peak reading entirely in some cases. This is one reason stand-alone was used in other testing in order to unload the uC for much higher LPS.
#57984
efiNick wrote: Fri Jul 29, 2022 8:00 pm i don't like the megasquirt and was initially enthused about the C++ supported speeduino (especially the cortex option), but i need to get more overall info to find if it would fit my narrow use needs
You will find that Arduino code is not really C++, its a beginners language designed to hide some of the perceived complexity of C, it is mostly non-OO but uses a couple of objects, like serial and eeprom and relies on overloading to simplify the API.
The Arduino IDE is much like programming in the late 80s/early 90s but without the ability to hook up a logic analyzer to the bus to allow debugging although the IDE does produce a cpp file which, theoretically, could be compiled and run in Atmel Studio which would give you a proper IDE with debug capabilities. You would have to shuffle some pins around because the JTAG connector is shared with some of the analogue input pins.

It looks like you have a fuel supply issue. readin[…]

Will this have an updated version about this featu[…]

Vr Conditioner Noise when cranking

I did the fix, but it's not work. I put my setti[…]

Perhaps some different points and pictures. Instr[…]

Still can't find what you're looking for?