Shop OBEX P1 Docs P2 Docs Learn Events
PIR firing on a cycle — Parallax Forums

PIR firing on a cycle

T ChapT Chap Posts: 4,223
edited 2008-12-06 17:05 in General Discussion
I got a PIR today and set it up on a loop in Spin, nothing else running, with a beep if high. The unit seems to work in terms of detecting motion, but it also has a cycle of a very rhythm of on/off with no apparent trigger:

2 seconds on

2 seconds off

I set it to the Normal mode and it is basically the same issue. The unit is in a room by itself and I am in another room.

There is nothing obvious (that I am aware of) firing an infrared pattern in the room or nearby.

I put it in a card board tube and it stopped in less than a minute. 3v3 in, high out is 2.8 with no load.

Any suggestions?

Post Edited (TChapman) : 12/4/2008 4:19:53 AM GMT

Comments

  • Bruce BatesBruce Bates Posts: 3,045
    edited 2008-12-04 05:03
    TChapman -

    Are there any fluorescent lamps nearby?

    Are there any dimmers in that room?

    How is that room heated?

    Is there a wall clock in that room?

    If this was tested in a house, which room was it in?

    So many questions, so few answers smile.gif

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    When all else fails, try inserting a new battery.
  • T ChapT Chap Posts: 4,223
    edited 2008-12-04 05:28
    There are fluorescent lamps but I tried with all lights off in the room.

    No dimmers.

    At present there is is no air conditioning on, 74F.

    Only a small LCD clock on a table.

    In a vocal booth, concrete floor, treatment on all walls and ceiling, 4 x 6 glass in the wall.

    When I put it in a cardboard tube and stuff a paper towel in the end that is exposed it will stop triggering.

    I am thinking it is defective due to the output being lower, but I am open to any experiments to test it.

    Thanks
  • T ChapT Chap Posts: 4,223
    edited 2008-12-04 05:48
    I think it doesn't like Qprox sensors, seems to solve it when I turn off a touch pad in the area.
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2008-12-04 06:17
    TChapman -

    Does the touch pad have a model number on it?

    Can you tell which Qprox sensor is being used?

    NOTE: Just for the record, Atmel and Qprox appear to be partners.

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    When all else fails, try inserting a new battery.
  • T ChapT Chap Posts: 4,223
    edited 2008-12-04 06:56
    Thanks a Bruce for the help.

    This is one of those mystery issues, I solved it, but makes no sense. There is a remote PCB that has a PCF8574 on it, plus a QT1081 with 4 outputs into 4 inputs on the 8574, and 4 inputs to the 8574 from a terminal block to allow whatever inputs you want to give it. I was testing the PIR into one of the inputs to the 8574, reading it with I2C, and getting the false triggers from the PIR.

    At first I thought it was proximity to the QT1081 that was causing it, but in fact when I pull the PIR output off the terminal block, it stops false triggering regardless how close I hold the unit to the PCB. It constantly false triggers if the output is connected to the 8574 along with the 4 Qt1081 outputs.

    Seems to work fine when connected straight to a Propeller input, even in close proximity to the Qprox chip and PCB.

    As an interesting test, I put a cardboard paper towel center around it, and pulled the PIR back into the cardboard tube so the Fresnel lens was maybe 4" from the outside edge. This created a circular "detectable" pattern of around 12" at 4' feet away. I suppose with a smaller tube plus pushing the unit deeper a tighter pattern could be created.

    Very cool device.
  • LeonLeon Posts: 7,620
    edited 2008-12-04 16:21
    Some PIRs are susceptible to RF. When we transmitted on VHF at an amateur radio club I used to belong to, we triggered the security lights at someone's house about 50 yards away.

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
    Suzuki SV1000S motorcycle
  • T ChapT Chap Posts: 4,223
    edited 2008-12-04 18:27
    What I am missing is why it doesn't misfire by proximity, but rather by having it's output connected to a connector>chip on the same board as the Qprox.

    If it were RF, would it misfire due to something on it's output?

    Using the same power, if I connect the outut of the PIR to the terminal block, it misfires in a repeat loop. If I connect to a Propeller pin directly, it is fine.

    Below is the board and schematic. The last 4 inputs on the terminal block connect to 4 10k trim pots to serve as voltage dividers in case there are devices above 3v3 connected.

    The PCF8574 has 4 outputs from the Qprox QT1081 to pins 1-4, then the 5-8 inputs are for misc sensor devices. The 4 Qprox inputs go to terminal block inputs 1-4, so they can be connected to remote sensors if desired.
    969 x 656 - 26K
    691 x 830 - 65K
  • LawsonLawson Posts: 870
    edited 2008-12-05 20:00
    Ug, no ground plane, and No bypass capacitors right next to the power pins of each chip on that board. I wouldn't be surprised if the ground on that board had all kinds of noise on it. Similarly I'd expect a good portion of this noise to couple to the external inputs through circuit elements and parasitic inductance/capacitance. Where is the ground of the PIR connected into this system? (I don't see any convenient ground connections on your terminal block)

    Marty

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Lunch cures all problems! have you had lunch?
  • T ChapT Chap Posts: 4,223
    edited 2008-12-05 20:13
    There is no ground plane when using Qpox, it causes problem (extra loading) and is recommended against. The PIR has common GND. The bypass cap is labeled BP, very close to the Qt1081. BPPCF is the cap on the 8574.
  • LawsonLawson Posts: 870
    edited 2008-12-05 22:17
    I just read the Q-touch app note AN-KD02 that talks about how to design for touch sensors. Lots of good info it there. The app note mentions that it's best to keep traces that go to keys away from other traces. It also recommends that a LDO regulator be dedicated to the touch IC. Also the app note only discourages the use of a ground plane near the touch electrodes and traces. Using a partial ground plane under everything else sounds like it's still good practice to me.

    Another trace that looks shaky is the ground connection between the PCF8754's bypass capacitor and the IC's ground. This connection loops around most of the board and the Q-touch chip adding a significant parasitic inductor in series with the bypass capacitor.

    I still don't see where the PIR is connected to ground on this system. What connector on this board is the PIR's ground connected to? When the PIR is directly connected to the Propeller is the ground connection of the PIR still connected to the board with the Q-touch sensor or is the PIR's ground connection also moved to directly connect to the Propeller board? Primarily I'm assuming that the previous poster who said PIR sensor's are sensitive to RF is right, and seeing what has been done to isolate a RF source (the Q-touch circuit) from the PIR sensor.

    My two cents,
    Marty

    P.S. The datasheet for the q-touch sensor mentions a calibration test that occurs every two seconds. This is likely the specific culprit.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Lunch cures all problems! have you had lunch?

    Post Edited (Lawson) : 12/5/2008 10:22:28 PM GMT
  • T ChapT Chap Posts: 4,223
    edited 2008-12-06 02:30
    Thanks for the suggestions Lawson. I have had great success with Qprox implementation on a number of boards, and in most cases I do maintain some ground plane under the chip itself. The actual board in question does have several ground regional planes on it (regulator area mainly), the image above has the ground plane removed de to some slight redesign for the next rev. This boards works very well as it is for all purposes except in the case of the PIR, which is still a mystery as to why the proximity is not the issue, but rather the output of the PIR being connected to the 8574. The power (3v3 and GND) to the PIR are from a main board(common GND) about 6 inches away from the aux board, the main board provides 5 volts to the aux (QT1081>8574), where in fact there is a dedicated regulator, although technically you could argue that hanging the 8574 on the same regulator makes it not so dedicated, but this has never been an issue. With years of experience and field testing various Qprox products, none of these design questions are an issue. The issue remains that the output of the PIR connected to the aux board alone is causing the problem, and how noise can be getting back to the decision making component of the PIR from it's output defies logic. Placing the PIR or it's output wire directly on the board or near any of the electrodes does not cause a problem. There is no reason that the output of a device should affect it's own decisions whether to trigger, at least not in this case I don't think.
  • T ChapT Chap Posts: 4,223
    edited 2008-12-06 11:31
    OK some progress.

    The anomaly only occurs when using 3v3 to the PIR, but 5v is fine.

    It appears it is may be some type of loop, maybe a strange ground loop or something I can't explain, but the boards are common ground, and I even jumpered the grounds on the boards and PIR to be sure.

    When you boot up, it doesn't misfire until you manually trigger it once, then it triggers about every 5 seconds forever when using 3v3 on the PIR. There is nothing obvious on the scope on the power to any of the boards, PIR, 8574, or output lines on the PIR, even at high res the scope meters negligible noise on the PIR. Putting the PIR in a closed box still produces the misfire.

    I can just as easily run it to a 5v connector, so there is no real reason now to try to understand the strange circumstances with 3v3.
  • LeonLeon Posts: 7,620
    edited 2008-12-06 17:05
    There will be less noise immunity with 3.3V. That might explain the anomaly.

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
    Suzuki SV1000S motorcycle
Sign In or Register to comment.