Weather Station: Stage 0

Stage 0: Planning a Solar-Powered Weather Station

So I'm building a weather station. Not buying one, building one. From scratch. Solar-powered, WiFi-connected, running C on a Raspberry Pi Pico 2 WH, measuring everything from UV index to lightning strikes. Because apparently I looked at the perfectly functional Met Office app on my phone and thought, "No, I need to make this harder for myself".

To be fair, though, if it wasn't for my family, I'd have gone off-grid a long, long time ago, and I'm starting to get drawn to the idea of building some significantly more complex off-grid systems, so I suppose it would be good to start with the basics - which a weather station sort of is.

I've broken the thing down into a few stages, that I can talk through here, and so that I can get that sweet, sweet dopamine hit from the completion of each milestone, even if it's literally connecting two wires to a breadboard (spoiler: good chance that's at least one of these blog posts, but I'll find 500 words from it).

The Project: Breaking It Down

Early on, I made a decision that might be the smartest thing I do on this entire project: I broke the whole build into eight discrete stages, numbered 0 through 7. Each stage is designed to be self-contained enough that I can test, validate, and write about it before moving on. Each stage gets its own blog post:

• Stage 0: Planning. You are here. Congratulations.
• Stage 1: Get the temperature, humidity and barometric pressure sensor talking over I2C and transmitting data over WiFi. Effectively, the "hello world" of weather stations.
• Stage 2: Bring the remaining I2C sensors online: the UV sensor, the lux sensor, and the lightning detector (lightning happens here like three times a year, but if you're not measuring lightning when you build one of these, what are you even doing?).
• Stage 3: Build out the data pipeline. Get the readings off the Pico and onto a server somewhere useful. This bit is actually quite boring by comparison. I do this for a job.
• Stage 4: Integrate the air quality sensor, which gets its own stage because it's a UART device with power management quirks, and also because I feel a sense of accomplishment from this one.
• Stage 5: Power system. Solar panels, batteries, charge controller, and all the maths that go with keeping this thing alive outdoors.
• Stage 6: Wind, rain, and physical assembly. The mechanical bits. 3D printing. Weatherproofing. Praying. Fixing. More praying.
• Stage 7: Dashboard and Met Office API integration. Making the data actually useful. Well. I say useful. I mean, I'm really just comparing it to see what's happening out my back door (a verifiable weather bomb in its own right) vs what the Met Office devices on buildings in nearby towns say.

The logic here is simple: start with the easiest wins, build confidence, layer complexity. Stage 1 gives me a working sensor and WiFi stack I can lean on for every subsequent stage. By the time I get to the fiddly mechanical stuff in Stage 6, the electronics and firmware should be solid. In theory. (lol, we are laughing)

The Build: Building It Up

The Brain: Raspberry Pi Pico WH

The controller at the heart of all this is a Raspberry Pi Pico 2 WH; the wireless version with pre-soldered headers. It's cheap, well-documented, has excellent low-power potential, and the SDK lets me write in C, which is exactly where I want to be. I know, I know, MicroPython and Thonny - blah, blah, blah. What's the point of getting down to bare metal and not using bare metal code. I want to get better with C, so we'll be using C.

I considered an ESP32 briefly, but where a Raspberry Pi is available, it seems like the simpler choice. The Pico SDK is a joy to work with and the RP2350 (Pico 2) is now a remarkably well-understood chip with a vast (VAST) back catalogue of support online.

The duty cycle plan is straightforward: wake every five minutes, take readings from all (most) of the sensors, fire up the WiFi, transmit the data to an external server, and go back to sleep. WiFi is only on during transmission - no sense burning power to maintain a connection nobody's using.

The Sensors: A Carefully Curated Menagerie Of Stuff I Had In Drawers

Choosing sensors and dreaming up what to include was, I'll be honest, one of the most enjoyable parts of this whole process. I don't know why - but the mapping out of all the things I'd be able to connect was really interesting. Here's what made the cut:

BME280: A Temperature, humidity, and barometric pressure sensor that operates over I2C. It turns out these guys are staples in hobbyist weather projects. They're accurate, well-documented, and dirt cheap. It also maps into the Pico nicely.

VEML6075: A UV sensor that covers UVA and UVB bands, plus a calculated UV Index. This also operates over I2C. This will present a different challenge because, like the BH1750 below, it requires some degree of visibility - black boxes aren't any use! I'm excited for this because I won't have to fear sunburn in my back garden - like in the great scorching of 2018.

BH1750: This provides ambient light in lux, and also operates over I2C. This gives me a proper illuminance reading rather than just a vague "it's bright out" from an LDR. Honestly, I'm not sure that has any value at all in Scotland, but it fits into the box and it wires into the chip - so it's in. The standards here are low.

AS3935: The lightning detector. Yes, really. This is the eccentric one. It detects electromagnetic signatures from lightning strikes and estimates distance - once again, over I2C. Do I need a lightning detector on a home weather station? Absolutely not. Am I including one anyway? Absolutely yes.

PMS5003: This is a particulate matter sensor for air quality. I'm excited to include this, because a lot of my early learning as a young data scientist/stats graduate was related to PM2.5 particulate matter - since that's what Roger Peng taught. And Roger Peng was an absolute dude. This one's a UART device rather than I2C, and it has its own power management considerations. It draws meaningful current when active, so the plan is to sample it hourly rather than every five minutes, and suppress it entirely during periods of poor solar charging. It has a sleep pin that I can drive from the Pico to keep it dormant between readings.

PCF8583 and tipping bucket rain gauge: This is a pulse-based sensor that will collect 0.2mm per tip. Simple, mechanical, reliable. Also an absolute disaster of accuracy requirements and calibration. A PCF8583 counter chip operates over I2C and will count pulses while the Pico is asleep, so I don't miss any rainfall between wake cycles.

3-cup anemometer: This will measure wind speed via a reed switch and magnet. Each rotation generates a pulse; count the pulses, do the maths, get wind speed. The cups and housing will be 3D printed in ASA or PETG with a UV-resistant clear coat, because this thing lives outside and I'd rather it didn't disintegrate after one summer. This is also where my 3D printer comes into action.

Wind vane: While the anemometer measures speed, this measures direction via a hand-wired resistor ladder on perfboard. Different resistor combinations for different positions, read through an ADC. It's old-school and fiddly but it works, and I already own the reed switches and resistors, which definitely justifies the approach.

You'll notice that almost the whole list operates using I2C. That's deliberate. It makes all the sense in the world to have fewer buses to manage, simpler wiring, and the Pico's I2C support in the SDK is solid. The PMS5003 breaks the pattern out of necessity, but one UART device is manageable.

Power: Solar, Batteries, and Anxiety

The power system deserves its own stage (and will get one), but the planning is very much a Stage 0 concern because it constrains everything else.

I've managed to source a DFR0559 Solar Power Manager 5V, which handles MPPT charging and battery protection, outputting 5V to the Pico's VSYS pin. Two 3.7V 5000mAh LiPo cells wired in parallel give an effective 9000mAh (accounting for real-world losses at 10%). Two 5W IP65-rated 5V solar panels, also in parallel, handle generation, with JST splitter cables for both the solar and battery connections.

I have created a preliminary power budget - including a 10% pessimism tax on consumption and a 10% cut to generation, because optimism has no place in power engineering. Base consumption comes out around 145mAh per day, rising to roughly 170mAh per day with the hourly PMS5003 sampling. Worst-case winter solar generation sits around 140mAh per day, which is tight, but the battery reserve gives approximately 53 days of autonomy. The PMS5003 suppression during poor solar conditions is the release valve: if charging is insufficient, air quality sampling gets cut first.

The Dev Environment: C, the Pico SDK, and No Ragrets

I'm writing this in C using the Pico SDK. Not MicroPython, not CircuitPython, not Arduino. C. On purpose. With enthusiasm, even. Thonny be damned.

The Pico SDK seems genuinely excellent; it's well-structured and thoroughly documented on first viewing, and gives me real control over the hardware without abstractions getting in the way. For a project where I care about power consumption, timing, and exactly what the WiFi stack is doing and when, that level of control matters. MicroPython would have been faster to prototype with, sure, but I'd have spent the time I saved fighting with garbage collection pauses and memory constraints. C lets me be precise about what's happening and when, which is exactly what I want.

The wiring architecture is still to be finalised. That'll evolve over time as I work through the stages. But the I2C bus layout, UART allocation for the PMS5003, ADC channel for the wind vane, and GPIO assignments for the pulse-counting sensors are all roughly accounted for in enough detail to start Stage 1 with confidence.

What's Next

Stage 1: getting the BME280 reading temperature, humidity, and pressure, and pushing that data over WiFi. It's the foundation everything else builds on, and it's where the soldering iron finally comes out.

I'll see you there. Assuming I don't get distracted by another sensor I definitely don't need and the 250 other projects I have on the go.