[rusEfi] 1994 USDM Mazda Miata #11

[AndreyB]

Here is my interpretation of kb1gtt's schematic as applied to my frankenso board.

Code: Select all

              1J
1Q -- (R10K)--|
   |        D7 Low side 
   |
   |                2S
1S -- (R10K)--------|
   |              E3 Low side 
  W50 Input

Wait a second, are you saying something is controlled electrically, not via the firmware? Looks like in this setup the ECU is not really turning anything on, it's just informed of the A/C status so that this could be used for idle adjustments etc

[spags]

Looks good to me don't forget the diodes

Sorry, confused, where would the diodes go in that schematic?

Wait a second, are you saying something is controlled electrically, not via the firmware? Looks like in this setup the ECU is not really turning anything on, it's just informed of the A/C status so that this could be used for idle adjustments etc

To be honest, no idea how the stock ecu does it. I still don't really understand it. It can be done that way though.

However, by my observations of how it behaves I think the ECU stands in the way of turning on the A/C. There are delays between pushing the button and engaging the A/C clutch. These delays could be done in hardware somewhere down the line but the fact that they vary depending on engine condition (waits for rpms to stabilize if started with a/c on for example). Leads me to believe it's controlled by the ECU.

[spags]

Thinking about it...

Even if the OEM configuration was a passive ECU and the relay was enabled by the a/c switch. I think it would be better (and more generic) although not simpler if the ecu had an active role where it had complete authority over the a/c subsystem. At this point it's wired that way and the only remaining thing to do is wire the (2) relays so the ecu can do it's thing.

I'm willing to write the code to control it.

Questions? Will one low-side handle two relays? And is there an existing schematic to how to do this being done?

Again, thanks for all your help and patience with figuring the hardware side of this.

[AndreyB]

I've added the code to control the pin according to the input switch. I have to run to the garage so I have not tested it yet, but it might work as is.

Code: Select all

	if (boardConfiguration->acRelayPin != GPIO_UNASSIGNED) {
		setPinState(AC_RELAY, acRelayLogic, engine);
	}

[kb1gtt]

I don't quite follow the D7 and E3 thing. I see the "low side" note, which I assume is low side drivers, probably jumper wire from the harness side of W10, wired too the low side driver side of W58 which would allow MCU control over the AC clutch activation. Then 0 ohm jumper on W57 for AC radiator fan activation.

When W50 is 12V or there is no RPM, the firmware needs to make W57 and W58 to be turned off, disabling the fan and AC clutch. When W50 is close to 0V, and there is RPM, then software will make W57 and W58 turned on, which will enable the AC clutch and radiator fan.

[AndreyB]

12V on W50? Would not 12V on analog input be a problem, or do we expect the diode to take care of this?

If W57 and W58 need to be on or off at the same time, I think we should consider them to be one wire - either W57 or W58.

I guess we are still on square one:

How many wires are coming into the ECU? A series of switches of different nature should be considered one switch as long as it's one wire in the end of the day.
How many wires to do we need to control with the ECU? Who devices which always operate together should be considered one wire as long as the devices are always operated together.

[kb1gtt]

I figure we want the fan control and compressor clutch control separate, as people will probably want additional fan controls. For example, if the engine overheats, no harm in turning on the AC radiator fan to help cool things down. However for now I say we just focus on the AC and deal with other potential radiator fan controls at a later date.

Yes the 12V should be handled by the rail dumping diodes.

[spags]

I agree about having both lines separate, was trying to not splurge on my low side outputs. Then it occurred to me that A) we don't have a shortage of those (not in this ecu anyway) and B) I don't expect to add more functionality.

Yesterday I wired it like this:
1J - W36 (D7 Low side )
2S - W57 (E5 Low side)
1Q - W50(PA1 ADC)

The low side connections still need to be tested, have to figure out how to make the low side activate from the console so I can test.


I also started writing a controller to handle the A/C during idle and such. Its not done yet but I'm attaching here so you can see what direction I'm headed in. It basically implements what kb1gtt said a couple of posts back but it also handles the idle changes.

My intention is to run it in the idle thread. Right after getIdle(). It modifies the idle struct according to a/c condition. Please note that other than kicking the PWM (this bump value should be configurable per car) and setting the new target rpm it doesn't interfere with the idle mechanism and relies on it to do it's job. Since it limits itself to certain RPM ranges this would exclude it from running during cranking. A lot of the config values are still as macros and will need to be moved to a proper place when the code matures.

[kb1gtt]

Ah, I see port D bit 7. I usually write this as PD7 which matches the discovery silk screen.

Keep up the good work with the code generation. I know russian is trying to focus on more critical code. It's great to see others contribute to items like this. If there is something I can offer like basic algo help, let me know. I can generally read and understand code, but I'm not so good at generating code.

[spags]

Thanks kb1gtt, you've been very helpful in the hardware side of it. My knowledge of hardware stops at the logical part of it. I get registers, timers, buses and adc's but once you throw a resistor or a diode in there I'm a little out of my element .

In other news, It works! I tested it earlier, the values are a little wonky and hard-coded. It needs to be tuned but the basic algorithm is implemented and working.

I work with git and have been using a git-svn bridge to the sourceforge repos since merge's russians changes into my code. I'm setting up a git repo on githhub so russian can review pull the whatever code he sees fit to integrate into mainline. I'm open to other ways of contributing code, but this is what has been working for me.

I would like to break out some of the a/c configuration to the engine config struct, once these are broken out it should make for a pretty generic algorithm. These are the proposed config parameters, they are macro's now:

Code: Select all

acPwmBump - How much the PWM gets kicked in order to adapt fast enough. I was trying 50, it's too much. Not really worth tuning until afr's and timing is tuned at idle.
acIdleRpmBump - How much the target rpm changes so the idle mechanism can keep it there. Specs on my car say 200 above idle.
acCutoffHighRpm - At what rpm the ecu cuts the A/C in order to have moar power or just save the compressor. 4000 in my car.
acCutoffLowRpm - At what rpm the ecu just disables the a/c in order to recover, or we could use the same panic RPM the idle thread uses?
acCoolingFan - Should this be added? We can just slave it to the ac_relay using fsio?

[spags]

And..here is the github repo.
https://github.com/jmt42/rusefi-code

[AndreyB]

And..here is the github repo.
https://github.com/jmt42/rusefi-code

Why does it not show up @ https://github.com/rusefi/rusefi/branches ?

[AndreyB]

I would like to break out some of the a/c configuration to the engine config struct

Will do tomorrow

[spags]

Why does it not show up @ https://github.com/rusefi/rusefi/branches ?

Good question, will figure that out tomorrow. Used git for years, new to github though.

[3400tZ]

Why does it not show up @ https://github.com/rusefi/rusefi/branches ?

Good question, will figure that out tomorrow. Used git for years, new to github though.

For some reason, it looks like your repo isn't a fork of the original repo. You want to click the "Fork" button in the rusefi repo and commit in that repo after.

[spags]

That might be it. I did a git-svn checkout of the repo in sourceforge so I could have accurate revision history instead of the repo-sync that the rusefi github repo has. That's been my working copy so I don't have to wait for the repo sync change to get my code. It keeps the possibility of committing to the svn repository open (git-svn is bidirectional). Also it merges my changes on top of russian's and keeps things easy for me while tracking development.

It seems getting github to recognize the link to the rusefi is going to be difficult since the repositories only share the svn repo as a common ancestor.

[AndreyB]

These are the proposed config parameters, they are macro's now:

Code: Select all

acPwmBump - How much the PWM gets kicked in order to adapt fast enough. I was trying 50, it's too much. Not really worth tuning until afr's and timing is tuned at idle.
acIdleRpmBump - How much the target rpm changes so the idle mechanism can keep it there. Specs on my car say 200 above idle.
acCutoffHighRpm - At what rpm the ecu cuts the A/C in order to have moar power or just save the compressor. 4000 in my car.
acCutoffLowRpm - At what rpm the ecu just disables the a/c in order to recover, or we could use the same panic RPM the idle thread uses?
acCoolingFan - Should this be added? We can just slave it to the ac_relay using fsio?

For now I've just added the ones I am totally confident about:

Code: Select all

	short int acCutoffLowRpm;
	short int acCutoffHighRpm;
	short int acIdleRpmBump;
...
...
} engine_configuration_s;

As for the rest, I want to think about this some day later... Like not this week later

[spags]

Ok, github repo, take 2.

https://github.com/jmt42/rusefi

This one is a clone of https://github.com/rusefi/rusefi so everything should line up within github.

[kb1gtt]

I'm curious, have you spent more time on creating the code or on getting git / github to work properly?

I wonder why someone can't make a good repo tool. From my view on the world, disjointed and convoluted tools are just as bad as poor security. There are many items that can waste my project time, and I'd prefer to use my limited time developing and not getting into an argument with the computer. So I wonder, why can't someone build a good repo tool?

[/end rant] Keep up the good work, even if I put up some negativity

[spags]

Well... i was kind of pushing it. Expecting 3 different repositories using 2 fundamentally different technologies inter-operate was kind if silly ambitious.

As for a good repository tool; git works pretty well for an SCM system, I've been using it for work and my personal stuff for years and it stays out of my way for the most part. I do have a particular disdain for centralized repository source code management (subversion and cvs looking at you!), IMHO, you just can't do branching properly with centralized systems.

Re: Github. Always had my git repos on my own servers or my job's servers. I hear good things about github so I decided to try it. Up until now.. meh? Its good enough for Linus (he started git and linux) worth giving it a try i guess. All i need is a place to push my code to so other people can pull, works well enough.

As for time writing code. A sad fact of life is a good programmer spends about 3-4 times as much time debugging than writing new code. Such is the nature of the beast. That's why so much attention is placed on software design. Setting up a repo is usually not such a bitch but i really really don't like svn so I'm trying to side-step it if possible.

[AndreyB]

I've moved two posts to http://rusefi.com/forum/viewtopic.php?f=5&t=501 just to make a statement that severe off-topics rubs my OCD the wrong way...

[spags]

Couple of small updates..

Added the WBO sensor to the car and wired the board and configured it for ADC port 7.

Made the following change to my car config:

Code: Select all

engineConfiguration->afrSensor.afrAdcChannel = EFI_ADC_7;

Another issue came up, I've had a "WARNING: ADC is off 14" warning come up on the console. Probably due to the new alternator control code.

Showconfig reveals the following:
2014-12-03 18_47: EngineState: Vbatt ADC14 INACTIVE PC4 rawValue=0.00000/divided=0.00000v
This value gets inherited from the honda configuration.
I traced it out to the breakout area of my board (W44), nothing connected. Should there be?

Will test in car and validate the wiring probably tomorrow. Along with attempting to configure idle.

[AndreyB]

I've just added

Code: Select all

engineConfiguration->bc.adcHwChannelEnabled[14] = ADC_SLOW;

into commonFrankensoAnalogInputs

This is about +12 voltage, it's board input 12 which is ADC_14. Frankenso inp 1-2-3-4... etc does not match stm ADC channels, more on this on http://rusefi.com/images/Frankenso/analog_inputs.png

This adcHwChannelEnabled is something I want to improve one day... Maybe simply enable all channels in slow mode with the exception of the MAP channel which better be fast.

[spags]

Update... disregard previous instructions for the wideband. Got it working after some changes.

Got it working with the following setup:
Routed the wideband input to W48. That corresponds to EFI_ADC_3.

Updated the configuration in my car to:

Code: Select all

	engineConfiguration->afrSensor.afrAdcChannel = EFI_ADC_3;
	initEgoSensor(&engineConfiguration->afrSensor, ES_Innovate_MTX_L);

It looks like the board is reading it correctly. Got it to idle and read an AFR of 10.4. It smelled rich.. now we know. It leans out when i rev the engine. Barely reaches 14.

Now that the hardware part is mostly done, I can turn my attention to code. I will try my hand at tuning this weekend. Hopefully I can get idle down and dial in the a/c code.

Progress!

[spags]

Quick update,

Have not gotten to tuning yet. May of found a bug with the dev console / ts switch mechanism, will chase it down later.

Here's a quick description: When console redirection is enabled ADC values go crazy. No idea why but I confirmed it on the bench. Will take a closer look later.

Trying a workaround, no redirection (as in... the normal way of doing things )

[spags]

Got a tuned idle @ 800 RPM. Runs like stock, still a little rich. I want to keep it a little rich while the idle code is debugged.

Here is the video:

[video][/video]

Issues (there is always something isnt there):
TS connectivity is unstable, does not crash but does not take every change.
Idle algorithm does not seem respond to loads fast enough. RPMs went down and AFRs went lean when windows where operated. I turned on the headlights while holding stock idle. Engine rpm went into cranking range and things got wierd. Engine stayed there even after load was taken out and did not recover, in fact stalled when i applied a little throttle. Will test taking out the 1 s brake on recalculating rpm corrections and see what happens. But that will be later.

Also here are the logs, the engine seemed to think it was off at times....

[spags]

Que se joda, la ignorancia es atrevida.

After testing the car at different rpms and tuning a bit I decided it was safe to take the car out for a drive. No video but i decided to log some of it with TS. It was not a proper test drive, just to check if TS logging works. It works mostly, missing load from the log, have to find where that's stored so I can tease it out.

Anyways, if anybody is interested here is the log. It will load up on megalog viewer but cannot track the tables since we are missing load.

Nothing broken yet

Here is the link:

Viewing with MegaLogViwer is more broken than i thought. Data can be viewed well but tracing through the maps is kaput.

[spags]

Did proper tests. Here is the data, all the trims are off. Accel enrichment is badong.

I'm going to post significant logs here in case anybody is interested.

[AndreyB]

Let me call you tomorrow, I will look into accel/deaccel stuff in the meantime

[spags]

Ok, I'l go into more details in the call. Here is the gist of it.

Last night I ran drove the car for about 15 minutes (the latest log). Not a single issue with missed events AFIK. The rev limiter works (I couldnt resist).

Re: warmup enrichment issue. The problem seems to be that the enrichment is too agressive, when I hit the throttle AFR's go way down. Still had not had the chance to sit down and pick the data apart properly. Maybe if we added enrichments (CLT, IAT and throttle) along with spark advance to the log we would get a better idea of what is happening.

Re: Rough startup. Didn't get the chance but i think it's too rich, if you look at the afrs while starting they go really low. No idea if it's an artifact of the sensor though.

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