Hotstuff

Introduction: Hotstuff

About: Has anyone tried turning me off and on again?

Aiming to become the greatest little graphing thermohygrometer available for an Arduino Uno.

Applications include:

  • Infant/nursery temperature monitor
  • Outbuilding temperature monitor
  • Greenhouse monitor
  • External atmospheric check
  • Home/office HVAC check and monitoring
  • Incubator monitor/control

NOTE: This is not a medical device and is no substitute for proper planning and working conditions!

- Features

  • Completely free for non-commercial use.
  • Comes with a super-speed 7 segment simulated font "Rose Digital" and the 16 segment with full alpha, "Astro Nerd" (see licensing for limitations on this part of the software, it’s for a good cause, we promise)
  • Almost entirely flicker free updates (1)
  • Auto ranging graph covering the whole range of the DHT11 and DHT22 sensors
  • Uses a DHT11 (at a pinch, we haven't tried) or DHT22 to get temp and relative humidity.
  • Displays relative humidity and temperature in Fahrenheit or Celsius
  • Displays dew (condensation) AND frost (condensing ice) points in the current units
  • Flashing graphic damp and dry air warnings.
  • User customisable proportional display fonts (option)
  • Main display range -9 —> 99 F or -9 —> 80C (Range warning if exceeded)
  • Humidity from 0% -> 99% RH.
  • Records max and minimum temperature and humidity since reset
  • Includes Steadman's calculations and will warn of uncomfortable or dangerous working conditions
  • Requires a minimum of parts Uno, 3.5" TFT shield
  • Optionally switchable F/C
  • Programmable heater control (for incubators, etc.)
  • Simple to build
  • Highly modular code
  • Did we say it was free?

(1) Buffering limitations on the UNO mean the chart flashes briefly during updates.

Supplies

  • Arduino Uno R3 (or Chinese clone).
  • 1 DHT22 temperature and humidity monitor (eBay/Amazon)
  • 1 TFT 3.5" Shield with resistive touchscreen and SD card slot (see text.)
  • A SPST slide switch (optional).
  • A PC with USB - to upload the program.
  • A 9-12v Power supply.
  • Good quality side cutters
  • Soldering iron & solder. Heatsink tweezers. Jumper wires.
  • Optionally, a case (Arduino Uno cases don't have enough room for a display shield).
  • Fine heat-shrink tubing (to dress and insulate the soldered points).

Step 1: What Makes This Special?

But hold on, you've seen the pictures and this is just another temperature and humidity meter right? You can get those on eBay for about the same cost as the Arduino TFT shield we used for this project.

Well not quite... allow me to explain.

Coronavirus, Covid-19, SARS-Cov-2 ... all pretty scary things one of the best things we can do right now is to look after our lungs and nowhere is this easier to do that at home. If we work in a modern office, it should have good HVAC and most modern cars have excellent filters that take most of the larger particles from the outside air before they enter the cabin. This leaves home... the one place where feel safe and that's where the most common nasties lurk. While it's possible to get Legionnaire's disease from a dirty shower head (yes, really!) that's quite uncommon thankfully.

But there's something far more common that most of us don't even give a second thought because we've lived with it our entire lives.

Mould.

More specifically, mould spores. Think of them as microscopic seeds that are produced by tiny fugal growths that hide away it the dark and disperse freely into the air - often without needing to be disturbed - and can fill our homes with everything from those nasty black patches in the damp corners to dry rot and more.

Mould doesn't damage your property (which is bad enough) it can cause irritation to the entire airway - from our nose and sinuses right now into the very alveoli, the millions of little sacs that line our lungs - they're so small that stretched out, they would roughly cover a tennis court. That's a lot of area for a microscopic organism to get in, hide away and cause all manner of havoc.

And there's more...

At the other end of the scale, dry air can wreak havoc too. The surface of our lungs is covered in a very thin film of a watery mucus - it's there to help keep the nasties at bay and it does a pretty good job, but if the air is too dry, that mucus starts to get dry too and that makes it more difficult to breathe.

And there's even more...

Humans naturally keep cool by evaporation - we sweat (on a dry, hot day, it's imperceptible) but as the humidity increases, people find that the water just "stands" on their skin and they start to get hot. Very hot.

In some parts of the world (Australia and the tropics) this is such a problem that workers have to be aware of the "effective working temperature" - the weather channels often refer to this as the "feels like" temperature, because as the heat/humidity increases, the chance of heatstroke and even death becomes a very real possibility.

For some rationale and further reading consult Wikipedia or dive in!

https://en.wikipedia.org/wiki/Heat_index

If you think, "that will never happen to me", consider that with climate change this is becoming a very real possibility at latitudes beyond Seattle and working on a hot "muggy" day you could be risking your health without even realising it.

Heat exhaustion is extremely unpleasant and heat stroke is a serious medical emergency.

So this device is not just a fancy graphing thermometer/hygrometer, it has built in alarms to warn of heat stroke conditions, will help you decide how well ventilated your home is too and it even looks pretty smart (if we do say ourselves).

With all that said, this device is not intended for medical purposes and should not be used where health and safety of workers might be compromised. Even if we could certify our code (we can't) the hardware itself does not carry that assurance. This is to stop all that messy legal mumbo jumbo but it should give you and idea how healthy your home is!

The build is about as easy as it gets although you will need to "butcher" the TFT shield because we're going to use it in ways the designers never thought of.

NOTE:

As someone has raised this issue, it's worth noting that DHT22 sensors have a claimed accuracy of ±0.5°C and ±1% Rh which is enough for many applications but not if the temperature/humidity is critical. We plan to add some post-assembly calibration later. The DHT11 has a slightly less precise temperature measurement of ±1.0°C but generally should reflect our environment well.

Step 2: Butchering the TFT

This is the only really tricky part and it's the sort of thing you need to get right because unless you're a bit handing with a soldering iron... well, less said about that the better.

This project *should* work with many shields of this resolution and type - and the software will work with any ATMega 328 or larger (the software a very tight fit, approaching 99% of the 28K available at this writing) and we've squeezed as many features in there as space will allow.

Check everything works before you start chopping bits off!

  1. Test fit the display to the Arduino - the uSD slot goes is at the end where the power and USB ports come in. The backlight will come on when it's powered but otherwise it won't do anything.
  2. Note the pin labels for the uSD card access. We won't be needing these so we're going to give the board a very short haircut.
  3. On our board the target pins are marked SD_SS, SD_DI, SD_DO and SD_SCK at the end of J1.
  4. You can leave or remove the last two pins - we cut the ones from our board.
  5. Don't cut anything else or the LCD won't work! For instance, LCD_D0 (one of the data lines) is very close so you need to use extreme care here.
  6. Check twice, cut once or hope you can solder a new header in!

Note: it may be possible to use "multiplex" the SPI pins we've used here and store data on the SD card but that is something we'll leave to other builders.

Step 3: Fitting / Soldering the Sensor

While it's not strictly necessary, soldering the connections is the best way to make this project into something you can mount and forget.

Soldering to the DHT22 should only be attempted by someone with reasonable soldering skills. The sensor is highlysensitive to changes in temperature and humidity. A nameless person slightly over-heated the solder pins on ours (cough, cough) and sent the sensor so far out of calibration that it refused to work until we'd "cooked" it as instructed by the manufacturer to stop it from producing read errors. A better option for most people is be to source a pre-mounted DHT11/22 with a header designed for jump wires.

DHT22s use a serial single-wire serial link to communicate with the MCU - with a potential range of over 10M (>32 feet) without signal conditioning so it the detector can be placed at some distance from the Arduino.

It transpired (after studying the schematics) that the 6-pin In-Circuit Serial Programmer (ICSP) header at the end of the board is connected to the SPI pins that were used by the shield for its SD card read/writer. Using these pins won't affect your ability to program the board over USB in future as they are primarily used for debugging and programming the Uno with a serial programmer (FDTI). As a side note, we're grateful to Steve Wood of AudioSpectrum Analysers in the UK, for supplying us with a spare one when ours vanished into Marc's vast pile of bits.

If you have a pair of good quality long-nosed pliers, it is possible to bend the wires over so they can take a DuPont header but soldering is the preferred method. With care (and a steady hand) it's perfectly possible to solder the DHT22 directly to the header.

Connection is about as easy as it comes but it's essential to observe polarity because connecting the device in reverse is likely to destroy it instantly. Although the DHT22 has four pins, pin 3 is not connected. Mounted sensors typically only come with three pins which line up beautifully with the header. With the sensor lying on its back (shown) you can see the power and data pins line up correctly.

Step 4: Test and First Use

All that remains is to carefully plug your DHT22 module into the Arduino and set up the software. Much of the clever stuff is done by the software, made possible by graphics library from Adafruit, David Prentice's MCUFriend display driver and equally clever stuff from Robert Steadman's "effective heat" calculations.

The only thing you'll need to set up in this basic configuration is to tell the software which three pins are being used.

If you prefer to wire your sensor differently, the following lines in CONSTANTS.H tells the Uno how to configure itself.

#define DHT22_DATA 11

The DH22 uses a very conservative 1 - 1.5 mA when taking a reading which is far less than the typical max of 20 mA so it's not going to stress anything. (Of course, short-circuiting any pin will almost certainly destroy the device hence why we suggest using heat shrink if you put the sensor on a Heath Robinson plug-in board.)

If all goes well, HotStuff will boot in about 5 seconds. If an error is detected, the screen will go black and display a short error message. This can largely be ignored as it just means the sensor either isn't powered or isn't wired correctly.

Step 5: Using the Instrument & FAQ

Q: I can see feint traces of the unlit digits on the screen. Isn't this a bug?

A: No, this is by design although it's not set in stone. The idea was to emulate the look of a "real" LCD display (vs. a high-resolution TFT). Such displays use large, pre-designed blocks which can be switched on and off like pixels, but unlike pixels they can occupy large parts of the screen. As a result there is invariably a feint trace of the material visible and this is emulated here.

Q: How can I switch between centigrade and Fahrenheit?

A: The function wasn't fully tested at the time of "going to press" (because someone forgot, didn't you...). However, we have checked and this function works (if desired) but attaching a small SPST slider switch with the one terminal to pin 12 and the other to an convenient ground. The fastest way to do this is to solder or use a modified DuPont connector to attach to the ground and the other either to pin 12 directly (some clones have an extra set of through holes for this sort of thing) or on original designs, to the MOSI pin on the ICSP header which is the one above the 5v power. If this switch is in the open position, the unit boots in centigrade but in the closed position, it pulls pin 12 low and a reboot brings it back up in Fahrenheit. There's no need for a resistor to protect the pin since there's an internal resistor provided.

Q: Can I use a different sensor?

A: Yes. But you'll either need to find a library that fits or write your own. We chose a DHT22 because of its single-wire interface and because there was one in the back of the parts draw gathering dust. One wire interface designs are preferable because we can use the other "free" digital pins for other functions. I2C is not available since that is occupied by the display shield. SPI is however if you're prepared to lose functionality such as scale switching, etc.

Q: Can I sell a commercial version?

A: Sure you can provided you follow the software licencing terms (it's essentially the 2-clause BSD licence which is very permissive, but be aware that other licences may apply to included libraries.) Also note this device is not (and never can be) certified for use in critical environments, it's for home/hobbyist use although it could find applications in residential care homes, offices and other workplaces. Just be aware that it's only as good as the weakest link... The font engine developed for this project is licenced for non-commerical use unless you make a donation to our colleague's cancer GoFundMe.

Q: My min/max readings are not recorded on the chart.

A: This is by design. The instrument using a "moving average" (a statistical mean) which is reset every hour. This helps to smooth the graph out and give a more reasonable look at the measurements preventing odd spikes (like some, er, "person" breathing on the sensor, from sending it crazy.

Q: Why don't you use C++ shortcuts (like ++, -- and so on) in your code? Why is everything so ... wordy!

A: One of the authors is a veteran 8-bit games programmer, but the other comes from Python. We have used a few shortcuts where their use is fairly unambiguous but C (the language underlying C++) is old and compilers in general were a bit dumb back when Kernighan and Richie wrote the first compiler, not to mention computers were slooooooow and keyboards had keys that you felt you had to hit with a slab hammer. All of these things (and others) led C to be a very terse language with multiple shortcuts to achieve the same thing. A large number have (and remain) responsible for some very tricky bugs: and don't even get us started on heap/stack crashes.

Obviously, some optimisations (the semaphores for example) are necessary because we're trying to squash a quart into a teacup but where possible we've avoided that.

Incidentally, if you don't own a well-read copy of K&R C... stop right now and go order one. There are a lot of very large books on C but K&R remains probably the best and since C underpins C++ you'll have a better understanding of that language's features too.

Q: I think I found a bug what should I do!

A: Bugs? There are no bugs, only features... just some features don't work how we expected them to. Leave us a note on GitHub and we'll try change the feature so it's more suited to the design. Actually the code is being refactored all the time into several different projects so it's fairly scrappy in places and for that Marc will be slapped with a wet haddock until he screams, "No more!" - Dan

Step 6: Compiling From Source

The project is hosted on GitHub (there's simply too much code to slap on an Instructable, people would get square eyes trying to figure out all this stuff) but while pre-programmed ATMegas will be available on eBay you might want to compile your own from source.

The source code which should compile under Visual Studio with Platform IO - it got a little unwieldy for the Arduino editor and Visual Studio allows us to writer better code with fewer errors thanks to some of the "lint" picking it has.

https://github.com/marcdraco/HotStuff

https://platformio.org/

https://visualstudio.microsoft.com/downloads/

You will need a couple of libraries for this shield.

Adafruit GFX (which will need the Wire library too).

MCUFriend_kbv by David Prentice v2.9. David has produced later versions but they are not guaranteed to work.

Step 7: Make It Your Own

There's nothing quite like having a beautiful project that you can show to others and have them gasp with awe as it starts up with your name up there in lights. So we've set the software up so that almost anyone should be able to make changes without a knowledge of C/C++.

Find in your favourite text editor in "constants.h" to find the following lines:

constexpr uint16_t defaultPaper = BLACK;

constexpr uint16_t defaultInk = CYAN;

You can see the colour names in plain English - David Prentice kindly supplied a load of definitions which appear earlier in file and all you have to do is change your foreground (and background) to something of your choosing before you upload to the board. The "trace" colours for the graph are a little deeper down here and look like this:

constexpr uint16_t HUMIDITY_TRACE {AZURE};
constexpr uint16_t TEMP_TRACE {YELLOW};

Although these TFTs aren't known for their contrast (and are limited to 5-6-5 RGB, 16-bit colour) we've provided an example compilation option "NIGHT_MODE" which is commented out by default but sets the display

Other colours can be adjusted similarly. Want it to read in Imperial when it fires up? No problem! Find and comment out ("//") or remove the following line and when you upload back to the board...

Questions, comments and improvements should be posted to GitHub.

Even longer documentation regarding hacking the project is in the accompanying README.MD

Step 8: Hacking It!

This project was created using the KISS principal and it's complete as it is.

It can form the basis of something based on another sensor - a more accurate or faster one perhaps, provided that there's enough space for its library. As you can see, things are already pretty tight.

When you know the code well, it's easy to change things dramatically, but even without a lot of programming experience a lot of the constant values in "constants.h" explain how to change things. More advanced programmers will note that it's relatively easy (we hope!) to pull the parts you need for later use. For example, we replaced the graph display with a fully functional real-time clock in under an hour. The clock requires a way to set the time however, so it's not useful as is; we'll release a functional version of that later on (you can find the development code on GitHub under HotStuff Chrono).

But there's something about these displays that isn't immediately obvious until you go to program on - that touchscreen.

The problem with resistive touchscreens of this type is that they need calibration which adds to the complexity and, frankly, there isn't the room with all the other functions we crammed in to crowbar another library in there. This would be possible with the Arduino Mega which has far more flash space, but where's the fun in that?

Look under the board and you'll see that apart from the digital I/O to drive the LCD and SD card there's no outputs for an ADC to detect the resistance measurement.

Odd right?

Clever folks these designers. The display has its own frame buffer: that's an area of RAM that holds the screen as it is while the power remains connected which means that you can (programmatically) disconnect several of the device's pins while it's switched on and use them for other jobs - provided you put them back afterwards!

For information on how this is done, we suggest reading Limor "Lady Ada" Fried's resistive touchscreen library.

And if you make something cool, please be sure to file a Pull Request!

Step 9: Optional Donations

Now here's the optional bit, let us introduce the lady who gave life and a name to the fonts used in this project and remains an inspiration to us all, particularly receiving news that she has developed cancer and ... most of us know how scary that particular bogeyman is. Her full bio is on her website https://www.rosedf.net/ and you can find her on the usual social media channels.

She says of herself:

"If I am not training to try and get to space, telling people to go look at our beautiful night sky, spending time with those I love, or just being a nerd, I like to focus my attention on education access and equity. I work on advocacy for victims of domestic/sexual abuse, and homelessness-like I was, and I like to raise awareness on the importance of Mental Health in everyday life and academia."

If you'd like to chuck her a few bucks (or whatever your local currency is) then we'd all really appreciate it. A lot of love went into developing HotStuff even thought it was meant as a teaching exercise and much of that work can be re-used for future projects that have a "slow" processor but need a fast, clear and above all LARGE alpha-numerical font on a TFT display.

Donate here (you have our thanks):

paypal.me/FirstGenSci

Be the First to Share

    Recommendations

    • New Year, New Skill Student Design Challenge

      New Year, New Skill Student Design Challenge
    • One Board Contest

      One Board Contest
    • Anything Goes Contest 2021

      Anything Goes Contest 2021

    3 Comments

    0
    tytower
    tytower

    1 year ago

    So the sensors you are using can be up to 2 degrees celsius out from actual . What allowance have you made for that ?
    Likewise humidity sensors vary even more than that .
    You make bold claims but with cheap and bad sensors come bad readings..

    0
    marcdraco1
    marcdraco1

    Reply 1 year ago

    HotStuff doesn't claim to be any more accurate than the readings it receives from the sensor (that would be idiotic). The only claim I can make is that it currently has the fastest font renderer of its type because it's only designed produce "faux" LCD 7 segment displays. I does have a very fast renderer for small fonts but it's not fully implemented here except for displaying the flashing icons. It uses 8-bit loops and offsets where possible (Limor's code is more generalised and used 16-bit). The difference on the ATMega 328 is startling and it's something I want to try on a smaller display - this one has requires a 16-bit value in one direction because it's larger than 256 pixels wide.

    There's an allowance in the code for a correction (you'd have to dig through the source but it is there) on each reading independently, there's no practical way that I've found to enter it when it's running as there just aren't enough inputs on the Arduino Uno with this particular shield. This isn't full implemented as I didn't feel it was 100% necessary as for reasons I've outlined, but since you raise it, here is the relevant section of code from Reading.cpp

    void Reading::updateReading(const reading_t reading)
    {
    m_currRead = reading + m_correction;
    m_minRead = (m_currRead < m_minRead) ? m_currRead : m_minRead;
    m_maxRead = (m_currRead > m_maxRead) ? m_currRead : m_maxRead;
    m_cumulativeMovingAverage = (m_cumulativeMovingAverage + (m_currRead - m_cumulativeMovingAverage) / ++m_cmaCounter) + m_correction;
    }

    The problem for most people is they won't have access to a scientifically calibrated instrument to get accurate readings in the first place. The same is true of all similar circuits. In tests we got two different DHT22s and they agreed with each other to within 0.5C and 1% RH, although there's no way to know which production run they originated from. There's also the matter of drift over time, but if someone wanted that level of absolute accuracy they wouldn't be making it with a $5 Chinese copy of an Open Source hardware based on a chip that's been in production for over a decade and is massively superseded.

    This isn't and doesn't claim to be a medical device but it does a lot that no other design of this type can do. A few percent of non-condensing humidity won't make a lot of different either way, if you're referring to Steadman's calculations?

    I'm currently attempting to squeeze a more accurate sensor in there. Using an SPI screen (vs. the shield) would give us room to use other sensors.