RPM code flawed?

Post here about your Arduino projects, get help - for Adafruit customers!

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
samroesch
 
Posts: 17
Joined: Mon Feb 08, 2010 2:48 pm

RPM code flawed?

Post by samroesch »

I've been working on gathering RPM data from a 9HP Briggs and Stratton from 0-3800 RPM, and I want to see the transient response under load (basically an engine dyno)

There is lots of RPM code floating around on the web- http://www.arduino.cc/playground/Main/ReadingRPM

We're trying to read two RPMs with one arduino, using interrupts for both. We now have pretty decent code that logs RPM to the SD shield, although it took a while to figure out that enabling more than one interrupt at once was a bad idea. This leads me to wonder about a flaw in RPM code- Most code checks the value of "millis", allows the interrupt to increment a variable a few times, and then check "millis" again to get pulses/second. Doesn't an external interrupt also affect internal interrupts? The timers use interrupts to count, and so every time the Arduino receives a pulse on the external interrupt, the timer stops, and your "millis" value is wrong.

Could you calculate the number of "millis" that you missed based on the number of interrupt pulses that you receive?

User avatar
adafruit_support_bill
 
Posts: 88088
Joined: Sat Feb 07, 2009 10:11 am

Re: RPM code flawed?

Post by adafruit_support_bill »

You could avoid the whole problem and use an RTC as your time-base as on the DataLogger shield.

samroesch
 
Posts: 17
Joined: Mon Feb 08, 2010 2:48 pm

Re: RPM code flawed?

Post by samroesch »

I am actually using the logger shield in this application, but a far as I can tell, the finest resolution that it outputs is 1 second, while I'm trying to count millis or even micros.

User avatar
adafruit_support_bill
 
Posts: 88088
Joined: Sat Feb 07, 2009 10:11 am

Re: RPM code flawed?

Post by adafruit_support_bill »

The DS1307 can also be set up to put out a precise square-wave pulse. So, for example, you could set up a 1 Hz pulse and just count the rotations between pulses.

User avatar
cstratton
 
Posts: 294
Joined: Wed Sep 29, 2010 3:52 pm

Re: RPM code flawed?

Post by cstratton »

I haven't looked into the detail for this case, but in general it should be possible to engineer a system so that servicing a critical interrupt delays others, but doesn't result in their total "loss" (provided they have unique interrupt channels, and you get to them before they would occur yet again)

However, there may be a simpler answer: Does the system need to do anything else while actually measuring RPM other than keep track of time?

If not, you could use an interrupt for only one of the timer or the RPM sensor, and a well written (possibly assembly language) polling loop for the other. If the RPM pulse is wider than the duration of the timer ISR, you can look for that in the loop. Otherwise, you can set the interrupt for the RPM pulse, and poll the _count value_ of the timer counter in the loop and count when it is near overflowing and wrapping around.

Or you can interrupt on the RPM sensor and start/stop a different hardware timer after so many counts. This may require dropping the arduino environment and just programming the AVR.

To measure two RPMs, an often practical solution would be to measure them one at at time for a few revolutions each. Possibly even time just a single rotation with a fast hardware timer before switching to the other.

If you really get yourself in a corner, bare AVR chips are only a few bucks each - devoting one to each shaft would not be unreasonable.

Another thing to consider would be using a CPLD to do the low level timing and reading it from the arduino with an SPI interface. CPLD development does require a different set of programming skills though. To some extent this is comparable to using a slave avr chip, only it's easier to set it up so that querying the data from multiple slaves doesn't interfere with ongoing measurements. In a similar vein, there may be existing chips which could solve the problem in hardware.

Locked
Please be positive and constructive with your questions and comments.

Return to “Arduino”