I was inspired by the growing need to help farmers better plan and allocate their resources and provide effective and actionable information about all things weather around local spots on their farm. Use the weather sense node, a farmer can manage and care for their crops better by getting real time data about humidity, temperature and ambient light. This is particularly useful for vertical farms that grow food in an indoor setting with a tightly controlled climate that requires effective and efficient feedback. Vertical farms are important because they can provide fresh food without the need to waste resources on transportation and storage in order to cater to urban populations in metropolitan areas with a quick turnaround time. Imagine walking into a grocery store that grows its food right above ?!

What it does

It collects weather related data such as humidity, ambient light and temperature about the local environment and relays all the information to a remote server. The remote server serves a webpage dashboard allowing access to the collected data. The user can also send commands to the node to turn on an actuator such as a relay or a servo to open a valve.


Relative humidity, temperature and ambient light.

How I built it

I designed the the PCBA using Altium, bought the parts on DigiKey, had the board fabricated at PCB:NG in brooklyn, NYC and wrote all the firmware in C using Atmel studio and the supplied APIs. The processor is an integrated module called the ATSAMW25 by Atmel that incorporates bluetooth and wifi along with a PCB antenna. The web platform was prototyped using node-red and deployed using IBM's bluemix hosting service. The messages were sent using MQTT with the broker hosted on a cloud MQTT instance.

Cloud Connection

The data was sent using MQTT & TCP/IP over WiFi to an MQTT broker. The MQTT broker then forwarded the data to a web app that was built using node-red and hosted on IBM Bluemix. All sensor data was sent to the cloud. All actuator states were received from the cloud. All diagnostics like heart-beats with a timestamp and sensor health were also sent to the cloud.


Every-time the device starts up from either a reset state or from a power cycle, the bootloader ensures the integrity of the firmware and also ensures that the firmware that has been downloaded is valid by using a crc checker. The bootloader is also responsible for upgrading the executing firmware by programming the on-chip flash with the firmware that was downloaded into the SPI flash. The device and be forced into boot mode by resetting the device while holding down the user button. This will lock the bootloader into boot mode. The bootloader check to see if the firmware write flag has been set and then decides to upgrade the firmware. It also logs the number of resets that have occurred due to a watch dog reset and if this crosses a set threshold, then the bootloader reverts to a golden image at the root of flash.

Memory Partition

See the last image in the carousel


Having had prior experience with firmware development, I was able to architect the firmware well and foresee issues. I did not run into too many issues. The only issue that I debugged for a while was specific to how Atmel's peripherals are designed. If a peripheral has been configured, it cant be reconfigured unless it is reset. This was an issue since the bootloader was using the USART and the app code also uses it. When setting up the USART in the startup code of the App, the code was stalled and hung up on waiting for the USART to not be busy when it wasn't at all. The best way to deal with this was to not setup any peripherals unless they had to be setup because the firmware had to be upgraded or a lock-in-boot was requested.

The firmware downloads are unsecure and that is one of the things that should have been addressed. If I had more time, I would have implemented secure over the air firmware upgrades using TLS/HTTPS and encrypting the firmware binary by using elliptic curve cryptography. I would also implement a fixed point math based low pass filter for more accuracy rather than a 10 point averaging filter.

Challenges I ran into

The biggest challenges for me were on the hardware side. Having had prior experience with software, hardware seemed to be more of a challenge for me. This was good. It helped me understand a lot more about PCB design and manufacturing. I connected the wi-fi trace to the reset circuit which caused issues with the atmel chip not being reset since the decoupling cap was being driven high.

The other issue was with the reset button. I used a large resistor to ground from the de-coupling cap that led to a 1.2v voltage across it. This was not low enough for the ATMEL chip to be reset.

The LiPo charging IC has a low power state which it enters when the battery is absent. In order to supply enough current in the absence of a battery, power path management must be done to supply the necessary amount of current. I did not do this and as a result, my board cannot run directly off the USB supply unless a battery is present.

Accomplishments that I'm proud of

The board had some challenges with resetting the CPU and running off USB supply without the presence of a battery (see above). By doing minimal amounts of re-work, these challenges were resolved.

I am proud of the board design which in my opinion turned out better than expected. I didn't think that I was going to be able to bring up the board and get it fully working. I am also proud of the software architecture for downloading the firmware, the CRC and MQTT working in conjunction with HTTP downloading functionality for over the air firmware upgrades.

What I learned

Building an IoT product is hard. There are many challenges along the way that can be averted by doing a thorough upfront feasibility study and first spec. I learnt that if the functionality and the product is well designed using system modeling language constructs like block diagrams, flowcharts, and pin mapping tables, it is very easy to avoid a lot of mistakes and accelerate time to completion. Having a methodical and logical approach is very important.

What's next for Weather Sense

I will continue to work on this project and further develop it into something more plausible by adding in a few more sensors and actuators so that it can be a standalone weather node that is capable of turning on a valve for water inlet and/or a nutrient mixture to increase the soil electrolyte content.

Built With

Share this project: