Erratic PIR output

[MikeG]

Jon:

I picked up four PIRs in my recent order.  Using a bare-bones test program that simply echoes the state of the PIR to an output, three of them appear to act normally, but the fourth simply oscilllates continuously at about 2 seconds on/1 second off.  All four units have their onboard jumper set to the "H" position.  (Incidentally, the Parallax site references ver. 1.2 of the PIR documentation, which describes the operation of this jumper; your link references ver. 1.1, which does not)  Do I have a bad sensor?

--Mike

[JonnyMac]

Hard to say.  You may want to give Parallax tech support a call, and we'll check in with them, too.  If you send it back we'll exchange it for you, no questions asked.  PIRs are notoriously twitchy to begin with, but shouldn't oscillate when in a "quiet" environment.

With PIRs, ALWAYS debounce the input, even when they seem to be working as expected.  Here's a template that I setup for PIR-activated programs:

' =========================================================================
'
'   File...... PIR_template.BS1
'   Purpose...
'   Author.... Jon Williams, EFX-TEK
'              Copyright (c) 2007 EFX-TEK
'   E-mail.... jwilliams@efx-tek.com
'   Started...
'   Updated...
'
'   {$STAMP BS1}
'   {$PBASIC 1.0}
'
' =========================================================================


' -----[ Program Description ]---------------------------------------------


' -----[ Revision History ]------------------------------------------------


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

SYMBOL  Sio             = 7                     ' SETUP = out; no ULN
SYMBOL  PIR             = PIN6                  ' SETUP = DN


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

SYMBOL  Baud            = OT2400

SYMBOL  IsOn            = 1                     ' for active-high in/out
SYMBOL  IsOff           = 0


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

SYMBOL  timer           = B2
SYMBOL  lottery         = W5                    ' random value


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

Reset:
  PINS = %00000000                              ' clear outputs
  DIRS = %00000111                              ' set output pins (P0..P2)

  PAUSE 20000                                   ' warm-up/inter-show delay
  timer = 0                                     ' clear for PIR debounce


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

Main:
  RANDOM lottery                                ' stir random value
  PAUSE 5
  timer = timer + 5 * PIR                       ' advance/clear timer
  IF timer < 250 THEN Main                      ' wait for valid signal

  ' show code here

  GOTO Reset


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


' -------------------------------------------------------------------------


' -------------------------------------------------------------------------


' -------------------------------------------------------------------------


' -------------------------------------------------------------------------


' -------------------------------------------------------------------------


' -----[ User Data ]-------------------------------------------------------

[JonnyMac]

Thanks for the tip on the docs link -- I've update our links.

[MikeG]

I just spoke with Dave at Parallax tech support, and he confirmed that it does indeed sound like a bad sensor.  He said he's never seen this specific behavior, but it seems to be defective.  Not sure if this will help anyone else, but at least we have something resembling an answer documented here. 

[dongray]

I had the same problem with a batch of PIR's.  If I power them at 3.3v, they all work fine though.  The spec says it is a 3.3v part which is 5v tolerant.  I suspect the latest parts have somehow don't have that tolerance. 

Since the current draw is low (I measured 0.2mA, which is double what the spec says, but still small), you could still power these from a 5v supply if you don't have a 3.3 volt regulator by using a simple resistor divider circuit. 
For example, a 680 ohm in series with a 330 ohm.  This would give 3.3v with a current load of 5ma from the main supply.  Not much load, but still enough to provide a good output to the PIR. 

[JonnyMac]

The whole idea behind the Parallax PIR is that it will plug right in to their BoE, or onto one of the headers on our Prop-1, Prop-2, or Prop-SX controllers -- adding a resistor takes away from the convenience of that sensor.  Parallax is looking into the issue.

[ron5526]

Couple quick questions re: the debounce code.

1.  Is this basically checking the PIR status 50x over 250ms to confirm the status of "1" (continuous).  Wouldn't a pause of say 1 sec then rechecking accomplish the same thing or does it really need to read it 50x for a proper check.?

2.  Is the "lottery" variable really being used by this debouncing routine?


Sorry for my lack of understanding.  I've used the PIRs in the past w/o having to debounce, however, never in rapid cycle like I will be using for my current project. 

Thanks.
Ron

[JonnyMac]

1. No, and here's why.  Let's say that the sensor has a glitch output, then -- about a second later -- has another.  The simplistic approach of scanning just twice could be fooled by this condition. 

2. We stick "RANDOM lottery" into the middle of a loop that is externally influenced (terminated) so that the value of lottery will be unknown when we drop through the debounce loop -- this is the only way to get true randomness.  You see, RANDOM is not truly random, it is pseudo-random.  If you run this little program:

Main:
  RANDOM lottery
  DEBUG lottery
  RANDOM lottery
  DEBUG lottery
  RANDOM lottery
  DEBUG lottery
  END

... you will see that the list output is the same every time; this "feature" can actually be used in Simon-type game applications where the output looks random, but really isn't.  Given the same seed (present value of lottery), the output after RANDOM is predictable because it is based on a mathematic function (called a Linear Feedback Shift Register -- in case you want to Google it).

[ron5526]

I don't think I'll quit my day job and become a BS1 programmer!!!  Hopefully, this will be my last beating of the dead horse.  Is there a time when we should use the below template (found in one of your posts re: the use of template) vs. the one above.  The reason why I ask is because this one does not have the random lottery code to it.  My thinking was the random lottery template is a more accurate/updated version.

Thanks again...



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

SYMBOL  Sio             = 7                     ' SETUP = out; no ULN
SYMBOL  Trigger         = PIN6                  ' SETUP = DN


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

SYMBOL  IsOn            = 1                     ' for active-high in/out
SYMBOL  IsOff           = 0

SYMBOL  Baud            = OT2400


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

SYMBOL  timer           = B2


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

Reset:
  PINS = %00000000                              ' clear all outputs
  DIRS = %00111111                              ' make P0-P5 outputs


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

Main:
  timer = 0                                     ' reset timer

Check_Trigger:
  PAUSE 5                                       ' loop pad
  timer = timer + 5 * Trigger                   ' update timer
  IF timer < 100 THEN Check_Trigger             ' wait for 0.2 sec input

  ' prop code here

  GOTO Main

[JonnyMac]

Programming is as much art as science, and the delay used will be based on devices connected to the controller.  I tend to use 250 for the PIR because they have twitchy outputs and a good output is much longer that 250 ms.  For button type inputs I tend to use 100.

If you want to standardize, use 100 as 1/4 second (250 ms) is quite a long time when it comes to quick button presses.

[CoffinBound]

MikeG - Would it be possible for you to post the code you used to test your PIRs, or is it posted already and I just didn't see it?  I have had very little luck getting them to function properly, even after installing them in a PVC shield as Scary Terry has documented.  I'm wondering if my 2 PIR boards are bad like yours.

TIA