Thought I'd update this as I've got a little further with the project. Maybe my findings will help others.
Unfortunatly I've not sorted out any MAP sensors yet so can't currently monitor multiple channels but thought it best to do a bit of fact finding to see how plausible this may be. I realised i have a single MAP sensor available as I recently bought a 'spare' airbox for my bike and that just happened to come with a sensor attached to it so I've just been using that.
The first thing I thought I'd do was create a program for measuring and viewing the MAP signal. I was a little concerned by a couple of things posted earlier:
stevieturbo wrote: ↑Mon Jun 13, 2022 6:15 pm
If you're trying to use them in single runners on the engine side of the blade, they will pulse like mad and need to be heavily damped to get any sort of usable reading from them
&
DaveEFI wrote: ↑Tue Jun 14, 2022 2:12 pm
Do know that MS uses a different algorithm for throttle bodies rather than a plenum. Presumably because of the less than smooth MAP signal?
Which having seen the way my measuring gauges jump around (even though they have a small orifice in the line which should damp the signal) I tended to agree with, however this is the result I got:
It's not un-smooth at all, in fact it shows a very regular output.
I actually built in a rough and ready smoothing capability into my system but in this image it is turned off. This is why there are 2 traces, the blue one is the filtered data, the red on raw data. I've offset them here so both can be seen, infact they should overlap each other without this while there is no filtering active.
There is nothing fancy going on here. The system is simply taking readings from the MAP sensor and outputting the values, so it seems the only reason for thinking the signal would be 'rough' is that a physical gauge and the human eye can't react quick enough. Bear in mind the time period for this waveform (distance between each peak or trough) at 1500RPM is around 80 milli-seconds.
Having seen this I decided to time-stamp the signals, work out the difference between the minimum readings, calculate the time period between them and massage this into RPM, this actually works really well.
This show the RPM signal included in the trace which is hovering around 1500, exactly as per the bike's instrument.
That's pretty much it for now. I did do one other thing althogh it may not be needed in reality.
I'm only really interested in the signal when the inlet tract is active, that is the inlet valve is open and air moving through the inlet tract, this is the 'trough' area on the trace so I've added the capability to clip the higher pressures as here:
I did this as I was concerned there may be some pressure reversals in this area, which is what I'm looking for, possibly skewing my readings, doesn't look like it will be necessary but it's there if I need it, other engines may have different characteristics.
What's next?
I know it seems like I'm a long way from a working system but I feel like the hard work is done in terms of working out the unknowns. I've seen that I can read and analyse a signal from a single inlet tract, there will be no new work to monitor the other one (or others when I move on to more than 2 cylinders) I'm already detecting the lowest value (peak vacuum if you like) so all I need to do is compare the inputs and work out the difference.
Obviously I'll need to add a display for the user (I'm not expecting to run this hooked up to a laptop in practice) but I've already done that on other projects. I then need to package it so that It can sit on the bike while running. I also intend to add an SD card data logger as I don't think it's a great idea to have the rider (me) watching this while riding.
I'd also like to tap into the bikes throttle position sensor but I'm not sure how sharing sensor outputs between systems can work in practice, it may simply be a case of making the two systems share a common ground but I don't know. Bit more research needed there.
If anyone has any other ideas I'd be interested to hear.