Humidity and temperature monitoring with a Raspberry Pi

Continuing my quest to protect my Caterham 7 using my Raspberry Pi, I bought a bargain box of 37 assorted sensors for £21. One of the devices supplied was a DHT11, capable of monitoring temperature and humidity. A quick internet search led me to discover the very useful pigpio libraries and daemon. Wiring up the DHT11 to the Pi’s GPIO pins was simple – 3 wires, 1 to the 3V3 supply, 1 to a ground pin and the data pin of the device to GPIO pin 17. The author of the pigpio library also provides some example code for the sensor.

This was enough to demonstrate that I could get it to work, but the accuracy of the DHT11 was woeful. It’s advertised as having an accuracy of +/- 2 Celsius, but my experiments suggested that the one I had acquired for the princely sum of 57p had an accuracy of around +/- 5 Celsius. As I also wanted the sensor to work in an unheated garage, another limitation was that the DHT11 is unable to read values below freezing.

Encouraged, I decided to invest a further £6 in a plug compatible DHT22 sensor. This has an operating range of -40 Celsius to 125 Celsius, with an accuracy of +/- 0.5 degrees. Initial tests suggested that it was far more accurate than the DHT11. While the sensor produces a slightly different data stream to the DHT11, it was close enough for the example code to have been written in a way that it would still work.

As part of my experiments, I made a small modification to the example code (testDHT.c) to calculate the dew point from the temperature and relative humidity readings. I’ve also changed the way it outputs data, to write it to a file rather than the screen.

void cbf(DHTXXD_data_t r)
   FILE* fp;
   char buff[100];
   time_t now;
   float rdwpt,rtemp,rhum;
   extern float rdewpt_();
   if (r.status == 0) {
       now = time (0);
       strftime (buff, 100, "%Y%m%d-%H%M", localtime (&now));
       fp=fopen("readings.txt", "a");
       fprintf(fp,"%s ",buff);
       fprintf(fp,"%.1f ", rtemp);
       fprintf(fp,"%.1f ", rhum);
       fprintf(fp,"%.1f", rdwpt);

While it would have been simple enough to write a dew point calculation in C, I decided to write it in FORTRAN instead. Hey, the more people who get to love FORTRAN the better. Here’s the function I wrote, which uses the Magnus formula. It’s declared in the C fragment above as an external function that returns a float. Parameters are passed to FORTRAN by address, rather than by value.

C                               RELATIVE HUMIDITY - RHUM
C     AUTHOR: TJH 28-01-2017
      REAL RH
      RH = (LOG10(RHUM)-2)/0.4343+(17.62*RTEMP)/(243.12+RTEMP)
      RDEWPT = 243.12*RH/(17.62-RH)

Compiling and linking the C and FORTRAN code using gfortran:

gfortran -Wall -pthread -o DHTXXD *.c *.f -lpigpiod_if2

produces an executable that can create a data file. This example was created using the command:

./DHTXXD -g17 -i600

which reads the data from GPIO pin 17 every 10 minutes.

20170128-2009 6.9 72.0 2.2
20170128-2019 6.9 71.7 2.1
20170128-2029 6.8 71.3 2.0
20170128-2039 6.8 71.4 2.0
20170128-2049 6.8 71.7 2.0
20170128-2059 6.8 71.4 2.0
20170128-2109 6.7 71.1 1.8

This provides data in a suitable format to use some relative simple gnuplot commands to create a charts. The first example plots the relative humidity readings over time, with the larger spikes in the relative humidity data correlating to the garage door being opened while it was raining.

set xdata time
set xlabel "Time"
set ylabel "Relative Humidity %"
set timefmt '%Y%m%d-%H%M'
set format x '%H%M'
plot 'readings.txt' using 1:3 title 'Relative Humidity' with linespoints

HumidityThe second example graphs the air temperature reading directly from the DHT22 with the dew point temperature calculated from the Magnus formula.

set xdata time
set xlabel "Time"
set ylabel "Temperature in degrees Celsius"
set timefmt '%Y%m%d-%H%M'
set format x '%H%M'
plot 'readings.txt' using 1:2 title 'Air Temperature' with linespoints, \
     'readings.txt' using 1:4 title 'Dew Point' with linespoints

Air temperature and dew pointI’m going to be keeping an eye on the data, to understand if it might be beneficial to seal the garage door more effectively than at present and invest in a dehumidifier.

Benchmarking the Raspberry Pi 3

I was fortunate enough to be able to order a Raspberry Pi 3 on Monday morning from The Pi Hut. This was because I’d taken the day off work as holiday, because I’d been to see the brilliant Adam Hills in Birmingham the evening before. This meant that the email announcing the Pi 3’s arrival was just about the first thing I read that day – and I ordered it immediately. It arrived today, so as is my tradition, the first thing that I’ve done with it is to run the FORTRAN version of the Whetstone Double Precision benchmark, compiled using gfortran.

Before I get to the results, it’s worthwhile noting how simple the Pi 3 was to set up and attach to my wireless network. I still remember my experience with the original Pi some four years ago, where simply getting an operating system onto an SD card took quite a lot of effort, and persuading it to work over WiFi even more. I think I spent a couple of days getting it to work properly – possibly longer – and got to play around in configuration files that I’d forgotten all about in the 25 or so years that had passed since I used to hack Sun UNIX kernels for a living.

Now, four years on, the first startup process is stupidly easy. Along with the Pi 3 (£30) and a case (£13), I’d bought a micro SD card with Raspbian pre-loaded (£6). This automatically configured itself when I powered up the Pi 3 for the first time and once that had finished (around 10 minutes or so) immediately rebooted into the desktop environment. A simple right-click on the WiFi Networks icon on the task bar allowed me to select my network and enter its password.

Installing a FORTRAN compiler was simple – all I had to do was open a terminal window and type:

sudo apt-get install gfortran

I also installed a copy of scrot (for taking screenshots) and gimp, so that I could edit them. A pre-installed version of Libre Office meant that I’d also got a spreadsheet editor with no effort – and no additional cost. Both gimp and Libre Office Calc seem to run exceptionally well on the Pi 3. I did try gimp on the original Pi, but lost the will to live waiting for it to do anything. As for Libre Office, I wouldn’t have dreamt of trying it.

So, to the results. The graph below compares the same benchmark using identical source code on the original Pi B, the Pi 2, Pi Zero and Pi 3. Over 10 runs, it manages an average of just under 400 MIPS – and like the Pi 2, that’s on one of its four cores (as the benchmark isn’t threaded). So at a cost of £30, that works out an amazing 7.5 pence per MIP – or less than 2 pence per MIP if you’re running something that can utilise all four cores simultaneously. The Raspberry Pi Foundation say that the Pi 3 is 10x faster than the original – this benchmark result therefore more than supports their claim.

Whetstone Double Precision Benchmark

All I need to do now is to find something useful to do with it (I have a couple of Internet of Things projects I’m looking at), although if my Windows 10 desktop ever gives up the ghost I think I might be tempted to simply replace it with a Pi 3, attached to my network storage device. The whole of this article has been prepared using the Pi 3, using the pre-installed Epiphany web browser to access my self-hosted WordPress site.

Raspberry Pi 3 - Raspbian Desktop

If my Pi 3 continues to perform reliably, I’m not sure why I’d ever need to buy a traditional Windows desktop again.

Benchmarking the original Raspberry Pi Model B

Yesterday, I used the FORTRAN double precision Whetstone benchmark to assess the new Raspberry Pi 2. The results are rather impressive.

For the sake of completeness, I spent this morning dusting off my original RPi, installing the same operating system (Raspbian) and compiler (gfortran) to repeat the test.

Double Precision Whetstone Benchmark Results, RPi 1 Model B The result – an average of 150,962 KIPS over 10 runs of 100,000 loops, compared with 276,369 on a single core for the RPi 2. Which on this single, somewhat flawed (albeit interesting) benchmark, makes the RPi 2 around 1.8 times faster than my original model B, or 7.2 times faster across all four cores.


Benchmarking the Raspberry Pi 2

When I saw that the Raspberry Pi 2 had been launched earlier on this week, I immediately decided that I had to have one. My original Raspberry Pi had been slowly gathering dust on the study windowsill for a couple of years, largely because my initial enthusiasm for it had waned rather quickly. It was simply too slow and unresponsive for me to be able to do anything very interesting with it.

However, my experience so far with the RPi 2 is making me wonder why I bothered to buy a new PC towards the end of last year. For the princely sum of £29.93 (delivered) from CPC (plus an additional £16 for a 5V, 2.1A power supply – the 700mA phone charger that worked with my original model B simply wasn’t up to the job), it’s more than adequate for programming tasks.

The RPi 2 even runs a web browser sensibly, which is more than I ever really managed to achieve with my first RPi. (Geek note: this post was written on my RPi 2, using the Chromium browser).

But just how good is it? A number of people have been testing its performance by playing old computer games on emulators, but that seemed a little bit too subjective for my tastes.

So instead, I installed a FORTRAN compiler and dug out a copy of the double-precision Whetstone benchmarking program(+). An average of 10 runs over 100,000 loops each (on a single core of the quad-core ARM v7 processor of the RPi 2) gave me a result of 276,369 double Whetstone KIPS (thousands of instructions per second).

Double Precision Whetstone Benchmark Results, RPi 2

It’s only when you dig out the historical results for this benchmark(*) that you start to realise how astounding this performance figure is. For example, the VAX 11/750 that I used for the first time at Warwick University in 1982 delivered around 510 KIPS of performance and was typically shared by two dozen people at once. At particularly busy times you could wait for whole minutes simply for the text editor to start.

The Prime 9955 that was the mainstay of development work when I joined my first company, PAFEC, delivered 3,450 KIPS, according to its 1986 benchmark results. I still have my original contract of employment, which stated that staff who worked on “the computer” were encouraged to adopt some rather unusual working hours. The Silicon Graphics Indigo2, the workstation that everyone wanted to use in 1993 as it was a byword for high performance computing, clocked up a very respectable 90,000 KIPS.

It’s only when you get to the release of Pentium II based PCs in 1998 that you start to see similar performance figures to that of a single core of the RPi 2. And you need at least a Celeron M or Pentium IV based PC from 2003 or 2004 to match the performance across all four cores.

I suppose I really ought to knock the dust off my original RPi and see how it performs with the same code …

Update, 8th February 2015I’ve now repeated the benchmark on my original model B.

(+) The Whetstone benchmark seems particularly appropriate, as like the Raspberry Pi, it was created in the UK.

(*) I’m indebted to Roy Longbottom and his collection of benchmarks for the historical performance information referenced in this post. The documents covering the development of the Whetstone (and other benchmarks) he’s curated are a fascinating glimpse into one aspect of the history of computing over the last 60 years or so.


PAFEC – The DOGS 3.1 SCURS Comment Block

This comment block, from the SCURS subroutine of DOGS 3.1 should bring back memories for former colleagues. The copy I have in my possession runs to just over 14 pages and has my provisional edits (dated 24th October 1985) for DOGS on the Sun-2 workstation using a Bitpad 1 compatible tablet. Seeing the lines of code starting IF (ITYPE.EQ.111) GOTO 395 again certainly brings back memories.

The SCURS comment block from DOGS 3.1, October 1985.The aim of SCURS was simple, but because of the ever-growing number of different graphics terminals, workstations and input devices DOGS supported, it had started to become unwieldy and became almost indecipherable by the release of DOGS 3.2 in 1986. DOGS 4.1 replaced SCURS with a structured library known as PUGS (PAFEC Universal Graphics System) used by Tektronix, Westward, Sigma and other graphics terminals, with a variant called LIONS used on Sun, Apollo, HP and other 32-bit workstations.