# phyphox Forums

Full Version: Calibration uncertainty query
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
We have been using Phyphox to generate tones for an Advanced Higher experiment to establish the speed of sound. It has been very successful. For the write up the students need to quote uncertainties in scale and calibration, could you help us out â€“ or is it phone dependent?
There are two aspects to this. One is the temporal accuracy of the playback rate, which is indeed device dependent. However, in my experience, this is very precise up to the point where I can not think of any situation in which I noticed any uncertainties. If you want to put it to the test, you might want to try and create a sound file with a click every second that runs for several minutes, which you can compare to a clock. (You can search for "click track generator" for musicians.)

The other aspect is the current limitations of the phyphox tone generator. The way it works at the moment (what we intent to improve soon) is that it generates a short audio track that loops. If you are using frequencies that are an integer fraction of the sampling frequency (usually 48 000 Hz), this works perfectly. So, for example, if you set the tone generator to 440 Hz, a single period would consist of 48000/440=109.0909 samples, which of course is not possible. Phyphox tries to mitigate this problem by calculating 100 periods (you can see these in the graph of the tone generator), so it creates 10 909 samples, which corresponds to a frequency of 48000/10909*100=440.0037 Hz, which is still very accurate (and probably better than the internal clock of the temporal accuracy).

Of course, this deviation strongly depends on the frequency. On one hand, phyphox will never calculate a waveform that is longer than one second. So, if you enter 0.9Hz, you will still see a one second loop, which will result in a 1 Hz tone with some clicking as it is not perfectly periodical. This of course is an extreme example, but at 50.5 Hz you get the same problem as phyphox tries to create 100 periods and stops after one second. You get a weird hybrid of a 50.5 Hz signal, which has an addition 1Hz periodicity with a click. At the other end, at high frequencies, you get the problem, that the 48.000 Hz sampling is not enough to sample the waveform. If you look at 11.000 Hz, you see a jagged waveform, because we do not always hit the peak of each period. This can even lead to beating patterns of the sampling frequency and the tone frequency (for example at 8040Hz). Here we also get the problem, that the 8040Hz are not an integer fraction of 48000 and with 100 periods, we create 1176 samples, resulting in 48000/1176*100=4081,6 Hz, which is more significant.

So, at the moment, the error from phyphox is rather complicated and depends a lot on he frequency you used. But in most experiments, at least if you are using "normal" frequencies, it is not the dominating source for uncertainties. Can you give some more details on how your experiment works?
(03-12-2020, 09:56 AM)SebastianÂ Staacks Wrote: [ -> ]There are two aspects to this. One is the temporal accuracy of the playback rate, which is indeed device dependent. However, in my experience, this is very precise up to the point where I can not think of any situation in which I noticed any uncertainties. If you want to put it to the test, you might want to try and create a sound file with a click every second that runs for several minutes, which you can compare to a clock. (You can search for "click track generator" for musicians.)

The other aspect is the current limitations of the phyphox tone generator. The way it works at the moment (what we intent to improve soon) is that it generates a short audio track that loops. If you are using frequencies that are an integer fraction of the sampling frequency (usually 48 000 Hz), this works perfectly. So, for example, if you set the tone generator to 440 Hz, a single period would consist of 48000/440=109.0909 samples, which of course is not possible. Phyphox tries to mitigate this problem by calculating 100 periods (you can see these in the graph of the tone generator), so it creates 10 909 samples, which corresponds to a frequency of 48000/10909*100=440.0037 Hz, which is still very accurate (and probably better than the internal clock of the temporal accuracy).

Of course, this deviation strongly depends on the frequency. On one hand, phyphox will never calculate a waveform that is longer than one second. So, if you enter 0.9Hz, you will still see a one second loop, which will result in a 1 Hz tone with some clicking as it is not perfectly periodical. This of course is an extreme example, but at 50.5 Hz you get the same problem as phyphox tries to create 100 periods and stops after one second. You get a weird hybrid of a 50.5 Hz signal, which has an addition 1Hz periodicity with a click. At the other end, at high frequencies, you get the problem, that the 48.000 Hz sampling is not enough to sample the waveform. If you look at 11.000 Hz, you see a jagged waveform, because we do not always hit the peak of each period. This can even lead to beating patterns of the sampling frequency and the tone frequency (for example at 8040Hz). Here we also get the problem, that the 8040Hz are not an integer fraction of 48000 and with 100 periods, we create 1176 samples, resulting in 48000/1176*100=4081,6 Hz, which is more significant.

So, at the moment, the error from phyphox is rather complicated and depends a lot on he frequency you used. But in most experiments, at least if you are using "normal" frequencies, it is not the dominating source for uncertainties. Can you give some more details on how your experiment works?

Thanks for your reply. We used the phone to generate a sound of known frequency. This was played (through a 100 W amp) at a Kundt's tube containing some cork dust. The length of the tube was adjusted until a maximum volume was reached, at which point the cork dust vibrated at the antinodes, allowing us to measure the wavelength, and hence calculate the speed of sound. We were using "normal" frequencies (600-2500Hz) - so it sounds as if the error is not going to significant.