(H)DL0100/010X (DLITE Family) SLEEP

Some DLITE family boards and accessories may ship with a simple firmware implementation of SLEEP on the main MCU.

SLEEP puts the MCU into some variant of a low power mode.

On the DL0102GXN firmware update for HDL-0108-IF2C demonstration, the default is to SLEEP after approximately one minute without active serial communications (e.g. radio or USB-serial from a PC).

The implementation is basic and for demo purposes. There are a lot of methods in firmware and board peripheral component controls to save power. This demo is a low-hanging fruit, big return for the demo effort kind of thing.

This SLEEP mode saves about 1/3rd (30%ish) of the total “full swing/fully active” power envelope on a GXN outfitted with an XBee DigiMesh 2.4GHz radio (which itself uses about 30% of the power envelope when not configured for sleeping). The GXN has a reduced modularized shutdown capability compared with the G (different application targets), by design. Regardless, the simple SLEEP command demo saves reduces the GXN/IF2C board pair power consumption by about 100mA during SLEEP, compared with the fully active power state.

(More about power consumption envelopes here.)

The firmware files, for example, dlite_settings.h/c and corresponding UT software utilities can be updated to be able to turn the sleep feature on or off as needed. Fairly straight forward updates. You may want it sometimes, you may not other times. Depends on what you’re doing.

The main MCU on the DL0102GXN in SLEEP may thus not respond as expected to an initial serial communication while sleeping because that first command will wake it, and it will probably miss some bytes in the comms or not respond completely as the UT software would expect, generating an error.

Simple updates to the UT software can anticipate potential sleeping and send a dummy serial Tx to wake the device and then subsequent commands will be processed as usual.

Note that the SLEEP implementation on the GXN MCU is again, a demo. The firmware does not completed shutdown on-MCU peripherals or on-board peripheral component neighbors that could be shut down. Some peripheral components and board sub-systems are shutdown when not in use, in the baseline firmware; or they used to. Worth exploring the extension of this.