Skip to main content

Tranche 3 Report

Introduction

At the end of second tranche, we were able to collect and visualize the data from one site. Tranche III work had two major goals. First was to ensure that we can scale the setup at three real world locations after having learned our lessons from the first deployment. The second goal was to improve the software and provide a linkage from data to predictions on the basis of prevailing climate. That involved developing a software that can codify existing disease prediction models. To that end, downney mildew in grapes and late blight in potato disease forecast models were developed.

Goals

  1. Prepare sensing devices for real world deployment in 2 more places. Incorporate feedback from IIHR deployment.
  2. Cloud software for disease analyis and advisories.
  3. Demonstratio of 3 real world deployments with 24x7 continuous monitoring using sensors and data in public domain

Development

The focus work done under the of grant was wireless sensor networks the provide a better alternative to current data acquisition systems in agriculture. To that end we developed low power off-grid monitoring infrastructure for agriculture. We did the deployments in real world conditions. The wireless sensors are low power optimized and suitable for creating ad-hoc networks for wide area agriculture use cases. The architecture is modular to support multiple sensors for continuous monitoring of critical agri input variables. With that we solved the data availablity problem. Next, We wanted to work on

A digital system that can capture the climate data accurately and translate it to concrete action items for daily operations will save resources like water, maintain soil health and improve crop yield and quality.

The meet the goal of 3 demonstration sites operating in public domain, we worked on the ankiDB™ cloud software to add

Cloud software

  1. API design for ankiDB cloud software
  2. API key based device access
  3. Visualization page for public device data and reports
  4. data synchronization facilites
  5. message facilities for a subscriber base

The choice was to base the work on one of the existing IoT cloud providers or develop our own. We decided to develop our own cloud stack to ensure

  • License free operation
  • IP ownership
  • Tighter integration with our use case

Like, with everything else in engineering, this decision also has tradeoffs. On one hand the argument can be that it is not a good decision to spend time on what has already been developed and avoid the NIH syndrome. On the other hand, our use case demands tigther integration with firmware and software and we view that as an essential ingredient for good solution delivery. Generalized systems always have processing over heads and ties us to a vendor platform. The essential features are data delivery and computations and no vendor provides them out of the box.

Deployment