Baseline Sensing

Edge software and sensor systems, from firmware to the browser.

Ethan Ross. Contract engineering for small and mid-sized companies. Based in Ottawa.

About me

I spent four years at Area X.O, Invest Ottawa's connected and automated vehicle test facility, as the engineer small and mid-sized companies worked with when they brought a system in for evaluation. I built the service that opened and closed live rail-crossing barriers during field trials, logging every state change to PostgreSQL for the audit trail and publishing crossing state to MQTT for approaching vehicles. I maintained vehicle telemetry across two transports, C-V2X within range of a roadside unit and 5G beyond it, on a single message contract so that handover remained invisible to everything downstream. Where a pedestrian-detection camera carried roughly two seconds of latency, I staged the alert into an early low-confidence warning followed by a confirmed one, recovering reaction time the link itself could not provide.

Earlier, on a six-month mechanical engineering contract, I built a robotic arm end to end, covering the mechanism, the electronics, and the stand that doubled as the enclosure for the boards, with drawings released to a machine shop for fabrication. The arm reproduced handwriting live from one tablet to another, which made the control problem one of continuous inverse kinematics, solving for the joint angles that placed the stylus where a moving stroke required it.

Selected work

Transport Canada connected-vehicle safety program. Ran on-track testing across 18 scenarios and 4 V2X safety applications. Wrote 3 formal reports as regulatory deliverables, and I am the author of the data-analysis chapter of a 227-page one. The proposals behind two competitively awarded rounds of that funding were mine.
Roadside edge-computer tuning. Worked on a partner's vehicle-queue detection model with staged vehicles on the track until detection confidence went from roughly 50-60% to 80-90%, the figure they went on to market.
QNX Sensor Framework driver. Wrote an external sensor driver in C++ on real hardware, and found 3 defects in the framework doing it.

The bench rig. A Teensy emulates the sensor over I²C so the driver can be exercised against known values.

The same driver feeding a live in-vehicle display, running on QNX.
Air-quality signals in the COVESA Vehicle Signal Specification. I wrote the proposal that added 14 signals, 3 units and a new quantity to the standard. A maintainer merged it in August 2026.
Cloud video relay for an intersection camera. Moving stream duplication off the camera's onboard processor took end-to-end latency from roughly two seconds to under 200 milliseconds. I found the two bottlenecks before choosing where to put the work, which is most of why it worked.
Automated pre-run and post-run gates for autonomous test campaigns, which stopped bad runs while the crew was still on track rather than in analysis days later.

Projects

megaplayA local music library manager for Linux, driven by a gesture on the headphones: volume down then up inside two seconds. A double-click on the headset and a raw key binding were both tried first and are dead ends, and the two-second window comes from measured timings rather than a guess. I am reworking it now so the gesture is device agnostic instead of tied to one set of headphones. Whisper and a tool-use layer behind it.

QNX air-quality sensorThe driver from Selected work, as source. C++ against the QNX Sensor Framework, cross-compiled and running on a Raspberry Pi Compute Module 4.

My agent signed its own permission slipAn essay I wrote on AI gating to prevent unwanted behaviour. A month of giving a coding agent real publishing authority, and where the gates had to sit.

Contact

ethan@baselinesensing.ca

Based in Ottawa. Remote by default, on site when the work needs hands.

Write and I will reply the same day, usually with questions. If it looks like a fit we talk for half an hour and I send you a written scope and a price. Four things make that first email useful, and rough answers are fine. Copy these into your message and answer under each one.

1. What is it?(a board, a device already in the field, a sensor that will not read right, a whole system, or something you need built from scratch)

2. What is it doing that it should not?(fails every time, fails now and then, works on the bench but not in the field, never worked, or nothing is broken and you need something new)

3. What have you already tried, and what did that tell you?(reflashed it, swapped the part, scoped the bus, had someone else look, nothing yet)

4. When do you need it working by?(this week, this month, this quarter, no date yet)