Rain Alarm for Astrophotography proto 2 - Wireless Communication

You’re reading part 2 of the Rain Alarm for Astrophotography series; part 1 is available here.

The need for radio communication

As previously discussed, we intend for the rain sensor device to remain outdoors alongside the unattended astrophotography equipment, in anticipation of rain showers.

Additionally, the base station will be located indoors so that the alarm can be heard within the house.

We want the two devices to reach each other from a distance of 50-100 meters, with some walls in between.

What radio communication technology?

Here are the options:

Wi-Fi: There are two approaches to consider. Both devices connect to the same home network, or one device—likely the base station—acts as an access point for the other to connect to. While I have full coverage in my own garden, I have to point out that the garden is not particularly long, and I bought an expensive dedicated Wi-Fi router to get that coverage. Wi-Fi won’t be a viable option for our plug-and-play product.
Bluetooth: Quite famous for IoT. What makes it promising are reports suggesting that BLE 5.0 could achieve a transmission distance of 200 meters outdoors and 40 meters indoors. I won’t eliminate this option just yet.
Zigbee: I love the Zigbee tech, but it’s not suitable for this type of project. Designed for mesh networks, it’s not optimized for long-range, 1-to-1 communication.
Cellular: That’s a solid option but I don’t want to go there to stay low-tech.
LoRa: This is IoT-centered, low-power, long-distance (from 1 to 10km!), and low-level enough to tune the bandwidth/range tradeoff. The modules are not too expensive and versatile: they support many other radio modulations, such as FSK. This appears to be the best choice.

Hardware

The microcontroller

Proto 1 was built with an Arduino Uno (ATmega328P microcontroller). This was the only hardware available around me at that time and it did the job very well. For this second prototype, I’m looking for something smaller that I can embed in a box, aiming to stick to the same microcontroller for the rest of the project.

Raspberry Pi-like boards are out of the question, as I don’t want a full computer here.

I considered using an Arduino Nano and ended up wasting two nights fighting with a cheap knockoff. I was surprised to discover that the low-cost suppliers not only produce bad-quality clones (Arduino being open source), but also cut costs by replacing some expensive components, like the serial-usb converter CP2102 for some shittier alternative, like the CH340. So yeah, I struggled with Windows 11 automatically updating the driver, which then made the OS stop recognizing the board with the latest driver version. Plus, whenever I connected the second board, it made the first one disconnect. Super annoying! The genuine-official Arduino Nano costs 20 euros, and I need two: 50 euros with the shipping. That’s quite expensive if I want to make a product out of this.

I went for a pair of ESP32 microcontrollers (ESP32 Wroom 32E) from uPesy.fr. Yup, made right here in France! I also migrated from the Arduino IDE to PlatformIO for the coding experience. Things are getting serious here.

Boards comparison — From left to right: Arduino Uno, Arduino Nano & ESP32.

The radio module

The ESP32 comes with built-in Wi-Fi and Bluetooth, but it lacks LoRa support. So, we’ll need a separate chip to handle LoRa. I chose the XL1278-SMT, which is based on Semtech’s sx1278. This module runs on 3.3V for both power and logic levels, which hopefully matches the ESP32 board. That’s different from Arduino boards, which operate at 5V.

SX1278 module — This tiny evil thing has 1.27mm pin headers that I had to bridge to 2.54mm pin headers for my breadboard.

Prototyping the radio communication

For this prototype, I’ve set up a button that toggles the ESP32’s built-in blue LEDs when pressed. The transmitter board on the left uses direct electrical wiring to control the LED, while the receiver board on the right gets the button status via LoRa and acts accordingly.

This is amusing, as there's no security in place right now. Who knows, someone might think I'm sending out Morse code messages!

Schematic

Both the ESP32 and the XL1278-SMT LoRa module connect in the same way on both circuits, using the SPI bus. The uPesy board features a tiny blue LED, D1, connected to the GPIO2 output.
I’m using a switch, labeled SW1, to simulate a rain trigger. The switch is connected to the ESP32 board via GPIO15, configured as INPUT_PULLUP. The board comes with a built-in pull-up resistor, so there’s no need for an external one.
When you press the switch SW1, it changes the state of the rain sensor’s LED, labeled D1. The base station’s LED follows the switch state as well thanks to the wireless link.
Lastly, I needed a capacitor C1 to stabilize the boot of the XL1278-SMT module on the transmitter side, due to some voltage fluctuation issues.

Takeaways

We’ve learned a few things:

The ESP32 is looking pretty solid, it’s safe to assume this will be the board I will use for the final product.
LoRa rocks too in terms of range and reliability. I was able to reach 200 meters of coverage with a 100% stable transmission between my house and outside on the street, with countless walls in between. That’s very good considering I haven’t fine-tuned anything and the PCB antenna is poor, and I don’t even need more than that.

Next step

Next on the agenda: speakers for the base station.

There’s a bunch of tweaks to make on this prototype, like:

Switching the ESP32 to deep sleep to kill the Bluetooth and Wi-Fi, dropping from 200mA to 20mA (easy).
Leveraging ESP32 timers so we don’t have to poll the switch or blast LoRa packets at CPU clock speed (medium-level stuff).
Getting the LoRa module into sleep mode and waking it when needed (tricky).
Securing the LoRa communication (medium-level stuff).
Buying the proper version of the LoRa to comply with EU regulation.

Part 3 is available here.