# Chapters.bio
> A professional life, told in chapters.
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### Testimonials
URL: https://chapters.bio/testimonials-meta/
Last updated: 2026-07-11T03:19:49.000Z
_No content available._
## Posts
### Engineering Live Streaming
URL: https://chapters.bio/engineering-a-streaming-platform/
Last updated: 2026-09-10T17:58:58.000Z
A client has hired me to build a streaming platform where viewers will be able to subscribe, watch live programming, and return to available recordings afterward. Think of a Netflix-style service built around live events and on-demand viewing, with the operational tools needed to prepare and manage those broadcasts.

My responsibility covers the engineering, interface design, and code. I’m translating the client’s requirements into a connected service, from the viewing experience to the systems that prepare and deliver each event.

This chapter is dated to the project’s August 10, 2026 kickoff. The accompanying mockups show later development concepts. Design and functionality may change; displayed content and data are illustrative. Client branding has been removed for this article.

AWS provides the cloud infrastructure behind the build. To explain how I’m approaching the event setup, I think of a stack of plates.

Each stack represents one live event. Each plate represents a layer of its setup, such as how the live feed arrives, where it needs to go, or how the event is recorded. Now imagine each plate is available in several colors. Choosing a color represents choosing how that particular layer should behave.

Putting an event together means selecting the right combination of plates and colors for that production. The next event gets its own combination. Some choices may carry over, while others change with the requirements of the show.

That flexibility is central to the engineering. In production, every event has its own requirements. The platform needs to accommodate those differences while keeping the setup understandable to the person operating it. The plates also have to work together: changing one choice can affect what is needed elsewhere in the stack.

My production experience helps me think through those relationships. I’m considering how an event is prepared, what needs to be checked before going live, what information operators need during the broadcast, and what happens to the recording afterward. The interface needs to make those decisions manageable without requiring the operator to understand every AWS service underneath them.

![Anonymized development mockup of a live-event operator workspace with video, audio meters and illustrative delivery information.](https://chapters.bio/content/images/2026/09/monitor-1.png)

![Anonymized development mockup of subscription replay viewing with playback controls and membership access information.](https://chapters.bio/content/images/2026/09/replay-1.png)

Active development previews: proposed live-event monitoring and subscriber replay viewing. Illustrative content and data; design and functionality may change.

AI is a significant part of my development process. I’m using it to help write and review code, explore implementation approaches, and work through technical problems. I remain responsible for the architecture, design decisions, and verification of the resulting system.

My target is to bring a build I estimate would otherwise take more than a year down to roughly three months. AI accelerates the implementation and gives me more opportunities to test and refine an approach. The resulting workflows still need to be checked, including whether the event configuration produces the intended viewing experience.

The platform remains in development, and I’m keeping the client’s identity and detailed commercial plans private. The assignment is to bring that configurable production system together with a straightforward subscription streaming service.

For the production team, the choices behind each event need to be visible and manageable. For the viewer, that work should resolve into something simple: finding the program, opening it, and watching.
### Building the Network Behind AI NOW Fresno
URL: https://chapters.bio/building-network-behind-ai-now-fresno/
Last updated: 2026-07-24T21:55:26.000Z
On July 22 and 23, I was in Fresno with Streaming Media Live to build and run the temporary internet system for AI NOW, hosted by the California Association of REALTORS®.

This was a hands-on AI conference expecting approximately 120 attendees. Because people would be working directly with online AI tools—not simply checking email—we planned around roughly 6 megabits per second of download capacity per attendee. That put the working requirement at approximately 720 Mbps before accounting for presenters, production equipment, multiple devices, or additional headroom.

The entire network was my responsibility—from deploying the Starlink connections and building five individual Wi-Fi setups to monitoring the system and helping people stay connected during the program.

## Building five independent networks

Setup began on July 22\. I prepared five active Starlink connections, each supporting its own Wi-Fi setup, so coverage and traffic could be distributed across the venue rather than depending on one shared connection. Together, the five connections provided approximately 1,200 Mbps—or 1.2 Gbps—of aggregate download capacity.

A sixth Starlink remained ready as a reserve. It was not needed during the event, but having it available was part of the design: live-event redundancy is most useful when it is prepared before a problem occurs.

The physical work included placing and checking the satellite terminals, routing cabling, preparing power, configuring the wireless networks, and confirming that each area could connect as intended. The system needed to be understandable enough to operate quickly while still giving me separate paths to monitor and troubleshoot.

## Supporting the room, not just the equipment

On July 23, the work shifted from installation to active support. I monitored the connections as the room filled, helped people get connected, and handled the smaller technical needs that naturally appear during a live event.

At its peak, the system supported approximately 165 connected devices—more devices than the original 120-person attendance estimate. One attendee might have both a laptop and a phone connected, while presenters and production equipment added their own demand. The network had become shared event infrastructure, not simply a connection for one production workstation or presenter’s laptop.

The five separate Wi-Fi setups also gave the deployment a practical advantage: demand could be spread across multiple Starlink connections instead of concentrating every device on a single path. The sixth unit remained available in reserve throughout the event.

![Thomas Fraley standing in front of the blue AI NOW event backdrop in Fresno](https://chapters.bio/content/images/2026/07/02-thomas-fraley-ai-now-fresno-1.jpg)

![Portable generator, fuel containers, and bundled network cabling outside the Fresno event venue](https://chapters.bio/content/images/2026/07/03-ai-now-fresno-backup-power-cabling-1.jpg)

![Wide view of the AI NOW Fresno audience seated with laptops and mobile devices during the program](https://chapters.bio/content/images/2026/07/05-ai-now-fresno-full-room-video-frame-1.jpg)

![AI NOW Fresno attendees arriving at classroom-style tables under purple venue lighting](https://chapters.bio/content/images/2026/07/04-ai-now-fresno-attendee-arrival-1.jpg)

From setup through the live program: the network lead, temporary power and cabling, attendee arrival, and the connected room in operation.

## A temporary network with a clear purpose

This was not a permanent venue installation. It was a temporary network designed for a specific production, assembled on-site and removed when the job was complete. That changes the engineering priorities.

The equipment has to travel well. Setup needs to be repeatable. Cabling and power must fit the venue without disrupting other departments. Most importantly, the system has to remain manageable while the event is already in progress.

That is the part of live network work I continue to value: the technology matters, but the real job is creating an environment where everyone else can concentrate on their own work. For AI NOW Fresno, that meant building the connections, staying available throughout the event, and giving the room a network it could simply use.
### Rebecca Corrado
URL: https://chapters.bio/testimonials/rebecca-corrado/
Last updated: 2026-07-10T20:53:30.000Z
Not only does he know content and is very creative; he also has the soft skills that many lack. He is very dedicated to his work and continues to stay on top of new technologies.
### Evy Zavala
URL: https://chapters.bio/testimonials/evy-zavala/
Last updated: 2026-07-10T20:53:29.000Z
Thomas is very knowledgeable and meticulous in his field of expertise. He is very diligent, a pleasure to work with, and knows how to get the best results!
### Alicia Dipietrantonio
URL: https://chapters.bio/testimonials/alicia-dipietrantonio/
Last updated: 2026-07-10T20:53:29.000Z
Thomas is very knowledgeable in his field. He is an excellent problem solver. If there is something that he doesn’t know, he will find a way to acquire the knowledge needed to get the task done.
### Building a Broadcast Network for The Circle
URL: https://chapters.bio/building-a-broadcast-network-for-the-circle/
Last updated: 2026-07-12T01:22:20.000Z
In June 2026, I was brought in as a Transmission and Network Engineer to support a 72-hour livestream produced by The Circle. The creator experience led into the Knockout Queens boxing event and was already underway when the production needed an immediate connectivity recovery.

The estate offered impressive spaces for creators, but it had not been designed to carry a continuous, multi-platform broadcast. My job was to understand the existing workflow, restore dependable transmission, and build enough redundancy for the production to continue changing throughout the weekend.

## Converting the estate into a temporary facility

There was no time for a conventional infrastructure build. I first separated the creative requirements from the connectivity paths they depended on, then designed a temporary network around independent services rather than trusting a single venue connection.

![Pool and palm-lined outdoor area used during The Circle creator event](https://chapters.bio/content/images/2026/07/estate-pool.jpg)

![The Circle event sign installed on the estate lawn](https://chapters.bio/content/images/2026/07/the-circle-sign.jpeg)

![Poolside production area prepared for The Circle's multi-day livestream](https://chapters.bio/content/images/2026/07/estate-production-area.jpeg)

The Circle's public creator experience occupied several outdoor areas across the estate.

## Building independent transmission paths

The transmission workflow used a LiveU LU800 with an LU300 supporting the live feeds. A Peplink router aggregated additional cellular connections, while three Starlink terminals added bandwidth and path diversity. Together, those systems gave the team alternatives when any one service changed or became congested.

The network supported simultaneous distribution to Kick, TikTok Live, and TrillerTV. I monitored the available paths and adjusted the temporary infrastructure as camera positions, schedules, and production requirements evolved.

![Live transmission equipment and monitoring computers operating inside the estate](https://chapters.bio/content/images/2026/07/transmission-workspace.jpeg)

![Multiple Starlink terminals placed across the estate lawn](https://chapters.bio/content/images/2026/07/starlink-terminals.jpeg)

![Temporary network and transmission equipment connected beside a window](https://chapters.bio/content/images/2026/07/network-equipment.jpeg)

The temporary network combined indoor transmission equipment with several independent outdoor paths.

## Supporting the production without changing roles

The production used Sony cameras alongside OBSBOT Tail 2 and Tail Air PTZ systems. My role remained transmission and network engineering—not technical direction—but the engineering work put me in a useful position to recommend broadcast workflows and operating practices as new creative ideas emerged.

By the end of the event, the estate was functioning as a temporary broadcast facility capable of supporting a multi-day creator production. The project reinforced that resilient transmission is not only about adding bandwidth. It depends on independent paths, continuous monitoring, and an architecture flexible enough to change with the show.
### From Site Survey to Reliable Webcast Reception
URL: https://chapters.bio/from-site-survey-to-reliable-webcast-reception/
Last updated: 2026-07-13T16:49:27.000Z
A national webcast dinner on February 19, 2026 depended on connectivity inside a venue that was not designed as a broadcast facility. My assignment started nine days earlier with an on-site survey. The survey changed the technical plan by showing which assumed connections were practical, which were too weak to count on, and where satellite internet could be deployed.

## Testing the available paths instead of assuming them

I tested the venue's available Wi-Fi and evaluated whether a wired connection could reach the event room. The physical route made a new hardline impractical, while the available Wi-Fi did not provide the operating margin I wanted for the webcast. I also tested service from three cellular carriers rather than treating a phone's signal indicator as proof of usable backup capacity.

The cellular tests showed that none of the available carriers was dependable enough to count as the event's fallback. That was an important result, even though it removed an easy option. A backup path is only real when it has been tested under the conditions where it will be used.

## Surveying the whole room, not only the network

The webcast was receive-only at the venue, so the network was part of a larger room workflow. I reviewed the display and audio arrangement, the limited space available for equipment, and how equipment placement would interact with venue service. A technically strong connection still had to fit into a working dinner environment.

An exterior location offered a clear position for satellite equipment. I documented that access point and delivered written findings and recommendations after the survey. This public account intentionally omits the venue, client, program name, local network measurements, floor plan, remote-access method, and any identifying configuration details.

![Diagram connecting the venue survey and exterior satellite internet path to an incoming webcast and room display](https://chapters.bio/content/images/2026/07/site-survey-satellite-delivery-5.png)

The survey connected the exterior satellite position to a receive-only webcast and display plan inside the room.

## Returning with a plan shaped by evidence

When I returned for the event on February 19, I deployed Starlink as the primary internet path for the incoming webcast and room display. Pre-show preparation included positioning the system, confirming the connection, testing the receive path, and checking the display workflow before guests depended on it.

![Starlink terminal deployed outside the venue for the February 19 webcast](https://chapters.bio/content/images/2026/07/2026-02-19-starlink-outside-1.jpg)

![Two-laptop webcast receive station and room-display controller on event day](https://chapters.bio/content/images/2026/07/2026-02-19-receive-station-1.jpg)

On event day, the outdoor Starlink position and compact receive station connected the internet path to the room display.

The satellite connection delivered substantially more capacity than the paths available during the survey. More important than the headline speed was its behavior through the event window. I monitored the incoming webcast and display path while coordinating equipment placement and service timing with the venue team.

## A successful event that began nine days earlier

The webcast went live at the planned time and was monitored through the event window. The setup followed the evidence gathered during the survey: unrealistic options had been eliminated, the physical satellite position had been identified, and the network plan had been connected to the room's display and operating constraints.

This assignment reinforced why I treat a site survey as engineering work rather than a preliminary visit. Measuring the real environment early made it possible to arrive with a plan built for that venue—not a generic kit and a hope that one of the usual connections would be good enough.
### Rebuilding the Rose Parade Workflow for 2026
URL: https://chapters.bio/rebuilding-the-rose-parade-workflow-for-2026/
Last updated: 2026-07-13T14:48:54.000Z
The 2026 Rose Parade returned with the same January 1 deadline and a newly assembled technical workflow. This year's documented work centered on preparing the production platform, validating the distribution and recording path, and carrying those checks into the Pasadena build.

The assignment moved through two connected phases: platform preparation in December and an on-site build during the final days of the year. A successful platform test would mean little if the physical show-week system did not reproduce the same path and recording behavior.

## Validating platform and recording before load-in

I began with production-platform preparation, signal checks, and recording validation. Repeated tests gave the team a chance to observe the live path and its record path before the temporary system was assembled in Pasadena.

The useful method was straightforward: verify the input, observe the output, confirm the recording, and repeat the check after a meaningful change. Private endpoints, account details, and configuration values remain outside this article.

## Carrying the checks into show week

Load-in and cabling began on December 29\. December 30 was dedicated to setup, testing, and final configuration, while December 31 provided a rehearsal and another complete verification window. Separating those stages kept physical installation, system configuration, and production operation from collapsing into one rushed checkpoint.

Each stage created a clearer handoff for the larger team. Cabling could be checked before final configuration, configuration could be checked before rehearsal, and rehearsal could expose the difference between a technically valid signal and a workflow that was comfortable to operate live.

![Temporary production control room with multiview monitors and routing equipment during Rose Parade rehearsal](https://chapters.bio/content/images/2026/07/2026-tournament-of-roses-1.jpg)

![Rain falling on the Rose Parade route and empty grandstands before dawn on January 1, 2026](https://chapters.bio/content/images/2026/07/2026-tournament-of-roses-rainy-route.jpg)

Show week moved from the temporary production position into a rainy New Year's Day route.

## What changed from the 2025 workflow

The 2025 project had emphasized distribution, timing, audience measurement, and failover. The 2026 scope centered on platform readiness and recording validation, then carried those checks through the on-site build and rehearsal.

The prepared system supported the January 1 parade before the team completed the event-day wrap. That is the outcome documented here; the article does not claim more about every destination or recording than the surviving project record supports.

The annual return still mattered because prior knowledge shortened the path to useful tests without replacing them. Reuse the lessons, rebuild the evidence, and arrive at show day with a workflow the team has actually operated.
### Migrating a Production Website with a Safety Net
URL: https://chapters.bio/migrating-production-website-with-safety-net/
Last updated: 2026-07-13T16:41:46.000Z
On December 18 and 19, 2025, I worked through a production-services website migration from staging toward its primary environment. The documented scope combined backup, migration, platform updates, cleanup, validation, and a final recovery point around the change.

## Preserving the environment before simplifying it

Before changing the production environment, I created backups covering the existing website and data state. That established a recovery point before migration and cleanup began.

That preservation step separated two decisions that are often rushed together: what should move now and what may be safe to remove later. The article omits the client name, domains, hosting account, database details, and storage locations.

![Diagram showing a staging website moving to production between pre-migration and post-migration backups](https://chapters.bio/content/images/2026/07/website-migration-3.png)

The migration sequence put backup, movement, validation, and a fresh recovery point around the production change.

## Moving staging into the production role

I moved the intended site out of staging and completed the environment updates recorded as part of the migration. The work kept the production destination and private hosting configuration out of the public description.

The migration was handled as a sequence rather than a single copy operation: preserve the starting state, move the site, update the supported environment, and then validate the result before cleanup.

## Updating and testing the operating site

After the move, I updated the supported site components and worked through the validation steps recorded for the public and administrative sides of the environment.

I then completed a final smoke test before sign-off. The purpose was to check the migrated site as a working system rather than treating a successful homepage response as the only evidence.

## Cleaning up without erasing the rollback path

Cleanup followed the migration and validation steps rather than preceding them. Material identified for removal was handled only after the pre-change backup existed, keeping the sequence recoverable.

The migration concluded with a fresh backup and final validation. Together with the pre-change recovery point, that documented both sides of the production change without making unsupported claims about the long-term storage or retirement of older systems.

The project reinforced that a production migration is not simply a file copy or a DNS change. A dependable migration connects preservation, environment changes, functional testing, careful cleanup, and a verified way to recover the state that was just approved.
### Upgrading Wowza with a Rollback Plan
URL: https://chapters.bio/upgrading-wowza-with-rollback-plan/
Last updated: 2026-07-13T16:37:44.000Z
On November 5, 2025, I upgraded a production Wowza Streaming Engine server to a later supported build. The software update itself was only one part of the assignment. The larger responsibility was to make a controlled change to a system used for live media, preserve a way back, and verify that the services returned in the expected state.

## Assessing the system before changing it

I began by confirming the installed Wowza version, reviewing the running services, and checking compatibility with the server's Java 21 environment. Those checks established the actual starting point and reduced the chance of discovering a prerequisite only after the streaming services had been stopped.

This article intentionally excludes the client, server identity, file paths, management address, application names, and stream configuration. They were relevant to the maintenance work but are not needed to explain the decision process publicly.

![Diagram of a streaming server upgrade with backup, maintenance, verification, and rollback stages](https://chapters.bio/content/images/2026/07/streaming-server-upgrade-3.png)

The upgrade plan treated rollback and service verification as part of the change, not as afterthoughts.

## Creating a clean maintenance boundary

Before installing the update, I stopped both the streaming engine and its management service and verified that the related processes had ended cleanly. A clear stopped state matters because an upgrade should not be writing over a service that is still handling files or holding part of the previous runtime in memory.

The update process created an automatic backup of the earlier installation before applying the new package. That backup was the rollback point if verification failed. A maintenance plan is incomplete when it describes only the desired forward path; it also needs a specific recovery state and a decision about when to use it.

## Verifying more than a successful installer

After the update completed, I restarted the streaming engine and management service. I then checked the service response and confirmed that Wowza reported the intended updated build. The point was not merely that an installation script reached its final line, but that the actual server process returned and identified itself as the expected version.

I also created a helper script for future maintenance. Repeating a known sequence through a small, readable tool can reduce skipped steps, but it does not replace judgment. Compatibility, backup state, maintenance timing, and post-restart validation still need to be reviewed for every change.

## Maintenance as a recoverable operation

The engine and management services restarted on the updated build, and the service endpoint responded as expected. Those were service-level checks rather than an application-level playback test. The update process left an automatic backup as the documented rollback point.

This upgrade reinforced a principle that applies to live-streaming infrastructure and ordinary IT systems alike: the real unit of work is not the software update. It is the complete change window—known starting state, clean stop, recoverable backup, deliberate install, service restart, and evidence that the services recovered afterward.
### Building a Gmail-to-Airtable Job Workflow
URL: https://chapters.bio/building-gmail-to-airtable-job-workflow/
Last updated: 2026-07-13T16:32:42.000Z
In October 2025, I worked on a small automation with a practical goal: turn job information arriving through Gmail into a structured Airtable record without asking someone to re-enter the same details by hand. Make connected the two services, but the value of the workflow depended on whether it could extract the expected fields from the test message.

## The connector was the easy part

Connecting an inbox to a database does not automatically create useful data. An email is written for a person to read, while Airtable expects distinct values mapped into known fields. The automation needed to recognize the relevant text, extract it correctly for the tested message format, and send each result to the right place.

My role was to debug the workflow, refine the parsing logic, verify the field mapping, and leave behind a process the client could understand. This public article intentionally omits the client's identity, the source messages, the Airtable schema, and the information contained in real job records.

![Diagram of an email moving through an automation step into a structured database record](https://chapters.bio/content/images/2026/07/email-automation-records-3.png)

In the completed test, the workflow converted job information from incoming email into the expected Airtable fields.

## Simplifying the input before improving the parser

During testing, I switched the workflow to plain-text parsing. That removed formatting from the input before the extraction rules ran and made it easier to see exactly what the parser was receiving. A simpler source gave the debugging process a more stable starting point.

I then refined the regular-expression match pattern used to identify the values the workflow needed. The goal was not to build the most elaborate parser possible. It was to make the smallest dependable rule set for the actual message format, while keeping the steps visible enough to diagnose when that format changes.

## Mapping is where automation becomes operational

Once extraction worked in the completed test, I reviewed the mapping between the parsed values and their Airtable destinations. A workflow can run successfully and still create a bad record if two fields are swapped, a value is empty, or text is stored in the wrong form. Each mapping therefore needed to be checked as part of the end-to-end result.

The completed test populated a new Airtable record with the expected mapped values. I also recorded a video walkthrough showing the workflow and the test result, giving the client a reference for how the scenario was assembled and how to inspect it later.

## A tested workflow, with known boundaries

This milestone established an end-to-end tested automation. It did not make email a perfectly controlled data source. If the message template changes, the parsing rules and mappings still need to be reviewed, and production use should include a way to notice messages that fail or produce incomplete records.

The project reinforced a lesson I use in larger systems too: reliability often improves when the input is made simpler before more logic is added. Debugging the source, narrowing the parser, verifying every mapping, and documenting the result turned a promising connection into a workflow that could be evaluated with real evidence.
### Connecting Camera and LiveU for San Diego FC vs. Tigres
URL: https://chapters.bio/connecting-camera-and-liveu-for-san-diego-fc-vs-tigres/
Last updated: 2026-07-13T14:48:53.000Z
San Diego FC hosted Tigres UANL at Snapdragon Stadium on August 1, 2025, during the Leagues Cup. I supported the partner broadcast in two connected roles: a field-camera position for interview coverage and the LiveU transmission workflow carrying program and supporting signals beyond the stadium.

The assignment crossed the usual boundary between a camera position and the network path behind it. Power, lighting, audio, video, venue connectivity, bonded transmission, and coordination with the production truck all had to work as one system before the first live segment.

## Building two connected field positions

Near the field, I prepared a Sony camera, lighting, a field monitor, and the audio and video handoffs needed for pregame, halftime, and postgame interviews. I coordinated the position's power and network requirements with the venue and checked the return path with the partner broadcast team.

A second position near the production truck housed the LiveU rack. It received the program and supporting audio signals, connected to the truck over Ethernet and video cabling, and used external cellular antennas so Ethernet and cellular could contribute to the bonded path. The two positions served different production needs, but a problem at either one could affect what the remote team received.

![Camera, field monitor, and LED light arranged beside the pitch at Snapdragon Stadium](https://chapters.bio/content/images/2026/07/2025-08-01-san-diego-field-position.jpg)

![Portable LiveU transmission equipment staged beside a production truck](https://chapters.bio/content/images/2026/07/2025-08-01-san-diego-transmission-rack.jpg)

The field setup connected the interview position to the equipment staged beside the production truck.

## Changing the transmission plan during testing

Early tests showed frame drops when the transmission relied on Ethernet alone. I worked with LiveU support and the receiving team to enable simultaneous Ethernet and cellular bonding, then ran extended stability checks before the evening broadcast.

Available bandwidth varied during the extended tests, so I adjusted the transmission bitrate rather than forcing the original setting onto a connection that no longer behaved the same way. Encoder restarts were coordinated during non-live windows so each change could take effect outside a planned segment.

## Following the signal beyond the encoder

The video path was only part of the job. Monitoring revealed uneven levels between audio channels, so I coordinated a source-routing adjustment with the truck and verified the correction through the LiveU return. That end-to-end check helped distinguish a source issue from something introduced later in the path.

Communication mattered because the people making decisions were spread across the field, the truck, support, and the remote receiving team. I translated the symptoms into specific checks, kept changes tied to safe operating windows, and helped the teams maintain one view of the transmission while the match schedule continued.

## Redundancy as a live operating practice

I remained on assignment through the field segments and live match window. After the event, I completed the equipment breakdown and helped preserve logs for post-show review rather than treating the end of transmission as the end of the engineering work.

This match reinforced that bonded transmission is not automatic resilience. Ethernet and cellular only become a useful combination when both are enabled, observed, and adjusted as real conditions change. The working method relied on extended tests, communication across the handoffs, and deliberate changes before and during the live window.
### Preparing Three SRT Feeds for Guatemala–El Salvador
URL: https://chapters.bio/tuning-three-srt-feeds-for-guatemala-el-salvador/
Last updated: 2026-07-13T16:25:15.000Z
For the May 31 Guatemala–El Salvador match at Finley Stadium in Chattanooga, I was responsible for preparing and operating three Secure Reliable Transport (SRT) feeds. The work began with a dedicated test day so the production and receiving teams could validate the complete routes before the live window.

I coordinated with client engineers to confirm that each source, server configuration, endpoint, and network handoff was aligned. Testing the full paths together gave everyone one shared operating baseline instead of treating each part of the transmission chain in isolation.

## Validating the complete route before match day

SRT is designed to carry video across variable networks, but its operating parameters still need to match the real route. I adjusted bitrate and latency, verified the endpoints, and repeated the process across all three feeds so the team could enter the live window with tested settings.

The settings involved a practical tradeoff. Bitrate determines how much video data the path must carry, while latency gives SRT time to recover delayed or missing packets. My role was to select a combination suited to the available routes, confirm it with the receiving engineers, and document the baseline for match day.

## Creating a shared operating baseline

I documented the feed map and operating parameters, confirmed the server-side configuration at the level needed for the show, and coordinated directly with the engineers receiving the feeds. That preparation gave the production team a clearer handoff and a common reference for final checks.

The useful lesson was not any private address, port, destination name, or access method. It was the value of testing the complete route, agreeing on the settings, and making sure the people on both ends understood the same operating plan before the production went live.

## Monitoring the live window

On May 31, I repeated the final connectivity checks, monitored all three SRT feeds, kept the client teams informed, and made adjustments within the agreed operating plan as conditions changed. The tested baseline and documented handoffs gave the live team a more consistent way to coordinate throughout the match window.

The assignment reinforced why transmission testing should reproduce the complete route instead of checking devices in isolation. A dedicated test day gave the team time to validate all three paths, align the technical handoffs, and begin match day with a workflow that had already been exercised under real operating conditions.
### Turning Times Square into a Live Boxing Broadcast
URL: https://chapters.bio/supporting-fatal-fury-in-times-square/
Last updated: 2026-07-13T08:00:37.000Z
On May 2, 2025, The Ring presented Fatal Fury: City of the Wolves in Times Square, a boxing card headlined by Ryan Garcia and Rolando Romero. In the middle of one of the world's busiest public spaces, a temporary ring, lighting grid, camera positions, production areas, and transmission paths had to come together as one live venue.

My role was on the remote-integration, or REMI, transmission side. I deployed a LiveU server that let the remote production team receive and switch the feeds coming from Times Square. The technical story was how a temporary outdoor venue became part of a remote live-production system.

## Building a broadcast venue in a public square

Times Square did not begin as a ready-made arena with permanent broadcast infrastructure. The production had to establish the ring, lighting, cameras, crew positions, power, communications, and network paths inside a public space that still had its own traffic, buildings, screens, and operating constraints.

The ring was the visible transformation. Behind it, the temporary transmission system had to make the venue usable for viewers who would never see the physical build. Every contribution feed needed a clear route from the event site into the remote production workflow.

## Creating the REMI path out of Times Square

The LiveU server gave the remote team a place to receive and switch the incoming feeds without moving every production function into Times Square. I prepared that server as part of the REMI workflow and connected the field contribution paths to the remote operation.

Connectivity combined bonded cellular with an additional microwave internet path brought in by a satellite truck. The two approaches gave the temporary venue different ways to carry live video away from the site instead of depending on a single local connection.

## Proving the temporary system before the live card

Setup on April 30 established the field and remote systems, and the May 1 rehearsal provided a full day to check the contribution feeds, server ingest, switching workflow, and connectivity before the live card. That rehearsal mattered because the venue and its broadcast infrastructure were both temporary.

On May 2, the same Times Square space functioned as both a boxing arena and the field side of a REMI production. The project showed that transforming a public plaza for a live event means building more than what the crowd can see: the remote switching, contribution paths, and internet connectivity are part of the venue too.
### Another Year at Coachella—This Time Remotely
URL: https://chapters.bio/monitoring-production-networks-at-coachella/
Last updated: 2026-07-13T15:55:47.000Z
Coachella was familiar work for me, but 2025 was different: instead of being on site, I was able to support the production remotely. I managed the device-networking and monitoring layer behind more than 40 cameras across two stages, along with the RF and production devices that kept those camera systems connected.

## Building one remote view across two stages

I configured a compact Linux device to run specialized network-monitoring software as a dedicated observability point. It gave me a single remote view of devices distributed across both stages instead of forcing the team to check each camera position or production system individually.

I organized and labeled the monitored equipment so I could quickly see IP addresses, negotiated network speeds, packet loss, connection state, and how long each device had been online. The same view made address conflicts, intermittent connections, and unexpected state changes easier to spot without exposing the production's private hostnames or network layout publicly.

## Finding network trouble before it reached the show

The goal was not simply to confirm that a device was online. I could watch for degrading link speeds, rising packet loss, a device repeatedly dropping and returning, or a network address that did not match the expected configuration. Those early signals gave me a chance to investigate while the camera was still working instead of waiting for a visible failure during the production.

A saved inventory and consistent device history also made troubleshooting faster. I could compare current behavior with the expected baseline, narrow a problem to a device or network path, and give the on-site team a more useful place to start checking rather than asking them to work through the entire chain.

## Remote did not mean hands-off

The on-site crew still handled the physical camera and network equipment, while I supplied the wider system view. When something changed, I could trace what the monitoring data showed, communicate the likely scope, and stay with the issue as the field team checked cabling, power, configuration, or the affected device.

For me, that was the real shift in returning to Coachella remotely: I did not need to stand beside every camera to understand the health of the network supporting it. A small, carefully configured Linux system turned dozens of separate devices into an operating picture I could monitor, trace, and use to catch network issues before they became production issues.
### Building Redundant Bilingual Feeds for LXF
URL: https://chapters.bio/building-redundant-bilingual-feeds-for-lxf/
Last updated: 2026-07-13T07:37:50.000Z
Lights Out Xtreme Fighting held LXF23 at Thunder Studios on March 22, 2025\. My transmission assignment was to deliver the live program in both English and Spanish, with an independent backup feed for each language.

That turned one event into four paths that had to remain easy to identify and monitor: English primary, English backup, Spanish primary, and Spanish backup. The goal was not simply to create duplicate streams, but to keep each language available if a device or connection changed during the event.

## Separating feeds, devices, and connections

The workflow used three Teradek Cube encoders and one LiveU unit to send the four Secure Reliable Transport (SRT) feeds. The venue's house internet carried the primary traffic, while an on-site Starlink system provided a separate backup connection. Signal distribution from the production truck fed the encoders before the network paths diverged.

The workflow kept the language, primary, and backup paths clearly identified, while the Starlink backup did not depend on the venue's house internet. That made a problem easier to isolate without treating every visible symptom as a failure of the source program.

## Verifying the complete route

Before going live, I checked the equipment, confirmed each destination, and used confidence returns to verify that both languages were arriving through their intended paths. This mattered because a healthy encoder display only proves the signal left one device; the return confirms that it survived the route and remained usable downstream.

Clear labels and a small, deliberate network were as important as the individual encoders. Four similar feeds can become confusing under show pressure, so the operating plan had to make the language, priority, device, and connection behind each path immediately understandable.

## Redundancy the team could operate

All four feeds were verified before the event and the transmission workflow ran through the live production. The assignment reinforced that redundancy has to be more than a second output on a diagram. It becomes useful when the backup is meaningfully independent, continuously visible, and simple enough for the team to act on without hesitation.

Bilingual distribution added another reason to be disciplined. Every technical decision had to preserve two audience experiences at once, and both deserved the same level of preparation, monitoring, and recovery planning.
### Engineering the 2025 Rose Parade Workflow
URL: https://chapters.bio/engineering-the-2025-rose-parade-workflow/
Last updated: 2026-07-13T07:37:41.000Z
The 2025 Rose Parade took place in Pasadena on January 1, but my work on its distribution workflow began in November. I helped evaluate, test, and prepare the cloud and encoding systems that would carry the program beyond the parade route.

This was a return to an annual production rather than a reason to trust a saved configuration without testing. The team needed current evidence about the distribution, measurement, and backup paths before the equipment reached the event site.

## Testing the distribution design

The early work centered on the cloud distribution workflow and its primary and backup routes. I reviewed the existing stack, tested its behavior, and helped troubleshoot a Secure Reliable Transport (SRT) delivery issue with the team.

That process turned a diagram into an operating plan. It documented the intended primary and backup behavior, defined the checks needed before show week, and kept endpoint addresses, access methods, identifiers, and configuration values private.

## Integrating timing and audience measurement

December added the systems around the main video path. I prepared a cloud production platform, tested destinations and Society of Cable Telecommunications Engineers (SCTE) timing markers, and worked through audience-measurement integration. Additional distribution testing added ingest, recording, and verification checkpoints.

These integrations had to agree about more than whether a picture was visible. Timing data, recording behavior, measurement signals, and the program itself all needed to be checked across the workflow. Several rounds of testing gave the team time to find differences before parade day.

## Moving from the lab to Pasadena

The on-site phase began with load-in on December 29, followed by setup on December 30 and stream testing on December 31\. Each day narrowed the gap between the remote preparation and the real production environment: physical cabling, final configuration, destination checks, and team handoffs all had to line up.

![Broadcast equipment cases and production gear staged beside mobile units during Rose Parade load-in in Pasadena](https://chapters.bio/content/images/2026/07/2025-tournament-of-roses-2.jpg)

![Wide view from empty Rose Parade grandstands across the parade route in Pasadena before event day](https://chapters.bio/content/images/2026/07/2025-tournament-of-roses-wide-route.jpg)

On-site preparation included both the production equipment and the temporary grandstands and broadcast positions along the parade route.

On January 1, the prepared workflow supported the live parade and the team completed the event-day operation and wrap. The strongest lesson was not that an annual event becomes routine. It was that repeatability comes from rebuilding confidence in the system each year through documented tests, explicit backup paths, and time to resolve integration problems before going live.
### Transmitting Sukeban Wrestling Live
URL: https://chapters.bio/transmitting-sukeban-wrestling-live/
Last updated: 2026-07-12T01:15:48.000Z
In May 2024, I served as Transmission Engineer for Sukeban's Japanese wrestling show at the Trinity Hotel in Los Angeles. The ballroom had been transformed into a distinctive live-event environment, with the ring, lighting, cameras, and production areas all working toward the same program.

## Supporting the live delivery

My responsibility was the transmission side of the broadcast: helping prepare the live-delivery path, confirming the required handoffs, and monitoring the program as it moved from the production to its online audience.

Transmission engineering is most effective when it stays connected to the rest of the show. I coordinated with the production team while keeping my scope focused on the live signal and its dependable delivery.

![Event equipment arranged around the Trinity Hotel ballroom before the Sukeban show](https://chapters.bio/content/images/2026/07/sukeban-event-equipment.jpeg)

![Wide view of the Sukeban ring and production area inside the Trinity Hotel ballroom](https://chapters.bio/content/images/2026/07/sukeban-ballroom.jpeg)

The Sukeban ring, event equipment, and ballroom staging came together as one coordinated live-production environment.

## Keeping the focus on the event

The technical work existed to support Sukeban's performers and the experience created inside the room. The live program was delivered successfully, allowing viewers outside the Trinity Hotel to follow the energy and presentation of the show.

For me, the event was a strong example of teamwork across a live broadcast. Each department had a defined responsibility, and the transmission role connected the finished program with the audience watching beyond the venue.
### Supporting AFSP's Talk Away the Dark Panel
URL: https://chapters.bio/supporting-afsp-talk-away-the-dark-panel/
Last updated: 2026-07-12T01:15:51.000Z
On May 20, 2024, the American Foundation for Suicide Prevention brought its “A Talk Away the Dark” panel to ArtCenter College of Design in Pasadena. The discussion brought together advocates and creative voices, including Zack Snyder, to talk openly about mental health and suicide prevention.

I served as Technical Director for the production. My responsibility was to support the conversation without allowing the production itself to become a distraction: make every participant easy to see and hear, preserve the complete discussion, and give the post-production team dependable material afterward.

## Preparing the room

Our production work began several days before the panel. The team built and tested a three-camera setup, planned the live switching, and coordinated with the sound team so the room and recording workflow worked together.

The cameras and external recorders captured 4K source material while an HD program line cut preserved the live sequence of the conversation. That gave post-production both an immediately useful version and the flexibility to revisit individual camera angles later.

The technical choices were important, but they were not the point of the event. The best result was a system quiet enough that the panelists could concentrate on the discussion and the audience could concentrate on them.

## Preserving the conversation

After the panel, my role continued through equipment return and media handling. I supervised the transfer and organization of the recordings so the material could move safely into post-production.

That final step can be easy to overlook. A production is not complete when the cameras stop. The recordings still need to be verified, organized, protected, and handed off in a form the next team can use with confidence.

## Work in service of the message

AFSP's mission is to save lives and bring hope to people affected by suicide. For this event, my contribution was practical: build a dependable production around a difficult and necessary conversation, then preserve that conversation for the people who would encounter it later.

The experience reinforced something I value about technical work. Not every successful system should call attention to itself. Sometimes the best measure of the work is that it gives important voices the space to be heard.

---

If you or someone you know needs emotional support in the United States, call or text **988** or visit [988lifeline.org](https://988lifeline.org/get-help/?ref=chapters.bio). The 988 Suicide & Crisis Lifeline is available 24/7.
### Building a Resilient Broadcast for the Vinivia Awards
URL: https://chapters.bio/building-a-resilient-broadcast-for-the-vinivia-awards/
Last updated: 2026-07-12T01:22:21.000Z
On April 4, 2024, the Vinivia Awards brought creators and guests to Optimist Studios in Los Angeles for a live product launch. I worked with the transmission team to help carry the event beyond the venue and into Vinivia's streaming platform.

The assignment was not simply to send out one feed. We needed a low-latency workflow that could continue operating if any individual connection became unavailable, while the venue also supported the connectivity needs of the event and its attendees.

## Building independent transmission paths

Our design combined gigabit internet, satellite connectivity, and bonded cellular service into parallel paths. That gave the transmission team options instead of tying the launch to one provider or one physical connection.

My responsibility centered on the transmission workflow: helping integrate the available paths, monitoring their behavior, and adapting the system as the conditions around the production changed. Phenix supported the low-latency delivery, and its engineer Jim was an important collaborator as the workflow came together.

![Guests and production crew moving through the magenta-lit event floor](https://chapters.bio/content/images/2026/07/62b2afd915-IMG_7382.jpeg)

![Indoor Vinivia Awards staging with guests, crew, and lighting equipment](https://chapters.bio/content/images/2026/07/499316951c-IMG_7383.jpeg)

![Presenters seated in front of a Vinivia display during the live event](https://chapters.bio/content/images/2026/07/69f909838e-IMG_7385.jpeg)

The production operated across several active event spaces under Vinivia's intentional magenta lighting.

The architecture also had to coexist with the event's broader network demand. Attendee Wi-Fi and production traffic served different purposes, but both were part of the same live environment. Keeping the transmission paths deliberate and observable helped the team protect the launch while the venue remained active around us.

## Adapting at the venue

Intermittent rain and cold affected an outdoor setup, while venue access and shared power introduced additional constraints. None of those conditions changed the objective: maintain a stable transmission workflow without disrupting the event.

The team adjusted equipment placement and changed where parts of the system drew power rather than attempting a disruptive move during final preparation. Those were small decisions compared with the scale of the launch, but they are often what determine whether a live system remains dependable.

![Camera position beside the Vinivia Awards arrival area](https://chapters.bio/content/images/2026/07/7b89f26fe0-IMG_7386.jpeg)

![Camera operator and production equipment beside the outdoor event area](https://chapters.bio/content/images/2026/07/9969e69851-IMG_7387.jpeg)

![Crowd gathered in the Vinivia Awards room under magenta stage lighting](https://chapters.bio/content/images/2026/07/5b4ffe3f1c-IMG_7394.jpeg)

Camera placement and transmission support had to coexist with a venue that remained active around the production.

Marcello Genovese helped keep the teams aligned as technical and event needs changed. That support made it easier to solve the immediate issue and keep the larger production moving.

## The result

When the Vinivia Awards began, the redundant paths were in place and the team could monitor the stream as creators moved through the event. The finished workflow connected the on-site production with Vinivia's audience while giving the transmission team practical alternatives if conditions changed.

![Vinivia mobile display parked outside the event venue at night](https://chapters.bio/content/images/2026/07/6c4bc3d2ca-IMG_7319.jpeg)

The event extended outside the main room as the launch continued after dark.

The project reinforced a principle that continues to shape my live-production work: redundancy is not only about buying a second connection. It comes from understanding which parts of a system are truly independent, making their behavior visible, and giving the team a clear way to adapt under pressure.

That is the work I enjoy most—building systems that stay calm enough for the creative team to concentrate on the event.
### Transmitting Argentina vs. Costa Rica Live
URL: https://chapters.bio/transmitting-argentina-vs-costa-rica-live/
Last updated: 2026-07-12T01:30:24.000Z
On March 27, 2024, Argentina and Costa Rica met for an international friendly at the Los Angeles Coliseum. I worked as a transmission engineer on the team responsible for carrying the live program beyond the stadium.

## Building independent distribution paths

The production required distribution to 25 Secure Reliable Transport (SRT) destinations. Rather than depending on one connection, the transmission design combined fiber, cellular, and satellite paths with broadcast encoders and LiveU equipment.

Those paths gave the team options if conditions changed during the match. My responsibility was to help prepare the transmission system, monitor the outgoing feeds, and respond to signal or connectivity issues while the program remained live.

## Operating through the final whistle

Live sports leaves little room to pause and diagnose a problem after the fact. The work depended on early setup, clear coordination, and continuous attention to the health of every path from kickoff through the end of the match.

The assignment reinforced a principle I use across live production: redundancy is most useful when the team understands the alternatives before they are needed. Multiple paths, active monitoring, and shared operating decisions turned a complex distribution requirement into a manageable live workflow.
### Streaming the Arc World Tour Finals
URL: https://chapters.bio/streaming-the-arc-world-tour-finals/
Last updated: 2026-07-12T01:30:25.000Z
The Arc World Tour Finals brought the Guilty Gear community together for four days of live competition. I served as the transmission engineer, responsible for helping the program reach its online destinations while the tournament continued inside the venue.

## Designing for a multi-day broadcast

The transmission workflow combined fiber, satellite, and internet connectivity to create primary and backup routes. LiveU equipment supported the remote path, including delivery to an RTMP listener in Japan, while Restream was used at the client's request for additional distribution.

My work covered preparation, path checks, live monitoring, and troubleshooting throughout the event. A four-day tournament changes the operating problem: the system has to remain understandable and recoverable across long days, changing match schedules, and repeated handoffs.

## Keeping the competition connected

The players and matches were the reason people watched. The transmission system's job was to stay out of their way while preserving a dependable connection between the venue and the audience.

This project reinforced the value of treating redundancy as an operating plan rather than a list of equipment. Each backup path needed to be monitored, understood, and ready to support the program if conditions changed.
### Engineering an Oscars Watch Party Stream
URL: https://chapters.bio/engineering-an-oscars-watch-party-stream/
Last updated: 2026-07-12T01:30:25.000Z
A West Hollywood venue needed a dependable Oscars program feed for an on-site watch party. Our team arrived early to build the reception, connectivity, and audio-video handoff before guests gathered for the evening.

## Connecting the venue

The setup combined satellite reception with a multi-SIM cellular router to support the event's viewing and communication needs. The incoming program source then had to be converted and handed to the venue's audio-video team as SDI so it could be distributed through the local system.

The physical layout mattered as much as the signal path. Equipment positioned outside and in the parking area had to support viewing spaces elsewhere in the venue, so the team coordinated cable routes, handoff points, timing, and audio coverage before doors opened.

## A coordinated handoff

My contribution was part of a larger event workflow that included the venue's technicians and production staff. Clear boundaries between reception, conversion, and house distribution helped each group verify its portion of the chain.

The assignment was a useful reminder that reliable event technology is often about interfaces between teams. A well-defined handoff can make a mixed system of broadcast, network, and venue equipment operate as one experience for the audience.
### Streaming MHSOAC Meetings from Napa
URL: https://chapters.bio/streaming-mhsoac-meetings-from-napa/
Last updated: 2026-07-12T01:30:26.000Z
The Mental Health Services Oversight and Accountability Commission held a public meeting in Napa, California. As Technical Director, I coordinated the systems that connected the room, the live stream, and people participating remotely.

## Supporting an accessible meeting

The workflow brought together camera feeds, room audio, video switching, internet streams, and audio integration for remote participation. Each part had to support the same conversation without making the technology the focus of the meeting.

I worked with camera, audio, and production team members to verify the handoffs between systems and monitor the meeting as it progressed. When normal live-event issues appeared, the priority was to diagnose them quickly while minimizing disruption for participants.

## Keeping the room and remote audience together

Public meetings create a different measure of success than an entertainment broadcast. People in the room and people joining remotely both need to hear, see, and follow the proceedings clearly.

The Napa meeting reinforced the importance of treating remote participation as part of the main production rather than an add-on. Coordinated audio, video, switching, and monitoring helped the technology support the commission's work without overstating the production's role in that work.
### Testing Apple Vision Pro in Daily Use
URL: https://chapters.bio/testing-apple-vision-pro-in-daily-use/
Last updated: 2026-07-12T01:30:28.000Z
In February 2024, I committed to using Apple Vision Pro as more than a short demonstration. I wanted to understand how its display, spatial interface, and connection to the rest of my Apple workflow felt during repeated use.

## What stood out

The micro-OLED displays and three-dimensional interface made text, video, and spatial content feel different from earlier headsets I had used. The useful question was not whether the first impression was impressive, but which tasks became clearer or more natural after the novelty faded.

I also explored how the device fit alongside my existing computers, displays, and accessories. That integration mattered because a spatial computer still has to coexist with files, applications, and habits that already work.

## A first-generation tradeoff

The testing also exposed practical limits, including glare, the learning curve of a new interaction model, passthrough quality, and the external battery arrangement. Those were not reasons to dismiss the platform; they were part of understanding where it was ready and where it still asked the user to adapt.

This was an early-use record, not a final verdict on the product category. The value of the experiment was learning which spatial-computing ideas held up in everyday use and which conclusions needed more time.
### Streaming CCRE Meetings Online
URL: https://chapters.bio/streaming-ccre-meetings-online/
Last updated: 2026-07-12T01:30:35.000Z
The Center for California Real Estate hosted an event for real estate professionals joining both in person and online. As Technical Director, I coordinated the systems that connected the presenters, cameras, room audio, live stream, and remote participants.

## Treating remote participation as part of the room

The workflow combined internet connectivity, camera and audio feeds, live video switching, presentation content, and Zoom audio. Each source had to arrive at the right destination without creating a separate experience for people joining remotely.

I monitored connectivity and audio, selected and framed camera views, and coordinated the transitions between speakers and presentation material. The work was less about making every switch visible and more about helping the audience follow the discussion naturally.

## One meeting across two audiences

Hybrid events work best when the online audience is considered during the initial production design. Audio routing, camera framing, and presentation timing all need to support the same conversation.

The event reinforced the importance of designing the room and the stream together. A coordinated technical workflow allowed participants to focus on the material rather than the boundaries between in-person and remote attendance.
### Encoding the 2024 Tournament of Roses
URL: https://chapters.bio/encoding-the-2024-tournament-of-roses/
Last updated: 2026-07-12T01:30:34.000Z
The 2024 Tournament of Roses brought its annual parade through Pasadena while broadcast teams worked behind the route to carry the program to viewers. I served as a network engineer focused on the encoded transmission and its timing markers.

## Monitoring the encoded program

My primary responsibility was to monitor the transmission encoding and respond if signal quality or delivery conditions changed. The goal was to keep the outgoing program stable while the live production continued along a fixed parade schedule.

I also managed Society of Cable Telecommunications Engineers (SCTE) markers used for downstream timing. Those markers had to be placed accurately so distribution partners could coordinate scheduled transitions without disrupting the program.

## Precision inside a larger team

Encoding and timing were only one part of the parade broadcast. The work depended on communication with production and distribution partners so changes could be understood and handled in real time.

This assignment reinforced how much live distribution depends on small, precise operations. Stable encoding, correct timing data, and clear team communication helped the transmission layer support the parade without competing with it.
### Directing an MHSOAC Public Meeting
URL: https://chapters.bio/directing-an-mhsoac-public-meeting/
Last updated: 2026-07-12T01:30:27.000Z
The Mental Health Services Oversight and Accountability Commission held a two-day public meeting in Los Angeles. I worked as the Director, coordinating the visual production and the connection between the room and remote participants.

## Coordinating cameras, slides, and recordings

My responsibilities included monitoring multiple cameras, choosing and refining framing, recording isolated camera feeds, and sending the selected program and presentation slides to Zoom. I also monitored the audio path so issues could be identified across the full meeting workflow.

Load-in changes and normal live-event interruptions required the production team to adjust as the meeting developed. Clear communication among camera, audio, and production roles helped each change remain manageable.

## Supporting the meeting rather than starring in it

The purpose of the production was to help people follow the commission's work in the room and online. Camera choices, presentation feeds, recordings, and remote audio needed to make the proceedings clearer without drawing attention to the technical system.

The event reinforced the value of proactive communication and disciplined monitoring. The strongest technical decisions were the ones that kept the public meeting understandable while the team handled changing conditions behind the scenes.
### Supporting Joshua's College Journey
URL: https://chapters.bio/supporting-my-childs-college-journey/
Last updated: 2026-07-12T00:25:00.000Z
In August 2023, my eldest son, Joshua, began college at Glendale Community College. It was an exciting milestone for our family and one of those moments that made the passage from childhood toward independence feel very real.

At the time, he was especially interested in writing and art. College offered room to explore those interests, build new skills, and discover how his creative goals might develop without requiring every answer at the beginning.

## Supporting the next chapter

My role as a parent was changing too. The work was less about directing each step and more about being available with encouragement, practical help, perspective, and the occasional technology fix when it was needed.

This chapter is not a prediction about the career he will choose or the person he will become. It marks the beginning of a college journey and the pride we felt in seeing Joshua take that step.
### From a Model 3 to a Model Y
URL: https://chapters.bio/from-a-model-3-to-a-model-y/
Last updated: 2026-07-12T01:30:33.000Z
In 2019, high fuel costs and a long Southern California driving routine pushed me to try an electric car. I brought home a Model 3 and began learning what electric-vehicle ownership was like in everyday use.

## A second chapter in 2023

Four years later, I moved to a Model Y. The new vehicle reflected both a different set of practical needs and the changes I had watched take place in electric vehicles since that first purchase.

This is a personal timeline record rather than a product review or a broad sustainability claim. It merges the separate 2019 and 2023 source posts while preserving both dates in the story.
### Prototyping a Networked Tally Light
URL: https://chapters.bio/prototyping-a-networked-tally-light/
Last updated: 2026-07-12T01:22:24.000Z
While working at SetNet, I explored a practical production question: could a small network-connected device provide a clear visual signal when a camera was live?

A tally light normally gives performers and crew an immediate answer without requiring another conversation. My goal was to test whether that signal could be controlled remotely over Ethernet while keeping the device small enough to fit into a production environment.

## What I wanted to learn

The first version did not need to be polished hardware. It needed to answer three questions: could an Arduino-compatible board listen for a command over a local network, could that command switch an LED reliably, and could the basic electronics remain compact?

That kept the experiment focused. Instead of building an enclosure or a larger control system first, I began with the network behavior and the light itself.

![Monitor, microcontroller, and breadboard arranged for an early networked tally-light bench test](https://chapters.bio/content/images/2026/07/8c93610a9c-IMG_5448.jpeg)

![Two microcontroller boards surrounded by test leads during a later bench iteration](https://chapters.bio/content/images/2026/07/68d982dc6c-IMG_5514.jpeg)

![Close view of the compact microcontroller board used in the tally-light prototype](https://chapters.bio/content/images/2026/07/7db86511b7-IMG_5439.jpeg)

Early bench work connected the networked boards, test display, and LED circuit before any enclosure or field packaging.

## Building the bench prototype

I configured the board as a small TCP server and assigned the network settings it needed to listen on a designated port. A client could then send a simple state: 1 turned the LED on, and 0 turned it off.

The code was intentionally narrow. Setup initialized the network connection and LED output; the main loop waited for a client and changed the light when a valid command arrived. Keeping the command set this small made it easier to isolate wiring, networking, and control problems during testing.

The photographs document several breadboard and board-level revisions. They are not fifteen different accomplishments, so this edited article uses only the views that explain the progression.

![Breadboard with a simple LED test circuit for the networked tally-light prototype](https://chapters.bio/content/images/2026/07/3ed505ed3b-IMG_5510.jpeg)

![Microcontroller connected to a breadboard during a later wiring iteration](https://chapters.bio/content/images/2026/07/05277745e5-IMG_5515.jpeg)

![Full workbench view of the connected prototype boards and breadboard wiring](https://chapters.bio/content/images/2026/07/58262e7e53-IMG_5521.jpeg)

Later iterations concentrated on the LED circuit and the connections between the controller, breadboard, and network hardware.

## What the experiment established

The bench prototype demonstrated the core idea: a camera-status indicator could respond to a simple command sent across the local network. It also gave me a physical platform for thinking through size, wiring, and how the control logic might fit into a broader production workflow.

It was still a prototype, not finished production hardware. The exposed boards and temporary wiring would need an enclosure, secure connectors, a repeatable power arrangement, startup and reconnection behavior, and field testing before the system could be treated as deployable equipment.

That distinction is the useful part of the project. A focused prototype can answer the riskiest question before time is spent polishing the wrong solution. Here, the network-control concept worked on the bench; the next phase would have been about durability, recovery, integration, and real operating conditions.

![Two compact controller boards connected during the final documented bench configuration](https://chapters.bio/content/images/2026/07/7d44b15a1c-69931110446__B2325EA4-40EA-4923-98A4-9F77E35C34F6-2.jpeg)

The working bench setup proved the control concept while making the remaining packaging and reliability work visible.
### From Family Rides to Onewheel Rentals
URL: https://chapters.bio/from-family-rides-to-onewheel-rentals/
Last updated: 2026-07-12T01:22:23.000Z
On July 23, 2023, Joshua, Caleb, and I added a Onewheel GT and a Pint X to our family adventures. The boards combined our interest in technology with a reason to spend more time outdoors, learn something unfamiliar together, and explore at a different pace.

What began as a new hobby quickly became shared family time. We could compare what we were learning, help one another become more comfortable, and enjoy the simple experience of getting outside together. This article keeps that family memory while avoiding photographs of Joshua or Caleb and details about our home or regular riding locations.

## Learning two different boards

The original GT and Pint X offered different sizes and riding experiences, which gave us more than one way to learn. Instead of treating specifications as permanent promises, the important part of the milestone was having equipment that could suit different riders and help us build confidence over time.

![Original Onewheel Pint X beside the public Wonder Woman statue in Burbank](https://chapters.bio/content/images/2026/07/b88dbbbf8f-A7400053_IssdeFz.4bbdf42d1ed4.jpeg)

The original Pint X during the same series of public-landmark rides in Burbank.

## Sharing the experience through rentals

The family hobby eventually grew into a small rental offering. I inspect and prepare the equipment, explain the controls and basic operation, and help new renters begin with clearer expectations. The exact inventory has changed since the original GT and Pint X purchase, so the live rental profile is the current source for available boards and accessories.

See the equipment currently available through [OnewheelRent.me](https://onewheelrent.me/?ref=chapters.bio).

## Starting with safety

Onewheel riding involves real fall and collision risks. Riders should review the manufacturer's [current safety guidance](https://onewheel.com/pages/safety-gt?ref=chapters.bio), wear an appropriate helmet and protective gear, inspect the board before riding, understand its warnings and controls, and follow the laws and conditions where they ride.

For me, this chapter is about more than the boards or the rental listing. It records a hobby I learned alongside Joshua and Caleb and the decision to make that experience available to other riders in a more practical way.
### Transmitting the Mobies Live
URL: https://chapters.bio/transmitting-the-mobies-live/
Last updated: 2026-07-12T01:30:28.000Z
The 2023 Mobies Awards brought the mobile gaming and esports community together in Los Angeles. As a Network Streaming Engineer with Streaming Media Live, I helped prepare the paths that carried the live program from the venue to its online destinations.

## Designing for failure before going live

The workflow used primary and backup internet connections with more than one encoding path. That gave the team alternatives if a connection, encoder, or destination behaved differently once the event was underway.

My role included path preparation, monitoring, and troubleshooting across the live window. Platform differences and international distribution requirements made clear naming, signal checks, and coordinated handoffs as important as the equipment itself.

## Keeping attention on the awards

The production existed to support the people and work being recognized by the Mobies. Our technical goal was to make the distribution dependable enough that viewers could focus on the program rather than the route it took to reach them.

The event reinforced that redundancy is a team practice. Backup connections and encoders only help when they are tested, monitored, and connected to a clear decision about when and how to use them.
### Rebuilding 360 Video Playback for iOS
URL: https://chapters.bio/rebuilding-360-video-playback-for-ios/
Last updated: 2026-07-12T01:30:29.000Z
When browser support no longer covered ThirdLaw's preferred 360-degree viewing workflow on iOS, I began prototyping a dedicated application. PlatePros used SwiftUI and RealityKit to let users browse and preview immersive driving plates on an iPhone or iPad.

## Separating the viewer from the data problem

Displaying 360-degree content was only part of the experience. The original video-library API limited how much metadata the app could retrieve at once, which made startup and browsing slower than the interface needed.

I introduced a backend cache that could gather and organize larger sets of library data before the app requested them. That reduced repeated external calls and gave the iOS interface a more predictable source for browsing and preview information.

## A TestFlight-stage product

At the time of this milestone, the app was being evaluated through TestFlight. It demonstrated the viewing and data-loading approach, but this article does not present the prototype as a finished App Store release.

The project reinforced a lesson that applies beyond spatial video: interface performance often depends on reshaping the data path behind it. A smoother viewer required both an iOS experience and a backend designed around the limits of the source service.
### Managed IT Consulting for Zavala Law Firm
URL: https://chapters.bio/managed-it-consulting-for-zavala-law-firm/
Last updated: 2026-07-12T01:15:49.000Z
As Zavala Law Firm's Managed IT Consultant, I provide ongoing support for the Apple devices its team uses every day. The relationship is built around continuity: maintaining the technology, helping users when something changes, and planning improvements before routine issues become interruptions.

## Maintaining the everyday environment

The firm's working environment includes Macs, iPhones, and iPads. My role covers routine operating-system and application updates, performance and storage review, device health, and user support across that Apple ecosystem.

Maintenance also includes the practical condition of the equipment. Battery health, available storage, physical care, and replacement timing all affect whether a device is ready when someone needs it. Treating those details as part of one operating practice makes support more predictable.

## Security without exposing the security plan

I help the firm apply appropriate update, password, encryption, and data-protection practices. This public overview intentionally excludes device counts, configurations, internal systems, credentials, client information, and the specific controls used by the firm.

The goal is not to make security feel separate from everyday work. It should be part of how devices are maintained, how users receive support, and how technology decisions are reviewed over time.

## Planning purchases and transitions

An ongoing consulting relationship also makes purchasing more deliberate. I help evaluate when equipment should be maintained, upgraded, or replaced, balancing cost with performance, support life, and the firm's actual working needs.

This work reflects the operational side of consulting that is easy to overlook: reliable technology comes from regular attention, clear guidance, and support that understands both the devices and the people using them.
### Building the 360CraneCam Switcher
URL: https://chapters.bio/building-the-360cranecam-switcher/
Last updated: 2026-07-12T01:30:29.000Z
ThirdLaw needed a practical way to change views from a 360-degree camera array mounted above a moving follow car. The operator needed physical controls that could respond quickly without placing the switching hardware in the same position.

## A networked pair of controllers

I built the prototype around two Arduino-compatible boards connected over Ethernet. The client read a bank of physical buttons through a multiplexer and sent the selected state to a server mounted with the switching equipment.

The server listened for those commands and changed the appropriate multiplexer channels controlling the video converter. This separated the operator's controls from the camera-side hardware while keeping the command set small and easy to diagnose.

## Designing for a moving platform

A follow car adds vibration, limited space, power constraints, and little time for complex interaction. Physical buttons and a narrow network protocol were useful because the operator could make a selection without navigating a general-purpose interface.

The system demonstrated that a focused hardware controller could turn a specialized camera workflow into a repeatable operation. It also made the remaining production work visible: packaging, connector security, power, recovery behavior, and field maintenance mattered as much as the initial circuit.
### Broadcasting Golden Boy Boxing Across Platforms
URL: https://chapters.bio/broadcasting-golden-boy-boxing-across-platforms/
Last updated: 2026-07-12T01:30:34.000Z
Golden Boy Boxing events began with one live source program that needed to reach more than one online destination. My role was to manage the restreaming workflow and monitor how that program was delivered across the required platforms.

## Adapting one program for several destinations

Each destination could impose its own resolution, bitrate, authentication, and timing requirements. The workflow had to preserve the source while creating outputs that matched those individual expectations.

I monitored the incoming feed, the restreaming system, and the outgoing destinations while watching for bandwidth, encoding, or connection problems. The goal was not to make every output identical at a technical level; it was to make each one valid and dependable for its platform.

## Managing latency and consistency

Multi-destination delivery also introduced differences in delay. Monitoring the complete path helped the team understand those differences and distinguish a destination-specific issue from a problem in the source program.

The work reinforced the value of treating restreaming as an active broadcast operation. Clear destination requirements, consistent naming, and continuous monitoring were what turned one live feed into a manageable set of platform deliveries.
### IT and Transmission Engineering at Streaming Media Live
URL: https://chapters.bio/it-and-transmission-engineering-at-streaming-media-live/
Last updated: 2026-07-12T01:30:30.000Z
At Streaming Media Live, my responsibilities crossed two operating environments: the IT systems that supported the company every day and the temporary transmission systems built for individual live productions.

## Building resilient live paths

As a transmission engineer, I worked with encoders, LiveU equipment, fiber, bonded cellular, and satellite paths. The objective was to create understandable primary and backup workflows that could be monitored and adjusted as a venue or production changed.

The work also included internet streams, audio and video handoffs, remote-participation platforms, and real-time troubleshooting. I collaborated with camera, audio, production, and venue teams rather than treating transmission as an isolated technical function.

## Connecting production with IT operations

My IT management responsibilities extended the same systems thinking beyond show day. I worked on data workflows, remote management, training, documentation, and repeatable operating practices that helped the team prepare before equipment reached a venue.

Combining the two roles changed how I approached live production. Broadcast resilience depended not only on the field equipment, but also on the preparation, support systems, and shared procedures behind it. This article consolidates two repetitive source pages into one factual career chapter and removes their third-person promotional copy and service advertisement.
### From Full-Time IT Manager to Consultant
URL: https://chapters.bio/from-full-time-it-manager-to-consultant/
Last updated: 2026-07-12T01:22:23.000Z
For six years, I served as IT Manager at SetNet, supporting the infrastructure and production workflows behind a company built around demanding, often unusual filmmaking environments. The role called for more than maintaining systems. It required translating creative needs into dependable technical workflows and adapting those workflows as productions changed.

After the pandemic, SetNet's operating model changed and my position evolved from a full-time role into a retainer relationship. The change preserved my connection to the company while giving me room to build a broader consulting practice.

## Expanding the work

I began supporting a small group of organizations with very different technical needs, including FeedRF, Streaming Media Live, and Zavala Law Firm. One client might need help with live-production connectivity, another with broadcast or RF workflows, and another with dependable day-to-day Apple and IT operations.

The variety was useful, but it also changed how I worked. In a full-time role, much of the context lives with you every day. As a consultant, I had to make that context visible: document decisions, define ownership, set appropriate availability, prioritize across organizations, and explain technical choices in language that matched each client's work.

That discipline made me a better operator and a better partner. I could bring lessons from live production into conventional IT environments, apply IT operations thinking to temporary event systems, and recognize patterns that were harder to see while working inside only one organization.

## Making room for family

The professional change also arrived during an important period for my family. Joshua and Caleb were moving through the end of high school and into college, and the retainer model gave me more control over where my time went.

That did not mean working less or caring less about the work. It meant being more deliberate about commitments so I could remain dependable to clients and present for my family. I had more opportunities to help Joshua and Caleb navigate major decisions, support their goals, and be available during a period that would not come around again.

## A broader definition of progress

Moving from full-time IT leadership to consulting did not feel like leaving one career behind. It felt like carrying the strongest parts of that experience into a more flexible form.

The transition taught me that professional growth is not always a larger team, a new title, or a straight line upward. Sometimes it is building a way of working that lets experience travel farther while making room for the people who matter most.
### Building Storage for 360-Degree Video
URL: https://chapters.bio/building-storage-for-360-degree-video/
Last updated: 2026-07-12T01:30:27.000Z
ThirdLaw's 360-degree video work generated large raw files that needed to remain organized and available beyond an individual workstation. I designed a network-attached storage system around the capacity and sustained-transfer demands of that media workflow.

## Designing around the footage

The project used a large multi-bay chassis, enterprise hard drives, and multiple storage controllers. Component choices were evaluated as one system: usable capacity, transfer throughput, drive reliability, expansion, serviceability, and recovery all affected the design.

Raw production media changes the balance of a storage build. Sequential performance matters, but so do predictable rebuild behavior, clear monitoring, and enough headroom for the archive to grow without immediately redesigning the platform.

## A foundation, not just a drive count

The finished system provided a shared storage foundation for the video workflow. This public account intentionally leaves out access methods, network layout, protection settings, and other operational details that do not need to be exposed.

The build reinforced that high-capacity storage is an operational system rather than a pile of disks. The useful result came from balancing performance, reliability, maintainability, and future growth around the work the team actually needed to preserve.
### Engineering CineVue for Film and Live Events
URL: https://chapters.bio/engineering-cinevue-for-film-and-live-events/
Last updated: 2026-07-12T01:22:22.000Z
FeedRF owners Dan Skinner and Jeremiah Goike built the company around wireless video tools for film sets and live events. As FeedRF's IT Manager, RF and Network Engineer, I contributed to both the development of the CineVue product line and the work required to deploy it in real production environments.

My responsibility crossed product engineering and field operations. I worked on hardware, software and firmware, RF design, network and system architecture, physical packaging, testing, and improvements that came directly from using the equipment on productions.

## Developing CineVue as a complete system

The CineVue line included micro transmitters, the CineVue QDR receiver, and CineVue Director receivers. Each component had a specific role, but the practical engineering challenge was making the full signal path dependable when it was installed on professional camera systems and used by production teams.

That required more than RF performance alone. Power, mounting, packaging, network behavior, monitoring, software and firmware, and the operator's workflow all affected whether the system was ready for the field. Testing and field feedback gave us a direct path from production needs back into product improvements.

![CineVue-equipped cinema camera operating under red stage lighting](https://chapters.bio/content/images/2026/07/09f0fea20c-340672159_158495716847383_261195900714327526_n.jpg)

![Professional cinema camera with CineVue components during technical preparation](https://chapters.bio/content/images/2026/07/7e6ac8d9ab-338219213_956081808727742_3855026147126102033_n.jpg)

## Supporting major productions

I personally supported CineVue work at Coachella, the Rock & Roll Hall of Fame, the film Rocketman, Billie Eilish's Happier Than Ever concert film, and additional productions. My field responsibilities included RF coordination, network setup, equipment deployment, on-site operation, troubleshooting, and client support.

Every production brought a different physical layout, camera plan, and RF environment. The goal was not to make broad claims about transforming the industry. It was to give crews a carefully developed and supported wireless-video system that could be adapted to the work in front of them.

## Connecting product development with field experience

FeedRF gave me the opportunity to work across the boundary between product development and production engineering. A choice made in hardware, firmware, networking, or packaging could affect the person carrying the camera or monitoring the signal, while an issue found in the field could become the next engineering improvement.

That feedback loop became the most important part of the work for me: design the system, test it, support it under real conditions, and bring what we learned back into the next version.
### Vaccinated to Return to Set
URL: https://chapters.bio/vaccinated-to-return-to-set/
Last updated: 2026-07-12T00:12:26.000Z
On April 5, 2021, I received the Johnson & Johnson COVID-19 vaccine.

At that point in the pandemic, vaccination status had become part of the return-to-work process across the production industry. While the exact policies varied by employer and production, receiving the vaccine helped me meet the requirements I was encountering and continue accepting work that required going to set.

This is a short public record of a career-access milestone during an unusual period. It is not medical advice or a statement about current production requirements.
### Learning Resin 3D Printing
URL: https://chapters.bio/learning-resin-3d-printing/
Last updated: 2026-07-12T01:30:35.000Z
I had wanted to explore practical 3D printing for years. In 2021, I bought an Elegoo Saturn resin printer and began learning the full process around it rather than focusing only on the machine.

## Learning the variables around the print

Resin printing introduced a connected set of variables: material behavior, room temperature, exposure settings, supports, cleaning, and curing. A successful result depended on understanding how those steps affected one another.

I joined printing communities, compared recommendations, and documented settings and observations in a personal wiki. The notes gave each failed or successful print a useful context instead of relying on memory.

This was the beginning of an experiment, not a claim that I had mastered the process. The useful outcome was a repeatable way to learn: change one variable, record the result, and build practical knowledge from the pattern over time.
### Building SetNet's Remote Production Workflow
URL: https://chapters.bio/building-setnets-remote-production-workflow/
Last updated: 2026-07-11T22:11:41.000Z
When COVID-19 changed how productions could operate, SetNet needed a practical way to support professional cameras and creative collaboration with fewer people physically present. As SetNet's IT Manager, I worked with owner and DIT Dan Skinner to lead the technical development of a portable remote-production workflow.

The objective was not to reproduce an entire set somewhere else. It was to identify the controls, signals, and conversations that people needed, then build a dependable way to extend those functions beyond the location.

## Combining connectivity and camera control

The system combined bonded cellular connectivity with interfaces for remote camera operation, microphones, lighting, and live monitoring. A conferencing platform gave directors, clients, and other approved participants a familiar way to communicate while viewing the production feed.

My work crossed the complete technical path: connectivity design, remote camera control, live monitoring, conferencing integration, equipment packaging, testing, documentation, and training. Dan contributed his production and DIT perspective so the system supported how crews actually worked rather than treating the network as an isolated product.

![Closed SetNet remote-production case labeled for field deployment](https://chapters.bio/content/images/2026/07/setnet-remote-production-case.jpg)

Packaging the system as a labeled field case helped turn the prototype into a repeatable deployment.

## Turning a prototype into a repeatable workflow

Portable equipment only becomes useful when a team can deploy and support it consistently. We organized the components into a field-ready package, tested how the connections behaved, documented the setup, and trained the people who would operate or support it.

The workflow was used to support remote participation across production locations during a period when normal working arrangements were changing quickly. This article does not claim that the system saved the film industry, preserved a specific number of jobs, or single-handedly created remote production. Its value was narrower and more concrete: it gave SetNet a tested way to connect professional production tools with people who could not all be in the same place.

## What the project changed for me

The project reinforced that remote production is a systems problem as much as a video problem. Connectivity, control, monitoring, communication, packaging, and training all had to work together before the technology could become dependable in the field.

It also demonstrated the value of pairing infrastructure engineering with production experience. Dan and I approached the same workflow from different but complementary directions, and the resulting system was stronger because both perspectives shaped it.
### Adding Solar Power at Home
URL: https://chapters.bio/adding-solar-power-at-home/
Last updated: 2026-07-12T01:30:34.000Z
In 2020, rising electricity costs made us take a serious look at producing more of our energy at home. We worked with NERDpower to install 21 Solaria PowerXT DC panels.

The source article is a short milestone rather than a long-term performance review. This rewrite preserves what was installed and why we made the decision without publishing an address, utility-account information, detailed bills, or security-relevant views of the property.
### How SetNet Kept Union Crews Working
URL: https://chapters.bio/how-setnet-kept-union-crews-working/
Last updated: 2026-07-11T23:25:33.000Z
In spring 2020, normal production work changed almost overnight. Under owner and DIT Dan Skinner's leadership, SetNet responded by building remote-production packages and operating workflows that allowed more of the production process to continue without putting a full crew in one location.

As SetNet's IT Manager, I helped turn that operational pivot into working technology. The early approach used portable systems that could be delivered to a location, provide redundant connectivity, and extend control of professional cameras, lighting, monitoring, and production communication beyond the set.

## Building the two-box remote workflow

The two-box workflow gave a production a practical way to establish stable internet and connect essential production tools without rebuilding an entire technical facility at every location. My work included the networking, bonded connectivity, remote-control integration, monitoring, equipment packaging, testing, documentation, and support behind the deployment.

The goal was not remote production as an abstract idea. It was a system that could arrive, be configured consistently, and give directors, camera teams, and other approved participants a dependable way to communicate and work.

## Creating new production responsibilities

Technology was only half of the pivot. SetNet also developed Zoom rooms that represented production spaces such as the set, green room, video village, and technical room. Supporting those rooms created Zoom Host and Zoom Assist responsibilities as part of the production workflow.

SetNet recruited and trained union DITs and other production personnel to operate and support the remote systems. That work helped preserve union jobs at a time when conventional production methods were unavailable or severely limited. This was a SetNet achievement led by Dan, supported by the team that developed, deployed, and operated the workflow.

## Recognition for Dan and SetNet

In December 2021, ICG Magazine named Dan one of its Change Makers. The profile documented SetNet's remote packages, Zoom-room workflows, training, and other production technology developed during this period. [SetNet's announcement links to the ICG feature on pages 82 and 83.](https://www.setnet.la/in-the-news-1/2022/6/15/owner-dan-skinner-named-change-maker-in-icg?ref=chapters.bio)

## Where this chapter fits

This chapter records SetNet's initial operational pivot in spring 2020: keeping people working, creating new responsibilities, and proving that the remote approach could support real productions. The January 2021 chapter, Building SetNet's Remote Production Workflow, continues the story by focusing on how the technology matured into a tested, documented, and repeatable system.
### IT Leadership at SetNet
URL: https://chapters.bio/it-leadership-at-setnet/
Last updated: 2026-07-12T01:30:30.000Z
I joined SetNet as IT Manager in 2016\. Over the next six years, my work connected the company's everyday technology operations with the specialized data and communication needs of production crews.

## Turning one-off solutions into repeatable workflows

Productions often arrived with different cameras, locations, schedules, and handoff requirements. I collaborated with filmmakers and technicians to understand the immediate need, test an approach, and document what the team could reuse on the next project.

That work included data-management services, remote-production experiments, equipment tracking, project-management practices, training, and standard operating procedures. The lasting value came from connecting the tools to a workflow people could understand and support.

## Leading through changing production needs

When production practices changed during the pandemic, the team expanded its use of remote monitoring and control. My contribution focused on testing, implementation, documentation, and support while recognizing that the resulting systems were a shared effort across production, engineering, and management.

This chapter deliberately leaves out private client information, credentials, network diagrams, financial commentary, and claims that cannot be independently verified. It records the scope of my role and the problem-solving habits that carried into my later consulting work.
### Supporting Berliner Through Its Rex Features Transition
URL: https://chapters.bio/supporting-berliner-through-rex-features-transition/
Last updated: 2026-07-12T01:30:30.000Z
When Berliner Photography became part of Rex Features, I served as Information Technology Lead through the transition. My responsibility was to keep the office, hardware, software, services, and digital-asset handoffs operating while the organization changed around them.

## Maintaining continuity during change

A company transition can change names and ownership quickly, while the operational systems still have to work every day. I focused on documenting what existed, supporting the people who depended on it, and reducing disruption as assets and responsibilities moved.

The experience taught me to treat organizational change as an operational project: establish what must remain dependable, clarify ownership, and make each handoff visible. This version does not repeat the source article's unverified speculation about later corporate plans.
### Building LifeWithTech and an Independent Practice
URL: https://chapters.bio/building-lifewithtech-and-an-independent-practice/
Last updated: 2026-07-12T01:30:30.000Z
In 2010, I began working independently as a technology consultant and founded LifeWithTech as a place to explain emerging technology in practical language. The two efforts shared a goal: help people make informed decisions without making the technology feel harder than it needed to be.

## Turning technical work into useful guidance

The consulting practice focused on research, implementation, testing, and support for early-stage technology work. LifeWithTech gave me a public way to turn the same habits into news, tutorials, reviews, security notes, and do-it-yourself projects.

This chapter merges two source entries dated the same day: one for becoming self-employed and one for founding LifeWithTech. Keeping them together makes the relationship between the professional practice and the publication clearer without importing accomplishments from later years into the 2010 milestone.
### IT Leadership at Berliner Photography
URL: https://chapters.bio/it-leadership-at-berliner-photography/
Last updated: 2026-07-12T01:30:31.000Z
At Berliner Photography, I served as Director of Information Technology in a fast-moving, cross-platform environment. Event and assignment photographs had to move from photographers to local editors, captioning teams, agents, and publications on demanding schedules.

## Supporting the complete image path

My responsibility was broader than maintaining individual computers. I supported the connected path that let people receive, process, organize, and distribute images, while balancing reliability with the changing tools used by photographers and editors.

The role included servers, workstations, storage, communications, software evaluation, scripting, remote offices, and support. This rewrite intentionally removes the source article's obsolete inventory of specific firewalls, operating-system versions, access services, and network topology.

The experience strengthened a principle I still use: the most valuable infrastructure is the part that helps creative work move safely and predictably from one person to the next.
### Caleb Was Born
URL: https://chapters.bio/caleb-was-born/
Last updated: 2026-07-12T00:31:36.000Z
On August 7, 2006, our family welcomed Caleb, my youngest son.

This short chapter preserves one of the most important milestones in my life without adding private details or family photographs.
### Joshua Was Born
URL: https://chapters.bio/joshua-was-born/
Last updated: 2026-07-12T00:36:17.000Z
On March 24, 2005, our family welcomed Joshua, my eldest son.

This short chapter preserves one of the most important milestones in my life without adding private details or family photographs.
### From Network Systems to Technical Project Management
URL: https://chapters.bio/network-systems-to-technical-project-management/
Last updated: 2026-07-12T01:15:55.000Z
My formal technical education developed in two stages at ITT Technical Institute.

In December 2001, I graduated with High Honors with an Associate of Science in Computer Network System Technology. The program established my foundation in the systems and networks that would become central to my work in information technology.

In June 2004, I completed a bachelor's degree in Technical Project Management, graduating with Honors. That second degree added a complementary perspective: technical work also has to be planned, communicated, coordinated, and carried through to completion.

Together, the two programs gave me a useful combination. I could understand the technology itself while also thinking about the people, priorities, and steps required to put it into practice. That combination continued into later roles across IT operations, infrastructure, technical leadership, and consulting.
### Network Consulting at Light of Power
URL: https://chapters.bio/network-consulting-at-light-of-power/
Last updated: 2026-07-12T01:30:32.000Z
In 2002, I worked as a Network Consultant with Light of Power Consulting. I helped manage a technical team responsible for designing, implementing, configuring, and supporting mixed-platform business infrastructure.

The work crossed local and wireless networks, user and remote systems, storage, backups, directory services, printing, and server applications. The important career milestone was learning to coordinate a broad support surface without treating each service as an isolated problem.

This chapter preserves the short historical record while replacing the source article's long list of obsolete service names with a clearer description of the responsibility.
### Turning Our House Into a Home
URL: https://chapters.bio/turning-our-house-into-a-home/
Last updated: 2026-07-12T00:59:46.000Z
After about a year of construction, the project was completed on June 1, 2001\. The single-story house we purchased in 1999 had been transformed into a larger two-story home.

This was more than a construction finish line. It marked the point when the place we had purchased became the home we had imagined for our family.

The story began with [Buying Our First Home](https://chapters.bio/buying-our-first-home/).
### Our Wedding Day
URL: https://chapters.bio/our-wedding-day/
Last updated: 2026-07-12T01:15:57.000Z
On April 29, 2000, Veronika and I were married in a small, intimate ceremony surrounded by family and friends who had traveled from many places to celebrate with us.

The ceremony was held in the same church used as a filming location for the television series 7th Heaven. We only put the connection together a week or two before the wedding—a small Hollywood detail that made the day even more memorable.

The story began with [The Day Veronika Said Yes](https://chapters.bio/the-day-veronika-said-yes/).
### Managing Special Events at Pinkerton Security
URL: https://chapters.bio/managing-special-events-at-pinkerton-security/
Last updated: 2026-07-12T01:30:32.000Z
In 2000, I worked in Los Angeles as Manager of Special Events at Pinkerton Security. The surviving source entry contains only the employer, role, and date, so this chapter remains intentionally concise.

It records the career milestone without inventing assignments, clients, methods, or outcomes that are not present in the archive.
### The Day Veronika Said Yes
URL: https://chapters.bio/the-day-veronika-said-yes/
Last updated: 2026-07-12T01:07:14.000Z
On August 14, 1999, I asked Veronika to marry me, and she said yes.

This short chapter marks our engagement—the promise that led to our wedding the following spring and the family life we would build together.
### Leaving Brooklyn for Los Angeles
URL: https://chapters.bio/leaving-brooklyn-for-los-angeles/
Last updated: 2026-07-12T01:15:56.000Z
I was born and raised in Brooklyn, so leaving New York in June 1999 meant leaving the family, friends, and routines that had shaped my life. It was hard to go, even though I knew I was ready for a new chapter in Los Angeles.

My girlfriend flew out to help me make the move west. What she did not know was that I was also carrying a private plan: I intended to propose during our trip.

That made the journey more than a change of address. It held two feelings at once—the difficulty of saying goodbye to the life I knew and the excitement of beginning something new with the person beside me.

Looking back, that is what I remember most. The move was a line between two parts of my life, but I did not cross it alone.
### Buying Our First Home
URL: https://chapters.bio/buying-our-first-home/
Last updated: 2026-07-12T00:56:07.000Z
On May 31, 1999, we purchased our first home in Los Angeles. It was a major step in building a life after moving from Brooklyn earlier that year.

At the time, the house was a single-story property. We later undertook a major construction project that lasted about a year and was completed in 2001.

Buying the house and rebuilding it were separate milestones: the first gave us a place of our own, and the second transformed that place into the home we had imagined.
### Executive Protection at Citadel Security Agency
URL: https://chapters.bio/executive-protection-at-citadel-security-agency/
Last updated: 2026-07-12T01:30:33.000Z
In 1995, I worked in New York as an Executive Personal Protection Officer at Citadel Security Agency. The surviving source entry contains only the employer, role, and date, so this chapter remains intentionally concise.

It preserves the career milestone without adding clients, assignments, protective methods, or outcomes that do not belong in a public article or are not supported by the archive.