The software to be put on each generation of the weatherbox. Meant to be a complete replacement of the previous Apple code with the added capability of implementing the same functionality onto the other generations.

Unified Software Team

Firmware Repository:

  • Communicate with weatherbox hardware teams to prepare device drivers for next versions of weatherboxes
  • Create detailed documentation and user manual
  • Increase sampling period to 1 minute
  • Reduce the power consumption
    • Implement a sleep function
  • GPS Integration

Future Firmware Ideas
Current Build Not Working Notes

  • Implement Snapdragon
  • Implement the Real-time Clock and GPS modules for Cranberry
  • Deploy weatherboxes
  • Assist other teams with software
  • Improve modularity of firmware code
  • Create new sensor drivers
  • Develop deployable versions of weatherbox firmware
  • Improve power efficiency of the weatherboxes

      Create and initialize board struct
      Set-up board
           Initialize all of the sensors
           Read Node ID from EEPROM
      Run a Power on Self-Test
           Sample each sensor
           Write sensor values to serial monitor
           Check for bad sensor values
      Heartbeat Packet
           Poll diagnostic data every three seconds for first thirty seconds
           Apply scaling factors to diagnostic data
           Construct heartbeat packet
           Transmit heartbeat packet every three seconds for first thirty seconds
           Write message to indicate successful transmission to serial monitor
      Data Packet
           Poll sensor and diagnostic data every thirty seconds
           Apply scaling factors to diagnostic and sensor data
           Construct data packet
           Transmit data packet every thirty seconds
           Write message to indicate successful transmission to serial monitor
      Command Mode
           Enter any character into the serial monitor to interrupt execution
           Enter “P” into serial monitor to run a Power on Self-Test
           Enter “E” to exit command mode and return to execution
  Initialization (setup()):
      Version check
      Initialization of corresponding functions and variables
      Initial health diagnostics
  Execution (loop()):
      Check weatherbox battery health
          if good health:
              Poll data from each sensor
              Data manipulation (scaling, etc.)
              Construct packet
              Transmit packet
              Clear packet buffer
          if poor health:
              Turn off sensors and XBee
              Update current battery voltage
              While the battery voltage remains bad:
                  Turn on XBee
                  Send health diagnostic packet
                  Turn off XBee
                  Wait approx 10 minutes
                  Check battery voltage
              Turn on Sensors and XBee

Q: Why use pre-made Arduino libraries for the sensors (and other hardware parts) instead of programming the I2C capabilities ourselves?

  • From recent experience, programming the I2C requires a solid understanding of the part on the I2C bus as well as I2C programming itself.
  • The pre-made libraries provides examples and the code to obtain data from the parts which shows the unique traits about the part.
  • Programming I2C relies heavily on understanding what is on the part's data sheet, while applying the pre-made libraries requires only a understanding of what each function in the library does (at minimum).
  • Pre-made libraries are open source and open to input from other sources to improve its overall functionality.


  • Tutorials - Provides helpful tutorials that cover setting up an Arduino sketch, using the serial monitor for debugging, and how to obtain input and assign output to pins.


  • Tutorials - Simple 25 step tutorial on to get those new to Git use to the common commands necessary to utilize and interface with GitHub.

Xbee Profiles:

  • Xbee Profiles - Link to download our Xbee Coordinator Profile and Router Profile.

Xbee Library:

  • Xbee Library GitHub - Location of the Xbee Library that provides users with the ability to utilize the functions of Xbee with Arduino.
  • Note: This library differs from the library the current Apple Code (10/23/2015) uses.

Xbee API Mode:

  • Xbee API Mode - Details the differences between Xbee's two supported modes of operation (AT and API). Details the benefits of using API Mode.

I2C Programming:

  • I2C Tutorial - Basic tutorial on using I2C bus with Arduino. It helps obtain data from the sensors for Cranberry and Dragonfruit.
  • I2C Discussion - Discussion on interfacing with multiple components attached to the SDA line.

Function Pointers:

  • Function Pointers - Goes over the basis of function pointers
  • Our code focuses on declaration and assignment
  • Function pointers are used to reduce the use of wrappers (large blocks of conditional compilation, #ifdef & #endif)
  • Two main categories of function pointers used:
    1. Sensor functions
      • Used to assign the appropriate generation-specific sensor function to the generation being run
    2. Transmission method functions
      • Used to assign the type of transmission method desired
      • Affects:
        • Packet clearing/initializing
        • Packet construction
        • Packet Transmission
      • Also affects what routine is run (at Full Integration level)
  • Function pointers MUST:
    1. Be declared the same type as the functions it can “point” to
    2. Be given the same amount and type of arguments as the functions it can “point” to

Apple Code:

  • Apple Code - Apple Code to be used as a reference for further updates to the new firmware.

Moving Average:

Git/GitHub Branch Name Changes:

  • Branch Name Change - Three commands to manage changing the name of your local branch and pushing the name change to the repo on GitHub.

Git/GitHub Tagging:

Tag Naming Conventions:

  • Semantic Versioning - Our tag conventions are based off of this idea, but not followed.
  • vX.Y.Z
    • X = Major updates to functionality of code
    • Y = Changes to code that doesn't affect overall functionality or logic
    • Z = Minor changes to patch errors or fix portions of the functions

Error Code Naming Conventions:

  • Error codes shall be a negative 3 digit number
  • Error ABC
    • A = Module
    • B = Function
    • C = Specific error

Unit Testing Practices:

  • Unit Testing - Guidelines to follow to create meaningful and useful Unit tests

Spring 2019

Fall 2018

Spring 2018

Spring 2016

Fall 2015


Contributing authors:

akim aleong aobatake cobatake dtokita jtu klin kliu kluong rli rwalser scottbn

Created by cobatake on 2015/12/02 03:01.