Б.г.> Сам по себе оверсэмплинг не является помехозащитным алгоритмом
Так и я писал, что он таким не является.
Б.г.> но он может частично давить помехи, если их частотный диапазон выше частотного диапазона сигнала.
Вот именно это и есть главное условие работоспособности алгоритма pinko в его барометрическом датчике апогея. Но, это хорошо, когда помехи по амплитуде всегда находятся в одном и том же пределе. Если они его на какое-то время превысят, то станут полезным сигналом, где даже на ровном месте (в покое) найдётся такая конфигурация данных во времени, которая, например, сможет удовлетворить условию старта. Итог: ракета стоит на месте, а программа уже думает, что летит.
Т.е. на том же примере барометрического датчика pinko нужен именно 10-битный АЦП, так как уровень собственных шумов типичного аналогового датчика находится в на уровне 9-10-битного АЦП. Т.е. примерно столько же или немного выше. Т.е. шумы с датчика будут хорошо видны. Поскольку, применяется не очень быстрый ЦП, то делать много сложений не получится, поэтому лучше 10-бит АЦП, а не 12-бит, так как сложений меньше нужно, чтобы убрать шумы. Теперь самое главное - это деление.
В простом суммировании для повышения точности делить совсем не обязательно, а для работы его алгоритма обязательно, иначе ничего не получится. Он и делает побитовый сдвиг суммы.
Т.е. разница между просуммированными значениями ещё более значительна в целочисленном выражении, чем в исходном не суммированном виде. А вот после деления или побитового сдвига разница между полученными значениями уже после деления становится на уровне ниже 1/1024, то в большинстве случаев смежные значения не смогут меняться вообще. Будет нитевидный сигнал, монотонно меняющийся целочисленно только в диапазоне {0, 1023}.
Но если исходные шумы станут на уровне 7-8 бит, то жестко заданной суммы и побитового сдвига уже не хватит для того, чтобы скрыть шумы таким образом. Они снова появятся и логика программы будет давать сбои. Будет снова шумоподобный сигнал меняющийся целочисленно только в диапазоне {0, 1023}.
Логично, что если ему попробовать использовать хотя бы 16-битный АЦП, то возникнут проблемы со сложением и сокрытием шумов, так как датчик шумит на уровне 9-бит, то складывать придётся настолько много раз, что его ЦП с этим просто не справится. Тогда, даже если выжать максимум, то после сдвига всё равно будет шум, так как сигнал будет меняться целочисленно только в диапазоне {0, 65535}
Или короче:
При одинаковом доступном количестве сложений и последующего деления получается, что уровень шума будет снижаться от 1/512, ну допустим, до 1/4096. Тогда такой шум исчезнет на целочисленном диапазоне {0, 1023} и останется на целочисленном диапазоне {0, 65535}. Тут изменения в шумах составят ±16 попугаев. При таком уровне шумов его алгоритм работать не будет, т.е. надёжность будет настолько низкая, что почти ни одного успешного срабатывания программы не получить.
Казалось, можно выбрать сразу АЦП 8 бит вместо 10 бит и ничего не складывать? Но 1/256 маловато будет для рекламы чувствительности прибора.