Work
Four projects, in detail
Each project is described by problem, approach, outcome, and stack, with the technical detail left in.
The instrument console below is current Pebble Logic work, with the client name withheld under a confidentiality agreement. The other three were performed by the principal as an employee, before the firm was founded. If you are replacing an instrument's acquisition path, study 01 is the closest match.
Case study 01/Regulated instrument/2026, current
Replacing a closed-protocol instrument acquisition path, under FDA documentation requirements
- Problem
- A medical device company with a federally funded research program was acquiring from its instrument through a closed third-party recording application and its interface module, and needed a Windows console application to replace that path. The software had to acquire and display a live pressure waveform, and it had to be built and documented to a standard that would survive an FDA premarket submission. The client had no in-house software engineering team, and the incumbent path ran through a vendor's closed, proprietary protocol.
- Approach
- Started at the hardware rather than the application. A formal trade study evaluated candidate data acquisition devices against 18 hard and 22 soft requirements, disqualifying options on isolation, resolution, and API openness. The incumbent closed-protocol path was disqualified and replaced with an architecture running from a MEMS pressure sensor through a dedicated signal conditioning unit into a LabJack T7, reaching the application through the open LJM library. A separate test rig injects synthetic waveforms into the T7 analog input from a second LabJack, a T4 driven by the development laptop, so acquisition and display are verified against known signals independently of the physical sensor. The software lifecycle documentation is written in parallel with the code rather than retroactively: development plan, architecture description, documentation-level plan, and a third-party dependency risk analysis that identified a versioned vendor data file as the highest-risk silent dependency in the system.
- Outcome
- A Windows desktop application replacing that acquisition path, with a signal chain verified against injected reference waveforms. The lifecycle documentation package supporting the client's regulatory submission is contracted and in progress. All software, including interaction design, delivered by the principal against a fixed not-to-exceed budget.
- Stack
- Python, PySide6/Qt, LabJack T7 and T4 with the LJM library, Windows, Git
Case study 02/Instrumentation/2019 to 2021
Real-time biosignal acquisition and classification over BLE
- Problem
- A physical therapy product needed to stream muscle activity from two wireless sensors simultaneously and tell a therapist, in real time, how many repetitions and sets a patient had completed. Raw electromyography is noisy and its signature changes substantially from one exercise to the next, so a fixed threshold does not work.
- Approach
- Built a mobile application maintaining simultaneous Bluetooth Low Energy connections to two sensors with live streaming. Wrote the signal-processing and classification logic to extract repetition and set boundaries from raw EMG across differing exercise signatures, rather than relying on a single threshold.
- Outcome
- Therapists could guide patients through workouts with live, automatic repetition and set counting from wireless sensors.
- Stack
- React Native, TypeScript, BLE, signal processing, machine learning
Case study 03/Energy/2019 to 2021
EV charging platform built from scratch, including the protocol server
- Problem
- An IoT product company needed a complete electric vehicle charging platform capable of driving third-party charging hardware it did not manufacture. Interoperating with other vendors' chargers meant implementing the open protocol they speak, which nobody on the team had worked with.
- Approach
- Researched the Open Charge Point Protocol and wrote an OCPP 1.6 server from scratch, then built the surrounding platform: a REST API, a relational data model for sessions and users, and an operator-facing web frontend. Implemented RFID authorization so drivers could start a session at the charger, usage tracking for billing and reporting, and charge-complete notification. Delivered as sole engineer on the product.
- Outcome
- A working charging platform interoperating with third-party hardware, built end to end by one engineer.
- Stack
- Python, Flask, PostgreSQL, React, OCPP 1.6
Case study 04/Energy/2017 to 2019
Commercial solar monitoring platform rebuilt for scale
- Problem
- A solar hardware manufacturer's monitoring platform for commercial installations had stopped keeping up. Dashboard queries spanning months of history took minutes to return, and the ingest path could not absorb the reporting volume from a fleet of more than 40,000 installations. Roughly 500 million rows and 100 GB arrived each month.
- Approach
- Interviewed customers, the support team, and the hardware engineers before writing code, to learn how the existing system was actually used rather than how it was designed to be used. Those conversations drove the central architectural decision: split storage by access pattern rather than scaling a single database. Recent data went into partitioned PostgreSQL, full history into a columnar warehouse, and an API layer routed each query to the right store based on its date range. Rebuilt the platform including the frontend, while keeping the legacy system running in parallel for a subset of customers through the transition. Added anomaly detection to flag underperforming installations and alert their owners.
- Outcome
- Sustained ingest above 9,000 database inserts per second. Dashboard queries across months of history dropped from multiple minutes to under two seconds. Customers were notified automatically when an installation underperformed.
- Stack
- Python, Django, Vue.js, PostgreSQL with partitioning, Redshift, AWS