Hello and very warm welcome on behalf of NTi Audio! Today we are talking about test concepts for smart devices. Let me please introduce myself:
my name is Markus Becker I will present this webinar and I am assisted today by Greg Schmidle,
our product manager. He is taking care of your questions and comments during the presentation and further on. We have prepared a couple of topics for this webinar, starting with a definition of smart devices, and some typical examples. Then we will explain the
difference between closed loop testing and open loop testing, which plays a key role in this whole concept. We will recommend a test signal, which is very well suited for this application. Then we will come to the key issue of smart device testing, the triggering & the signal acquisition
of the transmitted test signal. Afterwards I will say some words about
typical measurements that are executed and the test procedure that you may follow We have also prepared a practical presentation, wherein we
will show the concrete test procedure
of a smart device. Finally I will give some hints & tips that may be helpful, before I will conclude the webinar by coming back to your questions and providing some comments on our answers. I expect that the webinar will last approximately 1/2 h Let us first take a look on the definition of smart devices. These items typically have an integrated processor, which connects the device to the network, which may be an Ethernet network or a cloud etc. and these d
evices typically have a
built-in microphone and loudspeaker, which allows them to interact with the user. Let me give you some typical examples, starting with smartphones and tablets, i.e. the 'oldest' small devices. Then we have navigation systems and
car entertainment systems. We have smart speakers like the Amazon Echo Dot, but such devices are also available from other suppliers. We have intelligent thermostats or other household devices that may interact with the user via speech control, an
d we have even more exotic devices: speaker bulbs i.e. light bulbs with a built-in loudspeaker that allow to replay music or other applications. All these devices by the way are tested by our FX100 system, i.e. there is a practical connection between these items and our presentation. Now let us take a closer look at the open and closed loop test setup. We start with a closed loop test setup, which is the more commonly used one in the audio testing world. Here we have a test instrument that gene
rates the test signal, which is typically fed into the device under test (DUT) by an electrical connection. The DUT creates a sound via the built-in loudspeaker. That sound / acoustic signal is picked up by the measuring microphone and forwarded to the analyzer, which calculates the measurement results. Well, with smart devices we have the problem that there is no possibility to connect
a generator electrically through the DUT. because this connector is missing! Consequently we have to use the o
pen-loop approach. Here we somehow have to get the test signal into the DUT, from where it is replayed, picked up and analyzed. This setup has two implications. 1) We have to solve the challenge of triggering both the DUT and the analyzer 2) We have to synchronize the analyzer to the incoming test signal. I will tell you more details about these two points within this presentation. Let us first summarize the open-loop
test up. The starting point was that we have a DUT without audio input connect
or i.e. we have to solve the challenge of replaying the test signal from the DUT, and we do that by either saving the test signal on the DUT or streaming it during the test procedure. This gives us two application setups for loudspeaker tests. A) We have a PC that is replaying the test signal through the network or the cloud, from there to the DUT and to the analyzer, so we only have to take care that the triggering of the DUT and of the analyzer is executed correctly. B) The other approach is
shown here: that is the opposite direction. We generate the test signal in our instrument, we replay it through a loudspeaker to the microphone of the intelligent device. From there it is uploaded via the network or the cloud to the PC. Now we have to obey two issues. 1. We have to trigger the DUT correctly 2. We have to make sure that the received signal is replayed to our analyzer in order to allow us calculating the measurement results. Talking about the test signal, we strongly recommend to
use the GlideSweep. A GlideSweep is a sine wave, which starts at a low frequency, which is continuously increased over time. This test signal has several advantages. 1st advantage: it covers the full frequency bandwidth of interest. For intelligent devices this is typically 100 Hz - 10 kHz, but you may also extend this range, e.g. 20 Hz - 20 kHz, or reduce it to the bandwidth of your interest. The 2nd advantage is that you may include a header signal, schematically shown here. The header signal
is typically a superposition of 2 sine waves. So if you look at the spectrum, you can see it has a very significant pattern. The analyzer is now able to detect this pattern and to trigger to it, i.e. to recognize it as a header knowing that the GlideSweep will follow right after the header. The 3rd advantage is that the GlideSweep allows the parallel analysis of several
measurements in one step, e.g. Level and Distortion. This simultaneous analysis of several measurements cuts down the cycle tim
e tremendously. You just have to transmit the GlideSweep once to derive all these results from this single cycle. Now let us take a much closer look on the big issue of smart device testing, namely the triggering and the signal acquisition. The first step is quite easy, you have to trigger the DUT so that it replays the test signal. Some devices may have an manual interface or another way to trigger them - i.e. to replay the signal, e.g. a spoken instruction, but that is typically not the big ch
allenge. The things become more complex on the analyzer side. For instance, we have to arm the analyzer in a way that it is prepared for the incoming signal level. This applies for the input range = sensitivity of the analyzer. Let us assume that the input range is too small, i.e. the analyzer can only cope with very small input signals. But now there is a rather large signal coming in. This would cause clipping in the analyzer, and the clipping would apparently destroy the measurement result. O
n the other side, if the input range is too wide, i.e. if the analyzer could accept huge signals, but the incoming signal in fact is very small, you lose a lot of resolution a lot of measurement accuracy. For that reason you have to adjust the input range properly to cope with the level of the incoming signal. The second thing you have to consider is the triggering to the incoming signal. The analyzer has to start sampling the incoming signal at the right time, i.e. it must recognize the header
of the incoming signal correctly. Let us imagine that we trigger the DUT and we would simultaneously trigger the analyzer, but there is a time delay in between (for whatever reason). In that case the analyzer must be able to wait until the signal is actually coming in, before it starts sampling. The third important aspect to be considered is the synchronization of the analyzer with the sampling frequency. The reason is that the sampling
frequency of the DUT could be different from the one of the
analyzer. This difference could cause frequency shifts or other effects that will falsify the measurement results For that reason it is important that the analyzer synchronizes to this sampling frequency, and that is done via the header of the GlideSweep. The header has a frequency information included that can be used by the analyzer to synchronize itself Now a brief look on typical measurements. We start with the Level measurement = frequency response, or the Level @ a specific frequency, e.g
. 1 kHz The second typical measurement would be
the Distortion. You see the Distortion response here in the graph, i.e. Distortion versus frequency, or the THD @ a specific frequency, e.g. 1 kHz but it could also be another frequency. Let us take a closer look at the test procedure. Actually what I am showing you here is
the same what you will see afterwards in the practical presentation We start with the first step, a spoken instruction, which triggers the smart device, which in turn forwards t
his instruction to the cloud. The cloud reacts by playing back the test signal because we want to measure the loudspeaker of the smart device. Thus, the replayed test signal will be picked up by the microphone and then the analyzer can calculate e.g. the corresponding frequency response. Thus, we trigger the DUT with a spoken instruction and we trigger the analyzer with the incoming test signal that includes the header of course. Let us take a look at the microphone test procedure, which looks a
little bit different. We start with a spoken instruction + the appended test signal, because we want to measure the microphone of the DUT. So this item picks up the signal and forwards the test signal only to the cloud. This is done due to the spoken instruction. Now the cloud plays back the test signal to our computer, from where we can then replay it to the analyzer, which then calculates the measurement results. I will show you these 4 steps in my practical presentation, which is due now. Le
t me first briefly summarize the items and need for this presentation. We are starting with a controller PC, which is connected through our FX100 analyzer. We have an active loudspeaker, which is used to replay the speech instruction as well as the test signal We have an Amazon Echo Dot as an example for a smart device, which is connected to the Amazon Cloud. We have a microphone to pick up the sound that is generated by the Amazon Echo Dot and we have a mobile phone, which interacts with the cl
oud and allows us to replay the recorded signal to the analyzer. This is the FX-Control software, which allows us to control the test instrument, and I have also added a small webcam so that you can watch the setup in reality. I guess you can see the FX100 instrument, you see the measurement microphone, the active loudspeaker, the Amazon Echo Dot, which is our DUT, and the mobile phone, which interacts with the Amazon Cloud. I will now switch my microphone to the webcam so that you can listen to
all the signals and spoken instructions that are executed in this test setup. "Alexa: ask MyMedia to play test signal" "Playing the tracked test signal from your MyMedia collection" [GlideSweep test signal] "Alexa" - [GlideSweep test signal] I hope you could follow the procedure. Maybe you noticed that there was also a manual interaction: I had to trigger my mobile phone to replay the recorded GlideSweep from the microphone test. Let us take a closer look at the sequence. You see that here, thi
s is a four-step sequence, starting with the instruction to pick up the test signal and forward it to the cloud, then to replay it for the loudspeaker test, to record the signal for the microphone
test, and to replay the recorded signal for the analysis. I will now redo the whole procedure. "Alexa: ask MyMedia to play test signal" "Playing the tracked test signal from your MyMedia collection" [GlideSweep] "Alexa - [GlideSweep]" Here I'm back again. Let us take a look at the acquired results. Her
e we have the loudspeaker test results, we have the frequency response of the loudspeaker of the smart device, we have the sound pressure level at 1 kHz, we have the Distortion response and the THD @ 1 kHz That was a loudspeaker test. The microphone test looks very similar. We have the frequency response of the microphone, the Distortion response the Level @ 1 kHz and the Distortion @ 1 kHz, too. Let me get back to the slideshow. and to application hints that I wanted to share with you. The firs
t is the issue that needs to be considered is that every type of DUT requires its own individual test procedure, depending whether the device has a built-in microphone/loudspeaker or not, how it interacts with the cloud or the network etc. If you need any support in this aspect, please don't hesitate and contact us, we will be happy to support you Second, we may provide test sequences, e.g. for the Amazon Echo Dot that you see here on my desk. This simplifies the whole setup procedure for you La
st but not least, normally you want to apply a PASS/FAIL test, which means you want to sort out the bad = not good working devices from the good ones, For that you need tolerance limits / acceptance criteria. We have actually already held a webinar on this issue a couple of months ago. You may find the webinar recording on our website. That webinar covered the issue of starting with the frequency response e.g. of a good working device, and explains how to create a tolerance band that allows you
to establish this PASS/FAIL test. Well, I am at the end of the presentation. I want to remind you that we have a couple of partners and subsidiaries all over the world, which will be happy to support you or your customer at any time when you need it, so please don't hesitate and contact us. I would like to thank you very much for your attention I hope I was able to answer most of your questions and I would be happy to meet you again at one of our future webinars.
Comments