Easy Very Low Power BLE in Arduino
by Matthew Ford 24th March 2019
(originally posted 4th February 2019)
© Forward Computing and Control Pty. Ltd. NSW Australia
All rights reserved.
Update: 24th March 2019 – Rev 2 of lp_BLE_TempHumidity, adds more plot options and i2c_ClearBus, adds GT832E_01 support
This tutorial, A Redbear Nano V2 Replacement, is Part 3 of 3. This is Revision 2 of this project. Revision 2 PCB includes mounting for the coin cell and the sensor, simplifies construction and improves air flow around the sensor while shielding it from direct sunlight. Revision 1 is here.
1 – Building
Very Low Power BLE devices made Easy with Arduino covers settting
up Arduino to code nRF52 low power devices, the programming module
and measuring the supply current. It also covers specialized low
power timers and comparators and debounced inputs and using pfodApp
to connect to and control the nRF52 device.
Part 2 – A Very Low Power Temperature Humidity Monitor covers using a Redbear Nano V2 module and an Si7021 temperature/humidity sensor to build a low power battery / solar monitor. It also covers modifying the Si7021 library to be low power, tuning the BLE device to reduce its current consumption to <25uA and designing a custom temperature/humidity display for your mobile.
Part 3 – A Redbear Nano V2 Replacement, this one, covers using other nRF52 based modules instead of the Nano V2. It covers selecting supply components, construction, removing the nRF52 chip programming protection, using NFC pins as normal GPIO, and defining a new nRF52 board in Arduino.
This tutorial is a practical application of Part 1 Building Very Low Power BLE devices made Easy with Arduino by constructing a Very Low Power BLE Temperature and Humidity Monitor using a SKYLAB SBK369 board as a Nano V2 replacement. This tutorial covers how to create a new board definition and how to remove the nRF52 programming protect to allow it to be re-programmed. This tutorial uses the same sketch as Part 2 with the same tuned BLE parameters for low power consumption and can be powered from battery OR battery + solar OR solar only. The tuning of BLE parameters for low power was covered in Part 2
Rev 4 of pfod_lp_nrf52.zip also supports the GT832E_01 module and this tutorial covers using the NFC nRF52 pins as standard GPIO's.
The monitor constructed here will run for years on Coin Cell or 2 x AAA batteries, even longer with solar assist. As well as displaying the current temperature and humidity, the monitor stores the last the last 7 days of hourly readings. These can be charted on the your Android mobile and the values saved to a log file. No Android Programming is required, pfodApp handles all of that. The Android display and charting is completely controlled by your Arduino sketch so you can customize it as required.
Part 2 used a Redbear Nano V2 board for the nRF52832 BLE component. This project replaces that with a cheaper SKYLAB SKB369 board. As in Part 2, a Sparkfun Si7021 breakout board is used for the Temperature / Humidity Sensor. A modified low power library is used with the Si7021.
i) The Nano V2 was out of production for a number of months and does
not seem to fit into the Particle.io line up so it is not clear how
long it will be available for.
ii) The Nano V2 is more expensive. However it also has extra features. See below.
iii) The Nano V2 has components on both sides which gives it a higher profile and makes it more difficult to mount.
iv) The Nano V2 has limited I/O pins available and using D6 to D10 requires flying leads.
Although the Nano V2 board is more expensive then the SKYLAB SKB369 board, ~US17 versus ~US5, the Nano V2 does have more features. The Nano V2 includes a 3.3V regulator and supply capacitors, extra components for using the nRF52 DC/DC converter option, a chip antenna and a uFL SMT antenna connector.
Another alternative is the GT832E_01 module used by www.homesmartmesh.com. Rev 4 of pfod_lp_nrf52.zip also support programming the GT832E_01 module. The SKYLAB SKB369 and the GT832E_01 are available from https://www.aliexpress.com
Redbear (Particle.io) also has a bare module without 3V3 regulator, DC/DC components or 32Khz crystal components.
project has 4 relative independent parts:-
Component Selection and Construction
Removing the nRF52 coding protection flag and programming the sketch
Creating a New Arduino nRF52 Board Definition
Reconfiguring nRF52 NFC pins as GPIO's
In addition to the nRF52832 and Si7021 components selected in Part 2, this project adds a 3.3V regulator and supply capacitors.
The regulator used here is MC87LC33-NRT. It can handle up to 12V inputs and has a quiescent current of <3.6uA, typically 1.1uA. The Nano V2 used a TLV704 regulator has a slightly higher quiesent current, typically 3.4uA and can handle higher input voltages, up to 24V. The MC87LC33-NRT was chosen instead because its datasheet specifies how it responds as the input voltage falls below 3.3V where as the TLV704 datasheet does not.
The TLV704 specifies an input voltage of 2.5V minimum and it is not clear from the datasheet what will happen below that. The nRF52832 will run down to 1.7V and the Si7023 will run down to 1.9V. The MC87LC33-NRT on the other hand specifies input/output voltage differences down to 0V for low currents (Fig 18 of the datasheet). So given the choice of components, the MC87LC33-NRT was chosen because it has the specified performance.
The MC87LC33-NRT regulator needs some supply capacitors for stability and response. An output capacitor > 0.1uF is recommended on the datasheet. The SKYLAB SBK369 also specifies 10uF/0.1uF capacitors on the supply close to the board. Larger capacitors assist in supplying the nRF52 TX current spikes. Here 4 x 22uF 25V and 3 x 0.1uF 50V Ceramic capacitors were used. One 22uF and a 0.1uF capacitor was placed close the the SKYLAB SBK369, a 0.1uF was placed close to the output of the MC87LC33-NRT to ensure stability and a 22uF and 0.1uF were placed near the SKYLAB Vdd pin. The extra current reservoir capacitors, 4 x 22uF, were installed on the input to the 3.3V regulator so that they would charge to a higher voltage when running with solar cells. Charging to higher voltage equates to storing more current to supply the Tx spikes. For comparison the NanoV2 board has a 22uF / 0.1uF on the input to the TLV704 regulator and a 0.1uF on its output.
Ceramic X5R capacitors are used because they have low series resistance and low leakage current. The resistance is typically 100,000MΩ or 1000MΩ – µF which ever is less. So for 22uF we have 22000MΩ, i.e. 0.15nA leakage at 3.3V or 0.75nA for the five 22uF capacitors. That is negligible. For comparison Low ESR, Low Leakage Panasonic Electrolytic capacitors have leakage currents of <0.01CV. So for a 22uF 16V capacitor the leakage is <10uA. Note: This is the leakage at the rated voltage, 16V in this case. The leakage is lower at lower voltages, i.e. <2.2uA at 3.3V.
The 5V solar cells used in this project are small low power and inexpensive. Two cell are connected in series so that they will supply at least 3V even at low light levels. However they have variable performance at low light levels. Because of this variability, extra cells were purchased and the following selection process was used to discard the under-performing cells.
two cells in series and connect a multimeter across them and expose
the cells to a moderate level of light out of direct sunlight so that
the voltmeter reads >3V.
Then cover each cell, one at a time, and check that multimeter reads approximately the same voltage for each.
If the voltage reading are markedly different then exchange the low voltage cell for another and repeat the test.
Approximate cost per unit as at Dec 2018, ~US$61, excluding shipping and the programmer from Part 1
SKYLAB SKB369 ~US$5 eg
Sparkfun Si7021 breakout board ~US$8
2 x 53mm x 30mm 0.15W 5V solar cells e.g. Overfly ~US$1.10 minimum (see note on solar cell selection above)
1 x PCB SKYLAB_TempHumiditySensor_R2.zip ~US$25 for 5 off www.pcbcart.com
1 x MC78LC33 3.3V regulator, e.g. Digikey MC78LC33NTRGOSCT-ND ~US$1
2 x 0.1uF 50V ceramic C1608X5R1H104K080A e.g. Digikey 445-7456-1-ND ~US$0.3
5 x 22uF 16V ceramic GRM21BR61C226ME44L e.g. Digikey 490-10747-1-ND ~US$2
1 x BAT54CW, e.g. Digikey 497-12749-1-ND ~US$0.5
1 x 470R 0.5W 1% resistor e.g. Digikey 541-470TCT-ND ~US$0.25
1 x 10V 1W zener SMAZ10-13-F e.g. Digikey SMAZ10-FDICT-ND ~US$0.5
3mm x 10mm nylon screws, e.g. Jaycar HP0140 ~AUD$3
3mm x 6mm nylon threaded standoffs, e.g. Jaycar HP0146 ~AUD$3
Scotch Permanent Mounting Tape Cat 4010 e.g. from Amazon ~US$6.6
CR2032 battery holder, e.g. HU2032-LF ~US$1.5
CR2032 battery ~US$1
2 x Perspex sheets, 110mm x 35mm, 3mm thick
Solder Paste e.g. Jaycar NS-3046 ~AUD$13
The project is constructed on a small PCB. The PCB was manufactured by pcbcart.com from these Gerber files, SKYLAB_TempHumiditySensor_R2.zip The PCB mimics the Nano V2 pin out and is general purpose enough to be used for other BLE projects.
This is the schematic (pdf version)
First solder the SMD components, then mount the SKYLAB SKB369 board
Almost all the components are surface mount devices (SMD). The capacitors and IC's can be difficult to solder by hand. The suggested method is to hold the PCB in a vice and apply a small amount of solder paste to the pads and place the SMD components, except for the SKB369 board, on the PCB. Then using a heat gun, apply heat to the underside of the PCB until the solder paste melts and then do a quick pass over the top of the board being careful not to blow the components off. Finally touch up the components with a small tip soldering iron. Be careful with the capacitors and resistor as it is easy to melt both ends and have the component come loose while soldering one end.
This revision add extra 22uF 16V ceramic capacitors. These extra capacitors reduce the current spikes drawn from the battery and also the reduce the voltage dips when being powered from the solar cells. As long as the voltage from the solar cells remains above the battery voltage then no current is drawn from the battery.
After the SMD components have been mounted, you can solder in the SKYLAB SKB369 board. There are two test point holes on one side of the SKB369 tabs. Use two pins into a cardboard base to position the SKB369 board and carefully align the pins. (See the example photo below using the Revision 1 PCB) Then solder one pin of the opposite side to hold the board in place before soldering the other pins.
The completed Revision 2 PCB. Note the Gnd link wire from the CLK to GND in the finished part. This is installed AFTER programming to prevent noise on the CLK input from triggering the nRF52 chip into a high current debug mode.
The mounting case was made from two pieces of perspex, 110mm x 35mm, 3mm thick. The 3.5mm piece under the solar cells was tapped to take the 3mm nylon screws. This revised construction is simplifier then Rev 1 and improves air flow around the sensor. The extra holes at each end are for mounting, using cable ties for example.
Connect the Temperature/Humidity board to the Programmer described in Part 1 as shown below.
With the solar cells covered and batteries unplugged, Vin and Gnd are connected to the programmer's Vdd and Gnd (the Red and Black leads) and the SWCLK and SWDIO are connect to the Clk and SIO of the programmer header board (the Blue and Purple leads)
From Nordic Semi – Debug and Trace page
DAP - Debug Access Port. An external debugger can access the device via the DAP. The DAP implements a standard ARM® CoreSight™ Serial Wire Debug Port (SW-DP). The SW-DP implements the Serial Wire Debug protocol (SWD) that is a two-pin serial interface, SWDCLK and SWDIO
Important: The SWDIO line has an internal pull-up resistor. The SWDCLK line has an internal pull-down resistor.
CTRL-AP - Control Access Port. The Control Access
Port (CTRL-AP) is a custom access port that enables control of the
device even if the other access ports in the DAP are being disabled
by the access port protection. Access port protection blocks the
debugger from read and write access to all CPU registers and
Disable access port protection. Access port protection can only be disabled by issuing an ERASEALL command via CTRL-AP. This command will erase the Flash, UICR, and RAM.
Select CMSIS-DAP as the programmer for Particle's Debugger and select nRF5 Flash SoftDevice
If the flash works, then that is OK, but often modules will have been protected against re-programming and you will get this error output in the Arduino window
Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html debug_level: 2 Info : only one transport option; autoselect 'swd' adapter speed: 10000 kHz cortex_m reset_config sysresetreq Info : CMSIS-DAP: SWD Supported Info : CMSIS-DAP: Interface Initialised (SWD) Info : CMSIS-DAP: FW Version = 1.10 Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1 Info : CMSIS-DAP: Interface ready Info : reduce speed request: 10000kHz to 5000kHz maximum Info : clock speed 10000 kHz Info : SWD IDCODE 0x2ba01477 Error: Could not find MEM-AP to control the core Error: Target not examined yet Error while flashing SoftDevice.
In that case you need to set the ERASEALL command register in the nRF52 to clear the memory and make the device programmable again. The version of openOCD supplied with sandeepmistry nRF52 does not include the apreg command needed to write to the ERASEALL command register so you need to install a later version.
Install OpenOCD version OpenOCD-20181130 or higher. Windows pre-compiled version is available from http://gnutoolchains.com/arm-eabi/openocd/ The latest code is available from https://github.com/ntfreak/openocd.
Open a command prompt and change dir to the OpenOCD install directory and enter the command
-d2 -f interface/cmsis-dap.cfg -f target/nrf52.cfg
The response is
Open On-Chip Debugger 0.10.0 (2018-11-30) [https://github.com/sysprogs/openocd] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html debug_level: 2 Info : auto-selecting first available session transport "swd". To override use ' transport select <transport>'. adapter speed: 1000 kHz cortex_m reset_config sysresetreq Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : CMSIS-DAP: SWD Supported Info : CMSIS-DAP: FW Version = 1.10 Info : CMSIS-DAP: Interface Initialised (SWD) Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1 Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : SWD DPIDR 0x2ba01477 Error: Could not find MEM-AP to control the core Info : Listening on port 3333 for gdb connections
Then open a terminal window e.g. TeraTerm (Windows) or CoolTerm (Mac) and connect to 127.0.0.1 port 4444
The telnet window will show a > and the command
prompt will show
Info : accepting 'telnet' connection on tcp/4444
In the telnet window (i.e. TeraTerm) type
nrf52.dap apreg 1 0x04
this returns 0x00000000 showing the chip is protected. Then type
nrf52.dap apreg 1 0x04 0x01
nrf52.dap apreg 1 0x04
this returns 0x00000001 showing the chip is now set to ERASEALL on next restart.
Close the telnet connection and also use Ctrl-C to exit the openOCD program in the command prompt and then power cycle the nRF52 module and it will be now ready to program.
Now retry flashing the softdevice.
You can now program the nRF52 module from Arduino.
Close Arduino and re-install the latest version of pfod_lp_nrf52 support by following the Install the pfod_lp_nrf52 hardware support directions. The latest pfod_lp_nrf52 includes Select SKYLAB SKB369 Nano2 replacement board. Select that as the board and you can then program it with the Revision 2 of lp_BLE_TempHumidity, lp_BLE_TempHumidity_R2.zip, as described in Part 2.
If the programming fails. Close all the Arduino windows, remove the USB cables, restart Arduino and plug the programmer USB cable back in and plug the nRF52 module's USB supply back in and try again.
Then connect via pfodApp to display the current and historical temperature and humidity. Once you have displayed the historical plot, the readings are saved to the log file on your mobile and also available in the raw data screen.
(This data is from another time.)
To support a new nRF52 board you need to a) add a new directory under variants directory with the board files and b) edit the boards.txt file to add the new board to Arduino.
As described in Part 1, Installing the pfod_lp_nrf52 hardware support, find the hardware sub-directory of sandeepmistry package that you have updated with the pfod_lp_nrf52 support. Open the \hardware\nRF5\0.6.0\variants sub-directory and create a new directory for your new board, e.g. SKYLAB_SKB369_Nano2replacement In the new \hardware\nRF5\0.6.0\variants\SKYLAB_SKB369_Nano2replacement directory create three files variant.h, variant.cpp and pins_arduino.h You can copy them from on of the other board variants directories. For the SKYLAB_SKB369_Nano2replacement, I initially copied the files from the RedBear_BLENano2 variant.
The pins_arduino.h file does not need to be changed. It just includes the variant.h file
Edit the variant.h file to define the total number of pins your board will have, PINS_COUNT
NOTE: In the sandeepmistry package, NUM_DIGITAL_PINS, NUM_ANALOG_INPUTS and NUM_ANALOG_OUTPUTS settings are ignored.
your board makes more or less analog pins available, update the /*
Analog Pins */ section
of the variants.h
NOTE: For the NanoV2 and SKYLAB boards the Analog pins are mapped to the Digital pins A0 == D0 etc
This is not essential. You can assign the Analog Inputs to any convenient Arduino pin. See then blue/variant.h and blue/variant.cpp files for an example.
The nRF52832 chip has 8 analog input pins, but the SKYLAB_SKB369_Nano2replacement board only makes 6 of them available to match the Nano2.
All pin numbers, except the RESET_PIN, in the variant.h file are Arduino pin numbers. That is #define PIN_A0 (0) implies that D0 in the arduino sketch is the same pin as A0. The RESET_PIN is the exception. That number is the nRF52823 chip pin number and 21 is the only valid choice. However the pfod_lp_nrf52 support does not enable the reset pin on the nRF52832
There is only one entry in the variant.cpp file, the g_ADigitalPinMap array that maps Arduino pin numbers to the nRF52832 chip P0.. pins
NOTE: In the NanoV2 and SKYLAB boards, the Arduino analog pins A0, A1 … are the same as the Arduino digital pins D0, D1 … so the first entries in g_ADigitalPinMap MUST map to AINx pin numbers on the nRF52832 chip.
For the Analog Inputs your board makes available, those entries in g_ADigitalPinMap must map to nRF52832 AIN0, AIN1, AIN2, etc pin numbers. i.e. AIN0 is chip pin P0.02, AIN1 is chip pin P0.03 etc see the nRF52832 pin layout below.
Use (uint32_t)-1 for invalid mappings. For example the SKYLAB_SKB369_Nano2replacement board does not have a built in LED, D13, so its position is mapped to (uint32_t)-1
In pfod_lp_nrf52.zip the Redbear NanoV2, SKYLAB SKB369 and GT832E_01 variants sub-directories have images showing the mappings set up by variant.cpp.
In the case of the SKYLAB SKB369, there are plenty of pins to choose from. Only enough are mapped to match the NanoV2. In the case of the GT832E_01, all the available pins need to be mapped. Even then there are only three (3) analog inputs available instead of the six (6) on the NanoV2. As well as this the two NFC pins, P0.09 and P0.10, need to re-configured as GPIO's. See Reconfiguring nRF52 NFC pins as GPIO's below.
Here is the SKYLAB_SKB369_Nano2replacement entry in the boards.txt file.
## SKYLAB_SKB369 Nano2 Replacement SKYLAB_SKB369_NANO2_REPLACEMENT.name=*SKYLAB SKB369 Nano2 Replacement SKYLAB_SKB369_NANO2_REPLACEMENT.upload.tool=sandeepmistry:openocd SKYLAB_SKB369_NANO2_REPLACEMENT.upload.protocol=cmsis-dap SKYLAB_SKB369_NANO2_REPLACEMENT.upload.target=nrf52 SKYLAB_SKB369_NANO2_REPLACEMENT.upload.maximum_size=524288 SKYLAB_SKB369_NANO2_REPLACEMENT.upload.setup_command=transport select swd; SKYLAB_SKB369_NANO2_REPLACEMENT.upload.use_1200bps_touch=false SKYLAB_SKB369_NANO2_REPLACEMENT.upload.wait_for_upload_port=false SKYLAB_SKB369_NANO2_REPLACEMENT.upload.native_usb=false SKYLAB_SKB369_NANO2_REPLACEMENT.bootloader.tool=sandeepmistry:openocd SKYLAB_SKB369_NANO2_REPLACEMENT.build.mcu=cortex-m4 SKYLAB_SKB369_NANO2_REPLACEMENT.build.f_cpu=16000000 SKYLAB_SKB369_NANO2_REPLACEMENT.build.board=SKYLAB_SKB369_Nano2replacement SKYLAB_SKB369_NANO2_REPLACEMENT.build.core=nRF5 SKYLAB_SKB369_NANO2_REPLACEMENT.build.variant=SKYLAB_SKB369_Nano2replacement SKYLAB_SKB369_NANO2_REPLACEMENT.build.variant_system_lib= SKYLAB_SKB369_NANO2_REPLACEMENT.build.extra_flags=-DNRF52 SKYLAB_SKB369_NANO2_REPLACEMENT.build.float_flags=-mfloat-abi=hard -mfpu=fpv4-sp-d16 SKYLAB_SKB369_NANO2_REPLACEMENT.build.ldscript=nrf52_xxaa.ld SKYLAB_SKB369_NANO2_REPLACEMENT.menu.lfclk.lfrc.build.lfclk_flags=-DUSE_LFXO SKYLAB_SKB369_NANO2_REPLACEMENT.menu.softdevice.s132=S132 SKYLAB_SKB369_NANO2_REPLACEMENT.menu.softdevice.s132.softdevice=s132 SKYLAB_SKB369_NANO2_REPLACEMENT.menu.softdevice.s132.softdeviceversion=2.0.1 SKYLAB_SKB369_NANO2_REPLACEMENT.menu.softdevice.s132.upload.maximum_size=409600 SKYLAB_SKB369_NANO2_REPLACEMENT.menu.softdevice.s132.build.extra_flags=-DNRF52 -DS132 -DNRF51_S132 SKYLAB_SKB369_NANO2_REPLACEMENT.menu.softdevice.s132.build.ldscript=armgcc_s132_nrf52832_xxaa.ld
Comments – lines starting with # are comments.
Prefix – each board needs a unique prefix to identify its values. Here the prefix is SKYLAB_SKB369_NANO2_REPLACEMENT.
Name – The SKYLAB_SKB369_NANO2_REPLACEMENT.name line specifies the name of this board to show in Arduino's board menu.
Upload tool – The SKYLAB_SKB369_NANO2_REPLACEMENT.upload block specifies which tool to use for uploading. If you are using the Particle Debugger then use protocol=cmsis-dap as shown above.
Bootloader – This line is the same for all boards in this boards.txt
Build – Only two lines need to be
updated in this block. The
line specifies this board's the directory name in the variant
sub-directory. The SKYLAB_SKB369_NANO2_REPLACEMENT.build.board
is the value appended to ARDUINO_ and then defined while compiling
the code. e.g.
This lets you enable/disable parts of the code for specific boards.
Low Freq Clock – This line, SKYLAB_SKB369_NANO2_REPLACEMENT.menu.lfclk.lfrc.build.lfclk_flags, specifies the source of the low frequency clock, used for the lp_timer. There are three options, -DUSE_LFXO, -DUSE_LFRC and -DUSE_LFSYNT. The best choice is -DUSE_LFXO, if the board has an external 32Khz crystal. If not then use -DUSE_LFRC, which uses an internal RC oscillator and draws slightly more current, ~10uA more, and is much less times less accurate. Do not use the -DUSE_LFSYNT as this keeps the chip running all the time resulting in mAs current draw.
Softdevice – pfod_lp_nrf52 only supports nRF52 chips and softdevice s132 so no changes need for this block, other than the prefix.
Be default on the nRF52 pins, P0.09 and P0.10 are configured for use as NFC and expect to be connected to a NFC antenna. If you need to use these as general purpose I/O pins (GPIO's) then you need to add a define, -DCONFIG_NFCT_PINS_AS_GPIOS, to that board's ...menu.softdevice.s132.build.extra_flags compile settings in the boards.txt file.
For example pfod_lp_nrf52.zip, re-configures the GT832E_01 pins for use as I/O. The GT832E_01 section for this board, in the boards.txt file, has the following define added
GT832E_01.menu.softdevice.s132.build.extra_flags=-DNRF52 -DS132 -DNRF51_S132 -DCONFIG_NFCT_PINS_AS_GPIOS
The linker script in pfod_lp_nrf52.zip has also been modified to preserve this setting and does not need to be changed.
This tutorial has presented a replacement for the Redbear NanoV2 using a SKYLAB SKB369 module. A battery/solar powered Temperature Humidity Monitor was used as an example very low power BLE project in Arduino for the SKYLAB module. Supply currents of ~25uA where achieved by tuning the connection parameters. This resulted a CR2032 coin cell battery life exceeding 1 year. Longer for higher capacity batteries. Adding two cheap solar cells easily extended the battery life by 50% or more. A bright room light or a desk lamp is sufficient to power the monitor from the solar cells.
This tutorial also covered removing chip protection from a pre-programmed nRF52 and how to set up a new board definition to match your own PCB/circuit
No Android programming is required.
pfodApp handles all of that.
AndroidTM is a trademark of Google Inc. For use of the Arduino name see http://arduino.cc/en/Main/FAQ
The General Purpose Android/Arduino Control App.
pfodDevice™ and pfodApp™ are trade marks of Forward Computing and Control Pty. Ltd.
Contact Forward Computing and Control by
©Copyright 1996-2018 Forward Computing and Control Pty. Ltd. ACN 003 669 994