01-28-2020, 05:52 PM
In principle, this seems like an interesting idea, but this is a bit more tricky than the acoustic stopwatch.
The acoustic stopwatch works like this:
The recorded audio is handed to phyphox in chunks of about 100ms (I have not checked the exact value, but this also depends on the phone anyway). In each chunk we check whether there is an audio sample that exceeds the threshold. If it does, we locate it within the chunk and use its location to determine the time at which the stopwatch was triggered. We simply have to look for the first sample above the threshold and do not care at all about any other samples after this within the chunk. (This has some disadvantages: We cannot trigger twice within 100ms.)
However, finding the time at which the signal drops below the threshold is not that simple. The reason is that it does so all the time. Any tone or noise oscillates between extreme values and it drops below the threshold in every cycle. So, instead of looking for the first sample below the threshold, we have to monitor a sequence of samples and check whether all of them were below the threshold. How many samples? This depends on the tone you expect. For some random noise, monitoring a period of 1ms might be sufficient, but a 100Hz tone has a periodicity of 10ms, so we get a maximum once every 10ms and should only trigger if there has been no such maximum in a 10ms period. This also means that the resolution could only be 10ms.
This is not really a problem, but a complication for the "ease of use" for this kind of tool. The problem is that this is hard to implement in phyphox. Every experiment in phyphox is defined in our own file format, which does not (yet?) support loops. So we always analyze these 100ms chunks instead of looking at each sample at a time.
So, I cannot really offer you this function right away. However, I intended to improve the acoustic stopwatch anyway (I think I can create a version that does not require a threshold and a minimum delay setting), so I will put you request on my todo list. Unfortunately, this is a big list, so I cannot say when I will look into this.
The acoustic stopwatch works like this:
The recorded audio is handed to phyphox in chunks of about 100ms (I have not checked the exact value, but this also depends on the phone anyway). In each chunk we check whether there is an audio sample that exceeds the threshold. If it does, we locate it within the chunk and use its location to determine the time at which the stopwatch was triggered. We simply have to look for the first sample above the threshold and do not care at all about any other samples after this within the chunk. (This has some disadvantages: We cannot trigger twice within 100ms.)
However, finding the time at which the signal drops below the threshold is not that simple. The reason is that it does so all the time. Any tone or noise oscillates between extreme values and it drops below the threshold in every cycle. So, instead of looking for the first sample below the threshold, we have to monitor a sequence of samples and check whether all of them were below the threshold. How many samples? This depends on the tone you expect. For some random noise, monitoring a period of 1ms might be sufficient, but a 100Hz tone has a periodicity of 10ms, so we get a maximum once every 10ms and should only trigger if there has been no such maximum in a 10ms period. This also means that the resolution could only be 10ms.
This is not really a problem, but a complication for the "ease of use" for this kind of tool. The problem is that this is hard to implement in phyphox. Every experiment in phyphox is defined in our own file format, which does not (yet?) support loops. So we always analyze these 100ms chunks instead of looking at each sample at a time.
So, I cannot really offer you this function right away. However, I intended to improve the acoustic stopwatch anyway (I think I can create a version that does not require a threshold and a minimum delay setting), so I will put you request on my todo list. Unfortunately, this is a big list, so I cannot say when I will look into this.