Artificial light is supplied using LEDs with temperature and humidity controlled using Heating Ventilation and Cooling Systems (HVAC). It’s mother nature, 2.0. Well, actually it’s more like build 4.63e+6 . The truth is though, these setups have the real possibility to revolutionize farming. Results from various configurations around the world have proven very successful.

So the obvious question, “Can I replicate this on a smaller scale?” The answer to this is actually “it’s already been done”. Small indoor grow tents with full cultivations of one or more plants are a no longer just small hobbies at this point. Many people have a fairly simple setup. This includes digital/ analogue readouts for basic parameters and a timer of some sorts to dictate day/night cycle, an extractor for fresh air and an oscillating fan for circulation. That’s the basic covered.

My original tent had some of the basics; light cycle, heater and oscillating fan. But as time went on, I found that this did not produce results. My plants were not doing too well. It was time to get serious. I got a proper LED light setup, an extractor fan and a humidifier. This took my setup to the next level and the results were visible. Some plants started to get better. The only problem being that the setup was still very manual . All the parameters were controlled with analogue switches (me mostly).

DHT22

First things first. Get the STM32 up and running with the most basic code and drivers to toggle a pin. Once we have a baseline, I decided to write the driver for the DHT11 first. As the datasheet states, information is delivered over one pin and there is no “input” per seh. The procedure for initiating a reading on DHT11 is as follows:

• Microcontroller initiates a read request by pulling the data low for at least 20us. Microcontroller then releases the line. The data line is open drain with pull ups.

• The DHT22 then pulls the line low for 80us, then high for 80us. Data bits then follow this.

• Each data bit is preceded by a low ‘0’ pulse of 50us.

• A high ‘1’ then follows. This high can be either a ‘1’ or ‘0’. To differentiate, the signal must be timed. A ‘0 is ~27us and a ‘1’ is ~70us.

• There are 40 bits of data in the following arrangement:

  • 8 bits for temperature integer

  • 8 bits for temperature fraction

  • 8bits for humidity integer

  • 8 bits for humidity fraction

  • 8 bits for the checksum

However, the DHT22 is unlike the DHT11 in how this data is actually presented. The data for temperature and humidity is actually sent as a combined number represented by 16 bits. In other words, Humidity is bits[0-15]. To actually break that into integer and decimal parts, the 16bit number must be divided by 10 for the integer and mod for the fractional. The same applies to the Temperature. This is very different from the DHT11 which actually sends each part out as a separate 8 bits. Initially, I had written a driver for the DHT11 but ended up using the DHT22 as it was more accurate and I had managed to blow up a DHT11.

To create a driver to interface with the sensor, we will need to use the Input Capture feature from one of the timers. In the Nucleo STML4 series, Timer 2 (channel 1) is used. Setting up the basic part of the timer is fairly simple however getting the timing calculations correct require some tweaking. First off, consider the longest time the microcontroller has to count vs the shortest time. That’s 20ms for initialising, and then about 26us for a ‘0’. This is nearly an order of magnitude. So the pre-scaler needs to be a number that can operate at both extremes, else a change of pre-scaler mid cycle would need to be executed. This should be avoided.

ST7565

Once chosen, I moved on to the display. I opted for a monochrome LCD dot matrix with 128x64 pixels. Easy enough to find libraries for as writing your own LCD driver is very tedious. But also, don’t reinvent the wheel. The LCD interfaced using the SPI protocol, which was fairly easy to integrate and develop wit the HAL. In testing, the most trouble I ran into was a known problem with the ST7565 driver. When sending data over a period of time, the LCD would disjoint and overflow. Meaning, the characters would appear in the wrong place on the screen, chopped off at the bottom and restart again at the top. This was actually easily remedied with a quick search online advising to change the start position for the LCD in the library.

Repo: STM32_Lib_LCD_GMG12864-06D_ST7565R/README.md at master · GolinskiyKonstantin/STM32_Lib_LCD_GMG12864-06D_ST7565R (github.com)ave fun! limor (github.com)

D1 Mini

Getting the SD card working well was one of the harder parts of the build. In general, many (not all) SD cards can be written to using the SPI protocol. However, to facilitate opening, reading, and or writing to a file on the card, the FatFs library is used. The library takes care of the the protocol needed to set up a file system on the SD card, and the details of actually ‘mounting’ and ‘dismounting’ the card. At their most fundamental, these are all a mixture of specific data protocols sent over SPI and pointers to data structures used to keep track of the physical media the microcontroller now has access to. In implementation I found that the hardest part was integrating the library with my codebase. FatFs is a pretty hefty library and really gets complicated in the deepest bits. Unfortunately, it doesn’t take much to torpedo the whole thing and stop it communicating at all with the SD card. The library I used was a specifically developed to work with the STM32 HAL. You need only set up the handle to an SPI structure you’ve created and the library handles the communication speed switch needed for talking to the card. There is a little work that needed to be done to get the library include files to play nice.

Repo: ThundeRatz/STM32MemoryCard: Library to handle STM32 SDCards applications (github.com)