weekly update 9/31 – 10/6 – Power management testing

This week the power management group spent our time testing the hardware and the software, building the voyage divider to measure and report the battery output level, simulating the power requirement of the complete sensor/arduino/wifi system so that we can test and measure it’s power draw in action.

 

The voltage divider that we finally settled on is comprised of two resistors 11k and 18k ohms which allow us to measure the voltage output level of the arduino board relative to an internal 1.1 volt reference that aruduino has.

00107

we use the following code in a function called readVoltage to read the voltage:

#define BATTERY_PIN 0

 

int readVoltage() {
analogReference(INTERNAL);
int val;
val = analogRead(BATTERY_PIN);
Serial.print(“Battery voltage is: “);
Serial.println(val);
return val;

}

We simulate the power draw of the wifi card sending data with 4 LEDs in partallel being turned on for 7 seconds.

void connectToWifi() {
// this is a simulation for wifi connection assuming it will require 7s
digitalWrite(WIFI_PIN, HIGH);
delay(7000);
digitalWrite(WIFI_PIN, LOW);
}

In this way we can get an idea of how the system as a whole willo drain a battery by multiplying the sampling rate by a factor in order the extrapolate 6 months worth of data

Advertisements

Weekly blog 10/14 – 10/21 work in our group

In the power management group I suggested that we give each person a specific task so that everyone knows what they are supposed to do. We decided to give the tasks to a pair.

Ishwar + Annie: Have an appropriate block of code ready for our Arduino

Dadbeh + xhafer: Use the code and do hardware modifications to achieve the least power consumption in every cycle

 

The next phase would be testing which requires the code from other groups so we can run actual tests with the proper hardware in working condition and measure the battery life and power requirements.

 

 

weekly blog 10/7 – 10/14 – structs

Structs

This week we learned a lot about structs, how to use them to package data and also how to manage the memory that is allocated to them.  The following defines a struct of type Point which may be referenced using the alias Point. Each struct of this type has two values inside of it which may be accessed by using the . operator.

Struct

typedef struct Point {

int x;

int y;

} Point;

By using the alias whenever we want to define a new variable of type Point we wont have to define it by:

struct Point newPoint;

We could just simply define the new variable like we define any other variable:

Point newPoint;

Based on the method that memory is allocated to a struct, there are two types of structs

Static structs:

the memory size allocated to “data” is static meaning that the amount and also the location of the memory that is assigned to the struct does not change.

The following defines an array of type Point named Points that has “size” things inside of it. where size is an integer.

  Point points[size]

now accessing the values inside each entry in the array is easy by:

points[4].x = 1435

 

dynamic struct

Dynamic structs facilitate change of data size during the runtime. It is possible to change the assigned values of elements, as it was with static structures. In dynamic struct the initial allocated memory size is not a problem. It is possible to add new elements, remove existing elements or do any kind of operation on data set without considering about the memory space allocated initially.

The following defines a pointer p that points to the begining of a block of memory with size hat is equal to the size of the Point struct.

Point *p = (Point *)malloc(sizeof(Point));

To access the values strored in that location we can use

p->x = integer1;

p->y = integer2;

 

 

sources:

Static Data Structures vs. Dynamic Data Structures

C Head first

Wikipedia

 

 

Weekly blog 10/7 – 10/14

One concern about the implementation of the temperature and humidity sensors is about the best way to implement periodic power down or idle modes followed by pre-scheduled activity times in a way that optimizes the power consumption of the system and ensures reliable and maintenance free operation of each sensor for the longest time possible.

 

We do not want to use method similar to sleep() in python or delay() in C to implement the periodic waking up and powering down of the Arduino/sensor system since these functions keep the Arduino busy using considerable current and they also halt or suspend almost any other Arduino functionality while they are in effect; in other words while the Arduino in in delay() it will not be responsive to almost any other command.

Rocket Scream offers these features related to powering down and waking up the Arduino.

  • Supports all sleeping mode of ATmega328P:
    • Idle.
    • ADC reduction mode.
    • Power save.
    • Power down.
    • Standby.
    • Extended standby.
  • Selectable sleep duration:
    • 15 ms, 30 ms, 60 ms, 120 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, and forever (wake up using other resources) through on chip 125 kHz Watchdog timer. Using sleeping forever duration, the Watchdog timer module is not in use and will further reduce the current consumption by approximately 4 µA.
  • Option to shutdown Analog to Digital Converter (ADC) module to further reduce current consumption.
  • Option to disable Brownout Detector (BOD) module to further reduce current consumption by approximately 17 µA. BOD module cannot be disabled through software in idle and ADC noise reduction mode. It can only be disabled through fuse setting in these 2 modes.
  • Option to shutdown Timer 2 module in idle, ADC noise reduction, power save,  and extended standby mode. Timer 2 is used by the core of Arduino for PWM operation.
  • Option to shutdown Timer 0, Timer 1, USART0, TWI, and SPI module in idle mode.

source:http://www.rocketscream.com/blog/2011/07/04/lightweight-low-power-arduino-library/

 

Here is an example of the power down mode in use. This code periodically puts the Arduino in the power down mode and wakes it up to do some activity:

#include “LowPower.h”

void loop()
{
// Enter power down state for 8 s with ADC and BOD module disabled
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);

// Example: Read sensor, data logging, data transmission.
}

The following is an example of the sleep mode with periodic wakeup:

#include “LowPower.h”

void loop()
{
// Enter idle state for 8 s with the rest of peripherals turned off
// Each microcontroller comes with different number of peripherals

// ATmega328P, ATmega168
LowPower.idle(SLEEP_8S, ADC_OFF, TIMER2_OFF, TIMER1_OFF, TIMER0_OFF,
SPI_OFF, USART0_OFF, TWI_OFF);

// Do something here
// Example: Read sensor, data logging, data transmission.
}

 

Weekly blog 10/2 – 10/7

Pine Mountain group: B

Project group: Power Management

Our team seeks to have a deep understanding of the control boards that we will be using and how it interacts with the sensor, the WiFi board and the battery in order to achieve the most reliable and consistent configuration for the Arduino/sensor system at the same time achieve the minimum power requirements. a number of software and hardware methods to minimize the current draw of the Arduino pro mini. We plan to tackle this goal on software level by optimizing the code using Lightweight Low Power Arduino Library (LLPAL) which supports the following power saving features:

  • Supports all sleeping mode of ATmega328P:
    • Idle.
    • ADC reduction mode.
    • Power save.
    • Power down.
    • Standby.
    • Extended standby.
  • Selectable sleep duration:
    • 15 ms, 30 ms, 60 ms, 120 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, and forever (wake up using other resources) through on chip 125 kHz Watchdog timer. Using sleeping forever duration, the Watchdog timer module is not in use and will further reduce the current consumption by approximately 4 µA.
  • Option to shutdown Analog to Digital Converter (ADC) module to further reduce current consumption.
  • Option to disable Brownout Detector (BOD) module to further reduce current consumption by approximately 17 µA. BOD module cannot be disabled through software in idle and ADC noise reduction mode. It can only be disabled through fuse setting in these 2 modes.
  • Option to shutdown Timer 2 module in idle, ADC noise reduction, power save,  and extended standby mode. Timer 2 is used by the core of Arduino for PWM operation.
  • Option to shutdown Timer 0, Timer 1, USART0, TWI, and SPI module in idle mode.

(Source: http://www.rocketscream.com/blog/2011/07/04/lightweight-low-power-arduino-library/)

 

Sample code on how to use the library:

1

The Arduino mini board that we have at our disposal operates at 3.3 volts and its current draw is around 23 micro ampere in Power Down State with Timer enabled (PDS) and around  5 mA in Active State.

Arduino has a number of peripherals:

  • Analog to Digital Converter (ADC)
  • Serial Peripheral Interface (SPI)
  • Timer 0,1,2
  • Two Wire Interface (I2C)
  • USART
  • Watchdog Timer (WDT)
  • and the Brown-out Detection (BOD)

To save power, the ATmega328P MCU supports a number of sleep modes and unused peripherals can be turned off. The sleep modes differ in what parts remain active, by the sleep duration and the time needed to wake-up (wake-up period). The sleep mode and active peripherals can be controlled with the AVR sleep and power libraries or, more concisely, with the excellent Low-Power library from Rocketscream that was mentioned and linked above.

LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF); puts the board in PDS mode. It disables the ADC and the BOD. Power-down sleep means that all chip functions are disabled till the next interrupt. Further, the external oscillator is stopped. Only level interrupts on INT1 and INT2, pin change interrupts,  TWI/I2C address match, or the WDT, if enabled, can wake the MCU up.

LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);, the WDT will be disabled and you would not wake up until an interrupt is triggered.

Another method is to remove the LED that consumes a relatively noticable amount of current. Removing this LED does not affect the functionality as long as we have other methods to check the status of the Arduino.

In the coming weeks our team plans on having a working prototype of the Arduino + sensor system on which we can test and build on.

 

 

 

 

 

 

 

 

 

Battery and WiFi

This post aim to argue that the Battery + WiFi combination is the simplest, most cost effective, and fastest to implement based on the information that we have received about PMSS. Of course both WiFi and Battery implementations have obvious limitations

  • Our system will be entirely dependent of the reliability of the WiFi coverage at the location. any interruptions in the school will result on complete shut down of our system.
  • with the current WiFi coverage at the school, many of the locations that we initially aimed to cover will be impossible to reach
  • It is not clear to me that WiFi + Battery in the most effective combination as far as the battery life in concerned. It seems like most WiFi powered devices are designed to run off a power supply (i.e access points, routers, switches) or have very short battery life. This solution will need demonstrably more involved maintenance and monitoring than solutions that use low power radio waves or cables.

 

On the other hand, using batteries eliminates the planning, manpower, and also safety issues that arise when considering having sensors powered by AC. Also there were concerns that were mentioned multiple times about the installation and the wiring on the walls of several buildings.

If we were to even consider any solution other than WiFi our approach in the first visit should have been a little different. For example I was expecting crucial and basic information like the size of the area that the school occupies, the perimeter, the distances between the buildings that we need to cover by our wireless solution, the layout of the buildings relative to each other, possible obstacles, and also a birds eye view of the location. I do not see how we could discuss other wireless or wired solutions other than WiFi which is already implemented without first knowing this information. So WiFi seems like a choice that let’s us focus a bit more on the software side of the project rather than worrying too much about the logistics.