home register FAQ memberlist calendar

Go Back   Turbobricks Forums > Mechanical > performance & modifications > aftermarket engine management

Reply
 
Thread Tools Display Modes
Old 05-05-2021, 09:47 PM   #26
142 guy
Board Member
 
Join Date: May 2014
Location: Saskatchewan, Canada
Default

Quote:
Originally Posted by VB242 View Post
I know Toyota COPs have a feedback wire that are used to detect misfires, not exactly sure how, perhaps a piezo sensor in the COP?
Cars have have one of two misfire detection systems, or both. One looks at crankshaft speed fluctuations and the other monitors ignition coil output voltage. I have an Acura and it has two complete sets of P codes for misfires, one triggered by the signal (or lack of signal) from the ignition coil , the other triggered by monitoring the crankshaft speed. The Acura I have has COPs; but, they are passive COPs and the misfire monitoring circuit is just a voltage divider that generates a voltage pulse when the ignition coil fires. That pulse goes to an external misfire detection module which generates a conditioned signal for the ECU. The ECU initiates a spark trigger for the coil and probably waits for the signal from the misfire detection module to confirm that the coil did fire. If there is no confirmation signal it probably sets a P code. That system will only detect misfires caused by an ignition failure, not misfires cause by a fuel mixture problem or other problems. The crankshaft speed monitor will pick up misfires due to all causes, including stuff that are not legitimate misfires if the software is set too sensitive.
142 guy is offline   Reply With Quote
Old 05-07-2021, 08:01 AM   #27
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

Quote:
Originally Posted by bobxyz View Post
I thought I was close to done, but then realized that the Leonardo/32U4 microcontroller has NO hysteresis on the input pins, plus weird input voltage levels. The original Uno/328P boards have reasonable input hysteresis and levels. Without the hysteresis, the inputs will be _very_ sensitive to the slightest electrical noise. I'm really surprised that Arduino would pick a chip without any input hysteresis for hobbyist use. WTF were they thinking.
I'm using an Arduino Mega 2560 but from the manual also the Atmega16U4/32U4 have Schmitt triggers on digital inputs (see chapter 13.2 Ports as General Digital I/O)
https://ww1.microchip.com/downloads/..._Datasheet.pdf



In the while I've totally destroyed my board and rebuilt it using diodes to clamp the spikes and some LM339 comparators instead of optoisolators to change the voltage level. For the analog signals I still used OpAmps powered at 5V + some filters.
At the bench it works but I'm still not yet satisfied, infact I'm worried by the LM339 sinced it doesn't like negative voltages lower than -0.3V, and this is less of what I can cut using diodes.
Also the input impedance it's driving me crazy since I would like to have it much grather as possibile but this is in conflict with the need to have a good voltage precision (especially with OpAmps that handle analog signals for ECT, AMM, O2 sensor and battery voltage).
I started with resistors of 1MΩ but now I'm using only 10kΩ in series with the input pins of both OpAmps and Comparators thanks the high input impedance of OpAmps and Comparators.

I'm better studing it and the "Application design manual"...

Yesterday evening I wrote my first code that uses pin change interrupts and registers and it worked (I had also to fix the conflict with my code that was due to the dependency to the library SoftwareSerial that I don't use at runtime), now that I learned how it works it is easy, but the code is much more cryptical to read since it requires to enter more deeply into the hardware

In the next days I will rewrite also the other signals handling routines and I will made some measures to see how much is faster than digitalRead()...

This is the new code to measure injectors pulse width:



...

// PCINT16 alias PK0 alias A8

// Configure PCINT16 as an input using the Data Direction Register K (DDRK)
DDRK &= ~_BV(PCINT16);

// Disable the pull-up resistor on PCINT16 using the Port K Data Register (PORTK)
PORTK &= ~_BV(PCINT16);

// Enable pin change interrupt on the PCINT16 pin using Pin Change Mask Register 2 (PCMSK2)
PCMSK2 = _BV(PCINT16);

// Enable pin change interrupt 2 using the Pin Change Interrrupt Control Register (PCICR)
PCICR |= _BV(PCIE2);

// Enable interrupts
sei();

...

ISR(PCINT2_vect) {
unsigned long enterTime = micros();
uint8_t injectorPinStatus = PINK & _BV(PINK0); // Read PK0 using the Port K Pin Input Register (PINK)
if (prevInjectorsStatus != injectorPinStatus) {
if (injectorPinStatus) {
// injectors off
if (lastInjectorsActivationMicros > 0) {
injectorsTonMicros = enterTime - lastInjectorsActivationMicros;
}
lastInjectorsActivationMicros = 0;
}
else {
// injectors on
lastInjectorsActivationMicros = enterTime;
}

prevInjectorsStatus = injectorPinStatus;
}
}



...

Last edited by apollokid; 05-07-2021 at 05:35 PM.. Reason: rewritten initialization registers code to be more readable
apollokid is offline   Reply With Quote
Old Yesterday, 02:11 PM   #28
142 guy
Board Member
 
Join Date: May 2014
Location: Saskatchewan, Canada
Default

I am a clumsy C programmer; but, my understanding is that time functions should not be used within the ISR. In your ISR, you are initializing entertime using the micros() function. The micros() function returns the number of microseconds since the board started running the current code. The information I recall is that when called within an ISR micros() can provide erratic results once the operating time exceeds 2 milliseconds.

Since I have never tried using micros() within an ISR, I don't know what the nature of this erratic behavior is. If the problem is that it returns a time with an error of a few microseconds that may not be significant when evaluating the accuracy of the injector pulse width. Perhaps you are aware of the micros() problem and have determined that is not a problem for what you are doing.

I didn't check explicitly; but, it looks like you have dealt with the micros() overflow problem.
142 guy is offline   Reply With Quote
Old Today, 05:25 PM   #29
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

I think is not a problem of be a great C/C++ programmer, is to have a deep knowledge of the arduino architecture.
The micros() function relies on an HarwareTimer and HarwareTimers throw a software interrupt every time they run into overflow to increment a counter (necessary to know how much time has elapsed from the boot).
I think that using micros() inside a ISR could suffer problems if called more times since if the HarwareTimer runs into overflow between one call and the other the second call will return a time that precedes the one returned by the first call since the counter increment will be deplayed after the ISR ends.
If micros() is called only once at the beginning of a fast ISR I don't think it could be a real problem.
I was better reading the documentation and one problem using micros() is that on most arduino boards it has a precision of 4μs and this could explain why, also after having rebuild my interface using comparators instead of optoisolators, the minimum pulse width of a Tq pulse I can measure is still approx to 10μs.
May be that modifying the prescaler of the timers it is possibile to improve the precision but before doing a such thing I have to study much better the consequences since the timers are used also by other functions and/or libraries.
Consider that I'm still learning day by day new things about arduino and I could change my point of view in the future, but I also have to say that to measure injectors pulses (or engine rpm) the micros() function inside a ISR seems to work fine (and also for measuring the Tq signal, also if with a moderate precision). For other signals like IAC or vehicle speed I think that a ISR is not the proper solution and I believe that it could be better to call pulseWidth() with a short timeout inside a polling loop (the same to sample analog signals).
apollokid is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On

Forum Jump


All times are GMT -4. The time now is 07:37 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.