In the version 20190830 awake detection has changed and it is too aggressive now. Now several hours are wrong marked as awake in total and this is very wrong. Awake detection was more or less OK before this new release.
Support wrote me in my case looking into the activity log this awake detection is related to talk detection and heart rate. I will disable talk detection this night, but I would like to use heart rate detection with my MI band 4.
Did you change the heart rate influence on awake detection? Maybe you should implement a threshold for HR-is-showing-awake to make it less aggressive or to adapt it individually?
Last night I disabled talk detection and now all is fine, no awake was detected because there was no awake.
1 Like
Big thanks for reporting this. I hope we have just released a fix for this. I think the issue may be that on some devices we can suffer significant false positives on certain type of sound classification… such as talk in this case…
We have adjusted thresholds which trigger talk based awake detection in version 20190903… would you be willing to re-enable the option and let us know how this version works for you? I guess the update will arrive shortly…
Many thanks
1 Like
I can try when the new version will be delivered. But I am very sceptic regarding talk detection. In the last few years I got dozens of talk detections every night but I never found any talk when I checked the recordings. Snorring detection works fine but talk detection gives nearly only false flag tags in my personal case. Normally I do not speak when sleeping but only when I really awake.
1 Like
This very interesting. On our test devices talk detection works with minimum false positives. But every device’s audio system can add some artifacts which may increase false positives…So IMHO this is probably device specific… we are just working on the 3rd generation neural network for sound classification which we believe should reduce false positives in all sound classes and add some new classes… would you be willing to give it a try and let us know if it addresses the issue? Also would you share some of the recording which are falsely classified as talk?
1 Like
I would like to support this process.
How I should share my recordings (by Email?) and how I could try your last NN logic?
1 Like
Big thanks for the offer to help.
Could you please send the wrongly classified files to support@urbandroid.org? We will test them with the Gen 2 or Gen 3 networks and probably add them to the negative set to improve this case.
To participate in the 3 gen network experiment I can either put your IMEI to that experiment in the next BETA, or I can deploy an alpha version for you. In the first case I would need you to provide the IMEI number to support@urbandroid.org. In the later case I would need to know your Play Store Google account email at the same address.
Would that work?
Many thanks…
Did you get the audio files and my IMEI?
Hello Germo, I’m preparing a new BETA just now, you should be in the experiment for the new sound classification. I just think the sensitivity settings in Settings > Noise recording > Sound recognition may not yet be fully utilized… this may happen in the next BETA probably…Big thanks for your feedback…
Helo Germo,
my collegue just tried your recordings and indeed the old neural network produced a lot of false positives o them, but the new network seems to work well and does not missclassifies them… big thanks for help on this…
1 Like
This sounds great, I hope the new beta will be available soon in my play store account for download
It is a little bit better with the last beta, but there are still too much false detections.
Maybe one reason is the noice threshold setting which does not work? I increased the threshold every night by 10%, my current setting is 50%, but it looks like the setting has no effect. I can’t exclude low noice events from recording.
And yesterday I did a test at daytime and some talk was detected, but only with volume boost it was possible to hear, these have been talks in other rooms by other persons.
Please make the noice threshold settings work and show the noice level in noice recording diagrams. Currently noice diagrams looks similar for very low volume recording and for high volume level recording.
This will not solve all issues with wrong talk detections because they also occur on high volume recordings. But maybe you should pre filter noice data for talk detection a little bit more by volume if low volume talk is one reason of false detection.
Hello Germo,
I think tehre is an explanation for this… The recording threshold is used as a simple trigger for recording whenever the volume gets higher than that. The settings contril the first half of the volume so over 50% we record anyway even with a threshold of 100%…This seems to work well on most phones out there even we had few similar reports in the past.
Anyway when sound recognition senses any of the tracked sounds it also triggers recording regardless of volume. So if you have a lot of false positives you will get a lot of recordings even with a high threshold and the threshold setting will play a negligible role…
Noise recording threshold has no effect on the noise graph… this will simply show the volume of the recording regardless of the volume…
Can you please share once again some recordings with new classifier? I cannot promise we can solve this as this is apparently some device specific artifact in the sound system of a particular device, but we can try to teach the networks more robust to that specific kind of artifact maybe…
Many thanks for the feedback…
Oh one more question? Did you try to play with the sensitivity settings of Talk detection? This is basically something like the volume threshold but specifically for talk detection, you can find it in Settings > Noise recording > Sound recognition > Talk… you can try to set low sensitivity…
All of the settings already have effect on classification apart from snoring which will be added later on with the next BETA maybe…
Hello Germo,
one more think I just realized you need the phone permission granted to the app to be in the BETA experiment. No I believe you are actually not in the experiment after all… without the permission we cannot validate your IMEI and put your to the experiment I forgot about this sorry…
I you quickly see if you are in the experiment is Settings > Sleep noise recoridng > Sound recognition… if there you use a checkbox you are in the old version… if this takes you to another screen where you can fine tune which sounds are classified and with what sensitivity you are in the experimental version…
Also we did test your original false potives and they do produce nearly no false positive in the new version so I believe the isseu shoudl be mostly gone with the new classifiers…
Now I granted phone permissions, I hope this will allow me to get the new beta with talk detection threshould settings. Currently I have an older version without talk detection threshold settings.
BTW, what you write also explains my issues with anti snorring: noice threshold has no effect on snorring detection. Snorring detection is done also on low volume recordings, and I get to lot anti snorring.
If you implemented a talk detection threshold: maybe you can also implement a snorring detection threshould? This should solve the anti snorring issues.
1 Like
Thanks for the information…
android training in nagpur
Yesterday I got the last beta and noice classification works much better now, no more false talk detection. It’s a big improvement.
There is a bug now showing an empty graph in the overviews until the detaild graph has been watched several times, I sent a Screenshot in an individual error report.
Now it would be great if you will also add some more settings for anti snorring: trigger level, repeating,…
I seem to have the opposite issues. My awake periods are not being recorded at all. I hate to have to reach for my phone, unlock it, then manually press the pause in the app to record a wake period.
Sometimes I check and it does accurately report me as awake but I am not sure how and what triggers it to work sometimes but not most.
So I know I wake up a lot more than before. I know when I had the first free trial app it seemed to report my awake times much more accurately without me having to do a thing.
Now with this beta app I am getting no awake periods that show any duration of awake time unless I manually use the pause feature which is a pain to do when I wake up and want to really try to go back to sleep which fails some of the time.
Why this change? I have activated every single awake detection feature on the list in the settings.
There are even times my 21 mo old toddler wakes me up with her crying and I even talk to her yet it shows up on my graph as me being asleep despite the talking and noise disturbance.
Would love to know why it is not working for me much at all then. Should I turn the sonar volume up and what is the best minimal amount of signal strength I should have to improve awake detection without my manually having to record it?
The point is, is that it used to work just fine but now it doesn’t seem to work at all. Sometimes I have an hour where it takes me to fall back asleep after waking yet that lost hour isn’t recorded in my total sleep time at all, so it always makes it seem like I am getting better and more sleep than I really am.