Eric Howell · KM7GHS · Grey Operator
About Fallback Engineering
Real identity. Real systems. Real failures. Maintained documentation.
Fallback Engineering is written and maintained by Eric Howell, amateur-radio operator KM7GHS, publishing as Grey Operator. The site documents practical preparedness, communications, resilient technology, field systems, and the lessons learned while building and testing them.
What Fallback Engineering is
Fallback Engineering is about reducing dependency on perfect conditions.
The goal is not to prepare for the end of civilization. The goal is to keep a power outage, communications failure, vehicle problem, equipment failure, evacuation, or ordinary emergency from becoming worse because nobody understood the system.
This is not a gear catalog and it is not fear-based preparedness. The useful part of any system is the part that has been assembled, documented, exercised, and maintained. Supplies matter. Equipment matters. Procedures, training, testing, and fallback paths are what turn those components into something dependable.
Build complete systems
A collection of equipment is not a system until its dependencies, procedures, limitations, and failure paths are understood.
Test the assumptions
Product specifications and coverage maps are useful starting points. They are not substitutes for measurement and field experience.
Maintain the record
The documentation changes when the system changes. Old conclusions are corrected instead of quietly left to rot.
Who I am
I am Eric Howell, a broadcast engineer, automation engineer, systems integrator, software developer, and amateur-radio operator based in Goodyear, Arizona.
My professional work has involved live-production systems, broadcast video, automation, testing, networking, control systems, software, and the uncomfortable moment when several unrelated failures arrive at exactly the same time.
Years spent building and troubleshooting systems taught me that equipment does not fail politely. It fails during the show, under time pressure, with incomplete information and several people waiting for an answer. That experience shapes the way Fallback Engineering approaches preparedness: document the system, understand the dependencies, create fallback paths, and practice before the failure becomes urgent.
Working context
- Broadcast and live-production engineering
- Automation and test engineering
- Software and hardware integration
- Networks, control systems, and troubleshooting
- Amateur radio and field communications
- Vehicle, power, and off-grid projects
- Arizona desert and mountain environments
KM7GHS and Grey Operator
KM7GHS is my amateur-radio callsign. Grey Operator is the publishing and project identity used across Fallback Engineering.
Grey Operator represents the workbench, field, radio, vehicle, and systems side of the work. It is not a fictional character and it is not intended to conceal my identity. The name gives the projects a consistent voice while the person responsible for the work remains plainly identified.
The operator is not the point. The system, the evidence, and whether the procedure works when needed are the point.
How the work is developed
01 · Define
Identify the actual problem, the constraints, and what success needs to look like.
02 · Build
Assemble or configure a usable system rather than a disconnected collection of parts.
03 · Test
Exercise the system under realistic conditions and measure what can be measured.
04 · Document
Record the configuration, results, failures, limitations, and recovery steps.
A successful test is useful. A failed test is usually more useful, provided somebody writes down what happened.
Project Pages hold the maintained conclusions. Field Notes hold the dated evidence: installations, measurements, experiments, contacts, trips, failures, and changes.
Editorial principles
- Test before recommending.
- Separate facts, observations, and opinions.
- State assumptions and uncertainty.
- Date configuration-specific information.
- Correct old conclusions when the evidence changes.
- Explain tradeoffs instead of declaring universal winners.
- Avoid fear-based marketing.
- Prefer maintainable systems over impressive equipment piles.
- Use primary documentation whenever practical.
- Never hide a failure because it makes the project look untidy.
Current areas of work
Preparedness
The 72-Hour Plan, water, food, power, temperature, transportation, documents, pets, and practical household continuity.
Communications
Amateur radio, KM7GHS station development, mobile radio, APRS, DMR, Fusion, AllStar, EchoLink, antennas, and field procedures.
Field systems
Jeep-based systems, portable power, Meshtastic, off-grid messaging, computing tools, software, and experiments that escaped the workbench.
Arizona is part of the test environment
Fallback Engineering is based in the Phoenix West Valley. That location materially shapes the work.
Extreme heat, long travel distances, vehicle dependence, desert exposure, wildfire, monsoon weather, mountain terrain, electrical noise, and the large difference between urban and remote communications coverage all create practical engineering constraints. Cooling, water, mobile power, radio coverage, transportation, and offline information are not abstract preparedness categories here. They are ordinary operating requirements.
Corrections and useful disagreement
Technical corrections are welcome. Configuration details change, equipment behaves differently in different environments, and no single setup is universal.
When a correction is supported, the maintained document will be updated and the change recorded. The material on this site is a practical starting point, not a substitute for local requirements, primary documentation, professional advice, or testing against your own conditions.
Contact and profiles
- GreyOperator@fallbackengineering.com
- KM7GHS on QRZ
- Amateur-radio callsign: KM7GHS