This page is for product teams, OEMs and exhibition owners who want to prototype a voice interaction device on low-cost hardware such as the ESP32. Open firmware puts a first prototype within reach, but the device is only the start of a service: speech recognition, models, content and credential management decide whether it keeps working.
CNPS helps define the prototype scope, map dependencies and plan tests. Open-source projects such as XiaoZhi ESP32 are technical references, not a CNPS product supply or service contract. A working prototype is not a mass-production commitment; product testing, supply and commercial rights are assessed separately.
Where this fits
Reception or exhibition Q&A terminal
Visitors ask about exhibits, directions or opening hours by voice. Evaluate wake-up and recognition in noise, interruption handling and who is responsible for content updates.
Voice companion prototype for an existing product
Add a voice entry point to a current product and check whether users accept it. Evaluate the acoustic fit of microphone and enclosure, latency and the service cost of each conversation.
Multilingual reception
Serve Chinese, English or Arabic speakers. Evaluate recognition in each language, speech synthesis quality and language switching, and whether the content is authorized.
The expected output
A prototype scope and dependency checklist
What to share
One intended task, users, languages, acoustic conditions, expected volume and maintenance owner.
What to evaluate
- Specify microphones, speakers, power and network.
- Map speech, model and content service dependencies.
- Test interruption, noise and network loss.
- Plan firmware recovery, credentials and service cost.
How the evaluation runs, step by step
- Fix one task and authorized content
Do one thing only, such as answering questions about a single product line. Prepare authorized content and expected questions, and state the intended users and volume. - Specify hardware and the dependency list
Use the voice prototype specification to list microphone, speaker, power and network needs, and map the provider, region and billing of every speech, model and content service. - Test in the real acoustic environment
Test noise, distance, interruption and network loss where the device will actually be used. Record recognition errors, response latency and recovery instead of demonstrating in a quiet office. - Plan the lifecycle before discussing the next step
Agree firmware recovery, credential rotation, service shutdown and content updates, and estimate the monthly service cost per device. Then discuss product testing, supply and commercial rights.
Common mistakes
- Counting only hardware cost
ESP32 boards are inexpensive, but recognition, model and synthesis services bill by usage. Record the cost per conversation during the prototype so it does not escape control after rollout. - Rolling out after a quiet-room demonstration
Exhibition halls, receptions and street fronts differ enormously in noise and echo. A prototype untested in its target environment is not a basis for deployment. - Ignoring license and trademark boundaries
The firmware’s open-source license does not cover the cloud services, voices, product design or trademarks used. Check each item before a public release.
What to record during the pilot
Write these down before the test starts, so the decision rests on numbers you collected rather than on impressions.
- Wake and recognition errors by environment
Count false wakes, missed wakes and misrecognized requests at the real location, separately for quiet periods, peak noise and each language. - Response latency
Time from the end of the user’s sentence to the start of the spoken reply. Record the median and the slowest cases, and note which service caused the delay. - Interruption and recovery behavior
Log what happens when a user interrupts, when the network drops mid-reply and when the device restarts, and how long it takes to become usable again. - Cost per conversation and per device per month
Sum recognition, model and synthesis charges for typical exchanges during the prototype and project them to the expected volume. - Content coverage and refusals
Track how many real visitor questions fell inside the authorized content, how many were refused correctly and how many were answered outside scope.
Key terms on this page
These terms are used in the same sense on this page, in the linked resource and in our quotations.
- Wake word
- The phrase that switches the device from listening for its name to processing a request. False wakes in noise and missed wakes at distance are both measured.
- Speech recognition (ASR)
- The service that turns speech into text. It is usually a cloud service billed per minute or per request, with its own language coverage and region.
- Speech synthesis (TTS)
- The service that produces the spoken reply. Voice quality, language support and licensing for public use are separate questions.
- Barge-in / interruption handling
- What happens when a user speaks while the device is still replying. Poor handling makes a demo feel slow in real use.
- Dependency map
- The list of every external service the device calls, with provider, region, credential owner and billing, so nobody is surprised when one changes.
- Cost per conversation
- Recognition, model and synthesis charges added together for one typical exchange, then multiplied by expected volume per device per month.
- Firmware recovery
- How a device is updated or restored in the field when firmware, credentials or a service endpoint changes, without sending it back.
- Authorized content
- The questions the device is allowed to answer and the material it may answer from, agreed with the content owner before the prototype goes in front of people.
What to confirm
A working prototype is not a mass-production commitment. Product testing, supply and commercial rights must be assessed separately.
Common questions
Will CNPS manufacture the voice device for us?
In the prototype phase CNPS helps define scope, dependencies and tests. Mass production involves product testing, supply, certification and commercial rights, which are assessed and agreed separately after the prototype is validated.
Is the prototype suitable for children or the public?
A working demonstration does not establish content safety, child suitability or regulatory conformity. Assess content boundaries, privacy and safety specifically before a public deployment.
Does the device work when the network is down?
It depends on the architecture. Most voice functions rely on backend services, so the device needs clear prompts and recovery behavior during disconnection. This case must be covered in testing.
Which hardware do we need for a first prototype?
An ESP32-class development board with a microphone array, a speaker and stable power is usually enough to test the interaction. Enclosure acoustics and industrial-grade parts become relevant only after the task and environment are confirmed.
Can the device use our own model or knowledge base?
Usually yes, because the firmware calls backend services you configure. The question to evaluate is whether that backend answers correctly within acceptable latency and cost, which is tested the same way as a knowledge assistant.
What should we prepare before the field test?
The authorized content, a list of expected questions, the target location at its busiest time, a way to log every exchange and the person who will judge which answers were acceptable.
Continue exploring
Industry references are not presented as CNPS customer deliveries.