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.
- Client
- 12 Cuts Brazilian Steakhouse, a Dallas restaurant and private event venue12cutssteakhouse.com (opens in a new tab)
- 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 we sequenced it.
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
What changed, and how we know.
1 of the 3 below are measurements, each against a stated baseline. The rest are states of the delivered system rather than numbers, and are written as such rather than dressed up as figures.
- Spent on hardware to fix it
- $0
- Where the fault actually lived
- Under load
- Where the answer already was
- In the manual
Built with
Services involved
More work
Related engagements.
- 2023–202520 months, four phases
One codebase for the public site and the platform behind it
A public-facing site and an internal student-tracking platform, built years apart on stacks nobody still owned. We consolidated them into one application with one design system and one authorization model, and shipped it without a production regression.
Read the case study- Production regressions across the release window
- 0
- Unit and integration tests at handover
- 600+
- 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 license 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 license
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 to run, and where your estate is fine as it is.
- Phone
- (214) 723-2510
- Reply
- A person replies, not a sequence: within one business day, from someone who would be on the engagement.