Novice requesting PCB review and advice for a window / door sensor

[BearWithBeard]

Quick links to posts with major updates

• 14 Dec 2018
  First revision with a much more compact design and an Attiny84 variant
• 7 Jan 2019
  Second revision with more functionality, but without increasing the PCB size
• 25 Mar 2019
  PCBs arrived, ATmeg328P-based device is built and fully working

---

Original Post

Hi there,

I’ve started discovering the world of electronics through Arduino about three month ago and decided recently to get a little bit more serious about it. I’m designing my first custom PCB which should be used as a base for a little door / window sensor with an Atmega328P as its heart and the MySensors library as its soul.

I’m hopeful to find some knowledgeable guys over here, who could have a quick look at my design, point out flaws, give advice. That’d be awesome!

Before we go into the details, let’s have a quick look at the schematic and layout:

Schematic

Top layer

Bottom layer

The GND on the top layer as well as all VCC routes are 20 mil wide, all other signals are 8 mil wide. Clearances in DRC are 8 mil for everything. The bottom layer has a large ground fill, which I tried to keep as clean as possible.

Part List

• U1: Atmega328P-AU
• U2: DRV5032FB
• U3: NRF24L01+ (SMD module)
• C1, C2, C3, C4, C5: 100 nF Y5V MLCC
• C6: 220 µF 6.3V electrolytic
• R1: 10k Ω
• R2: 68 Ω
• 3V CR2032

Concept and functionality

By designing this board I had three main aspects in mind:

• Should be able to run for (many) years off a single coin cell
• Keep it as small as possible … (currently ~ 2x the size of an Arduino Pro Mini)
• … but still solderable by hand (no parts smaller than 0805)

The circuit goes into power-down mode by default, where it should consume ~ 2 µA (plus whatever leakage current might be introduced by the capacitors, I expect no more than 1-2 µA extra based on my own tests) - I measured ~ 1.5 µA on prototypes I’m currently running, which feature a mechanical reed switch instead of a digital hall effect sensor. When the hall effect sensor detects a change (window opened or closed), it wakes the Atmega via interrupt on INT0. The MCU then sends the current state along with the voltage level over the radio module to the master node and goes back into power-down mode.

Speaking of the hall effect sensor: the DRV5032 is a ultra-low power sensor from TI, which can be powered between 1.65 and 5.5V. The FB-variant is omni-polar and particularly economical, as it operates at only 5 Hz and has a push-pull output which means that no external pull-up resistor is needed, bringing its current consumption down to an average of 0.7 µA or less at 3V and below.

You are almost certainly already familiar with the good old Atmega328P and the NRF24L01+ radios, so I won’t waste no words on them.

Now that you have a basic idea of my thoughts and goals, let’s get to the fun part:

My questions / concerns / uncertainties:

1. DRC check yields zero errors, except for the through hole mounting points of the battery holder (marked in purple on the layout screenshots), which are quite close to the edge of the board. That should pose no problem, should it?

2. Regarding ceramic capacitor positioning and their capacity: I’ve tried to get each MLCC as close to the corresponding GND and VCC pins of the components they belong to, so that they create their own little "current loop". The sensor, MCU and radio each get a single 100 nF capacitor. Is that sufficient?

   Is it advisable to add a second 100 nF cap to the AVCC / GND pair on the right side of the MCU (marked in yellow)?
   [EDIT: The AVR Hardware Design Guide clearly states "For devices with multiple pairs of power and ground pins, it is essential that there is a decoupling capacitor for every pair of pins" and "To improve the accuracy of the ADC, the analog supply voltage must be decoupled separately, similar to the digital supply voltage", but I see that many people don't do so and by trying to keep it simple, I thought it is worth the question anyway.]

   The 220 µF electrolytic cap should protect the coin cell from sudden current spikes when the radio is in transmission mode and should be able to deliver most of the current during this time, so I don’t think the radio needs another ~ 10 µF MLCC near it, does it?

3. I would like to make use of the FOTA functionality of the MySensors library - not because I expect to change the code frequently, but just in case, for convenience - but I didn’t have time to mess with this yet. So the question is, if I need to be able to upload the actual sketch physically / wired for the first time - like with ArduinoOTA for the ESP8266, before you can use the wireless upload? If not, I’d gladly remove the serial header entirely.

I might also remove the LED, as I probably won’t use it in the final build to save power - I’m currently using them on the prototypes to see when and for how long they wake up. With the saved space I might either try to make this thing even smaller or a little more versatile by adding additional headers for I2C / SPI instead.

Thanks for your attention and patience if you actually read everything!

[huex]

looks good ,
but sot23 maybe needs to be a specific direction. or TO-92s?

[mfalkvidd]

@bearwithbeard I don’t know much about pcb design but the serial header could be useful when debugging/troubleshooting so personally I would prefer that at least the tx pin is available. Some people have used pogo pin connectors to save space.

[dbemowsk]

I thought it was more common for the ISP header to be 2 rows of 3 pins instead of a straight 6 pins? Not that you can't make that work.

[flopp]

U1, you have a lot of GND-area underneath the atmega328, it may be possible that a pin close to this area will touch the area and you will get a short circuit between a pin and area.

[BearWithBeard]

Oh, answers! Thank you guys, appreciated! I've changed the layout quite a bit since I started this thread. I've also already ordered PCBs for them. But more on that later, let me get to your messages first:

@huex said in Novice requesting PCB review and advice for a window / door sensor:

looks good ,
but sot23 maybe needs to be a specific direction. or TO-92s?

Uhm, you are talking about U2, the hall effect switch? Since it has two pins on one and only one pin on the other side of the package, I don't think it can be soldered the wrong way around.
Or are you talking about the orientation in relation the the magnetic field? As far as I understand the data sheet, it doesn't matter if the sensor is mounted horizontally or vertically. The only requirement seems to be that the magnetic field is perpendicular to the top of the package - and its strength of course.

@dbemowsk said in Novice requesting PCB review and advice for a window / door sensor:

I thought it was more common for the ISP header to be 2 rows of 3 pins instead of a straight 6 pins? Not that you can't make that work.

Yes, you are correct, a 2x3 header would be preferable, so that you could simply plug your standard adapter on it. The reason for the single row in the design was to save horizontal space and it also allowed a much cleaner routing of the signals to the NRF24.

@mfalkvidd said in Novice requesting PCB review and advice for a window / door sensor:

@bearwithbeard I don’t know much about pcb design but the serial header could be useful when debugging/troubleshooting so personally I would prefer that at least the tx pin is available. Some people have used pogo pin connectors to save space.

I understand your point. But IMHO debugging and troubleshooting should take place on a breadboarded version before switching to a rather permanent solution like this.

I will have a look at those pogo pins, thank you!

@flopp said in Novice requesting PCB review and advice for a window / door sensor:

U1, you have a lot of GND-area underneath the atmega328, it may be possible that a pin close to this area will touch the area and you will get a short circuit between a pin and area.

The ground area on the top PCB layer underneath the MCU would be covered by a soldermask. So, as far as I understand, it shouldn't be possible to short a pin with this area, as long as the mask isn't scratched off or improperly applied by the manufacturer. Am I wrong?

The updated layout

As I says earlier, I made some changes to this project. Here's a quick summary:

I've designed an additional variant with an Attiny84

I'm waiting for parts to arrive to test the setup with the Attiny, but I'm confident it will work. If it will, it reduces the total cost per device by ~1.2 Euro / 1.35 USD, allows for a ~7mm narrower package and makes it easier to solder.

I've decided to exchange the 220 µF electrolytic cap for a 10 - 22 µF MLCC.

This should significantly reduce potential battery capacity losses through leakage current a "bad" electrolytic cap could introduce. It should also be sufficient to cushion the initial current spike when the NRF24 enters transmission mode and will also step in faster as the electrolytic cap would be able to.

Status LED and serial header removed

I simply saw no need for those parts anymore. Using the LED as a “I noticed that you closed / opened the window”-status indicator would add another 10 - 20 mA for a few ms and - let’s be honest - nobody would want to stare at the sensor whenever they open or close a window to see if it detected it, they would simply expect it to work. Letting it light up periodically in case of a fault or as a low battery indicator, drains to much battery juice and would better be handled in the backend / by the server, I think.
Keeping a separate TX pin, as @mfalkvidd mentioned, might be useful along with a jumper to optionally enable debugging output, I guess. I might add that in a later revision. Makes more and more sense the longer I think about it.

I quickly made some screenshots of the top layers of each version:

With Atmega328P

With Attiny84

With all those changes, I was able to shrink the PCB to roughly the size of two CR2032 coin cell holders: 24 x 43 mm for the Atmega variant and 24 x 36 mm for the Attiny variant. Pretty happy with that.

Your comments and opinions are still appreciated!

[Nca78]

Hello, and congratulations for a first PCB you seem to have carefully thought it out.

@bearwithbeard said in Novice requesting PCB review and advice for a window / door sensor:

DRC check yields zero errors, except for the through hole mounting points of the battery holder (marked in purple on the layout screenshots), which are quite close to the edge of the board. That should pose no problem, should it?

It will depends of the capabilities of the PCB maker, you should adjust the rules file used for DRC accordingly.

Regarding ceramic capacitor positioning and their capacity: I’ve tried to get each MLCC as close to the corresponding GND and VCC pins of the components they belong to, so that they create their own little "current loop". The sensor, MCU and radio each get a single 100 nF capacitor. Is that sufficient?
Is it advisable to add a second 100 nF cap to the AVCC / GND pair on the right side of the MCU (marked in yellow)?

I would add one, it's not a lot of work and it will give you more stable power source for ADC when you measure battery voltage.

The 220 µF electrolytic cap should protect the coin cell from sudden current spikes when the radio is in transmission mode and should be able to deliver most of the current during this time, so I don’t think the radio needs another ~ 10 µF MLCC near it, does it?
The one close to the radio will help for the noise and it can be necessary for the current spikes depending on the distance with the main capacitor.
Regarding your last post with updates your reserve cap is too small, with around 3V on the battery pin you need to derate the capacity by around 50%, there were many posts related to button cell on the forum, and advice from reputable sources was to use around 100uF MLCC.

I would like to make use of the FOTA functionality of the MySensors library - not because I expect to change the code frequently, but just in case, for convenience - but I didn’t have time to mess with this yet. So the question is, if I need to be able to upload the actual sketch physically / wired for the first time - like with ArduinoOTA for the ESP8266, before you can use the wireless upload? If not, I’d gladly remove the serial header entirely.

You need to burn a specific bootloader to manage FOTA, so you need headers. As said before, it's also useful for debugging with serial output, make tests like power consumption depending of different programming options, etc.

Regarding LED you don't need 10-20mA, if you use a small SMD led it can go well below 1mA and still produce a decent amount of light, I use around 200uA with a 0603 green led of one of my boards and the light is pretty bright.
Led can also be used to warn of errors, for example different blink count/duration based on an error during initialization, like when it can't find parent etc

Last thing, I would avoid traces and components next to the antenna. The ICSP header is in a very bad position imho. Your bottom layer seems nearly empty, I would move the battery holder to the bottom layer and translate all components to the left so that ICSP header is no more next to the antenna area.
I would also add a ground pour on top layer.

[BearWithBeard]

Thank you very much for your answer, @Nca78!

Sorry for another lengthy post. I try to keep it short but still being relevant and informative. Feel free to skip to the section(s) that interest you.

Regarding the additional capacitor to deal with the current spikes

When I started this thread, I also cobbled together two prototypes that I attached to the same door.

• 3V CR2032 coin cell (Sony)
• Atmega328P-PU with two 0.1 µF ceramics and 10kΩ pull-up on reset
• NRF24L01+ with one 0.1 µF ceramic
• 3mm led with 1kΩ resistor as an indicator
• mechanical reed switch with a 1M Ω pull-up resistor

They are both identical, except for one additional 220 µF electrolytic cap (it’s a nichicon ULD series cap) on one device in parallel to the battery to compare how this affects reliability and the battery consumption. (I also asked a question on the ElectricalEngineering StackExchange on that topic if you are interested: Protecting a coin cell from high current spikes - using a capacitor or not?)

Have a look at this graph that displays the measured voltage over time. (Ignore the spikes at the beginning - that was me being stupid).

You might notice, that there is no significant difference in the development of both units. If anything, the unit with the cap might drain the battery just slightly faster than the other. Now imagine if the devices were attached to a window, which typically gets opened no more than 2 - 4 times a day, as opposed to a door of a frequently used room, the discrepancy might be more noticeable since the duty cycle is much lower / time between wake ups much higher, possibly resulting in the (electrolytic) cap being the largest load of the device.
But I have to admit that I have no long-time data. It is possible, that the capacitor might make a huge difference once the battery voltage drops below 2.3V or something like that.

But is the device with the capacitor more reliable (so far)? Well, have a look at another boring graph:

This graphs displays a dot whenever a device woke up and transmitted a state change over the course of two days. (I made the blue dots a little bigger because they have a lower z-index / are visually behind the yellow ones). Looks like there is no event that has been reported by only one device.

I know, it’s just my personal experience and observation and doesn’t mean much. I guess, it wouldn’t hurt to use a 100 µF MLCC instead of a 10 - 22 µF one, considering that their leakage current is way, way below that of a good electrolytic cap. But regarding the current MLCC shortage - getting your hand on a decent 100 µF MLCC isn’t easy nor cheap. A quick look at Mouser reveals twelve MLCCs with a voltage rating of 6.3 VDC and only one with 10 VDC or above at stock (only looking at 0805 and 1206/1210 packages). Most of them only in 3-digit quantities with prices over 1 EUR / 1.15 USD or more per 100. Not the best time to go that route. Adding up a bunch of smaller capacity ones might be a decent workaround (but requires getting another revision of the board manufactured first, while the first hasn't even arrived yet ).

Antenna and ICSP positioning

I tried to keep any copper away from the antenna - maybe I can do a better job, that’s true. I also don’t plan to solder headers onto it if you are worried the pins might interfere with the signal.

Low power LED

Could you please suggest / link a LED such as you are using? Just to give me an idea what to look for regarding their specs.

Placing the battery on the bottom layer

I’ve thought about that, too. And it would make sense considering the large ground plane on the bottom that I am currently connecting to the battery through three little vias. But there’s only ~17mm of depth on the windows in my house where I’d like to fit in the device as well as the magnet. The thickness is probably the most critical dimension of all. I’ll take this into consideration - another point on my to-do list.

[Nca78]

@bearwithbeard said in Novice requesting PCB review and advice for a window / door sensor:

I know, it’s just my personal experience and observation and doesn’t mean much. I guess, it wouldn’t hurt to use a 100 µF MLCC instead of a 10 - 22 µF one, considering that their leakage current is way, way below that of a good electrolytic cap. But regarding the current MLCC shortage - getting your hand on a decent 100 µF MLCC isn’t easy nor cheap. A quick look at Mouser reveals twelve MLCCs with a voltage rating of 6.3 VDC and only one with 10 VDC or above at stock (only looking at 0805 and 1206/1210 packages). Most of them only in 3-digit quantities with prices over 1 EUR / 1.15 USD or more per 100. Not the best time to go that route. Adding up a bunch of smaller capacity ones might be a decent workaround (but requires getting another revision of the board manufactured first, while the first hasn't even arrived yet ).

You can have a look here for some explanation about calculation of capacitor value
http://www.ti.com/lit/wp/swra349/swra349.pdf

I didn't buy capacitors recently, didn't notice the availability/price problem, this is creepy, I'm happy to have stocks.
I just check on an order made last year on Arrow, only 2 cap references are still available for sale, one is 80% more expensive, the other over 300% more

[momo90]

Nice Project! Are You planning to share the gerber files and the code?
I would need 15 of them in my new house

[BearWithBeard]

Thanks again, @Nca78. I must have skipped the capacitor dimensioning part when I read that white paper a while ago.

Fiddling around with some numbers both at the lower and higher end of their expected scale, yes, 100µF seems to be a save capacity to go for.

And let's be honest - since I'm planing to use a MLCC instead of the electrolytic cap there is no (technical) reason to leave it out or undersize it.

Thank you @momo90!
Yes, I intend to do so once I got them up and running.

[huex]

well,,i buy some hall effect sensor as EM-1781-T5,HAL2481L,ES248L, work well,but battery cost too much for me ,the EM-1781-T5 consume least,atmega328p 1MHZ with sleep nothing sensors 7.8ua，work with EM1781 sleep 16ua，when Magnetic near，cost 22ua, .......so ....i think Although it provides a more accurate and wider range of sensing, it consumes much more than a reed.

[BearWithBeard]

Hi @huex,

you might want to give the DRV5032FB from TI a chance, which I've listed in my opening post. The data sheet states an average power consumption of 0.69µA at 3V.

I only found a Japanese data sheet for the EM-1781 (which you mentioned as the sensor which has the least current consumption), but as far as I understand, it specifies an average consumption of 6.5µA at 1.85V. At 3V it is properly even more. That's ten times higher than the DRV5032FB.

The DRV5032FB should consume less than a reed switch, since it doesn't require pull-ups to keep the interrupt pin from floating. Even with a rather high 1MΩ resistor you'd look at ~3µA at 3V using a reed switch.

Also - Let's not forget that reed switches tend to bounce which needs to be counteracted in software or it triggers multiple times. Both cases increase power consumption since the device spends more time in an active state. They are also a mechanical part - the more often you use them, the higher is the chance that they fail.

I still think, overall, a hall effect switch is the better option for this application

[huex]

@bearwithbeard
YEAH，because difficulty get dr5032FB in my region，more 20HZ with 3v like DRV5032AJD,DRV5032ZEDBZR ,DRV5032FA Available ，maybe other similar low power and low voltage chips ?

[BearWithBeard]

No, unfortunately there are no equally suitable alternatives I know off. There's actually only one that meets these requirements:

• Supply voltage at least between 2V and 3.3V
• Average current consumption < 2µA
• Push-pull output
• Preferably omnipolar

The closest alternatives I know of are the Honeywell SL353LT and the Diodes AH1911. The former can only operate down to 2.2V unfortunately and the latter, while meeting all requirements, drains 1.6µA in average, which is twice as much as the TI chip consumes - but it might be a good alternative for you if it is more easily available in your region.

[Nca78]

@bearwithbeard why would you need to go below 2.2V if you're powering your board with a CR2032 ? At 2.5V it will nearly be dead already, with only a few % of capacity left.

And a NO/NC reed switch can be used to have very low power consumption, and at every change of status you switch the pin you are watching with the interrupt. It's a 0uA standby power consumption, but I still prefer the DRV5032 because of the small size and robustness, reed switches are bulky and fragile, especially the NO/NC with their dual pins on one side.

I have looked a lot and didn't find anything better than DRV5032, second best choice is indeed SL353LT. If you don't have any source for your region you can still order at lcsc, they have a few (7). Unfortunately their DRV5032 are not FB versions, but they have a push-pull version in stock so you will get the same power consumption as SL353LT. If I'm not wrong all versions can go as low as 1.65V so it's suitable for you. There's nothing lower than 1.5uA except the drv5032FB.

[BearWithBeard]

@nca78
As I stated in the opening post, I’ve just started getting into electronics and programming a few month ago - I don’t know a lot, but I try to try to get the best out of if. (And that’s also the reason why i’m always thankful for advice, critique and suggestions.)

In general, I thought it would be a good idea to use components that are capable to work in a wider voltage range than the power source can provide, instead of the other way around.

I am aware that most of the usable capacity of a CR2032 is exhausted long before it drops down to 2V. But at the same time, almost all fabricators state that they consider the battery to be “dead” at 2V. So, with the little experience I have, I ask myself, why would I want to waste the ~5% capacity that is left between 2.5V and 2V from the beginning? This might be a few weeks or even just a few days of extended lifetime, but it comes at no extra cost.

Maybe I should consider looking for alternatives to a CR2032 that don’t increase the overall size and complexity of the circuit too much. Using a CR2450 (~600mAh) would increase the overall thickness by merely 2mm, but increase the expected life time by a factor of ~2.5. Boosting a single LR03 to 2.5V or 3V might not be worthwhile despite its relatively large capacity.

And a NO/NC reed switch can be used to have very low power consumption, and at every change of status you switch the pin you are watching with the interrupt.

I have only worked with regular NO reed switches - didn’t know there are SPDT-type reed switches available. Nice! Then again, if you buy this kind of reed switches from reputable distributors instead of noname grab bags from China, they cost (a lot) more than a DRV5032FB (Mouser lists them between 2.7 and 10+ USD a piece) and you still have to deal with all the disadvantages of a reed switch that have already been mentioned.

---

Oh, btw - I just stumbled upon the Honeywell SM351LT / SM353LT. Works between 1.65 - 5.5V and is advertised with an average current consumption of ~350nA.
I guess, that can only be achieved when supplied with a very low input voltage since the data sheet states a sleep current of 0.2µA at 1.8V and 2.6µA at 5.5V. Too bad it doesn’t provide numbers for 3V.

On top of that, with a sensitivity of 7 resp. 14 Gs it would be possible to use very small magnets. Even a tiny 3x2mm N38 grade neodymium disc magnet would be strong enough to trigger at a distance of 10mm.

[Nca78]

@bearwithbeard yes I notice you make a lot of efforts to study all the options, I'm impressed of the care you put on your board !

And yes it's always a good idea to take some margin but how much lifetime will those 5% get you ? Somewhere like 1 month for a 2 years battery life, it's not really a game changer. What I meant is it's probably better to chose a sensor with a tiny lower power consumption and 2.2V instead of 1.8V as it will save more energy than you can gain with those last 5%.

I agree with you for the other battery options, CR2450 is a big increase in battery life and if you accept to have one dimension of at least 30-32mm (battery + radio antenna clear from it) then it's worth it. There are ultra low power boosters like TPS6109x that provide better battery life from a single LR03, but it is relatively expensive (few extra $) and takes around 1sq cm of board space (IC, inductance, 3 caps, 2 resistors). So it fails on most of the points: higher complexity, higher cost, and much more bulky with AAA.

Thank you for the tip for SM351/353, I didn't knew about it. Sensibility is really impressive, I have already added some to my list for my next purchase, I will test and report the consumption at 3V. Hope it's closer to the one at 1.8V than 5.5V, but I'm not optimistic when I see the quick increase from 1.65V to 1.8V (9% more voltage = 25% more current).

And for the reed switches, yes not worth all the pain to save at best 0.2-0.3$ if you buy them from AliExpress.

[BearWithBeard]

Sorry for taking so long to reply. I’m spending some quality time with my family these days and try to relax a bit. I hope you all can share some time with your loved ones as well.

@nca78 I agree with you that it would be better to choose a sensor with a lower power consumption, if it can only work down to 2.2V. I implicitly assumed that there is no sensor that’s more economical than the DRV5032FB, which happens to work down to 1.65V or something, so I chose it as my benchmark. Sorry for not making myself clear earlier!

Regarding the Honeywell sensor: I quickly put the sleep current values from the datasheet in a spreadsheet and plotted a graph trough those points. Assuming the current increases uniformly, we should expect 0.67µA at 3V, in which case it would match the DRV5032FB in terms of power consumption. Let's hope it's not far off from that, because the higher sensitivity would make it the better choice if that's needed.

And again, thanks for your participation. Really appreciated.

---

In the meantime I’m slowly making progress on a “rev 2” board that also implements some suggestions that came from you guys. I aim to post an update before the new year begins.

[BearWithBeard]

It took me a little bit longer to post an update, but I decided to spend some more time with my family and focused on another project for a while. Hope you've all had a good start into the new year!

I made quite a lot of changes to the PCB and incorporated ideas and suggestions from you guys.

As always - feel free to skip whatever section you don't care about or just read the headings to get a "tl;dr" version of the changes.

Schematic and PCB layout

Schematic

Top Layer

Bottom Layer

The routing around the Attiny's pins almost looks like I'm working with a single-layer PCB, but I can't use vias except for GND in this area as the coin cell occupies the whole backside (and several (inexpensive) PCB manufactures seem to be unable to make tented vias and cover them with a solder resist mask). I guess those fancy "spirals" around the left-hand pins won't cause any issues.

Trace width for GND and VCC is still 20 mil. All other signals are now 9 instead of 10mil.

There are some airwires visible between some of the VCC signals. I guess EAGLE doesn't understand that the four VCC through-hole pads of the battery holder are physically connected. If anyone could tell me how to deal with it, that would be greatly appreciated!

(And yes, yes. That lonely resistor on the back looks so sad and silly. But it's the position with the shortest routes and least vias I could come up with, so it seems to be the best solution.)

List of Components

• U1: Attiny84A-SSU
• U2: TI DRV5032FB or Honeywell SM353LT
• U3: NRF24L01+ SMD module
• R1, R3: 10kΩ (0805)
• R2: 680Ω (0805)
• D1: Kingbright 2 mA, 150mcd, 40 deg, red Dome-LED (1206)
• C1, C2, C3, C4: 0.1µF 50VDC X7R MLCC (0805)
• C5: 100µF 16VDC electrolytic cap (e.g. Nichicon UMA series)

I will focus on the Attiny variant for now

I prefer using the Attiny84 for several reasons over the Atmega328P for this project - it allows to make the overall device a little bit smaller, gives more options for routing signals and costs less than half of an 328P, which feels wasteful to use with most of its pins unconnected.

I will most likely go back into EAGLE and design a variant for the Atmega328P as well before I'm going to order PCBs the next time so that I get a batch of both anyway - but I don't want to continue working on two variants simultaneously while major changes are likely.

Ground plane on both PCB layers

As suggested by @Nca78, I've also added a ground plane on the top layer this time.

But I'm unsure if this has any consequences for the decoupling capacitors and their corresponding power pins. Doesn't it "break" their current loop? Why would it be considered bad if the plane would be VCC instead? (I definitely need some good reading on this topic.)

Status LED included

@Nca78 pointed out that there are SMD LEDs that can produce a bright spotlight with very little power.

Mouser doesn't seem to have any LED in their catalogue with a current consumption <2mA that's larger than 0402. So the one I chose to include is a 1206 dome-LED from Kingbright which reaches a luminosity of 150mcd at 2mA in a 40° cone. LEDs with similar specs seem to be easily available. I think that should do the job.

Added serial pins and a jumper

Originally, I didn't want to add a serial header at all, as it would take up way to much space on the PCB. But @mfalkvidd made me think about a simpler solution: Adding RX/TX pins to the already existing ICSP header.

This allows for on-demand debugging functionality via software serial if pin 12 is pulled high through the jumper. If the jumper is disconnected, pin 12 will get pulled down to ground and serial functionally will be disabled, going back to normal operation mode and reducing power consumption to a minimum.

At this point, I don't worry about auto-reset functionality, since the Attiny84 with its 8kB of flash memory hasn't enough space to fit a bootloader besides the actual program.
That's a consideration to take into account with the Atmega variant.

Increased distance between antenna and copper

The new design leaves much more space between the antenna of the NRF24 module and any part of the circuit (at least 5mm). The closest metal part will be a M2 bolt that attaches the board to the enclosure.

Using an electrolytic capacitor as a buffer instead of a MLCC

Well ... I went forwards and backwards many times whether to use an electrolytic cap or an MLCC. After all, I concluded using an electrolytic cap is the most sensible solution. Here's my (lengthy) explanation for it:

• (Large capacity) MLCCs are increasingly difficult to acquire and their prices are going up as well. There is no guarantee that I - or anyone else interested in this project, as private individuals - can get an affordable MLCC in a specific SMD package in a reasonable amount of time. Items that are in stock today can be sold out by tomorrow, with lead times of "53 weeks".

• The actual capacitance of MLCCs is largely dependent on the applied voltage in relation to its rated voltage (DC bias, some background info). This means that a 100µF MLCC rated for 10VDC might store a charge of only 40 - 70µF when supplied with 3V (average values I've gotten by looking through the online databases from murata and TDK). This would require the use of a MLCC that has a higher nominal capacitance or possibly, depending on the specific part, a higher rated voltage, which has its "sweet spot" at around 3V. But those cost easily 5 - 25 USD / Euro a piece. That's not sensible at all.

• Last but not least: Reading a paper from a German battery manufacturer ("Leakage current properties of modern electrolytic capacitors"), I concluded that using an electrolytic cap in battery-powered applications might not be as bad as one might think.

  AVX apparently released a paper very similar to this, but unfortunately it doesn’t seem to be (publicly) available anymore. Rubycon writes in a technical note that the specified leakage currents are higher than they actually are, “because it takes too much time to measure the true leakage current”.

  Summarizing, the specified leakage current in a capacitors data sheet is usually far above the actual operating leakage current that should be expected when a voltage is applied to the capacitor continuously. It is generally by a few factors lower than specified, even more so when the supply voltage is far below the rated voltage (TDK, p. 17) - for a 100µF 16VDC cap and a specified leakage current of up to 3µA that is supplied with 3V, the operating leakage current should settle between 100 and 250nA.

  Plus, my experiment with the two prototypes I mentioned in an earlier post seems to back the point that the leakage current of (decent) electrolytic caps isn't a huge deal in low power applications as one might think, since both devices seem to drain the battery equally.

Considering that 100µF 16VDC electrolytic caps with a total height below 5.5mm are - other than similar MLCCs - rather cheap and widely available, it seems reasonable to stick with an electrolytic cap as a buffer.

After all, the limiting factor regarding the total uptime of this device isn't the technology of the buffer capacitor - it's the self-imposed constraint in regards to the overall dimensions of the device, thus opting for a tiny CR2032 coin cell. Choosing a slightly larger power source will absolutely have a much bigger impact on the battery life as any kind of capacitor could have.

Yes, the best possible capacitor might increase the battery life by a few weeks or even two months - a CR2450 instead of a CR2032 would increase it by years.

For the sake of completeness, there are also specific "low leakage" electrolytic caps available like the UKL series from nichicon which specify a leakage current of less than 0.2µA after two minutes. Unfortunately, with a minimal size of 6.3mm x 11mm they are a bit too large for this project.

Moved the battery to the back of the PCB

Making use of the fact that I go back to using a electrolytic cap as a buffer, I can mount the battery as well as the cap to the back of the PCB - as well as the 90° angle pin header for the jumper that otherwise wouldn't fit on the board.

This makes the device ~2mm thicker (~9mm total thickness) than mounting everything on the top of the PCB (~7mm total thickness) but I can keep the board dimensions of 24mm x 36mm despite adding more components. Having all the thick components on the back also means that the hall effect sensor is as close to the front of the enclosure as possible, reducing the distance to the magnet.

The CR2032 can easily be replaced by a CR2450, which has a three times higher nominal capacity, without increasing the overall device thickness and only increasing the PCB height from 24mm to 27mm - I just have to commit to using a specific coin cell holder model to adjust the contacts on the PCB accordingly. Until then, I'll stick with the CR2032.

---

That's it for now. Your comments, ideas and suggestions are highly appreciated, as always. Thanks for your attention!

[momo90]

@bearwithbeard said in Novice requesting PCB review and advice for a window / door sensor:

Honeywell SM353LT

Really a very nice, well planned sensor. Respect! I really like the Attiny variant!

But at least in my country some of the components are really hard to get (U2, C1 - C4). Sure mouser is delivering worldwide, but the shipping costs are pretty high.

You placed the hall sensor in the middle of the board.To be honest I dont have much expirience with hall sensors (I'm using reed switches). The ideal allignment for the sm353lt is in the same plane as the magnet. How are you going to place the pcb and magnet at a window or door?

[BearWithBeard]

Thank you @momo90!

But at least in my country some of the components are really hard to get (U2, C1 - C4)

Yes, I'm aware that the DRV5032(FB) isn't widely available. In fact, as far as I know, none of the electronics distributors in my country list them neither. That's why I decided to order from Mouser - they also offer free shipping worldwide for orders above 50 Euro / 60 USD. But there's also Digikey, Arrow, LCSC,.. who stock them.

I might compile a list of suitable alternative sensors that can be used instead, sometime in the future.

C1 - C4 are interchangeable with basically any other 0.1µF 0805 MLCC with a rated voltage of 6V and above. Because the device is intended for indoor-use, the temperature stability of the dielectric isn't too important. And DC bias doesn't seem to be a huge problem with these small capacities in 0805 packages.

The ideal allignment for the sm353lt is in the same plane as the magnet.

That's true and I have to admit that I haven't given much thought about the Honeywell sensor yet. Still, the datasheet also states, that the magnet can approach the sensor perpendicularly (i.e. from the front), but with a reduced sensitivity. I guess it's best to test and verify this physically.

How are you going to place the pcb and magnet at a window or door?

I think it is best to illustrate that with a drawing (sliced through the center, dimensions and alignments are just approximations):

The PCB will be attached to the non-movable frame of the window with the top of the sensor pointing into the room. The magnet will be attached to the window itself. The yellow arrow indicates the movement of the magnet.

Positioning the hall effect switch exactly in the center is convenient, because then it doesn't matter if you attach the enclosure with the antenna in the upper right corner or rotate it upside-down - just position the magnet above the center point and you're good.

Positioning the sensor on the left or right of the PCB means that you need to care about orientation, especially with both left- and right-hinged windows.

It might be worth considering to swap the sensor's position with the ICSP header (or with the electrolytic cap alternatively, moving it to the center and attaching the board upside-down). That would allow to place the magnet much lower, which might help making it less conspicuous when the window is opened.
I guess this would also allow to align the magnet in the same plane as the sensor, in case of the Honeywell SM353LT.

[momo90]

The way you want to mount the sensor could cause, that the sensor doesnt realise that the window is tilted. Because if you tilt the window, the magnet is still in front of the sensor.

I always put my window sensors beside the window in the upper corner of the window. So the reed is open when the window is tilted or completely opened. And therefore my reed switches are on the side of the sensor.

Sorry for my bad english, I hope you understand what I mean...

[BearWithBeard]

@momo90

I think I understand what you mean. But I don't want to place the sensor on the side of a window, because when two or even three windows are next to each other, there's not enough space to put the sensor in between. In my house, there is a gap of 22mm between two windows.

I currently have some reed switches mounted above windows - similar to the drawing from earlier - and they detect both open and tilted windows just fine.

The way you want to mount the sensor could cause, that the sensor doesnt realise that the window is tilted. Because if you tilt the window, the magnet is still in front of the sensor.

Yes, the magnet is still perpendicular to the sensor, but further away from it. If the sensor doesn't detect that the window is tilted, the magnet is too strong and a weaker magnet should be used instead. There are calculators that help to find a suitable magnet for a specific distance to the sensor.

[Nca78]

@bearwithbeard said in Novice requesting PCB review and advice for a window / door sensor:

Status LED included
@Nca78 pointed out that there are SMD LEDs that can produce a bright spotlight with very little power.
Mouser doesn't seem to have any LED in their catalogue with a current consumption <2mA that's larger than 0402. So the one I chose to include is a 1206 dome-LED from Kingbright which reaches a luminosity of 150mcd at 2mA in a 40° cone. LEDs with similar specs seem to be easily available. I think that should do the job.

I just used cheap 0603 leds from AliExpress, green color, with high value resistor (2K) to limit current, and it still produces a good amount of light. I will test again with empty board and only led + resistor to be sure, and report here.

[BearWithBeard]

@nca78

Oh, really?! I would have guessed that the light from such "cheap LEDs from AliExpress" would be barely visible when combined with a high value resistor. I bought some assortments of leaded LEDs from China a while ago, just to have some at hand to tinker about - some of which aren't even bright enough to tell if they are lit indoors at daylight (especially green LEDs) when using a small 220R or 330R. Contrary to "branded" LEDs I've got from local distributors (probably the benefit of having an actual datasheet with specs).

SMD LEDs might be a totally different thing then, regarding luminosity. Or the case size matters (smaller -> higher concentration -> tiny dot, but very bright).

... or I simply ordered garbage.

[BearWithBeard]

Wow, what a journey it was! As you might know, I ordered my first batch of PCBs at the end of November 2018. At the end of February 2019, I still didn't receive them so I contacted the manufacturer. After some back and forth they agreed to produce and ship my next order for free. In the beginning of March, I placed a new order with the "new revision" of the sensor. This time it took less than two weeks to arrive.

And there it is: My first proper build!

Banana One Euro for scale.

I'm quite happy with it. The circuit is functional and SMD soldering turned out to be a lot easier than I imagined, even without any prior practice. This gives me a decent confidence boost in designing and soldering future projects.

The board fits neatly into a 3D printed enclosure (55.5 x 27.5 x 11 mm). No mounting screws necessary. The magnet is seamlessly embedded in a tiny single-part enclosure (11 x 8.6 x 4.8 mm).

The combination of the DRV5032 and a 5x3mm neodymium disk magnet is perfect. The window is considered "open", when the gap between both enclosures is 8mm or more, and "closed", when the gap is at most 4mm wide. Awesome!

But there are also bad news...

You might have already noticed that the image above shows an ATmega328P, not an ATtiny84. But why? There are two issues with it:

• The ATtiny84 is lacking some hardware features, or has them implemented in a different way than the ATmega328P, and MySensors makes use of them. The results are compiler errors. For example, MySensors uses SIGRD (Signature Row Read) to retrieve a unique hardware ID for the device and EIFR (External Interrupt Flag Register) to clear pending interrupts. Unfortunately, this seems a little bit too advanced for me to address with my current knowledge.
• The ATtiny84 provides SPI functionality through USI. If you want to use the SPI protocol to communicate with other devices (a radio for example), as opposed to programming the chip itself, the MISO / MOSI connections apparently have to be swapped around (I didn't test this yet, but DO is on the same pin MISO and DI on the same as MOSI). This means, that my ATtiny84-based PCBs most likely won't work unless I cut the MISO / MOSI traces and rewire them with some jumper wires. Pity!

Since I have 25 ATtiny84A-SSUs laying around, I would still love to address these issues some time in the future. Without MY_DEBUG, the program is ~7950 bytes small and fits on the ATtiny84. 512 bytes of EEPROM (MySensors seems to use up to ~410 bytes) and another 512 bytes of memory (the program uses ~350 bytes) seem to be plenty, too.

What I learned, what I would change

Still, I call this project a success so far and I learned a lot in the process. I want to conclude this update with a list of lessons I learned, things I would change or might add in a further revision.

Lessons learned

• Don't reinvent the wheel. When I first started, I wanted to do everything myself, but I quickly realized that's not the right thing to do, especially if you're new to it. Yes, you will learn everything from the ground up, but you won't ever finish anything satisfactorily. Making use of tools like MySensors, on which many smart people worked for years, allows you to learn while doing practical things and keeping your motivation high. But don't blindly copy & paste either. Use it as a foundation.
• Don't rush it. Research thoroughly, read the fluffing manuals. It really helps to plan ahead and make yourself familiar with the technical and environmental constraints and requirements of your project, the characteristics of the components you want to use, and so on. Overall, I think I did well and have been amply rewarded with a fully functioning ATmega328P-based device. But at least the SPI issue of the ATtiny84 could have been addressed before ordering any PCBs if I wouldn't have been so naive to blindly believe that it would "just work".
• Don't freak out if you accidentally create a solder bridge or if a component slips out of place. Take a deep breath, apply some flux and try again. You will fix it.
• When you are compiling your program, make sure to set a proper CPU clock frequency via F_CPU or else you might end up in an infinite loop of trying to fix things that aren't broken. Whoops!

Possible changes, ideas for further revisions

• To allow more flexibility regarding the choice of components, I'd like to include a pad for a MLCC that could optionally be used instead of the electrolytic capacitor. It would also be great to allow the installation of other coin cell holders with a different footprint.
• A basic reverse polarity protection would be great, but I need to find a solution first, that doesn't suck the battery dry while the device is sleeping, nor causes a huge voltage drop.
• Get rid of the debug jumper I introduced with the first revision. When I thought about adding it, I was still working with a MySensors-free program, in which I wrote my own debug messages. With MySensors, I feel custom debug messages are not necessary and on top of that, debugging is toggled via a preprocessor directive (MY_DEBUG), which can't be toggled at runtime.
• Consider replacing the LED with a bi-color LED that can be driven using two I/O pins for success and error indication.
• Add RX/TX pins for the Atmega328P-variant. Besides allowing debugging without soldering thin wires directly onto the MCUs tiny legs, it would allow to upload a bootloader and enable serial programming, and thus OTA updates.
• Add a second set of VCC, GND and INT0 pads or pins where jumper wires can easily be soldered onto. Instead of using the hall sensor to trigger an event, one could attach a simple daughterboard for a button and turn the device into a smart home button / Dash button clone for on-demand automation.

I don't know if this is the end to this thread or not, but I want to thank you guys again for listening and helping. And who knows - maybe somebody can find bits and pieces in here that they can take away for their own projects.

[Nca78]

Congratulations @BearWithBeard, that's a great achievement, especially from someone supposed to be a "novice". I'm sure many can learn from your lessons, the most important one to me is "don't rush it", it goes with "triple check schematic then board", "unit test your components" and "don't finish late at night". Else you will probably end up with mistakes on PCB and a lot of wasted time.

For reverse polarity protection, I think this is the more simple solution:
https://forum.mysensors.org/topic/5478/how-to-get-longest-battery-life/25

[BearWithBeard]

Hi guys,

I have already shared my observations regarding the electrolytic capacitor in another topic, but I thought it would be a good idea to document it here aswell and have it all together for future reference.

Recap

Using an electrolytic capacitor in ultra low power applications

Both my experiments with THT prototypes and the final device reveal that there is no harm in using an electrolytic capacitor. Without a doubt, it is better to use one than no buffer at all.

• Do electrolytic capacitors drain the battery faster?

  No, the leakage current is practically so low, that it is negligible.* After almost a year, the CR2032 coin cells in the three prototypes which only differed in the choice of the electrolytic capacitor (Nichicon, Chinese noname and no cap at all), were still at ~3.05V, with a delta of merely 30mV between them.

  *See my earlier post in this thread for more background information and links to literature regarding leakage current.

• Can I leave them out then?

  No, you should not leave them out. They increase reliability by providing stability to the voltage level. While I couldn't detect any difference in reliability under "laboratory conditions" with the three prototypes, things changed with the finished device in real world scenarios: Placing two of them on a window on the other side of the house, far away from the gateway, I noticed that one of them, on which I didn't solder a capacitor, failed to reach the gateway reliably with the default setting of #define MY_RF24_PA_LEVEL RF24_PA_HIGH. Changing this setting to RF24_PA_LOW resulted in both nodes being unable to reach the gateway at all - they were to far away for this power setting. However, soldering a capacitor on the second device and keeping the PA level up, resolved the reliability issues completely. This effect might be even more noticeable, the further the coin cell is discharged.

• Which capacity does it need to have?

  A coin cell has a comparatively high internal resistance of about 10 - 20 ohms over most of its usable capacity which will cause a relatively large voltage drop during high current pulses. For comparison: alkalines are typically below one ohm.

  Taking measurements (with a fresh CR2032) revealed that the voltage dropped ~550mV when no capacitor is used, ~250mV with an 100µF electrolytic capacitor and ~200mV with a (physically much larger) 220µF during transmission, which suggests that 100µF is a good compromise in capacity and physical size, if you are space restricted. If you can though, opt for a much larger capacitor, as the voltage drops will increase the further the battery is discharged, due to the rising internal resistance.
  To put this into perspective: The CDEbyte E01-ML01S (compact NRF24 SMD module) has a power consumption of 13 mA for TX/RX at 3.3V. A typical send() function takes about 80ms on average to complete, so we can estimate an energy demand of 0.0035 Joules per sent message. A 100µF capacitor on the other hand can only store about 0.00045 Joules at 3V or about 0.00031 Joules at 2.5V. So, if you want to hold enough energy for a whole send period, you would need a ten times larger capacitor.

I'm not saying electrolytic capacitors are the best choice in this application, but they may be the best compromise in case other technologies are too expensive or hard to source.

How did everything else pan out?

• Initially, I planed to program the devices with dupont wires skewed through the PTHs, but I found the connections were way to flimsy and unreliable. I had already ordered some pogo pins and 3D printed a little spring supported jig (similar to this) which clamps the pogo pin tips firmly into the holes. So I highly recommend, if you don't want to solder headers on a though hole connector like this, build something that provides a solid, stable contact for programming.
• Another initial problem was, that I couldn't get the first device to operate properly and because the TX pin wasn't exposed, debugging it wasn't easily possible. I ended up soldering a thin wire directly onto pin 31 (TX) on the ATmega328P to get serial output, which was far from ideal. In every new design, I will make sure to always provide a way for debugging, be it a dedicated header, or atleast a test pad, if the space doesn't allow for more.
• The footprint of the CR2032 holder is a custom design which I made specifically for the part that I had at hand. In hindsight, I'd prefer to keep footprint designs generic if possible instead of designing for a specific part, to allow substituting them with slightly differently designed models.

Other than that, everything went quite smoothly. The first node based on my own PCB is now running for 337 days nonstop and has reported 6754 events since then, which averages to roughly 20 wake-up cycles per day. The CR2032 is currently at 3.02V. I expect it to keep working at least another year, but only time will tell!

---

Revision 2

I have since redesigned the board and ordered a new batch of PCBs, which should arrive soon (hopefully) and if all goes well, I will share it on openhardware.io. While the board dimensions stayed the same, the new version has more functionality and allows much more flexibility in the selection of parts.

• There will be two variants to accept both the generic Chinese SMD version of the NRF24l01 module (GND on pin 2), as well as the CDEbyte E01-ML01S (GND on pin 8).
• The minimal distance between the antenna and any parts or traces has been more than tripled - from ~2mm in the old design to >6.5mm in the new.
• Most of the 1206 and 0805 parts are now 0603, which saves a good amount of space and I'm confident, that anyone who can solder a QFP chip by hand, will also be able to solder 0603 components.
• An improved battery clip footprint should be compatible with most THT sheet metal retainer with four pins and SMD variants with 4 small or 2 wide contacts.
• An additional 1210 footprint near the electrolytic capacitor allows to use a large capacity MLCC instead as a buffer. Two or more MLCCs might be used if the electrolytic capacitor's footprint is... creatively misused.
• Optional reverse polarity protection (for the coin cell only) can be used with a suitable P-channel mosfet (Vishay SI23##, Toshiba SM3J3##R, Diodes Inc DMP1045U-7,...).
• Optional encryption / hardware signing support with a SOT-23 ATSHA204A. Because of space restrictions, I opted not to add a footprint for a dedicated decoupling capacitor.
• Two footprints for LEDs instead of just one allow color coding for different indications. With the dimensions of the enclosure in mind, the LEDs are also exactly centered in both dimensions (symmetry <3).
• The hall effect sensor is now also exactly horizontally centered and as close to the edge of the PCB as possible. That means that the sensor should now be able to detect the presence and movement of a magnet in more positions (needs to be verified) and the magnet housing can be smaller. I intend order some Honeywell SM353LT and perhaps some other sensors in the near future and test them aswell.
• An additional footprint for an optional pull-up makes it possible to use different hall effect sensors, if the DRV5032FB is hard to acquire for some folks.
• The 2x3 2.54mm-pitch programming header has been replaced with a SOICbite footprint. Granted, for a device, that is intended to be accessible, this is an awkward choice. But considering that it only requires about a third of the space, while providing 8 contacts instead of 6 and a suitable SOIC-8 programmer clip is available for less than 3 USD, I though I'd give it a try. It's an experiment. And if it turns out to be a bad decision - quickly soldering on a bunch of wires to program the device, which is usually a one-off job, isn't the end of the world. I also intend to post a review of my experience with a SOICbite after testing it.
• And last but not least: having two spare pads on the SOICbite footprint means that two additional signals can be routed there. I opted for TX/RX to simplify debugging if required.

[mfalkvidd]

Very interesting, thanks for sharing your insights and thoughts!

@BearWithBeard said in Novice requesting PCB review and advice for a window / door sensor:

quickly soldering on a bunch of wires to program the device, which is usually a one-off job, isn't the end of the world

Have you considered programming the mcu in a separate jig before soldering it?

[BearWithBeard]

No, I didn't seriously consider it. I have a minimal programming circuit with ZIF-sockets to program DIPs, but those are easily removed from a circuit (assuming they are put into sockets and not soldered) in case they need to be reproprammed . Doing this with a TQFP seems like a one-way road, so I think a way for in-circuit programming should be provided regardless.

I mean, I didn't have to reprogram my first revision nodes so far, but I might want to add signing support later on or upgrade to MySensors 2.4 or 3.0 for some reason, so it should definitely be possible, but I'm not too worried, if the programming process is a little cumbersome, if the SOICbite experiment doesn't work out.