On the 7th of April 2020 I wrote about the Website Generator of CumulusUtils. That appeared to be somewhat bigger than I expected, simply because it was about a full blown website with users interacting. And interaction generates comments. All has now stabilised and CumulusUtils works fine.
Meanwhile, on the background I had been working on a project to get going with air quality sensors like the PMS1003 ($14,20 at AliExpress) or similar cheap serial devices. In the back of my head always has been the creation of a multi sensor ‘sniffing’-centre to get a complete overview of the local airquality. Something worthwhile: I grew up in the neighbourhood of Rotterdam/Pernis an area known for its bad air and now I live south of Delfzijl, a small harbour in the North of the Netherlands with relative big industry area. 30 km North from there there are two large coal power plants and smog condition occur several times per year, though not often.
So I defined some design conditions for this sensor project, taking into account my experience with CumulusUtils and C#/Mono on the Raspberry Pi (3B+), the environment of CumulusMX (CMX). And certainly when it became clear that CumulusMX would start supporting the Davis AirLink device it became even more interesting. How to set it all up, make it worthwhile, maybe connect to CumulusMX and have my CumulusUtils have the display… An interesting environment was developing and after contact with @Scapeler – a citizen science project in the Netherlands – I decided on my design conditions:
- Platform would be a Raspberry PI ZeroW;
- I would try developing in C#;
- I would use a sensor from Plantower;
- For Temp/Hum I would use a Sensirion SHT3x family sensor;
- The final location of the ‘sniffing’-centre would be solar powered within range of my own local network.
The development platform
Soon after I had made the decision on the platform I discovered that reading GPIO on the RPi is not all that simple, especially not if the choice is for a multithreaded platform like C#/Mono where the time critical tasks need to be protected.
Libraries did exist and I studied about five of them. Most were too old, not maintained and had a very small user base. They were also pretty complex and always implied interfacing from C# to some C++ or C or even assembler runtime library. That in itself should not be a problem – though I don’t really have experience there – but the main issue I saw was that I had no control over the code, nor an example of how to act in case of problems.
In the end and after quite a long time I settled on the RaspberrySharp library by JTrotta. I find it accessible and clear. Code and examples are present.
However, there was one problem: I could not get the combination of Mono and RaspberrySharp to work on the ZeroW so after several retries I turned to a RPi 3B+ and installed the runtime for dotnet (the .NET Core 3.1 environment) and got it working in one go. That made the decision. Maybe I’ll get back to the Zero W once, but this brought me progress and quite some computing power. That power gives the possibility to do additional things on that machine. So the platform now is :
- .NET Core 3.1 on RPi 3B+ under Raspbian Buster
- RaspberrySharp (1.4.0) as mentioned above
- System.IO.Ports (4.7.0)
- C# in Visual Studio
In January 2020 I contacted Scapeler for some advice on what sensor to use and he came back with a Chinese site full of low cost sensors, with the Plantower family prominently present. To make a long story short: it was not really very important which sensor I took, I could always change later. Only one criterium was relevant: it had to be a serial interface. So I went for the PMS1003 ) which in the operational situation probably will be replaced by another PMSx003.
For the Temperature-Humidity sensor I was first inclined to simply use the data from my weather station but as thinking progressed it became clear that one actually needs the data from the direct vicinity of the particle sensor simply because the dependency of the resulting values of both temperature and humidity. I use the Sensirion SHT31. Although the specification of the sensor does not give a formula one could deduct the temperature dependency from the graphs given. The dependency of humidity is unclear which may be problematic in the open air situation.
The correction is prescribed in the USA but I can’t find the background to that correction and it only holds for the sensors (PMSx003) in the PurpleAir device. I hope to find additional info soon. This probably has to be a sensor specific correction.
The final outside location
I rented a small piece of ground from the community to pitch my weather station. The sensor station will be put aside the weather station and it will be powered by something like this (battery to be added). Everything probably mounted in a sort of Stevenson screen – if I can find one cheaply enough.
The hardware setup as shown in the photograph above served for development purposes very well. Soon I could read both sensors and had a rudimentary application. As I participate on the Cumulus forum because of my CumulusUtils application, I decided to publish this in the Homebuilt part. Within twelve hours somebody else posted on the Davis AirLink device which was to be made available end of September and CumulusMX appeared to be going to support it.
Thinking it over and seeing what was published in CMX 3.9.0, I had a short discussion by email with Mark Crossley. It appeared:
- The interface from CMX to AirLink was a JSON structure being handled over an HTTP interface.
- If the AirLink was defined as a local device, the only thing it needed was a name and an ip-address.
- CMX polled twice per minute to make sure it did not miss anything.
- Graphing the particle sensor data would be planned for version 3.9.1
So, there I was with a partial program which could read data from sensors and write it to a file, but I would still have to make the graphs, and incorporate it as a kind of alien body, into my CumulusUtils.That required some quick thinking.
I implemented a rudimentary web server which on any request would return the value of the required JSON structure. But the clever thing was to make the whole thing transparent. I created an AirLink emulator (working title: FakeAirLink) which created all averages and the required nowcast value the actual AirLink has. I made the whole thing configurable to facilitate easy addition of other sensors.
In no time I had a simple but good functioning application which runs under .NET Core 3.1 on the RPi (3B+ and up). All hardware included probably adds up to roughly € 100,- (excluding the solar power set) It integrates with CMX and CumulusUtils to have both data storage and easy display of the data.
Some time to go to finish it all, but the big task – idea how-to – of the software has been done.