Mike Rankin Turns His Tools Towards the nRF52832 BLE MCU!

Of all the ESP32 projects I've seen, I've been most impressed by some of the work that Mike Rankin turns out.

His polished approach to even the most napkin sketch of ideas consistently turns out hardware with a professional feel not only to its implementation, but the documentation that goes along with it, and his latest design is no exception, save only for choice of MCU running the show!

While Rankin is normally to be found turning out projects based around the Espressif Systems ESP32, his latest board features one of my favorite series of MCU — the Nordic Semiconductor nRF52 series — specifically, the nRF52832 Cortex-M4 BLE MCU!

I guess the idea of a test is to get some answers, and this test board from Rankin looks set to suitably explore nearly all the functions of the nRF52832, letting him get to grips with the operation of the device.

More than just a simple breakout board, however, this little prototyping platform is tricked out with some pretty nice peripherals making it suitable as a standalone device for a number of applications!

Let's pick through what's up for grabs, as detailed in the schematic below!

Quite a capable core...

Let's start at the beginning — the central part of this PCB is unquestionably the MCU core, based around the very capable nRF52832 MCU, from Nordic Semiconductor!

While also available in WLCSP packaging (some 3 mm^2 in footprint!), this 6 mm^2 QFN48 package part packs quite a punch, not only in processing power, but in peripherals to pick from.

It's Cortex-M4 CPU is clocked at 64MHz, and has plenty of memory made available to it — some 512KB of flash is complemented by up to 64 KB of RAM, allowing for some serious applications to be developed on it.

Being a Nordic MCU, this part is going to feature some Bluetooth connectivity, but that's not all it offers on the wireless front. On top of BLE, it also sports BLE Mesh functionality and NFC (the same technology used when you tap a payment card, or with your phone, to complete a purchase).

On the digital front, this part has all the usual suspect for interfaces available — UART, SPI, TWI (Two wire / I2C), I2S and PDM — the latter two are going to come in very handy for any audio applications you might find yourself developing!

But there's no USB on the nRF5283...2.

Not to worry, that UART interface we mentioned is piped into a CP2104, from Silicon Labs — one of the de facto choices for a USB-UART converter in the wake of FTDI gate.

The community really did seem to lose a bit of trust in FTDI after that driver debacle, but I digress...

The nice thing about having a USB interface on board is you also have a handy 5V supply from which to power your project.

Not content with operating only while tethered — and who could suggest otherwise for a BLE enabled board! — Rankin has also seen to it that the USB supply is used to provide a rail for powering a SL4054ST25P Li-Ion battery charger, from Techfuse.

This is a new part to me, but deserves a mention here due to its pricing — some $0.05 in qty of 10, from LCSC. 5 cents for a battery charger IC? That's a tip worth keeping in the play book!

It's also nice to see a reference here for how to implement a simple, cheap power source prioritization, with Q2 — a FDN340P, P-Channel MOSFET used to select the USB supply in preference to the battery rail — the last thing you'd want to do with a Lithium cell would be to have it sharing the system Vcc, when it's up at 5V... 😬

So, if we're going wireless, we'll need a bit of a HMI, in place of a terminal prompt.

How about a 96 x 16 pixel monochrome OLED, interfaced over I2C? That ought to do the trick!

So far, we've got all the building blocks of a versatile BLE device in place. A BLE-capable MCU, with a rechargeable power source, and even a graphical display!

Not content with that alone, Rankin has also thrown in a HDC1080 temperature and humidity sensor from Texas Instruments. This solid state device keeps a tab on the relative humidity and temperature of the environment it is exposed to.

As these two factors alone play a significant impact in the comfort of the indoor air we spend most of our lives in — before considering the buzzword metrics of tVOC and eCO2 — this is a great example of a sensor that is going to find itself commonly deployed in a range of devices to come yet!

Sitting on the same I2C bus as the OLED display, the different device addresses make sure that there are no clashes when communicating between the two peripherals.

Note the text detail of the schematic, with the field sat below the schematic symbol noting the I2C address of the debive, as configured. That's some good practice that can save you having to pull up yet another datasheet during debugging!

While Rankin hasn't yet released sources for this board over on his GitHub, we can imagine he's likely busy verifying this project before doing so!

If you want to keep up to date with what R is up to, I'd recommend following along on his Twitter for some interesting tidbits to follow!