Restaurants & Hospitality
The microphone worked perfectly until the room filled up
It kept testing fine and kept failing in use, so it kept getting replaced. Nothing was ever wrong with the microphone. The fault was where the receiver had been put, and the manufacturer's own installation instructions had said so from the beginning.
Verified engagement. Every claim on this page traces to a document, a publication or a system somebody can open, and we can arrange a direct reference call for a shortlisted engagement. The work was done by the engineers who founded this firm, in most cases before the firm existed, which is why the dates below predate it. Client names and identifying details are withheld under NDA unless the client has agreed to be named.
- Client
- 12 Cuts Brazilian Steakhouse, a Dallas restaurant and private event venue12cutssteakhouse.com
- Duration
- One visit, one hour
- Team
- 1 engineer
- Year
- 2026
The situation
What we walked into.
Staff reported the wireless microphone cutting out during service and during large private events. It was read as a hardware fault, which is the reasonable first reading, and the system was replaced more than once on that basis.
An IT contractor had already been out. They tested the equipment, found it working correctly, and left — which was an accurate test and the wrong one. The next time the room was full, the microphone failed again.
By the time we were called, the venue had spent real money replacing equipment that had never been faulty, and had good reason to believe the next replacement would not work either.
Approach
How it was sequenced.
Each step had to be independently valuable. That constraint is what let the client stop at any point without being stranded.
- Step 01
Reproduce the failure, not the equipment
The fault only appeared under conditions a bench test removes: the receiver in its installed position, and a room with people in it. So we stopped testing the microphone and started testing the installation, in place, under load. A component that passes every test and fails every event is telling you the component is not the variable.
- Step 02
Follow the signal path
Traced the path from the handheld transmitter to the receiver's antenna rather than the list of parts. Two obstructions turned up, and both were siting rather than hardware: the receiver was installed inside a closed cabinet, and during larger events a standing crowd sat directly between the presenter and that cabinet.
- Step 03
Do the arithmetic
The system operates around 580 MHz, which puts the wavelength near 52 cm. At that scale UHF does not usefully bend around an obstacle the size of a cabinet, and it does not pass cleanly through a room full of people — bodies are largely water, which absorbs these frequencies rather than letting them through. A clear line of sight between transmitter and receiving antenna is not a best-practice suggestion at this frequency; it is the condition the link is designed around. That is also why the failure tracked audience size, and why it disappeared every time someone tested an empty room.
- Step 04
Read the manual, then move the receiver
The manufacturer's installation section already said not to enclose the receiver. The fix was to mount it high and clear of the cabinet, with an unobstructed path to the floor the microphone is actually used on. No equipment was purchased, and nothing was reconfigured beyond where the box sits.
What was built
The parts that mattered.
- The fault was load-dependent, which is precisely why every bench test cleared it.
- A closed cabinet and a standing crowd are both attenuators at UHF, and the two together were more than the link budget could absorb.
- The manufacturer's installation instructions had already ruled out the cabinet.
- Diagnosis cost less than the replacement hardware it made unnecessary.
Results
Measured, with the method stated.
Every figure below has a defined measurement window and a comparable baseline. Numbers without those are just adjectives.
- Spent on hardware to fix it
- $0Spent on hardware to fix it
- Where the fault actually lived
- Under loadWhere the fault actually lived
- Where the answer already was
- In the manualWhere the answer already was
Built with
Services involved
More work
Related engagements.
- 2024About four weeks
The scanner read every barcode except theirs
They had no way to say who was holding what, and a barcode scanner that would not decode their own label format — the capability was licensed separately and they had declined to buy it. Writing the decoder in C cost less than the licence and made the rest of the system possible.
Read the case study- Trackable, in and out, by holder
- Every item
- Bought to read their own labels
- No licence
- 2024–presentOngoing, still in service
Relative numbers nobody could use, referenced to magnetic north
Autonomous vehicle testing was producing position and rotation relative to wherever the vehicle happened to start, which made every run internally consistent and impossible to compare against any other. Referencing the whole system to magnetic north turned it into data a person could reason about — and it is still collecting.
Read the case study- Position and rotation, not relative
- Absolute
- Never decommissioned
- Still running
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether you should be building this at all.