It has been quite some time since our last entry, but things sure have not been standing still. We have now a functioning prototype, which our supervisor currently is showcasing in Ethiopia at different coldroom facilities. As of now the system consist of a sensor node, which collects data and forwards it to a internet connected raspberryPi. The Pi pushes the data to a online database, utilizing the OpenEnergiMonitor system (emoncms). In this setup we have also added a graphic interface for the sensor node, delivering different variables handy for reading the cooler’s status.
The final setup is still not determined, but we wanted to show as many possibilities of features that can be implemented. It is also possible that some facilities will not need the split setup with a sensor node and a raspberry, they might just need the sensors connected directly to the raspberry, if they only have one cooler. To reveal the idea behind the system we have designed every component, part and software bit of the system to fit into a modularised design mentality. The diagram below shows how these modules is set up the working prototype in Ethiopia – The SMS function [Module 3 – Alternative] is still on its way.
beneath we see our first prototype of the sensor part of the system (sensor node), the box contains: A JeeNode, a glcd (link), a piezo element (for alarm demonstrating purposes) and the entire thing is powered by 6 AAA-batteries. The temperature sensors are within the RJ11-extenders and are connected with RJ11 phone-cables. (Note: the phone cables are not crossed, this makes assembly next to impossible to do wrong)
The screen on the node delivers 4 variables: The current average of the connected sensors, the highest and lowest temperature recorded since startup/last reset and the times since last reset. The icon in the top right corner shows coldroom status, the logic behind it is still not implemented, but the thought is that it will indicate if the temperatures is below or above the acceptable range and if there have been recorded freezing temperatures. Other system failures may also be implemented for example a accumulated time for which the temperatures have been out of the appropriate range. This has some clear problems that has to be accounted for because the vaccines are constantly being renewed, so the accumulated time will varie from when they were stored in the cooler.
For demonstrating purposes we added a alarm mode, the alarm could be simulated by not connecting all 4 sensors. This made the node turn on the red LED on the front and to play a node with the piezo element everytime a “faulty” reading was made.
Above we see the casing we made for the RaspberryPi, it is clear that we underestimated the combined size of everything when assembled. Therefore we have a lot of cables sticking out and then re entering the box again, this is of course a problem we will have to approve for the next prototype.
As shown on the graphical module layout above more and more components are added to the system. This is causing accidents being difficult find and solve to why we need to keep designing a system which in term of a fault will not cause a breakdown of the entire system. This is a challenging part and hard to describe in a blog post, why we urge you readers to comment and ask questions while we keep on blogging.
Emil & Adam