[rusEfi] 1994 USDM Mazda Miata #11

[spags]

Here ya go

Code: Select all

index,average,stdev
0,0.0,0.0
1,48.74,0.5515432893255079
2,118.835,1.039446968344224
3,212.885,1.4919953083036048
4,226.6,1.4990663761154839
5,280.245,2.255670631985085
6,296.515,2.4112341238461448
7,402.95,2.743574311003801
8,474.02,5.232590180780476
9,574.705,15.888689373261743
10,590.09,18.172644276494303
11,758.375,155.01901963952682
Last value = 758.375
-38.375
10.365000000000002
80.46
174.51
188.225
241.87
258.14
364.575
435.645
536.33
551.715
720.0

[spags]

Here is a longer run.

Code: Select all

index,average,stdev
0,0.0,0.0
1,42.17,17.039548954459697
2,103.1875,41.69524596059227
3,185.885,75.1099363789981
4,197.9425,79.98203722443826
5,245.65375,99.26023343248508
6,260.48625,105.25347838670227
7,355.47375,143.6356152548624
8,416.485,168.28839905692507
9,498.65625,201.49093839514754
10,510.73875,206.3731882113081
11,574.485,232.13348118208685
Last value = 574.485
145.515
187.685
248.7025
331.4
343.4575
391.16875
406.00124999999997
500.98875
562.0
644.17125
656.25375
720.0

[spags]

Car specific update. Working on getting LM_REAL_MAF fueling working for the miata. Specific code for this is in https://github.com/jmt42/rusefi-code/tree/miata_maf

The rusefi.ini TS file has a working mass air flow gauge.
The miata maf data seems right and produces sane values (at least while cranking)
The miata engine config is not ready for merging. Will update when it runs.

[spags]

I'm back in black!

Painted car.

IMAG0316.jpg (1.07 MiB) Viewed 16654 times

After getting my car back from the paint shop and being bogged down from work for the last couple of weeks, I've finally had some time to work on rusefi!

So first thing i do is recompile latest version in the repo and run it in my car. After checking that everything lines up and running it for a bit. I switched to using the REAL_MAF algorithm. It runs! A little rich, but runs just fine.

So what is next (tomorrow hopefully)?
- Fixing my AFR sensor, for some reason I'm only getting the two exteme values. I have to check if the problem is in the AFR driver or the board.
- Trying it with my derived curve. This was with the default curve, it runs rich. Looking forward if i got the maf curve right.
- Tune the thing, and keep finding and fixing bugs. Hopefully drive it like that for a bit.
- Get my idle algorithm up to date with the latest code and dialing it in.
- Validate VSS
- Get the A/C to work nicely with idle.
- Start real world testing (like a trip on real roads... to real places)

[AndreyB]

I need to document accel enrichment... I need to expand it to include real_maf algo, it's currently only used for SD...

[AndreyB]

PS: at the moment the guy with most miles on his rusEfi has like three times the width of your island! you would have to drive in circles

[spags]

Yeah, it didn't feel like it was using any accel enrichment. It did feel tighter than just the using the fuel map though (which is to be expected).

PS: at the moment the guy with most miles on his rusEfi has like three times the width of your island! you would have to drive in circles

This is awesome!, my personal objective is to get it up to daily driver quality. A lot of that is in the manners of the engine (idle, ac, alternator, etc). The core is there and ready, All we need is to refine and polish.

[AndreyB]

I've just added acceleration enrichment for real_maf algorithm, it could even work but it might want other parameters in your case.

Code: Select all

		float maf = getRealMaf(PASS_ENGINE_PARAMETER_F) + engine->accelEnrichment.getEnrichment(PASS_ENGINE_PARAMETER_F);
		return getRealMafFuel(maf, rpm PASS_ENGINE_PARAMETER);

See also http://rusefi.com/wiki/index.php?title=Manual:Software:Fuel_Control#Acceleration_Enrichment

[spags]

Ok some updates.

AFR Sensor:
- I have an Innovate LC-2, the output was either 0v or 5v. It would work right after turning on the engine and it would freak out as the engine warmed up. Re-calibrated the sensor and the problem went away.

MAF:
- The MAF curve I calculated is wrong. Runs way to lean will regroup on this later. With whatever values are in there now it runs rich but otherwise just fine.
- The TS integration, specifically the MAF curve updating needs love.
- When updating the MAF curve the interface gets confused and TS is locked out for a few seconds.
- It doesn't take the values reliably. Will some times revert to an old value when i refresh the screen.
- ECU gets knocked out of REAL_MAF algorithm mode back into the old MAF sometimes, no idea what triggered but i didn't look. Happened without restarting the ecu.

SD/MAP:
- I've just modified the board and broken out the wiring for a GM MAP sensor through the unused middle plug. I used ADC4 (fast PA4) as the analog channel. Works on the bench. Will install wiring harness and sensor in car at some point later today and ve tune the car at some point.

I've just added acceleration enrichment for real_maf algorithm, it could even work but it might want other parameters in your case.
See also http://rusefi.com/wiki/index.php?title=Manual:Software:Fuel_Control#Acceleration_Enrichment

Kickass, will test. For now i'm switching my focus to MAP since MAF is being such a bitch to configure.

[AndreyB]

- When updating the MAF curve the interface gets confused and TS is locked out for a few seconds.
- It doesn't take the values reliably. Will some times revert to an old value when i refresh the screen.

TS is not perfect in general and here we have that pre-calculation table lookup which does not make things easier. Making 'burn' action smoother is going to be a big task, ideally I would need to check all the parameters, one by one, if they have changed, and only apply them if they in fact do change...

[spags]

Another update:
- MAP sensore is wired in the car. Burned the 3 bar one i had and had to go to the store and get a 1 bar (yay better resolution!). Don't put 5 volts into the Vout line of a GM style MAP sensor, it will ruin it. Ask me how i know
- VE auto tune in ts does not work atm. It leans the car down until it stops running.

I need to rest, tomorrow i'm going to attack the problem with a fresh mind.

I case any other miata owners are going to run a map sensor. I ran it through the firewall in a hole right next to the windshield washer reservoir. No need to cut the firewall, i pulled out a plug and made a grommet out of it. Same thing the DIYPNP guys do, but i left the MAP sensor in the engine compartment and ran the wires.

[kb1gtt]

You probably already noted this some where in the above, but what engine do you have? Well I'm really interested in if the engine has that tuning valve thing? Several of these engines have a valve that needs to be adjusted above about 3 to 4 kRPM. It's tuning the intake to get more air into the cyl. With out it, you'll see a flat line around 5k to 5.5k RPM.

I tend to agree with your approach, shorter electrical wires and longer mechanical hose should make for a better signal. The issue that some get concerned with is the amount of delay in the hose. Some day I'd like to find a tool that can simulate a pulse and let someone see the results of the pulse. I would bet the CPLD simulation stuff found in CAELinux could do that kind of thing.

Keep up the good progress.

[spags]

I have a simple 1.8 L honest engine, no cheats , no vvt (variable valve timing, rotates the intake camshaft to retard or advance the intake timing) and no vics (variable manifold cavity size to help with resonance). I might upgrade to a VVT head, they drop right in. Maybe someday....

Re: Tube length vs wire length.
I opted for sticking the sensor on the firewall and running the wire from there. FI guys like to keep the pressure sensor as close to the manifold as possible. I've read arguments for both, running a longer tube and running a longer cable. The DIYPNP guys just run the tube right into the board and they swear up and down it doesn't hurt anything (very probably true).

I thought about it, there are two big issues, latency and attenuation. With latency electromagnetic beats sound every time. Attenuation, 5 feet of 22 gauge cable is 0.065 Ohm (according to some web calculator), well within margin of error of the adc at those voltages.

Speed of sound is 340 m/sec at sea level density, so it takes 1/(340/length) for a pressure wave to propagate through air (i'm being very simplistic, i seem to remember tubes where a special case). Attenuation through air, its a crapshoot (this is where i agree with using CPLD), and then you've got the rubber tube acting as a spring/shock absober...

[kb1gtt]

Don't forget the typical low cost MAP sensors, typically have a 1mS or longer delay. That delay is also part of a low pass filter which limits the MAP to some couple of kHz in frequency response. Then the signals propagation will vary from a vacuum to what ever pressure you have, ect. So yup, lots of moving targets, all of which are probably below the noise floor of the MAP sensor, so probably not of any real importance.

Lots of notes about how the speed of sound varies found on this page http://www.phy.mtu.edu/~suits/SpeedofSound.html It varies from everything from humidity, temperature, pressure and make of of the gas. AKA city air vs country air will sound different.

[spags]

Ok, update time.

This weekend i carved out some time to play with rusefi. Bit of a frustrating weekend but some progress was made.

What works:
VE Analize: Works awesomely, got a tune that i can drive around. Soooo close to me being able to daily this!

What don't work:
A/C - Cannot get fsio to work, kind of confused by the code...not very exited about using fsio but should be enough to drive the car around.
idle - I'm writing a PID implementation of idle (again, since all the plumbing down there has changed so much my previous code won't patch). I've found that the car starts really well when the ICV opens wide, i want this on my car. Implementing the algorithm itself is easy, I'm having problems with the persistent configuration, i added a struct to hold the pid coefficients in the txt file and now the console nor ts can connect. I've recompiled the console after rebuilding the config and updated the ts file in my tune, still no worky.

Bugs:
TS will reset my fueling algorithm to something bogus (this bug is brought to you by the number 7).
Adding fields to the txt file is not as trivial as it should be. I've uploaded the rusefi_config.txt file i modified, maybe I'm holding it wrong

[AndreyB]

What don't work:
A/C - Cannot get fsio to work, kind of confused by the code...not very exited about using fsio but should be enough to drive the car around.

I am still looking into something, but at least I've just fixed this flood of 'setPin A/C off' messages: this was because it was trying to do stuff with the pin once you've assigned it but before you've reset rusEfi, thus before pin was initialized properly. Should be better now. Also just added set_ac_pin command.

[AndreyB]

Soooo close to me being able to daily this!

PS: you might want to replace the op-amp chips, see http://rusefi.com/forum/viewtopic.php?f=4&t=19&p=14990#p14986
Since you are in the continental US it would probably be easiest if you can order those directly there.

[spags]

Ok, progress. Conformed fsio with a/c is working, as you said needs to be reset after assigning the pin.

Persistent configuration struct.

Have not tested yet but found the following size mismatches:

console/binary/tunerstudio_configuration.h:#define PAGE_0_SIZE 15288
integration/rusefi.xml: <filesize>15288</filesize>

These values are not being scaled by ConfigDefinition.jar when the configuration grows. Will work around it for now.
b

[AndreyB]

integration/rusefi.xml: <filesize>15288</filesize>

fixed

[spags]

TS question.

I'm in the process of cleaning up the config, specifically for the idle controller area. Running into the following issue. Going to rest for a bit, but this is the problem i'm having. Any pointers or ideas welcome.

2015-04-26 22_20: EngineState: firmware error: TS page size mismatch: 14712/14708

However i checked, the size of the generated struct is 14708, no idea where those 4 bytes are coming from, ts seems to work, only the console seems to break.

Here is the commit that breaks it.
https://github.com/jmt42/rusefi-code/commit/d19eef7755fbeee3b8738b6e18800e5ce15e1e3b

[AndreyB]

Welcome back

[spags]

Hi!

I've been a little out of touch. Hopefully i will be able to play with the board in the car some time this weekend. In the process of moving so free time is at a premium.

Very exited to see the new improvements!

[AndreyB]

I currently have a 94 in my garage as an engine donor, I might start the engine on rusEfi before pulling the engine actually