In the previous article, I described how a proof of concept revealed that allophone synthesis wasn't the right technology for industrial voice alarms — and how OKI's ADPCM chips offered a path to something better.
Now came the harder part: building an actual product.
There's a significant difference between a working prototype and a shippable product. Most of what I learned about embedded engineering I learned in that gap.
Architecture First
Before writing a line of firmware or laying a single trace, I defined the complete system architecture.
The TGV-101 needed to accept alarm codes from a PLC, reproduce pre-recorded voice phrases, display status on an LCD, accept operator input via a four-key menu, and — optionally — transmit voice messages over the analog radio networks already present in most industrial facilities.
That last item required a radio interface that could mix voice audio with addressing tones and trigger the radio's push-to-talk contact, essentially emulating a microphone. A technically strong friend helped me work through that problem. The solution was a modular tone interface board that could be swapped to support either of the two common addressing schemes of the era.
The system settled into three boards: main, user interface, and radio interface.
The Tool That Changed Everything
While waiting for components — sourcing specialized parts in Mexico in the early 1990s required patience — I built a development tool that paid for itself in the first week.
Instead of programming a physical EPROM, erasing it under UV light, and reinserting it for every firmware change — 15 minutes per cycle — I built an EPROM emulator that connected to the printer port and loaded new firmware in seconds.
Iteration time dropped from 15 minutes to near-zero. Six months of firmware development became manageable because of that one tool.
This is a pattern I've repeated throughout my career and that we apply at EXPERTiS today: the best embedded teams build the tools that make the work faster. Tooling isn't overhead — it's leverage.
The Firmware Challenge
Bring-up firmware — validating that all hardware subsystems worked — took about three weeks.
The application firmware was a different problem. The TGV-101 needed a menu-driven interface with multiple screens and configuration options. In 1990s embedded development, there were no UI frameworks. I designed one from scratch: a lightweight structure that defined screens, navigation, and input handling in a way that made adding menus straightforward.
It took six months. But by the time it was complete, the system worked correctly across every use case the product needed to handle. No shortcuts at the architecture level means fewer surprises in the field.
What Shipped
The TGV-101 went into real industrial installations. The PLC placed an alarm code on the parallel port, the system looked up the corresponding voice sequence, and the message played — either locally through a PA amplifier or directed to specific personnel via radio.
The audio library was recorded by a professional voice — clear, authoritative, exactly the quality the proof of concept feedback had told us we needed. Each unit was semi-custom: the message library compiled directly into the firmware for each client's specific alarm conditions.
It wasn't a perfect product. Field configuration required engineering support. But it was a complete embedded product: defined requirements, structured architecture, custom hardware, custom firmware, real installations.
What That Cycle Still Teaches
Validate before committing to architecture. The proof of concept saved months of development on a product that would have failed in the field.
Build your tools. An investment in development infrastructure pays back on every iteration.
The user experience is a technical requirement. The feedback about urgency and emotional connection wasn't a soft concern — it was a specification.
Plan for the next version from the start. Every manual process in the TGV-101 became a design requirement for what followed.