Is there a way to count pulses (a steady 120hz) for a changing length of a butt

[Jon Williams]

Sure...

Main:
· DEBUG· "Honey, I love you ... can I spend $100?· Please..."
· END


As far as the rest of your program, calculating BPM from your 120 Hz input is easy:

· bpm =·7200 / countHz

Displaying on three 7-segment LEDs will take a bit of hardware, and you have choices: you could use a multiplexer like the MAX7219 or the MC14489 (cheaper), or -- if the display cathodes are not common -- you can go really cheap and use a 74HC595 for each digit.· These can be daisy-chained so you'll only need three IO pins to display the BPM (that goes for the muliplexers as well).

Calculating the blink rate for the LEDs is no big mystery either.· Assuming a 50% duty-cycle you could do this:

· blinkRate = 30000 / bpm
· DO
··· TOGGLE BpmLed
··· PAUSE blinkRate
· LOOP UNTIL (StartBtn = Pressed)

See my attachment for a more advanced version that turns the LED on for a fixed period; the off time is dependent on the bpm value.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

[Clock Loop]

Will I have a hard time using the BS2 for talking to 2-wire, 1-wire, or I2C devices? I have a few samples on the way from maxim, and one of them is the display driver MAX6959 (which is a 2-wire)

[Jon Williams]

You cannot use 1-Wire devices unless you have a serial-to-1-wire convertor -- unless you get a BS2p model. All BS2 models have SHIFTOUT and SHIFTIN instructions that can be used with devices like shift registers, etc., and can also be used to synthesize I2C communications. If you get a BS2p you can skip the I2C synthesis since those models (BS2p, BS2pe, BS2px) have I2COUT and I2CIN instructions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

[Clock Loop]

In this code,

Count_Pulses:
  DO : LOOP UNTIL (StartBtn = Pressed)
  DO : LOOP UNTIL (StartBtn = Released)
  DO
    IF (PulsesIn = 0) THEN
      pCount = pCount + 1
      DO : LOOP UNTIL (PulsesIn = 1)
    ENDIF
  LOOP UNTIL (StartBtn = Pressed)
  RETURN

What does the " : " in "DO : LOOP UNTIL" do?
Ive searched the help and didn't find any example code that shows use of " : " like this.

[Bruce Bates]

BPM -

The colon just permits you to stack more than one PBASIC command on one physical line
like this -

A = 1 : B = 2 : C = 3

DO : LOOP UNTIL etc

I suppose another way of saying it is that the PBASIC Stamp Editor views it as an artifical
LF + CR.

Regards,

Bruce Bates

[Tracy Allen]

newPulsesIn VAR bit
oldPulsesIn VAR bit
Count_Pulses:
  DO : LOOP UNTIL (StartBtn = Pressed)
  DO : LOOP UNTIL (StartBtn = Released)
  DO
    newPulsesIn=PulsesIn
      pCount = pCount + (newPulsesIn ^ oldPulsesIn & oldPulsesIn)
    oldPulsesIn=newPulsesIn
  LOOP UNTIL StartBtn
  RETURN

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

[George Sutton]

In just a matter of MINUTES, the first of several very useful and informative replies were provided.· And in a matter of a few hours, circuits were breadboarded and software code was written, tested, and provided.· If this is not customer service, then such does not exist.· Jon, Beau, Chris, Tracy, and Bruce are to be commended for yet again coming to the aid of a Stamp user.
·

[Jon Williams]

I actually tried that technique on a different project and while it works, it is much slower than IF-THEN-ENDIF (probably due to all the bit level variable access and manipulation).· I love the trick though, and have included it in the StampWorks update in the multi-button input and debouncing project.

Tracy Allen said...

newPulsesIn VAR bit
oldPulsesIn VAR bit
Count_Pulses:
  DO : LOOP UNTIL (StartBtn = Pressed)
  DO : LOOP UNTIL (StartBtn = Released)
  DO
    newPulsesIn=PulsesIn
      pCount = pCount + (newPulsesIn ^ oldPulsesIn & oldPulsesIn)
    oldPulsesIn=newPulsesIn
  LOOP UNTIL StartBtn
  RETURN

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

[Clock Loop]

To make sure I understand this code correctly,

Count_Pulses:                               'Sub Count_pulses.
  DO : LOOP UNTIL (StartBtn = Pressed)      'this loops this one line of code untill I press the button
  DO : LOOP UNTIL (StartBtn = Released)     'this loops this one line of code untill I release the button
  DO
    IF (PulsesIn = 0) THEN                  'this makes sure every active low part of 120hz is counted, not every high swing.
      pCount = pCount + 1                   'this adds 1 to the count for every active low part of 120hz
      DO : LOOP UNTIL (PulsesIn = 1)        'This loops this one line of code untill 120hz swings high.
    ENDIF
  LOOP UNTIL (StartBtn = Pressed)           'this loops the entire 120hz pulse counter until the button is pressed again.
  RETURN                                    'this returns me to main to display count results.

[Clock Loop]

I hope Im not annoying you guys with all my questions. heh.. Ive got another.
Heres my results from counts. I added some code to repeat the counts, without resetting the chip, and added code to calculate the bpm and display it.

My question is, if I use the command BUTTON to debounce the button, will it smooth out my BPM results? Or is there another reason I am getting a very WIDE range of results. The button was pressed at a constant rate, timed by a metranome. obviously humans aren't perfect, but i know the results should be within +/-10 bpm of eachother... Obviously I will use averaging over a time frame, but I would like to improve the data I am sending to my averager.

example:
Press button. Wait. Press again.
bpm = 57
bpm = 240
bpm = 86
bpm = 86
bpm = 10
bpm = 167
bpm = 122
bpm = 167
bpm = 144
bpm = 194
bpm = 167
bpm = 194
bpm = 144
bpm = 20
bpm = 144
bpm = 240
bpm = 104
bpm = 1
bpm = 144
bpm = 104
bpm = 225
bpm = 224
bpm = 104
bpm = 194
bpm = 144
bpm = 144
bpm = 144
bpm = 167
bpm = 122
bpm = 1
bpm = 86
bpm = 1
bpm = 194
bpm = 232
bpm = 144
bpm = 104
bpm = 86

heres the code

' -----[ I/O Definitions ]-------------------------------------------------

Bttn            PIN     0                       ' active-high button input
Hz              PIN     1                       ' 120 Hz input


' -----[ Constants ]-------------------------------------------------------

Pressed         CON     1                       ' for active high button
Released        CON     0


' -----[ Variables ]-------------------------------------------------------

pCount          VAR     Word                    ' count of pulses
bpm             VAR     Byte

' -----[ EEPROM Data ]-----------------------------------------------------


' -----[ Initialization ]--------------------------------------------------

Reset:
  DEBUG CLS,
        "Press button.  Wait. Press again.", CR


' -----[ Program Code ]----------------------------------------------------

Main:

 DO
  pCount = 0
  GOSUB Count_Pulses
'  DEBUG ? pCount
   bpm = 7200 / pCount
   DEBUG ? bpm

 LOOP


' -----[ Subroutines ]-----------------------------------------------------

Count_Pulses:
  DO : LOOP UNTIL (Bttn = Pressed)
  DO : LOOP UNTIL (Bttn = Released)
  DO
    IF (Hz = 1) THEN
      pCount = pCount + 1
      DO : LOOP UNTIL (Hz = 0)
    ENDIF
  LOOP UNTIL (Bttn = Pressed)
  RETURN

[allanlane5]

1. No, you should not use 'Button' to debounce, or you'll lose the time between presses.

2. A human being had kind of limited resolution. +- 10 mSec might be a better metric.

3. You may need to de-bounce your readings -- not with "Button" though.
That would explain your '1' and perhaps '86' readings. Note that a switch will 'bounce' for 1 to 3 mSec, depending on the spring tension.

[Jon Williams]

You many need to use an external circuit to clean-up the button bounce -- the trick with your program is that you're manually counting pulses from an external device with an ~8 ms period; by inserting debouncing code you will start missing counts.· You may want to consider that PCF8583 as an external counter I mentioned earlier; it may be a better solution for you to measure the period (accurately) between button presses.





▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

[Clock Loop]

hmm.. bummer i figured it would be a easy solution. somehow the button is my problem tho. I hooked my counter up to another 555 timed at 3hz. and the numbers are much more steady. Only about a 7bpm difference between them. So somehow the button is making it very wack.

[Clock Loop]

Oh, btw, if anyone is keeping track of this and using the code, the BPM calculation should read

bpm = (3600 / pCount) + 10, NOT bpm = 7200 / pcount

I dont know why, (prolly from my 555 timers inaccuracy) but I had to add 10 to my result to get the range in the proper BPM. Mabee this will be fixed with a crystal clock.

[Clock Loop]

Where do I get the PCF8483? I searched parallax.com, and maxim-ic... nothing.

[Orion]

digikey has them http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=280886&Row=165410&Site=US
try www.mouser.com also

[Jon Williams]

How do you figure (the 3600 part)?· 120 Hz x 60 seconds (one minute)·= 7200.

BPM said...
Oh, btw, if anyone is keeping track of this and using the code, the BPM calculation should read

bpm = (3600 / pCount) + 10, NOT bpm = 7200 / pcount

I dont know why, (prolly from my 555 timers inaccuracy) but I had to add 10 to my result to get the range in the proper BPM. Mabee this will be fixed with a crystal clock.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

[Jon Williams]

Buttons are inherintly noisy.· The ticky part for you is that debouncing software takes a little more time than you have between raw input pulses.· If you use an external counter there will be a built-in delay while sending the message, so that will help -- you can go back to the non-debounced method to keep the code simple.

BPM said...
hmm.. bummer i figured it would be a easy solution. somehow the button is my problem tho. I hooked my counter up to another 555 timed at 3hz. and the numbers are much more steady. Only about a 7bpm difference between them. So somehow the button is making it very wack.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

[Clock Loop]

Jon Williams (Parallax) said...
How do you figure (the 3600 part)? 120 Hz x 60 seconds (one minute) = 7200.

When I found out I questioned myself also.

But after calculating what my bpm SHOULD read, I found that it was double.
I ran the program like you wrote it.
My clock is 120hz.
My button click is hooked up to a 555 running at 3hz.

3 X 60 = 180BPM.

If you run the program with bpm = 7200 / pcount, your BPM will be around 80.
If you change it, the bpm will be correct (close to 180) (assuming you have exactly 3hz and 120hz)

Or this might be a result of me using DEBUG code.
Mabee its slowing the program down?
Heres a question.
How Do I NOT send the BPM back thru DEBUG? Is there a way to STORE it and send it in Bunches? Mabee this would prove if my debug is slow?

[Jon Williams]

There is no problem with your BASIC Stamp being slow -- that should be abundantly clear by now.· Since you're sending the DEBUG output between measurement windows it's not affecting the count.

I'd say the *problem* is in your button pressing -- that's probably what's slow and is resulting in a higher-than-expected number.· Not that I got particularly scientific, mind you, but using the old "One thousand one, One thousand two..." counting between button presses always resulted in the correct value on every test.· Have you verified that your 120 Hz input is actually 120 Hz?· I had a scope to check my 555, but I also did this:

· COUNT PulseIn, 1000, countHz
· DEBUG ? countHz
· END

... and I got 122 (which is what my scope said as well) -- and this was close enough to test the code.· If you want to speed up your DEBUG output (again, it's NOT affecting the count routine -- unless you snuck a DEBUG output into the middle of it), just send the value:

· DEBUG DEC countHz, CR

This will print just the value without·the variable name (you know what you're looking at).

The lesson is you have to be very careful when you start "shotgun compensating" -- pretty soon nothing will work, nothing will match expectations, and ultimately you'll be left scratching your head wondering why.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax