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
Is your feature request related to a problem? Please describe.
To help diagnose wrong configuration, it would be useful to make a difference between "silence" (some signal but below thresholds) and "frozen" signal (constantly at the same value for long time).
Describe the solution you'd like
Implementation should be straight forward, with some potential for optimizations as we only need to consider "sample batches" that are all at the same value.
static unsigned long timeOfLastChange=0; that stores the millis() from the last changing sample batch (special case "0" = never changed since startup)
static float previous_sample =0; for comparing with new samples. If all samples in the batch == previous_sample, we are stuck at a value. If at least one is different, update timeOfLastChange to indicate "not stuck". And update previous_sample to a randomly picked sample, like the 16th in a batch (does not matter which one we use).
edit: previous_sample is not strictly needed. Just take the first one from a batch of 512, and compare if all other 511 are the same value. If yes--> potentially frozen.
check timeOfLastChange when showing info page. If silence and timeOfLastChange - now() > 5 seconds --> show "frozen".
Additional context
I2S is basically single-direction from programming perspective, so you set pins, then start reading values. There is no feedback available about bad configuration, for example missing/broken MCLK signal.
Thanks @netmindz and a few other discord users who suggested a detection scheme for "frozen" signals.
At the moment it feels like there are too many failure possibilities that all just result in the info page saying silence. For example, you can set the wrong pin for master clock and just get Silence, when surely without clock we are getting no meaningful data at all, so reading the same sample value all the time?
The text was updated successfully, but these errors were encountered:
Great idea and for sure will eliminate some of the guess work . I do hope you could also consider analog as that would be helpful for line-in as some are still on the DIY listed in the wiki ( works really well when it does )
It would not be possible to do this for analog @dosipod as the value read this way will never be exactly 0 or freeze if a connection comes loose.
The idea here was to help uses get better feedback when trying to wire up I2S devices, but using the wrong pins etc. Better to indicate some form of error rather than just say "silence"
development note for a future feature
Is your feature request related to a problem? Please describe.
To help diagnose wrong configuration, it would be useful to make a difference between "silence" (some signal but below thresholds) and "frozen" signal (constantly at the same value for long time).
Describe the solution you'd like
Implementation should be straight forward, with some potential for optimizations as we only need to consider "sample batches" that are all at the same value.
static unsigned long timeOfLastChange=0;
that stores the millis() from the last changing sample batch (special case "0" = never changed since startup)static float previous_sample =0;
for comparing with new samples. If all samples in the batch == previous_sample, we are stuck at a value. If at least one is different, update timeOfLastChange to indicate "not stuck". And update previous_sample to a randomly picked sample, like the 16th in a batch (does not matter which one we use).timeOfLastChange - now() > 5 seconds
--> show "frozen".Additional context
I2S is basically single-direction from programming perspective, so you set pins, then start reading values. There is no feedback available about bad configuration, for example missing/broken MCLK signal.
Thanks @netmindz and a few other discord users who suggested a detection scheme for "frozen" signals.
The text was updated successfully, but these errors were encountered: