home register FAQ memberlist calendar

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

Reply
 
Thread Tools Display Modes
Old 04-20-2021, 04:41 PM   #1
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default Arduino LH Jetronic interface: live data + MicroSD logging + ELM327

Hello everyone, my name is Diego and I live in the north of Italy. I recently posted a question in this forum about the reverse engineering of the Tq-signal that the LH Jetronic send to the EZK.
I've immediatly found some users interested when I described the project on which I'm working on and I was invited to open a new topic to create a place where to talk about and to share tech information and experiences.

Since it's impossibile to query the live data from the LH-Jetronic of my Volvo 945 I decided that I could try to build an interface that, acting like a network sniffer, decodes all the I/O signals directly through the control unit connector using my DIY breakout-box.

This is a picture of the board in the state it is today:


The project started last summer when I decided that it was the time to learn something about this Arduino who talk everyone. Today it's still under development and some parts are yet missing but the board is already usable for some tests and it is in a state that is much more than a proof of concept.

The board is divided in 3 main layers:
  • 12V car layer: here I put all the circuitry that is powered by the battery of the car. Here is where I put active filters, resistos, OpAmps and anything I need to drive the led of the optoisolators. I've also used some microswitches to be able to enable/disable each single signal without disconnect any wire.
    I still have to add an overcurrent protection circuit (a couple of fuses it could be the minimum)
  • Optoisolators layer: here I put the optoisolators (now I'm using both the 4N35 for the digital signals and the HCNR201 for the analog ones)
  • Arduino layer: here I put all the 5V circuitry from the transistors of the optoisolators to the input pins of the Arduino board

The Arduino board I used is an Arduino Mega 2560 since it supports 6 interupt pins and many digital and analog input pins plus the following shields:
Here some screenshots of the GUI I've designed with a brief description of the available functions:


Injection screen


  • Ton is the pulse time of injectors
  • Tq is the engine load (yet under reverse engineering, at the moment I read the raw pulse width in μs)
  • rpm is obvious
  • λ is a graphical tool that shows the deviation from λ=1 (stechiometric mixture), it uses a configurable lenght circular buffer to calculate a mobile avarage plus the voltage produced by the oxigen sensor
  • hummer is when engine is knocking (yet under reverse engineering)
  • switch is the idle switch on the throttle body
  • IAC is the PWM of the idle air valve that measures the opening %


Cooling system


  • 1 Fan: show when radiator fan is active at low speed
  • 2 Fans: the same at high speed
  • ECT voltage: voltage of the ECT sensor but I support the LH doesn't read a voltage but a current that I could measure using a breakout-box
  • ECT temperature (at the moment I use a quadratic interpolation function base on the voltage but I don't think that is too much precise)


Oxigen sensor


  • Media mob. (in english mobile avarage): is the configurable lenght in seconds of the samples
  • n. camp. (in english number of samples): report how many samples are in the circular buffer
  • The λ % indicator reports for how much time the mixtures was rich or lean
  • Oxigen sensor voltage
  • Same λ graphical tool of "Injection screen"


Tachimeter


  • Giri (engine rpm)
  • VelocitÓ (vehicle speed)
  • Nice To Have: instant fuel consumption, must be measured the opening and closing latency of the injectors with a scope or by consulting a tech paper (more documentation is need)


ELM327 Emulator



Report the status of the bluetooth ELM 327 emulator.
At the moment I support only the following PIDs but I want to supports as many as I can.
  • 010C engine rpm
  • 0105 Engine coolant temperature
  • 0114 Oxygen Sensor 1
  • 0D Vehicle speed (incomplete)

For this feature I made a derivated work from the library GTTurboEcu since the orginal version works only with SoftwareSerial and I had found some random hangs when the rpm signal that I was reading using interrupts changed quickly.
So I added the support to HardwareSerial too by introducing an abstract layer interface and in this way I solved all my problems.
NOTE: I've tested it only with Torque on Android but it may also work with other compatible scanners


MicroSD real time data logger



To be implemented.
I've some ideas to be developed, for example I could create the commands to start/stop the logging and to choose which signal include or the max leght of each recording.
I was also think at a injection map reverse decoder (by only driving the car it could be relative easy to rebuild the real injection map also without accessing to the memory of the control unit and it could also be possibile to measure the deviation (min vs max) of injectors pulse width that could help in diagnosys (for example in the case of a roughly engine)
Any suggestion here in usefull features is really appreciated.


Setup



To be implemented
For example I would like to add i18n support


That's all
I hope to finish the board within this year but I don't have none that runs me back so I will take all the time I need.
Anyway I'm curious to start testing it on the car (at the moment I tested it only on my desk using a signal generator and a DIY injectors emulator that I build using a fuel relay drived by a Darlington transistor with a zener 60V diode as overvoltage protection to replicate as much as possible the same waveform of the real injectors)
Finally I will return to work on the software Kikad becasue It could be fantastic to get a PCB and collapse this large prototype board into a little device that stays in the palm of one hand.


Opss... I was forgetting to share you at least one picture of my DIY breakout boxes.
Without them and the my friend Picoscope 2204A this project could be really hard to carry on, if not impossibile.
Here more pictures hoping they could be useful to someone: https://photos.google.com/share/AF1Q...lMZVRiMExMek9R

apollokid is offline   Reply With Quote
Old 04-21-2021, 07:50 AM   #2
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

Hi Diego, Wow, you've done a lot of work! Very nice.

A couple years ago, I started to work on a similar project to monitor LH2.4+EZK using a simple Arduino board. I wanted
- a dashboard Multi-Gauge LCD display for use while driving, and
- full speed logging for offline tuning and graphing

At the time, I was only monitoring the EZK signals, plus a Wideband O2 input and a MAP pressure sensor input. This is what my benchtop setup looks like, with a couple different displays (click pictures for bigger size).







The items shown are:
- RPM
- Load - the width of the ECU Tq Load signal in microseconds (proportional to injector on time)
- Vbat - battery voltage
- Idle - the TPS idle switch
- DegF - the coolant temperature, currently the raw ADC value, not yet converted to degrees
- AFR - Wideband O2
- Spk - spark advance in degrees
- Dwel - spark dwell time in milliseconds
- KpA - input from MAP pressure sensor (currently connected to pot for testing)

For testing, I have a LH2.4 ECU and a EZ116K connected with a chopped off harness to a simple engine simulator board. The switches are for some of the sensors (temperature selects 3 resistors -- normal, hot, cold), and the one knob is for the MAF (or AMM) voltage. RPM (60-2 wheel signal) is from my Hantek oscilloscope pattern generator.


To connect to the EZK signals, I soldered wires to the connector pins inside the box. I think this will work in the car, but it's not pretty.


After working on the project for a while, I ran into some problems:
- The Arduino Nano that I was using didn't have enough pins to monitor EZK+ECU and support a LCD display
- Updating the LCD display (over SPI) was much slower than I liked.
- The LCD library (Adafruit GFX) occasionally glitched when sharing the Arduino with my interrupt-based measurement code. I think this is a common problem for Arduino libraries, that they don't work well with other interrupt based libraries.

I got busy with other projects and this one has been gathering dust for at least a year. With your inspiration, I've started to work on the project again.

Instead of using a single Arduino to do everything, I want to change the architecture to use 2 Arduinos. One would do all the measurements and only use a simple serial port interface. This can be connected to a Bluetooth module for logging and display on a PC or smartphone. If I can figure out the protocol, and there are not any legal issues, it would be nice to support TunerStudio or MSdroid software applications. For the in car dashboard multi-gauge, a 2nd Arduino and a small LCD display would be used, with a serial interface to the 1st Arduino.



I need to work through the available pins on an Arduino Pro Micro (32U4) to see if they can monitor all the ECU, EZK, and extra signals that I want. I'll post a pin usage proposal when I'm done.

In Italy, what hobbyist PCB companies do you have access to? There are a couple Chinese companies that are now offering PCBs plus assembly with common surface mount parts. Can you get PCBs from jlcpcb.com or seeedstudio.com?

-Bob
__________________
'85 245glt b21ft aw71 k-jet -> lh2.4
bobxyz is offline   Reply With Quote
Old 04-21-2021, 10:12 AM   #3
esmth
Board Member
 
Join Date: Jul 2016
Location: MA/NH
Default

Very impressive, both of you. Definitely farther than I have gotten, mine is really only CLI software running on a laptop. I am especially jealous of those neat bread/perf boards. Mine always turn into jumbled messes.

I need to make me one of these bench setups to run LH and EZK out-of-car. My volvo is my second office!

It is news to me that the 'TQ' signal is proportional to injector open time. That is good to know.

For the OLED/LCD UI in the past I have used u8g2. I think it only supports mono screens but it is very lean and configurable. It leaves plenty of CPU time and memory for other things. I do like the idea of dual MCU boards with one being the data sampler and the other being the displayer/logger. Lots of room to grow

I am not a laywer but I think one can get around the fcc/radiation legal issues by just not including the bluetooth by default. Just let the end user source the bluetooth module separately and plug it in.
__________________
1991 244 LH2.4 M46 352k miles

Last edited by esmth; 05-10-2021 at 10:17 AM..
esmth is offline   Reply With Quote
Old 04-21-2021, 05:53 PM   #4
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

For the moment I didn't find flickering problems with the display but I'm using only 2 interrupt pins to read rpm, injectors pulse and Tq but may be I will need a third interrupt so I will have to find a solution.
My idea was to connect each digital signal to its own digital pin on the Arduino board and connect also each of these signal to an OR logic gate which output activates the interrupt pin.
The interrupt routine then should read all the digital pins of a port and then check each single bit in order, from the one with the hightest priority to the lowest.
It should not be a complex circuit in my opinion, and if the logic gate is sufficiently fast I believe that it should works.

For PBCs, I made only one little PCB in my life and for producing it I've used the jlcpcb.com service.
No SMD, only through hole components. Price and quality are very good in my opinion.
apollokid is offline   Reply With Quote
Old 04-22-2021, 04:41 AM   #5
Swedbrick
Board Member
 
Swedbrick's Avatar
 
Join Date: Oct 2016
Location: Netherlands, Source of Grolsch
Default

To chip in on the DIY PCB making, I've made several and prints through jlcpcb. SMD soldering is doable at home, just make sure you get thin solder, tweezers and a smaller soldering iron tip. I got a Velleman VTSS230, those also come with a hot air side so you can quickly reflow components to pull them into the pad nicely
__________________
Volvo 745 - IPD springs, 25mm/19mm swaybars, K-cam, LH2.4, M90 swap, 3.54 \w racingdiff lsd, track/daily
-------------------------------------------------------------------------------------
I sell LH2.4 Chips for Europe!
Swedbrick is offline   Reply With Quote
Old 04-22-2021, 08:06 AM   #6
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

Glad to hear that you can use jlcpcb.com. That makes it easier for anyone to order boards directly, instead of my needing to figure out customs and international shipping.

I was going to use KiCad, but I think we should try the online EasyEDA.com tools instead. I just setup an account at oshwlab.com so we can share design files. I've never used either of these before, so I hope they work well and have a high quality library of PCB footprints. It will be a learning experience.

My eyesight and nerves make surface mount assembly and rework challenging, but jlcpcb can do small volume SMT assembly with common parts. Are you OK with surface mount resistors/capacitors/diodes on the initial prototype boards? Probably 0805 and SOT-23 sizes (but I'll use bigger if jlcpcb has them in their common parts library). Or would you prefer all through hole so that you can assemble/modify it yourself?
-----
I'm still looking at the pin assignments for the Arduino. I'd like to monitor these signals:
- EZK: Vbattery, RPM, ignition, load, temperature, idle switch, knock enrichment
- ECU: MAF, injection, VSS (vehicle speed), IAC (idle air - optional?)
- Other: wideband 02, MAP pressure

Anything else I should try to include?
bobxyz is offline   Reply With Quote
Old 04-22-2021, 03:10 PM   #7
Swedbrick
Board Member
 
Swedbrick's Avatar
 
Join Date: Oct 2016
Location: Netherlands, Source of Grolsch
Default

Quote:
Originally Posted by bobxyz View Post
I was going to use KiCad, but I think we should try the online EasyEDA.com tools instead. I just setup an account at oshwlab.com so we can share design files. I've never used either of these before, so I hope they work well and have a high quality library of PCB footprints. It will be a learning experience.
I've used EasyEDA before, the installable version works well, however tends to force you to use their parts warehouse, which can lead to some interesting parts number variations. Especially transistors and small logic chips tend to have different pinouts on smd variants, so beware. Their routing software is great and the design rule checker is also accurate. It takes a bit to get used to how to use via's and create ground planes, but hey, it's free

SMD soldering does require a steady hand, I mostly stick to 0603 and 0805 for hand work. 0402 is doable, 0201 is insanity. This board is mostly 0603, with SOIC pin spacing, and done by hand in around 30m. I designed it in easyEDA and ordered through JLCPCB, to give an idea of the SMD quality.



A set of small tweezers and a ESD safe work area are very good tools to get for smd work, as the components are more delicate both in mechanical and electro static damage Also stuff like cleaning of small tin balls and flux become more significant, so for a first prototype through hole is probably a good option if you don't want to invest a lot initially and have space to debug.
Swedbrick is offline   Reply With Quote
Old 04-22-2021, 09:38 AM   #8
Wobsmangbaffler
Newbie
 
Join Date: Nov 2020
Default

How are you measuring the car speed? I am currently doing a similar project but it is only for measuring the speed of the car, and not inputs from LH / EZK.

The technique I used was:

- Take sine wave signal from rear axle

- Filter through a full bridge rectifier to make it all positive voltage

- Use capacitors to smooth the pulsating signal into a smooth voltage level

- Use analogread() to measure this average voltage, which correlates to vehicle speed

Does LH have a different way of measuring vehicle speed?

Interested to know!
Wobsmangbaffler is offline   Reply With Quote
Old 04-22-2021, 09:46 AM   #9
esmth
Board Member
 
Join Date: Jul 2016
Location: MA/NH
Default

Quote:
Originally Posted by Wobsmangbaffler View Post
How are you measuring the car speed? I am currently doing a similar project but it is only for measuring the speed of the car, and not inputs from LH / EZK.

The technique I used was:

- Take sine wave signal from rear axle

- Filter through a full bridge rectifier to make it all positive voltage

- Use capacitors to smooth the pulsating signal into a smooth voltage level

- Use analogread() to measure this average voltage, which correlates to vehicle speed

Does LH have a different way of measuring vehicle speed?

Interested to know!
if I recall, the VSS sensor in the diff produces an AC voltage that is wired to the cluster speedo/odo. Inside that there is a UAF2115 chip which converts the AC frequency to a open collector signal that LH weakly pulls high and counts when it is pulled down. It'd probably be best if you counted this post processed signal instead of trying to process the AC voltage yourself. The AC from the sensor is pretty high, I have measured over 90 volts from it with a high impedance meter.
esmth is offline   Reply With Quote
Old 04-22-2021, 02:40 PM   #10
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

If you're talking about a 240 with an electronic speedometer, then yes, a pre-processed and filtered VSS signal is easily available. The filtering circuits are on the speedometer PCB. The signal goes to the ECU as part of the 9-pin or 11-pin cabin/gauge connector that joins the engine harness near the ECU/EZK. Check your wiring diagram, but it's normally a blue-black wire. The signal also comes out the back of the cluster to 2 side-by-side spade tabs just to the left of the speedo housing.

On the face of the speedo should be a K10042 or K41068 number, or something close. The 10042 or 41068 is the number of rear axle pulses per mile. The pre-ABS cars use a 12-tooth differential pickup; ABS cars use 48-teeth. You can lookup the revs/mile online for your tire size, and multipy by 12 or 48, to get the Kxxx number. The speedo in the ABS cars divides the rate by 4 so that the VSS signal to the ECU is always for 12 pulses per axle rev.

As esmth said, the signal uses an open collector driver with a pullup resistor in the ECU. It will swing between ~0volts and ~13volts (IIRC). You can use a simple resistor divider to drop it down to 5volt logic levels (keep the combined resistance over ~20K to avoid distorting the signal still going to the ECU). You'd then want this to drive an interrupt pin, with a tiny bit of code that increments a counter on each pulse.
bobxyz is offline   Reply With Quote
Old 04-25-2021, 01:02 PM   #11
142 guy
Board Member
 
Join Date: May 2014
Location: Saskatchewan, Canada
Default

Quote:
Originally Posted by apollokid View Post
Thank you very much 142 guy for your reply.

The only things that I was able to understand is that zeners has some capacitance that slower the fall of square edge and diodes in general affect the speed of the magnietic field collapsing due to the recirculation of current inside the coil.
Since I was unable to determine how much energy must be released when the injectors close (and since my snubber circuit could have interfered with the electronics of the car) I decided that optoisolators could be the safer way.
I was too much scared to make stupid things and to damage something due to my poor experience.

You told me that you find problems using optoisolators for your tach and cam wheels on my MSII installation. Can you explain me better why?
A 12 tooth crank wheel and at 6000 rpm means a frequency signal of 1200Hz, before writing this reply I retested my 4N35 (that is not classified as a fast optoisolator) to see its performances and what you say is true, optoisolators start to distort the signal when frequency rises but up, but at 5kHz the signal shape, also is not perfect, is yet near accettable in my opionion.


The other signals I had to sample are all at a lower frequency, eg. at 6000 rpms the rpm signal is at 200Hz frequency, and also the speedometer reaches 300Hz at 210km/h so it should be not a problem so I decided to use near the same system for al digital inputs.

The only signal that starts to beacame a problem is Tq-signal since I measured it and is in the range of 20Ás to 240Ás (on my car) and so near the limits of the 4N35 that has 10Ás of switching time. Also the way I used arduino is near its limits since I use interrupts with multiple digitalRead() that take near 5Ás for each execution.
For this reason I started to read the ATMega manual beacause I want to learn something about hardware Timers (all new thing for me, and not so easy to learn) to find a better way to take the measure of these short pulses.


About using of Schmitt triggers to clip spikes from rectangular signals seem a good idea, did you tried it?
All the things I've red about this type of comparators with hysteresis were only to square a sine signal but thinking about it they should also remove spikes that go outside the supply voltages (in theory also a standars comparator and may be also a simple BJT transistor used in bjt saturation/interdiction region)

A final question that scares a little to me: how is easy to lead IC to latch-up with spikes, especially after having connected the GND of the car to that GND of arduino? This is for me yet a dark area of knoledge but is another of the reasons for which I thinked that to keep a galvanic isolation between the circuit of the car and the circuit of arduino was a good idea.
First off, I did not mean to imply that you should not use opto isolators. Its just that you need to be aware of the frequency limitations. It seems like you are already aware of those problems so you should be able to apply the opto isolators correctly. I did a couple of posts about 4 -5 years ago in the Turbobricks Aftermarket Engine Management forum discussing the potential problems with the 4N25 opto isolators as used in MSII. I included waveform captures showing the signal distortion. MSExtra uses the cam 'tooth' to define the next tach tooth as the first tooth. You have the option of defining the tooth edge as the rising or falling part of the signal. The 4N25 opto isolator distortion was not the same on the rising and falling edge of the signal. I did a quick search; but, I am not able to find those posts that I did. However, I think my point at the time was that by picking the correct edge for triggering you could eliminate the impact of the distortion and it worked fine. Also, that it probably would not work if you used something like a 36 tooth wheel. As long as you are aware of the limitations then you can make use of the opto isolator.

As an observation, if you want to pick up engine speed or the output ignition timing by sensing the voltage on the negative terminal of an ignition coil, the opto isolator circuit as used in MSII would provide an excellent circuit for conditioning the input and on a normal B230 the switching frequency is well within the response range of the 4N25.

As a suggestion, if you want to pick up the duration of the injection pulse, the injectors are controlled by a power transistor or a power MOSFET. Why not measure the base or gate signal to the switching device? The base or gate signal will typically be at the logic level for the EFI controller (5 volts or 3.3 volts ??). It should be a clean signal and I expect that the input impedance to the Arduino is high enough that it will not affect the output drive current from the EFI controller significantly. The drive current on an opto isolator would probably be higher than the additional current being sunk into the Arduino. The datasheet for the ATMega should specify the input impedances. If you want isolation you could install a really high impedance op amp in voltage follower mode between the EFI controller and the arduino.

My experience with Schmitt triggers is primarily in debouncing on input contacts. The schmitt has two output levels, logic low and logic high which is what the arduino wants. You do need to respect the voltage limits on the schmitt trigger hardware so if you expect high voltage transients so you may still need to protect the input. Obviously the schmitt is restricted to cleaning up digital inputs only.

Input voltage protection could be as simple as a filter capacitor which filters out high frequency transients with a zener or perhaps a MOV if you think you have something really nasty. You are correct that zener diodes have junction capacitance; but, in reverse voltage mode the junction capacitance for low wattage diodes is typically less than 1000 pF which is likely not going to be a problem for lower frequency signals. The dual diode arrangement that Swedbrick shows for analog input voltages is excellent because it limits signal excursions to the magnitude of the supply rail voltages plus the Vfd of the diode. The supply rail will have some internal source impedance so the limiting will not be perfect.

Are you trying to use digital reads to capture high speed events? I am not a skilled C coder; but, I think the preferred way to do that is to attach an external interrupt to a digital pin and when the event occurs set a flag in the interrupt service routine. The main code uses the flag to start a timer (timers generally do not work in the ISR). Better yet to use hardware timers; but, those require more skill / knowledge as you are discovering. If you want to capture a leading and trailing edge on a pulse you may need to use two separate interrupts because you need to specify whether capture occurs on going high or going low. There are some interrupts that allow you to capture going both high and going low; but, you don't know which so you don't know whether it is start of pulse or end of pulse. As I recall the Arduino Uno only supports external interrupts on two pins which may or may not be sufficient for your use. The Teensy 3.2 has 23 pins that can be assigned as digital inputs and I believe all of them can be assigned as interrupts. The Teensy 3.2 also allows overclocking up to 96 Mhz which should eliminate any speed limitations. Of course, you could try the Teensy 4.x family which allow overclocking up to 912 Mhz - who needs coding elegance when you can just turn up the boost screw on the turbocharger! The Teensy 3.2 and 3.5 are 5 volt tolerant so if your ECU is 5 volt you can do digital interfaces directly. The other Teensy products are 3.3 volt only so you need to get into level shifters.

I have never experienced latch up so I can't help you. If you are logging real time data on the Arduino, I would connect the the electrical ground for the Arduino as close as possible to the ground for the ECU. I would also take the + supply for the Arduino from the same supply as the ECU. The best solution would be to make the + supply and ground connections right at or as close as possible to the board in the ECU. This eliminates problems with differential signals appearing caused by inductive or galvanic coupling into the separate ground or supply paths to the two devices.

Last edited by 142 guy; 04-25-2021 at 01:10 PM..
142 guy is offline   Reply With Quote
Old 04-25-2021, 07:18 PM   #12
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

Quote:
Originally Posted by 142 guy View Post
Are you trying to use digital reads to capture high speed events? I am not a skilled C coder; but, I think the preferred way to do that is to attach an external interrupt to a digital pin and when the event occurs set a flag in the interrupt service routine. The main code uses the flag to start a timer (timers generally do not work in the ISR). Better yet to use hardware timers; but, those require more skill / knowledge as you are discovering.

I'm not a skilled C++ coder too, previous time I used it was at university near 25 years ago. I used interrupts to measure times, this is how I read injectors pulse width and is pretty easy:



void LHJetronicDataReader::injectorsSignalChange() {
unsigned long enterTime = micros();
int injectorSignal = digitalRead(INPUT_PIN_ECU_INJECTORS_SIGNAL);
if (injectorSignal == HIGH) {
// injectors on
lastInjectorsActivationMicros = enterTime;
} else {
// injectors off
if (lastInjectorsActivationMicros > 0) {
injectorsTonMicros = enterTime - lastInjectorsActivationMicros;
}
lastInjectorsActivationMicros = 0;
}
}


and this is for rpm and Tq together:

void LHJetronicDataReader::tqSignalRise() {
unsigned long tqPulseWidth = 0;
noInterrupts();
unsigned long enterTime = micros();
while (tqPulseWidth <= MAX_TQ_MICROS) {
if (digitalRead(INPUT_PIN_ECU_TQ_SIGNAL) == LOW) break;
tqPulseWidth = micros() - enterTime;
}
interrupts();
tq = tqPulseWidth;

unsigned long currentRpmSignalRisingMicros;
unsigned long pulseDuration;
// to-do: dopo circa 70 minuti micros va in overflow e riparte da zero
currentRpmSignalRisingMicros = enterTime;
pulseDuration = currentRpmSignalRisingMicros - lastRpmSignalRisingMicros;
// un impulso ogni scintilla, ogni 2 impulsi un giro completo dell'albero motore
engineRpm = ONE_MINUTE_MICROS / pulseDuration / 2;
//Serial.println((String) "Last: " + lastRpmSignalRisingMicros + "\nCurrent: " + currentRpmSignalRisingMicros + "\nRPM SPEED: " + rpmSpeed + "\n");
lastRpmSignalRisingMicros = currentRpmSignalRisingMicros;

//Serial.println(totalTime);
}




If you whould like to see the whole C++ class that read the measures:

LHJetronicDataReader.cpp
When I will learn hardware timers probably I will rewrite this code.


For optoisolators... I'm yet undecided if it worth to totally aband them.
I'm testing the flowwing circuit based on tips I learned these days using an emulated injector that has the same 60V spike when the signal rises, the circuit seems to perform very well and it can goes up with frequencies without the limits of optoisolators and to maintain a perfect square waveform also at 15kHz and above.
Furthermore, thanks to the high impedance input it can be used without modifications also for any other 12V digital signal.
As you can seen I didn't cloned as-is the circuits posted by Swedbrick; I'm a stubborn and until I don't understand why only a 10kΩ can be used I preferer to continue to decouple with a voltage follower using a high impedance to minimize as much as possibile the load.
So why I'm still undecided? Because I found 2 or 3 times a spike that goes out of the 0-5V range, and one of them was -2V and I was unable to replicate it plus your observation on GND.
Quote:
Originally Posted by 142 guy View Post
If you are logging real time data on the Arduino, I would connect the the electrical ground for the Arduino as close as possible to the ground for the ECU. I would also take the + supply for the Arduino from the same supply as the ECU. The best solution would be to make the + supply and ground connections right at or as close as possible to the board in the ECU. This eliminates problems with differential signals appearing caused by inductive or galvanic coupling into the separate ground or supply paths to the two devices.
I have to say you that this conflicts with my "project requirements": I whould like that the arduino interface could be connected throughthe same D-SUB connector I've on my break-out box and since it will have near 1m meter of cable the GND will not be as closed as possibile.
A solution could be to remote with the cable only the LCD screen and the keypad, will it be sufficient?

EDIT: I've made a mistake in circuit diagram, I will redraw it

Last edited by apollokid; 04-26-2021 at 02:47 AM..
apollokid is offline   Reply With Quote
Old 04-26-2021, 11:08 AM   #13
142 guy
Board Member
 
Join Date: May 2014
Location: Saskatchewan, Canada
Default

The digital read may work if the event timing is relatively slow compared to the clock speed and you don't have many other code steps going on in the main software loop. As an example, if injectorSignal goes HIGH just after you execute "int injectorSignal = digitalRead(INPUT_PIN_ECU_INJECTORS_SIGNAL); " you won't capture the state change until the next time you run through that part of the code loop. If the software loop is small and the clock speed is high you may be able to go through the main loop fast enough that the timing error that occurs may not be large. However, the problem is that you will never know about the error. You would need to hook up an oscilloscope to the injector signal at the same time that the Arduino is logging the pulse duration and compare the oscilloscope results to the Arduino log to confirm the accuracy.
142 guy is offline   Reply With Quote
Old 04-26-2021, 11:54 PM   #14
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

Sorry, I haven't had as much time as expected to work on this project in the last few days, and haven't had time to fully follow all the recent discussions.

I'm still planning on using simple RC circuits, and a couple high-speed switching diodes for inductive clamps, to monitor the EZK/ECU signals. I'd like to keep the added loading on the EZK/ECU signals to only ~10uA to ~50uA, or ~200K ohms to 1M ohm (definitely high impedance). I need to trace the EZK Tq/Load signal driver to see if higher loading can be used since it's the fastest signal of the bunch. I also need to trace the IGN driver because I'd like to measure exact ignition advance, and may need lower RC delay for the desired accuracy.

For grounding, the Arduino board needs to connect only to ground in the EZK, or only to ground in the ECU. Any other connection may add a bad ground loop that might affect normal engine control.

For high speed timing measurements in the Arduino, you need to setup custom PCINT PinChangeINTerrupt code. This will trigger an interrupt routine whenever the logic level of one of the enabled pins changes. The interrupt routine then needs to keep track of the previous and current state to figure out which pin changed.

Here's what I have for the older IGN setup/interrupt code:
Quote:
[in setup section]
// Setup high speed digital inputs
pinMode(4, INPUT); // IGN sparkAdv

// Setup interrupt handlers for high speed signals: rpm (tach), vss, load, inj, spark
PCICR |= 0x04; PCMSK2 = 0x10; // IGN: pin D4, PCINT2_vect (D0-D7)

[in interrupt routine section]
//********************Interrupt Service Routines***********************
// For good info on setting up interrupts, including the pin change interrupts that aren't
// directly supported by the Arduino library, see: http://www.gammon.com.au/interrupts

// Interrupt Service Routine for pin D4, IGN input, PCINT2_vect (D0-D7)
// - enabled via direct interrupt register config in setup() section
// - triggers on both edges of IGN signal
// - Dwell is pulse width
// - Advance is updated here using falling RPM signal edge captured by RPM ISR

ISR(PCINT2_vect) // Pin change interrupt for pins D0-D7 (only D4 enabled)
{
boolean edge;
unsigned long edge_time;

// get interrupt edge and current time
edge_time = micros();
edge = digitalRead(4);

// Measure ignition dwell time as rising to falling pulse width (coil changes when signal is high)
// Measure ignition advance as previous falling RPM edge to falling ign edge
if(edge) {
ign_rise_edge = edge_time;
} else {
ignPeriod = edge_time - ign_rise_edge;
ign_fall_edge = edge_time;
advance = edge_time - rpm_fall_edge;
ign_int_flg = true; // set flag to indicate new ign dwell and advance measurements
}
ign_ints_processed++;
}
I'm still looking at the Arduino capabilities and how to monitor all the signals. I think it will work well, and that I can possibly leave the I2C SDA/SCL pins unused if someone wants to use them for expansion in the future (such as the Sparkfun Qwiic interface).
bobxyz is offline   Reply With Quote
Old 04-28-2021, 01:14 PM   #15
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

@bobxyz: When you were talking about PinChangeINTerrupt I was thinking you were meaning about the https://github.com/NicoHood/PinChangeInterrupt library but from your snipplet I've understood that you are talking about a different thing and you want to use directly the registers.
I've not written yet any code that uses them but I read something about and I agree with you that could be the right method to get more interrupt enabled pins. (This is the link to the article I'm talking about: https://thewanderingengineer.com/201...ge-interrupts/)
In your snipplet I saw that you have used the function digitalRead() to read the status of a single pin, digitalRead() is not too much fast and if used to read the status of many pins inside the ISR its delay could became an minor issue. Do you have already searched for a faster way? It should be possibile to read the status of a pin reading the whole port as a byte and applying on it a bitmask instead of using digitalRead().


@142 guy: I don't understand what you mean with As an example, if injectorSignal goes HIGH just after you execute "int injectorSignal = digitalRead(INPUT_PIN_ECU_INJECTORS_SIGNAL); " you won't capture the state change until the next time you run through that part of the code loop.
Did you thinked that the function injectorsSignalChange() is called from the main loop as a polling?
No, both injectorsSignalChange() and tqSignalRise() are ISRs and not normal functions.
Since injectorsSignalChange() is an ISR is impossibile that the injectors signal falls down and rises up again in less than 5Ás (or a bit more), also when engine is at idle the pulse width of the injectors is near 2000Ás.
The slownes of the function digitalRead() is a limit in measuring very short pulses width with high precision but I don't think that is this my main problem to solve.
Infact I've better re-analyzed the Tq signal recordings I took two weeks ago with my oscilloscope and I found another issue.
I was thinking that the pulse of Tq and injectors were always in sync, in other words I was thinking that:
- at t0 injectors pulse signal falls down
- at t0 + approx 130Ás Tq pulse signal rises up
- at t0 + 130Ás + 20Ás...250Ás Tq pulse signal falls down
- at t0 + 2000Ás...8000Ás injectors pulse rises up
This is wrong because when the rpm and load increases the sync of the two signals change and there are situations when there is an overlapping.
For example the injectors signal could fall down when the Tq was yet high and according to my code the call to injectorsSignalChange() will be delayed until tqSignalRise() ends. I found also that also the sync of the Tq rise changes.
If I had more interrupt pins availabe I would never have calculated the rpms from the count of the Tq pulses instead of the rpm pulses and above all
written a busy wait inside an ISR. I did it to quickly test the performances of the optoisolator and believing that it could works, after all also the pulseIn() function do a similar thing to measure a pulse length.
This could drive to an error in the measure of the injectors pulse that could reach up to 250Ás and is not acceptable.
Pin Change Interrupts, as suggested by bobxyz, could help me to rewrite the code and to fix the problem, but I whould also to find the alternative to the digitalRead() function.


A bit off-topic: I also would like to add the the ignition advance measure, but I'm dreaming a totally different way from getting the crank signal from EZK. I believe that it could be possibile to detect the TDC by analyzing the AMM signal oscillations and I want to take more scope measures using AC coupling to better study it.
May be that it will drive me to dead-end road, but a few years ago I made a similar experiment using my oscilloscope and I was able to measure the ignition advance with a reasonable precision looking the current oscillations produced by the alternator that can show you when the piston reaches TDC and BDC (when there is the piston stroke the current produced is a bit more since the cranck shaft is accelerating, on the opposite, when the piston is compressing the crankshaft slow down a bit)
Also the air mass is not a continuosus flux but if you are able to zoom the signal just enough you can see that is alternating, in sync with the pistons that suck the air. One of the most difficult thing in doing this is that the amplitude of the signal changes not only with the load but also with the rpms as you have seen I'm a novice in designing electronic circuits.
apollokid is offline   Reply With Quote
Old 04-30-2021, 12:59 PM   #16
142 guy
Board Member
 
Join Date: May 2014
Location: Saskatchewan, Canada
Default

I had not read your code and had read into your comments that you were using the digital read inside the main loop. If you are doing the digital read inside the ISR then you have eliminated the timing issue that I raised.

A comment on your idea about using the AMM signal to detect TDC. I don't have any experience with AMM devices, just MAP sensors. With a common plenum intake manifold the pressure fluctuations pretty much disappear once the engine speed is above 1500 RPM. During engine cranking the cylinder filling events are very easy to spot; but, once the engine fires and comes up to idle speed it would be very difficult to reliably identify the cylinder filling events. Even when the cylinder events are easy to spot I think it would be difficult to get a precise measurement on TDC. The magnitude of the fluctuations will depend on the volume of your intake plenum with a smaller volume making the measurement easier.

If you have a high tooth count wheel on the crankshaft (36 tooth would be ideal) at idle it will be very easy to pick up the engine speed variations that occur at idle. I can do this with what is the equivalent of the 12 tooth wheel that I have. I have never checked to see what the speed variations look like as the engine speed increases because the stored energy in the flywheel increases which tends to smooth out the variations. Clearly a 36 tooth would be better than a 12 tooth wheel. OBDII compliant ECUs use crankshaft speed detection to detect individual cylinder misfires so it would appear to be possible; but, a complete misfire probably results in a much larger speed delta than that caused by the compression of the intake charge. That said, OBDII crankshaft speed misfire detection systems are a little notorious for their reliable signal measurement and to avoid false error codes typically require 3 detection events in a trip before they will trigger the CEL continuously.

I believe that Saab's Trionic engine management package used their ion sense cylinder pressure management system to detect #1 TDC firing in place of a cam position sensor; but, I don't believe that they used it as a precision measurement (exactly TDC).
142 guy is offline   Reply With Quote
Old 05-04-2021, 07:29 AM   #17
VB242
Beep beep zip tang
 
VB242's Avatar
 
Join Date: Sep 2011
Location: The Right Coast
Default

Quote:
Originally Posted by 142 guy View Post
I had not read your code and had read into your comments that you were using the digital read inside the main loop. If you are doing the digital read inside the ISR then you have eliminated the timing issue that I raised.

A comment on your idea about using the AMM signal to detect TDC. I don't have any experience with AMM devices, just MAP sensors. With a common plenum intake manifold the pressure fluctuations pretty much disappear once the engine speed is above 1500 RPM. During engine cranking the cylinder filling events are very easy to spot; but, once the engine fires and comes up to idle speed it would be very difficult to reliably identify the cylinder filling events. Even when the cylinder events are easy to spot I think it would be difficult to get a precise measurement on TDC. The magnitude of the fluctuations will depend on the volume of your intake plenum with a smaller volume making the measurement easier.

If you have a high tooth count wheel on the crankshaft (36 tooth would be ideal) at idle it will be very easy to pick up the engine speed variations that occur at idle. I can do this with what is the equivalent of the 12 tooth wheel that I have. I have never checked to see what the speed variations look like as the engine speed increases because the stored energy in the flywheel increases which tends to smooth out the variations. Clearly a 36 tooth would be better than a 12 tooth wheel. OBDII compliant ECUs use crankshaft speed detection to detect individual cylinder misfires so it would appear to be possible; but, a complete misfire probably results in a much larger speed delta than that caused by the compression of the intake charge. That said, OBDII crankshaft speed misfire detection systems are a little notorious for their reliable signal measurement and to avoid false error codes typically require 3 detection events in a trip before they will trigger the CEL continuously.

I believe that Saab's Trionic engine management package used their ion sense cylinder pressure management system to detect #1 TDC firing in place of a cam position sensor; but, I don't believe that they used it as a precision measurement (exactly TDC).
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?
__________________
Quote:
Originally Posted by 240240 View Post
I'm shocked someone actually took me seriously.
VB242 is offline   Reply With Quote
Old 05-05-2021, 09:47 PM   #18
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-04-2021, 11:12 PM   #19
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

I'm making progress on the design, but am not quite there yet. Here's what the schematics look like currently (click for bigger):


For the initial boards, I picked a 15-pin Dsub connector to bring the EZK/ECU signals onto the board. A short wiring harness then splits this into 2x 9-pin connectors, 1 for EZK and 1 for ECU/extras. The resistor/capacitor/diode circuits in the schematics are about right, but the exact component values may change. I also expect to move some of the port assignments around once I get to layout.

The latest choice for an Arduino is a Leonardo 16MHz 5volt 32U4 board. I think I can fit all the Monitor circuits onto a daughterboard (aka shield) of about the same size if I use SMT parts (assembled by JLCPCB).

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.

At this point, I'm trying to decide if I want to go back to a Uno/328P Arduino that has better noise immunity but doesn't include the 2nd serial port, or if I should just add an external schmidt trigger buffer chip to the schematics and move on.

Let me know if there are any [brief] questions or comments. If anyone is interested in more direct access, I think I can setup a Group on easyeda.com and add others to the project (you'll need to setup an account and PM me your user name, or maybe email).
bobxyz is offline   Reply With Quote
Old 05-07-2021, 08:01 AM   #20
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 05-08-2021, 02:11 PM   #21
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 05-09-2021, 05:25 PM   #22
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
Old 05-09-2021, 08:23 PM   #23
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

Status: I'm still looking at options to use an Arduino Leonardo 32U4 cpu with external buffer circuits to give good hysteresis and noise tolerance. I want to stay with the 32U4 so that I can use a hardware serial port for the HC-05 Bluetooth board. It's not a max baud rate issue, but I don't trust the standard "software serial library" to work well with my extra interrupt code. Writing good and glitch-free interrupt code can be difficult, and I've seen problems sharing interrupts with common LCD graphics and CAN bus libraries.

Hysteresis: The some of the Atmel/Microchip AVR datasheets included graphs of hysteresis, some don't. Without a graph, you can still infer the hysteresis from the charts of Vih and Vol levels (see Pin Threshold section). The Uno 328P datasheet shows ~500mV of hysteresis (Vih,typ - Vil,typ), which gives good noise immunity. The Leonardo 32U4 shows only ~25mV, which gives almost no noise tolerance. Your Mega board's 2560 cpu has ~400mV of hysteresis, which is good.

More Status: I've pretty much given up on the option of having a 100% thru-hole PCB -- the added signal buffering takes too many parts. I'm hoping that the JCLpcb SMT assembly has high quality because I really struggle with any SMT work. The latest plans are to use dual 5v schmitt trigger buffers, 74LVC2G17 in a SOT-363 pkg, with +/- clamp diodes to provide hysteresis and level-shift the inputs. You can get dual series schottky barrier diodes in a SOT-323 pkg (BAT54SWT), so there should be plenty of room. For the initial PCBs, I'd like to use the UNO/Leonardo R3 shield form factor. I think this will plug onto your Mega board too (but you may need some jumper wires because some of the pin change interrupts are on different pins).

Clamping undershoot: To clamp signals with a minimum voltage difference, look for a "schottky barrier diode". These will typically clamp at a bit less then 0.3v at low currents. I forget the common thru-hole part numbers.

Interrupts: Once you're comfortable with the pin-change interrupts, you can use them to measure any pulse parameters directly. After you're setup and understand how to measure one pin, the rest are just slight modifications. Besides, I'm not sure if the pulseIn() function will play nicely with other interrupt-driven code.

Micros(): I forget where I found the documentation, but the micros() function should be fine to use within an interrupt routine. There might be problems if you have very long interrupt code. If it's too long, your routine has disabled interrupts, and the micros() code can't execute its counter rollover interrupt code until your routine is done.

Normally, you don't want to add any unmatched sei() interrupt enables to your main code. Generally, if you need interrupts disabled in main code, you do a: cli(); ; sei(); . Remember, the Arduino environment is already using interrupts (for timing and for serial) and that you need to share nicely.
bobxyz 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 05:03 AM.

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