I’ve long wanted to inject more live into my web presence and this blog in particular. It’s work in progress – one of my main sites is currently not even live! Wherever we may end up though, informal writing about science and the changing northern environment is something I want to do more of. So I’ve made two changes to give this site more oomph:
I’ve added a custom domain, borealperspectives.org, to this (currently) WordPress-hosted site. All URLs will work fine, whether you access them via borealperspetives.wordpress.com and the new borealperspectives.org. This is, unless and until I may decide in the future to move the site off WordPress.com, but that’s not in the stars right now.
I’ve moved to the smallest paid account to remove ads from the site. Only when I happened to access it from a browser that was not logged into WordPress.com did I see how intrusive the ads would be. It’s not much money, and I hope will make for more comfortable reading.
After an incredibly warm (and low-snow) start of winter in 2018, temperatures plunged to proper sub-Arctic winter values. A few days ago, we were worrying about thawing (with temperatures in the 30s °F / around 0 °C), and then down the curve went. Last night we reached -40 (choose your unit: the scales meet at -40) as per our consumer-grade Davis weather station. That’s the official definition of “cold snap”, and it’s the first of the season.
Higher elevations, such as Cleary Summit, a mountain pass on the Steese Highway north of Fairbanks, are currently about 30 °F/17 °C warmer than the valley bottoms. Where we happen to live (and which is why “a house in the hills” is something we keep looking out for).
Life as -40 slows down. You can go out just fine, and you’ll be amazed by how well sled dogs are adapted to this extremely harsh weather, but it’s not really fun to exercise outside, plastic is brittle, batteries go flat … and you don’t have time for recreation because you need to keep an eye on the house systems. Especially to make sure that water stays liquid, be it in drains or incoming pipes.
The house we live in is made from three-sided logs, which retain heat quite well. We mostly heat with a very efficient and Toyo oil stove. But we have a wood stove to fall back on, in case the electricity or the Toyo have an outage. We decided to fire it up today, to make sure it works well and because it creates a nicer warmth in the corners too far from the Toyo. Wood burning is a huge and complicated political hot potato in interior Alaska, and a topic too complicated to go into in this post. The short version is: it’s traditional, economical and doesn’t require electricity; but it also contributes to air pollution in a way to occasionally render the winter air in Fairbanks one of the worst in the planet, so at a minimum eliminating the most polluting types of burners is quite imperative for the health of the population.
Our stove is an EPA-certified Blaze King with a catalytic converter, but even so: however pleasant wood heat is, you’ll get an impact on the air you breathe. Air quality indices only talk about outdoors air (and usually averaged over 24h). Another topic, though, is indoors air. I took the opportunity to pull out a little PM2.5 sensor that I bought online a while ago. (Disclaimer: I haven’t checked the calibration. At least during the summer wildfires it seemed to work reasonably well and deliver believable values.) Today, before starting the wood stove and with a blazing oil stove, it measured around 15 µg/m3, which is an ok value. With the wood stove, it was at 66 µg/m3 after an hour, went up to just above 100 µg/m3 and then settled in the 80s, which you will find labeled as “unhealthy for vulnerable populations”. My setup is here, with the sensor in the left foreground. It talks to the computer via a USB-to-serial interface. (I wrote the app to teach myself Dash for interactive real-time applications.)
This, of course, is measured indoors, not outdoors, and in the 24h average we will quite likely end up in the “moderate” range for the day. We’re fine.
On a related note, no one should retain too rosy a picture of the air pre-historic and pre-industrial populations used to breathe. Notwithstanding, of course, their insights about the relationship to nature: if a culture or people practices indoors wood or coal burning for cooking and warmth, chances are that respiratory illnesses were prevalent.
Addendum: Approximately 5-6 h after we first started the wood stove, the picture has changed a little bit. PM2.5 values came progressively down to 15-25 µg/m3, pretty much to where they were before we started. Clearly, the first fire-up phase is what generates the most pollution, while collected crud from inside and outside the stove burned off. In contrast, low-to-medium hot, steady operation deteriorates the air much less. Also, I believe it takes a few hours for the catalytic converter to reach its operating temperature. Apparently, letting the stove cool down completely and sit cold for extended periods is a recipe for air pollution. The lesson from this is: If you want to heat with firewood, make sure you have a device with a certified catalytic converter, use it continuously and burn dry, well-seasoned wood.
I called it a shootout first, but hey, it wasn’t anything violent.
Sensing temperature with Python and the pyboard
Because I have the best spouse in the world, my recent birthday brought me a whole pile of little boxes with electronic tinker toys, useful ones, straight from Hackerboxes. I’ve since been renewing my acquaintance with the soldering iron and dusted off an old project about building environmental sensor units.
One of the development boards I was keen to try out is the pyboard, which is the original or official board for MicroPython. MicroPython is a new implementation of a remarkably rich subset of Python 3.4 to run on microprocessors. I already had a good deal of experience with CircuitPython, the education-friendly derivative of MicroPython published and maintained by Adafruit. Now it was time for the real thing.
The pyboard is very compact. For comparison, the grid on my work surface are 1×1 cm.
So the plan I came up with is: Gather the temperature sensors from my kit, hook them all up to the pyboard at the same time, log the temperature for a while and compare the outcome.
The sensors
After rummaging through my component boxes, I fished out these three sensors (pictures below):
The TMP36 is a popular low-cost silicon band gap temperature sensor. It is small, with three output pins, and comes in a black plastic housing. T range: -40-150 °C, T accuracy ±2 °C. Price: $ 1.50
The DHT11 is a very common temperature and relative humidity sensor with not the best reputation for accuracy. It comes in a blue housing with electronic components included, and our version (from a Hackerbox) is mounted onto a small board, which adds a pull-up resistor and a power LED. The DHT11 documentation is a little spotty. The sensor apparently uses a negative temperature coefficient (NTC) thermistor (ie, temperature goes up → resistance goes down) and some kind of resistive humidity measurement. The sensor can only take T measurements every 2 sec. T range: 0-50 °C, T accuracy ±2 °C, RH accuracy ± 5%. Price: $ 5
The most expensive item in this set, the Sensiron SHT31-D, uses a CMOS chip to measure temperature and relative humidity, with a capacitive method. I used the lovely little Adafruit breakout board. T range: -40-125 °C, T accuracy ±0.3 °C (between 0 and 60 °C) and up to ±1.3 °C at the edges, RH accuracy ± 2%. Price: $ 14.
The prices are 2018 prices from US vendors. By ordering directly from Chinese outlets, you can usually reduce them to ~40%, except for the much rarer SHT31-D, for which only one ready-to-use alternative (which is not much cheaper) appears to exist.
The three temperature sensors: TMP36 (left), DHT11 (middle), SHT31-D (right).The whole setup.
Two related consideration at this stage: What communication protocol do the sensors use, and what MicroPython libraries are available to drive them from the pyboard?
While the documentation for MicroPython is superb, I found the pyboard to be a lot less well documented. MicroPython comes with a library specific to the pyboard (pyb) as well as generic libraries that are supposed to work with any supported board (eg. machine), and their functions sometimes overlap. I had to consult the MicroPython forum a few times to figure out the best approach.
The TMP36 is a single-channel analog sensor: The output voltage is linear in the temperature (it boasts a linearity of better than 0.5%). So we need a DAC pin to measure the output voltage at the pyboard (using a DAC object from the pyb module). According to a forum post, the pin output is a 12-bit integer (0-4095) that is proportional to the voltage (0-3.3V). So we get the voltage in mV by multiplying the pin value by 3300 and dividing by 4095. Then, as per the TMP36 datasheet, we have to subtract 500 and divide by 10 to convert that value to °C. Easy.
The DHT11 also uses single channel protocol, but a digital one, which looks a little idiosyncratic. (I was a little surprised to find that none of my sensors uses the popular 1-Wire bus.) Luckily, MicroPython ships with a library (dht) that takes care of everything. It outputs temperature in °C and relative humidity in %.
I was particularly happy how easy it is to scan the I2C bus for the device port with MicroPython. From the MicroPython REPL (which you enter to as soon as you connect to a new pyboard via a terminal emulator like screen), it’s great to be able to create and probe objects interactively, for example like so:
This said, the sht31 library doesn’t even need the user to provide the port. I’m just noting this because this task can be a little frustrating on the Arduino platform, and take more tries to get it done.
Our basic workflow was this:
Using the MicroPython REPL, develop the MicroPython code incrementally. The goal is to take a measurement every 10 sec and send the data back to the computer over the USB serial port.
I let the experiment run for a few overnight hours in my somewhat overheated home office corner, where the air is very dry.
The measurement results
Even while monitoring the data flow, some observations stand out: The DHT11 only provides temperatures in whole degrees. And the temperature measured with the TMP36 is a good bit (about 2-3 °C) higher than the output from the other two sensors. The data looks somewhat like this:
Let’s look at plots of the three temperature curves. At first, I was not impressed: The DHT11 measurements seemed to jump around a whole lot, the SHT31 has a very weird periodic signal and the TMP36 data is incredibly noisy (apart from unrealistically high – the room wasn’t that badly overheated!).
But things become clearer once we plot onto a single figure: The upticks of the DHT11 measurement correspond exactly to the peaks of the SHT31 data, and so do the minima! Also, the two sensors agree, within their precision, quite well in absolute value. Once I took the SHT31 signal seriously, I realized what it was due to: The thermostat cycle of our Toyo oil stove! I had no idea that it was on this 30 min cycle. How interesting. And now that I know, I really like the SHT31. (Apparently you get what you pay for in this case.)
What about the TMP36? Well, it’s noisy and operating way outside its nominal accuracy, but at least some of the signal is clearly due to the real temperature variation.
The fall-off of the data during the first hour is, btw, probably because I removed my body from the desk and went to bed. The air cooled afterwards.
Since I had the relative humidity data, I looked at it, too. Here the SHT31 and the DHT11 agree less well in absolute value, and I think the latter is in agreement with its reputation as not very accurate. I find the SHT31 values a lot more convincing. One thing that the graphs don’t show is that if you blow on the sensor, the SHT31 adjusts immediately and goes back to normal pretty fast, while the DHT11 takes a few seconds for its measurement to jump. It also saturates quickly (showing unrealistic nearly-100% of RH) and takes a long time to return from an extreme measurement.
What did we learn? What else could we find out?
So this was interesting! I didn’t expect to get so clear a feeling for the different sensors’ strengths and weaknesses. At the same time, I’m have more questions…
The DHT11 confirmed its reputation as a very basic sensor. Its temperature measurement was in better agreement with what I think is reality than expected, but the relative humidity is not very trustworthy. Its limited range and whole-degree step size make it a mediocre choice for a personal weather station, and its slowness unsuitable for, say, monitoring temperature sensitive circuitry. But could we get a higher resolution with a different software library? Are there settings that escaped my notice? As-is, I see its application mostly in education and maybe indoors monitoring when you don’t need much precision.
The TMP36 was disappointing, but maybe my expectations of this $ 1.50 sensor were excessively high. As an analog sensor, it is faster than the DHT11 (though I don’t know how fast … just yet) and can be used for monitoring temperature extremes, but not with high precision because of the noise! Maybe a good approach would be to reduce the noise in some fashion. Also, did I have a bum unit, or do they all need calibrating? Maybe the pyboard-specific conversion formula has a flaw, and a different board or method would produce a different result?
The SHT31-D looks like a great sensor all around. Also congratulations to Adafruit for producing an outstanding breakout board. This would be my choice for a weather station, hands down.
Other questions I have are: How different would the performance be in a different temperature range? I live in Alaska, and temps went down to -30 °C today. (My medium-term plan is to put a sensor under the snow.) Also, how fast can we actually retrieve successive measurements from our two faster sensors? Last, I think I found at least two more temperature sensors in my kit. How do they compare?
Some time during the last year or two there has been a change in my attitude towards serial connections: I used to think of them as a relic of a bygone time, when personal computers came with RS232/DE-9 interfaces and you could find them on all sorts of peripherals. A relic used by scientists and instrument makers for reasons, probably, of expedience. And if your instrument comes with a serial connector, you sigh, go look for a serial-to-USB converter and hope that it’s not one with an unmaintained and buggy driver that for all time will make you doubt in your data.
It is true that my deep negativity stemmed from the time I was receiving GPS signals in an airplane and worried a lot about USB buffer lag impacting the time stamps. I still think my worries were founded in this particular application. It is also true that for full-blown precision instruments providing an ethernet interface (or maybe something else?) out oft he box would be highly preferable to the unholy rat’s nest of serial hubs, USB converters and ethernet hubs (not to mention proprietary software to run them) that you find in too many scientific installations.
But since I’ve been playing with electronics and development boards, dealing with UART feels completely normal and appropriate. I own a bunch of converters (USB-to-UART, USB-to-DE-9) with FTDI chips, which work very well. And while it’s true that I’m far from understanding everything about serial communications, and am still leery of the reliability of timings below the ms level, it’s a lot more convenient and manageable than other options.
It’s already been two months, and I still haven’t posted about going to PyCon in Montreal. I had a wonderful experience! Many thanks to the PSF and PyLadies, whose travel grant brought the cost down into the realm of the feasible for me.
PyCon is an extremely well-run conference, run by a community that emphasizes a welcoming attitude. There’s a visible science presence (much more general than the topics you’d see at SciPy, of course), and an impressive 30% of speakers were women. I came away from it with many new ideas, got to talk with countless Python people, met many members of the geospatial community, including Sean Gillies, the author of such useful libraries as Shapely, Fiona and Rasterio, who turned out to be lovely. Also, two very nice gentlemen from the National Snow and Ice Datacenter (my pleasure!), serendipitously, as I used some NSIDC data in my presentation. Right, I gave a talk (on using satellite data to make maps, understandable without a remote sensing background), which was well received. I’ve embedded it below, and you can get the slides on speakerdeck here :
I’ve learnt tons by watching talks from past PyCons. It’s one of the best pass-times to do in the evening. So I thought I’d put together a quick “PyCon highlights for the pythonic scientist”, with links to the relevant videos. A few notes of caution:
These are not my best-of PyCon talks. Some talks that were excellent I left aside in favour of some that have a clearer utility for someone working in scientific research.
Most of these are 30 min talks. Some are 45 min. The ones that are marked as “3h” were tutorials, and may be somewhat tedious to watch — except if you really want to learn about a topic in-depth, in which case you’ll be happy they exist. Otherwise, skip!
I organized them roughly by topic area and added annotations. If you only have time for a few, my suggestion is to start with the ones with the asterisk. (Again, not because they’re necessarily the best, but because I think you get a lot of reward for your time investment).
Boreal Perspectives 