Miata Turbo Forum - Boost cars, acquire cats.

Miata Turbo Forum - Boost cars, acquire cats. (https://www.miataturbo.net/)
-   ECUs and Tuning (https://www.miataturbo.net/ecus-tuning-54/)
-   -   PNPAdurino AFM Eliminator (https://www.miataturbo.net/ecus-tuning-54/pnpadurino-afm-eliminator-58913/)

FieldEffectDave 07-06-2011 03:57 PM

PNPAdurino AFM Eliminator
 
Broken out into a seperate thread so as not to take the Arduino ECU one too far off track.

http://www.tincannetwork.com/files/R...ntOverview.PNG

Concept is to make a "box" which takes in a MAP sensor input (and others if required) and outputs an analog signal to substitute the AFM signal expected by the NA MX5 OEM ECU.

The AFM is a vane type with a potentiometer. (anyone got flow vs voltage curve?) It is inverted, low air flow generates a high voltage, high air flow / RPM generates a low voltage.

It also appears logarithmic, the change in voltage is much greater between 2000 - 4000rpm, than 5000 - 6000rpm.


Introduction "story":

I was shown an article in a magazine where the a MAP sensor and a simple inverting op amp circuit was used to substitute the AFM for a carburettor converted MX5. (so the standard ignition system would still work)

I didn't believe it could be that simple so I wired the OEM AFM to a spare ADC on the megasquirt, did some drives and used the collected data to make a curve. This is what it looks like: (I think with some averaging / smoothing applied. I need to search for the origional files.)

EG:

http://www.tincannetwork.com/files/M...0AFM%20ADC.JPG

This is just a dumb comparative measurement based on a datalog to make a replacement curve.

The area of 15 - 25kpA is where it is too ambiguous to rely on MAP data alone, another sensor input (eg TPS, RPM, drpm/dt) is required to decide what voltage feedback is required to replicate what the AFM does.

Some additional datalogs:

http://www.tincannetwork.com/files/MAPvsAFMloads.png

http://www.tincannetwork.com/files/MAPvsAFMidle.png

http://www.tincannetwork.com/files/MAPvsAFMlowload.png

http://www.tincannetwork.com/files/M...iveoverrun.png

I am on overseas assignment in Germany, and my MX5 is in storage in Australia so I cannot make any more logfiles.

Joe Perez 07-06-2011 06:59 PM


Originally Posted by FieldEffectDave (Post 745709)
(anyone got flow vs voltage curve?)

Yeah, I did this about five or six years ago using a Greddy E-Manage Ultimate. Here's the writeup I did on it: http://miatajoe.50megs.com/

There's a complete graph of sensor voltage vs. RPM for different MAP readings, along with all the raw data behind it. Lots of other details as well.

JasonC SBB 07-06-2011 08:12 PM

I have an Arduino box that does this.
Takes 2001 cam and 12+1 crank inputs, and MAP sensor as inputs, and puts out the following:

MAF signal
factory crank signal

to feed the factory ECU so it'll do the emissions, EGR, and idle properly.


The MAF signal is a function of MAP and RPM. To do it properly, I did a 3D curve fit of the MAF signal datalogs.

FieldEffectDave 07-07-2011 03:23 AM

Thanks for that Joe!!!!!!!

http://miatajoe.50megs.com/airflow_output_map.gif

Would not be hard at all to implement this in an Arduino.

I don't quite follow the AE table on your page.

For an acceleration enrichment input, could the derivative of the MAP sensor signal be used?

Joe Perez 07-07-2011 11:38 AM


Originally Posted by FieldEffectDave (Post 746047)
I don't quite follow the AE table on your page.

For an acceleration enrichment input, could the derivative of the MAP sensor signal be used?

To be honest, I didn't spend a lot of time fine-tuning the AE table. It only took a couple of iterations to get it right.

The E-Manage did not directly support the use of MAP as an enrichment trigger- the software only allowed you to use TPS. Of course, that car (at the time) did not have an analog TPS, so I connected the output of the MAP sensor to the TPS input of the E-Manage (this was a fairly common technique), so the end result was that the MAP sensor was used, but in a non-intuitive way.

I personally believe that a true TPS signal is probably a better signal to use than MAP, since sudden throttle movements should (in theory) be reflected in the TPS signal slightly quicker than they are in the MAP signal. It takes time (albeit not very much) for the pressure inside the manifold and the tubing between the manifold and sensor to equalize after the throttle plate has moved.

Good luck with your project. Out of curiosity, may I ask why you are doing this? For my own car, I chose to rip out the entire system and replace it with a MegaSquirt as soon as the technique for doing so became commonly supported on the Miata (I was tired of being a pioneer), and I was quite happy with the result.


I love your username, by the way. Maybe mine should be Bipolar Junction Joe? :D

Reverant 07-07-2011 12:00 PM


Originally Posted by Joe Perez (Post 746182)
I love your username, by the way. Maybe mine should be Bipolar Junction Joe? :D

I don't think you should be remembered or called as "the Bi guy". May I suggest Metal Oxide Joe?

Joe Perez 07-07-2011 12:13 PM


Originally Posted by Reverant (Post 746203)
I don't think you should be remembered or called as "the Bi guy".

Heh. I didn't even think of that one.

In the US, "bipolar" means that you have a psychiatric (mental) illness which causes frequent and uncontrollable mood changes, alternating between depression and mania. In other words, a biploar person is fucking crazy (though also quite likely to be a successful artist or musician.)

http://en.wikipedia.org/wiki/Bipolar_disorder

JasonC SBB 07-07-2011 12:29 PM

Can I be "MOSFET Guy"?

Joe Perez 07-07-2011 12:36 PM

Nope. I dub thee Inductive Output Jason.

FieldEffectDave 07-07-2011 02:07 PM


Out of curiosity, may I ask why you are doing this?
My MX5 is a daily drive and I am abit paranoid. I want to move from a shared function boomslang to a stand alone setup, but I want the security blanket that if the Megasquirt smokes I can pull the carpet and swap the OEM PCM back in at any stage. And drive around on the OEM PCM until I have the time to investigate problems.

So I want this level of redundancy, and also to remove the AFM.

I guess the next question is, what happens if the Arduino AFM substitute shits itself. So long as it doesn't die at the same time as the megasquirt I will be fine. Maybe ill keep the AFM in the boot : /

blade8r 07-07-2011 07:18 PM


Originally Posted by FieldEffectDave (Post 746252)
My MX5 is a daily drive and I am abit paranoid. I want to move from a shared function boomslang to a stand alone setup, but I want the security blanket that if the Megasquirt smokes I can pull the carpet and swap the OEM PCM back in at any stage. And drive around on the OEM PCM until I have the time to investigate problems.

So I want this level of redundancy, and also to remove the AFM.

I guess the next question is, what happens if the Arduino AFM substitute shits itself. So long as it doesn't die at the same time as the megasquirt I will be fine. Maybe ill keep the AFM in the boot : /

you know i feel the same way when it comes to my car. i would like the ability to turn it back to normal if and when it does break.

the stand alone units are a cool thing when you want to go big. but i just don't want to spend $250 for a complete DIY megasquirt setup or 450 for the pnp setup. i don't want to spend that much money. i don't know what it is.. but i just don't want to sink my hands into megasquirt. i mean they make a great product. but like in the late 90's i just want to be a part of a community who came up with a program like Crome for P28's that there was for the most part a community effort. i wish we could do the same thing for our cars. our cars deserve it.

any case spending $113 for audrino or mbed makes me feel like a Jewish Diamond Smuggler who struck rich. i don't mind doing something the helps out a whole community which does including myself. that is mostly my perspective.

btw back to topic question:
should we follow the other threads group on using mbed? the other thread had already ported the code and it should function with ease. it really is a superior hardware. should we consider this hardware instead of audrino?

also push comes to shove if anyone wanted to go stand alone from the "AFM Eliminator". the base hardware is there to change over accordingly. we should have design a way where we can reflash, recode and reconfigure hardware if a person wanted to have full control.

literally we could customize the way we want to tune the car.

but i don't want to thread this thread to think that it's an obsolete idea. i am still very interested in putting a working product in my car.

FieldEffectDave 07-08-2011 05:06 AM


should we follow the other threads group on using mbed?
Depending on how fast the analog output needs to be updated, I think an mbed is overkill.

I would go for an Arduino / Atmel, maybe even an ATTINY. Built with discrete components, an onboard MAP sensor (the one MS uses is $14 from digikey) and parts scabbed from the old AFM I would aim for a $50 DIY build price.


Electronics design question:

I would probably do the D2A with a resistor ladder, maybe start with 8 bits.

I want the ground return of the D2A to use the signal ground from the OEM PCM - so there is no risk of a ground shift between our "box" and the OEM PCM causing an error in the signal voltage.

I want the Arduino / powersupply ground return to be a seperate chassis return, so the Arduino supply current is not returning through the OEM PCM signal ground.

How can achieve the ground isolation between the D2A output ground and the Arduino ground?


I was thinking of using the AFM pot supply from the PCM as a VREF - maybe divide by 2 with a low tolerance resistive divider feed into an A2D then do ratio metric scaling of the output based on this measurement. But the difference between ARduino AREF / VCC and the OEM PCM Signal output is probably going to be so small this would be a waste of time? Thoughts?

bloodline 07-08-2011 08:30 AM

This does sound like a fun project! I'll keep tabs on it and help where I can!

@blade8r while the Mbed is lovely, with loads of great features... It does cost twice as much and an Arduino and it is a 3.3volt system, not really a problem for digital parts of the system... But a bit of a pain in the wotsit for the 5volt analogues in the car :)

@FieldEffectDave, why use an DAC at all? A resistor ladder is easy to build and 8bit resolution would be sufficient for this project... But... That eats up 8 IO pins... If it was me building this I would use a single PWM output with a simple RC filter to average the voltage out :) any problems with that? (also did you get my PM?)

FieldEffectDave 07-08-2011 09:28 AM

http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Components/General%20IC/22060b.pdf


I am actually thinking something like this would be ideal.

It will isolate the Arduino ground from the AFM signal ground.
Will use the PCM signal supply - so no compensation required there if the Arduino VCC/AREF differs from the PCM Sensor supply.
Can be chosen to a similar impedance to the AFM potentiomer - which should provide good compatibility with the PCM input circuit.



also did you get my PM?
Yep. I need to get another PCM so I can run it on the bench to continue following the traces back to the uC.

bloodline 07-08-2011 09:57 AM


Originally Posted by FieldEffectDave (Post 746586)
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Components/General%20IC/22060b.pdf


I am actually thinking something like this would be ideal.

It will isolate the Arduino ground from the AFM signal ground.
Will use the PCM signal supply - so no compensation required there if the Arduino VCC/AREF differs from the PCM Sensor supply.
Can be chosen to a similar impedance to the AFM potentiomer - which should provide good compatibility with the PCM input circuit.

That's just cheating, but if it is cheaper than a cap and a resistor then it's a very good solution, and one that meets all your requirements! :)

I note that the Arduino can take an external voltage ref (as long as it's not above 5v).

Though, more components always leads to more points of failure... Something that I'm always very conscious of when designing systems.




Yep. I need to get another PCM so I can run it on the bench to continue following the traces back to the uC.
Cool :) the more I think about the Coolant temp signal, the more I'm convinced the IC blocking your path is just a comparator, the ECU knows the engine is either Hot (at working temp) or cold (below working temp).

Joe Perez 07-08-2011 12:32 PM

2 Attachment(s)

Originally Posted by FieldEffectDave (Post 746559)
How can achieve the ground isolation between the D2A output ground and the Arduino ground?

The OEM design already utilizes several separate ground return paths. On the 1.6 cars, you have:

2A: Injector ground
2B: Output ground (things like IAC and solenoids)
2C: CPU ground
2D: Input ground (sensor ground)

2A and 2B are tied together and then go to the head at Ground Point 3.

2C and 2D also tie together and hit the head at Ground Point 2. Communally, they also provide the ground path for the shield on the O2 sensor line, the shield on the AFM signal line, and the grounds for TPS, AFM (VAF and IAT, but not COR) and CLT.

(That may be the largest number of TLAs ever written in a single sentence.)

Here's the page from the '92 FSM which shows all of the relevant ECU grounds schematically:

Attachment 240909

And the drawing which shows the locations of ground points 2 and 3:

Attachment 240910

I'm not clear on the purpose of the ground at 2H. The FSM simply states that the little jumper is present in US cars, and presumably absent in Canada cars. The jumper itself is under the dash near the point where the front harness comes in through the firewall on the passenger's side, and ground point 1 looks to be just to the right of the HVAC fan. I would avoid it.

FieldEffectDave 07-08-2011 12:53 PM

Was more a question of electronic design:

With PWM + RC, Resistor Ladder etc, ... output voltage will be referenced to Arduino ground. If you tie Arduino ground to the AFM ground on the PCM then your Arduino return current will add a voltage shift / noise on the ground wire and potentially affect the measurement made by the PCM.

Its probably being over ----, but best practices would be to avoid this. Hence the digital pot makes a neat solution:

http://www.tincannetwork.com/files/P...atedGround.png

Does anyone know what the full deflection impedance of the AFM pot is?

JasonC SBB 07-08-2011 01:14 PM

FED you are overcomplicating things.

The Arduino doesn't suck a lot of current so its power supply return current can be connected to its analog output filter return, and all connected to the ECU's sensor ground. Just be sure to properly decouple the uC and any other digital circuitry locally on its board. BTDT. I used the Arduino PWM "analog" output into an opamp 2-pole lopass filter. The miata has stuff that sinks much more current into the sensor ground.

If you insist on a separate ground:

All you need to do to have a separate analog output ground is to use the Arduino PWM "analog" output to drive a small signal MOSFET which drives the lopass filter. The small signal MOSFET switch will ignore any ground offsets between the uC ground and the analog circuit ground.

I do this grounding shit for a living. I design switching power supplies. You have circuitry that switches 10A and 500V in 20 ns sitting next to ground signals with 10 mv of discrimination.

Joe Perez 07-08-2011 01:25 PM


Originally Posted by FieldEffectDave (Post 746730)
If you tie Arduino ground to the AFM ground on the PCM then your Arduino return current will add a voltage shift / noise on the ground wire and potentially affect the measurement made by the PCM.

Yes, I know. My point was that there are already a couple of ground wires set aside for low-current stuff in the factory harness, said lines already being divided up into those intended for use by the microprocessor and those intended for use by the analog signals.

I like the digital pot idea simply because a monolithic D-A converter is cleaner than some resistor-ladder combination.

I cannot imagine, however, that a teeny little arduino and the tiny little signals that it's dealing with are going to cause any kind of noise that could possibly be perceived beneath all the garbage that's already present in most of the ECU's I/O lines as a result of their close physical proximity to things like the injector wiring.

FieldEffectDave 07-08-2011 01:53 PM

Fair enough, thanks for the insights!

Just tossing around more design ideas:

Inside the PCM the Sensor supply (2K) comes straight from VCC, via this device:

http://www.tincannetwork.com/files/PCMThermalFuse.JPG

Which could be a hybrid thermal fuse + pi filter?

I put ~90 Ohms of load on the output and had the heat gun set to 120 degrees (C) aimed at the fuse and there was no voltage drop across it.

(~47ohms + 80 degrees on the gun was enough for the fuse to trip.)

So provided the circuit can stick within a current budget of say 40mA it could be powered off the sensor supply and then no additional power / ground is required and drops a few components off the BOM.

Joe Perez 07-08-2011 02:02 PM

Sounds good.

In my experience, it is always best for analog sensors (or things feeding into analog inputs) to share the same signal ground as the ECU. That way, any noise present will be perceived equally by all devices and will not result in offsets.

In the '94 and later cars, Mazda took this to the extreme and actually ran the grounds for all of the analog sensors back into the ECU itself, whereupon they loop through it and go out to actual ground.

Most of the time I see people having calibration issues with wideband O2 sensors, for instance, it's because they did what they thought was "best" and ran a dedicated ground wire for the sensor controller separate from the ECU grounds. I expect you would encounter similar problems here if you start running separate ground lines for things that really need to share a common ground potential with the ECU, no matter whether that ground potential is the same as "true" ground or not.

Joe Perez 07-08-2011 02:06 PM

Oh, one other thing- you do realize that the IAT sensor is physically located inside the AFM, right?

FieldEffectDave 07-08-2011 02:11 PM


Originally Posted by Joe Perez (Post 746756)
Oh, one other thing- you do realize that the IAT sensor is physically located inside the AFM, right?

Yep.

I pulled apart an AFM before I left Aus, when I get back I have the the Male connector and IAT waiting for me.

JasonC SBB 07-08-2011 03:33 PM

My Arduino PWM into AFM-signal mimic works fine; I DVm'ed and scoped the output voltage at the AFM input terminals and it was fine.

The lesson is that the PWM output with a filter, done right, works fine.

Joe Perez 07-08-2011 03:43 PM


Originally Posted by JasonC SBB (Post 746793)
My Arduino PWM into AFM-signal mimic works fine; I DVm'ed and scoped the output voltage at the AFM input terminals and it was fine.

Cool- didn't realize the Arduino natively supported PWM emulation of an analog signal. Can't say I do know much about them, I just don't think of them as being analog-friendly devices in the same way as, say, a Parallax chip.

What sort of time-constant did you end up with on that?

JasonC SBB 07-08-2011 04:06 PM

1 Attachment(s)
IIRC the native Arduino PWM freq is ~500 Hz, and 8 bits of resolution.

See schematic and specs:


https://www.miataturbo.net/attachmen...1&d=1310155546

blade8r 07-08-2011 10:29 PM

so if i understand this correctly in order for us to limit the amount of unnecessary I/O usage, we are going to take 5v hot Source from the stock ECU using 1 I/O pin from the AFM harness. followed by grounding the PNPAdruno directly to the Stock ECU. by dong that we can take the guess work out of grounding issues. also this would mean that the aftermarket Map sensor will be needed to be grounded at the PNPAdruno level.

sounds simple enough. besides we are going to have an even more headache needing to splice into the oem harness to get an auxiliary source rpm input from TDC sensor and CKP sensor from the CAS.

and this signal source has to be ran in parallel. someone has already written a code for rpm source already right? (those who don't know it'll have to be run parallel or a 12-1 wheel will need to be retrofitted with a sensor which will cost more money and a new code will need to created in it's place).

anyways this sounds good so far... now about those tables...

JasonC SBB 07-08-2011 10:42 PM

Writing code from stock crank or cam signals to generate RPM is easy. (no you don't need both)

As for the AFM-mimic voltage output, I used a curve fit equation, not a table. I posted the equation in another thread.

Joe Perez 07-08-2011 11:20 PM


Originally Posted by blade8r (Post 746931)
we are going to take 5v hot Source from the stock ECU using 1 I/O pin from the AFM harness. followed by grounding the PNPAdruno directly to the Stock ECU. by dong that we can take the guess work out of grounding issues. also this would mean that the aftermarket Map sensor will be needed to be grounded at the PNPAdruno level.

Are you planning to install this under the hood or inside the car near the ECU?

Fundamentally, this all sounds kosher.



we are going to have an even more headache needing to splice into the oem harness to get an auxiliary source rpm input from TDC sensor and CKP sensor from the CAS.
One vampire tap is a headache?

All you need is the CKP (Ne) signal, which is a white wire at pin 2E of the ECU, or you're under the hood, you can pick it up right at the cam sensor. This will give you a 0-5v squarewave (the stock ECU provides the pullup) with two pulses per crank revolution.

blade8r 07-09-2011 12:34 AM


Originally Posted by Joe Perez (Post 746943)
Are you planning to install this under the hood or inside the car near the ECU?

Fundamentally, this all sounds kosher.

i was planning to install the unit next to the ecu or just above the carpet level. i unfortunately have a miata that has water damage and a ecu was replaced. let me rephrase... the old owner cut the original harness leaving me with this pile of giant crap of twisted tee wired harness.

anyways it's plan on going in there.. although i plan on mounting the Map Sensor near the engine bay and I'm planning on wiring the map outside of the ecu as i think most people here want to run a tee. but that's just me.


Originally Posted by Joe Perez (Post 746943)
One vampire tap is a headache?

All you need is the CKP (Ne) signal, which is a white wire at pin 2E of the ECU, or you're under the hood, you can pick it up right at the cam sensor. This will give you a 0-5v squarewave (the stock ECU provides the pullup) with two pulses per crank revolution.

yea just forgot that your really don't need a tdc signal source to make a good rpm signal and the vampire tee.. didn't think about that.. yea eazy now.

ianferrell 07-09-2011 10:10 AM

My 2c, Just get an ms3... Then you'll have your ms2 as a spare, and we can concentrate more on making the ms-can-display project extra badass :) I just gotta find time to code, and we just had our 3rd child last night, so its going to be difficult in the short term :(

But, that said, this is a pretty cool project, there's a lotta AFM cars out there.

Joe Perez 07-09-2011 03:52 PM


Originally Posted by ianferrell (Post 747008)
I just gotta find time to code, and we just had our 3rd child last night, so its going to be difficult in the short term

I don't see the problem here. Sounds to me like the wife now has plenty to keep her busy, leaving you undisturbed to write code.

blade8r 07-22-2011 07:19 AM

hey jason sbb

is there anyway for you to post the Code of your afm mimic for your adruino.

i've looked and looked and i can't seem to find your code other then the one bloodline posted up in the other thead about the adruino standalone

i've studied as much as i can about coding these past few weeks (all this time as this thread became somewhat idle) and i learned that it's better to let the expert do the software side of things.

i got a buddy who codes for Microsoft in Seattle. Owes me a favor, doesn't know a lick of thing about cars. but I'm sure i can explain the concept of a 1.6 CAS.

anyway you could repost that equation curve of yours? I'd like to save some time instead of attempting to get it written from the ground up. so at least it's modified where it can use a 1.6 cam and rid of the excess outlet code.

JasonC SBB 07-22-2011 11:26 AM

from https://www.miataturbo.net/showpost....9&postcount=50

AFMvoltage =
1.746
+ 1.639 * RPMscaled
+ 0.6576 * MAPscaled
- 0.8774 * RPMscaled^2
+ 1.465 * RPMscaled*MAPscaled

Where RPMscaled = RPM / 7000, clipped to a max of 1
and MAPscaled = MAP / 100, clipped to a max of 1

This fits the data I gathered from my 2000 with ~1% RMS error.

JasonC SBB 07-22-2011 11:28 AM

2 Attachment(s)
Code. Spacing formatting is lost so I'll also attach the file.
Note this also generates an NB style crank trigger signal from a TSE 12+1 trigger wheel.

-------------------------------------------------------------------------------------------------

// this is to generate miata NB crank trigger pattern, 80 and 10 BTDC pulses
// and generates curve fitted MAF signal from 2.5bar Motorola MAP sensor and RPM
//from 12-1 wheel with missing tooth at 30* ATDC
//toothPeriod with 12 tooth wheel at 9000 RPM is 555u
// with 18 us per degree
// at 7200 RPM it's 694 us between normal teeth, with 23 us per degree
// at 100 RPM it's 100 ms during the missing tooth

const int CKPin_Pin = 2;
const int MAFoutPin = 3;
const int CKPout_Pin = 4;
const int CKPPinInterruptNo = 0; // this is for pin 2
const int LED_Pin = 13;
const int MAPinPin = 0;

volatile byte ATooth=0; //tooth counter, counts 0 to 12; 12th is early, extra tooth, then resets to 0
volatile unsigned long toothPeriod=0; // time between teeth
volatile unsigned long lastToothPeriod=0;
volatile unsigned long normalToothPeriod=10; // time between non-missing teeth // initialize to a large number fro startup
volatile unsigned long toothTime=0; // system micros() time when tooth passed (rising edge)
volatile unsigned long lastToothTime=0; // system micros() time when previous tooth passed


boolean LEDstate=HIGH; // temp
//boolean outputState=HIGH;


void setup() { // run once in Arduino upon reset or powerup
pinMode(CKPin_Pin, INPUT);
pinMode(CKPout_Pin, OUTPUT);
pinMode(MAFoutPin, OUTPUT);
pinMode(LED_Pin, OUTPUT);
pinMode(MAPinPin, INPUT);
attachInterrupt(CKPPinInterruptNo, edgedetected, RISING);
digitalWrite(CKPout_Pin, HIGH);
// Serial.begin(9600); // temp
}


void edgedetected() { // interrupt routine on rising edge detected on CKP input

lastToothTime = toothTime;
toothTime = micros();
lastToothPeriod = toothPeriod;
toothPeriod = toothTime - lastToothTime;
if (toothPeriod < ((lastToothPeriod)*6/10)) { // early (extra) tooth detected // try .33 and .7

toggleLED(); //temp

ATooth = 12; // force to 12; it will be 12 anyway if it's in sync
// toothTime = lastToothTime; // undo toothTime assignment
// toggleLED();
; //
}
else { // regular tooth gap, or just after extra tooth
ATooth++;
if( (ATooth) > 12 ) {

ATooth = 0; // when it reaches 13, cycle around to 0;
normalToothPeriod = toothPeriod + lastToothPeriod;
} else normalToothPeriod = toothPeriod; // we just passed a normal tooth gap
}
/* Serial.print(ATooth,DEC); // temp
Serial.print(" ");
Serial.print(normalToothPeriod,DEC);
Serial.print(" ");
Serial.println(toothPeriod,DEC); // temp */
// if ( ATooth == 10 ) {
// Serial.println("it's 10");
// digitalWrite(CKPout_Pin, LOW); // temp
// }
// if ( ATooth == 11 ) {
// Serial.println("it's 11");
// digitalWrite(CKPout_Pin, HIGH); // temp SOMEHOW this one doesn't work, it doesn't toggle
// }
}

int MAP;
unsigned long temptoothPeriod;
unsigned long MAPscaled;
unsigned long RPMscaled;
unsigned long MAF;

// re: doMAF() which calculates MAF voltage.
// MAP input (analogRead()) reads 0-1023 for 0-5V. Freescale 2.5bar MAP sensor equation is Vo = 5*MAP/250 - 0.2
// or analogread result = 1023*(MAP/250)-41
// large equation below is written for MAPscaled and RPMscaled to be 4095 (12 bits) full scale
// returns MAF value which is 0-255, written to PWM output, which produces 0-5V
// orig curve fit eqn is:
// MAFvoltage = 1.746 + 1.639 * RPMscaled + 0.6576 * MAPscaled - 0.8774 * RPMscaled^2 + 1.465 * RPMscaled*MAPscaled
// where MAF ranges from 2~4.6V (when MAP is 20~100 kpa and RPM is 500-7000), and RPMscaled = RPM/7000 and MAPscaled=MAP/100
// the large equation has been carefully ordered to maximize precision without overflow
// eval of all equations (not including analogRead and analogWrite) takes ~100 us.
// If I use shift right instead of divide/2^n is saves about 20 us
// analogRead() adds another 100 us and analogwrite() perhaps 20 us.

void doMAF() {
MAP=analogRead(MAPinPin);
temptoothPeriod = constrain(normalToothPeriod,715,10000); // limit RPM range for use in equation, to 500-7000 rpm
MAP = constrain(MAP,41,367); // limit MAP to 20~100 kPa
RPMscaled = 2925714 / temptoothPeriod; // 7000 RPM is 1023
MAPscaled = ((unsigned long)MAP+41)*10; // 100 kPa is 1023
MAF = (1430 + 1342*RPMscaled/4096 + 539*MAPscaled/4096 - RPMscaled*RPMscaled/4096*719/4096 + MAPscaled*RPMscaled/4096*1200/4096)/16;
analogWrite(MAFoutPin, MAF); // default settings is ~490 Hz PWM, accepts values 0-255
// toggleoutput();
}

unsigned long itIsTime=0;
unsigned long tempToothTime=0;
boolean pulsed80_na=false; // flag if 80* BTDC pulse is has already been outputted
boolean pulsed10_na=false; // flag for 10* BTDC
boolean MAFout_na=false; // flag if doMAF() has been executed already

void loop() { // main Arduino loop

if( ATooth==1 || ATooth==7 ) { // 80* BTDC pulse, begins 17* after tooth 1 and 7, 3* wide
if(!pulsed80_na) {
tempToothTime = toothTime; // store toothTime in temp var bec toothTime is volatile

itIsTime = normalToothPeriod *17/30 + tempToothTime; // calculate when 17* later is
while( micros() < itIsTime); // do nothing until 17* have passed; micros() returns how many microseconds elapsed since powerup
digitalWrite(CKPout_Pin, LOW);

itIsTime = itIsTime + normalToothPeriod/10; // 3* later
while( micros() < itIsTime); // do nothing for 3*
digitalWrite(CKPout_Pin, HIGH);
pulsed80_na=true;
}
} else { // not tooth 1 or 7
pulsed80_na=false;
}

if( ATooth==3 || ATooth==9 ) { // 10* BTDC pulse
if(!pulsed10_na) { // 10* BTDC pulse, begins 27* after tooth 3 and 9, 3* wide
tempToothTime = toothTime; // store toothTime in temp var bec toothTime is volatile
itIsTime = normalToothPeriod *27/30 + tempToothTime; // calc time when 27* is; normal tooth period is 30*//
// note: this will fail if it wraps around (70 minutes)
// if( itIsTime < micros() ) { // it wrapped around
// while(itIsTime < micros() ); // wait til micros() wraps around too
// }
while( micros() < itIsTime);
//while( micros() < itIsTime && (ATooth ==3 || ATooth==9)) ; //do nothing until required 27* time passes or tooth comes early
// note if next ATooth arrives we'll be >= 3* behind but that's OK
digitalWrite(CKPout_Pin, LOW);
// if( ATooth==3 || ATooth==9) { // tooth didn't increment early
//itIsTime = toothPeriod + tempToothTime;
// } else { // Atooth came early
itIsTime = itIsTime + normalToothPeriod/10; // 3*
//}
while( micros() < itIsTime);
digitalWrite(CKPout_Pin, HIGH);

// toggleoutput();
pulsed10_na=true;
}
} else { // not tooth 3 nor 9
pulsed10_na=false;
}

if( ATooth == 1) { // just don't do it before or after extra tooth , let's calc MAF output .... once very rev; may want to add qualifier for doing it only every 100 ms or so
if(!MAFout_na) {
doMAF();
MAFout_na=true;
}
} else { // not tooth 10
MAFout_na=false;
}
}

FieldEffectDave 10-30-2011 11:57 AM

1 Attachment(s)
Could anyone with an AFM (89 - 93 flappy potentiometer style) help me out with some ballpark measurements of the connector?

http://www.tincannetwork.com/files/AFMConnector.PNG

https://www.miataturbo.net/attachmen...ine=1319990257

http://miatajoe.50megs.com/afm.gif

I want to pick up a little hobby box for this project whilst I am still in Germany, but I don't have an AFM connector / car to measure for a size reference.


All times are GMT -4. The time now is 10:21 AM.


© 2024 MH Sub I, LLC dba Internet Brands