rusefi.com

Is it possible to put the frequency function to MAF also ? I'm guessing it's not implemented yet ...

http://www.ls1howto.com/index.php?article=25

Number-One have you thought about using Maf instead of Map ? Map is generally much harder getting to work on two-stroke engines. Just a question, no flaming

bjorkmanders wrote:Is it possible to put the frequency function to MAF also ? I'm guessing it's not implemented yet ...
http://www.ls1howto.com/index.php?article=25

https://sourceforge.net/p/rusefi/tickets/203/
I see two issues with that: frequencies are much higher, this would really need to be converted to voltage somehow, I'd rather not capture digital signal of that frequency programmatically. Also looks like I cannot get a unit to play with for $20 as with the Ford MAP.

russian wrote:

bjorkmanders wrote:Is it possible to put the frequency function to MAF also ? I'm guessing it's not implemented yet ...
http://www.ls1howto.com/index.php?article=25

https://sourceforge.net/p/rusefi/tickets/203/
I see two issues with that: frequencies are much higher, this would really need to be converted to voltage somehow, I'd rather not capture digital signal of that frequency programmatically. Also looks like I cannot get a unit to play with for $20 as with the Ford MAP.

They succeeded implementing frequency maf sensor in ms3, so should be possible ? Also if you are interested in implementing it I could send a sensor to you . Sorry for hijacking the thread :O

/Anders

bjorkmanders wrote: They succeeded implementing frequency maf sensor in ms3, so should be possible ?

60/2 trigger wheel produces ~7000Hz at 7000 rpm and this is handled digitally and the handler is much more complicated, so 13000Hz with a much simpler handler should totally be possible - it's just that if it could be converted to analog then it would be much easier on CPU.

bjorkmanders wrote: Also if you are interested in implementing it I could send a sensor to you.

I would love to grab one from you! Now promises on when I would implement it, but it should be easy, so it should be soon. I would love to expand device support spectrum.

Thought the whole idea behind freq-maf is getting the signal digital instead of analog, and therefore less prone to get missreading ? I went that route because problems occurred with the analogue maf.

Is it possible to make interrupt every say 10 event instead ? To get the less load on the CPU, think the signal would be accurate enough.

Will look for a maf and send it to you

/Anders

bjorkmanders wrote:Thought the whole idea behind freq-maf is getting the signal digital instead of analog, and therefore less prone to get missreading?

I am not sure if frequency output would count as a digital signal. A digital signal would be if it would have been a sequence of bites over some protocol like CAN or SPI which seems to not be the case.

It appears the frequency decoder will need to decode between 10Hz and 15kHz to cover a variety of sensors. If we make it accurately capture the 15kHz signal, it should be accurate for the lower frequency signals. Per Nyquist this means we need to capture at least 2X the 15kHz, so the decoder will need to decode at least a 30kHz signal, while at the same time it needs to count up to .1 second. A timer set for a tick every 33.3uS would tick 3003 times in 10Hz signal and would tick 2 times for a 15kHz signal. So that would be a 12bit timer. I'm not sure we have a 12bit hardware available. So this may not play nice with the approach of a timer connected to an IRQ.

Posted in this thread http://rusefi.com/forum/viewtopic.php?f=3&t=396&start=80 is this ford sensor with the below specs.

I guess this brings us to a more philosophic discussion, the matter of balance between simplicity and flexibility (or, may be better to say ubiquity?).
How many sensors with this frequency output are there in the market? (of any kinds - MAF, MAP, O2, CLT, IAT?)
Besides, the newer boards have prototyping area - why not use this area for adding separate chips to convert frequency back to voltage?

kb1gtt wrote:It appears the frequency decoder will need to decode between 10Hz and 15kHz to cover a variety of sensors. If we make it accurately capture the 15kHz signal, it should be accurate for the lower frequency signals. Per Nyquist this means we need to capture at least 2X the 15kHz, so the decoder will need to decode at least a 30kHz signal, while at the same time it needs to count up to .1 second. A timer set for a tick every 33.3uS would tick 3003 times in 10Hz signal and would tick 2 times for a 15kHz signal. So that would be a 12bit timer. I'm not sure we have a 12bit hardware available. So this may not play nice with the approach of a timer connected to an IRQ.
Posted in this thread http://rusefi.com/forum/viewtopic.php?f=3&t=396&start=80 is this ford sensor with the below specs.

map_sensor_ford.gif

I guess this is not so difficult to implement using the "PWM input mode" of timers 2-5 in the STM32F4xx? That would lower the number of interrupts to the CPU massively.

In ms3 you used only one sample per revolution. The one that gave the highest flow-value. It was a crank-degree-window where the samples where taken from. Say between 200-270 degrees. It worked really well.

I solved a similar timing sample problem with a arduino, that where suppose to take a high frequency and convert it to a rpm. Now the frequency was to high for the timers and cpu clock to handle. What I did was to give a interrupt every 10th event. That gave me plenty of time and accuracy to calculate the rpm. is it perhaps possible to solve it this way ?

Seems like there where quite many who used frequency maf when I desided to go that route.

/Anders

Once upon a time I knew the fellow that developed that windowed map approach and encouraged MS folks to do approach. He didn't get positive feedback, however it's good to see they used the idea. I agree it's a reasonably good approach.

I think we can get both flexibility and simplicity. I'm reasonably ignorant about the software low level details, but for these low frequency signals, I suspect we can include it in a software timer. I believe we have some lower priority tick tasks that can include a decoder. However I'm ignorant and it's easy for me to say, "it's just a software problem"

It is simple to measure (accurately) freq. with STM hw,
but trying to measure freq. in sw with multitasking environment is not a good idea.

This Ford sensor looks linear-enough to me, the implementation for low-frequency MAP sensors is ready:

Thank you, feedback tomorow.