Counting and displaying pulses

cws

I am building a device that simulates a 30 meter wheelchair sprint race. I am using a max7219 to display the speed (3 digits, XX.X mph), elapsed time(3 digits, XX.X seconds) and distance (2digits XX, meters). I am using an external timebase to provide .1 second pulses. Since the race is so short, I have to sample the wheel several times per revolution. At a reasonable top speed of 15mph, the pulses from the wheel are 30 ms apart. I am comfortable with both driving the max7219 and the integer math workarounds needed to to do this. My question is how can I know if a BS2px is fast enough to to update the displays without missing pulses from the wheel sensor?

I can't seem to understand how to use POLLIN to help with this, and do not want to add the complexity of storing pulses in a 4bit counter or Tracey Allen's cd515 if it is not required.

stamptrol

For a final answer, you may have to bench test the system. I suspect the BS2px will be fast enough, but it will depend entirely on the code you have running.

Feed a simulated wheel pulse stream into the stamp and work on the code to calculate and display the required results.

If the wheeel pulses come at 30mS intervals, and the timebase is 100 mS, doesn't that give pretty coarse resolution?

Cheers,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

Mike Green

Here's a typical hold circuit. When a positive going pulse comes in (on the left), the capacitor gets charged to +5V. The diode prevents discharge of the capacitor. The Stamp I/O pin is normally in input mode and would read the voltage on the capacitor. Once the Stamp has read the input, the program would briefly make the I/O pin LOW, then INPUT mode again. This will discharge the capacitor and make it ready for the next input pulse.

The advantage of this circuit is that it will hold any incoming positive pulse until the Stamp has time to read it. If the Stamp is busy doing something else, it won't miss the pulse although it will miss a second pulse if it doesn't service the first pulse before the second comes in.

cws

Thank you for you suggestion.

I believe the resolution will be OK. The .1 second time base will be directly used to increment the only elapsed time display to its max value of 99.9 seconds.

Current speed will be calculated and updated every second or two depending on what gives the best readout. Right now I am getting .16 meters per pulse, and this is probably sufficient for my application as it is mainly for amusement and not actual competition. My 30 meter sprint now works out to 188.074 pulses. so I will end the race at 188 pulses.

BTW, the actual time between pulse at 15MPH is 24ms not 30ms. I was not even sure I would get a response to my post (1st timeposter), so i entered this value from my memory and it is really the value for 12mph., which is still a reasonable top speed for this device.

I will follow your sugestion of bench testing with a funtion generator. If this test shows my code is too slow, is POLLIN a possible soultion, or would external counters be easier to impliment? I am one to hope for the best and plan for the worst. Should I start studying one now or just wait to see what bench testing shows?

cws

Thank you for your suggestion Mike.

If I understand this, it helps by catching and holding pulses that may occur when the stamp is busy doing other things. As long as I do not get 2 pulses in the same program loop, it does not matter when they arrive, the capacitor will hold the pin high until discharged. This is what I was trying to get out of POLLIN, but just could not see how to simply achieve it. Thanks for the help, your suggestion is certainly a useful trick to have in ones bag.

Tracy Allen

How long are the pulses themselves? I see that they are 24 or 30 ms apart, so the pulses themselves are just a few milliseconds.

The capacitor and diode works well for this sort of thing. I have used that approach for rain gages and other things that briefly close a switch, and the capacitor allows time for the program to get around to examining the input. Note that if the input happens to be a reed switch or something like that, the circuit will need a pullup resistor at the left side of the diode in Mike's diagram.

You asked if you might also use POLLing for this. That would not require the diode/capacitor network. Maybe. The POLLing status is checked between PBASIC instructions, so it depends on how long the input pulse is in relation to the longest single PBASIC instruction you have in your main display loop. For example, a long SEROUT instruction may take several milliseconds to execute completely, and during that time, the POLLing function will not check the input. But here is how it is done:

' outer loop
POLLIN 0,0   ' set polling and look for low level
POLLMODE 10  ' this mode latches the triggers

' inner loop
DO
' ... stuff
GET 128,triggers  ' a byte variable
IF triggers.bit0=1 THEN ' checking poll status of pin p0
   ticks=ticks+1   ' it was activated, need to add one to pulse count
   POLLMODE 0   ' reset trigger
   POLLIN 0,0   ' set polling and look for low level
   POLLMODE 10  '  this mode latches triggers
ENDIF
' ... more stuff
LOOP

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

cws

Thanks again for all the help.

I am driving a flip flop with a 2 notch chopper disk mounted to a jackshaft that is driven by the 24" diameter wheel of the chair and a fixed slot sensor. The triggers are a minimum of 24 or 30 ms apart, and the flip flop changes state on each trigger. The wheel develops .16 meters for each state change. I learned about state machines from your website, and that is what I am trying to do with both the wheel encoder and the time-base.

This is my first time at this, but I think this makes the pulse 50% duty cycle and a min of 24ms apart for the wheel, and 100ms apart for the timebase.

I will study the POLLIN example.

thanks again

Tracy Allen

The flip flop and ~50% duty cycle make it easier to catch the pulses. It probably doesn't need POLLing, but here is a demo that shows how the logic works.

' {$STAMP BS2pe}
' {$PBASIC 2.5}
' demo of using POLLMODE to detect and count transitions on an input pin p2
' where high and low time on the pin are both longer than the loop time
Nticks VAR WORD   ' counts events
Pstats VAR BYTE    ' for reading polling status register
idx VAR BYTE       ' index for demo

POLLIN 2,~IN2    ' looking at p2, to be opposite of current state
POLLMODE 10       ' latch polling status when in2 changes state
DO
  GET 128,pstats    ' polling status
  DEBUG CR,DEC Nticks,TAB, BIN1 IN2,TAB, BIN1 pstats.BIT2
  IF pstats.BIT2=1 THEN     ' executes IF code only if p2 changes state ' 
    Nticks=Nticks+1    ' increment the event counter
    POLLIN 2,~IN2      ' new opposite state
   POLLMODE 10         ' reset polling trigger
  ENDIF
  FOR idx=0 TO 24      ' simulation of program 24 milliseconds
    PAUSE 1
  NEXT
LOOP

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

cws

Thanks for all the help. I think I have what I need to establish all my declarations , layout a proto PCB,and start building the code. BTW, like many others, it was your website that allowed me conquer, or at least subdue, the integer math thing. Thanks for all your efforts in helping others.

Tracy Allen

Hi cws,
The time and distance displays are straightforward, but I wonder about the speed display. distance/time, but with 100 milliseconds resolution in time and a distance count on the same order of magnitude, even the best math will have trouble with a meaningful instantaneous speed. It will be okay for the average over the entire race.

An alternative is to measure the duration of every second or third flip-flop cycle, and use that to calculate instantaneous speed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

cshaw

I think I am ok here. I have spreadsheet that lets me compare all the parameters.

I will update the speed once every 1 or 2 seconds.

The slower you go. the worse it gets.

For each pulse of my encoder, the chair travels .16 meters, this is a constant.

MPH = meters per second / .447 so .447 is the constant conversion factor here.

At 3 MPH or 1.34 meters per second I am getting 1.34/.16 or 8.38 pulses per second.

then,

MPH = 8.38 pulses per second x .16 meters per pulse/ .447 conversion factor

can simplify by dividing .16 meters per pulse/.447 conversion factor to arrive at a new conversion factor of .358.

MPH = pulses per second x .358

3MPH or 8.38 pulses per second x .358 = 3 mph

Of course, I will only see 8 pulses if I sample once a second.

8 pulses per second x .358 = 2.86 MPH indicated for 3mph actual, I can live with that for this application.

8.38 pulses is pretty close to 8, so to be fair lets use 8.99 pulses as the worst case scenario.
actual MPH= 8.99 pulses x .358 or 3.2 MPH with 2.86 MPH indicated based on 8 pulses,
this is not so great, but it does get better as you go faster.

At 8 MPH, there are 22.4 pulses per second, so losing that fractional pulse is not so costly.

BTW,When the race is over, the display does switch from current to average speed.

The most important value is the elapsed time, as this is what one person uses to compare themselves to others.

The encoder resolution is .16 meters per pulse this works out to 188.07 pulses for 30 meters, so at 188 total pulses the race is over.

If I put more notches in my encoder, I can get better low speed resolution. It all goes back to my original concern of how fast can I read the encoder. I can also sample/update every 2 seconds,while this would not help my 8.38 pulses example, it would help with counts of n.5 and above.

The wheelchair is on rollers and the wheels have little momentum/inertia, so their speed varies quite a bit as they are pushed, I wish I could just time between flip flops, but this would result in wildly varying speeds. The device does not coast well between pushes, this is intentional as a safety factor. If the wheels had enough inertia to be good flywheels they would store enough energy to cause many stubbed fingers.

If I am really missing something here please let me know. I hope this is not to much information, I am new to the forum and I am not sure what is considered proper etiquette.

Thanks once again.

cshaw

I have completed both the software and hardware portion(almost) of this project, but I have one problem that has me stumped.

I intended to clock a cd4013 using an optical slot sensor with a chopper disk. During development to test this I used a function generator driving an optoisolator. This worked fine and was a handy way to verify accuracy. The optoisolator would clock the 4013 fine, but when I try to use the slot sensor, a logic probe shows a valid pulse, but the 4013 will not clock. Logic values are great; 5 volts high, .7 volts low at the clock pin. When I use a micro switch to clock the 4013, it works fine other than the bounce. I put a diode in line with the switch to raise logic 0 to .7 volts, and it is still fine. My encoder disk has 4 small notches that normally pull the clock low for a few milliseconds, and then return it high. it makes no difference how fast or slow I rotate the disk, the 4013 will not clock with the slot sensor. Is there something critical about the rise time of the clock pulse? this is the only thing I can think of.