[rusEfi] 93 1.6l Miata stock engine (for now)

Your chance to introduce yourself and your vehicle
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

93 1.6l Miata stock engine (for now)

Post by stefanst »

I need to use my 1.6l Miata engine to its fullest potential. What better way to do this, than to add rusefi?
BUT: I also love my creature comforts and that means I need AC.

What I would like to do:
Monitor the AC switch with an analog input
Once the AC is turned on, I would like to raise idle rpm by a certain value- let's say 50rpm and then, as long as rpm is greater than the new idle rpm, minus, let's say 30rpm or so, I would like to turn on the AC compressor and AC fan which are both connected to a low-side driver.

To summarize:
idle rpm target is, let's assume, 900 according to our idle rpm tables
When AC is turned on, new idle target is 950
If AC is turned on and rpm> (950-30), turn on AC compressor and AC fan

FSIO still seems to be mainly Voodoo, so here I am, begging for assistance.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

you can already control outputs with "rpm > 930" condition, but at the moment you cannot adjust idle target based on FSIO logic

This is https://github.com/rusefi/rusefi/issues/600
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

I'll try it on the stim, but first I have to work on my house :-(
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

So, I got a bit stumped on setting this up in FSIO. Even the simple version without the increase in idle.

My problem is that I couldn't find a description on how to reference an analog input.

Under FSIO Inputs I set ADC #1 to PA3
Under FSIO Outputs I set Output #1 to PC13, 0Hz (not using PWM- just bang-bang)

So now I want something like IF(input1 >0,5) THEN set output 1 to 100%

So in for FSIO formula 1 in RPN we get something simple like: input1 0.5 >

Questions:
It appears that Formula 1 is hard-connected with Output 1, but not with Input 1, correct?
How do I reference Input 1?
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

Yes, VVT should work pretty much out of the box with set engine_type 47
Do you have VVT gauge showing anything?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

I've just realized that FSIO inputs are only half-implemented. I am really embarassed for wasting your time trying to figure out how it works while currently it has extremely limited functionality. Good news is you can _hopefully_ use it as is, and I am hoping to improve this logic soon.

Documentation updates at https://rusefi.com/wiki/index.php?title=Manual:Flexible_Logic#FSIO_digital_inputs

Prior to today, it was
rpn_eval "fsio_input"
and
set_fsio_expression 0 "((rpm > fsio_setting(4) & (fsio_input < fsio_setting(5)) | rpm > fsio_setting(1) | (coolant > fsio_setting(2) > | (vbatt < fsio_setting(3)"

both without index parameter - as of right now it's always ADC input #1

In order to reduce or increase the confusion, I will now at least rename it to "fsio_analog_input" - so the above examples ARE NO LONGER VALID WITH LATEST FIRMWARE, the above mentioned link to the documentation should be the source of truth for version 20180801


https://github.com/rusefi/rusefi/commit/309dd497da9e52340017b4e8b25acaa83be52cab
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

PS: so at the moment it's only ANALOG input which I assume could still be used for a switch, it's just that you would need to compare analog switch voltage with some threshold, like in the example where it says
fsio_analog_input < fsio_setting(5)

or maybe could be simplified to

fsio_analog_input < 1
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

It's been over a year since I played with rusefi, BUT: I have the 93 Miata running on rusefi. And it's running almost flawlessly.

One teensy-weensy little problem. I believe I reported on this earlier: When using CL Idle control, there is a condition where the I-Term of the controller just runs away from me. This is when I'm coasting. What is happening:
- driving along and about to stop
- Lifting off the throttle while still in gear- TPS is 0, so CL idle engages
- While coasting, the RPM is much higher than the idle target, since the engine is being turned by the wheels
- So the PID is trying to reduce idle and the I-Term just keeps dropping into deep negative territory
- Now I'm pushing the clutch, when trying to come to a stop and the I-Term overrides all the other terms of the PID and our idle valve sits at its' minimum, leading to the engine stalling, if, for example, AC is running

I found a trick to deal with it- blip the throttle briefly when hitting the clutch. This leads to the PID turning off briefly and the I-Term resets. If I forget, the engine stalls and embarrassment ensues.

Log trace showing the behavior: I-Term goes to negative 55. P-Term has to overcome this in order to avoid stall. If I make the P-Setting strong enough, so it can overcome this problem, my idle starts oscillating like crazy.
Runaway I-Term idle drop.png
Runaway I-Term idle drop.png (69.73 KiB) Viewed 20078 times
How can we overcome this?
If you have a MAP sensor, the easiest thing would be to set a minimum MAP value for PID to engage. When the car is coasting, MAP is below normal idle MAP. So we can start engaging PID, when the MAP goes above a certain value and the I-Term will have a lot less time to go nuts.
Another option would be to define coasting from the change in RPM. During coasting the RPM changes only slowly. Once I hit the clutch, it drops more quickly. Define a threshold value for drpm that determines if we're coasting or supposed to be idling.

Last but not least, we need min and max values for I-Terms. I can't see a scenario where an I-Term for CL idle would evener need to be smaller than [minimum]-[offset].

As always, I may very well be wrong.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: 93 1.6l Miata stock engine (for now)

Post by kb1gtt »

How much error do you need for 100% output based on just the P term? One potential option is to create an band for the I term. This is common on temperature controllers. Basically if you have a P term of 10, when ever your RPM is off by more than 10 RPM, your P term would be 10*10=100% output. In this situation, there is no need for the I term, so the I should be 0. Then if you are closer than +/- 10 RPM, the P term is no longer 100% output, and the I term could be part of the equation. Keep in mind that eventually the I term will be your full output, and the P term should be really close to 0% of your output.

Also do you have I term limits? Limits can prevent the issues caused by wind up.

Any how, I can suggest an I term band, as well as I term limits.
Welcome to the friendlier side of internet crazy :)
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

We have MIN/MAX values for the OUTPUT. So we're never commanding less than minimum or more than maximum. But the individual terms have no min/max. P-term is [error]x[p-parameter]. Which is fine. But I-Term winding up is killing me. Or rather my engine. Limiting "I" is what I tried to suggest in a roundabout way. There's no point in "I" ever being lower than the difference between the minimum value that can be commanded [min] and the [offset] value, which is the value we start with when entering CL idle. My minimum is 30, my offset is 42. I can't picture a scenario where you need a value of less than -12 in this case. Maximum value for I-term should be [max]-[offset]. Of course we can be MORE restrictive, but less restrictive makes no sense.
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

I think I JUST understood the suggestion. Only start adjusting "I" when "P" is not maxed out anymore. Makes sense.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

I have just exposed iTermMin/iTermMax setting for idleRpmPid, similar to how we have this for ETB pid under https://github.com/rusefi/rusefi/issues/913

Please let me know if it works or else, maybe we can even come up with nice global defaults? At the moment it's set to -200/+200 by default.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: 93 1.6l Miata stock engine (for now)

Post by kb1gtt »

Can we add limits which will set the I term to 0? With idle, lets say the set point is 1kRPM. Then lets say you set the max I cleared limit = 100 RPM, and min I cleared limit = 50 RPM. Then if you are above 1100 or below 950, the I term is 0.

Temperature controllers commonly have very slow response times. It has become very common for these controllers to have a Proportional Band (PB), instead of Proportional Gain. Basically if you want 100C, you tune your gain by specifying the PB of something like 10C. The gain ends up being G=100/PB. For this discussion, lets just consider it 100% output, and ignore the issues with it when it's not really 100%. One reason for band instead of gain is because the I term winds up, and causes overshoot. A semi-hidden feature that happens when you set your PB is that you also clear your I term when outside of the PB. I find this semi-hidden feature annoying, as you cannot change it, and you can only find it by looking at the I term. Often this I term is not available for normal people to analyze. It was a real pain reverse engineering this particular issue. Also it's common you do not want this set at the magical PB, which is what I was once faced with. So to make it more clear, I suggest we simply allow setting a I clear min limit and I clear max limit. Also we could disable it with setting the clear limits to 0. AKA if I clear min = 0, then integral clearing based on the min is disabled.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

And potentially more important https://github.com/rusefi/rusefi/issues/806 - different implementation of PID altogether! I would ask @andreika to tell us more about CIC PID approach to idle control.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

I downloaded the latest FW, exposing min and max for the I-term. But, to start with, I did some experimenting with the other settings.

Overall Settings; RPM target = 1050, OFFSET = 35, MIN = 30, MAX = 75. P= 0.003, time base 500ms. All others 0
P-term was arrived at through prior experimentation.
P-only 500ms.png
P-only 500ms.png (53.48 KiB) Viewed 20044 times
Previous Error oscillates from -459 to +369. In response P-term (which isn't logged) oscillates from -5 to +11 (it can't go to less than -5 due to the lower limit. Otherwise we'd get a P-term of -13.4, stalling the engine)
We learn that 500ms is too slow. Strong oscillations caused by sluggish response. I then went to 200ms time base. Things improved, but could be better.

Next log:
Same values, only time base 50ms.
P-only 50ms.png
P-only 50ms.png (65.74 KiB) Viewed 20044 times
This looks much better. Smaller oscillations, our output varies between 31.8 and 41.4. RPM oscillates between 1163 and 915 (target 1050).
I also went to a 10ms time base. Improvement was there, but quite marginal.

Now, trying to get rid of the oscillations, I added some D-term (D=0.01):
P-D 50ms.png
P-D 50ms.png (53.92 KiB) Viewed 20044 times
You can see the D-term reacting, but the impact on the oscillations was minimal. I added more "D", but essentially to the same effect. It looks like at this fast time base, the D-term goes away too fast to really make a huge difference. You can actually see the MAP value reacting to the fast fluctuations, so the idle valve does react quite fast, but the RPMs don't care much. The engine is just too slow to react.

Then I tried to reduce P to get rid of the oscillations, while still leaving D in there, because, why not. I also added some "I". Now when I had enough "I" to actually make a difference in a reasonable amount of time, the problem with the engine stalling re-occurred. Even the time it takes for the engine revs to drop from blipping the throttle (a little more than 1s), my "I" term has wound down enough to stall the engine sometimes.
PID.png
PID.png (58.24 KiB) Viewed 20044 times
And then it started raining, so I pulled my convertible back in the garage and stopped the experiment for now.

Lessons:
- I still need to optimize time base more. Maybe with a longer time base, "D" will have more effect
- There's a fine line between the "P" parameter that keeps the engine running somewhere near target idle and one that oscillates quite impressively
- If you make "I" strong enough to make idle control feel like it's somewhere near stock, it still winds down too much, so we get back to a stalling engine. I'll try a more conservative lower limit for "I" next time and maybe lower the offset, so we can reach target under all conditions. My strategy so far was to have the offset at a value that keeps the engine running with the AC on. But maybe that's too much.

BTW: It seems that we're off by a factor of 10 for the "P" parameter. I had it set to 0.003. So at a "previous error" of 400, it should only add 1.2, yet it adds 12.

Does anybody have a succesfull implementation of PID idle running in anything that feels near stock idle quality?

@andreika My Russian is highly limited, so I can't follow what's been going on in hte discussion. Could you give me a short description what your custom PID_CIC code does? Do you think it could help my problem?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: 93 1.6l Miata stock engine (for now)

Post by kb1gtt »

P term? Also what was the total output? What do you think the total output should have been? Can you sketch in a line to show what you think it should have been?
Welcome to the friendlier side of internet crazy :)
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

P-Term is not logged by debug. I guess we don't have sufficient float variables available.
In any case, it can easily be calculated by looking at the actual output and subtracting everything else. It's just "previous error" x 0.03 (p-parameter).
Total output is f1. I can upload the logs if that helps.

Not sure what you want me to sketch.
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

I've been doing some thinking.

I'm fighting several issues here. If I'm running the engine without much additional load (for example AC), I can tune the PID values to give me decent idle control. I select the min value to just barely keep the engine running. The Offset is roughly where I expect idle to land. The PID just does some fine-tuning around that.
I can do the same thing for the engine running WITH additional load. But then my idle will be too high when the AC is not running.

But if I tune for idle without AC running, my engine will stall if I turn on the AC. I can crank up the P parameter to avoid that, but this will invariably lead to oscillations- no matter what I do with base time and D-parameters. I'm pretty sure at this point it's not a tuning issue- it's a conceptual problem.

An easy fix would be to increase the minimum and offsets when the AC is running. However, there are a few other things that change my power requirement: Engine fan, headlights, power steering for example. Even the AC input is not a 100% thing. The AC pressure sensor could shut the compressor down without the ECU ever knowing about it.

So, no easy fix. I'm pretty sure the suggestion to only have "I" come in when P is not maxed will help, but I don't think it will be enough. Maybe that, combined with some sort of AC adder for min and offset might do the trick.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: 93 1.6l Miata stock engine (for now)

Post by kb1gtt »

See attached picture. I think the Blue line is fairly close to what you desire the output to be. The bottom white line is what is happening. Is this picture reasonably close to what you expect / desire? If not can you sketch a line similar to this, which shows what is desired vs what is happening?
Attachments
PID_Should_be_JH.png
PID_Should_be_JH.png (76.01 KiB) Viewed 20025 times
Welcome to the friendlier side of internet crazy :)
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

So, the car just developed another problem: MAP goes to "0" and stays there until I restart the unit.
Really creates a big issue with drive-ability. Engine just dies randomly. Tried 3 different 3bar MAP sensors- same result. I would usually suspect my wiring, but wiring doesn't get reset by shutting the unit off and turning back on. Now it happens pretty much every time while cranking. Car fires up and MAP goes to 0. Car dies. All other inputs are fine. I checked- the pin isn't used for anything else.
Using PA6 (IN10) for input.
Any ideas where I screwed up before I go on the treasure hunt?
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

stefanst wrote:
Wed Sep 04, 2019 10:52 pm
So, the car just developed another problem: MAP goes to "0" and stays there until I restart the unit.
Do you have rusEfi console? What does analoginfo display while MAP says zero?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

So, I get error code 105. "OBD_Manifold_Absolute_Pressure_Circuit_Malfunction = 105,"
I have low value threshold at 5 and high threshold at 250. I assume one of these gets exceeded for some reason and the controller shuts it down- correct?
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

russian wrote:
Wed Sep 04, 2019 11:05 pm
[...]
Do you have rusEfi console? What does analoginfo display while MAP says zero?
Sorry- nowhere near the car. It's at work and I'm at home. I do have the ECU, but it behaves nicely on the bench.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

Oh right :( with value out of range, it returns 0 :(

Code: Select all

	if (cisnan(mapKPa) || mapKPa < CONFIG(mapErrorDetectionTooLow) || mapKPa > CONFIG(mapErrorDetectionTooHigh)) {
		warning(OBD_Manifold_Absolute_Pressure_Circuit_Malfunction, "unexpected MAP value: %.2f", mapKPa);
		return 0;
	}
	return mapKPa;
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

russian wrote:
Wed Sep 04, 2019 11:47 pm
Oh right :( with value out of range, it returns 0 :(

Code: Select all

	if (cisnan(mapKPa) || mapKPa < CONFIG(mapErrorDetectionTooLow) || mapKPa > CONFIG(mapErrorDetectionTooHigh)) {
		warning(OBD_Manifold_Absolute_Pressure_Circuit_Malfunction, "unexpected MAP value: %.2f", mapKPa);
		return 0;
	}
	return mapKPa;
Looks like that error doesn't get cleared and the engine stalls :o
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

russian wrote:
Wed Sep 04, 2019 11:05 pm
[...]
Do you have rusEfi console? What does analoginfo display while MAP says zero?
Well, analoginfo shows the following after cranking:

Code: Select all

MAP ADC6 fast PA6 adc=0.01/input=0.02v/divider=2.00
While before cranking we get this:

Code: Select all

MAP ADC6 fast PA6 adc=0.90/input=1.81v/divider=2.00
All the other sensors, including TPS and MAF, that get fed by the same 5V supply, seem to behave perfectly normally. I tried 3 different MAP sensors, so I doubt it's the sensor. Will do some bench testing later. Maybe switch to a different ADC. Car is still at work, so I didn't have a DVM and I was unable to test actual voltages which would have helped a LOT.
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

One thing I forgot to mention:
This happened once, driving. I limped back to my office, using un-tuned MAF. Then I replaced the MAP sensor. The engine fired up, I had signal for about 5 seconds or so and then the engine died. Interestingly it died RIGHT when I started a log.
Now it dies every time I'm cranking the engine. Typically right when the injectors and coils start firing. The engine still fires up, since we don't use MAP during cranking, but as soon as it goes out of cranking mode, it dies.
It looks like the ADC is still reading something though. Just very small voltage, but it is varying a bit.
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: 93 1.6l Miata stock engine (for now)

Post by stefanst »

So, I think I traced it to a faulty brainboard.
The output from the opamp worked just fine, but after the voltage divider I got 0V, or close to it. It appears that this board just pulls the PA6 pin to low as soon as injectors and / or ignition start firing.
It just started randomly. Weird.
Replaced brainboard and so far it's all good. I'll let it run on the bench over night and see if it's still OK in morning.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 93 1.6l Miata stock engine (for now)

Post by AndreyB »

Hardware and reality. Two things we cannot trust :( But we probably do not have resources to deal with limping mode and automatic switch to limping mode :(
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply