Spudmn's Puma board build

[Fred]

Don't panic just yet!

ADC readings are currently being taken at all 7 of your teeth positions. Which is wrong. Your hot cam just makes the wrongness obvious. Simis and Preston and em_knaps are all suffering from the same issues, it's just not wild for them. You will probably find that the values actually used to schedule will be consistent and useful due to the order of operations. The correct solution is to add settings for where to read ADCs and where not to.

Feel free to hard code/hack that in for yourself in the short term. Just wrap the sampling code with an "If currentEvent == 0 or 4, then sample, else don't" and it should clean up a LOT. Try that first :-)

Adding alpha-N support won't be too difficult. You can also be the first to try out hybrid tuning if you want, though I need to modify MTX to make that possible.

in any case, a TPS is a great thing to log at the very least :-)

Fred.

[Spudmn]

Cool.

I will get some VAC hose this afternoon. I will be able to hack the code to suit.

[Fred]

You might want to try other pairs too, you have 3 possible pairs to sample on:

0,4
1,5
2,6

3,7 is obviously not possible ;-)

You might get more acceptable results with one pair than the others.

You can do the test before you do the hack by doing a classic bin log at idle (please share the file with me bzip2ed) and look at the values vs the position of currentEvent. There should be a pattern to it. Choose which ever pair has the lowest vac and/or most even readings.

Fred.

[Fred]

Remember you said that you saw the firmware lock up? I have a situation on my bench rig where the benchTest firmware locks up, or at least, stops sending comms. Can you tell me what *exactly* the symptoms were that made you say "it locked up" please? I'm curious as to what you saw/noticed, it might provide a clue. I'll be doing some tests later today to try to track this down. It could be the same thing.

[Spudmn]

I had the debug pin connected to the LA and was cranking the RPM input with my test bench hard drive thing.

The LA showed that the RPM interrupts where taking a lot longer than normal.

I was blaming the LA at the time so I didn't get a log. I was not checking the coms at the time so I don't know if that was working or not.

Sorry not much help I know.

[Fred]

Any idea what the RPM was? No big deal. I tracked this down to trying to push the bench test hack to 50k rpm with 12 minus 1 :-) It didn't like that much LOL. 12 minus one read clean until 13500 so your 8-1 should be clean to close to 20k or so before it gets overly busy.

What are you calling "a lot longer than normal" anyway? The numbers that you emailed me were shorter than reality in the first place. Only the simple execution paths scored that well. The number needed to be set for the worst case which is just after and/or just before the gap. Theoretically they can't take longer than they take because they can't be interrupted, only external main loop code can increase in execution time with ISR load.

Fred.

[Spudmn]

Any idea what the RPM was?

about 1000 RPM. May be slower as my battery drill was getting flat.

so your 8-1 should be clean to close to 20k or so before it gets overly busy.

I think that I might be getting valve bounce at that speed.

What are you calling "a lot longer than normal" anyway?

I didn't measure them and I can't remember but I guess that they were about the width of 6 ms

Sorry not much help. The code still had bugs when I saw this.

Theoretically they can't take longer than they take because they can't be interrupted, only external main loop code can increase in execution time with ISR load.

I know. Thats why I blamed the LA.

[Spudmn]

You can do the test before you do the hack by doing a classic bin log at idle (please share the file with me bzip2ed)
Fred.

Log as requested.

MAP_Test.bin.bz2

Map sensor of Mini with hot cam

(30.68 KiB) Downloaded 589 times

Please note that the MAP is connected to one side on the manifold. cylinders 3 and 4.

This creates a interesting pattern with a MAP pulse every second 360 cycle.

I should be able to hack some thing together to get around this.

[Fred]

OK, I've had a look, that's a cool log, 50-100kpa variation! Look at the value for tooth 6, though. If you create a little balance tube setup between the runners and feed the map from that (as you probably should have from the start) then you'll find it more consistent, but still with variation. Do that next, and then do another log and post it, hopefully you find that 2,6 is a winner, add the hack and roll with it like that for the time being :-)

[Fred]

Hmmmm, how about two map sensors, one for each runner pair, and read one on one cycle/tooth and another on the other? You could be the first running two maps! :-)