INTERESTING PROJECTS

Acorns Fired!
A self-hosted archive and player for scanner radio call recordings.

Overview
Acorns Fired! is a self-hosted web application for organizing and reviewing radio call recordings captured through sdrtrunk, an open-source software-defined radio decoder. sdrtrunk is great at capturing and decoding live radio traffic, but it leaves behind a folder full of individual audio files — useful to the software, not so useful to a person trying to find a specific call later. Acorns Fired! turns that raw output into something searchable and easy to browse.

What it does
Acorns Fired! automatically indexes new call recordings as they come in, logging the details that matter most: date, time, and talkgroup. The web interface lets you search that history and play back any call directly in the browser, without having to dig through a folder of audio files.
The call list is kept intentionally simple, showing just what/when/who rather than technical metadata that's rarely useful day to day. Managing and labeling talkgroups is handled separately, keeping the main browsing experience clean and focused on finding and listening to calls.
Calls can also be transcribed to text automatically, using speech-to-text models that run entirely on-device rather than relying on any cloud service. This keeps the transcription private and fast, and makes it possible to skim or search a call's content without listening to the audio first. Transcription can be turned on or off per talkgroup, so it's only applied where it's actually useful.

Why I built it
This started as a practical need: a way to go back and find a specific piece of radio traffic without remembering an exact timestamp or scrolling through an unsorted folder of recordings. It's become an ongoing project touching a few areas I enjoy working in — software defined radio, public safety, file monitoring, audio handling, and web application design — built around a tool I actually use.

Centralized control system for Kuando Busylights across a 10-workstation call center.
Node.js · HTTP · UC Integration

Background:
A call center with 10 workstations, each equipped with a Kuando Busylight to show agent availability. Agents used three different unified-communications applications, so the light needed to reflect status across all of them.

The problem:
The standard Busylight software relied on automatic presence detection tied to specific UC clients. It couldn't integrate with all three applications at once, and its automatic presence tools conflicted with each other, producing incorrect and inconsistent status across the workstations.

Approach:
The Busylight hardware supported native HTTP control locally from its host workstation, independent of the manufacturer's presence software. I built a Node.js broker on each workstation that listened for commands from a central server and set the light's color over HTTP.
This moved presence logic to a layer that could account for all three UC applications, rather than depending on any single client's detection.

Outcome
•Platform-agnostic: no longer tied to one UC vendor's presence integration.

•Extensible: any system reaching the central server can set light state.

•Centralized control across all 10 workstations, with consistent status.

A full telephony migration from Verizon One Talk to Microsoft Teams Phone, driven by the need to eliminate excessive costs, modernize communication tools, and align the phone system with how staff actually work in a post-pandemic environment.

The organization was spending over $3,000 per month on Verizon One Talk and associated mobile services. Following the shift to remote and hybrid work during the pandemic, the vast majority of desk phones sat idle or unplugged — yet every device continued to incur monthly charges. The One Talk softphone saw near-zero adoption, and the overall service was drastically underutilized. The existing hardware consisted of Verizon-branded Yealink phones running locked Verizon firmware, limiting flexibility and tying the organization to a single carrier ecosystem.

Meanwhile, staff were already deeply embedded in the Microsoft 365 platform, using Teams daily for chat and meetings. The phone system was the last piece that hadn't caught up with reality.

The decision was made to migrate entirely off Verizon One Talk and onto Microsoft Teams Phone with a Microsoft Calling Plan. All phone numbers were ported away from Verizon to Microsoft, cutting the dependency on the carrier's telephony platform.

The rollout started with a Teams client-only deployment. All staff — excluding frontline workers — were licensed for Teams Phone, giving them the ability to make and receive calls directly from the Teams desktop and mobile apps. For most users, this was the only solution needed.

A solution was still needed for in-person shared workspaces such as front desks and common areas, where a physical handset is practical. Microsoft's SIP Gateway feature supports registering compatible Yealink hardware with Teams, but the existing phones were locked with proprietary Verizon firmware that prevented this.

The Verizon firmware lock was bypassed by jailbreaking the Yealink phones and flashing them with the factory SIP firmware. Once restored to standard SIP operation, the phones were registered with Microsoft's SIP Gateway, upgraded to Teams firmware, and joined to the Teams environment as SIP phone devices. This eliminated the need to purchase new hardware while giving shared spaces full Teams calling capability.

To further extend the platform's capabilities, 10DLC registration was completed, enabling SMS messaging for all Teams Phone users. This added a communication channel that staff had previously lacked, allowing text-based outreach and responses directly from their Teams-assigned numbers.

Monthly telecom costs dropped from over $3,000 to under $700 — a reduction of more than 75%

Zero new hardware purchased — existing Yealink phones were repurposed through firmware recovery

Unified communications platform — voice, chat, meetings, and SMS all consolidated into Teams

Improved user satisfaction — staff now use a single, familiar application for all communication

Eliminated waste — no more monthly charges for idle, unplugged desk phones

Scope:
Hundreds of Aruba switches and thousands of access points
100+ school and administrative buildings across the ISD and local districts
A complex network environment with over 1,000 VLANs

The first phase of the deployment focused on TACACS+ for management-plane authentication. ClearPass was configured as the TACACS+ server for all switches and access points, enabling centralized control over administrative access. By integrating ClearPass with Active Directory, admin accounts are automatically provisioned — eliminating the need to maintain local credentials on individual devices and ensuring that access rights stay in sync with directory group memberships.

ClearPass was deployed to automatically identify and classify devices connecting to wired switch ports. Using profiling and policy enforcement, ClearPass dynamically assigns the correct VLAN and port configuration based on device type. In a network with over 1,000 VLANs, this automation dramatically reduced the administrative burden of manual port provisioning and minimized the risk of misconfiguration across the district's many locations.

Device certificates issued through Active Directory Certificate Services were used to authenticate endpoints via 802.1X. This approach provides strong, credential-free authentication for domain-joined devices and ensures that only trusted, managed endpoints gain access to protected network resources.

MFA was integrated into the ClearPass administrative authentication workflow, adding a second layer of verification for any management-level action on switches and access points. Every network device across the ISD and its local districts is secured behind MFA, significantly reducing the risk of unauthorized administrative access.

ClearPass was integrated with Palo Alto Networks firewalls to share identity context. As users and devices authenticate through ClearPass, identity and role information is passed to Palo Alto, enabling user-aware firewall policies. This integration provides consistent security enforcement from the network edge through the firewall, tying access control and threat prevention to verified identities.

A local school district was running an on-prem Cisco ASA paired with a WebSense URL filter — a stack that was aging, hard to modernize, and increasingly outflanked by students who'd figured out how to circumvent it and access harmful content. Worse, the underlying network was flat. A single VLAN spanned all seven district locations, which meant any modernization effort that depended on segmentation, identity, or differentiated traffic policy was effectively blocked at the architecture layer.

The plan: Migrate off the ASA + WebSense stack onto a Palo Alto firewall hosted at Ingham ISD, reachable across the StarNet county-wide metro ethernet service. The hosted model was attractive — Ingham ISD already operated the platform, the metro ethernet existed, and the migration would let Mason consume modern firewalling and URL filtering as a managed service rather than a local hardware refresh.

The catch: A flat network can't safely consume a hosted firewall sitting across a metro ethernet link. Before the migration could happen, Mason's network had to be redesigned from the ground up.

My role: I was the primary technical lead for the entire effort — the network redesign, the firewall migration, the wireless authentication work, and all the coordination with Ingham ISD. This was the project I was finishing as I prepared to move from Mason to Ingham ISD myself.

What I built: The network redesign: I devised a master network plan replacing the flat single-VLAN topology with roughly 30 segmented VLANs across the district. Traffic was separated by location, by endpoint type, by user type, and by wired versus wireless. The redesign gave the district a foundation it had never had before — and a posture compatible with the routed, policy-driven environment Ingham was bringing to the table.

The firewall migration: With the network ready, traffic was redirected across the StarNet metro ethernet to the Palo Alto firewall hosted at Ingham ISD. URL filtering was applied per-IP, relying on static IP assignments to control which traffic was filtered — a technical constraint of the platform at the time. Within that constraint, only student devices were subject to URL filtering; staff sessions were unfiltered, because the per-IP design couldn't differentiate users on shared infrastructure.
The wireless authentication layer: With segmentation in place, I deployed a RADIUS-backed wireless solution that authenticated corporate, staff, and student devices into appropriate VLANs based on identity. What had been an open or PSK-based wireless environment became an identity-aware one, with each device class landing in the segment its policy was designed for.
Outcome: The migration was successful. The student circumvention problem was solved at the architecture level — students no longer had a flat path to manipulate. Mason gained a modern, hosted firewall posture without buying or maintaining the hardware locally. The network redesign became the foundation everything else built on, and the project was one of the first real production uses of StarNet, the county-wide metro ethernet service that had been built but largely under-utilized until that point.

A local school district had 7 locations, each with its own digital phone system and analog trunks. The platform was a WINN Walker system from a company called WINN — proprietary hardware, proprietary CLI, and a serial console as the only real management interface. Because the system could only be administered by physically plugging into the console at each site, every change request — moves, adds, changes, troubleshooting, anything — was routed to an external service partner who would dispatch a technician on-site. Small changes carried a full service visit's worth of cost. The arrangement had been in place for years and was treated as just how things worked.

I'd inherited support for the phone systems and quickly recognized that the bottleneck wasn't the hardware — it was the access method. If I could get to the serial console from the head office, I could administer the systems myself remotely.

I owned this project end to end — identified the problem, designed the solution, sourced and configured the hardware, deployed it across all seven locations, and took over routine PBX administration internally from that point forward.

I deployed serial-to-Ethernet adapters at each site, exposing each PBX's RS-232 console as a telnet endpoint reachable from the central office. From a single workstation, I could now reach any phone system on the network and run the same proprietary CLI the vendor had been driving on-site. Moves, adds, and changes that used to be tickets became five-minute tasks.

The district stopped routing routine PBX work to the external partner. Every change request that didn't require physical hardware work was now handled internally, with no service visit and no invoice. The shift was embraced — leadership liked the savings, and the existing vendor relationship was preserved for the work that genuinely required hands on hardware.

A server environment was aging and falling out of vendor support, and a new physical server had just been acquired for a specific upcoming project. The plan was to install the workload directly on the new hardware, the way it had always been done.

I saw a different option. By installing free ESXi on the new server instead of running the workload bare-metal, we could host the original project and additional VMs on the same hardware — at zero incremental cost. It was a chance to introduce virtualization to the district without asking for a dollar of new budget.

I built the case and the plan, presented it to leadership, and contributed to the deployment alongside a senior technician who took architectural lead. It was an early-career project for me, and I learned a lot from being in the room while it came together.


The plan was successful. The host eventually grew to about fifteen VMs, and the district's direction changed: from that point on, virtualization was the default. Every server build after this one was virtual, and the deployment became the proof point that justified the larger shared-storage, multi-host environment that followed.

Two things stuck with me.

First, the cheapest infrastructure improvements are often the ones nobody asked for — they come from spotting an opportunity inside a budget that's already approved.

Second, getting buy-in for a quiet, low-risk pilot is a good way to change the direction of an organization without ever having to fight for it.

A local school district was running on Novell — eDirectory for identity, GroupWise for mail and calendaring, and ZENworks for endpoint management.

It was a stable environment that had served the district well for years, but the platform was aging, the talent pool of Novell-fluent administrators was shrinking, and the modern Microsoft stack offered capabilities the district couldn't match on Novell. A migration was overdue.

I led the project end to end as a full-time IT analyst — scoping, architecture, execution, and rollout.

Two thousand users across staff and students, three major Novell platforms to retire, three Microsoft platforms to stand up in their place.

eDirectory → Active Directory
GroupWise → Exchange Online
ZENworks → SCCM

The hardest problem wasn't technical. It was getting users to buy in. Novell was familiar. People had spent years building muscle memory in GroupWise. The technology lift was real but solvable; the human lift was where projects like this actually succeed or fail.

I leaned hard into demos and training before, during, and after the cutover, so users saw the new tools working before they had to live in them. Just as importantly, I built a grace period into the rollout that let users migrate their own GroupWise data into Exchange on their own timeline rather than forcing a hard cutover. That single decision did more to defuse resistance than anything else — people felt in control of the change instead of subject to it.

The outcome was a fully modernized identity, mail, and endpoint management environment, delivered without a revolt. The new stack became the foundation for everything that came after — directory-integrated wireless, modern endpoint imaging, cloud-based collaboration, and eventually the network segmentation and 802.1x work that followed.

This was the first project where I owned a major migration end to end, and the lesson stuck: technology transitions live or die on whether users feel respected through the process. I've designed every migration since with that in mind.