Reading Frequency, Pulse Width, etc. with Various Square Wave Inputs

[1slickvdc]

Another project, this time I'm making a "drive monitor" thing for my car, which includes one of those fancy MPG meters among other things. I've got the math worked out on how I'm going to read the info to get the stuff I need to calculate and output the desired information. My thing is that I'm having difficulty trying to figure out the best way to read frequency, pulse width, etc. from the ECM with my Arduno. All the signal waveforms are square waves, although not all are 5V. Some not only vary in frequency, but duty cycle/pulse width. I've also got a small Cyclone II FPGA I can use as well if need be to help handle the logic/counting. Most, if not all, of these signals are extremely low frequency, Some even single digit Hz depending on conditions. I haven't seen much go more than a couple KHz, if that.

I've already looked through libraries that already exist for Arduino, but none are suitable for something that's not a 50% duty cycle or something that varies so wildly in frequency/cycle. The ECM can do something with that, obviously, so I just need a hand figuring out how to make it a bit more user- and controller-friendly. Ideas using the Arduino and the FPGA are both welcome. Wouldn't mind the experience in Verilog or VHDL either, but I think this stuff is just too slow to be of any practical use on that... although I could and may be completely wrong.

Thanks!

[vk6zgo]

Another project, this time I'm making a "drive monitor" thing for my car, which includes one of those fancy MPG meters among other things. I've got the math worked out on how I'm going to read the info to get the stuff I need to calculate and output the desired information. My thing is that I'm having difficulty trying to figure out the best way to read frequency, pulse width, etc. from the ECM with my Arduno. All the signal waveforms are square waves, although not all are 5V. Some not only vary in frequency, but duty cycle/pulse width. I've also got a small Cyclone II FPGA I can use as well if need be to help handle the logic/counting. Most, if not all, of these signals are extremely low frequency, Some even single digit Hz depending on conditions. I haven't seen much go more than a couple KHz, if that.

I've already looked through libraries that already exist for Arduino, but none are suitable for something that's not a 50% duty cycle or something that varies so wildly in frequency/cycle. The ECM can do something with that, obviously, so I just need a hand figuring out how to make it a bit more user- and controller-friendly. Ideas using the Arduino and the FPGA are both welcome. Wouldn't mind the experience in Verilog or VHDL either, but I think this stuff is just too slow to be of any practical use on that... although I could and may be completely wrong.

Thanks!

Well,to "nit pick",only 1:1 mark/space ratio (50% duty cycle) ones are "square waves".
The rest are "rectangular waves".

Yes,there is a difference---when you express them mathematically,some terms cancel out in the square wave form,making it a simpler expression.
It is 30 years since I did this crap,& I don't know where to find the appropriate reference anymore.

[Rerouter]

Simplest way, close to how I approached an automotive counter in the past,

You have 3 levels of interrupts you can make use of, 2 dedicated pins, and a maskable pin change interrupt,

Use the 2 pins for your fastest signals, as they can be defined as rising falling or changing

Then a quick little interrupt that reads the micros timer to get you both duty and frequency, (a change interrupt will trigger on rising and falling)

Then for the other signals use the general pin change interrupt, only on the pins you care about, capture a snapshot of the pins, and use that to figure out what pins changed, compared to the last snapshot, and a timer value to know the frequency or duty.

Note the interrupts do not stack, so you will want some averaging to account for missed pin changes,

[dadler]

How old is your car? If it's not ancient, it will probably be much more robust to interface via the OBDII connector with a CAN bus transceiver. Then you can access a ridiculous quanitity of engine runtime information.

[1slickvdc]

How old is your car? If it's not ancient, it will probably be much more robust to interface via the OBDII connector with a CAN bus transceiver. Then you can access a ridiculous quanitity of engine runtime information.

It's a 2001, and luckily it's a Subaru, so I've got the likes of RomRaider and FreeSSM, however, many of the PID's used for the MPG calculation are not available. Partially because I've got one of the FIRST of the H6-3.0 engines, and in with that are all sorts of nasty things that the later models or same year H4's don't have problems with or have in their computers. For example, the formulas out there now all use MAF in combination with other things, and I don't have a MAF sensor, let alone the PID to feed. This thread for example: http://www.romraider.com/forum/viewtopic.php?f=3&t=1219 contains information to add MPG calculations to your interface. The thread is old and that fake PID is now included standard in the program. However, it disappears once it reads my ECU because some of the requisite PID's aren't there, like the MAF.

I also suck at and hate dealing with serial communication (one is likely because of the other), otherwise I could just pull the PID's I know I have, like the ones I'm currently trying to use the "hard way", and can math it up from there. Hell, the guys who wrote the software I use when I'm diagnosing or monitoring the car with my laptop even spilled the guts to the SSM system: http://www.romraider.com/RomRaider/SsmProtocol ... I still have no idea how to use that information.

[Sal Ammoniac]

Does the AVR on the Arduino have timers with input capture capability? Input capture is commonly used to determine the frequency and pulse width of digital signals, as long as the frequency of the signal is less than half the frequency of the timer clock.

[dadler]

An Atmega328 has a single input capture channel, but if you need to sample multiple simultaneous signals you could use a mux and switch between signal sources. You can easily use the ICP to measure frequency and duty cycle in this fashion. It's attached to 16bit timer1.

[dadler]

App note: http://www.atmel.com/images/doc8014.pdf
Sample code: http://www.atmel.com/images/AVR135.zip

I used the above code as a starting point when I developed the fuel pump PWM driver for my Subaru.

[1slickvdc]

Quick one since I'm on the move and since its a critical difference: I'm using a Mega2560.

[dadler]

Quick one since I'm on the move and since its a critical difference: I'm using a Mega2560.

The same code works, you just have more pins and channels. The Mega2560 is the same architecture with just "more" of many things. Just read the datasheet. If I remember correctly, the Mega2560 has 3 or 4 capture channels.

[xtoffer]

Quick one since I'm on the move and since its a critical difference: I'm using a Mega2560.

The same code works, you just have more pins and channels. The Mega2560 is the same architecture with just "more" of many things. Just read the datasheet. If I remember correctly, the Mega2560 has 3 or 4 capture channels.

The AVRs are rather flexible on this as well. The input capture unit can normally be connected to the built-in analog comparator which in turn can use the ADC multiplexer for one of its inputs, for even more possibilities. But yeah the 2560 seems to have plenty ICP pins all on its own.