When the uRADMonitor CITY was designed, the goal wasn’t just to build a good air quality station. It was to build a platform: one that could evolve as monitoring needs change, without requiring a complete hardware redesign every time a new sensor category becomes relevant.

That design philosophy is now being put to the test with greenhouse gas (GHG) sensors.

Adding NDIR GHG Sensors: N2O, CO2, CH4

The latest CITY configuration adds support for NDIR (Non-Dispersive Infrared) gas cells covering three greenhouse gases: nitrous oxide (N2O), carbon dioxide (CO2), and methane (CH4). These are the primary GHGs associated with agricultural emissions from soil processes, livestock, and organic matter decomposition and they are increasingly relevant to environmental compliance and carbon accounting programs.

The NDIR cells selected share a common form factor and UART interface across all three gas types. This was a deliberate design choice: an identical footprint means a single PCB layout supports any combination of gases by swapping the cell, not the board. Measurement ranges are matched to field conditions: CO2 at 0-5000 ppm (1 ppm resolution), CH4 at 0-100 ppm, and N2O at 0-1000 ppm (10 ppm resolution).

Gas Slot Architecture and Automatic Identification

One of the less visible but more significant changes in this firmware revision is how gas sensors are defined and managed. The CITY now uses a slot-based gas configuration system. Each physical sensor position is declared as a named slot with an associated gas type, measurement range, and UART channel. The firmware reads this slot table at boot and configures the communication stack accordingly with no manual assignment, no hardcoded sensor order.

// Gas slot definitions — each slot declares its type, range, and mux channel
gas_slot_t gas_slots[] = {
    { GAS_CO2,  RANGE_5000PPM, MUX_CH0 },
    { GAS_CH4,  RANGE_100PPM,  MUX_CH1 },
    { GAS_N2O,  RANGE_1000PPM, MUX_CH2 },
};

More importantly, each NDIR cell exposes a Gas ID register over UART. On startup, the firmware queries this register for every detected cell and cross-references it against the slot table. If a cell reports a Gas ID that doesn’t match its declared slot, the firmware flags the mismatch and skips that channel until resolved. This makes physical sensor swaps safe: plug in the wrong cell by mistake and the system refuses to log bad data silently. This also gets us closer to a true plug and play scenario for most cases.

uint8_t detected_id = ndir_read_gas_id(slot->mux_channel);
if (detected_id != slot->expected_gas_id) {
    log_warning("Slot %d: expected GasID 0x%02X, got 0x%02X — skipping",
        i, slot->expected_gas_id, detected_id);
    slot->active = false;
}

UART Multiplexing with Windowed Polling

NDIR cells of this type share the same physical UART bus. To handle multiple sensors on one interface, the CITY uses a dedicated MUX driver layer that switches the active channel before each transaction and enforces a settling window between switching and polling. Each sensor gets its own time slice; the driver guarantees no two sensors are active on the bus simultaneously.

void ghg_poll_all_slots() {
    for (int i = 0; i < NUM_GAS_SLOTS; i++) {
        if (!gas_slots[i].active) continue;

        mux_select(gas_slots[i].mux_channel);
        delay_us(MUX_SETTLE_US);           // settling window per sensor

        ndir_send_read_cmd();
        if (ndir_await_response(NDIR_TIMEOUT_MS)) {
            gas_slots[i].last_ppm = ndir_parse_concentration();
        }
    }
}

The same MUX driver handles multiple NDIR cell families that differ in their UART protocol framing , command structure and response packet layout are abstracted behind a common interface, so the slot table entry, not a compile-time flag, determines which driver is used for each channel. Extending to a new gas type means simply adding a row to the slot table and, if the cell uses a new protocol variant, a driver implementation but nothing else changes.

The Platform Advantage

What makes all of this possible without a board redesign is the CITY’s base architecture. The mainboard provides power regulation, connectivity (GSM with external antenna), SD card logging, and the sensor bus. The gas sensor payload sits in a separate, swappable module above the board. Adding a new sensor type means a new module and a firmware update; the data pipeline, cloud upload, and API remain identical.

Deployed Outdoors, Running Continuously

The outdoor photo shows a CITY unit in its typical deployment: pole-mounted with its big Stevenson-style radiation shield, solar power, and a meteorological sensor dome at the top. Built for long-term, unattended operation , the kind of continuous record that makes GHG trend analysis meaningful.

GHG concentrations in agricultural environments are not static. They vary by season, time of day, temperature, and land use. Capturing that variation requires persistent monitoring, not spot sampling. The “Model CITY”, already proven for urban air quality over multiple years and across dozens of countries, brings that same continuity to the GHG use case.

What This Means in Practice

A single uRADMonitor CITY station with the GHG sensor module can simultaneously track N2O, CO2, and CH4 alongside standard parameters particulate matter, temperature, humidity, barometric pressure and transmit everything over GSM to the uRADMonitor cloud in real time. The Gas ID autodetect layer adds a practical safety guarantee: the data logged is the data the sensor actually measures, verified at the hardware level on every boot.

The sensor variation works perfectly, getting it closer to a generic platform than a single fixed hardware design with a new set of sensors for a completely different new application scenario.

More on uRADMonitor CITY: uradmonitor.com/products