You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the detection algorithm is biased towards positive signals. Any series of three signal frequencies with acceptable timings is treated as a positive. There is only some awareness of negative indicators like harmonic detection. The result is that some of the tunes can still trigger a false positive. This is not really a problem when using the Sailfish build with the heater tune toggle option, but it is annoying.
Another problem is that playback of M300 commands will likely become less accurate in future releases of Sailfish. This means the detection parameters will need to be made more lenient which again increases the risk of false positives.
To both reduce the risk of false positives while allowing more sloppy timings, I propose to update the detection routine to evaluate groups of 3 possible signals as a whole instead of sequentially.
The false positives I have seen, all have a whole bunch of ignored simultaneous signals. The motivation for this was that a sharp bang on the printer housing must not cause a detection to be aborted, but a sharp bang will only cause 1 or maybe 2 FFT frames with multiple signals, not 10 like I often see in a false detection. So if a candidate sequence has more than 2 simultaneous signals, discard it.
Similar for timings: if the timing of one beep and one pause is somewhat too long but the other timings were perfect, the printer was probably slowed down while playing an actual sequence and it should be accepted. If all timings are suspicious, then it should be discarded.
This can be implemented as a penalty system where each simultaneous signal case adds a score, an each timing flaw adds another score. If the total score exceeds a threshold, discard. A fancy way to determine optimal scores would be to gather a lot of examples and then throw some learning algorithm against it, but good results can probably be obtained as well with some common sense.
The text was updated successfully, but these errors were encountered:
Currently the detection algorithm is biased towards positive signals. Any series of three signal frequencies with acceptable timings is treated as a positive. There is only some awareness of negative indicators like harmonic detection. The result is that some of the tunes can still trigger a false positive. This is not really a problem when using the Sailfish build with the heater tune toggle option, but it is annoying.
Another problem is that playback of M300 commands will likely become less accurate in future releases of Sailfish. This means the detection parameters will need to be made more lenient which again increases the risk of false positives.
To both reduce the risk of false positives while allowing more sloppy timings, I propose to update the detection routine to evaluate groups of 3 possible signals as a whole instead of sequentially.
The false positives I have seen, all have a whole bunch of ignored simultaneous signals. The motivation for this was that a sharp bang on the printer housing must not cause a detection to be aborted, but a sharp bang will only cause 1 or maybe 2 FFT frames with multiple signals, not 10 like I often see in a false detection. So if a candidate sequence has more than 2 simultaneous signals, discard it.
Similar for timings: if the timing of one beep and one pause is somewhat too long but the other timings were perfect, the printer was probably slowed down while playing an actual sequence and it should be accepted. If all timings are suspicious, then it should be discarded.
This can be implemented as a penalty system where each simultaneous signal case adds a score, an each timing flaw adds another score. If the total score exceeds a threshold, discard. A fancy way to determine optimal scores would be to gather a lot of examples and then throw some learning algorithm against it, but good results can probably be obtained as well with some common sense.
The text was updated successfully, but these errors were encountered: