Xtal1

Здравствуйте! Подниму некропост. А нет ли у вас, случайно, 7.40 на данный момент? А то похожая проблема возникла и своими силами не нашел.

Да, как-то я не подумал. Спасибо.

Так все-таки смотреть в сторону БИХ-фильтров? И еще такой вопрос: чем трехкаскадное скользящее среднее по 64 отсчетам лучше, нежели просто усреднять 192 отсчета, если получать отсчет с выхода для каждого входного не требуется?

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

допустим, но какое это имеет отношение к вопросу...

)) да там всего 1 ms показана, где Вы это увидели?

Попробую ответить такой картинкой: По названиям каналов должно быть понятно где какой сигнал. Период между маркерами - это то, что собственно измеряется. Задержка между SLAVE SYNC DETECTED и SLAVE TX точная и обеспечивается таймером МК. Не буду засорять ноосферу лишней информацией, просто скажу, что задержка эта необходима в силу особенностей работы самого трансивера. Как видите, ничего там лишнего нету и при такой скорости передачи задержка особо меньшей быть не может. Формат пакета следующий: 4 байта преамбулы, 3 байта синхрослова, остальное - данные, но они никакой роли не играют.

Как я уже говорил выше, задержка естественно есть. Она состоит из задержек на переключение режимов приема/передачи, самого времени передачи пакета... Время входа в прерывания стабильно одинаковое (это тоже отлаживалось и проверялось), каких-то более приоритетных да и вообще других включенных прерываний нет. И еще раз повторюсь, все задержки константные (во всяком случае насколько я смог их измерить с точностью до 41,6 нс). Нестабильны задержки от начала отправки пакета передатчиком и до момента выдачи сигнала детектирования синхрослова приемником. Они одинаково пляшут при передаче в обе стороны. И порядок гуляния этих задержек как раз укладывается в гуляния самого результата измерения. Вы хотите сказать, что моя гипотеза о периоде дискретизации входного сигнала в трансивере, которым он квантует результирующие значения не верна? А эти 40, это вы взяли скачки результатов из выборки? То-есть Вы тоже считаете, что малину портит именно частота дискретизации самого трансивера? Еще хочется услышать Ваше мнение по поводу вот этого. Как думаете, там результат получился более красивый именно за счет несколько иного функционирования трансиверов (я имею ввиду, что у них частота дискретизации могла быть повыше)?

Трансиверы ST-шные SPIRIT1. Параметры передачи на данный момент следующие: FSK, 250 kbps, Δf = 127 kHz, полоса пропускания 540 kHz. Контроллер используется STM32f401, тактирование таймера 84 MHz. Соответственно те тугрики, которые тики таймера, которые в прицепленном файле, это время выраженное в 1/84е6 секунд или 11,905 наносекунд на каждый тугрик. Наверное, я не совсем понял вопрос, но тот сигнал, который я приводил, получен при неизменном взаимном расположении трансиверов (на расстоянии около 2-х метров) и предметов вокруг них (за исключением меня, сидящего рядом на стуле). Большого значения не имеет, если она, конечно, в разумных пределах. А какая задержка имеется ввиду, время расчета?

Всех ответивших благодарю за помощь. Вообщем, это не АЦП, потому сеанс телепатии был не совсем удачен. Физически, эти значения представляют собой тики таймера в системе радиочастотной ToF. Т.е. мы измеряем расстояние между цифровыми трансиверами с помощью вычисления времени полета радиоволны. Сам процесс измерения производится следующим образом: Первое устройство (мастер) запускает счет таймера и отправляет ведомому пакет, в момент завершения отправки происходит событие захвата и защелкивается значение счетного регистра таймера, мастер переключается в режим приема. Далее, ведомое устройство, принимает пакет, переключается в режим передачи, и начинает отправку ответного пакета. Когда мастер ловит событие детектирования синхрослова, то это событие на другом канале захвата таймера вызывает защелкивание второго значения таймера (переполнения учитываются). После этого, получаем разницу между двумя событиями в тиках таймера. Вот именно эти значения и даются в первом посте. Все задержки, константные, кроме одной - задержки между началом передачи и моментом возникновения события детектирования синхрослова. Подозреваю, что природа этого связана с частотой дискретизации входного сигнала в трансивере. Другими словами, насколько точно трансивер определяет фронты сигнала - насколько точный результат я и получаю на выходе. И "ненормальность" распределения, мне кажется, связана именно с этим. Во всяком случае, другого объяснения для того факта, что измерения стремятся занимать несколько определенных дискретных значений, я пока не придумал :) Сама проблема заключается не в том, что нужно получать большую скорость измерений, а в том, что устройства автономные и тратить энергию на слишком длинные сеансы связи - роскошь. Так, на данном этапе, для того, чтобы провести 100 циклов измерения я сейчас затрачиваю 85 мс, но усреднение 100 значений дает разброс больше желаемого. Приемлемую болтанку дает усреднение 1000 значений, но тогда и время измерения почти секунда. Так что при этом сеансы измерения расстояния прийдется проводить значительно реже, что, собственно и смущает. Пытался вычислить для выборки максимумы и минимумы (все, если их несколько) и выбросить из усреднения, но это не дало результата. Видимо действительно нужно как-то задавать окно и за его пределами отсекать "левые" значения. Но пока не придумал по каким критериям задавать границы этого окна, имея просто выборку, например из сотни значений.

Всем доброго времени суток. Прошу прощения, если не в тот раздел, но более подходящего не нашел. Проблема заключается в следующем: Есть поток входных значений, для примера даю выборку из 1000 отсчетов sampling.rar Нужно фильтровать такой поток значений, дабы получить "болтанку" на выходе не более 2-3 единиц по амплитуде. Тупым усреднением этого получается достичь лишь при количестве усредняемых значений близкому к 1000. Можно ли добиться подобного результата с помощью каких-то более серьезных алгоритмов фильтрации и получить при этом время отклика фильтра хотя бы 200-400 сэмплов.

Условия испытаний следующие: Есть приёмник. Он настроен на выдачу Automatic Acknowledgment каждый раз по получению пакета. Есть передатчик, который хочет определить расстояние до приёмника. Он настраивает радиочип на вывод информации о соответствующих событиях (флагах внутри него) на внешние линии. Далее, передатчик запускает отправку пакета. Когда пакет отправлен, от трансивера на вход захвата таймера МК поступает соответсвующий сигнал. Начинается отсчет временного отрезка. Дальше, после получения ACK-а от приёмника, на МК выдается еще один сигнал, по которому отсчет отрезка времени заканчивается. Ну а дальше, отбросив время на передачу пакетов, задержку в приёмнике до выдачи ACKa и т.п., поимеем время распространения волны от передатчика к приёмнику и обратно. Делим на два, считаем расстояние. В реальности же, получаем сильно большое "дрожание" измерений. В районе десятков мкс. Замечено, что в последовательности измеренных таким образом интервалов времени очень часто повторяется ситуация, когда из 10-ти измерений 3-5 совпадают с точностью до десятков нс, иногда это 2-3 измерения подряд, иногда нет. Скажите, с чем может быть связано. Трансивер может обрабатывать идентичные по структуре пакеты разное время?