amaora

Список непрочитанного стал открываться ~30 секунд, это же не только у меня так?

Специальная разметка и цепляться за опорные точки, сопровождать каждую пока она в поле зрения, всегда держать несколько точек в поле. Будет инкрементальное счисление без потери шагов, а при более сложных "рисунках" может быть и абсолютное счисление.

Функция производная которой равна этой же функции.

Не очень понимаю как использовать эти неизвестные аппаратные особенности стирания. Если возвращается статус cтирания, то могут быть какие-то стратегии его использования. Но для чего знать как именно контроллер "недотрет" битый сектор? В любом случае будет программный контроль целостности данных.

Может быть я не правильно понял задачу. Когда мне нужно калибровать два симметричных измерительных канала я подаю одинаковый сигнал на оба канала, и нахожу например коэффициенты КИХ (с помощью МНК) преобразующего измерения одного канала в другой (или каждого канала в эталон). Если добавить в прибор источник подходящего информативного сигнала, то калибровка станет автоматической, без оператора. В частотной области не делал.

Вот это хотелось понять, спасибо. Поверхностно понял про БЧХ и перемежение, избыточно для моей задачи.

Слишком узкое решение под определённые условия тоже "не очень". Ну возмем более мягкую модель, пусть сбоем будет называться пропажа блока длиной 1-500 байт неразрывным куском, с вероятностью 0.003, один раз за всю передачу. Длина пропавшего блока и его смещение от начала имеют равномерное распределение. Тогда достаточно, держать повторные блоки на расстоянии более 500 байт от оригинальных. Можно дополнить задачу следующим условием. Необходимо минимизировать время (среднее/максимальное) получения принимающей стороной полного пакета данных с учётом ожидания недостающих повторных блоков в случае наличия сбоя. Из этого условия получается необходимо сначала передать оригинальные пакеты, и лишь после начинать делать повторы, которые будут востребованы с вероятностью 0.003. А порядок повторов наверно лучше оставить последовательный, для минимизации среднего времени, максимальное же время уменьшить не получится.

Вопрос не в этом, хотелось оценить возможность применения избыточного кодирования. Где-то применял их раньше, но это не то, что нужно сейчас. Похоже остаётся повторять блоки несколько раз как самое простое. Можно ещё подумать в каком порядке лучше их повторять.

Разобьём передаваемый поток байт на блоки, по 4-16 байт. Синхронизацию и проверку целостности блоков оставим на более низкие уровни. Будем считать, после передачи на принимающей стороне находятся корректные блоки в корректном порядке, известно какие блоки отсутствуют. Выпадать может любой блок, или несколько в произвольных местах. Какие алгоритмы можно применить?

Как применить это к большому блоку данных ~100Кб? Допустим есть возможность увеличить размер передаваемых данных на 50% (~150Кб), как потом восстановить исходные данные из уцелевших кусков которые суммарно имеют длину ~100Кб но разбросаны произвольным образом? Восстановление отдельных разрядов внутри короткого слова это не то, что нужно.

Можно, было подобное, теперь нет достаточно flash памяти на две копии. Протокол без обратной связи, без запроса повторной пересылки, один байт потеряется/побъется и да, CRC32 не сойдется.

По времени передачи, могу позволить длиться этому процессу в 2-3 раза дольше.

Протокол с подтверждения хочется избежать, может быть много приёмников одновременно, массовая рассылка. Памяти RAM под всю прошивку нет. Это есть, надо немного надёжнее, особенно при передаче по UART, избежать окирпичивания из-за битых блоков/байтов.

Есть возможность передавать данные в одну сторону по цифровому каналу связи, есть возможность увеличить объем данных для восстановления возможных ошибок передачи. Какие алгоритмы можно применить? Передаётся прошивка объёмом ~100Кб. Нужна устойчивость к потере до ~50% передаваемых данных. Объем передаваемых данных можно увеличить в 2-3 раза. Передача байтовый поток, либо блоками по ~64-бит с контрольной суммой каждый. У меня хватает фантазии только на передачу блоков в псевдослучайном порядке каждый по три раза. Канал связи например USART или CAN.

Развёл токи по разным направлениям от МК, аналог в одной стороне, цифровое в другой. Полигоны не резаны, земля общая, аналоговое питание через RC фильтр. Выборка и преобразование в "тишине" при спящем ядре МК, частота тактирования АЦП немного завышена. Шум в одном младшем разряде. F405, F722, lqfp64.

Ну не абсолютно, у глонасс точность эфемерид ниже если правильно помню. Конфигурация траекторий КА отличается.

А не надо путать "за идею", "оплачивается", "опенсорс", "форфри", и Столмана с Торвальдсом. Открытое или свободное не означает бесплатное и не означает, что разработчики ничего не получают. То, что вы, возможно не можете представить других моделей, кроме продажи копий с закладками и умышленными недостатками без права/возможности делать клоны, это результат медленной неявной пропаганды, как и искажение смысла патентов и многое другое. Да.

Есть много преобразователей сигналов ресолвера (вращающийся трансформатор) в цифровой вид и в дискретный квадратурный сигнал, например ADS1200. Но ничего не могу найти для преобразования в аналоговый однополярный квадратурный сигнал. Существует такое?

Так звон в фазной цепи, заряд ёмкостей body диодов и других, а ток (сквозной) идёт по длинному контуру, верхние и нижние ключи далеко. Их надо установить как на вашей картинке установлены параллельные пары ключей, корпус в корпус, тогда и для конденсаторов место будет у самых ног. Либо переключать медленнее. Да греться должны, диоды не помогут.

Трассировка просторная, но не думаю, что она вносит большой вклад в этот звон.

Сравните параметры reverse recovery, попробуйте отдельно верх и отдельно низ переключать с резистивной нагрузкой.

1. Из вашего описания задачи. Нельзя удерживать момент противодействия внешней нагрузке при разомкнутом управлении, получите "пропуск шага". Для серво не будет иметь значение неравномерность вращения в разомкнутом цикле; 2. Это новая информация из которой можно будет делать выводы (причина в неравномерном формировании токов или в двигателе), без этого мне нечего предложить; 3. Для понимания, чтобы знать ответы на возникающие вопросы.

Отладка такого режима работы бесполезна для вашей конечной задачи. Посмотрите как устроен сервопривод. Об этом надо думать только после того, как будет проверена (обеспечена) равномерность вращения вектора тока. Может быть и заданные величины заполнения где-то обрезаются, короткие импульсы не проходят. А зря, нарисовать временную диаграмму работы ключей, с формами токов, моментами выборок АЦП и другими событиями было бы очень полезно.

Вы им управляете как шаговым двигателем, а не как BLDC. Так можно, но с чего бы в таком случае рассчитывать на равномерность. Предполагаемые причины в порядке приоритета: 1) Проверить равномерность вращения вектора тока, может быть значения в ваши таблицах неравномерны, или есть асимметрия двигателя; 2) Есть ли cogging torque? То есть, неравномерное сопротивление вращению отключённого двигателя, по причине взаимодействия магнитного потока ротора с полюсами статора. В этом случае при таком управлении надо увеличивать ток удержания; 3) Асимметрия двигателя, ничего не поделать при разомкнутом управлении;

Если даже определить, по анализу принимаемых данных, что вот сейчас UART принимает фреймы не с того места, и так везёт/совпадает, что не определяются никакие ошибки. Тогда следующий вопрос, как пересинхронизироваться? включать-выключать UART и надеяться, что на этот раз повезёт?