Ribbit Power Hop Challenge - Layout and Bring-up

Note: This is part 2 of my Ribbit Power Hop Challenge submission, which contains the layout notes and bring-up for my design. Read the previous project to learn more about the design process.

Revisions to Initial Submission

After receiving insightful feedback from the judging team, some revisions were made to the initial design detailed in my original Hackster project.

Here is a updated system diagram:

And this is the top-level drawing of the final schematic:

Additions/removals [＋/ －] and modifications [ ～ ]:

[＋] nRF52833 companion SoC + Bluetooth Antenna to act as a serial interface to the nRF91 via USB, and provide device provisioning capabilities via Bluetooth

[－] FTDI interface - relying on nRF52 to provide a serial interface

[～] Changed battery holder size from 14430 to 18650 to increase battery capacity

[＋] JST PH battery connector to allow alternate battery connection in place of 18650 cell

[＋] Battery protection circuitry to provide over-current, over-voltage, and under-voltage protection

[＋] Test points and jumpers on power rails for voltage and current monitoring of each subsystem

PCB Layout

Download the layout here. These primary design considerations dictated subsystem placement on the PCB:

• Minimize interference to sensitive traces (RF + USB). This led to the two wireless subsystems (nRF52 Bluetooth + nRF91 Cellular) being placed on the top layer, opposite the noisy switching power circuitry on the bottom layer. The USB differential-pair traces were routed on an internal layer, shielded from the top and bottom layer by ground planes. Care was taken to ensure even low-speed digital signals (I2C and SPI) were routed distant-from and/or orthogonal-to RF traces. On the bottom layer, the power circuitry was placed as far as possible from the Bluetooth trace antenna.
• Connector inputs (Solar + USB-C) were colocated to simplify enclosure design.
• Other human-manipulated interfaces (battery holder, debug connectors, jumpers, and test points) were placed on the same side where possible to simplify the bring-up and debugging process.
• Large ground planes on the top and bottom layers, with stitching vias and vias placed around the periphery of the board to minimize emitted EMI from the board.
• Balance a minimal form factor while simultaneously keeping signals exposed in case hardware modifications are needed.

Given all of these considerations, the following layout was created:

Additional considerations:

• The board stack-up was chosen to ensure the characteristic impedances of high-speed traces (50 ohm for RF traces and 90 ohm for USB traces), attempting to correspond the design to reference layouts as closely as possible.
• Following suggestions of the nRF9151 design guidelines, power trace impedance was minimized as much as possible to reduce voltage droop during high-current cellular operation.
• Because there wasn't much space for test points on this board, many of the vias were untented at least on one side to act as pseudo-test points.

Stack-up:

Note that during the assembly process, the team at PCBWay notified me that the 2 pin SMD headers had an incorrect footprint. This meant they couldn't solder the parts I had specified and I needed to purchase the correct one and solder on my own once they arrived.

Board Dimensions

The final board dimensions were 84mm x 50mm, about the size of a credit card.

Board Bring-up

Bring-up is the process of testing a freshly assembled PCB. Board bring-up for a new project is always exciting because the board hasn't been tested before, so "here there be dragons".

The first step was to visually inspect the PCBs for assembly defects such as components placed with the wrong orientation or shorts between pins. No issues there, PCBWay did a great job with assembling these boards!

Next up was to test all power rails by first checking for shorts to ground and then powering the inputs with a current-limited power supply.

Both the USB power and solar panel inputs had no issues. Unfortunately, there was a mysterious short on the input of the battery which appeared to be a diode due to its non-linear current draw behaviour as the current limit was ramped.

The issue turned out to be with Q5, which was intended to be a reverse polarity protection. The footprint for this part was created improperly which resulted in the body diode being placed across the battery input and ground. Oops. It was an easy task to remove and short out this (not required) component with a piece of wire soldered across the correct pads instead.

Following this, all power rails looked good and I was ready to proceed to programming the SoC. The best way to program the nRF52 and nRF91 is with the Nordic nRF Connect SDK, which is based on the Zephyr RTOS. If you're used to bare-metal programming with a simple HAL, this is certainly a step up in complexity. But, after getting over the learning curve, there are many prewritten examples and resources that made the testing process a bit more convenient.

An important step for each SoC was creating a Device Tree "board" definition, which defines what hardware is accessible to your Zephyr code and how to access it. One thing that took me way too long to figure out is that the nRF52 on this board is missing an external crystal. The BLE functionality relies on it, so none of the Bluetooth stuff worked initially. The following KConfig configured the nRF52 to use the internal RC clock source instead:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

Once the boards were defined, I could load up a simple "Blinky" example to toggle a GPIO (attached to a LED on the nRF91 and an easily accessed pin via scope on the nRF52) to prove programming was successful! And then the Bluetooth and Cellular samples to exercise the functionality of each of the antennas.

Bluetooth examples for the nRF52 are fairly straightforward. I flashed a test beacon example and I used my cell phone as the Bluetooth listening device. One thing I noticed was that the RSSI of my Bluetooth packets seemed a bit low in comparison to a few other devices when I moved around the house, indicating the antenna matching could probably use some work. However, that is to be expected with a brand new design and it works well enough in close proximity.

For the nRF91, I found the nRF Connect SDK - Modem shell sample to be useful for testing the cellular modem. With this shell, I could write low-level AT commands to the modem to ensure it was configured correctly and I could also control the internal GNSS module without having to write up any firmware myself. Useful when I'm still learning the modem interface libraries and just want to prove the subsystems are working as intended.

Testing the GNSS was done outside with a clear view of the sky in order to get a fix on many satellites quickly. This GPS test was performed as a cold start, meaning there was no current information available about current GPS satellite locations, which means it generally takes much longer to get a fix. I didn't make use of the Assisted GPS features offered by Nordic for this testing. It connected in about 51 seconds, which seems OK to me.

Note that due to the design, there is no direct USB <-> Serial device for the nRF91. The nRF91 must pass UART messages to the nRF52 which then forwards them to the USB interface. The USB CDC ACM (virtual COM) port is handled in the nRF52.

The final test was to test the I2C interfaces going to the peripherals. Unfortunately, the BQ25798 and SCD30 don't have built-in drivers in Zephyr, meaning there was slightly more work required to interface with them. I was able to use the generic I2C device driver to simply write and read out the required sequences of bytes according to the device datasheets. If there were built-in drivers, I could have skipped this step.

Both of the I2C buses were functional and connectivity was tested for each device by reading out some static chip ID or version information stored on the chips. In hindsight, I think I could have used the I2C shell included in Zephyr to test these devices even faster.

Bring-up Summary

Visual Inspection: OKPower Rails: All OK except for VBAT, incorrect reverse polarity FET footprint caused a short to ground, OK after bypassingnRF91 & nRF51 Bring-up: OKBLE: OKCellular: OKGNSS: OK Charger: OKSensor Bus: OK

A more detailed record of tests and results is available in the bring up summary in this spreadsheet.

Power Testing

An important part of being a solar powered device is using the incoming energy efficiently. In order to measure efficiency, I powered the device with a power supply supplying 98 mA @ 6.6V. This resulted in power to the battery of 130 mA @ 3.6V. Dividing power out by power in gives an efficiency of 72%. I picked these current and voltage values for the input since they correspond roughly to the specs of the 6V, 1.2W solar panel selected for this design. The output power @ 3.6V corresponds to the voltage of the fully charged LiFePO4 on hand :).

However, there is an option to use a lower switching frequency and larger inductor for the BQ25798. Despite missing this during the initial design, I was able to order a replacement part (same footprint) and swap out R15 for 4.7kOhms (i.e. the resistor that sets the voltage at the BQ25798 'PROG' pin, configuring the switching frequency). This gave: 98 mA @ 6.6V = 647 mW in, and 138mA @ 3.66V = 505 mW out. Or an efficiency of 78%!

I think I would have liked the efficiency to be a bit higher, but the efficiency in the exact operating conditions I'm operating this part at (< 500 mA) are unspecified in the data sheet, so it required testing.

Full Integration Test

To demonstrate a fully working system, I created a new sample application based on the nRF Cloud Multi Service sample. This sample app handled the device provisioning and connection to nRF Cloud. I just needed to modify the main thread of the application to program the PMIC, enable the load switch to the sensors, and start sampling the SCD30 (most of the code was already completed in the previous step).

I used the "Temperature" sensor data type since there were only a few fixed types built in and I wasn't sure how to set up a new one. Once the device was provisioned with nRF Utils via

claim_and_provision_device --api-key <api_key> --provisioning-tags "nrf-cloud-onboarding" --cmd-type at_shell --port <serial_port>

the device connected to nRF cloud and downloaded a set of credentials transferred over the cellular network. Pretty cool. Here is my registered device:

For this demonstration I modified the HTML so that instead of "Temperature" it shows "CO2" just to avoid confusion.

I let the fully built Ribbit device run over the course of a day and collected some sensor data which was reported to the nRF Cloud backend. It is then able to be queried in their web app. Here is the CO2 data collected:

The onboard ADC of the BQ25798 allows the charging current to be measured:

It was a partly cloudy day for the test day. You can see the solar power rise slowly starting in the morning, peak around 1 PM (solar noon for me) and then slowly drop until around 5pm when the sun was blocked by a building. The drops in the panel current are from when clouds obstructed the sun. This was a quick test so I'm sure the panel placement could have been optimized, I just angled it roughly at 30 degrees.

I regret not recording the solar panel voltage (available via the ADC of the BQ25798), which would have allowed measurement of the total energy collected during the test day. Panel voltage is roughly ～6V which gives a rough average power of 0.5W over the 10 hour period. Not too bad!

Overall this was a fun test to prove that the design charges from the solar panel, operates as intended and interfaces properly with the sensors.

Power Consumption of Integration Test

The Nordic PPKII was used to profile the system's power consumption during the full integration test:

The above power trace demonstrates the device initiating a cellular connection for the first ～25 seconds, followed by sensor readings. Pulses are attributable to the CO2 sensor, which performs continuous measurements on a 2 second interval (the sensor's default).

The average current of the data trace pictured above is 54.9mA, corresponding to an average power of 181mW @ 3.3V, a power consumption that could theoretically be supplied by the solar panel, at least as illustrated in the above test (although there wouldn't be much margin for error if there were many cloudy days). The good news is that the power consumption of the nRF9151 subsystem can be optimized, perhaps very significantly. Currently, with no optimizations being done, the nRF9151 subsystem consumes ～36 mA － a test was conducted to determine that the sensors are responsible for ～19mA of the ～55mA measured above. According to the Nordic Online Power Profiler, consulted during the initial design stage of this project, the nRF9151 should be able to consume as little as an average of 41 uA during cellular operation by utilizing Power Saving Mode. The large discrepancy is likely due to the many activities running on the nRF9151 in the full integration test, whose software is based on Nordic's nRF Cloud multi-service sample. This software sample consistently communicates with the cellular network to conduct localization and doesn't put itself into a sleep mode.

Known Issues

As mentioned in the bring-up section, the most critical issues found after receiving and testing the design are:

• SMD 2-pin headers (J4-J9, J14) have an incorrect footprint (cannot be soldered)
• Reverse polarity protection MOSFET Q5 has an incorrect footprint (causes a short circuit on board)

Both of this critical issues in the design are both simple footprint fixes that do not require major redesign on the board.

Future Design Recommendations

In the time that this board was being designed, TI released an app note implementing a circuit that helps the BQ25798 boot up more reliably when solar conditions are poor and the battery is low. I think this could be a big improvement to reliability of the system and only requires a couple of extra transistors:

There are more notes in the bring up sheet from some extra ideas or thoughts that came up after the design was already frozen for layout, but they are mostly minor and too detailed to be included in this report.

Design Files / Other Documents

The following Google Sheet documents steps and values measured during bring-up and testing: https://docs.google.com/spreadsheets/d/1FIy1DVAQr41zQV4V2hd3cEl0jTIkmZ11u3IzZUdCSKI/

Code used for this part is in the following repos

• https://github.com/djgood/ribbit-solar-nrf52
• https://github.com/djgood/ribbit-solar-nrf91 (sample app code lives in the 'sample-app' branch)

Hardware design lives in this repo: https://github.com/djgood/power-hop-hardware