Weather station
Embedded system for collecting and logging weather data.
CESI · Embedded systems · Team project
- Intended use
- Fitted to ships
- Target
- ATmega328, 2 KB of RAM
- Quantities
- Pressure, humidity, light, temperature
- Deliveries
- Analysis, architecture, mock-up, documentation
Key points
- Four measured quantities: pressure, humidity, light, temperature
- Timestamped logging to SD card
- On-board readout interface
- User documentation written
How it works
- 1
Analyse before wiring
The system was first described in UML and SysML: what it must do, which actors are involved, how the blocks fit together. On an embedded project this detour is not a school exercise: once the board is wired and the case closed, changing your mind costs a teardown.
- 2
The program architecture
Functions, variables, division of responsibilities: the software structure was laid out on paper before being written. On a microcontroller each global variable eats memory measured in kilobytes, and the compiler gives no warning when there is no longer enough left for the stack.
- 3
The four sensors
A barometer for pressure, a hygrometer for humidity, a photoresistor for light and a temperature probe. Each answers in its own way: some return a digital value ready to read, others a voltage that must be converted and calibrated.
- 4
Logging
Each reading is written to the SD card with its timestamp, so a period can be replayed afterwards rather than only read live. That is what separates a display from a measuring station: the first serves only whoever is looking, the second produces data usable later.
- 5
On-site readout
An on-board interface shows current values and history without plugging in a computer. On a ship this is a usage constraint rather than a convenience: nobody fetches a laptop to find out whether the pressure is dropping.
Try it yourself
The station's loop as it runs on the microcontroller. Unplug a sensor to see what happens.
Pressure
1011hPa
Humidity
75%
Light
470lx
Temperature
12.5°C
Readings: 0 · SD card writes: 0
Values are simulated: the prototype left no publishable dataset. What the demo shows is the rhythm of the loop: sensors are read every cycle, the SD card is written only every tenth cycle because it is far slower, and unplugging one sensor does not freeze the others.
Context
Design an embedded weather station to equip ships. The measurements serve two purposes: an immediate readout for the crew, and a history kept on an SD card for later analysis. What makes the brief interesting is where it ends up: a system exposed to sea spray, powered without guarantees, and that nobody will come to reboot.
What a microcontroller changes
Writing for an ATmega328 has little in common with writing for a computer. Two kilobytes of RAM, no operating system, no sensible dynamic allocation, and a program that has to run for weeks without a leak or a reset.
- No allocation on the fly: everything is sized at compile time, or the stack eventually eats into the data
- Strings are expensive: a single error message takes a noticeable share of available memory
- Writing to the SD card is slow and must be spaced out, or it stalls sensor reading
- A sensor that stops answering must not freeze the station: the loop carries on with the other quantities
What I took away
- Programming under memory constraints, where every variable has to justify itself
- Modelling in UML and SysML before wiring, because a build does not refactor
- Reading sensors of different natures and converting voltages into physical quantities
- Making data persistent and timestamped, therefore usable afterwards
- Writing documentation for someone who did not write the code