FOSDEM/airqualityboard - Codeberg.org

This is the repository for the FOSDEM air quality monitoring board. We aim to create a reasonable standard which other conferences can adopt widely and with the least amount of effort.

= Intentions =

We intend to give interested staff, devroom managers, and attendees a solid decision-making basis. We also intend to improve air quality through ventilation where feasible. At the same time, we recognize that 100% protection is impossible and that ULB Solbosch is a historic venue without modern AHUs (air handling units).

We intend to collaborate as much as possible. This means e.g. re-using existing projects. We intend to collaborate with eventinfra for using devices under the year while FOSDEM doesn't need them. We intend to spread the knowledge about this effort, to enable other conferences and community spaces to re-use our design.

= Roughest of timelines =

Ideally, we have at least a few finished units in hand for ConfConf in May/June of 2026. If not that, something preproduction that somewhat works would be nice. The rationale is that ConfConf is likely the largest adoption multiplier for this hardware. Ideally, we collect feedback online beforehand and do demos / unit distribution on site.

By summer when event seasons starts, we should have 10-20 units in somewhat regular use across the various events. For testing, software and maybe hardware improvements, raising awareness, and also simply to help people make good choices.

By FOSDEM 2027, we should have around 50 production units in the EU.

= Design goals / constraints / requirement =

This list is currently a desired state -- some things like "not a fire hazard" are non-negotiable. Other details can potentially be moved around a bit.

== MUST ==

• Open Source and Open Hardware
• No fire hazard: pouch batteries are a no-go, AA or 18700 are examples of acceptable battery types
• CO_2, temperature, relative humidity, air pressure
  • Calibration cycles must be long, or unnecessary
  • Measurements are reliable enough to give a good decision-making basis
• Configuration, deployment, and operations scale well. Everything is automated.
  • Every device knows its identity in the firmware/software and its also clearly labelled onto the device, e.g. MAC address as QR code
    • This ID can also be used for other purposes, e.g. to link to c3nav, OpenStreetMap, etc
  • Remote configuration: once the device has a working WiFi / Meshtastic connection configured through USB serial, information/configuration such as location can be configured remotely
  • 2 people or less should take 2 hours or less to completely configure 50 units
• Flexibility: Optional hardware should have proper footprints, sockets, or plugs - firmware needs to work reliably with all reasonable hardware combinations
• Several different Mounting options, for example
  • M3 (or so) holes
  • Lego compatible holes, same spacing
  • https://de.wikipedia.org/wiki/Euroloch at the top
  • 3D printed enclosure
  • laser-cut enclosure
  • optionally: fit into the FOSDEM videobox
• RGB or warning LEDs, with configurable threshold and physical on/off switch
• e-paper with at least three colors, can blink
• WiFi 2.4 GHz and 5 GHz
  • IPv4 & IPv6
• Different power supply options. With hardware switch or other assurance that multiple inputs do not damage/destroy the device
  • USB-C
  • battery (no pouches. AA, 18700, or so)
    • battery runtime must at least three full days
    • battery must be easily removable for storage purposes
  • Front-mount everything so it can be taped to a door/wall?
• Extra space for an inventory label
• Small and space-efficient. 50 units can be stored in a reasonably sized box
• Sturdy enough to be shipped commercially in a box
• Easy to source and long availability: components should be common, or chosen with years of manufacturer-guaranteed production
• Deployment software, data collection and storage, visualization, alerts etc need to be packaged with the hardware, all based on Open Source
  • Netbox integration seems like a good component of that
• 2 extra buttons for future functionality
  • 2 extra status LED for future functionality
• Re-use standard components as much as possible. E.g. only M3 or M4 or M5, not a mix. Use common resistor & capacitors, etc.
• On-board antenna(s)

== SHOULD ==

• A fancy version should be around 100€ per unit, as base unit should be around 50€. Overages can be discussed, but they must be discussed
  • Reliability, long term availability of parts, etc rank higher than raw price
• Outdoor-ish capable. It should be useful at and survive CCCamp, EMFCamp, the Dutch hackercamps. No direct rain and no direct sunlight
• No requirement for active fans. No moving parts
• Battery power measurement
• Beeper, with configurable threshold and physical on/off switch
• Public data read-only endpoint in addition to the private configuration one?
  • Can we e.g. transmit measurements unencrypted?
• Re-use proven designs and software wherever feasible
• Syslog / Loki messages for debugging
• Modern tooling & languages. Embedded Rust seems nice
• Components with Open firmware etc are preferred
• Reproducible / verifiable build (units will be left out unattended)
• Blink / beep for "find me"? But in the case any switch for the beeper must not override the find me?
• RGB LED light bar to visualize measurements?
• temp sensors largely decoupled from the heat of the board

== MAY ==

• Meshtastic backup
  • If Meshtastic, should configuration also work through this?
• NFC for mapping / navigation / treasure hunts?
• Prometheus endpoint?
• Particulate matter sensor
• VOC
• Light level
• Noise level
• Other sensors?
  • Gyro / orientation to detect people playing too much/theft?
• Optional power supply mechanisms
  • 12V in?
  • PoE?
  • Solar?
• Extra antenna jack for longer range?
• Can we charge the batteries via USB-C?
• Unlikely, but just for completeness' sake: the ability to measure and report on WiFi quality would be nice. That might need an extra ESP32 or something

= Open questions =

• What should the default transport mechanism be? WiFi & MQTT?
  • Does Meshtastic make sense?
  • 433 Mhz?
  • What about Thread/Matter?
  • Is / should it be possible to read out data through USB?
• What specific temp & relHum storage & operating ranges make sense?
• Find out what cheap & reliable AliExpress etc USB chargers & cables to get
• What are the trade-offs between being soldereable by hand vs fab/stencil/oven?

= Potential hardware =

This will be broken out into its own file soon.

• ESP32-C5 supports 5Ghz WiFi. But the WiFi blob is closed source and not yet reverse engineered

= Other projects / links / resources =

• https://www.airgradient.com/
• https://datagnome.de/ (used at CCC and other events, doing somewhat overlapping things compared to this project)