TLDR for the public: You can contribute to the improvement of sonar. Refer to the paragraph marked with a ^
TLDR for the developers: I am terribly sorry but I can’t quite conclude this whole thing. I’m afraid that you may have to read the entirety of this post. Sorry for that.
TLDR for the person who read my email sending to the support: This content is quite similar but I am not sure what changes I have made. A difference comparator would aid you.
Thank you for reading this “feature request”. It is not quite a feature request, but some usability fixes to sonar. Besides informing everyone (not just the devs) of this potential improvement, I hope to gather information regarding whether you have a bedside table, and whether your device (currently supporting sonar or not) exhibits similar behavior.
I used sonar for the first time since both my phone and power bank had a low battery and I need to charge them. I was amazed at its accuracy but thought that it was strange that I cannot use full volume in the default F18-20 mode without audible popping and clicking but I can in individual frequencies mode. I did some investigations in audacity and found that in F18-20 mode, the app generates pulses that sweep through the frequencies, and in individual frequencies mode, the app generates a single frequency continuously. The spectral analysis reveals that the popping occurs on the falling edge of the pulses. I then used a signal generator and discovered that for each volume level (and maybe for each frequency) a different amplitude fade-in speed is needed to prevent audible popping and clicking.
Here is the proposed solution. Similar to ClearType, the user can be presented with a series of Yes/No questions on whether the test audio pulse emits a popping and cracking sound. In doing so, sleep as android can narrow in the optimal settings for the fade-out (and maybe even the fade-in) period of the pulse and use the maximum amplitude that the device allows. Note that from preliminary discovery, it is not necessarily the case that a larger fade-out time necessarily equates to less clicking, so a binary search may not be suitable. Devices that suffer from poor accuracy (excluding devices that actively filter out sonar signals) may be lacking in this feature to make it work.
^ For you who clicked hoping to help test things out, please install Function Generator on Play Store by keuwlsoft. Get used to the UI of that application (I know it is not the best but this app offers manual fade-in-fade-out time control). Use the Sweep function and sweep through 0& amplitude and 100% amplitude. Set the mode to bounce and vary the time. Post the findings below and hope that it contributes to better sonar sleep tracking.
To my knowledge, few people in Hong Kong actually have a bedside table. I am using the sonar feature on a shelf that has a bit of distance from it to the bed. I hope that this feature can help those that can’t use sonar to use it or to make those that are using it have access to the breathing pattern detection feature.
Here is the default text from the topic editor: When creating a new feature request, don’t forget to vote after submitting it!
Hello, this is very interesting. Few years back when we designed the Sonar we have tested it on the Pixel phones at that time and found out that the Hamming window was the best from our experiments to produce least artifacts. But of course this is device specific and depends on the audio system of the device. So one modulation may work better on one device and worse on other… So I guess we could experiment with mode options in the sensor test screen. What did you exactly use to prevent the popping?
I know nothing of Hamming window and would like to learn more from your past experiments.
EDIT: Now I do, it is probably related to the transformation of a signal into its frequency representation. This is, however, only semi-related to our discussion as this discussion mainly focuses on the emission of the sonar signals, not the reception of it. Regardless, discussion is welcome, and more selection options for the user are also good. Moreover, even if the selection of window function is needed, it probably can be automatically solved just by putting the phone inside a cabinet, let it emit various sonar signals, and let the users (or show to the developers) see which is the best. Hence more focus should be put on the emission side, which the phone probably does not realize it is making clicking sounds and needs manual calibration of fade-in-fade-out intervals by the user.
Regardless, I did not achieve full volume with Sleep as Android using mixed frequency mode. I merely discovered on using the Function Generator app that the fading at 0.1-0.15s at full volume caused audio beeps that sounded like a square waveform but I cannot see it on audacity because it is too soft. Those audio artifacts are, however, not the same as the clicks of sleep as android, presumably because it terminates a waveform at its highest amplitude or whatnot. Stopping an ongoing output on the Function Generator does make an audible click, which proves my point. I suspect that the beeps from the Function Generator are because it uses 16-bit audio, yet the ZenFone 6 (my phone) supports 24-bit audio.
I am willing to be a tester for further investigation on the topic, and I acknowledge the risk associated with sending waveforms that are potentially damaging to the speaker system in testing the new sonar.
EDIT 2: additional information: definitely not this effect since that effect demonstrates an audio frequency sweep as the artifact, not my audible click that happens at the end of each pulse. I’ll give spectrum analysis and audio recording of my audible clicking later. Also, I would like to know why is it that using a range of frequencies it must be a pulse yet the app is fine with using a stable tone for a single frequency.
I manually confirm that there is clicking even for the ultra-slow waveform doing 20-24kHz
There are quite a few conclusions to draw here
Apparently, Sleep as Android exhibits the use of frequencies above 20kHz
This device cannot tolerate anything more than 22kHz
Frequencies above 22kHz gets distorted and “Mirrored” back to 22kHz
Upon doing so, audible clicks may occur
The loudness of audible clicks from the result of exceeding 22kHz depends on how “quickly” the waveform exceeds it
Reducing the amplitude removes audio clicks but does not fix waveform distortion in point 3
It may be possible that Sleep as Android is suffering from poor accuracy right now as it attempts to use even higher frequency but is affected, as the waveform from SaA isn’t purely straight line but it seems that there may be some distortion going on
@petr-urbandroid I would like to know whether Sleep as Android actively uses anything beyond 20kHz. If so, consider updating the description in the app to reflect the scenario. I would also like to change my hypothesis from related to fade-in-fade-out to related to frequency change, since more investigation on the spectrum analysis revealed that the click doesn’t occur on the falling edge of the pulse.
@petr-urbandroid F18-20 produces frequencies from 18000 to 22000, hence the audible clicking that only occurs when exceeding 21kHz and why the signal strength of F18-20 is worse than F18, F19, or F20 alone. Will file a bug request since this is NOT intended behavior. Sorry for decompiling your app, it was needed to test my hypothesis
Additional information: sampling rate was selected to be 44.1kHz for this device even though 48kHz was available. It is strange behavior
