Most software developers work at one layer of the stack. Frontend or backend. Mobile or web. Cloud or embedded. When you are the sole software lead for a scientific instrumentation company, you work at all of them — because nobody else is going to.
I have been building software for Dualem for years. Dualem manufactures electromagnetic induction instruments — precision sensors used around the world for soil mapping, environmental assessment, agriculture, archaeology, and subsurface exploration. The instruments are carried across fields and towed behind vehicles, measuring the electrical conductivity of the ground beneath them. The data they produce helps researchers and engineers understand what is happening underground without digging.
My job is everything between the raw sensor data and the human being who needs to understand it.
The Android app#
The first thing I built was the Android companion app. A surveyor in a field needs to pair their phone or tablet to the Dualem instrument over Bluetooth, see live sensor readings as they walk or drive a survey line, visualize the data on a map in real time, and export the results when they are done.
That sounds straightforward until you start building it. The instrument streams electromagnetic conductivity data across multiple sensor arrays — each measuring at different depths below the surface — alongside GPS coordinates, instrument orientation, temperature, and battery status. All of it arrives as a continuous stream of NMEA-style sentences over a Bluetooth serial connection. The app needs to parse every sentence type, validate checksums, detect record boundaries, and display the results on live instrument gauges and a map — without dropping data and without draining the battery.
The app runs as a foreground service so data collection continues with the screen off. It supports both Bluetooth and WiFi connectivity. The gauge system is configurable — different instruments have different sensor arrays, and the display adapts to what is connected. The map renders survey paths in real time with color-coded markers that give the surveyor immediate visual feedback on what the ground looks like beneath them.
The desktop app#
The Android app handles data collection in the field. But many surveyors work from laptops — running longer surveys, processing larger datasets, and needing the larger screen for detailed analysis. Laptops run Windows, macOS, and Linux. That meant building a cross-platform desktop application.
I built it in Rust with Tauri — a framework that wraps a native webview around a Rust backend. The frontend is React with MapLibre GL for mapping. The backend handles Bluetooth serial communication with platform-specific implementations for each operating system, because Bluetooth SPP works differently on Windows, macOS, and Linux.
The desktop app connects to the same instruments, parses the same data stream, and provides the same real-time visualization — but on a platform that also supports the heavier analysis workflows that field tablets cannot handle comfortably.
Laptops do not have onboard GPS. In the field, surveyors use RTK receivers — expensive, dedicated GPS hardware. For development and testing, I needed a way to feed GPS data to the desktop app without hauling an RTK setup to my desk. So I built GPS NMEA Tether — an Android app that turns a phone into a Bluetooth GPS source, streaming standard NMEA position sentences to any device that accepts them. It started as a testing tool. It turned into a polished app with a live instrument dashboard, nine languages, and enough utility that it stands on its own.
The web platform#
Field data needs to go somewhere after the survey. I built a web mapping platform where teams can upload survey data, visualize it on interactive maps, and manage their projects. The stack is React and Node.js with MapLibre GL for rendering and Firebase for authentication and storage.
The web platform closes the loop between field collection and office analysis — the same data that arrived from the instrument in real time can be reviewed, annotated, and shared from a browser.
The website#
I also designed and built the Dualem corporate website — presenting the product line, technical specifications, and documentation to the researchers, engineers, and procurement teams who evaluate and purchase the instruments. The site had not been modernized in years, and the brand needed a web presence that matched the precision of the instruments themselves.
One developer, every layer#
The Dualem work spans Android native development, cross-platform desktop applications in Rust, full-stack web development, and corporate web design. That range is unusual for a single developer. It exists because the company needed someone who could own the entire software surface — and because I find the challenge of working across every layer of the stack more interesting than specializing in one.
Scientific instrumentation is a domain where the software matters as much as the hardware. The best sensor in the world is useless if the surveyor cannot connect to it, cannot see the data, and cannot get it to the people who need to analyze it. That is the problem I solve at Dualem.
