Thanks @berkseo!

Have been enjoying your work with nRF52 designs.

Also on my list is trying the built-in capacitive touch capabilities of the chip.

I can @ you if I get anywhere with it - might come in handy for your capacitive touch glass mini switch to save you a few components?

Very nice @Fanfan!

Love the power protections - those would have saved me a few nRF24s in the past!

How have you found the ceramic antennas?

I’ve been wondering whether to add pads to mine for experimenting...

@monte Re: FTDI Boards & Bootloaders.

I didn’t write the bootloader myself from scratch, but modified and combined various elements from Nordic’s SDK v11 example, SparkFun’s development version and Adafruit’s Feather version.

It was quite a nice learning experience of hacking in bootloader land and dealing with event-driven architectures without any low level debugging skills (yet!) - that’s why I’m now trying to get into SWD/JTAG debugging to make things like this easier.

I certainly don’t understand everything that’s going on, but “loosely” from what I can figure out, it uses Nordic’s proprietary SoftDevice (S132) combined with some custom bootloader code to boot into a predefined state, where it’ll wait for new “image” either over a serial or bluetooth connection.

The new “image” can be either your regular sketch-type code (referred to as the “application”), a new SoftDevice (S212, S332, etc.) and/or even a new bootloader.

Once the new “image” is received and validated by the (existing) bootloader, it is copied to replace the existing “image” parts where necessary and the chip is reset.

Nordic’s pc-nrfutil command line utility handles interfacing with any standard FTDI board over a COM port (mine is an old SparkFun, but any should work) to perform the upload.

In SDK11, there isn’t much in the way of safeguards, but in SDK15 there are things like cryptographic signing, custom initialization packets and protocol buffers, etc.

I did have to make one tweak to the nrfutil Python code, to make it wait a little longer after opening the COM port before sending the DFU initialization packet. This might be unnecessary with optimized bootloader code, I don’t know, since the nRF52832 boots pretty quickly.

I could go on, but I’m still learning myself, and so if you or anyone else has any other questions, comments, suggestions, etc., perhaps we better move them to a new discussion thread? (Just tag me in so I see it…)

Thanks for your interest though!

@nagelc Thanks! The clip on programmer is one-part Adafruit’s FTDI “Fiddy” from here, and one-part SparkFun’s old (retired?) 3.3 or 5v selectable FTDI programmer with a custom 3D printed enclosure.

I plan to modify the “Fiddy” design a bit as there were some elements of it that I’ve found a bit frustrating. However, YMMV. Gotta love pogo pins for programming though…

Re: Board envy. Really? Well, if you like, I could do what I did on my last project - which was selling the leftovers. At the moment, I always make more than I need, for testing and some much needed practice with the smaller 0402s. Just send me a chat message if you (or anyone else?) are interested.

Continuing along the theme of one of my last projects, I built a nRF52832 into a 328p Pro Mini footprint. Made two versions: One with some edge SMA or U.Fl pads and another with a PCB trace antenna:

I wanted to start getting into using 32-bit microcontrollers (ARM Cortex varieties like nRF5x, SAMDs, STMs, etc.) for some more complex HA and other electronics projects and am trying to ease the learning curve from all my 8-bit ATMEGA experience.

Keeping the 328p pin-compatible footprint and PCB size means I can still reuse most of my other Pro Mini project boards to get going. An added bonus is the nRF52's ability to remap (almost) any pins, which will no doubt come in handy.

They’re both two layer boards and I get pretty decent range out of the PCB trace antenna - ever so slightly better RSSI than EByte’s E73-2G4M04S1B, which was surprising since I didn’t really do anything different (that I’m aware of) and their module is shielded too.

Since there’s no need for a separate nRF24 board and other associated components, like external SRAM or ATSHA, it’ll possibly save me a few $ too! Power pins next to the (remappable) I2C pins make some of the sensor modules (like SI7021) pluggable.

I also gain 16x the program memory (512K vs. 32K) and 8x the speed (64MHz vs. 8MHz) which is no small increment!

Some of the project boards I have made use of the Pro Mini 328p’s FTDI pins, so I added a few components to enable the use of an FTDI programmer with custom DFU serial bootloader.

Basically, a DTR pin toggle from the FTDI will reset the nRF52 into a state where it’ll briefly listen for a new program - similar to Adafruit’s Feather. You can also force that state for a longer period with a combination button press like Nordic and SparkFun’s development boards.

I’m unfamiliar with SWD/JTAG programming/debugging and all things GDB/OCD, so I built myself a black magic probe out of a STM32 blue pill and am going to have a play with all of that, along with VS Code and PlatformIO and probably one or two others.

MySensors nRF52 support worked out of the box (!) - so a huge thanks to all the hard work of the folks round here for getting that up and running. If there’s anything I can help with there, please let me know and if I’m able, I’ll try to take a stab at it (OTA maybe?). Like I said, I’ve got quite a steep learning curve here though.

On the low power end, I added the DCDC components Nordic recommend too and managed to get the MySensors smartSleep() current down to around 0.7uA - as per the datasheet, I think. However, I found that with a couple more code tweaks and grounding the SWDCLK, I would get into the nA region. This seems a bit out of spec to me and perhaps it’s just a measuring error, but it was repeatable and the board still happily sending data/heartbeat again each time it woke up. (It’s fluctuating around 1.6nA below - no sensors connected though, but it’s a start…)

One other project in the back of my mind is using this board as the basis for a quadcopter, but that’ll probably have to wait until the summer holidays…!

Thanks for the kudos, @dbemowsk. Right back at you for your scene controllers; I’m trying to get into 3D design myself, but can’t justify the time commitment right now.

Re: Do you have these on OpenHardware.io?

No, sorry, that would require me to be far more organized than I am at present!

Maybe if there was enough interest, I could justify putting in the time to clean things up enough to publish… But it is valentines today, so any tinkering will surely be met with an icy stare if I try it tonight!

Re: Can fully functional boards be purchased somewhere? I would be interested in trying a few out if possible.

Really? I’ve never done something like that before. You do realize these are very much “alpha” right? I mean, I’ve tested the majority of the pins, but nothing like proper production hardware verification or anything. Having said that, it’s not like there’s anything complicated going on.

I managed to dig out four spares this afternoon that I’m not using from the last batch I made - how many would you like?

Three have a 1284p attached and one has the regular 1284 - I believe the only difference is the 1284 doesn’t have BOD, but I normally turn that off anyway for a (probably) miniscule power saving. I haven’t installed the crystal oscillator or reset switch yet. I don’t normally do that until I know what the use-case is. I believe I have enough spare 16MHz and 20MHz ones to fit (maybe some 8s) and some SMD reset switches too.

The only other thing would be the bootloader. I could flash the standard MySensors DualOptiboot?

So, if you (or I suppose anyone else for that matter) are interested, just shoot me a chat message via my profile and we can figure things out off-thread, as this is a bit off-topic now.

Thanks again for the interest - even if you don’t buy - made my day!

That looks awesome @alexsh1!

Nicely laid out and cleanly soldered. Was that with an iron or hot air (or both)? Nice clear silk too; I like the power and “signal” symbols. Did you ever try a FOTA update with it? Or a low power/speed profile?

I see you went a bit wider and longer than the standard Pro Mini, (I’m assuming) to get at all the pins and add the extra regulator, LEDs, etc.

I was constrained by needing something that fit the same footprint for existing boards I already had, e.g. other “motherboards” I’d made similar to @sundberg84’s excellent Easy/Newbie PCB or wanting pin-compatibility for stacking boards like the ATSHA+EEPROM+Radio+ICSP one below:

I tried routing with the chip at a 45 degree angle too but couldn’t get a DRC to pass with the pads so close to the PTHs. I may try again with shorter (custom) TQFP pads...

Re: 1284p’s downsides of cost and size.

I know. I ended up justifying it to myself this way:

We can all get cheap 328p Pro Minis from Ali for around $2. The vast majority of my Pro Mini projects are battery powered, so there’s some “labor cost” to disable the power LED and remove the regulator. But regardless, I certainly can’t make myself a low(er) power Pro Mini for $2 - the OSH Park PCB alone is probably close to that.

I think the cheapest I ever got 1284p chips for was around $2.50, again from Ali. My “Pro Mini XL” PCBs were around $1.70 from OSH Park, add a sprinkling of 0402s, etc. and we’re probably at around $5.

I couldn’t find any 1284p-based boards near that price. The closest I got was Kevin’s Mini Duino, which is another lovely looking board, but doesn’t fit my need for a Pro Mini-constrained size and pin-compatibility. Essentially, I was after something close to a drop-in replacement.

So, $2+ versus $5+ for all the benefits (at least as far as I was concerned) listed above? It became a bit of a no-brainer.

And on the low power front, I profiled the MySensors library sleep command on it at around 5uA on 4.5v @ 20MHz using an external full swing, around 4uA on 3v @ 8MHz and around 3uA on 1.8v @ 1MHz Internal RC Osc:

Those numbers are certainly good enough for all my current applications - no pun intended!

But I would like to look at the 32-bit contenders as potential replacements.

I’ve seen nRF52s with 512K for around $2 on Ali, so maybe I’ll try my hand at a Pro Mini nRF52 or something similar eventually. The board above was a fun challenge, and afterall is what this is (mainly) about for me.

Built a 1284(p) into a 328p Pro Mini footprint. Not sure what to call it, a Pro Mini XL maybe?

I now have x4 the program memory (128K vs. 32K), x4 the EEPROM (4K vs. 1K) and x8 the SRAM (16K vs. 2K) all in a 328p Pro Mini pin-compatible (I think!) footprint of about same size.

I can also run at 20MHz vs. the usual 8MHz provided I’m prepared to run it at 4.5v and above.

Had to sacrifice a few pins and components, but might be able to put various selections back in future revisions. Nothing major (in my opinion) just components associated with the regulator really. I also went for a crystal (not installed yet, on order, LEDs too..) over a resonator - just a personal preference for when timing is critical.

And yes, those are 0402 SMDs. I actually did them by hand (!) with a microscope and a judicious amount of coffee; a fine-point iron, solder wick and flux became my best friends.

So far, I’ve had it working with nRF24s and RFM69s radios, ATSHA for personalization and external flash for FOTA. The DualOptiboot bootloader code and makefile needed a bit of tweaking, but nothing major.

I broke out the JTAG I/F but haven’t played with that yet and also added power pins next to the I2C to make some of the sensor modules (like SI7021) pluggable - see below.

I also want to play with the QTouch library support for built-in capacitive touch buttons, sliders, etc.

Why not just go with an ARM (STM32, SAMD, nRF52)?

I’m working on it! ;o)

Am not wanting to start a(nother) 8-bit vs. 32-bit discussion. I’ve got an AliExpress package of 32-bit MCUs coming (very) slowly to me. When it arrives, I’ll start experimenting and exploring - probably with the nRF52s, since those seem to be the flavor-of-the-month and very capable-looking chips...

But until then, I need more program memory!
(Among other things…)

@acb

So, I’m answering my own question a little here after digging into the gateway/node logs and code - and so I'm replying to my own post.

Should FOTA work with personalized nodes/gateway?

Yes, it should and it does. FOTA (and any other internal commands) works with personalization (signed commands) using the MYSController.

What doesn’t appear to work is if you’re using smartSleep and asking the MYSController app to trigger sending your internal command upon receiving from the node - in this case, simply a heartbeat from smartSleep.

Does that make sense?

So, if I don’t sleep the node, I can issue reboots and other internal commands that are signed, no problem.

As soon as I switch to using smartSleep(DURATION) instead of wait(DURATION) and ask the MYSController app to trigger sending, for example, an internal reboot command “Upon RX”, then the reboot command never makes it to the node before it goes back to sleep. So the gateway tries to send the queued command, but the node has already gone back to sleep, and so it gets ignored.

I’ve tried varying the smartSleep duration as well as the MY_SMART_SLEEP_WAIT_DURATION_MS define.

I haven’t tried varying the MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS define, but it didn’t immediately appear that this was a transport connection issue.

It looks like the gateway/node do all their NONCE request/response just fine, but it could be something to do with how all that gets queued and ordered.

Doesn’t look like it has anything to do with ATC at all, since I’ve tried enabling/disabling on both node and gateway.

Also doesn’t look like it has anything to do with the new driver, since I’ve tried both the old and the new and get the same behaviour.

The only difference appears to be the way smartSleep interacts with signed messages.

I’ll keep digging, but if anyone has any ideas what I might be doing wrong here, I’d appreciate any help or advice.

Thanks!

Quick question: Should FOTA work with personalized nodes/gateway?

If the answer should be yes, then I appear to have a problem…

As soon as I enable signing and signature requesting, the node will no longer respond to any internal or stream commands (e.g. Request Presentation, Reboot, Firmware, etc.) made via @tekka’s MYSController app. I haven’t tried anything else yet.

The node still happily sends signed sensor data to the gateway and they ping-pong with heartbeats, etc.

And as soon as I disable signing and signature requesting, the node will respond to all those same commands, quite happily rebooting, updating the firmware, etc.

So, am I doing something wrong?

(MYSController Version: 1.0.0beta, b3316. MySensors Library v2.3.1)