Обновить
16K+
214

Embedded SW/Firmware Engineer

23,6
Рейтинг
548
Подписчики
Отправить сообщение

У меня есть Malahiteam DSP4.
Ставлю на подоконник - уверенный сигнал.
Ставлю на комп. стол в кабинете - нет сигнала.
Был бы пульт можно было бы оставить приемник на подоконнике и переключать каналы пультом.

Может ещё добавить ИК приемник, чтобы переключать станции ТВ пультом?

По полученным коррелограммам строим окружности яркостей (коррелограмма будет радиальным профилем).
5. Далее реализуется метод, известный в радиолокации под названием Back-Projection
Суть его в следующем:

  • задаём сетку выходной 2D карты;

  • для каждого узла выходной карты рассчитываем яркость как сумму яркостей от точек (соответствующих дальности до этого узла) разных кругов (у каждого круга будет своя дальность, соответсвующая заданному узлу). Т.е. для каждого узла с координатами (x, y) вычисляем яркости Ci от разных кругов на соответствующих радиусах и суммируем эти яркости:

Яркость заданного узла выходной карты равна сумме яркостей от разных кругов на определённом радиусе (свой для каждого круга)
По сути - это то же суммирование range profiles, но каждый круг перед суммированием нужно свинуть вдоль оси х на положение xi.

Я так и делал. Пробовал просто численно просуммировать range profiles, но получилось какое-то каля-маля.

Прежде всего, необходимо экранировать приёмник от половины окружающего пространства (например, заднюю полусферу). Это необходимо для того, чтобы исключить неоднозначность определения целей по дальности (2 цели на одинаковой дальности от прямой перемещения будет невозможно разделить).

Интересно как это технически сделать?

3. Для каждого зондирования осуществляем сжатие отражённого сигнала (построение "коррелограммы"). Будет быстрее сделать это через перемножение спектров с последующим переходм обратно во временную область.

Я так и делаю.
Cвертку считаю при помощи алгоритма FFT iFFT.
Это вычисляется быстрее FIR.
Вот по этой формулу.

iFFT{ FFT( принятый сигнал) * [комплексное сопряжение(FFT(импульсный ЛЧМ-сигнал))] }

В результате программа вычисляет свёртку для файла длинно 0,7 секунд в 13 раз быстрее по сравнению с FIR фильтром, и в 3421 раз быстрее, если сравнивать с DFT!

Как быть если надо реализовать два экземпляра программного uart?

Can без протокола - ничто.

А can протоколы(uds, j1939, xcp и прочее) это много кода.

У начальства в планах было продавать эту умную розетку в каждом хозяйственном магазине.

В этом

Glyndwr University или еще одна статья об образовании за границей / Хабр https://share.google/fKqsP0LJcD3mln2Me

У меня есть сонар. https://habr.com/ru/articles/1050166/
Я записал эхо сигнал в известных местах вдоль прямой с известным шагом.
Все измерения были неподвижные.
Вычислил свертки при помощи коррелятора.
После согласованной фильтрации (корреляции с зондирующим сигналом) получил коррелограмму.
Формально у меня есть набор радиальных профилей (range profiles) вдоль окружностей радиуса  r  вокруг каждой позиции .
Это и есть исходные данные .  
Получил коррелограммы, которые показывают расстояния до каждой цели из заданной точки. По сути это одномерные графики.

Хочу построить акустический аналог SAR / aperture synthesis. Или томографию окружающего пространства. Как мне теперь на основе этих N коррелограмм построить 2D карту окружающих предметов вокруг?

Пробовал просто численно просуммировать range profiles, но получилось какое-то каля-маля.

пробовал вычитать range profiles

пробовал брать среднее range profiles

Но пока картинка не проясняется.

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

Если у Вас в прошивке нет отладочной CLI, то Вам, конечно же, не нужны функции из файлов xxx_diag.c и xxx_commands.c.

Вот как раз поэтому сериализаторы структур, команды shell и выделены в отдельные файлы исходников.

Чтобы не захламлять код ядра самого условного драйвера.

Тогда просто берете файл xxx_drv.c xxx_drv.h , xxx_const.h, xxx_type.h, xxx_config.c xxx_config.h. остальное просто не подключаете к сборке.

Если подходить как к чужому драйверу - в свой проект драйвер из десяти файлов даже еще и с собственным mk файлом я бы не добавил. 

Вас может испугать большой набор файлов: 21 штука. Однако в коде и репозитории гранулярность как раз к месту. Так как не все файлы надо собрать в той или иной сборке. В одних платах есть UART-CLI в других нет. Там где CLI есть сразу надо подключать diag и commands. Где-то нужны модульные тесты, где-то нет. В одних проектах много flash памяти, а в других надо утрамбовывать код. В одних проектах одна кнопка в других 88 кнопок, то есть надо подключать конфиг отдельным файлом. В одних проектах есть NVRAM, в других нет. В одних проектах используют GNU Make, в других Cmake. В одних проектах нужна документация, в других нет. Всё это надо учитывать при проектировании программного компонента. Поэтому и получается что для одного модуля надо множество файлов. Это нормально.

сегодня внезапно выяснилось, что он оказывается еще хочет, чтобы порядок ответов на вопросы соответствовал порядку в котором вопросы задавались в сообщении.

Человек не умеет пользоваться Crtl+F по pdf-ке.

Модульные тесты невозможно внедрить опосля, когда продакшен код уже написан и отгружен.

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

Нанимают тестировщика и считают, что проблема решена. Но не тут то было. Внезапно для себя они узнают, что их «продакшен код» совершенно, абсолютно не тесто пригоден.

Так получилось... Так вышло... Так сложилось исторически...

Просто нет базы для составления модульных тестов. В коде нет как таковых getter‑ов и setter‑ов, на основе которых обычно и строятся модульные тесты. Там условно одна или две функция‑Бог: void xxx_init(void ) и void xxx_invoke(void ).

Более того, их код с требуемыми сертификаций ключами компилятора GCC даже и не собирается вовсе!

При этом разработчики, чтобы прикрыть хвост еще стремятся обвинить во всем тестировщика, что это, дескать, он не справился с задачей модульного тестирования их горе legacy.

Такое себе решение, нанимать отдельного человека, чтобы тот начал писать модульные тесты под legacy.
Даже ИИ говорит, что модульные тесты должен писать сам автор тестируемого кода.

Модульные тесты должен писать сам автор модуля. По крайней мере первый набор модульных тестов. Дело в том, что написание модульных тестов требует глубокого понимания предметной области. У разработчика модуля это понимание уже так или иначе накоплено по мере разработки самого модуля. Если вы будете привлекать к написанию тестов сторонних людей, то вы потратите существенно много времени пока новые люди освоят предметную область, вникнут в код и придумают тесты для него.

остается любопытным почему заместо stm32 не использовать второй MDR, если уж не пихать все остальное в ESP32

Насколько я помню в MDR не было PDM и I2S интерфейсов для микрофона.
Тов. майор бы не смог работать.

Есть компании, где просто за одно упоминание слова "юнит-тест" могут наказать как за попытку внедрения вредной практики, способной разрушить работающий цикл разработки и поддержки продукта.

Это прям яндекс драйв чистой воды.

Но, на хабре за упоминание юнит-тестов в положительном ключе принято сливать карму, или хотя бы минусовать,

Есть такое.
Когда я написал текст про модельное тестирование статься даже в плюс не вышла.

Модульное Тестирование в Embedded 
https://habr.com/ru/articles/698092/

Аналитимка показывает, что большинство минусов за
"Ничего не понял после прочтения "

Информация

В рейтинге
332-й
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность

Специализация

Инженер встраиваемых систем, DevOps-инженер
Старший
Git
Bash
CI/CD
C
Встраиваемая система
Программирование микроконтроллеров
Разработка программного обеспечения
Алгоритмы и структуры данных
Системное программирование
Разработка драйверов