The Project board is for sharing projects based on Silicon Labs' component with other community members. View Projects Guidelines ›

Projects

    Publish
     
      • Low Power Contest 2015: Falcom, the next-gen falconry system

        Timur | 11/334/2015 | 11:48 PM

        Welcome to Falcom! (Falcon Communications)

         

        One of the main challenges in falconry is knowing where your bird is in realtime. Look up, even with binoculars, and sometimes falcons fly so high that you simply can't see them. You can worry whether your bird is lost, or you can just use Falcom and simply keep track of the bird on a map on the screen of your smartphone or tablet.

         

        Falconers and hawkers care a great deal about their birds of prey, because they are not only monetarily valuable, but also posess immense beauty and timeless elegance. Most current products that help finding birds are either trivial analog radios or GSM-based solutions, both of which are distrusted by many people in the community.

        We opted to do it the hard way, creating a device that operates in the 434 MHz ISM band and has a range of tens of kilometers (up to 50km in ideal conditions). You can mount the Falcom device on the back of your bird and it will periodically sends you its GPS coordinates. You can connect to the device with a transceiver and then connect the transceiver to your smartphone or tablet and watch where your bird flies on a map.

         

        Do you want to get the most out of your bird? Falcom helps you breed better birds by gathering data from its on-board motion sensor, which you can use to evaluate your birds's performance and adjust its training accordingly. Many falconers are also accompanied by dogs when they hunt. We acknowledge this and our device is also usable on dogs.

         

        The hardware

         

        Obviously, a bird as small as a falcon cannot carry much weight, so we had to take every possible measure to make our device as small and light as possible. Our latest prototype weighs approx. 10 grams and occupies a 20×26mm PCB (including every component). This is thanks to the excellent EZR32WG chip from Silabs which we believe to be the best member of the EFM32 family. It not only has a great MCU but also our favourite RF chip (the 446x series), and the IPD from Johanson makes sure that we don't waste valuable PCB space with the matching network. The other beast is an L76 GNSS module from Quectel which lets us get a good fix at the birds' location in a short time.

         

        The device has a 160 mAh Lithium-Polymer battery (the best in this form factor). It can operate in two modes:

        • "hunting mode" when it actively monitors everything (location, acceleration, etc.). In this mode the battery life is around 8-10 hours.
        • If however your bird is lost, it can switch to "lost mode" when all unnecessary peripherials are shut down and it sends coordinates rarely. In this mode it can operate for 4-5 days.

         

        Here is the full list of main components:

        • Silabs EZR32WG330F256R67 wireless MCU is the heart and soul of the entire device
        • Johanson IPD for 434MHz antenna matching
        • TCXO for optimal RF performance
        • Quectel L76 GNSS module for knowing our location
        • MPU-9250 motion sensor by Invensense
        • Honeywell SL353LT hall sensor (used for waking up the device before mounting on the bird)
        • Microchip MCP73811 for battery charging
        • Silabs TS1102 current consumption sensor
        • TPS63031 buck/boost converter to produce a stable 3.3V from the Li-Po battery
        • Custom made antenna connectors

        Again, we've fitted all of the above into just a 20×26mm two-layer PCB.

         

        Screenshot from 2015-11-30 23-23-28.png

         

        How did we do it?

         

        Our battery runtime would be impossible without the low-power features of the EZR32WG. We utilize these features extensively.

         

        • The software of the device is based on an event loop architecture. Basically, the event loop executes tasks in a loop and when there are no more, it puts the MCU into EM2 sleep mode. In this mode, it can still operate the peripherials we need. Any event that occours will trigger an interrupt request which adds a task to be executed by the event loop. This approach allows the ARM core to spend most of its time with sleep while work is still being done by the MCU.
        • We communicate with the GNSS module using the LEUART peripherial and use its frame detection features. When a start frame is detected, we only start a DMA transfer and when we got the signal frame, the core will process the incoming message. This means that while a message is being received by LEUART, the core can either sleep or do other tasks.
        • We schedule the radio transceiver using the LETIMER in the MCU. When not transmitting or receiving, we power down the radio and the TCXO entirely so that the system can save power.
        • In "lost mode" when your falcon is lost, the entire circuit spends most of its time powered down. We can turn off the sensor, the radio and we operate the GNSS module in backup mode and the MCU in EM4 sleep. The BURTC is used to periodically wake up the MCU so that it can warm-start the GNSS module and when a GPS lock is acquired fire up the radio and broadcast its coordinates. After that it powers everything down again and returns to EM4.
        • The ACMP is also quite useful, because it consumes very little power but can notify us about important events. For example, the battery voltage is connected (through a voltage divider) to an ACMP channel. The ACMP can then notify us when the battery is being depleted. (It's also connected to an ADC, of course.) Charger sensing is done in the same way. The charger input is (through another voltage divider) connected to another ACMP channel and the ACMP will notify the MCU when the charger is connected to the device.

        Note that we also utilize the "AlwaysLocate" mode of the GNSS module to reduce its average power consumption and the power saving modes of the motion sensor. These features together make Falcom a viable product.

         

        20151130_007.jpg

         

        20151130_008.jpg

         

        Mechanical design

         

        The device features a charger port and two custom-designed antenna screws, one for the 434 MHz ISM band antenna and the other for the GNSS module. We found the bulk and weight of ceramic antennas unacceptable so we opted for a monopole antenna instead. According to our measurements, the two antennas don't disrupt each other.

         

        We have also made prototype housings for the device. These are 3D printed and made out of industrial plastic.

         

        This case is meant to be mounted on birds:

         

        12208564_1670735279833766_6449856858623372340_n.jpg

         

        We also have a variant which is meant for use on dogs:

         

        12195993_1670735266500434_1343074551776373896_n.jpg

         

        How to use

         

        Make sure your Falcom is fully charged before you put it on your pets! First, mount the device on the back of your bird and then touch it with a small magnet to turn it on. The LED will start blinking which indicates that it is ready to be paired to a receiver. Connect your receiver to your smartphone or tablet and follow the steps on the screen to pair with the device. Your Falcom is now ready to go when you are! Just press the "Begin" button on the screen when you want it to start recording your bird's movements.

         

        The path that your bird took can later be downloaded from the receiver to your computer so that you can boast about your adventure and show off to your friends. You can load the data into Google Earth to show a 3D view of the bird's flight path.

         

        Current status and the future

         

        We've just finished the current hardware and are sill in the process of refining the software. We aim at a release in early 2016 and are very confident that Falcom will be a lovable product by the falconeer community.

         

        Here is a picture of all our hardware including the receiver that we test our Falcom with.

         

        12226966_1670735929833701_2793507151899078852_n.jpg

         

        Let's keep in touch! Like us on Facebook and stay tuned for our soon-to-be-launched website.

      • Low Power Contest 2015: Industrial Automation Realtime Process Data Display

        inakizi | 11/334/2015 | 11:38 PM

        Introduction

        This project started with the intention of creating a device using the Tiny Gecko to show realtime process data acquired using the Modbus Protocol in a small LCD screen. The single most important requirement of this system is low power consumption because the idea is to be able to be battery powered without requiring any battery changes during the lifetime of the product.

         

        LCD Functions Optimization

        The very first time I started Simplicity Studio, I decided to try the Energy Profiler with the touch example. I was greatly impressed when I saw this:

         

         Figure1.png

         

        It was really impressive to see how much power was consumed by a C function. But very quickly saw that there was a problem right there: the LCD_SynBusyDelay was taking 85% of the power, and just from the name (BusyDelay) I knew that was not something normal. It would have been extremely difficult to find this issue without the use of the Simplicity Studio Energy Profiler.

         

        Because my design requires the use of the LCD Screen, my first objective was to find the reason of this above normal energy consumption and fix it.

        Being new with the Gecko platform it took me some time to figure out what the problem is:

         

         

        /***************************************************************************//**

        * @brief

        *   Polls LCD SYNCBUSY flags, until flag has been cleared

        *

        * @param[in] flags

        *   Bit fields for LCD registers that shall be updated before we continue

        ******************************************************************************/

        __STATIC_INLINE void LCD_SyncBusyDelay(uint32_t flags)

        {

        while (LCD->SYNCBUSY & flags);

        }

         

        This function is the responsible of all the extra consumption. Basically this is required to synchronize the fast clock rate domain of the ARM core with the slow clock domain of the LCD peripheral. The program must wait after writing to the LCD peripheral registers until the write has taken effect.

         

        In order to solve this issue I created a small program based on the emlcd demo program to amplify the issue and find a solution for it.

         

        This is the Energy Profiler view of the test program

         

        Figure2.png

         

         

        So in the energy profiler, it can be seen that this program has a energy score of 3.0 with an average consumption of 1.26 mA. This is mainly due to the LCD_SyncBusyDelay function taking over 96% of the power consumption.

         

        The solution to the problem should be to modify the LCD_SyncBusyDelay to sleep while is waiting for the synchronization. However to not modify the standard libraries, I created this function:

         

         

        __STATIC_INLINE void LCD_SyncNotBusyDelay()

        {

        while (LCD->SYNCBUSY) {

              EM2Sleep(1);

        }

        }

         

         

        and I call it before calling any function of the em_lcd library that internally uses the BusyDelay.

         

        So the resulting Energy Profile is this:

         

        Figure3.png

        Now the Energy score is 4.2 with an average consumption of 106uA. This is an impressive ten-fold improvement in the current consumption.

         

        Attached are the First Version with no optimization and the optimized version of the LCD functions.

         

        RS-485 Modbus Data Acquisition

         

        With the LCD issue solved, the next step was to get the Modbus data from a real device. For this a small RS-485 driver is required. It is difficult to find a RS-485 Driver that is able to work a the low voltage of the CR2032 battery, but after searching we found the ISL32603 that is able to operate from 1.8V to 3.6V. This is connected to the Tiny Gecko USART1:

         

        Figure4.png

         

        This is the implemented circuit

        IMG_4995.JPG

         

        Now an important problem with RS485 circuits is to be able to handle correctly the Driver enable. Very few microcontrollers have USARTs with automatic Driver Enable for RS485. The Gecko family is one of those that have it so it is easily achievable a very narrow control of the driver enable. This is a scope capture that show the data and the driver enable automatically generated by the gecko.

         

        IMG_4996.JPG

         

         The energy Profile of the whole circuit for one data retrieval using Modbus is this:

         

        WholeCircuitEnergyProfile3.JPG

         

        The data for this circuit was entered into the Energy Aware application from Silicon Labs. For an every minute update this is the resulting battery operating time for a CR2016:

         energyAware1.png

         

        So the application will run for 6 years with one battery.

         

        This is the video describing the application:

         

         

         

        Conclusion

         

        The most important thing of this design is that it sips power. It is an extremely low powered circuit.

         

        During data acquisition and display it consumes an average of 12uA.

        And while idle it only takes 600 nA.

         

        To give you an idea how little power this is, I entered the data in the Energy Aware application of Silicon Labs.

         

        If I press the button every single minute, this CR2032 battery will last over 6 years.

         

        If I keep it polling data continuously non-stop it will last almost a year.

         

        First of all, I have never seen a device implementing an industrial protocol over RS485 using only a CR2032 battery, and one that would be able to last for years, blows my mind.

         

        This is all due to the extremely power efficiency of the Silicon Labs Tiny Gecko microprocessor and its incredible power saving features

         

         

         

         

      • Low Power Contest 2015 - Internet of Plants

        jlangbridge | 11/334/2015 | 08:13 PM

        Nature and technology don't need to be enemies. As technology advances, we also need to take care of nature. The Internet of Plants project aims to take care of plants, both inside and out, flowers, fruit, vegetables or even trees. Sensors analyse their environment, ranging from a single plant sensor to potentially thousands. By extracting and analysing this data, the project aims to reduce using excess resources.

         

        Different species of plants require different factors; a carnivorous plant requires a large amount of water, while the same amount of humidity could kill a cactus. Water is a valuable resource, one we can't afford to waste. Sunlight, on the other hand, is available everywhere, but while some plants require direct sunlight, others need shade. It's difficult to know exactly what condition our plants require, and this project is here to help.

         

         

        Sensors placed next to the plant analyse soil humidity, temperature, and light exposition. The sensor readings are sent to a base station via ZigBee to a central processor. This processor is connected to Internet, and reads in weather reports, to automate plant care. Why would you turn on a sprinkler system if it will rain in the next few hours? Optional range extenders increase ZigBee coverage, but also have digital and analogue I/O for diverse usage; measuring water levels in cisterns, turning on automated sprinkler systems, opening and closing greenhouse windows, or simply to turn on and off indicator lights.

         

        Since each plant species is different, sensors are pre-programmed at the base station. The base station knows the ID of the sensor, it knows what species of plant the sensor is monitoring. If needed, the system can water a series of plants without watering others, reducing water consumption, saving both resources and money.

         

        IMG_5507.JPG

         

        The sensors are an always-on solution, constantly monitoring the environment, and to be always on, they have to be almost always off. EFM32 microcontrollers are used for their energy efficiency, and remain in sleep for most of the time. Every few minutes, the sensor is woken up by an interrupt, and proceeds to make sensor readings. Information is then sent to the base station via ZigBee; temperature, humidity, light levels and battery levels are sent to the base station before returning to sleep mode. In trial runs, sensors were placed into Energy Mode 2, and sensor readings were sent every 30 seconds, but end products will send data every five minutes, being awake for only a fraction of a second before returning to deep sleep. The sensors are powered by the same energy as the plants they monitor; solar panels on the top charge the internal battery. Energy harvesting will be a requirement.

         

        IMG_5505.JPG

         

        ZigBee was chosen for the mesh network technology. Since the sensors are almost always off, they cannot be used to extend range, so optional range extenders with extra functionality can be added to the network, increasing range, and adding digital and analogue I/O.

         

        The base station doesn't just monitor the environment, it can give detailed statistics, and take care of your plants for you. It isn't enough to know that the soil humidity is 55%; what matters is that your tomato plants require 50% humidity a few weeks after being planted, but also require more water as they grow. The base station can inform you via a web interface about corrections that should be made, or can make the adjustments automatically of you have an automated sprinkler system.

         

        These units are R&D models, and as such, lots of things can change. One of them uses a SiLabs UV sensor, and a pH sensor is planned. Also, current models send data every few seconds, whereas production models will send data every five minutes, spending even longer in sleep mode (EM2), increasing the energy efficiency. Future models will turn off the sensors completely, and turn them back on via a GPIO before making sensor readings.

         

        EnergyScore

         

        The source code is available in the attachment. It is still heavily work in progress, and the UART configuration isn't quite finished.

      • Low Power Contest 2015: WireLEss - A 600 nA Low Energy wireless transceiver using EFM32 LEUART

        Frogbert | 11/334/2015 | 06:10 PM

        1. Introduction

        Wireless communications are a very important aspect of today's internet of things. In particular, RF transceivers take most of the energy budget of a wireless sensor node.

        Therefore, we investigated a very simple wireless transceiver being based on the Low Energy UART feature of the EFM32 Happy Gecko. The basic principle is that the UART sequence of high and low bits are translated into an RF signal, with a logical '1' corresponding to an enabled RF signal and a logical '0' to a disabled RF signal. Thus, the UART sequence (we use an inverted UART to set the IDLE state to a logical '0') will be used to generate an on-off-keying (OOK) modulation on an RF signal.

        With this principle, we were enabled to set the current consumption to 600 nA when listening for an incoming RF pulse (EM4) and to 2 µA (EM2) when receiving incoming data.

         

        Our team is a group of two Bachelor students, Joachim and Markus, and one PhD student, Sebastian, from the Laboratory for Electrical Instrumentation, University of Freiburg, Germany. We were recently digging into the field of the EFM32 microcontrollers, so that we decided to develop and program this circuit just for the purpose of participating in this contest.

         

        2. Circuit concept

        The circuit concept shown in figure 1 will allow to transmit and to receive data, while the receiver part is extremely power efficient. To transmit, an 868 MHz RF carrier signal, which is generated by a common RF chip (C1101), will be turned on and off by the data sequence coming from the EFM32 LEUART (see figure 2). Therefore, an antenna switch will be activated and deactivated using the signal.

        To receive, the antenna switch will be configured so that incoming signals from the antenna are guided to the passive OOK demodulation. This diode rectifier recovers the envelope of the RF signal, which is just a noisy version of the transmitted UART signal with small amplitude. To properly restore the data, a comparator with additional filter will slice the signal, so that it can be received by the LEUART interface.

         

        Schematic.png

        Figure 1: System concept of our LEUART radio.

         

         

        UART-RX.png

        Figure 2: UART data pattern and corresponding RF signals.

         

        3. PCB design

        A custom PCB was designed, featuring a self-designed loop antenna, an EFM32 Happy Gecko HG310 microcontroller as integrated transceiver using its LEUART feature, a rectifier with two Avago HSMS-285 diodes and a low power comparator (Texas Instruments TLV3701). The RF transceiver used for nothing but generating a non-modulated 868 MHz RF carrier is a Texas Instruments CC1101. The antenna and the diode rectifier were both matched to 50 Ohms for maximum RF power transfer.

        A CR2032 coin cell is used as energy storage. Both PCB design file and picture of the final prototype circuit are shown in the following:

         

        PCB-Design.png

        Figure 3: Design of the custom 4-layer PCB.

         

         

        WireLEss-PCB.jpg

        Figure 4: Assembled prototype sensor node.

         

         

        4. Software

         

        4.1 Transmitter

         The data transmitter is initialized by configuring the CC1101 by the SPI interface to transmit a continuous carrier during LEUART data transmission. As mentioned before, the IDLE state of the UART should be a logical 0, as this is the state when no RF signal is transmitted. Once data should be sent, the RF carrier is enabled and the bytes are fed to the LEUART interface with a baudrate of 9600 Baud/s. The UART signal thereby enables and disables the connection of the RF transceiver to the antenna, having a 868 MHz signal with an envelope which corresponds to the UART data. In the first step, a random pattern is sent, so that the comparator at the receiver is enabled once, waking the receiver from EM4. After a short delay to allow startup of the receiver, the data pattern is sent. Finally, the RF carrier is deactivated to safe energy.

         

        4.2 Receiver

         The receiver is the subject of our energy optimization, with its program being shown in the flow diagram below. Initially, it is set to EM4, also disabling the RF transceiver. Once a 868 MHz wireless signal is turned on, this impulse will propagate through the air to the OOK demodulator and will trigger the comparator, resulting in a pin interrupt. The controller will initialize by setting up DMA, RTC (with external crystal to decrease power consumption and clock jitter) and the LEUART interface in receiving mode (also see the corresponding functions below). Then, the DMA controller stores incoming data into the RAM being in EM2. The incoming data will be scanned by the DMA/LEUART in a way that the LEUART interrupt service routine will activated once a particular byte (signal frame pattern), is transmitted. Thereby, we can realize two functionalities:

        • a low-power data transmission: the signal frame pattern tells the controller that the data transmission is finished
        • a low power wake-up receiver: the signal frame pattern is different for different sensor nodes; once a node receives its signal frame pattern, it can initiate measurements and transmit the measurement data back to the requesting node.

        The nice thing is that the EFM32 LEUART can automatically search for this signal frame pattern and trigger the LEUART0IRQHandler() while being in EM2. Thus, scanning the incoming data for a wake-up address is very power efficient.

        In our example, we used the wake-up byte 'carriage return' to initiate a measurement. If no signal frame pattern is received within 300 ms, we go back to EM4 to safe more energy. For the measurement, we read data from a Si7012 (using the Si7013 library) and transmit it back by turning the receiver into the LEUART transmitter described in 4.1.

         

        FlowChart.png

        Figure 5: Flow diagram of the receiver software. The important functions are presented in the attachment SourceCode.txt.

         

        5. Power consumption & results

        While the transmit mode is characterized by the power consumption of the RF transceiver (approx. 20 mA), the receiver is an ultra-low power device. When waiting for an RF pulse, the device consumes only 600 nA. Being triggered, 2 mA will shortly consumed by the initialization. In data receiving mode using LEUART, approximately 2 microA are consumed. Both a picture of the measurement setup in EM4 and the Energy Profiler screenshot prove the low power consumption. For the Energy Profiler screenshot, we sent the STK3400 onboard controller to EM4 as well and connected our custom board to the VMCU breakout pin. Thus, these screenshots also show the power consumption of a second Gecko in EM4, so that roughly 200 nA should be subtracted.

         

        WireLEss-EnergyMeasurement.jpg

        Figure 6: Supply current measurement while being in RX listening mode (EM4). The meter shows 570 nA.

         

         

        EnergyConsumption.png

        Figure 7: Low energy profiler screenshot with Gecko on STK3400 still being connected.

         

        Even in RX receiving mode (2 microA), our circuit could listen for 10 years using a 180 mAh coin cell, neglecting self-discharge. Even energy harvesting devices can easily power this RF receiver. Still, the range of our radio can be improved, as it is only 2 meters so far. Cat Wink

         

        If you have any questions, feel free to ask!

         

        Best regards

        Joachim, Markus and Sebastian

         

        Attachment: Some code of the most important software functions.

      • Low Power Contest 2015: WireLEss - A 600 nA Low Energy wireless transceiver using EFM32 LEUART

        Frogbert | 11/334/2015 | 06:10 PM

        1. Introduction

        Wireless communications are a very important aspect of today's internet of things. In particular, RF transceivers take most of the energy budget of a wireless sensor node.

        Therefore, we investigated a very simple wireless transceiver being based on the Low Energy UART feature of the EFM32 Happy Gecko. The basic principle is that the UART sequence of high and low bits are translated into an RF signal, with a logical '1' corresponding to an enabled RF signal and a logical '0' to a disabled RF signal. Thus, the UART sequence (we use an inverted UART to set the IDLE state to a logical '0') will be used to generate an on-off-keying (OOK) modulation on an RF signal.

        With this principle, we were enabled to set the current consumption to 600 nA when listening for an incoming RF pulse (EM4) and to 2 µA (EM2) when receiving incoming data.

         

        Our team is a group of two Bachelor students, Joachim and Markus, and one PhD student, Sebastian, from the Laboratory for Electrical Instrumentation, University of Freiburg, Germany. We were recently digging into the field of the EFM32 microcontrollers, so that we decided to develop and program this circuit just for the purpose of participating in this contest.

         

        2. Circuit concept

        The circuit concept shown in figure 1 will allow to transmit and to receive data, while the receiver part is extremely power efficient. To transmit, an 868 MHz RF carrier signal, which is generated by a common RF chip (C1101), will be turned on and off by the data sequence coming from the EFM32 LEUART (see figure 2). Therefore, an antenna switch will be activated and deactivated using the signal.

        To receive, the antenna switch will be configured so that incoming signals from the antenna are guided to the passive OOK demodulation. This diode rectifier recovers the envelope of the RF signal, which is just a noisy version of the transmitted UART signal with small amplitude. To properly restore the data, a comparator with additional filter will slice the signal, so that it can be received by the LEUART interface.

         

        Schematic.png

        Figure 1: System concept of our LEUART radio.

         

         

        UART-RX.png

        Figure 2: UART data pattern and corresponding RF signals.

         

        3. PCB design

        A custom PCB was designed, featuring a self-designed loop antenna, an EFM32 Happy Gecko HG310 microcontroller as integrated transceiver using its LEUART feature, a rectifier with two Avago HSMS-285 diodes and a low power comparator (Texas Instruments TLV3701). The RF transceiver used for nothing but generating a non-modulated 868 MHz RF carrier is a Texas Instruments CC1101. The antenna and the diode rectifier were both matched to 50 Ohms for maximum RF power transfer.

        A CR2032 coin cell is used as energy storage. Both PCB design file and picture of the final prototype circuit are shown in the following:

         

        PCB-Design.png

        Figure 3: Design of the custom 4-layer PCB.

         

         

        WireLEss-PCB.jpg

        Figure 4: Assembled prototype sensor node.

         

         

        4. Software

         

        4.1 Transmitter

         The data transmitter is initialized by configuring the CC1101 by the SPI interface to transmit a continuous carrier during LEUART data transmission. As mentioned before, the IDLE state of the UART should be a logical 0, as this is the state when no RF signal is transmitted. Once data should be sent, the RF carrier is enabled and the bytes are fed to the LEUART interface with a baudrate of 9600 Baud/s. The UART signal thereby enables and disables the connection of the RF transceiver to the antenna, having a 868 MHz signal with an envelope which corresponds to the UART data. In the first step, a random pattern is sent, so that the comparator at the receiver is enabled once, waking the receiver from EM4. After a short delay to allow startup of the receiver, the data pattern is sent. Finally, the RF carrier is deactivated to safe energy.

         

        4.2 Receiver

         The receiver is the subject of our energy optimization, with its program being shown in the flow diagram below. Initially, it is set to EM4, also disabling the RF transceiver. Once a 868 MHz wireless signal is turned on, this impulse will propagate through the air to the OOK demodulator and will trigger the comparator, resulting in a pin interrupt. The controller will initialize by setting up DMA, RTC (with external crystal to decrease power consumption and clock jitter) and the LEUART interface in receiving mode (also see the corresponding functions below). Then, the DMA controller stores incoming data into the RAM being in EM2. The incoming data will be scanned by the DMA/LEUART in a way that the LEUART interrupt service routine will activated once a particular byte (signal frame pattern), is transmitted. Thereby, we can realize two functionalities:

        • a low-power data transmission: the signal frame pattern tells the controller that the data transmission is finished
        • a low power wake-up receiver: the signal frame pattern is different for different sensor nodes; once a node receives its signal frame pattern, it can initiate measurements and transmit the measurement data back to the requesting node.

        The nice thing is that the EFM32 LEUART can automatically search for this signal frame pattern and trigger the LEUART0IRQHandler() while being in EM2. Thus, scanning the incoming data for a wake-up address is very power efficient.

        In our example, we used the wake-up byte 'carriage return' to initiate a measurement. If no signal frame pattern is received within 300 ms, we go back to EM4 to safe more energy. For the measurement, we read data from a Si7012 (using the Si7013 library) and transmit it back by turning the receiver into the LEUART transmitter described in 4.1.

         

        FlowChart.png

        Figure 5: Flow diagram of the receiver software. The important functions are presented in the attachment SourceCode.txt.

         

        5. Power consumption & results

        While the transmit mode is characterized by the power consumption of the RF transceiver (approx. 20 mA), the receiver is an ultra-low power device. When waiting for an RF pulse, the device consumes only 600 nA. Being triggered, 2 mA will shortly consumed by the initialization. In data receiving mode using LEUART, approximately 2 microA are consumed. Both a picture of the measurement setup in EM4 and the Energy Profiler screenshot prove the low power consumption. For the Energy Profiler screenshot, we sent the STK3400 onboard controller to EM4 as well and connected our custom board to the VMCU breakout pin. Thus, these screenshots also show the power consumption of a second Gecko in EM4, so that roughly 200 nA should be subtracted.

         

        WireLEss-EnergyMeasurement.jpg

        Figure 6: Supply current measurement while being in RX listening mode (EM4). The meter shows 570 nA.

         

         

        EnergyConsumption.png

        Figure 7: Low energy profiler screenshot with Gecko on STK3400 still being connected.

         

        Even in RX receiving mode (2 microA), our circuit could listen for 10 years using a 180 mAh coin cell, neglecting self-discharge. Even energy harvesting devices can easily power this RF receiver. Still, the range of our radio can be improved, as it is only 2 meters so far. Cat Wink

         

        If you have any questions, feel free to ask!

         

        Best regards

        Joachim, Markus and Sebastian

         

        Attachment: Some code of the most important software functions.

      • Low Power Contest 2015: self-powered battery tester

        hlipka | 11/333/2015 | 11:03 PM

        Introduction
        If you have kids at home, you surely know this problem: most of the toys need batteries. So you always have a stash of batteries in unknown state laying around and need to check them. (Even if you don't have kids you probably know this problem). Or you have a device that stopped working and you want to check whether its the batteries fault or not.
        So you can use one of these cheap plasticky low-cost ones
        pa07-1500.jpg
        Maybe you have a cheap DMM that came with a battery test mode (my first one does:

        cheap_DMM.JPG

        but it shows a value somewhere around 40 without any indication whether that's good or bad).

         

        But we are engineers. We love getting precise and meaningful data, even if its just about something as ordinary as a battery. So you can decide to do some real measurements using your DMM. Since a battery needs to be measured under some load this gets a little bit tedious, swapping in and out different resistors while probing the battery voltage. But since we are engineers, we just take this as an excuse to start another project, don't we?

        But I don't want to have just another gadget that also need a batteries - especially since this could end up in a problem of recursion. So I wanted to have a battery tester that

        • can be used for alkaline and NiMH batteries
        • gives me accurate and meaningful data
        • doesn't need batteries by itself

        Since it needs to perform some calculations, it must have a MCU, which kind of defeats the idea of being battery-less. But why not powering it by the battery that's currently measured? There are boost converters available that start at 0.65V, and when the battery is below that it's really dead anyway. And the EFM32 chips are energy-saving enough to not drain the battery.

        So the idea to my battery tester was born. Its using a Zero Gecko (with the ZG STK and its Memory LCD), which gets powered by a boost converter. When the battery voltage drops too low during measurements (the tester applies a load up to 100mA) the Zero gecko is powered purely by the capacitors that decouple the voltage rails.

        The tester measures the battery voltage without any load (apart from the boost converter itself), with 10 mA and with 100 mA load (though the actual load depends on the battery voltage). From there it calculates an average voltage (not just an arithmetic average but a weighted one which places emphasis on voltage under load). This voltage is used, together with typical discharge curves for NiMH and alkaline batteries, to estimate the remaining capacity. But the measurements under load are also used to calculate the internal resistance of the battery. For this the change in voltage and the change in flowing current is used.

        I used the Panasonic battery handbooks for getting typical discharge curves. Unfortunately PDFs are not allowed to upload.

        Instead of just showing the estimated capacity, the battery tester shows all the data is has gathered and calculated. This allows the user to check suitability for the desired use. If the battery should be used for a low-power application (e.g. a watch) then the voltage with low load is important. If its about to be used for something power-hungry (e.g. a lamp) then the internal resistance needs to be looked at, together with the voltage at 100 mA load.

        The schematic
        I planned to tester to be connected to the expansion header of the Zero Gecko STK. This meant that the tester would not be small. But I wanted to use the Memory LCD, its not exactly friendly to manual soldering. So I went ahead and checked which connection of the Expansion header I could use for my tester. It turned out that there aren't many left. The STK3200 suffers from the same problem as all the other Silabs (or rather EnergyMicro) STKs: most of the pins on the headers are already taken by the peripherals on the board. I don't know why this is so, but I had this problem with all the STKs so far. But in the end I found one free pin for an analog input (PD6) and two that could act as digital outputs (PE12 and PE13).

        The schematic is not overly complex (for the original image see the attachment):
        Self-powered battery tester - schematic
        The main component is of course the boost converter, following the data sheet examples closely. I used a MCP1640 for two reasons: it can run with a start-up voltage of 0.65V (and after start-up as low as 0.35V), and can cope with voltage on its output while the input voltage is disconnected (battery gets removed while the storage caps are still full). The schematic shows its output set to 3.0V, but in the end I changed it to 3.3V (I will explain the reason when explaining the software). During start-up the MCU might see the battery voltage on PD7 while Vmcu is still not present (start-up time of the MCP1640 is about 0.75 ms) D2 has been added which powers the EFM32 directly from the battery during that time. Together with the resistor divider R2+R7 the analog input will not go above the supply voltage.

        F1 and D1 protect against reverse insertion of the battery and limit any reverse voltage to a small value. The schematic shows three batteries, this is because I wanted to have different options to connect the battery under test (AA holder, AAA holder and via header pins).

        The output of the boost converter is fed into the two storage capacitors C4 and C5. They are intended to keep the MCU and the display alive even when the battery is not capable of delivering enough cuirrent (after measurement). R5 limits the inrush current (to allow the boost converter graceful startup with low voltages), while D3 allows full current (without big voltage drop) to flow to the MCU when the boots converter cannot deliver power anymore.

        When I had done a prototype I had recognized before that these storage capacitors are not needed actually. When populating the PCB I added just one of the first, and it was able to power to circuit for more than 30 seconds. When I removed it then, even the output capacitor of the boost converter (10µF) and the capacitance on the STK (another 20µF) are enough to provide power for about 4 seconds after removal of the battery. So this part could be skipped actually.

        The output voltage of my circuit is connected to Vmcu on the expansion header. Doing so ensures that only the parts of the STK that are actually needed are powered. using the 3.3V rail means that the MCU current sense circuitry, as well as all the parts that handle the external debug connector are powered too (and the 5V line powers everything). The big drawback is that powering the Vmcu line dis-allows powering the STK by the USB connector. So I could not use the PCB with a battery connected while debugging (or even flashing) the STK. But since the MCP1640 is not susceptible to voltages on its output, removing the battery is enough. But it would be nice to have this changed in future revisions of this board.

        Last part is the load generation circuitry. During my first experiments I used NPN transistors to switch the load resistors, but the Vce voltage drop made calculating the current difficult. So I'M using N-Channel MOSFETS now. The 2N7002 has an on-state resistance of about 3 ohms, so with a 1.2V battery voltage the currents are close to the desired 10 and 100 mA. Both FETs are switched by the MCU when it want to measure voltage under load.

        The PCB
        batt_test2_pcb.png
        When I started the design I oriented its size on the width of the STK3200 expansion header. Back then I did not plan with adding the battery connectors on the PCB but instead wanted to use external battery compartments. But then I discovered that they are designed to firmly hold the batteries in them so one could not swap them easily in and out. For a normal device this is desired, but for a battery tester this is counter-productive. So, quite late in the design process, I enlarged the PCB to accommodate two pairs of battery contacts.

        Making the PCB wider also allowed me to add mounting holes that fit the ones in the STK so the battery tester PCB can be firmly fixed to the STK. For the connector I did not use a SMD one, but a normal through-hole connector that gets mounted sideways on the PCB. This results in the PCB sitting above the STK, otherwise it would be at the same height.

        The PCB was designed with being single-sided in mind. There are some traces on the bottom side, but I minimized them because they are now manual bridges. I specified them as 0.6mm holes and drilled them as 0.4mm ones, using 0.25mm wires (single strains from a larger wire).

        I manufactured the PCB using the toner-transfer method. This was the first time I did so, and it worked quite well. A while ago I had bought two sheet on Press-n-peel blue, and I was amazed how easy it was. The only problem I had was that my printer seems to be low on toner - some of the larger copper areas were not uniformly covered with toner so there are not holes in the copper.
        PCB_pnp_blue.JPG
        But all the traces and finer structures went fine (the smallest traces were 0.25 mm / 10 mil, and the pin pitch of the MCP1640 is 0.95 mm / about 40 mil). There were some mistakes on the PCB, though. The area designated for the inductor is a little bit small (though the pads itself are OK), and I used a too large footprint for two of the diodes (probably a copy-and-paste error in KiCad). I also added a big copper plane on the topside of the battery connectors, which would shorten the connectors after soldering.


        Building a real tester
        This is how it looks as a finished battery tester:

        batt_tester_finished.JPG
        I already mentioned that the battery tester PCB is mounted sideways on the STKs expansion header. To give the whole assembly some stability I mounted the STK on an acrylic plate. When the battery tester PCB is mounted its other side is held in place by a rubber stand-off.


        The Software
        The software can be divided in three basic parts. First comes all the initialization stuff, the the measurements are done, and the last part calculates all the results and shows them on the LCD.

        For the initialization I decided to try the hardware configuration wizard / perspective. This is not strictly needed since in my experience the documentation both for the hardware and for the libraries (especially emlib) are quite good and allow to work without such a tool. But it was new since I did work last time with SimplicityStudio and I just wanted to try it. All in all it worked quite well but there are some details that could be improved. First, you need to remember to switch to the configuration perspective to use the tool - just opening the *.hwconf file is not sufficient. The I noticed that not all allowed configurations are supported - in my case the ADC configuration allowed only 2x oversampling. The tool also creates code for all unused peripherals, which can be confusing when looking at the code. But in the end it was a good help and got me started faster than otherwise.

        When the code has called the generated start-up procedure, it sets up the Memory LCD (by calling the BSP support routine) and displays a first test indicating the tester starts measuring. When writing this code it took a while to get all the needed libraries correct - they are not documented AFAIK. And I find it strange that I need the emlib_usart code for using this display. It uses SPI, but emlib_spi is not needed... After this first message all the remaining clocks are activated (this cannot be done in the configuration perspective AFAICS).

        For the measurements the battery tester wait for half a second to allow the voltage to stabilize. During this time the boost converter can fill all caps on the board, and the voltage of the battery can return to its no-load level. during this time the MCU goes to EM2 to draw as few current as possible. When the first measurement has been taken, the first FET is turned on to create a 10mA load to the battery. The voltage of the battery is allowed to stabilize for 100 ms before the voltage is measured. Then the other load resistor is turned on (for a 100 mA load) and the same procedure happens. After that both loads are turned off, and the ADC clocks is also turned off.

        The last part of the code calculates all the results from the measurements. The three voltages are averaged (while giving the voltage measured under load more weight). Then the actual currents the flowed during the load measurements are calculated, and using this the internal impedance of the battery is calculated.

        The last calculation tries to get an estimated remaining capacity from the measured voltage. For that I took typical discharge curves (I found some good ones in the Panasonic battery handbooks, see the attachments). I interpolated the curves using three to four line segments to make the calculation not too complicated. The points for these segments are stored as #DEFINEs in the code, and are used for interpolation.

        To avoid confusing results (such as negative impedance) the measured values are sanity-checked before calculation. For example, the voltages under load must be smaller than without load - noise could affect the measurements. The ADC is configured to use 32x oversampling and the internal RC-filter, but I saw this problem sometimes. Also too small battery voltages indicate that the battery is dead anyway so the impedance is meaningless.

        When all calculation are made, all the measured values are shown on the LCD. Then all clocks that are not needed any more are disabled, and the CMU goes to EM2 to draw as few power as possible.

        The code makes use of three low-power features of the EFM32 architecture. First is the internal delay function that utilizes the RTC to sleep in energy mode 2. Using the provided API makes this implementation quite simple and is great energy-saver. Second is the ability to turn of peripherals (and their clocks) that are not in use. Doing so even during program runtime means that I can disable what I don't need and save even more power. Third, setting the clocks speeds easily and during runtime also means that one can save a good amount of energy when not all the horsepower of the MCU is needed.

        Energy consumption measurements
        Unfortunately the EnergyAware profiler doesn't work under Ubuntu (see http://community.silabs.com/t5/Simplicity-Studio-and-Software/Energy-Profiler-not-working-under-Ubuntu-14-04/td-p/152105 ). If it would I had tried to further optimize the clock speeds. For example I would have checked how much of a difference it makes when the MCU is clocked lower during the ADC measurements - I only need the full speed for the calculations. This problem also means I cannot provide a EnergyScore.

        To get at least a certain understanding of how much current the battery tester draws I created a small "energy debugging" adapter that just adds a 51 ohm resistor to the Vmcu line. There I connected my scope and got some measurements:
        current_measurement.png
        My scope allows to convert the measured voltage into a current with a sensitivity of 50V/A which is what I needed. I triggered on the jump in current consumption that happens when I press the reset button. One can clearly see different phases of execution:
        * first there is a long initialization delay. I'm not sure what's causing this, it might be the LCD init code. This might need some investigation, but then 1.5 mA will not kill the battery hopefully...
        * Then after one second the actual code kicks in and writes the first message to the display - thats the first big spike
        * then the current consumption drops down to nearly zero with just three small spikes. This is the MCU waiting and doing the three ADC measurements
        * right after that the calculations and their display take nearly 250 ms
        * and after that the current goes down to zero again

        My DMM measured the current consumption at about 1.8 µA. This is more than the data sheet specifies form EM2, but there is some hardware running to keep the Memory LCD alive. For my application it doesn't really matter, though. When the battery is removed from the holder, the display stays alive for another 5 seconds at least so there is plenty of time to read the results even when the battery is dead after the measurements.

        Conclusions
        I uploaded a video demonstrating the use of the battery tester to Youtube:



        It shows the results for different batteries (one alkaline, two NiMH) in different states of discharge.

         

        I'm quite happy how this project turned out. The tester proved to be really useful even during its development - I have a large set of rechargeable batteries that sometimes need testing.

         

        From a development perspective it was easier than expected. The hardware configuration tool of SimplityStudio was quite helpful, despite its shortcomings (which I hope will be handled in upcoming releases). The emlib libraries make programming quite easy, especially manipulating the clocks and hardware set-up. I did not need to any special fiddling around to get a really low energy consumption. I just applied some com,mon sense how to save energy, and I was down to below 2 µA standby current. If I needed ever lower current I could dig into the code to see what is set-up by the BSP code.

        If I would to be start over again maybe I would make some changes to the layout of the PCB. Maybe I would be so adventurous and create a all-in-one PCB with a Zero Gecko and the memory LCD on it - then it would be even smaller (maybe even the size of the PCB as it is now). But for now I'm happy as it is.

         

        If you have any questions to my schematic or the code, feel free to ask. If you want to re-use, go ahead! (Maybe mention my name...)

         

        I would like to thank SiLabs for this contest, and for sponsoring the Zero Gecko Kit. I really like your gear!

      • Low Power Contest 2015: Wireless Sensor Platform

        TheGarageLab | 11/333/2015 | 12:30 AM

        This entry is a component of a larger project called Sensaura which provides a hardware and software solution to implement low power sensors communicating over a wireless network protocol and publish values to a MQTT message bus.

         sensor_and_breakout.jpg

        This project consists of a prototype implementation of a SensNode processor module using a EFM32 Zero Gecko starter kit and a simple sensor backpack to test the power consumption and functionality of the design.

         

        Usefulness

         

        The goal is to develop a small, cheap, wireless sensor board with a well defined API, form factor and network protocol that can be used as the basis for a range of customised sensors.

        hardware_modules.png 

        The sensors are intended to be run from batteries (the ideal design should operate for 6 months on a single AA cell) or other disconnected power sources which allows for deployment in areas without a fixed power supply available. Sensor data is gathered through an adapter connected to an IP connected host, formatted as JSON and published to an MQTT server for consumption. This design allows maximum flexibility without requiring the sensors themselves to be connected to the internet.

         

        Low Power Features

         

        To achieve the desired goal of operating on a single AA cell for a period of 6 months power usage must be carefully carefully controlled both in the design of the sensor and peripheral circuitry as well as by utilising the low power features of the EFM32 CPU.

         

        The processor module is anticipated to spend the majority of it's time in sleep mode, only waking up at periodic intervals to read sensors and transmit results. In the case of the EFM32 this will set the processor to energy mode 3 (EM3) which allows it to wake up on RTC or pin change events at the discretion of the firmware.

         

        As the design is generic and intended for use with other ARM processors as well not all low power features of the EFM32 (such as LeSENSE) can be utilised due to difficulty exposing those features in a generic way.

         

        Implementation

         

        Due to time constraints the implementation of the prototype is not yet complete, some functionality is untested or only partially implemented. The current code base for the EFM32 prototype is available on GitHub and will be updated as more progress is made.

         

        Hardware

         

        The hardware components consist of the EFM32ZG-STK3200 Development Kit, a breakout board matching the final board footprint with a NRF24L01+ wireless module fitted and jumper leads to connect to the IO pins on the development board and a simple sensor backpack for testing.

         zero_gecko_prototype.jpg

        The sensor backpack consists of the following components:

         

        Two of the components use an I2C interface for communication, the moisture sensor requires a digital output to control the current flow for measurement and an analog input to take the reading. Both boards are single sided PCBs that were milled with a small CNC machine. One of the goals of the project is to ensure that processor and sensor boards can be made using resources generally available to the hobbiest - milling or etching single side boards that can be hand soldered is a core requirement.

         

        To allow data being transmitted on the NRF24L01 network to be captured and used on a PC a simple Arduino based adapter was also constructed. This simply uses an Arduino Nano to report any packets received on the NRF24L01 network over a serial port connection and was assembled on a breadboard.

         

        Software

         

        As the SensNode is intended to be processor agnostic I use a simple API that provides generic access to GPIO, analog and timing functions. For the purposes of the prototype I implemented a shim layer that implements the SensNode API using the EMLIB Library. The actual sensor firmware was then implemented with calls to the SensNode API.

         

        Implementing a sensor like this is relatively simple in concept - the main application loop simply reads the values of the various sensors and transmits them over the NRF24L01 network and then puts the processor to sleep for a specified period of time before repeating the process. For this particular sensor there are no unpredictable events (such as motion sensors) so the wake up process is purely driven by the real time clock. The values measured in this case are also fairly slow to change (there would not be a significant change over a duration measured in minutes) so it can spend the
        majority of it's time in sleep mode.

         

        Conclusion

         

        As I mentioned earlier the project is not yet complete. Time constraints and some unexpected difficulty with the NRF24L01 interface prohibited a full implementation from being completed in time for this submission. As a result any power profile readings taken at this stage would not be of much use.

         

        On the positive side however the project has exposed some improvements that can be made to the overall design;

         

        1. The main issue I had with the NRF24L01 module was the stability of the signals on the SPI bus. Most of these are caused by the use of jumper wires to connect it to the development board - a common problem when working with external peripherals.
        2. Due to a misreading of the datasheet for the CPU I assumed that the LEUART could only be driven by the 32.768kHz clock and only supported 9600 baud transmission. As a result I used the two USART channels to implement I2C and serial communications and provided a bit banged SPI interface. This further complicated the interface to the NRF24L01.
        3. In a design such as this the power consumption of the CPU is only a part of the total picture - power usage by external peripherals needs to be managed correctly as well. One enhancement I intend to make to the design is to provide the processor sleep state available on a GPIO pin - this will allow external circuitry to shut down if needed when the processor goes into sleep mode which will further reduce the total power consumption.

        Development on this prototype will continue with the eventual goal of moving to a EFM32HG108F64G CPU on it's own dedicated board.

         

        This prototype is part of a much larger project which is moving somewhat slowly with only a single person working on it part time. If you find the design concept interesting I encourage you to take a look at the Sensaura project in more detail - I would welcome any feedback or assistance.

      • Low Power Contest 2015:µCoaster. Smart, indirect temperature sensing coaster

        ToniT800 | 11/331/2015 | 10:55 PM

        How many times you made yourself a cup of tea/coffee and then forgot to drink it?

        Once you remember, it is already cold and doesn't taste anymore.

        It happened  many times to me, so I decided to do something about it.

         

        After winning my  Gecko STK here:

        Win an EFM32 STK with your idea

        I decided to go on and finish long forgotten project: µCoaster.

         

        This coaster uses TMP006 Infrared temperature sensor. This sensor measures indirectly the surface temperature by its infrared radiation. This is perfect IC for my idea, since there is no other way to measure temperature of a cup/plate of different sizes, shapes and materials.

        By placing TMP006 under the cup, I can perfectly measure its temperature. Moreover the power consumption is very low :1µA in shut down mode and around 200µA  in active mode.

        EFM32 fits here perfectly, since it also consumes very little power.

         

         

        Here are µCoaster main features:

        -Stay in Stand by mode consuming  10-20µA

        -Each 10 second check the  ON button.If touch is detected wake up.

        -It is possible to set the desired temperature by using  according buttons.

        -Additional button resets any action and puts µCoaster back to Stand By

        -Additional button allows you to read current temperature and set it as desired temp for the future (In case you dont know exact preferable temperature, you can just measure and save the one you enjoy)

        -The temperature is shown by 8 red LED in binary, which are controlled by 8 bit shift register.

        -There is green LED and a buzzer for status notifications

        -3,3V boost converter ensures there is enough voltage for bright LED's and buzzer , even if battery is low.

         

        Building process:

        Here is first prototype.

        WP_20151002_00_33_45_Pro (1).jpg

        After the concept has been proved, I started to work on custom PCB

        sche.pngpcb.pngPCB3Dt.pngPCB3Db.png

        While  PCB were in production, I had some creative time working on caseRobot Happy

         WP_20151104_16_16_26_Pro__highres.jpg

        Meanwhile the PCB arrived:

        I made a few newbie design  mistakes, but this is also my first big project...

        PCB looks cool, but the production quality is pretty poor(made by Ragworm, UK)WP_20151110_16_13_43_Pro.jpg

         Anyway, time to assemble and test:

        WP_20151125_16_13_20_Pro__highres.jpg

         

        After many sleepless nights and few dead geckos, it finally works!! Time to calibrate the TMP006 using 

        Greisinger GMH2710 (Accuracy +-0.1 °C )

        WP_20151127_02_45_32_Pro__highres.jpg

         

         The sensor is calibrated for the clear glass material, but it actually works pretty good with many other surfaces  like ceramics, cardboard,plastic etc, since these materials have pretty similar emission constant.

         

         You must avoid materials with very low emissivity, like shiny, polished metals.

        You also have to consider the thickness of the material which effectively isolate the liquid. In case of glass bowl, the temperature of water is pretty much equal to the temperature of the surface outside.

        On the other hand, I use big  white mug (see video), which has very thick wall. The temperature outside  differs from the inside by  about 6°C. In my code I compensate this temperature loss.

        With calibrated sensor, the sensing accuracy is +-2°C which is more then enough for this purpose.

         

         Power consumption:

        I am sorry to say, but during development the boost converter died due to my design  mistake, his death took the EFM32 on my PCB and the whole STK dev board, Which made it impossible to use Energy Aware featureRobot Sad

        After losing few more geckos I finally found  the faulty part, corrected my mistake and replaced the boost converter.But STK is now dead ....luckily I had separate Segger J-Link so I can go on with my project.

        Overall I can summarize the power consumption in

        stand by mode:

        -EFM32 In EM2 with RTC consumes around 2-3 µA

        -TMP006 on Power down draws around 1 µA

        -NCP1402 in Off states consumes 1 µA

        Ideally should be around 5-6 µA,. There are many components on the board, Which also add some leakage current to the system

        I measured around 12µA in stand by (see attached video)

         

        Active mode

        Here the MCU  consumes relatively  insignificant amount of power. The most current flows through LED's and Buzzer.  Around 800µA  flows through single red LED.

        This mode consumes lots of energy, but since µC stays in it for a very short period of time, it is not very significant.

         

        Measurment mode:

        In this mode, the MCU stays most of the time in EM2. Waking up each 10 s, activating  TMP006 and going in EM3 until valid data is ready.

        After that it deactivates  the sensor and goes in EM2 for the next 10s.

        The TMP006 consumes around 240µA while performing measurements.One measurement takes 1 second to complete.

        To sum up, most of the time  the system consumes as much energy as in stand by.

         

        Since i dont have any graphs, here is at least short video of current consumption in  stand by and active mode:

         

        Here are few pics of final product and of course the presentationRobot Happy Enjoy.

        WP_20151127_15_30_38_Pro.jpg

        WP_20151127_15_31_17_Pro.jpg

         

        Demonstration video

         

        The whole code on github (read my code at your own risk=)

        https://github.com/AntonZero/uCoaster

         

         

         

      • Low Power Contest 2015: Weather Station Mesh-Network

        michael_k | 11/331/2015 | 08:48 PM

        This project is about a wireless weather station network for the winery to increase the crop. Each weather station measures the temperature, air humidity, soil humidity, wind-speed, rainfall and is powered by solar energy. To increase the range, the weather stations should form a mesh network with routers units.

        In this post, I only explain the firmware and which peripherals I have used. For a full description of the project, see the following link. 

        Project: Weather Station Mesh-Network

         

        Prototype

        Einbau_Platine_en.jpg

         weatherstation_sch.png

         

        Firmware Description

        The hole system has basically two states (except the GPS-state). After the initialization phase the EFM32 goes in EM2 for a time span of 55 minutes, to reach a low power consumption. In this sleep-state only the LETIMER and the ACMP are active. When the time is over, the LETIMER generates an interrupt to wake up the EFM32 and it will start the wind-speed measurement for one minute. After 60 minutes, the EFM32 wakes up and goes into active-state to get and send all the data.

         

        Firmwareplan_en.png

         

        Current Consumption

        lpcontest_energyprofiler.PNG

        The whole system only needs about 20µA when it is in sleep-state. In active-state the current consumption rises up to 3mA when measuring the data. After the EFM32 enables the XBee for data transmission, the current reaches it's peak at 20 – 30mA.

        Unfortunately I wasn't able to get the real Energy Score, thus the energy profiler wasn't able to capture the data for over one hour. Furthermore the Energy Score is based on a coin cell, so it isn't relevant for my project, because I'm using a Li-Io battery.

         

        Used Peripherals

        LETIMER: wakes up the CPU at a determined time

        ACMP: enables/disables the charging circuit (LTC4077) according to the battery voltage level

        Code:

        void ACMP1_Init(uint8_t in_pos, uint8_t in_neg, bool out_inv)
        {
        	int temp;
        
        	CMU->HFPERCLKEN0 |= CMU_HFPERCLKEN0_ACMP1|CMU_HFPERCLKEN0_GPIO;
        
        	temp = ACMP1->CTRL;
        	temp &= ~0x778;
        	temp |= ACMP_CTRL_HYSTSEL_HYST7|ACMP_CTRL_WARMTIME_256CYCLES|out_inv << 3;
        	ACMP1->CTRL = temp;
        
        	temp = ACMP1->INPUTSEL;
        	temp &= ~0xF7;
        	temp |= in_pos|in_neg << 4;
        	ACMP1->INPUTSEL = temp;
        
        	ACMP1->ROUTE |= ACMP_ROUTE_LOCATION_LOC2|ACMP_ROUTE_ACMPPEN;
        	GPIO->P[3].MODEL |= GPIO_P_MODEL_MODE7_PUSHPULL;
        
        	ACMP1->CTRL |= ACMP_CTRL_EN;
        }

        I2C: communication with the SHT25 (T/RH)

        Code:

        float sht25_get_temp(void)                     //SHT25 temperature
        {
        	char data[3];
        	float h, h1, h2;
        	uint16_t t;
        
         	I2C0_start(SHT25_W_ADDR);
         	I2C0_send(SHT25_T_COMMAND);
         	I2C0_rep_start(SHT25_R_ADDR);
         	I2C0_receive(&data[0]);
         	I2C0_receive(&data[1]);
         	I2C0_receive(&data[2]);
         	I2C0_stop();
        
         	t = data[1]<<8;   			//shift LSB to  8th pos.
         	t += data[0];				//MSB at pos. 7-0
        
        	h = t*175.72;				
        	h1 = h/65536;
        	h2 = h1-46.85;
        	return h2;
        }

        USART: communication with the GPS module

        LEUART: communication with the XBee module

        Code:

        void send_API_Frame(int wert, int NODEID, int MID)
        {
        	char buf[20], checksum;
        	int sign=0, sum1=0, sum2=0, i, check;
        	char api_frame_header[3]={START,0x00,LENGTH};
        	char api_frame_body[60]={FRAME_TYPE,FRAME_ID,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xFF,0xFE,BROADCAST,OPTION};
        
        	if(wert<0)
        	{
        		sign=0;
        		wert *= -1;
        	}
        
        	sprintf(buf,"=%01d%02d%01d%05d%c",NODEID,MID,sign,wert,0x04);
        
        	//calc 8-bit checksum
        	for(i=0;i<=13;i++)
        	{
        		sum1 += api_frame_body[i];
        	}
        	for(i=0;i<=10;i++)
        	{
        		sum2 += buf[i];
        	}
        
        	sum1 += sum2;
        	sum1 &= 0xFF;   				
        	check = 0xFF-sum1;				
        	checksum = check;
        
        	LEUART0_send_char_n(api_frame_header,3);
        	LEUART0_send_char_n(api_frame_body,14);
        	LEUART0_send_string(buf);
        	LEUART0_send_char(checksum);
        
        }

         ADC: measures the battery voltage, using the ADC in single conversion mode

         

        Main

        /*
         * wetterstation_main.c
         *
         *  Created on: 10.10.2014
         *      Author: Michael Koefinger
         */
        #include "wetterstation.h"
        
        extern volatile uint8_t rtc_flag, gps_flag, tilt_flag;
        
        int main(void)
        
        {
        	/*****************Clock Settings******************/
        	CLK_Init();
        	/**************Peripheral Settings****************/
        	Peripherie_Init();
        	/****************Timer Settings*******************/
        	LETIMER0_set_interrupt(CMU_LFAPRESC0_LETIMER0_DIV512,LETIM_COMP_60);
        	/********************Loop*************************/
        
        	while(1)
        	{
        		if(rtc_flag == 1)
        		{
        			VDD_Peripherie_ON();
        			measure_send();					//read the sensor data and send it to the base-station
        			VDD_Peripherie_OFF();
        			rtc_flag = 0;
        		}
        		if(gps_flag == 1)
        		{
        			GPS_send_pos();					//send current position to base-station
        			gps_flag = 0;
        		}
        		if(tilt_flag >= 3)
        		{
        			tilt_alert_send();				//send a tilt alert to the base-station
        			tilt_flag = 0;
        		}
        
        		enter_EMx(2);						//go to Energy Mode 2
        		__WFI();							//wait for interrupt core instruction
        
        	}
        
        }

         

      • Low Power Contest 2015: Take-A-Pill: Medicine Reminder

        PGrzes | 11/330/2015 | 08:26 PM

        Every kind of medical treatment is more efficient when a patient takes his drugs regularly at specific time of a day. This condition is extremely important in serious diseases such as cancer, hypertension or diabetes. Unfortunately, in real life people often forget about their simple duties and skip their doses. When someone takes the pills for a long time (in chronic diseases) there is additional risk of doubling the dose if patient is not sure if he took a pill or not. Problems like mentioned affect elders (especially with memory diseases) and busy people.

         

        To solve this challenge I decided to design a medicine reminder. Because of the specific target, there are some assumptions to achieve:

        • Interface should be as simple as possible
        • Device has to work for a long time on battery
        • Medicine containers should be easy to clean or replace
        • Low maintenance costs
        • Resist for sudden moves

        A heart of device is a Starter Kit EFM32GG-STK3700. In my application I used two buttons and LCD display mounted in STK. Additionally I connected a low current LED matrix (7x3) closed in wooden enclosure. Everything is powered by small CR2032 battery.

         

        Theory of operation is very simple. Once per week a nurse places a pills in a small plastic glass. Every column is a different weekday and every row is a different time of day. Current weekday and time can be changed by pushbuttons and it is displayed on LCD. At preprogramed hour (8 a.m., 1 p.m. and 6 p.m.) proper glass is highlighted. When the patient take a pill he should push the button to confirm. A device goes to sleep mode and it wakes up when there is time to take next pills.

         

        Most of hardware was already done on the STK. LED matrix and glasses deserve for special attention. Every LED is placed inside a little ring magnet. A glass consist of two plastic containers. Inside of outer glass there is a metal pad glued to the bottom. Inner glass, where pills are held, is placed inside. A magnet snap the pad and the whole container stays in place during rapid moves. Plastic glasses are very cheap so to maintain cleanliness inner container should be replaced from time to time.

        Software is based on clock demo. I have added low power LED matrix handling. I expanded a real time clock handling to count weekdays. Instead of static text, LCD displays a current weekday. When the glass is highlighted, pushing any of button will turn of the LED.

         

        For power consumption analysis I used Energy Profiler and energyAware Battery software. In sleep mode a device consume only 1,6uA. Program wakes up every minute to refresh the LCD. This process last for 15ms and power consumption rises to 3,54mA. When the LED is turned on, supply current hits 4,32mA.

         

        With assumption that a patient will take a pill approx. 5 minutes after LED is on, a single CR2032 battery will power a device for around 192 days. This result can be unsatisfying, so I recommend using two alkaline AA batteries is series (almost 6 years without battery replacement).

         

        A device needs some improvements. First of all I have to 3d print a fitting enclosure for electronics. Moreover I should add some extra buttons to avoid accidentaly time change. Bluetooth connection with smartphone would be a nice feature. 

         

         

        Enjoy!

         

        Link to youtube record: https://youtu.be/IAPwW3jWMzc