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!

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.

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.

Put together this pro mini nRF24 shield for testing...

I have a number of sensor projects that sit within the nice footprint of a Pro Mini. Now I want to find a kind of universal power platform--hopefully small--to power them. So far, what I came up with was this, which runs the Pro Mini from 2xAAA batteries, and where the Pro Mini (and whatever the project built on it) simply "plugs in" to it:

Is there anything better? Ideas? Comments?

It worked! After doing the above mass erase, the nRF52832 Ebyte Module successfully programmed from the NRF52 DK. I uploaded the mysensors lightsensor sketch, and the serialGateway running on the NRF52 DK is receiving its messages.

Many thanks to mfalkvidd for his mass erase suggestion and for his link to the Roger Clark youtube video, which had further mass erase commentary.

Also, many thanks to d00616 for his excellent guide:
https://www.openhardware.io/view/376/MySensors-NRF5-Platform
Without that, I would have been lost on how to set anything up.

Thanks to everyone else too who made comments and suggestions. This has been a great group effort with a successful outcome.

@Mishka Well, since you ask, I think the EM8500 would be interesting to try: https://www.emmicroelectronic.com/sites/default/files/products/datasheets/8500-ds.pdf

I only recently discovered it, but the datasheet says it can self-start with an input voltage of 300mv and a mere 3 microwatts. Once started, the datasheet says it can continue functioning on as little as 100mv and 1 microwatt. It also claims to include MPPT.

The other one that would be interesting to try would be the EM8900, which can self start with an input voltage as low as 5mv, which is, AFAIK, the lowest of any available commercial chip.
https://www.emmicroelectronic.com/sites/default/files/products/datasheets/8900-ds.pdf
However, for a solar cell as small as your solar bit, it would require extra circuitry to operate it in burst mode, because at 5mv the micro-ampere requirements would likely exceed what your solar bit could deliver on a continuous basis. It's the same issue as with the LTC3108: https://www.openhardware.io/view/732/Extreme-Energy-Harvester

I haven't yet tried a solar cell scavenged from a solar calculator, but that might be interesting to try as well, since presumably those are well designed to work with indoor lighting and have been perfected over decades for that use since the 1970's. Unfortunately, I don't know of any that can be purchased outright instead of as part of a solar calculator, like say the FX-260 or similar. Maybe someone reading this knows of a source?

Though it's cheating, the last option would be to use a long-lived button battery purely to avoid cold-boot scenarios and to manage the collection of real solar power during those times. I imagine that such a battery could be quite small if limited to that type of use. Some such batteries might last as long as 40 years, such as Tadiran. That said, if it were deprived of light for long enough, it would probably run the battery down sooner than desired, so I don't like this option.

@monte I think it may run into the same barrier I encountered with both uPython and FORTH and uLISP. I got them all to do FOTA with nRF52, which is easier because they are interpreted, but in none of the cases could I easily leverage the wonderfully extensive arduino sensor libraries because those are written in C. Apparently there do exist ways to do it with linkers and such, but I wouldn't classify it as easily done. More like "easier said than done." uLISP would have been the easiest to adapt C-libraries, but it's a slow inefficient implementation of LISP, so that was a downside. Although practically anything can be made to work given enough time and effort, there's something to be said for staying within the Arduino framework so as to minimize time and effort.

That said, maybe your idea is different. Sometimes it's hard to really know until you explore it a bit.

@Nca78 Just FYI, I looked into attempting a FOTA on the nRF52 but at the time I didn't feel as though I had enough easy-to-follow information to do it within the limited spare time available. I think adafruit may have some kind of FOTA for the nRF52 with their circuitPython project, but that language's runtime is awfully slow compared to C or FORTH.

@zboblamont Ah, you got bit by my main reason for not liking Domoticz: Domoticz would be so much more useful without that 5 minute minimum between recorded datapoints. It's a wonder they've never fixed that.

@Nca78 Looked at another way, once installed and sealed up it will also be a sort of time capsule.

@Calvin-Khung a black magic probe would allow you to do that.

@alowhum said in Everything nRF52840:

From what I heard Pine was thinking about upgrading the watch to the NRF52840?

Maybe so. Their website does say: "Note: Final revision may use higher powered hardware including the nRF52840 and/or 16 MB of storage rather than 8 MB."

On the other hand, what's currently on sale in their store is an nRF52832: https://store.pine64.org/?product=pinetime-dev-kit

@Nca78 Good point! I guess one could take the shell and components and insert a custom pcb that uses nRF52840... But that would be extra work. A pity they didn't go that route in the first place.

It does look perhaps a bit big:

@monte Is PineTime the best of the currently available nRF52 watch options? If so, since it's offered at $24.99, I think I may want to order one.

@TRS-80 said in Best choise for a controller:

It is generally regarded as being stable and well supported on the BSDs since a long time now. But I am a GNU/Linux guy. Ubuntu is of course based on Debian, but I dislike Ubuntu project for many reasons and consider it a meme operating system (IMHO why not just use Debian?).

Yes, I'm on the same page as you regarding all the points you mentioned in this passage. Otherwise, a few years ago I would have simply learned BSD and its implementation of ZFS.

I'm at a point where I'd rather not keep waiting indefinitely though.

Thanks for the links! I'll give those a read.