Industrial Systems · RF · Surveillance Research · Data Preservation

I build things, break things, document things, and collect unreasonable amounts of data.

Most of the projects here started because I ran into a system I didn't completely understand and decided that was now my problem.

That has included industrial automation and conveyor controls, radio systems, surveillance infrastructure, public records, embedded hardware, simulators, mapping tools, and processing millions of scanner recordings because apparently keeping a reasonable amount of data wasn't an option.

I'm mostly interested in systems that already exist in the real world.

What talks to what? What happens when something fails? What gets logged? What gets retained? What does the documentation leave out? Can you reconstruct what happened afterward?

That's usually where the rabbit hole starts.

A lot of my current work revolves around automated material handling and industrial controls.

Things I've been learning, documenting, or screwing around with include:

• MDR and conventional conveyor
• Zero-pressure accumulation
• Metering and carton gapping
• Sortation systems
• Photoeyes and field sensors
• Motor controls and VFDs
• PLC / ladder logic
• AS-Interface
• Industrial networking
• HMI / SCADA
• Fault propagation
• Root-cause troubleshooting
• Machine safety and LOTO

I'm also building a warehouse/controls simulator based around actual conveyor behavior rather than treating the whole building like one magic belt that makes boxes disappear.

The idea is to model the ugly parts too: throughput limits, accumulation, jams, blocked photoeyes, bad motors, controls faults, maintenance, questionable operational decisions, and the cascading consequences of somebody "fixing" the wrong thing.

Boxes moving around is the easy part.

Figuring out why they stopped moving is more interesting.

I've been screwing around with radios for a long time.

Current projects involve:

• DMR
• Conventional radio
• Public-safety monitoring
• SDR
• Radio system design
• Talkgroup and subscriber analysis
• Scanner recording
• RF metadata
• Infrastructure mapping
• Building searchable RF datasets

I have an absurd amount of scanner audio.

Rather than accepting that I now own a gigantic pile of seven-second audio files that no human being could reasonably inspect, I've been working on ways to transcribe, index, tag, correlate, and search them.

The eventual goal is being able to treat recorded RF activity like a dataset instead of a folder full of mystery WAV files.

I spend a fair amount of time looking into surveillance infrastructure, especially systems deployed in public space.

That has included:

• ALPR/LPR systems
• Camera networks
• Shared surveillance networks
• Public-safety data platforms
• Vehicle and device tracking
• Sensor fusion
• Inter-agency data sharing
• Retention policies
• Access controls

A lot of this research comes from public records.

Contracts, invoices, policies, deployment records, maps, emails, manuals, procurement documents — whatever fills in another piece of the system.

I'm less interested in what the sales brochure says the technology does than what was actually purchased, where it was installed, who can access it, where the data goes, and how long it sticks around.

Policy, marketing, and technical capability are not always the same thing.

I archive shit.

A lot of shit.

RF recordings, public records, manuals, government documents, maps, metadata, web pages, datasets, research material, and anything else I think has a decent chance of disappearing six months before I need it.

Storage is cheap.

Realizing the only copy of some obscure technical document disappeared three years ago is annoying.

The harder problem is making the resulting pile useful. A directory containing 1.5 million files technically qualifies as an archive, but it isn't a particularly good one.

So a lot of my work eventually turns into indexing, metadata extraction, search, attribution, deduplication, and figuring out how to make something I collected today still understandable years from now.

Most of my projects are some mixture of software, hardware, and research that got sufficiently out of hand to require software and hardware.

Software

Python scripts, parsers, automation, data-processing pipelines, web apps, search tools, simulators, mapping utilities, and whatever small utility saves me from doing the same annoying thing 4,000 times.

Hardware

Radios, SDRs, ESP-class boards, Raspberry Pis, sensors, antennas, embedded devices, and assorted electronics that seemed like a good idea when I ordered them...

Research Infrastructure

Public-records archives, RF datasets, maps, geospatial overlays, documentation, archival workflows, and tools for turning piles of unrelated information into slightly more organized piles of related information.

• Conveyor controls and automated material handling
• Warehouse / controls simulation
• DMR, P25, and public-safety radio
• Distributed surveillance systems
• Public-records-driven infrastructure mapping
• Passive sensing
• Data fusion and de-anonymization
• Digital preservation
• Figuring out what to do when a dataset becomes too large to casually grep anymore

This list is subject to change whenever I see something interesting and make the mistake of asking "how does that work?"

I don't really have a stack.

I use whatever gets the thing to do a thing.

Observe the system. Preserve the evidence. Figure out what the hell it's actually doing.

The projects I enjoy most tend to have at least one of the following:

Incomplete documentation, an unreasonable amount of data, an opaque system, conflicting explanations, weird behavior nobody bothered documenting, or a perfectly reasonable explanation that stops being reasonable the second you look closely at it.

Those are usually the fun ones.