Timing and counting

jrhons

I'm trying to use the BS2 to count pulses and sync them in real time with a 555 timer. Can I use the COUNT command twice to count clock pulses at the same time as input pulses or will it execute one then the other? Any other suggestions on how I can do this?

Franklin

How do you plan to control the 555 timer?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

Mike Green

The Stamps can only do one thing at a time. If you execute a COUNT statement, the Stamp just counts pulses on one pin and doesn't continue with the next statement until the counting period is over. What are you trying to do and how fast/short are the pulses?

jrhons

I'm trying to make a bike computer. I haven't been able to test the rpm sensor yet so I haven't been able to condition the signal yet. The idea, though, is to count pulses and match them with a timing circuit to be able to compute speed (and distance).

Amaral

why do you have to match the pulses with a timing circuit ?

to comand Count itself is already an counter over a period of time .

Amaral

jmalaysia

If your plan with the 555 timer is to create a reference clock then you really don't need it. I'm not sure you want to use COUNT instead of just monitoring a pin for a transistion, assuming the rpm sensor is nothing more than a switch that opens or closes once per revolution. You can measure the time between pulse inputs and convert it to actual speed in the program. You might consider averaging the previous few readings with the current reading to get a more stable output. Wheel circumference/time between pulses would give you feet/sec. You will probably have to calibrate it for accuracy. For distance, each pulse would represent one wheel revolution, so distance is pulses X wheel circumference. You could calculate the average mph either periodically or with a button press.

Zoot

Somebody said...
You can measure the time between pulse inputs

That would actually be very tricky on a Stamp w/o some external reference that is slow enough for the Stamp to check regularly. Otherwise you have to measure actual time through your "main" loop and see how long it takes. And every code change will prob. change the time through the loop. And that's not even accounting for cases where the actual code executed is longer or shorter (due to if/thens, select/case etc).

Let's say your external timer (555 pulses) is 20hz (every 50ms). "Scanning" for pulses might go something like this:

TimerPin PIN 0 ' to external reference clock (pulses)
Timer VAR Word ' the "count"

MainLoop:
  IF TimerPin ^ Timer.BIT0 = 1 THEN Timer = Timer + 1 ' increment timer only on "change" of pulse state 
                                                                                  ' -- doubles effective resolution so timer would be in 25ms "ticks"

  ' rest of your code here, remember if you want to catch every "edge" of the pulsetrain, the rest of the code needs to execute in less than 25ms
  GOTO MainLoop

P.S. -- at this kind of resolution, the Word Timer will "rollover" at about every 27 minutes...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Phil Pilgrim (PhiPi)

If you're using a magnetic pickup (i.e. Hall-effect sensor or reed switch), you might be able to infer the instaneous speed from the width of each pulse, using a PULSIN (assuming bounce is not an issue). This would give you plenty of time between pulses to do other things. There are some variables you'd have to deal with (e.g. the distance of the magnet on the spokes from the pickup) that may affect pulse width. But this could be calibrated out from time to time by comparing the pulse width with the time between pulses.

-Phil

Zoot

Somebody said...
comparing the pulse width with the time between pulses

How would/could he get that time on a Stamp w/o an external reference or timing/measuring instruction execution time? RCTIME occasionally to count some kind of average "low" time between pulses?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Phil Pilgrim (PhiPi)

Zoot said...
How would/could he get that time on a Stamp w/o an external reference or timing/measuring instruction execution time?

Instruction execution loops, once calibrated, are reliable. I don't see an issue there.

-Phil

jmalaysia

Me either. And just for reference, a 27" bike tire travelling just under 10mph would toggle a sensor every 500msec, so we're not talking long intervals.

Zoot- a section of code like we're talking about takes a fixed amount of time to execute a loop. As you said, each time you modify the loop code it affects the final result of the counter nested in the loop. However, when you are finished and happy with your program, you just put a line in (outside the counting loop) to calibrate the counter with reality.

jrhons

OK. A couple more questions.

Zoot, how does your code work to catch a rising edge? I'm a PBASIC newbie (this is my first forum thread too) and I'm not exactly sure what your sample code is doing. Specifically "TimerPin ^ Timer.BIT0 = 1".

And Phil, once polish my loop off, how do I measure its execution time?

jmalaysia: How would I include the calibrating code INSIDE the loop so I can continually update the time and speed as I go?

By the way, thank you all for your input thus far!

Zoot

^ = XOR = eXclusive OR

In a XOR, the result is "1" only if the two bits ARE different:

0 : 0 = 0
0 : 1 = 1
1 : 0 = 1
1 : 1 = 0

It's a way of having the counter count up only when the state of the input (the pulse edge) changes, even if it gets sampled more often than it changes. But this kind of schema wouldn't necessarily be relevant if you "manually" time your main loop instead, as PhiPi suggests.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Phil Pilgrim (PhiPi)

jrhons said...
How would I include the calibrating code INSIDE the loop so I can continually update the time and speed as I go?

Okay, it looks like you've thrown another measurement into the mix: elapsed time, in addition to speed and distance. That complicates things quite a bit. For speed and distance you only need to know the execution times of those short sections of code where you're actually measuring something. For elapsed time, you'd need to know how long every section of code takes to execute under all conditions. That's well-nigh impossible. If you really need elapsed time, I suggest you add a real-time clock chip like the DS1302. That would make the speed computations easier, too.

-Phil

jrhons

Thanks Phil. I think you're right. Guess I'm ordering some more peripherals....

jmalaysia

I think you're misunderstanding what I mean by calibration. The calibration is only used to adjust the counted value to an epected value.

For example:
EX1:

time=0
DO
time=time+1
IF sensor=1 then count=time
LOOP

EX2:

DO
time=time+1
IF... THEN
IF... THEN
IF... THEN
IF sensor=1 then count=time
LOOP
(the IF... THEN's are just for example)

If you ran both loops for and equal period of time EX1 would result in a higher "count" because EX2 has more going on inside the loop, making it take longer to execute.

Let's say we ran each loop for 1 second (simulating 60rpm), with EX1 giving a count of 500 and EX2 giving a count of 400. You have to convert that to speed for it to be useful, right? So a count of 500 in EX1 would be 60rpm, whereas in EX2 a count of 400 would be 60rpm. You just make a little math equation after the loop to convert it to speed. Since you're the only one that knows the wheel size I can't do that.

This will give you the instantaneous speed of the previous wheel revolution. It would update pretty fast so because the wheel is spnning faster than I originally thought, somewhere over 400rpm for 35mph. I think it is something like 12 rpm per mph (for a 27"), so it might be stable enough to read on a display. What I'm trying to say id that if you are rolling right on the threshold of the next mph digit your display might be switching back and forth between digits faster than you can read it. At 35mph (427rpm) it would get a pulse every 140ms. I use 35mph because that is the fastest I would go on my bike before the fear of imbedding road in my face took over at that point!

Phil Pilgrim (PhiPi)

jmalaysia,

You're right about the instaneous speed thing, and a calibrated loop would work fine for that. But he also wants to know total elapsed (i.e. "trip") time. That involves much more than just timing one or two loops and is better left to an external timer.

-Phil

jmalaysia

Yeah, the elapsed time got added in later in the post and I didn't see it. To keep up with total elapsed time the bike would need to stay in motion for the entire trip or have a second loop to accumulate time while stopped. You would have to add a start and stop button for the timer as well, instead of having it automatically start when motion started. It still could be done without an external timer but it somewhat more complicated. I use calibrated loops to keep up with a project of mine that records and plays back bidirectional variable speed movements and it also records pause time.

Now that I think about it, the one I had on my bike started automatically and shut down after a minute or so of inactivity. I don't think it kept up with elapsed time, but it did retain total distance travelled, which was a nice feature.