Product case study · Refrigerant safety · Industrial IoT
QVRF
A modern refrigerant detection platform for HVAC and VRF systems — combining A2L refrigerant sensing, a BACnet stack independently verified at Protocol Revision 26, NFC commissioning of unpowered devices, and an Android service application.
Overview
Refrigerant safety for a changing regulatory landscape.
The move to A2L refrigerants — mildly flammable, lower-GWP gases such as R454B — changed what a refrigerant detector has to do. Detection is no longer a comfort or leak-cost issue; it is a safety function governed by appliance safety standards, with defined response behaviour and protected alarm thresholds.
QVRF was developed as a complete platform for that environment: a fixed refrigerant detector that senses A2L and other gases, evaluates alarm conditions, drives outputs, and reports into a building automation system over BACnet or Modbus — while remaining fast to commission and serviceable in the field.
Engineering challenges
Four problems that shaped the design.
1 · A2L safety compliance
Alarm thresholds for A2L refrigerant detection must not be user-changeable. The configuration model had to expose useful commissioning settings while locking safety-critical parameters behind a compliance mode.
2 · Proven BACnet interoperability
Claiming BACnet support is easy; passing independent verification is not. The stack had to satisfy the BTL test suite at Protocol Revision 26 — object model, services, and device management all conforming.
3 · Commissioning before power
Detectors are often installed before the panel is energised. Configuration had to be possible on an unpowered device, which ruled out conventional serial or display-driven setup.
4 · Field updates without opening the enclosure
Firmware needed to be updatable in the field by a technician, without breaking the enclosure seal, carrying a laptop, or de-commissioning the device.
System architecture
One device, three interfaces.
The architecture separates the safety-critical sensing and alarm path from the configuration and supervisory paths, so that commissioning and network activity can never compromise detection behaviour.
Sensing path
Refrigerant sensor front end → signal conditioning → embedded measurement and alarm evaluation → relay and signal outputs.
Supervisory path
RS-485 fieldbus presenting the device to the BMS as BACnet MS/TP objects, or as Modbus RTU registers.
Configuration path
NFC memory interface readable and writable by an Android handset — independent of device power state.
Service path
Diagnostics, calibration state, runtime, and manufacturing identity exposed for commissioning and troubleshooting.
Electronics
A sensor-agnostic front end.
The platform was designed to carry more than one sensing technology on a common board and enclosure, so a single product family could address refrigerants, combustibles, and air-quality gases without a redesign per variant.
Firmware
Embedded control, protocol stack, and bootloader.
The embedded firmware carries the measurement and alarm logic, both fieldbus protocol stacks, the calibration and diagnostic model, and a bootloader capable of accepting an image delivered over NFC.
Measurement & alarm
Sensor acquisition, filtering, %LFL scaling against the configured target gas, alarm evaluation, and output control.
BACnet stack
Ported and integrated from the open-source BACnet Stack project — MS/TP data link, object model, standard services, alarming, and device management.
Calibration & diagnostics
Zero/span calibration state and age, runtime accumulation, fault detection, and stored event history for service.
Bootloader
NFC-delivered firmware image handling with validation, so a technician can update a device in place.
Mechanical design
Built for mechanical rooms and plant spaces.
The enclosure had to protect the electronics in HVAC and plant environments while still presenting the sensor to the air being monitored, keeping the NFC target accessible from outside, and allowing straightforward wall mounting and field wiring. Enclosure, mounting, sensor access, and labelling were developed as part of the same product effort as the electronics and firmware.
Software
The tools that make the product usable.
A detector is only as good as the workflow around it. Two applications complete the platform — an Android NFC service app used in the field, and a Windows configuration tool used on the bench and in production.
QVRF ConfigTools — Android / NFC
Reads and writes device configuration over NFC, including on unpowered units. Handles address, baud rate, protocol, target gas, LED behaviour, batch cloning, factory data, and firmware download.
Project commissioning
Site and project management with a per-device checklist — installed, powered/configured, BAS communication verified, alarm and relay tested, commissioning report — plus stored event and diagnostic history.
QVRF-Mate — Windows
PC-side configuration, diagnostics, and service support for bench work, production, and troubleshooting.
Manufacturing data
Serial number, manufacture date, sensor type, and compliance flags written as structured factory data at production time.
Certification & compliance
Verified, not just claimed.
BACnet BTL — Protocol Revision 26
The QVRF BACnet implementation was independently tested and achieved BTL Listing at PR26 — a credential relatively few gas-detection products carry.
UL 60335 alarm-threshold rules
The configuration model enforces a compliance mode in which A2L alarm thresholds are not user-changeable, matching appliance-safety expectations for refrigerant detection.
Certification scope depends on the specific product model, sensor, revision, and listing. BTL Listing applies to the exact QVRF product and revision submitted to the BACnet Testing Laboratories. Marks should only be shown with the approved model and listing information.
Gallery
Product and software.
Development timeline
From requirement to listed product.
Lessons learned
What this product taught.
Port a proven stack, then prove it
Starting from the open-source BACnet Stack and submitting to independent BTL testing produced stronger interoperability than a scratch implementation would have — and the listing is evidence a customer can check.
Design commissioning, not just the device
NFC configuration of unpowered units removed the single biggest source of field friction. The workflow around a product often determines whether it is adopted.
Let compliance shape the data model
Treating "which settings may a user change" as an architectural decision — rather than a UI detail — made the safety requirements enforceable in firmware.
One platform, many variants
A sensor-agnostic front end let one enclosure, one firmware base, and one toolchain serve refrigerant, combustible, and air-quality variants.
Notes on this case study
This page describes publicly documented product capabilities and my own engineering contribution at a high level, rather than confidential design detail. Product names, trademarks, certification marks, and commercial specifications belong to their respective owners.
← Back to the product lineup