This post follows on quite quickly (for me at least!) from my last one regarding my latest tests and reflections on environmental issues with some thoughts about how to measure ground temperatures in a reliable way. I am also going to take a look at the difficulties I might face in trying to automatically interpret cloud cover the whole year through. Finally I am going to share some thoughts on how I might approach packaging the system for deployment in the open air, and what to do about supplying power and communications.
If there is one thing this project is providing, it is many hours of thought about temperature; both in terms of obtaining measurements that are as accurate as I can make them, and understanding the data that this system will eventually provide.
Initially I started taking ground temperature from the ambient reading given by the MLX90614 sensors. This was just as a matter of quick prototyping to get circuitry outside and gathering test data. It worked well until I packaged the circuit into a plastic box exposed to solar radiation; albeit the lid of the box had two generous squares cut out so that the sensors had access to the sky. Over a few days of data gathering I noticed that the ambient readings being provided by the two MLX90614 variants were consistently higher than the local ground temperature from my weather station and, more importantly, differed from each other by a few degrees Celsius.
It quickly became clear that it was time to find an external way of providing a baseline ground temperature.
A graph comparing ambient measurements taken by the MLX90614 sensors versus a DS18B20
I decided to get a DS18B20 1-wire digital temperature sensor on the scene to in order to provide a baseline from which to see how the two MLX90614 were performing in comparison. The results can be seen in the graph above. It is apparent that indeed sitting a sensor in an small box will not give a very reliable ground temperature reading. In any amount of sunshine the heat inside the box builds very quickly indeed. It is noticeable that the BCF variant gives a reading that is slightly closer to the DS18B20 than the BCC variant. I think that this is probably due to the larger size of the BCF and that it is therefore poking through the cut out in the box lid.
The DS18B20 may not be the only answer: there may be an option to try out pointing a MLX90614 down at the ground; this is, however, something I may have to try at a later date when I get closer to assembling a mark 2 prototype.
Long term I think that measuring ground temperature using an external means such as this will be the only answer to getting accurate measurements down the line. I will be casting my eye over the Met Office surface observations fact sheet in the near future to get more of an idea where I should concentrating my ground temperature measurement efforts.
Part of the enjoyment of this project so far has been trying to understand the seasonal variations in temperature of both the sky and the ground. Over years of observing the weather I like to think that, as far as ground temperature goes, I have a pretty good understanding, as would anyone given enough time. However, sky temperature is not something most people take an interest in so it is not surprising that there is little data out there on the subject.
Any excuse to get a cloud photograph in...
In the months so far since I started sampling the sky temperature (which is not quite a year yet), I have seen that a lovely clear blue sky is pretty much at the same temperature on a winters' day as it is at the height of summer; both round about -38°C when measured with my IR thermometer.
Overcast skies tend to differ more between the winter and summer months with those in winter tending to be quite a few degrees colder. This is usually because the cloud base is at or near the same temperature as the ground temperature in the respective season. So a typical summer cloud base temperature might find itself at 12°C; a winter cloud base temperature at -2°C.
In essence the temperature gap between clear skies and cloudy skies is not a straightforward relationship. It depends very much on season and local variation.
Let us look at a simple example:
|Season||Cloud||Sky °C||Ground °C||Gap °C|
As of yet I have not firmly planned how I am going to graph the data; I am just aware that having data and making sense of it are two totally different things. It is likely that, at least initially, I will look to just graphing the ground and sky temperatures side by side and leave the interpretation to some manual comparison. Below is an example of such a graph.
Showing both sky and ground temp together; both sensor variants
Ultimately I would love to end up with some sort of heat map with a quarter hour resolution over a 24 hour period. Perhaps this is just mission creep though; the initial idea was just to observe clouds in the night sky. Be that as it may, the ability to do something like this will depend on understanding the temperature limits in the system. All food for thought in the future of this project.
Running a prototype on the bench is nice and simple. There are no concerns with the environmental conditions, other than that your shed is warm, and that there is a cup of tea to hand. Also, there is no concern to the issues with power or communicating with the Arduino; it is all at the end of a USB lead. Of course, this all changes the minute we shift the whole kit outside.
When thinking about what type of materials to consider packaging this system in there is only one really sensible answer: plastic. This is because plastic is readily available, easy to work with (in terms of shaping, cutting and bonding), comes in many easy to use shapes and it is relatively cheap. Falling back on experience gained from the soil temperature project I will again look to plastic plumbing supplies for the raw packaging materials. I am also planning to investigate some exterior electrical enclosures, such as weather resistant junction boxes, as a ready made alternative.
I had originally considered using serial communications but this presented a number of problems, such as what happens as soon as I have more than one Arduino based device collecting data; I am then into the realms of serial networks and so on.
Briefly, I considered using radio of some sort such as Sparkfun's 915MHz wireless transceiver, but then power supply would still be an issue. So my thinking went back to some sort of wired communications. I then came across the marvellous ENC28J60 module which opened up the possibility of using communications over IP - something I am already quite happy with using. The ENC28J60 itself is a fairly self contained 10BASE-T Ethernet controller with a whole host of features including an SPI interface. Here is a data sheet if you are interested.
I won't go into describing how to get an Arduino and ENC28J60 module as there are plenty of articles on the net on how to get started. I will, however, recommend using the UIPEthernet library written by Norbert Truchsess. In my opinion it is by far the best library of the small selection available. It has proven to be very reliable when left running for extended periods, unlike other libraries which have crashed after a few hours.
Once the decision was taken to use wired communications in the form of Ethernet it was but a small light bulb moment to realise that Ethernet does not use all the twisted pairs in a cable; commonly only two of the four available. therefore it seemed to me a no-brainer to use a couple of the spares as a supply and a ground. Being that I am passing DC at a relatively low voltage, I do not anticipate any issues with interference with the network signal.
I think that I am closer to coming to a conclusion with the physical build of the project than I am with the interpretation of the data once that starts to flow forth. For now I am just going to concentrate on getting the project built; once I am gathering data the fun is really going to start!