Measuring time between pulses (10 - 5000 milliseconds inbetween)

NickeA

Hi!

I'm trying to build a fuel consumtion monitor for my power boat. I´m planning to use a flow sensor that gives 2500 pulses per liter of petrol that passes through it. My problem is finding a way to measure the frequency of the pulses since there may be anything from 10 milliseconds between the pulses (pushing the Chevy V8 hard) to perhaps 2-5 seconds between the pulses (engine idling).

option 1 - using COUNT to count the number of pulses during one second or so wont work since there will be so few pulses per second (less than one in the very low end) that the accuracy will be low.

option 2 - using PULSEIN to measure the time between the pulse wont work in the low end either since the function times out already after 131 milliseconds.

How would you guys solve this?

BR / Nicke

Mike Green

You're going to need some kind of external circuitry to help with this. For counting pulses, consider EMESystems' CT515. To get the timing right, consider using a RTC chip like the DS1302. SparkFun has a breakout board for the DS1307 which uses the I2C protocol. This can be used with a BS2, but requires a lot of code to handle. The BS2p/pe/px Stamps have built-in statements for I2C which makes this easy to use.

You could also use an external counter with a BS2, reading the count a couple of times a second using a PAUSE for timing. If the count hasn't changed, you just wait to check again. If the counter overflows, use a COUNT statement. You'd need to ignore some readings when the fuel consumption is changing rapidly.

stamptrol

To avoid missing pulses while the Stamp is elsewhere in the program, use an external counter chip. The flowmeter pulses are counted directly by the counter and when the Stamp is ready, it queries the counter, gets the number of pulses then resets the counter.

Knowing the time between readings, all consumption calculations can be done.

A 4024 binary counter is a possible choice. You wouldn't need to take all the outputs into the Stamp. Just enough to cover the pulses accumulating between readings, say 4 or 5 bits.

Cheers,

NickeA

Thanks for your responses. Since hardware isn't my strong side I´ll start by trying to find a sensor with more suitable specs.
BR / Nicke

Sapphire

What is your desired update frequency for the display? If you only need to see an update once every 5 seconds, then COUNT would still work for you. Just COUNT for 5 seconds, and you get a result. Even at the highest consumption, you wouldn't overflow a Word result. As Mike said, you'll lose accuracy during rapidly changing consumption, but any counting method, either in hardware or software, will not be able to overcome that with a fixed count window. So give it a try and see how the numbers look.

Tracy Allen

Another approach to timing a long interval is a program loop. The Stamp is single threaded, no interrupts or things going on the background. So the time it takes to execute a loop is constant and dependable. Here is a snippet...

[SIZE=1][FONT=courier new]CycleTimer:
  t1 = 0   ' a word variable to count time high
  t0 = 0  ' a word variable to count time low
  DO : LOOP WHILE in0  ' wait for pin to be low
  DO : LOOP UNTIL in0  ' wait for pin to be high
  DO : t1 = t1+1 : LOOP WHILE in0   ' time pin high
  DO : t0 = t0+1 : LOOP UNTIL in0    ' time pin low
  cycleMs = (t1 ** factor1) + (t0 ** factor0)  ' calculate total milliseconds
  RETURN
[/FONT][/SIZE]

The ordinary BASIC stamp can execute the inner DO:LOOPs at over 1000 per second, but it will be a bit different for the high and the low. The factors at the end are chosen to make each part and the total come out in milliseconds from rising edge to rising edge. The calibration step takes a bit of effort and a source of 1Hz square wave, but it can be pretty good once done.

More comments at this URL, old pre PBASIC 2.5. The last snippet there includes a timeout in the loops, so they don't get stuck if the process being monitored comes to a dead stop.

I developed the CT515 to deal with exactly this kind of problem. It is even more acute with things like rain gages and anemometers, which cover a wide range of frequencies down through sub-Hz to a complete stop.