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

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Limbus - a low power motion sensor
« on: May 20, 2016, 03:13:32 PM »
Hello everybody,

here's one of the projects I've been working on these past few weeks. I was quite inspired by Joe Lucid's Tino and Tom's TH Mote and tried to reuse (or abuse) some of their ideas when designing low-power, miniature motion sensor. I named it "Limbus" because it resides in the interface between man and machine (or between changing environment and the more rigid/stagnent home). Actually this is only one of the devices in the Limbus series, but I'll tell you more about them later.



Now, some design requirements for the motion sensor:
- nice appearance (similar to Felix's MotionMote). After all, this is one of those few sensors that need to be visible, so no ugly tinkering this time (see below some  before/after pictures to see what kind of MonsterMote's I've had until now :) )
- small size (especially the depth) and light weight, since I wanted to attach the sensors to walls with double-sided tape.
- low power PIR sensor -> smaller battery -> size and weight reduced automatically
- more robust than the ubiquitous cheap, chinese PIR sensor
- temp & humidity sensor included
- wirelessly updated
- preferably also ICSP and FTDI interfaces

Here are notes on the current design:

PIR sensor:
Panasonic EKMB1101113 (http://www.mouser.fi/ProductDetail/Panasonic-Industrial-Devices/EKMB1101113/?qs=raAh8RbVwI5epY%252bTpPfoFA%3d%3d)
Somebody mentioned this on other thread. It's really nice PIR sensor, with standby current of only 1 uA. It's a tad expensive (18,8 euros on Mouser, on Digikey 20.79 euros), but my free time is more expensive when it comes to having headaches with the chinese PIR sensors (susceptability to voltage fluctuations and nearby wireless transmissions). On my tests I found I've found it to be quite stable, so no need to add "dead time" after RFM69 transmissions anymore. Only thing that I wished it had is lower height, but I guess one can't have everything :)
One thing to mention: I found out that when used wirelessly (no FTDI/ICSP cable attached), it wouldn't trip to motion always, but when oscilloscope probe was attached, it miraculously started to work. Even though the example wiring in the datasheet doesn't mention this,  a 100K resistor between GND and OUT solves this (I didn't try other values though)

SI7021 temperature and humidity sensor:
Standby current 60 nA so no other power down mechanisms needed. Relative humidity conversion current 150 uA, duration 2.6 ms (8-bit resolution).
Temperature conversion current 90 uA, duration 2.4 (12-bit res). For some reason no way to enable both 8-bit RH and 11-bit temp resolution together(?). Peak current during I2C operations is 3.5mA (<100 uS), but I haven't measured what is the average current consumption and duration during temp & RH comms yet. 

Flash chip W25X40CL (same as is Moteinos).
To squeeze out even the 1 uA sleep current, the chip is put behind mosfet to power it up only during OTA firmware updates. The Optiboot boot loader was modified to turn the power on when updating the firmware.

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?

Atmega328p:
Running now in 8 Mhz. According to datasheet min voltage is 2.4, but I suspect when battery level declines, voltage might droop under this during tx, so maybe it could be better to run it with 4 Mhz. On the other hand, we want to do our stuff and get back to sleep as quickly as possible. But then again, we are waiting for many milliseconds during tx and temp/RH conversion. Maybe best to alternate between 1-8 Mhz and even put CPU to sleep during the whole 5 mS temp conversion? This needs more investigation.

Tag Connect for ICSP and FTDI connectors:
I hate soldering these bulky 2.54mm pitch connectors when mostly they are being unused, so I tried to look for alternatives (pogo pins, edge connectors). Eventually I found out about Tag Connect
(http://www.tag-connect.com/) and I haven't looked back :) It's pretty expensive for such a simple thing (33 euros for TC2030-MCP-NL cable + 16 euros for triple pack of back plates), but this is a one-time purchase and saves a lot of head-ache later. For the smaller footprint NL (no legs) version the back plate is recommended to hold the connector in place (at least when debugging with FTDI interface), so remember to take this in account when designing the 3d layout (you don't want the adjacent parts to get in the way).

Battery:
Both CR2450 (solder-type) and CR2032 (battery holder) can be installed. Battery voltage is read through resistor ladder (3.3K and 1K), powered by PNP mosfet (same mosfet as the flash chip). 100 nF cap is there to stabilize the measurement, but I still need to investigate how much removing this would decline the accuracy (with these values RC time constant = 0.33 mS, so around 3*RC= 1 mS with 0.767 mA is now wasted just waiting for the capacitor to charge).

Sleep modes:
- CPU power down without internal WD during longer (>1s) periods. RFM69W is in sleep. Current consumption is 1.5-2 microamps in this mode.
- When awake, RFM69W is put to Listen Mode automatically to save battery.
- For shorter periods (for example when flashing leds for 30ms) the internal WD is used to sleep. RFM69W stays awake (in Listen Mode).
- After booting the operation mode is "Service/maintenance" (for example 30-60 seconds), during which RFM69W is awake (in Listen Mode) to receive OTA updates and other configuration changes. There's a reset switch that is incidentally also used to enter service mode. CPU dozes in short (now 500ms) cycles with internal WD.

LEDs:
in addition to normal led, WS2812B RGB led is used for troubleshooting/debugging/signaling. Could be configured real-time to customize "motion detected" indicator light. Since WS2812B uses whopping 470 uA in idle (led off), it is powered by a second PNP mosfet. Maybe powering it directly from 328P pins could be possible, but I don't know how much is the peak current draw and I didn't want to risk frying any of the CPU pins.

PCB:
All the above could be fitted to 2-layered 31x31 mm PCB. Main restrictive factor was to have both CR2450 and PIR sensor side by side, since having them on separate sides would put too much bulk depth-wise. Also, with only 2 layers it was getting tiresome to route all the connections without having to have the board peppered with vias :) Also having a well connected GND plane is nice.
One note: When using CR2032 the top (+) connectors (for CR2450) need a jumper wire. Also if reset switch is not soldered in, the top GND-connected holes need a jumper wire.

Enclosure:
34 x 34 x 18.5mm. Printed in PLA 1.75mm with 3d printer from Think3dPrint3d. Still need to tinker with the Simplify3D settings to get better quality front plate.

Here's some pictures of the completed ones:



They are quite an upgrade compared to the few Frankenmotes that I've had to endure up to now :)



Blunders (so far.. ) in rev 01:
- Output from PIR was originally wired to A7, which doesn't even have a interrupt capability :) Now wired to D5
- 100k resistor added between GND and OUT (PIR sensor) for stability
- Bulky reset switch replaced with slim SMD switch (current footprint not compatible and I had to use extra wires so this work-around is not physically the most stable but works)

Future ideas and improvements:
- For non-wall attached sensors adding depth while reducing frontal size would be acceptable. Maybe one PCB with 328p + rfm69 + flash + voltage sensor, and a separate PCB for other peripherals (PIR, leds, si7021). Frontal size should come down to around the size of CR2450,  depth maybe around the same, so nice cube form factor could be achieved.
- Give up the after-boot service mode and manual update initiation, and move to 100% Listen Mode? Then no manual button-pushing would be required. Also on-demand temperature sensing would be possible. How much would current consumption increase then?
- Swap RFM69W with smaller RFM69CW.
« Last Edit: May 21, 2016, 03:06:38 AM by Marcus »

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Limbus - a low power motion sensor
« Reply #1 on: May 20, 2016, 05:33:17 PM »
Thanks for posting!  This looks like a nice project.  It will be interesting to hear how your battery life proceeds.

Re: TPL5010, I have a couple of designs 'in flight' (just got one set of PCBs back today), but haven't had a chance to test it yet.  I looked at this for time keeping function and didn't find it very satisfying for that application and plan to use it entirely as a watchdog that resets my motes.   I did conclude that you can achieve virtually ANY resistor value with 3 603 5% resistors.  Two in parallel and one in series.  For example in your case, you would have come pretty close with a 5.1K in series with 100ohm.

I wouldn't dare use a WS2812B on a battery operated mote, especially a coin cell mote.  Which library do you use to drive it?  Let us know how that works out!

It looks like good tradeoffs and design.  Congratulations!

Tom
PS:  Interesting set of 'key pads' in the background!   ;)

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Limbus - a low power motion sensor
« Reply #2 on: May 21, 2016, 05:46:45 AM »
Neat project. It's a pity you guys don't make these available commercially. I think they would sell like hot buns.
Maybe as a DIY kit with all the parts in a bag and e nice PCB? It would be a neat project to enter into SMT.
How to you get around the pet problem?

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Limbus - a low power motion sensor
« Reply #3 on: May 21, 2016, 07:14:59 AM »
Great project! Nice form factor, congratulations. Excellent before/after presentation  ;).

Only one thing I don't understand:

Quote
Battery voltage is read through resistor ladder (3.3K and 1K), powered by PNP mosfet (same mosfet as the flash chip).

Without regulator why a voltage divider? Why don't you just measure bandgap against vcc?

What's your experience with these antennas so close to the battery plane? What kind of range do you get?

Joe

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Re: Limbus - a low power motion sensor
« Reply #4 on: May 21, 2016, 07:53:37 AM »
Hi Tom and thanks for the feedback!

About the resistors, nicely figured out! :) I should add footprint for the third resistor in next revisions then. I'm anxiously waiting for your results and experiences with the TPL5010. I also thought about the AB18X5 since it is much more versatile (and little bit lower power too, but at these levels not that important). However it has to be reflow-soldered (because of the damn middle ground pad...) and so it's out of reach for me at this time. Maybe later if I'll buy an oven and start experimenting with reflowing as well. So much to do, so little time :)

Actually the WS2812B seems to work quite nicely with coin cells and despite of the somewhat large quiescent current, the individual LEDs can be run with quite small current (around 0.5-1 mA) and yet are bright enough to serve as indicator lights (with higher currents it's more like illumination). Also the mosfet seems to be unnecessary, so one can drive the led straight from a data pin. Only drawback is that with lower voltages the driver inside WS2812B takes a while to boot (<1ms), so the LED cannot be driven instantly when powered. Actually I'm now gathering data about WS2812B and I think I'll start a new thread for just this topic.

 About battery life.. I experimented with CR2032 and Moteino a while back:
- brownout detection at 1.8V. Battery was Energizer CR2032.
- Every second measure after/before TX voltage. Blink led light. Total 32ms @ 22 mA.
- Send with RFM69W. 4ms @ 56 mA (led was also on during this time)
- rest of the time sleep with WD .  5 uA current.
Avg current is then 0.933 mA. If we assume we can extract 200 mAh from CR2032 (quite optimistic, I know), this would give 214 hours (8,9 days)  up-time. With this setup, I got around 6 days, but in hindsight I had ACKs on, so most likely this downward-spiraled the unit a bit earlier than estimated.   Anyway, this was quite an torture test and in real-life situations things look much better. Even with the same setup just extending the TX interval to 1/min would lead to a uptime of >1 year. And then there's the battery voltage recovery feature with coin cells, so longer idle periods give proportionally even better battery life.
But I do want to repeat the torture test again with Limbus, but this time with WS2812B and see how it fairs.

The keyboard in the background is Ergodox (the left half of it actually) with custom key caps and keyboard layout :)

@Luisr320: Thanks! Selling these would require quite a bit of logistics and user support, and I guess none of us would have time (as hobbyists) to do that in addition to normal day work. Maybe Felix is the only exception :)  But if there's any interest, I'll tidy up the schematics and layout and publish these so you and others can source the PCB and parts and assemble them by yourself.

« Last Edit: May 21, 2016, 08:13:18 AM by Marcus »

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Re: Limbus - a low power motion sensor
« Reply #5 on: May 21, 2016, 08:09:41 AM »
Great project! Nice form factor, congratulations. Excellent before/after presentation  ;).

Only one thing I don't understand:

Quote
Battery voltage is read through resistor ladder (3.3K and 1K), powered by PNP mosfet (same mosfet as the flash chip).

Without regulator why a voltage divider? Why don't you just measure bandgap against vcc?

Thank you! :)

You mean the 1.1V bandgap reference? I do use that, but with it the voltage has to be lowered into 0-1.1V range. Or have I missed something?
Damn, I've totally somehow overlooked the possibility to read the bandgap AGAINST the VCC and not the other way around ;D
http://jeelabs.org/wp-content/uploads/2012/05/04/measuring-vcc-via-the-bandgap/index.html

What's your experience with these antennas so close to the battery plane? What kind of range do you get?

Joe

I haven't done any range or RSSI measurements yet, but I'll look into this soon.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Limbus - a low power motion sensor
« Reply #6 on: May 21, 2016, 11:50:45 AM »
Great work!

But if there's any interest, I'll tidy up the schematics and layout and publish these so you and others can source the PCB and parts and assemble them by yourself.

Yes!  I would definitely be interested in that, as I'm sure others would be too.  The advantage to you is that the project will continue to evolve as folks "give back" feedback and improvements. 

The only other project I'm presently aware of that's directly related to the panasonic detector element is just a small breakout board for mounting the panasonic device itself:  https://github.com/davidk/PanaPIR  So, it's nowhere near as sophisticated.  However, it does highlight something that I and perhaps others didn't fully appreciate earlier which is that these Panasonic devices are more than just purely the sensor element, but instead include a fully integrated motion detection circuit.  So, that translates to not just a small size, but also a reduced parts count, which in turn means  less assembly time than if one were starting with merely a raw PIR sense element.  I had been planning to start with that breakout board and then eventually back my way into a more integrated solution, but if you're able to share the schematic and board files for your project it would really fast forward things.  Alternatively, as an easier project, some might wish to simply wire such a breakout board directly to a Moteino and call it a day.  The high degree of integration built into the panasonic element would perhaps (?)  enable directly connecting a Moteino in that way.

Thank you for posting!
« Last Edit: May 21, 2016, 12:46:01 PM by WhiteHare »

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Re: Limbus - a low power motion sensor
« Reply #7 on: May 22, 2016, 02:37:59 PM »
Great work!

But if there's any interest, I'll tidy up the schematics and layout and publish these so you and others can source the PCB and parts and assemble them by yourself.

Yes!  I would definitely be interested in that, as I'm sure others would be too.  The advantage to you is that the project will continue to evolve as folks "give back" feedback and improvements. 

The only other project I'm presently aware of that's directly related to the panasonic detector element is just a small breakout board for mounting the panasonic device itself:  https://github.com/davidk/PanaPIR  So, it's nowhere near as sophisticated.  However, it does highlight something that I and perhaps others didn't fully appreciate earlier which is that these Panasonic devices are more than just purely the sensor element, but instead include a fully integrated motion detection circuit.  So, that translates to not just a small size, but also a reduced parts count, which in turn means  less assembly time than if one were starting with merely a raw PIR sense element.  I had been planning to start with that breakout board and then eventually back my way into a more integrated solution, but if you're able to share the schematic and board files for your project it would really fast forward things.  Alternatively, as an easier project, some might wish to simply wire such a breakout board directly to a Moteino and call it a day.  The high degree of integration built into the panasonic element would perhaps (?)  enable directly connecting a Moteino in that way.

Thank you for posting!


Hi WhiteHare,

thank you! I wasn't aware of the Panasonic breakout board.  Seems like a nice way to connect the sensor to wireless nodes. I'm frankly surprised that there hasn't been been more Panasonic PIR related projects, since it's been out for few years already in it's quite small, low power and hassle-free little device! Maybe the high price has been putting people off.. 

---------

Now, to the antenna measurements: I have quite small city apartment and around 15 meters is as far as I've done any range evaluation, so I've just used RSSI measurements instead.
The short spiral antenna (in the pictures) has actual length 16cm, identical to the ones that came with 433 Mhz Moteinos. It's a tad shorter than 17.2 cm (quarter-wave antenna),but I guess this was to compensate with the short antenna stubs already on PCBs. I should experiment with different lengths later.

There was no difference between CR2450 and CR2032 devices. I tried the device in vertical position (battery close behind antenna) and layed flat. Antenna itself was vertically in both cases, parallel to gateway antenna. I got however mixed results: On some distances vertical was few dBm better, on other distances the layed flat position was superior, but only marginally. Or maybe the antenna is just so finicky that simply bending it over and over again between those two positions gives different results.  Having the antenna horizontally (perpendicular to gateway antenna) reduces RSSI 8-12 dBm.

Spiral antenna results (RSSI in parentheses):
- 2m line of sight ( -55 to -64 )
- 8m behind wall (-62 )
- 10 line of sight (-73 )
- 10m, inside metallic fuse box (-69 ??)
- 10m, behind thick wall (-79)
- 10m,  inside fridge (-88), occasional packet loss
- 12m line of sight ( -74 )

With straight vertical antenna:
- 2m ( -33 )
- 10m  ( - 50 )
- 10m, inside fridge (- 53)
- 10m, inside freezer (-58)
- 10m, inside microwave oven (-78)

With spiral antenna, I'm able to do OTA updates up to 10-12m (-70 to -75 dBm), and with straight antenna I even managed to update the Limbus that was inside a microwave oven 10 meters across  ;D








joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Limbus - a low power motion sensor
« Reply #8 on: May 23, 2016, 04:31:01 AM »
Thanks! The antenna data makes sense. It's performing pretty badly as I would have expected from the setup. One thing to note: just curling up a l/4 antenna does not give you a tuned antenna. Depending on the shape you need different lengths of wire. So it would make sense to try a longer curled wire and clip it until you get to the sweet spot.

I'm a bit surprised that vertical isn't clearly better than horizontal though.

Joe

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Re: Limbus - a low power motion sensor
« Reply #9 on: May 23, 2016, 04:35:23 PM »
Hello all,

I've published the gerber files and schematics here: https://github.com/WetwareLabs/Limbus/tree/master/Model%20D

I'm by no means any kind of expert with PCB design, so I would be happy to receive any comments and suggestions!  :)  This is actually my second ever PCB produced by manufacturer (Elecrow). Before this I've just etched PCBs for few projects myself, but now getting a 10+ boards delivered in about a week for 8 euros + 21 euros for DHL shipping is a no-brainer..  8)



« Last Edit: May 23, 2016, 04:40:22 PM by Marcus »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Limbus - a low power motion sensor
« Reply #10 on: May 24, 2016, 12:12:08 AM »
Hello all,

I've published the gerber files and schematics here: https://github.com/WetwareLabs/Limbus/tree/master/Model%20D

I'm by no means any kind of expert with PCB design, so I would be happy to receive any comments and suggestions!  :)  This is actually my second ever PCB produced by manufacturer (Elecrow). Before this I've just etched PCBs for few projects myself, but now getting a 10+ boards delivered in about a week for 8 euros + 21 euros for DHL shipping is a no-brainer..  8)

I'm very new to Eagle, but I don't think it can import those files.  Maybe it could import them as separate layers, but I'm not sure those layers would remain correlated in an edit process.  Is your program able to export .brd and .sch files?

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Re: Limbus - a low power motion sensor
« Reply #11 on: May 24, 2016, 12:10:39 PM »
Hello all,

I've published the gerber files and schematics here: https://github.com/WetwareLabs/Limbus/tree/master/Model%20D

I'm by no means any kind of expert with PCB design, so I would be happy to receive any comments and suggestions!  :)  This is actually my second ever PCB produced by manufacturer (Elecrow). Before this I've just etched PCBs for few projects myself, but now getting a 10+ boards delivered in about a week for 8 euros + 21 euros for DHL shipping is a no-brainer..  8)

I'm very new to Eagle, but I don't think it can import those files.  Maybe it could import them as separate layers, but I'm not sure those layers would remain correlated in an edit process.  Is your program able to export .brd and .sch files?

The gerber files are used for PCB manufacturing by production houses, and not really intended to be edited anymore. I'm using ViewMate (http://www.pentalogix.com/viewmate.php ) to view and double-check them for errors before sending for manufacturing.

For PCB design, I'm using Diptrace. I haven't found a good way to export Eagle files, but you can download the free version of Diptrace from their web site. I added the editable schematic, pcb layout and component libraries to my repository as well.

Not trying to start a flame war regarding PCB design programs here, but I have to tell you that few years ago when I got into electronics I tried Eagle, since it was (and still is) pretty popular among hobbyists. But I got frustrated even from the beginning.. Even basic things like moving traces and components felt so cumbersome, not to mention creating new components. Maybe if you're really accustomed to the work-flow it becomes easier, but after few hours playing with it I admitted that I'd rather be sitting at dentists chair than use Eagle. Then I tried Diptrace and I haven't looked back. Everything was so intuitive and easy! It was like browsing internet on modern smart phone compared to how it was with old phones without touch screen :)  I didn't even have to read/watch any tutorials since almost all the functions were pretty self-evident, and I was creating schematics and doing layouts in no time. There was also no need to search for component libraries since component creation is also super easy. Only a few times I had to google how to do to a certain task. Adding custom hot-keys also speeds up the work tremendously, for example "Update copper pour" is useful when modifying the bottom ground plane. (but of course this is not restricted to Diptrace).   </rant>

Anyway, if you're not heavily invested in Eagle yet, I (humbly) suggest that you give Diptrace a try :) (Also KiCad has been getting quite good lately, I heard, if you're into Open Source solutions).

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Limbus - a low power motion sensor
« Reply #12 on: May 24, 2016, 03:53:55 PM »
Hello all,

I've published the gerber files and schematics here: https://github.com/WetwareLabs/Limbus/tree/master/Model%20D

I'm by no means any kind of expert with PCB design, so I would be happy to receive any comments and suggestions!  :)  This is actually my second ever PCB produced by manufacturer (Elecrow). Before this I've just etched PCBs for few projects myself, but now getting a 10+ boards delivered in about a week for 8 euros + 21 euros for DHL shipping is a no-brainer..  8)

I'm very new to Eagle, but I don't think it can import those files.  Maybe it could import them as separate layers, but I'm not sure those layers would remain correlated in an edit process.  Is your program able to export .brd and .sch files?

The gerber files are used for PCB manufacturing by production houses, and not really intended to be edited anymore. I'm using ViewMate (http://www.pentalogix.com/viewmate.php ) to view and double-check them for errors before sending for manufacturing.

For PCB design, I'm using Diptrace. I haven't found a good way to export Eagle files, but you can download the free version of Diptrace from their web site. I added the editable schematic, pcb layout and component libraries to my repository as well.

Not trying to start a flame war regarding PCB design programs here, but I have to tell you that few years ago when I got into electronics I tried Eagle, since it was (and still is) pretty popular among hobbyists. But I got frustrated even from the beginning.. Even basic things like moving traces and components felt so cumbersome, not to mention creating new components. Maybe if you're really accustomed to the work-flow it becomes easier, but after few hours playing with it I admitted that I'd rather be sitting at dentists chair than use Eagle. Then I tried Diptrace and I haven't looked back. Everything was so intuitive and easy! It was like browsing internet on modern smart phone compared to how it was with old phones without touch screen :)  I didn't even have to read/watch any tutorials since almost all the functions were pretty self-evident, and I was creating schematics and doing layouts in no time. There was also no need to search for component libraries since component creation is also super easy. Only a few times I had to google how to do to a certain task. Adding custom hot-keys also speeds up the work tremendously, for example "Update copper pour" is useful when modifying the bottom ground plane. (but of course this is not restricted to Diptrace).   </rant>

Anyway, if you're not heavily invested in Eagle yet, I (humbly) suggest that you give Diptrace a try :) (Also KiCad has been getting quite good lately, I heard, if you're into Open Source solutions).

Thanks!  I'm certainly open to using whatever is easiest.  Earlier, I was tentatively leaning toward learning/using Eagle only because its file format seems the most commonly used.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Limbus - a low power motion sensor
« Reply #13 on: May 24, 2016, 09:33:31 PM »
@Marcus,

Really awesome project that contains some community research and ideas, congrats!
I have been experimenting a little with the Panasonic PIRs. I bought the 1uA one (the long range version with a larger dome) and a 6uA version like the one you use. Here are the various versions of these, I think only the WL and VZ versions are interesting for low power general motion sensing, NapiOn are more specialized:



Here's a comparison between the interesting variants, chinese PIR, and Panasonic long range and short range, full album here:



My setup simply was to replace a chinese PIR in a MotionMote with one of these Panasonic PIRs, and the software debouncing added to the MotionMote sketch for the reason explained below, no other changes.



As far as PROs:
  • all-in-one compact solution (think a lot goes into that plus it has the lens built in)
  • ease of use and pin compatibility (just current and shape difference)
  • low voltage without hacking (like the chinese PIRs)
  • in the month or so of testing so far it seems as reliable as the chinese PIRs (the ones that do work :)))

The CONs as I observed:
  • cost is a big one - the 1uA version is ~$20USD, the 6uA is ~15USD
  • 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
  • no sensitivity or trigger delay adjustment ability, both available on the chinese PIRs

@Marcus, Did you observe the rapid firing of OUT when movement is continuous (many many triggers when someone walks in front of it, or just waving the hand).

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Re: Limbus - a low power motion sensor
« Reply #14 on: May 25, 2016, 09:20:06 AM »
Thanks Felix!

Nice to hear that you have experimented with this PIR sensor as well! How is the battery life now in MotionMotes after the upgrade?

Yes, I did notice that the sensor fires few times when motion is detected. Not really a big deal - I just ignore the output for a few seconds after the initial interrupt.  I didn't even consider this as a bug but a feature, since the firing stops at the same time as motion.

As for the pros and cons, I mosty agree with you. But I don't find the lack of adjustment pots a problem however. In my (not so scientific) testing, I've found out the sensor to be at least as sensitive (reacts to motion) and specific (no false alarms) as manually carefully adjusted chinese sensors. Maybe there's some kind of magical adaptive circuitry inside Panasonic PIRs..