Перейти к содержанию

    

Fat Robot

Свой
  • Публикаций

    1 016
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Fat Robot

  • Звание
    ʕʘ̅͜ʘ̅ʔ

Контакты

  • Сайт
    http://
  • ICQ
    0

Посетители профиля

6 290 просмотров профиля
  1. при оценке частоты важны snr, время накопления и интервал стационарности источника
  2. любопытный прибор, конечно. время реакции на изменение напряжения исчисляется секундами. главное, конечно, чтоб заказчиков такое поведение устраивало
  3. Фильтр - это прекрасно. Но все же посмотрите, как зависит в вашей схеме Vrms от соотношения фаз частоты отсчетов и частоты основного тона. Пусть вы измеряете сигнал с частотой ровно 50 Гц и у вас точно 5 отсчетов в периоде
  4. Ну так и восстанавливайте средствами интерполяции.
  5. 4. Если периодов достаточно, то самое простое - увеличить частоту выборок, чтобы уменьшить влияние от стробоскопирования, и наложить оконную функцию, чтобы уменьшить влияние краевых эффектов
  6. Для оценки RMS по 1 периоду основного тона нужно оценивать длительность этого самого периода или частоту, а также фазу. Т.е. реализовать синхронное детектирование. А дальше несколько вариантов: 1. Считать RMS по количеству выборок, которое укладывается в период. Этот период нужно брать от 0 до 0, чтобы уменьшить погрешности от краевых эффектов. 2. Интерполировать выборки, чтобы в 1 период всегда укладывалось фикс. число интерполированных отсчетов на постоянных значениях фазы основного тона. Для этого в вашем случае нужно иметь частоту отсчетов более чем 4 раза превышающую макс. частоту шумового процесса. 3. Подстраивать частоту отсчетов средствами апч. Тут нужно смотреть, что позволяет ваше железо, и какие возможны изменения. Пр оценку частоты сигнала в розетке тут было много копий поломано. Поищите.
  7. Проверить то, что передатчик правильно формирует пакеты, а приемник их принимает - это, как вы правильно заметили, задача весьма простая. Сложное - правильно реализовать и проверить машины состояний, реагирующие на нештатные ситуации. Вот пример решения такой задачи, в котором без выхода за рамки TCP исследуется подключенное к сети устройство. https://www.bobbriscoe.net/projects/2020comms/tcp-test/draft-moncaster-tcpm-rcv-cheat-03.html А вот что пишет нам автор стека lwIP: http://lists.nongnu.org/archive/html/lwip-users/2016-05/msg00125.html
  8. А можно полюбопытствовать, для какого канала распространения нужна такая экзотика? Я слабо себе представляю условия с такой "острой" частотной избирательностью, где помогала бы OFDM с разнесением в ~100Hz. Контейнерный терминал с остро направленными антеннами?
  9. Это, разумеется, не верно, т.к. прямой перебор выдает максимально правдоподобную оценку, а Чейз - ее аппроксимацию. Разница в пользу мп-оценки будет более заметна при низких отношениях сигнал-шум.
  10. А вы попробуйте сравнить процедуру Чейза и прямой перебор. Информационная часть у вас короткая, должно получиться быстро.
  11. Я говорил про несколько проходов app декодера в одной итерации турбо-декодера.
  12. https://www.mathworks.com/help/comm/ref/com...tem-object.html Introduced in R2012a Мне пока не понятно, как задать начальное состояние (circulation state), но я уверен, что вы справитесь. Кстати, по поводу circulation state: он позволяет сделать многопроходный декодер для constituent conv. code, используя 'закольцованную' решетку. Вы рассматривали такую возможность при реализации?
  13. В матлабе есть реализация турбо кодера и декодера. С них можно начать. Успехов
  14. Matlab? При реализации tc я обнаружил довольно неприятный эффект: можно сделать незначительные ошибки (перемежитель, выкалывание, хвост) , которые приводят к незначительному ухудшению корректирующей способности. Т.е. кодер и декодер tc до определенной степени устойчивы к ошибкам реализации: катастрофы не происходит, все продолжает работать, но хуже, чем заявлено. Искать и отлаживать такие ошибки очень тяжело.
  15. неудачный опыт коллеги безусловно ценен. а если loopback заглушку прицепить вместо платы? http://www.ni.com/tutorial/3450/en/