[rusEfi] 1994 USDM Mazda Miata #11

[puff]

i've read, it's almost never 'too rich' during cold startup (3-5 times longer impulses is quite common)
if the startup is warm, russian said, there was a 1 second delay before discovery starts actual pulses…

[spags]

Still getting my bearings but if you look at the AFR's in here along with the temps. Maybe it's the 1 second wait until things start pulsing Maybe it's not rich enough?

I need to get another log of it cranking without me throttling it to get it to start so the hard start behavior can be seen more clearly.

Another miata owning member (tomiata) requested the maps, these are very much a work in progress. I got a 14.5 steady AFR during the day, it runs slightly lean at night, IAT enrichments still off i guess. Since you'r IATs can be quite a bit lower than mine (more air on each gulp) i would not recommend using these for long without having the AFR meter running.

P.S. For some reason msq files are not allowed on the forum, posting to google. Here is the tune:

[AndreyB]

P.S. For some reason msq files are not allowed on the forum

msq should be allowed now. TunerStudio logs might be better since they have a better & free (?) viewer

[sturovo]

This is awesome we are beginning to cross the threshold into tuning!

This thread is completely fantastic!
The groundwork for future success is right here
Congratulations and well done spags, russian, Kb1gtt.

[spags]

Thanks! I've been resting on my laurels and scheming of what to do next .

Here is the plan:
Objectives: A configuration that works using the stock hardware of the miata, this means MAF. I know everybody thinks SD is the cats meow in the tuning world but I want to make a solution that any other miata or protege or sephia or (insert BP engine car here) can use without modifying the car. Getting more power and readability out of the stock setup is a challenge.

Roadmap:
- Make sure we are getting the information we need to tune this. Think the TS log is missing some data. Will make a detailed post of this in the software forum where it belongs.
- Get starting to work properly, it runs beautifully but starting it is like pulling teeth.
- Get starting and idle to work properly. With A/C, and adapting to loads like headlights and power steering.
- Give the MAF some love. Probably add a linearization curve somewhere. I like correct data.
- Tune the rest map.
- Get the IAT and CLT enrichments dialed in.
- Acceleration enrichment, the internets say it's the last thing you tune. Since it tends to hide fuel map and ignition problems.

I don't expect to do this in a strictly linear way. Some of these things are going to be iterative.

Feedback on what to do next is most welcome.

[spags]

Ok, may of found an issue with cranking, this is a log of cranking without any throttle (i usually have to throttle it to get kick it out of cranking logic). If i'm reading this correctly, it's missing every other revolution. Here is a log file with the behavior. This could be an issue with other part like the wave chart code.

Anyways here's the data.

And a screen shot of said thing happening.

2014-12-09 21_53rpm_0_maf_0.58.png (34.37 KiB) Viewed 16972 times

[AndreyB]

Images would really help. I am torn between all the things I want and need to be doing

[AndreyB]

It would be interesting to invoke
triggerinfo
then make a cranking attempt
and invoke triggerinfo again just to see the difference in error counters

[spags]

Will do next time the board is in the car (tomorrow). Pulled it out to get TS to play with the new changes.

[AndreyB]

Pulled it out to get TS to play with the new changes.

Someone needs a spare discovery



since you would burn this one one day anyway

[AndreyB]

I wonder if SF would allow you to create a ticket? Because a ticked would help me not to forget the way I did forget in this case. You can also use ticket # to poke me.

In return I am poking u for triggerinfo before and after a cranking sync miss.

[spags]

Ok, here is the ticket: https://sourceforge.net/p/rusefi/tickets/123/
I posted the triggerinfo output and a logfile containing that one cranking effort. On that ticket.

[AndreyB]

new command in #5789
enable trigger_details
This enables extra logging of what's going on in terms of your trigger decoding. Please try it and post your messages or maybe the full log.

[spags]

Ok, here is the log.

This was two crank tries. Let me know if you need anything else.

[AndreyB]

Does it contain any running? I would need some running to compare it with cranking.

[AndreyB]

triggerinfo now shows expected synchronization gap range, in your case it's currently

gap from 1.25999 to 2.09999

[spags]

Ok, I'm going to get data of it starting _AND_ running tomorrow night. Time was at a premium this weekend...

[spags]

Ok, here is the data, along with it running.

[AndreyB]

While running you have

Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=1.48962 @ 11
Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=0.67122 @ 4
Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=1.48936 @ 11
Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=0.67141 @ 4
Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=1.48620 @ 11
Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=0.67154 @ 4
Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=1.49083 @ 11
Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=0.67114 @ 4
Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=1.48830 @ 11
Mon Dec 15 21:22:17 AST 2014: postMessage EngineState: gap=0.67166 @ 4

so the synchronization gap is about 1.48

and the range is

Mon Dec 15 21:22:25 AST 2014: postMessage EngineState: isError No/total errors=9 ord_err=1/total revolutions=203/self=No
Mon Dec 15 21:22:25 AST 2014: postMessage EngineState: gap from 1.25999 to 2.09999
Mon Dec 15 21:22:25 AST 2014: postMessage EngineState: sn=Yes ignitionMathTime=1202 schTime=1062 triggerMaxDuration=41424

In the code I have

Code: Select all

void initializeMazdaMiataNaShape(trigger_shape_s *s) {
	s->reset(FOUR_STROKE_CAM_SENSOR);
	setTriggerSynchronizationGap(s, 1.68f);

which is a bit off.

one thing to do would be trying to compile it with

Code: Select all

	setTriggerSynchronizationGap(s, 1.48f);

50/50% if it would make a difference or not.

Another thing - please invoke
set_analog_chart_mode 1

that would enable trigger shape recording into analog chart pane & into the logs, this would allow us to confirm the angles in void initializeMazdaMiataNaShape(trigger_shape_s *s)

[AndreyB]

PS: running a unit test produces

current gap 0.634655
current gap 1.575660
current gap 0.634655
current gap 1.575660
current gap 0.634655
current gap 1.575660

So it's all a bit weird - why do I have 1.68 in the code while it's 1.58 in the test or even 1.48 in reality... Something is a bit off Once you set_analog_chart_mode 1 there should be analog_chart lines in the log, these would have the answers.

Another value which tells us if actual trigger shape is same as expected is comparing sensor signals actual duty cyxle

TRG_0_DUTY,30.03,TRG_1_DUTY,38.76
TRG_0_DUTY,29.91,TRG_1_DUTY,38.80

with expected values
testTriggerDecoder2("miata 1994", MIATA_1994_DEVIATOR, 11, 0.2917, 0.3716);

These seem to be pretty close. I am not getting how comes duty cycles are more precise then synch gap.

[spags]

Ok, got cranking working, it's rough but mostly reliable.

Here are the changes I've done.
- set_idle_pwm 800 - This got rid having to give it throttle while starting. I confirmed that with set_idle_enabled 1, the 600 cranking value it also works.
- I changed the cranking parameters to the following:



Video:

[spags]

Couple of missed starts and finally ran it for a few seconds.

These are set:
enable trigger_details
set_analog_chart_mode 1

[AndreyB]

perfect, it has the data I was looking for

analog_chart,0.00000|0.00000|51.00000|3001.00000|120.00000|2002.00000|213.00000|1003.00000|229.00000|3004.00000|284.00000|5.00000|297.00000|2006.00000|405.00000|3007.00000|474.00000|2008.00000|565.00000|1009.00000|581.00000|3010.00000|649.00000|2011.00000|
analog_chart,0.00000|0.00000|52.00000|3001.00000|121.00000|2002.00000|215.00000|1003.00000|231.00000|3004.00000|288.00000|5.00000|301.00000|2006.00000|411.00000|3007.00000|481.00000|2008.00000|575.00000|1009.00000|591.00000|3010.00000|661.00000|2011.00000|
analog_chart,0.00000|0.00000|51.00000|3001.00000|121.00000|2002.00000|215.00000|1003.00000|231.00000|3004.00000|288.00000|5.00000|301.00000|2006.00000|411.00000|3007.00000|481.00000|2008.00000|575.00000|1009.00000|591.00000|3010.00000|661.00000|2011.00000|

these are pairs of angles and event_id, id / 1000 is the event type and id % 1000 is event sequence number. Will decipher and compare with trigger definition code tomorrow

[AndreyB]

So your log file says

0 0
51 3001
120 2002
213 1003
229 3004
284 5
297 2006
405 3007
474 2008
565 1009
581 3010
649 2011



0.00000,0.00000,
52.00000,3001.00000,
121.00000,2002.00000,
215.00000,1003.00000,
231.00000,3004.00000,
288.00000,5.00000,
301.00000,2006.00000,
411.00000,3007.00000,
481.00000,2008.00000,
575.00000,1009.00000,
591.00000,3010.00000,
661.00000,2011.00000,


0.00000,0.00000,
51.00000,3001.00000,
121.00000,2002.00000,
215.00000,1003.00000,
231.00000,3004.00000,
288.00000,5.00000,
301.00000,2006.00000,
411.00000,3007.00000,
481.00000,2008.00000,
575.00000,1009.00000,
591.00000,3010.00000,
661.00000,2011.00000,

any my trigger definition right now is

Code: Select all

	s->addEvent(49.15363636, T_SECONDARY, TV_HIGH);
	s->addEvent(114.1581818, T_SECONDARY, TV_LOW);

	s->addEvent(213.0222222, T_PRIMARY, TV_HIGH);
	s->addEvent(225.759, T_SECONDARY, TV_HIGH);
	s->addEvent(279.54375, T_PRIMARY, TV_LOW);
	s->addEvent(294.786, T_SECONDARY, TV_LOW);

	s->addEvent(410.318, T_SECONDARY, TV_HIGH);
	s->addEvent(477.6911111, T_SECONDARY, TV_LOW);

	s->addEvent(576.4975, T_PRIMARY, TV_HIGH);
	s->addEvent(590.39625, T_SECONDARY, TV_HIGH);
	s->addEvent(656.5125, T_SECONDARY, TV_LOW);
	s->addEvent(720.0f, T_PRIMARY, TV_LOW);

Not that far but kind of not the same values exactly. Anyone to either find some exact numbers on the internet or figure them out?

As for figuring the values out, I would say one would need to run the engine at constant RPM for some duration of time and then average the values. With a clean enough run the values are supposed to get more precise.

PS: it looks like analog chart produces only integer values somehow? It might be best to get numeric values just to improve precision of the raw data.

[spags]

I could do a longer run and write small script to extract the info.

My timing is advanced my 2 degrees right now. Would that throw readings off?

[AndreyB]

My timing is advanced my 2 degrees right now. Would that throw readings off?

No, because these values are in relation to synchronization point, they have nothing to do with timing or TDC or anything else. These angles are from one of the trigger event points which rusEfi has declared to be the one of interest - this event is assumed to have zero angle.

[spags]

Found the issue with the round floats.

In rpm_calculator.cpp change the return line of getCrankshaftAngleN to

Code: Select all

	return ((float) timeSinceZeroAngleNt) / getOneDegreeTimeNt(engine->rpmCalculator.rpm(PASS_ENGINE_PARAMETER_F));

[AndreyB]

Code: Select all

	return ((float) timeSinceZeroAngleNt) / getOneDegreeTimeNt(engine->rpmCalculator.rpm(PASS_ENGINE_PARAMETER_F));

Actually the root cause of the issue was that getOneDegreeTimeNt was integer for no reason, fixed in #5812! Thank you for locating the issue.

One day we would need float rpm but I think it's not a pressing issue yet.

[spags]

Alright, tasty data time....

With the attatched script and log I produced:

Code: Select all

Trigger		StdDeviation
----------------------------------------
0.000000		0.000000
52.960405		0.136736
122.635956		0.284776
216.897031		0.490407
232.640068		0.522702
288.819688		0.663799
302.646323		0.700889
412.448056		0.969577
482.816719		1.155502
577.035495		1.425413
592.878113		1.471576
662.899708		1.690242

This data, is not horribly far from the values russian posted. I also posted the standard deviation through the run, error increases as the revolution gets longer and this makes sense.
The script discualifies points where rpm variance is to big so we should be ok.
This run had 219 data points.

The script is public domain/gpl. If somebody wants to use it (doubtfull) let me know so I can make the code a little bit prettier. I shat this out in 10 minutes so it aint pretty.

Edit: Added script to forum post.

[AndreyB]

Man, I cannot express how much this stuff helps!

With these numbers we are getting gap ratio of 1.4930 which is much closer to value in your log. Checked in #5815