> ## Content Index > Fetch the complete content index at: https://sreekars-journal.labvion.com/llms.txt > Use this file to discover other available public pages before exploring further. # Two short words, and everything the microphone hears around them - URL: https://sreekars-journal.labvion.com/tm01-on-off-and-everything-else/ - Published: 2025-10-16T12:30:00.000Z - Updated: 2026-10-29T08:26:52.000Z - Description: OFF, ON and noise are the three classes in the exported voice model. The application begins with a one-second audio window: 16,000 raw samples at 16 kHz. After feature processing, the model has a 650-value input and produces predictions for those three labels. That’s a much more interesting rou - Author: Sreekar - Tags: TinyML, #Import 2026-10-29 10:08 OFF, ON and noise are the three classes in the exported voice model. The application begins with a one-second audio window: 16,000 raw samples at 16 kHz. After feature processing, the model has a 650-value input and produces predictions for those three labels. That’s a much more interesting route than the short label list suggests. The project combines an INMP441 microphone, an ESP32-family board, Edge Impulse and a PPK2 power profiler. I want to understand both the sound-to-prediction route and its electrical cost. The model can run on a small device, but neither the microphone nor the power measurement disappears once the classifier starts. Each stage changes what the next one receives, and a prediction at the end does not explain the route by itself. The idea is to do the classification on a small device rather than treat the microphone as something attached to a much larger computer. The project uses an INMP441 microphone, an ESP32-family board and a model prepared through Edge Impulse. There’s also a power profiler because I want to connect the software work to the electrical energy it takes. I'm deliberately keeping recognition separate from any action after it. A prediction of ON isn't, by itself, proof that an appliance has been controlled correctly. First I need to understand how the device gets from audio samples to a label. Otherwise it would be easy to make a demonstration look convincing while leaving the part that produces the decision quite mysterious. ![TinyML hardware photograph: controller assembly, microphone and Nordic power profiler. Exact board identity, wiring and individual contribution require confirmation.](https://sreekars-journal.labvion.com/content/images/2026/10/IMG09.jpg) TinyML hardware photograph: controller assembly, microphone and Nordic power profiler. Exact board identity, wiring and individual contribution require confirmation. The first stage is sound becoming samples. The microphone supplies digital audio, and the program has to read it in the right format. That sounds like a small piece of setup until I notice that the values may need scaling before the next stage can use them. The model cannot correct every mistake made before the audio reaches it. After that comes feature processing. Instead of handing a classifier an unexplained list of raw microphone numbers, the setup uses MFCC features. I'm still working through what that processing keeps about the sound. For now, the important point is that the model is trained on one representation, and the live device has to produce a compatible representation too. Then the classifier produces predictions across the three classes. This is where the simple label list becomes awkward again. ON and OFF have fairly clear meanings. Noise is everything represented by that class in the data, not a magic name for every sound that could ever happen near the microphone. If the examples are narrow, the name doesn't make them broad. I can picture a recording that makes this difficult: a chair moving or somebody speaking another word that shares part of the sound. The point is that ordinary surroundings contain much more than silence and two neatly separated commands. The training data therefore feels like part of the device, even though it isn't a physical component on the board. The microphone, the recordings, the feature settings and the classifier all affect the result. If I only look at the neural network, I could spend time changing the last stage while missing a problem in the first. There are also two different success questions. One is whether the device predicts the intended word reliably under conditions I have actually checked. The other is how much time and energy it takes to do the work. A fast prediction that mistakes background sound for a command isn't very useful. A good validation score doesn't tell me the energy cost either. I need separate evidence for each question. This is why the power profiler interests me. Code usually feels invisible while it runs. A current trace gives me another way to look at activity on the board. But I can't just point at a peak and call it the neural network. Audio capture, processing, output and waiting can all draw power. The program's stages have to be matched to the interval I'm measuring. Edge Impulse handles much of the model preparation and export. That gives me a way to work with a real device without pretending I have written every training tool myself. There’s still plenty left to understand: what the model expects, how the application supplies it and what the numbers coming back actually mean. My mentor can help when I lose the connection between those stages. Examples in the documentation are useful for a smaller question, such as a sample conversion or a processing step. I want to keep the actual configuration beside those explanations so I don't accept a clear answer to a slightly different setup. Even the word local needs an explanation here. The exported model can run on the board, but that does not mean the whole training process happened on that small device. Edge Impulse provides the model preparation and generated inference library; the library identifies the platform as author and maintainer. That credit is part of understanding the work. The application still has to fill the expected audio frame and supply compatible samples to feature extraction. A 16,000-sample recording and a 650-value model input describe different stages of the same route. Recognising those stages lets me ask where an unexpected prediction begins instead of treating the entire system as the neural network. For this first part, I'm leaving the whole project in view but starting with the microphone. It gives me one thing I can inspect before adding the model's decisions. The three labels are still a useful place to begin. They just don't make the route to a working voice device as small as the list looked.