The Story of PlanTsar

Inspiration

Having worked on a wireless sensors for agriculture in the past, I wanted to apply the same idea to indoor plants! This device is targeted for those people who love having plants around their house, but do not want the extra work that comes along with it in terms of monitoring it's health and watering it at the right time.

Demo Video

In the demo, this device logs soil moisture, relative humidity and temperature of a potted plant. All of this data is sent to the could via MQTT brokers and can be used to track the health of the plant. Additionally, the device can periodically water the plant via a water pump controlled by a relay. A simple web frontend created and hosted on IBM Bluemix is used to display data from the device and issue commands to the device. The device is also capable of OTAFU (over the air firmware update) and failsafe rollback to know working firmware versions using the external flash chip to store copies of the firmware image.

Waterbug is one device in a trio created by our group to perform local climate sensing and actuation. The other projects are:

Our Pitch Deck

Built with

The board schematic and layout design was done on Altium Designer 17. We got the PCBA done at pcb.ng, based in Brooklyn, NY. They were a very cost effective and fast option and easy to use! The brains of the board is the SAMW25 Wi-Fi chip that contains ATWINC1500B wi-fi chip and the ATSAMD21 Microcontroller. All the firmware was developed on Atmel Studio in C. The could part of the project was handled with a MQTT broker on couldmqtt.com and our fancy dashboard was created and hosted on IBM Bluemix. Bluemix was insanely easy to setup and use. The logic behind our dashboard was built with simple drag and drop blocks on Bluemix's node-red.

Components and Circuitry

Sensors

  • Sparkfun- soil moisture sensor – Voltage read by ADC
  • Texas Instruments- Humidity and Temperature sensor – I2C protocol
  • Silicon Labs – Ambient light sensor – I2C protocol

Actuation

  • Surface mount LEDs
  • Omron Electronics – Single pole single throw relay

Memory

  • Adesto Technologies – 8MB Flash memory- SPI protocol

MUC+ WiFi connectivity

  • Atmel SAMW25

Other things worth mentioning are the dual power capability, where the board can be powered via a micro USB cable or a lipo battery. Schottky diodes are used in power path management. A buck regulator is used to get a steady 3.3V output and a lipo charging IC is used to control the flow of current when charing the lipo battery via the USB cable.

Memory Partition

The SAMD21's non volatile memory is separated into the following different blocks. The bootloader is allocated 32kB and resides at the base of the memory location . It is always first run when the device is reset. A boot status flag at the end of the bootloader memory location is used to keep track of the current firmware version and whether an upgrade of the firmware is necessary and from which flash location. The main firmware or application code resides from in the remaining 224kB of the total 256kB flash memory. The external SPI flash chip is just divided into 3 blocks of 256kB each to store different version of the firmware. The golden image is our “safe mode” or a known good firmware that is used to fallback on when we have issues with OTAFU.

Bootloader Implementation

The bootloader works by first checking the current version of the fimware and checking if there is a firmware upgrade scheduled in the flags at the end of it's memory. If there is, then it chooses the right firmware from the external flash chip and write it over the app code section of the microcontroller's memory. The bootloader also takes care of broken / faulty firmwares by keeping track of the number of watchdog resets and reverting the firmware to the golden image after a certain number of watchdog resets.

Firmware and the cloud

When the board is under normal operation, it is connected to the WiFi and is regularly logging data from its sensors on a cloud MQTT server. The board also receives commands from the MQTT server that is issued from a user via the dashboard, hosted on IBM Bluemix. As added security, the dashboard can only be accessed by those who have the login credentials for the page. It is not publicly available to all!

Over the Air Firmware Upgrades

Firmware updates are initiated in the application when it receives the appropriate command from the MQTT server, which in turn is controlled by a button on the dashboard. Upon deciding to do a firmware upgrade, the MQTT over Wi-Fi stack is de-initialized and a regular HTTP stack for file download is initialized. The appropriate firmware file is downloaded from an open server and stored into the external SPI flash chip. While downloading, a CRC32 is calculated and checked against another downloaded file that contains only the CRC of the first file. Only if the CRCs match, the upgrade process proceeds and control is handed over to the bootloader for overwriting the current firmware.

Discussion

Hardware Development and Challenges:

Board bring-up initially seemed to be smooth and perfect, but later several issues emerged.

  1. The reset button on the board didn't work as expected, because of forgetting to account for an internal pullup on the line. It was tried to be fixed by changing the resistor values. However, I also realized that my mistake was wiring the button the WiFi chip reset pin and not the Atmel MUC's reset. I had to stick to power cycling my board to perform a reset.
  2. A battery level monitor circuit, that used a simple resistive divider and and opamp to determine battery level, messed up isolating power between the battery and my 3v3 power plane, but this did not cause any problems in the device operation.
  3. The above mentioned opamp's footprint was designed wrong. It is very easy to get confused with size on SC70 and SOT23 footprints.
  4. The most serious of all problems was the failure of the power regulator on my board after powering on the device post soldering the relay on it. The relay did not even need to be turned on for my power regulator to heat up badly. After much thinking, I realized that not having a pulldown on the relay enable line were signs of a bad design, since the relay's state would be ambiguous on startup and any type of flickering on the enable line would cause the relay to draw huge currents from the power line. This is fixed by adding a resistor and a bodge wire on the PCB that acted as a pull down for the relay enable line.

Software Development and Challenges:

Software development on Atmel studio was definitely more difficult than anticipated. Lots of pieces of software had to be brought together for this project to work.

  1. The HTTP file downloader proved to be a complex HTTP stack that was provided by Atmel's ASF and we only had control over callback functions of the stack. The file download came in random chunks of data over the WiFi and we had to create a circular buffer to store them temporarily and write only page aligned blocks of data into the external flash.
  2. The I2C communication protocol was a little tricky to be setup and required the right delays between packets to meet the specs of the peripherals and get correct data back.
  3. A precomputed MQTT library was difficult to work with. Subscribing to topics were hard to do and would frequently fail. We eventually discovered that it would only work properly at optimization level -O1.
Share this project:
×

Updates