A sensor that measures radiofrequency electric fields produces numbers in volts per metre, and those numbers say nothing until they are read next to a threshold. For a personal meter working in the 100 MHz – 3 GHz band — the frequencies of WiFi, mobile telephony, wireless devices — the software that downloads and interprets the data matters as much as the sensing: it has to move the reading from the device to the screen without dedicated drivers and, above all, it has to set it against the right regulatory limits.

The data transfer problem

A portable sensor records a time series of samples in internal memory: for each one, the field intensity and a timestamp. To analyse them you have to get them out. The traditional route is a serial port: the microcontroller exposes a UART, a USB-to-serial converter (typically an FTDI chip such as the FT232R) presents it to the operating system as a virtual COM port, and a desktop program opens the port at 115200 baud and reads the stream.

The cost of this route is installation. Converter drivers, an executable for each operating system, separate updates. For a device meant to be used by anyone — not by a lab technician — every installation step is a point where the user stops.

A serial port inside Chrome

Chrome Apps introduce an alternative. Unlike a web page, a packaged Chrome app can access local hardware, and among the available APIs is chrome.serial: direct access to a serial port from the app’s JavaScript, with no intermediate native binary.

The flow is minimal. You list the ports with chrome.serial.getDevices, open the connection with chrome.serial.connect(path, {bitrate: 115200}, callback), and receive incoming bytes by registering a listener on chrome.serial.onReceive, which delivers data as an ArrayBuffer together with the connectionId. Transmission to the device goes through chrome.serial.send. The FTDI converter stays the same on the hardware side, but on the software side the dependency on a per-platform executable disappears: the app runs wherever Chrome runs.

From there it is application code. The raw stream has to be parsed according to the firmware protocol, rebuilt into a series of (timestamp, V/m) samples, and handled for the rest of its lifecycle: archiving imports with their metadata, filtering by date range, drawing the charts. A library such as D3.js, or the C3.js wrapper built on top of it, is enough to plot the field over time. All of this works offline: downloading and analysing the sensor data needs no network, because the sensor is the only source required.

The critical point: V/m is not a number, it is a contextual measurement

The hard work is not the chart. It is deciding what a value means. Is a 4 V/m peak high or low? The question has no answer without a reference, and the reference is regulatory.

Internationally, the reference levels for public exposure come from the 1998 ICNIRP guidelines. For the electric field they vary with frequency: in the 10–400 MHz range the reference level is 28 V/m, rising at higher frequencies (for example 61 V/m around 2 GHz). In Italy the framework is the framework law 36/2001, implemented for radiofrequencies by the DPCM of 8 July 2003, which sets exposure limits, attention values and quality objectives in the 100 kHz – 300 GHz band. The attention value for environments with prolonged occupancy, in the text then in force, is 6 V/m for the electric field.

There is a second detail that changes the software. ICNIRP does not compare the instantaneous value: it prescribes averaging over a six-minute interval for frequencies between 100 kHz and 10 GHz. A time series of RF fields, then, is not assessed sample by sample but in windows. An honest threshold analysis has to be able to average over the right interval, count exceedances on that basis, and tell an isolated peak apart from a prolonged exposure. Showing the instantaneous maximum next to an averaging threshold is an error of method, not of graphics.

Design implications

It follows that a personal meter is largely a translator from units to meaning. The part that needs care is not the chart rendering but the chain: correct firmware protocol, conversion to V/m consistent with the sensor’s calibration, averaging over the prescribed window, comparison with the relevant regulatory threshold. One applied instance of this chain is the eyEM Data Manager software built by noze for the Polab sensor, described in the project page: https://www.noze.it/en/projects/polab-eyem/.

Choosing a Chrome App has an effect beyond convenience. By removing the driver and the per-platform executable, it moves the complexity from installation to the app’s inspectable JavaScript. Anyone who wants to check how a raw datum becomes a V/m on screen reads that code, not an opaque binary. For a measurement tool, where trust in the number is the whole point, the transparency of the processing chain is not a detail.

Limits

The picture described concerns the transport and interpretation of the datum, not its physical accuracy. A personal meter is not a certified metrological instrument: the sensor’s calibration, its frequency response, the antenna’s isotropy and the measurement uncertainty stay outside the software and determine how much the upstream number can be trusted. The comparison with the attention value, moreover, is indicative: a formal conformity assessment follows standardised measurement procedures that a pocket device does not reproduce. And the dependence on Chrome Apps ties the tool to a platform whose future is not in the hands of those who build it. The software makes the measurement legible; it does not make it a certificate.

Cover image: POLAB eyEM project card (noze).