+ Reply to Thread
Page 2 of 4 FirstFirst 1234 LastLast
Results 21 to 40 of 64

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

  1. #21

    Default

    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
    Attached Files Attached Files
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  2. #22

    Default

    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)
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  3. #23

    Default

    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
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  4. #24

    Default

    In this code,

    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.
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  5. #25

    Default

    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
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  6. #26

    Default

    Code:
    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
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  7. #27

    Default

    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.
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  8. #28

    Default

    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...
    Code:
    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
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  9. #29

    Default

    To make sure I understand this code correctly,
    Code:
    
    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.
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  10. #30

    Default

    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
    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
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  11. #31

    Default

    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.
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  12. #32

    Default

    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
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  13. #33

    Default

    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.
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  14. #34

    Default

    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.
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  15. #35

    Default

    Where do I get the PCF8483? I searched parallax.com, and maxim-ic... nothing.
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  16. #36

    Default

    digikey has them http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=280886&Row=165410&Site=US
    try www.mouser.com also
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  17. #37

    Default

    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
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  18. #38

    Default

    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
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  19. #39

    Default

    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?
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

  20. #40

    Default

    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 withoutthe 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
    Last edited by ForumTools; 09-30-2010 at 10:07 AM. Reason: Forum Migration

+ Reply to Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts