[rusEfi] 1994 USDM Mazda Miata #11

[spags]

Wow, it helps!



Now come the warmup enrichments.

Edit: I should note, this was after reflashing the new firmware and resetting to my engine type and adjusting the solenoid frequency. No more changes where necessary.

[spags]

Small update, I've been playing around with tuning the idle and a/c algorithms.

Here's an update:
[video][/video]

[spags]

Hi, small update. With a question!

I've been working on other things, but today i got a wild hair up my ass to validate ignition timing (another thing i should of done from the start).
So I plug in the board and my timing light, set the whole map to 10.0 degrees advance (my car has 2 adjusted in the hardware). So i expect to see 12 degrees, in fact i saw a lot more like 20 something.

I pull up tuner-studio and look for a field that makes sense. globalTriggerOffsetAngle looks like it, the engine type configuration had this at 294. I start messing with it and get it up to 310. There the timing light says 12 degrees (10 from the ecu +2 on the sensor). The engine runs just fine, starts up fine as well.

Questions?
- Does this change throw my earlier trigger measurement out the window. I don't think so but it doesn't hurt to ask.
- Will this affect (hopefully improve) injector timing?
- Was this a stupid idea and should i put it back the way it was?

[AndreyB]

what you did is absolutely right, I wish I had an accessible timing mark on my engine I only have one for engine assembly which is hidden if the engine has all the stuff on it.

- Does this change throw my earlier trigger measurement out the window. I don't think so but it doesn't hurt to ask.

No, your trigger measurement was measuring the SHAPE, and you are now playing with the reference shape start point - the shape stays the same.

- Will this affect (hopefully improve) injector timing?

Not sure what you mean here. The question of when to start the injection is an open question, where is a parameter which specifies that - you can control at what angle to inject fuel, but I have no idea when we want to inject fuel

- Was this a stupid idea and should i put it back the way it was?

Probably not. Your timing gun should be showing exactly what you are expecting.

PS: there is an unfinished piece of code something about ignition mode DYNAMIC and STATIC or whatever, the intention of which was to allow setting fixed timing for timing adjustment with the TEST MODE input which you probably have on your harness. Not finished, would be nice to wire this switch into the board and ADC and finish that code.

[spags]

Not sure what you mean here. The question of when to start the injection is an open question, where is a parameter which specifies that - you can control at what angle to inject fuel, but I have no idea when we want to inject fuel

I meant deciding when the injector starts it's squirt. As to when that should happen; I'm on the same boat, no idea when it should happen. I imagine there is a magical time relative to the intake valve opening event that makes the fuel mix better but i haven't looked into it yet. What would be the adjustment for when i do look into it?

PS: there is an unfinished piece of code something about ignition mode DYNAMIC and STATIC or whatever, the intention of which was to allow setting fixed timing for timing adjustment with the TEST MODE input which you probably have on your harness. Not finished, would be nice to wire this switch into the board and ADC and finish that code.

Agreed.... I've got the TEN line, in the OEM ecu grounding it sets the timing at 10 deg.

Also at some point I would like to connect the check engine light as well so we have rudimentary in-car diagnostics. Having the dev console is awesome and all but in the future it would kick ass if we could notify out of spec sensors and badness in the engine (like knock) without having a pc.

[AndreyB]

Re#1:

Code: Select all

	/**
	 * this is about deciding when the injector starts it's squirt
	 */
	float injectionOffset;

Re#2:

Code: Select all

 * @file malfunction_indicator.cpp
 * @brief We can blink out OBD-II error codes using Malfunction Indicator Light (MIL)

[spags]

Ok. I'm giving up on MAF, joining the SD bandwagon.

After seeing russian's neon run and what is required to calculate engine load with MAF. Ah fuck it... I'll give in to the simple pleasures of SD, intake's coming off anyways.

So.. this means modifying the board and while I'm at it I might as well add some lines I've been wanting. Here are the proposed modifications. Hopefully these will be the last.

GM style 3bar MAP sensor (on it's way). That needs an ADC, think there is already one configured in the miata config. Have to check.
VSS, i don't think it will be very exact but i see the code going in and it looks like fun to have. This will need yet another ADC and probably pull-up as well.
Diagnostic line on ECU harness, this can by any old pin that ecu can check for ground.
Engine light, not sure what i want it for right now but it should be very useful. Also not quite sure yet on how to drive it.
Any other accessories you guys might deem useful in the future, (e.g. clutch switch?) that fit.

First step is finding suitable pins for these. Any suggestions?
As always thanks in advance for any assistance.

[AndreyB]

Ok. I'm giving up on MAF, joining the SD bandwagon.

After seeing russian's neon run and what is required to calculate engine load with MAF. Ah fuck it... I'll give in to the simple pleasures of SD, intake's coming off anyways.

So.. this means modifying the board and while I'm at it I might as well add some lines I've been wanting. Here are the proposed modifications. Hopefully these will be the last.

GM style 3bar MAP sensor (on it's way). That needs an ADC, think there is already one configured in the miata config. Have to check.

Oh yep, SD is addicting - it just runs from the box, that's a miracle.

VSS, i don't think it will be very exact but i see the code going in and it looks like fun to have. This will need yet another ADC and probably pull-up as well.

Not adc. VSS goes into a timer capture actually, PA8. Mine is

Code: Select all

	boardConfiguration->logicAnalyzerPins[0] = GPIO_UNASSIGNED;
	engineConfiguration->vehicleSpeedSensorInputPin = GPIOA_8;

Please note that I did not get it to work yet on the first and only attempt - I need to play with an oscilloscope.

Diagnostic line on ECU harness, this can by any old pin that ecu can check for ground.

TEN input? Technically could be any pin in digital mode but as a first option can you please write the code more or less the way AC switch code is done via ADC?

Engine light, not sure what i want it for right now but it should be very useful. Also not quite sure yet on how to drive it.
Any other accessories you guys might deem useful in the future, (e.g. clutch switch?) that fit.

First step is finding suitable pins for these. Any suggestions?
As always thanks in advance for any assistance.

MIL light? First question is investigating if it's controlled by ground or +12v. No idea how to figure this out, probably by staring at the schematics for long enough?

[spags]

Ok, update on hardware modifications. Nothing is connected but I have more information on how things work.

- MAP sensor, wire is connected to the ADC channel to be used. Sensor should be getting here tomorrow will validate with board before installing on car. There is one more free hole in the ecu connector. Seems like it's going to be used for the signal cable. Will use ADC4. Not sure what the open pin on the harness is will post it when I install it.
- TEN Diagnostic indicator. Connected on the harness side. Will test that it does what I think it does tomorrow. Car harness pin 2H
- MIL Light - As far as i can tell from the schematics the ecu grounds it to turn it on. So low-side it is. Still not assigned to anything on the ecu. Will test tomorrow before connecting to ecu side. Car harness pin 1E
- VSS Connected on the harness side of things. Still not sure of what kind of signal my car produces. Want confirmation it's a timed signal and what voltages i see before plugging it into the board. Car harness pin 1M

MAP sensor should be getting here tomorrow hopefully.

[spags]

Some progress and questions.

1) MIL light is tested to work by grounding the ecu side, so I've wired it up to a low-side driver.
Questions:
- Is there a way to activate a low side pin from the dev console without having to write any control logic? Just want to test that the hardware can do it.
- I see there is some code generated by java "thingy" called enum_2_string. It requires a slew of java dependencies, i don't feel like tracking down. From what i can see in the build system this is a manual step. Russian can you please add enum for the MIL light. I can take it from there and add something similar to AC_RELAY so fsio and the malfunction thread can use it.

2) TEN switch, it's just a wire from the diagnostic connector to the ecu. See http://www.miata.net/garage/faultcodes.html for how the OEM uses it. I'm running out of ADC's and want to use a generic pin. Still sorting the hardware details. But this is what I have until now (thanks kb1gtt for shedding some light earlier). Use one of the GPIOs and have a pullup to keep the line high until grounded by the user. Actual resistor values for what I should use are welcome. I understand that the protections on a raw gpio pin are not great but I understand it's an acceptable risk given that this will only be used during calibration and troubleshooting.

3) VSS, I've done some research, it seems russian was right: https://sites.google.com/site/miatadiagnostics/miata-na-1-8l-sensor-data/vehicle-speed-sensor and I'm going to need a pullup for that.
- Questions this also needs to be pulled up to vdd?
- What is the recommended resistor value (I'm assuming it's going to be relatively low since we want it to switch fast).

4) MAP sensor. Not here yet

[AndreyB]

Some progress and questions.

1) MIL light is tested to work by grounding the ecu side, so I've wired it up to a low-side driver.
Questions:
- Is there a way to activate a low side pin from the dev console without having to write any control logic? Just want to test that the hardware can do it.
- I see there is some code generated by java "thingy" called enum_2_string. It requires a slew of java dependencies, i don't feel like tracking down. From what i can see in the build system this is a manual step. Russian can you please add enum for the MIL light. I can take it from there and add something similar to AC_RELAY so fsio and the malfunction thread can use it.

No dependencies, tiny independent java project. I will need to check in the jar anyway. Also if I make tiny changes I just add the new sections manually.

Anyway, that pin is already there - it's called LED_CHECK_ENGINE

[AndreyB]

3)
- Questions this also needs to be pulled up to vdd?
- What is the recommended resistor value (I'm assuming it's going to be relatively low since we want it to switch fast).

from 1K to 10K? but be aware of my signature.

[spags]

No dependencies, tiny independent java project.

^ That statement made me giggle a bit.
Seriously though, the readme didn't document how to build it and a after a quick look it seems to have needed an IDE to build.

Anyway, that pin is already there - it's called LED_CHECK_ENGINE

^ Indeed it is is sir. Not only that but there's a whole error management system that I hadn't seen (that works). Pleasant surprise. Once i get the rest of the hardware modifications out of the way might be a good idea to replace the debugging errors with a proper testing command in the console. So many things to do and so little time.

Now on to the pull-ups....

[AndreyB]

Seriously though, the readme didn't document how to build it and a after a quick look it seems to have needed an IDE to build.

Right, I've just improved that. But in my defense, Jetbrains IDEA is trivial to install and it's just works right away

[kb1gtt]

1k to 10k should be good. I seem to recall there are internal 10k's that can be activated, so you might not need to add any resistors. It might be a software option.

[spags]

Ok, just added the VSS line, used a 1k pullup. According to speedinfo its counting events on the bench, so that works.

TEN and the MAP lines will have to wait until next week....

1k to 10k should be good. I seem to recall there are internal 10k's that can be activated, so you might not need to add any resistors. It might be a software option.

And this is why I should read the spec sheet for this MCU. Thanks kb1gtt, will look into this.

[AndreyB]

2) TEN switch, it's just a wire from the diagnostic connector to the ecu. See http://www.miata.net/garage/faultcodes.html for how the OEM uses it. I'm running out of ADC's and want to use a generic pin. Still sorting the hardware details. But this is what I have until now (thanks kb1gtt for shedding some light earlier). Use one of the GPIOs and have a pullup to keep the line high until grounded by the user. Actual resistor values for what I should use are welcome. I understand that the protections on a raw gpio pin are not great but I understand it's an acceptable risk given that this will only be used during calibration and troubleshooting.

I have not made my mind really, but I am kind of tempted to suggest FSIO for TEN implementation. I suggest timingMultiplier and timindAdditive, which would be multiplier=1 and additive=0 by default, while TEN would make them multiplier=0 and additive=10, and suddenly you 10 degrees timing.

[kb1gtt]

And this is why I should read the spec sheet for this MCU. Thanks kb1gtt, will look into this.

If you read the STM datasheet you may find I haven't read the datasheet I think it has a the pull up, but I could be wrong, so don't bang you head too hard about it if you don't find it.

[AndreyB]

my assumption is that you cannot set pullup/pulldown while in timer input capture mode which is the context of VSS. i can easily be wrong

for instance 'clutch up' input is different because it's not the complex 'timer input capture' device but the plain GPIO mode.

[spags]

I have not made my mind really, but I am kind of tempted to suggest FSIO for TEN implementation. I suggest timingMultiplier and timindAdditive, which would be multiplier=1 and additive=0 by default, while TEN would make them multiplier=0 and additive=10, and suddenly you 10 degrees timing.

Actually that sounds like an excelent use case for fsio. TEN does different things on different cars, and timing marks changes per car model. It avoids having to write all software for storing the value and intepreting it.

my assumption is that you cannot set pullup/pulldown while in timer input capture mode which is the context of VSS. i can easily be wrong
for instance 'clutch up' input is different because it's not the complex 'timer input capture' device but the plain GPIO mode.

Does the current clutch up down code use this? Because it would be ideal for TEN input.

[AndreyB]

Does the current clutch up down code use this? Because it would be ideal for TEN input.

yes

Code: Select all

iomode_t getInputMode(pin_input_mode_e mode) {
	switch (mode) {
	case PI_PULLUP:
		return PAL_MODE_INPUT_PULLUP;
	case PI_PULLDOWN:
		return PAL_MODE_INPUT_PULLDOWN;
	case PI_DEFAULT:
	default:
		return PAL_MODE_INPUT;
	}
}
		mySetPadMode2("clutch up switch", engineConfiguration->clutchUpPin, getInputMode(engineConfiguration->clutchUpPinMode));

Wanna focus on VSS & MIL for now and I would implement the FSIO input code within the next week?

[spags]

Yeah sounds like a good idea. This is a small todo list of things that I'll be doing. Open to suggestions.

MIL - Remove the debugging debugging errors on init. And replace with something like milbench. For the short term this is going to have to go on the ignition_central.cpp file since that's where the bench thread lives. I was planning on something that blinks the light a few time and that seems like it's going
Compile a list of error codes we want to support and start slowly implementing them. I would start with the OEM error codes for my car and add codes as they become relevant.

VSS - I just field tested it. The values are bonkers. I'm attaching the log file for the run. I tried to keep as close to 20 mph as possible. I like the results, it says that my little miata can go .3c (where c is the speed of light). So for some reason it's seeing a lot of noise. It can reliably tell if the car is moving or not.

Resting for today, any suggestions or feedback welcome.

[spags]

Ok, update.

I finally got around to working on the milbench code and testing it. It would look like this in injector_central.cpp.

Code: Select all

extern OutputPin checkEnginePin;

void milBench(void) {
  	brainPin = boardConfiguration->malfunctionIndicatorPin;
	pinX = &checkEnginePin;
	
	delayMs = 0;
	onTime = 3000;
	offTime = 0;
	count = 1;
	
	needToRunBench = true;
}

I also added a console action in controller/malfunction_indicator.cpp called testmil that adds a couple of OBD errors to the error table (as opposed to just adding them on thread startup). I found a strange issue with it though. Apparently the console command gets executed at some point without me entering the command on the console!

I noticed that I was getting errors on the MIL even without me running the command. I confirmed this by commenting out all of the addError() calls in testmil() and reflashing. No errors on the MIL. testmil() is not explicitly called by me anywhere.

I'm probably holding it wrong since a bug like this with addConsole() would of reared it's head long ago. But looking at other commands this should not be any different. Here is all the code if somebody wants to take a whack at it: https://github.com/jmt42/rusefi-code/tree/miata_mil

[AndreyB]

Great to have you back!

I've just merged the MIL changes, the config file is a bit of a conflict I am now too tired to think about it... https://sourceforge.net/p/rusefi/code/6534/

[spags]

Good to be back!

Any confirmation/fix for the testmil() bug?

[AndreyB]

Any confirmation/fix for the testmil() bug?

Nope, no idea what's going on

I can kind of see how console would re-send a command. I have not experienced a random command invocation. Technically I've fixed a stack overflow bug today, technically you can compile your binary with #define EFI_ENABLE_ASSERTS TRUE to enable stack validation.

[spags]

Ok, will test later. Could be the console. I didn't see anywhere in addConsole() anything that could come close to triggering this. If it's happening from within the console firmware it's some kind of bad freaky.

I noticed that the new console code stores some sort of state between runs. Where is this "state" stored? I want to test again starting the console with a clean slate to discount the command getting sent for some reason.

[AndreyB]

Code: Select all

public static final String CONFIG_FILE_NAME = "rusefi_console_properties.xml";

[AndreyB]

Thank you for your angle extraction script by the way, I've checked it in as https://svn.code.sf.net/p/rusefi/code/trunk/misc/extract_trigger_angles.py

[AndreyB]

Hey, can you please do me a favor? I need to gather trigger angles while cranking, with the car NOT catching-up.

1) update firmware & update console
2) disable injection & ignition

3) in sensor sniffing (ex-analog sniffing), set chart mode to '1' and chart frequency to '2'
(enter value and hit ENTER on the keyboard for it to be send to the firmware)

4) cranking it a bit and post the result from the 'wizard' pane (UI still horrible, work in progress)