|
Home
| pfodApps/pfodDevices
| WebStringTemplates
| Java/J2EE
| Unix
| Torches
| Superannuation
|
| About
Us
|
|
|
Easy Very Low Power BLE in Arduino
|
by Matthew Ford 11th February 2019
(originally posted 4th February 2019)
© Forward
Computing and Control Pty. Ltd. NSW Australia
All rights reserved.
This tutorial, A Redbear Nano V2 Replacement, is Part 3 of 3. This Revision 1 and has been superseded by Revision 2 here.
Part
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 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
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 36 Hrs of 10min readings and the last 10 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.
If you are looking for a complete DIY BLE mesh system, check out www.homesmartmesh.com. It uses a different BLE nRF52 module with less I/O pins. Redbear (Particle.io) also has a bare module without 3V3 regulator, DC/DC components or 32Khz crystal components.
This
project has 3 relative independent parts:-
Component
Selection and Construction
Removing the
nRF52 coding protection flag and programming the sketch
Creating
a New Arduino nRF52 Board Definition
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 on the input to the MC87LC33-NRT and a further 2 x 22uF capacitors where soldered across the Vin/GND pins as a further current reservoir. For comparison the NanoV2 board has a 22uF / 0.1uF on the input to the TLV704 regulator and a 0.1uF on its output.
The extra current reservoir capacitors 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.
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.6nA for the four 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.
Approximate cost per unit as at Dec 2018, ~US$61, excluding shipping and the programmer from Part 1
SKYLAB SKB369 ~US$5 eg
Aliexpress
Sparkfun
Si7021 breakout board ~US$8
2 x 53mm x 30mm 0.15W 5V solar
cells e.g. Overfly
~US$1.10
1 x PCB TempHumiditySensor_R1.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
4 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 12mm nylon screws, e.g. Jaycar
HP0140 ~AUD$3
3mm x 12mm nylon nuts, 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
Perspex sheet, 3.5mm and 8mm
pfodApp
~US$10
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_R1.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.
Note the extra 2 x 22uF 16V ceramic capacitors, added after the board was made, are soldered across the VIN / GND tabs. 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. Then solder one pin of the opposite side to hold the board in place before soldering the other pins.
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, 8mm thick and 3.5mm thick. The 8mm piece was milled out to take the boards and battery and the 3.5mm piece used as the backing and tapped to take the 3mm nylon screws. This construction, shown below, is time consuming and limits the airflow around the sensor. So the next version will just be mounted between two unmilled 3.5mm perspex sheets spaced about 8mm apart via spacers to simplify construction and improve air flow around the sensor.
The cut out in the corner make it easy to assemble in the correct orientation. 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 and batteries unplugged, Vin and Gnd are connected to the programmer's Vdd and Gnd (the Yellow and Green leads) and the SWCLK and SWDIO are connect to the Clk and SIO of the programmer header board (the White and Grey 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
memory-mapped addresses.
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
bin\openocd.exe
-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 connectionsThen 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
and then
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 lp_BLE_TempHumidity used in Part 2 sketch as described here.
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.
If
your board makes more or less analog pins available, update the /*
Analog Pins */ section
of the variants.h
file.
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 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
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.ldComments – 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
SKYLAB_SKB369_NANO2_REPLACEMENT.build.variant
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.
-DARDUINO_SKYLAB_SKB369_Nano2replacement
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.
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-2020 Forward Computing and Control Pty. Ltd.
ACN 003 669 994