Not sure if others would have interest in this, but I'm designing a PCB for an easy-to-solder TH node. As presently conceived, it would have 3 surface mount components (an LED on the front and a resistor and capacitor on the back), plus a DIP atmega328p, a header to accept an inexpensive si7021 TH breakout board, an FTDI header, and an RFM69HW. The idea is that it would run at 8Mhz and be powered by two AA batteries, so it's sized to be compact but still easy to solder. The same thing could be achieved with wires and some of the other boards out there, but this might be a little tidier if a TH mote is what you want as either the starting point or the end-point.

PCB dimensions are 0.65x2.55 inches. i.e. it is narrower than a typical AA battery holder, but roughly the same length.

The LED and resistor are optional, and you could forego the capacitor as well if you wanted a truly bare bones TH solution. However, the pads are there if you wanted to utilize them. Also, you could skip the si7021 BoB if you wanted just a generic mote.

I had hoped that someone would make an easy to solder board like this for the RFM69HW, but I got tired of waiting and finally decided to just make my own.

I found a good place to do range testing.... too bad I didn't bring the gear!

@OldSurferDude If I have a question about something I generally post the question. Sometimes someone will answer it, and all is good. But on those occasions where no one answers it to my satisfaction, and I later do figure it out myself, then I return and post the answer to my own question. I think if everyone followed this protocol, it would help. What I see across forums (not just mysensors, but just about all forums everywhere) is people who post questions with a "Thanks in Advance" attitude, but who never bother to close the loop if they do find the answer. Or they never confirm whether or not someone's suggestion worked or didn't work. The result is that when searching for an answer, one has to search through a lot of posts which don't contain any useful answers. So, I would encourage everyone to return and post answers to their own questions, if no one else already has, because in all likelihood someone else will have the same question in the future. I think that one small change might make a huge difference.

Good news! Last night I did some accelerated load testing on the supercap. First I charged it to 3.6v and then I hooked up an RFM69HW mote which woke up once a second to do 3 things: 1. check the voltage level, 2. turn on an LED for 1ms to simulate a sensor load, and 3. transmit a packet containing the voltage data using the RFM69HW.. Bottom line: 14,111 packets transmitted before running out of juice.

Not bad for a first attempt.

Yesterday received the PCB. Today assembled for testing this battery-powered nRF52-based passive infrared motion detector:

Made this 12 button keypad. Requires only one analog pin to read which button is pressed, and any button press can also wake an arduino from sleep:

Consumes no power when no button is pressed.

For sure, the store shelves are pretty much overflowing with smart home products and IoT these days, much more than in the past. Is it just diffusion of attention, or do people just buy what they need now in complete systems or something? Or buy stuff that has phone apps instead of a hub? Or has Home Assistant taken over? Or Amazon Alexa? Not much in the way of new postings compared to the past. If anything, I thought there'd be more activity due to more and more IoT interest generally. If anything, it seems like Mysensors has a more robust and complete system now than in years past, and it's broad enough to include just about everything. What gives? Have off the shelf prices dropped so far that the economics no longer favor rolling-your-own or something? i.e. buy rather than build? Where's the new frontier? Is it now AI and system level stuff? I'm really curious. I mean, not all that long ago Google bought a thermostat company (Nest) for over a billion dollars. There's clearly been a sea change, and I'm just wondering what changed.

A pair of lithium AA primaries is hard to beat because:

1. Unlike alkaline's, they don't leak.
2. Have a look at the discharge curve: https://data.energizer.com/pdfs/l91.pdf By the time they drop to 2.4v, if not before, you'll want to replace them.
3. Obviously much longer life, both shelf life (20 years!) and energy capacity.

I think running 8Mhz from the internal RC is a no-brainer: wake up time is less than 4us. So, if your node wakes up often, you'll save a ton of energy over time.

The best time to take your battery measurement is immediately after a Tx. That will give you the most conservative reading. Save that measurement in a variable and then send it in your next transmission. Switch on your ADC just before Tx and take your first ADC measurement during Tx, because you have to throw out the first measurement anyway. That way you can take a fresh (and valid) ADC measurement just after Tx before the voltage rebounds.

Hope that helps!

Here's the version that I most recently assembled:

As you can see, the 15F supercap is now on the board itself. It works fine.

I've since made a few refinements and have sent the new files off to be fabbed. The newest version of the PCB will measure roughly 22mm x 22mm.

On the other hand, the nRF52805 does have PORT DETECT, which appears can provide the basic wake-up functionality at no penalty to current consumption. i.e. total sleep current remains at 0.8ua with full memory retention. AFAIK, that's still better than any of the other nRF52xxx chips Nordic has so far made, and in that one respect also better than what the nRF5340 can achieve. That compares to 0.5ua current draw when the nRF52805 is in OFF mode, with no memory retention, but where PORT DETECT could still be used to wake-up the nRF52805. So, the interesting question remains: how many mah are consumed by going from stone-cold 0ua OFF to full-on? Knowing that, one could compute the tradeoff of going that route vs sleeping at 0.8ua or 0.5ua. If the stone-cold OFF interval is long enough, it will win, and so the only unknown (currently) is how long that interval needs to be to reach a break-even point, and beyond that the energy savings pile up.

One shortcoming of the nRF52805 that I just ran across: it has no LPCOMP. I'm surprised, as it's rather basic functionality.

@Larson About 10 years ago I did it using the A2D on an Arduino Due once for a simple 433Mhz OOK receiver. It worked well enough. Like you, it was my first experience doing such things.

@Larson Although I haven't tried it myself, I have my doubts that a soundcard would work for recording signals sent at 2mbps, if only because that is way outside the spec for normal sound recordings. However, for slow signals, yes, I can believe it would work.

There are also software defined radio receivers that would probably do a good job of receiving and, with the right software, displaying signals. Certainly HackRF One would be one such device that could do it. I haven't tried that either, but it was designed for the purpose. IIRC, Andreis Speiss did a video on using a cheap ($10-$20) SDR to receive and decode some fairly basic radio packets. Maybe it would display them as well.

Bambu Labs has gotten a lot of buzz recently for being super fast and generally awesome.

Epilogue: It turns out that although I'm now able to receive packets on an nRF52 that are sent by an nRF24L01, the payload appears to be gibberish. Argh! So close, and yet no cigar. I thought it worth mentioning for anyone who happens to be following along. I'm fairly sure it must involve those mysterious S0, S1, and LENGTH bit blocks, but as there's virtually no documentation on this aspect of things, a solution will either involve extensive troubleshooting or else locating some relevant code and figuring it out from that. In the end, I'm not sure it's worth the effort. I may just stick with plain vanilla nRF52-to-nRF52 communication, as that much is working fine and without further hassles.

Trying to enlarge some holes on an incorrectly fab'd PCB. I have a 1mm diameter drlll bit, but it turns out none of my drills will hold it--their chucks have a more than 1mm diameter void when closed. I never knew until now, when the chips are down. So, for the future, what drills will hold small bits like this?

As a one-off, I held the bit with a pair of pliers and crudely rotated the PCB around it to drill the 3 holes, but it was awkward and I never want to have to do that again. As a one-off, it did work though.

I finally did receive the boards (4 different designs in all), but on one of the designs PCBway incorrectly drilled 3 of the holes with the wrong diameter, rendering the board useless. I've never had a FAB make a mistake like that before. Because of this, I probably won't be using PCBway again. What a bummer.

I'm trying to remedy the situation by drilling a 1mm hole where they should be, but I'm finding that none of my drills will even hold a 1mm drill bit. Anyone know of a way to drill 1mm holes?

Oh great, the new China lockdown has halted shipments, so my boards are in limbo until China unlocks its lockdown.

I've hit my hassle threshold. I need to find a domestic fab....

I may try this: use an IVR, but the prompt will be "Please spell the first name of the person you are trying to reach." The corresponding number then connects the call. Anyone who really needs to reach me can figure out the prompt, but it should defeat all robocalls and, I'm guessing, most if not all of the human originated spammer/scammer calls. Worth a try, and then judge by the results. If need be, I could add further filtering with a prompt of "Please enter your callback number" And if that still isn't enough, I could add a message of "Please wait for 30 seconds while your call connects" and then add a 45 second delay before ringing for further frustration. Surely that would eliminate the scam callers who have no time for delays, yet still allow through anyone with a legitimate agenda. Meanwhile, family members would be given a secret code that would pass them through immediately and without delay. There are a number of open source IVR software packages, so I'm guessing regular VoIP hardware should interface with it over ethernet. Not sure, but IIRC, with some VoiP there may be a way to reveal the true originating phone number and see if it is a match for the Caller-ID, which nearly all the time is spoofed and therefore a glaring tell. It would make sense that such a way would exist, because a VoiP carrier would need to have a way to charge to the originator the cost of completing the call and plainly would not agree to rely on ordinary caller-id for that purpose as it does not provide a verifiable audit trail. Therefore, the carriers must have this info, and the only question is whether there's an API where that information could be retrieved in real time. I can think of no reason why it would be privileged information that would be withheld if specifically requested. Indeed, if it isn't free for the asking, there's probably a model where the carrier would gladly provide it by charging extra for such information.

If this works, then I may get an additional VoiP number and only give that out instead of my actual cell phone number. Then, if possible, I'd program my cell phone to only accept filtered calls forwarded to me from that VoiP number. This way my cell phone would be also filtered.