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

[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. :stuck_out_tongue_winking_eye:

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. :thinking_face:

[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. :smile:

[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.