Author
Topic: Limbus - a low power motion sensor (Read 8933 times)

Battery life is surely better, I am saving around 60-80uA from this upgrade (in idle). In active detection mode the saving over the chinese PIR is around 200-250uA.

Basically the rapid firing of many repeated triggers is somewhat unnecessary. The problem is the pulses are completely irregular. So if theres a constant pattern of motion for 5 seconds, the pulses are just all over the place, there could be 30 pulses in those 5 seconds, maybe more. So while pulses only happen with motion (which can be useful sometimes) the lack of having a pattern would make it difficult to make any determination of what's going on other than just knowing there's motion. In my case all i want to know is when motion is detected. Then i want a single packet to notify the gateway, and i don't care if there's motion for another 30 seconds. When I come home, take my shoes and coat off, and spend that half minute to a minute, i only need to know about 1 motion event, not 30. But again, yes continuous motion can be useful and the fact that you have control over debouncing is a plus. In their DS or an app note they actually show the "typical ciruit" which includes hardware debouncing.

In terms of adjustability, don't get me wrong, I think the Panasonic PIRs are great overall and less is sometimes more (lack of pots) but I haven't used these long enough to just discard the need for any adjustment. All we need it for it to just work so if it's smarter and doesn't need us to find the sweet spot, and it just works in most scenarios, then its a win.

I look at the many pulses versus single pulse as very much a feature. I'm pretty sure it can be used to help rule out false positives from, for example, a gust of wind or similar. In contrast, a human detection would produce a lot more pulses. Although a lot of motion detectors do offer pulse counting, it's usually just a fixed threshhold amount, so a useful part of the information (a kind of confidence level) simply gets truncated and lost.

I look at the many pulses versus single pulse as very much a feature. I'm pretty sure it can be used to help rule out false positives from, for example, a gust of wind or similar. In contrast, a human detection would produce a lot more pulses. Although a lot of motion detectors do offer pulse counting, it's usually just a fixed threshhold amount, so a useful part of the information (a kind of confidence level) simply gets truncated and lost.

I can't disagree and I see you being motivated enough to do the research, I'd be interested in the outcome and how that can become useful in a practical sense. Maybe that should be separate with a reference here.

I can sum it up briefly: for outside perimeter monitoring (which is a notoriously difficult area to cheaply monitor with PIRs because of being prone to false alarms), how your system responds can be proportional to how confident it is about what kind of thing is likely causing the sensor to activate. Admittedly, other use cases may not benefit from the added information, so really, everybody here is right, depending on your use case.

Yup it plugs right in, except the pinout is not in-line. So a future version could support a parallel OUT pin at the right spot, VCC and GND match, easy change. But I have some extra mods I want to make. I may even completely redesign the MotionMote, not sure yet. Too much else to do right now. Babies got in the way

<...snip>Watchdog TPL5010:Only 35 nA operational current. Wakes the CPU every second so that 328P can be put to power-down mode. Interval is set with two parallel 1% resistors. Recommended for 1 second is 7.15K || 19.1K = 5.202K, but I didn't have those exotic values so 6.82K || 22K = 5.194K is close enough. (should calibrate this individually for accuracy but at this point it's "good enough").I had originally trouble with the example schematic suggesting to wire the reset output to CPU, since 1 second is too short time to get even past boot loader without the WD then resetting the CPU again. I removed the wire and put pull-up resistor from VDD to WD reset pin, but the latter seems unnecessary.Other problem was that sometimes the WD would not acknowledge the DONE-signal from CPU after a single missed WAKEUP signal, and the WD would just keep resetting the CPU (or would try, since reset is not attached anymore), and would not send any more WAKEUPs (which leads to eternal sleep unless interrupt comes from PIR). After a while (and many more explicit DONEs before going to sleep) the WD would eventually start acknowledging them again, but this was quite annoying. Configuring the WAKEUP interrupt handler right at the setup (and not before sleep) and keeping it attached all the time seems to help though. Now one remaining problem is that I can't get the WD to reset it's time cycle (DONE signal does not seem to do this), so if I want to explicitly use internal WD to sleep for shorter duration, there's eventually going to be overlap between the two WD cycles and CPU wakes up earlier than supposed. Has someone here had similar issues with TPL5010? <snip...>

Marcus, I finally got a chance to play around with the TPL5010. Partly 'inspired' by your issues, I built a breadboard to test it before soldering it onto my PCB. The only thing that I found that I had missed in the spec was that you MUST issue a DONE after the end of the Reset pulse and before the first Wake timeout, otherwise you will NEVER get a Wake pulse. From then on, Done/Wake happily handshake until your code goes south...

I believe the spec is a bit misleading in this regard. They state that you must issue a Done to "signal successful processing of the WAKE signal". Uh, I guess this is true, but you must also use DONE to "signal successful processing of the RESET signal"...

The only thing that I found that I had missed in the spec was that you MUST issue a DONE after the end of the Reset pulse and before the first Wake timeout, otherwise you will NEVER get a Wake pulse. From then on, Done/Wake happily handshake until your code goes south...

That's great news! I think the loop antenna would work much better with a smaller TH mote board and the CR1632 which only has 130mAh. But add in the tpl5010 and you'd still be set for a battery life of a couple decades.

Now if only Felix could make the RFM69CW not only better, but also smaller!

I am currently doing some experiments with the PIR EKMB130111 and recognized the already mentioned issue from you Felix:"the OUT seems to fire rapidly - yes I used the resistor as you did (i think 10k or 100k) so I had to do some software debouncing to have a single trigger per given unit of time of movement"

It says:"Note 2) Please select an output resistors (pull-down concept) in accordance with Vout so that the output current is lower than or equal to 100μA. If the output current is more than 100μA, thismay cause false alarms."Therefore with a supply voltage of 3.3V we need a minimum resistor of 33kOhm.

I am currently using 100kOhms and still have to debounce the output with ~2s....how is your experience?

Update:I also tried 1MOhm as pulldown resistor...works to...but does not really stabilize the output more....but reduces the power consumption a bit

@ulli,I am not sure how a pulldown can reduce current in a significant way (not according to ohms law).It causes a voltage divider which can reduce current on the main wire depending on the overall pulldown vs main wire resistance.But for this application the pulldown is to stabilize any stray pulses, that's how I see it. I saw no difference in behavior at 10K or 100K. I would not use anything above 100K since it's quite a weak pulldown.To really reduce current you'd have to use an inline resistor.