Файлы  •  Ссылки  •  Прошивки  •  Правила  •  Архив  •   FAQ  •  Участники  •  Поиск
Регистрация  •  Вход

Программный анализ сигналов

Список форумов » Программное обеспечение » Микроконтроллеры На страницу 1, 2, 3  След.
АвторСообщение
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




23-07-2017 08:15

Всем доброго времени суток. Возникла необходимость анализа комманд Diseq от спутникового ресивера с помощью микроконтроллера pic12f629.
Суть протокола Diseq состоит в том, что двоичные символы - логические "единицы" и "нули" - кодируются посылками тона 22 кГц. Длительность одного символа постоянна и равна 1.5 мс, длительности посылки и паузы изменяются. Для "единицы" длина посылки составляет 0.5 мс, или 11 периодов частоты 22 кГц, а длина паузы - 1.0 мс. Для "нуля", наоборот, посылка длится 1.0 мс и содержит 22 периода тона 22 кГц, пауза - 0.5 мс. Всего таким образом передается 4 байта информации (каждый байт дополняется в конце битом четности).
Сложность заключается в том, что в самом протоколе не заложен признак начала передачи (как например в протоколе NEC в пультах дистанционного управления), и, кроме того в некоторых случаях может присутствовать частота 22 кГц, в связи с чем анализ существенно усложняется.
Я попытался реализовать программный анализ пакета без использований каких либо прерываний, но достоверность определения не высокая. Кто что может посоветовать по сути данного вопроса?
Eex
Участник
Сообщения: 1522




23-07-2017 09:11

Задача сведётся к двум этапам: 1. принять бит, и 2. проанализировать принятую информацию.
1. видимо физический уровень рассчитан на определение бита с помощью фильтра. На выходе RC фильтра у нас будет чёткий сигнал от пауз в посылках. Можете поставить фильтр перед контроллером и пустить сигнал на компаратор в контроллере. На выходе из компаратора получите готовые единицы и нули.
Если задача анализировать именно программным путём, то нам потребуется таймер, настроенный на 0.4мс (определяем ноль). Сам сигнал подаём на пин внешних прерываний контроллера. При каждом внешнем прерывании сбрасываем таймер. Если таймер отсчитает до 0.4мс, то мы приняли (как минимум) ноль. Перезаряжаем таймер опять на 04мс и смотрим сработает ли он второй раз. Если таймер был сброшен внешним прерыванием, то мы остались с "нулём", если сработал таймер второй раз, то у нас "единица", если таймер сработал третий раз, то у нас обрыв коммуникации или не активность шины.

2. мы приняли биты и теперь надо посмотреть что у нас за инфа. Запоминаем 4 бита и проверяем на чётность. Если чётность не совпала, то принимаем следующий бит и проверяем на чётность уже с ним (сдвигаем биты каждым принятым новым битом). Если чётность совпала, то, предположительно, у нас есть принятый байт. Надо определить это случайное совпадение с чётностью или нет. Проверим правдоподобен ли байт (может в байте никогда не должны встречаться какие-то значения или есть протокол более высокого уровня для проверки соответствия). Если байт правдоподобен, то исполняем его.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




23-07-2017 09:24

Если взять типовую схему Disec, то имеем сигнал с коллектора транзистора сразу на порт контроллера. Однако ж там такие шумы!!! Поэтому приходится ставить в параллель емкость от 1 до 47 нф. Плату я уже сделал, поэтому RC цепь "лепить" уже некуда... Стало быть придется анализировать частоту.

Добавлено 23-07-2017 09:30

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

Добавлено 23-07-2017 09:51

Да еще вопрос: может кто подскажет какого назначение диода VD1 между базой и землей?

  diseq.JPG  71,76 КБ  Скачано: 34 раз(а)

Eex
Участник
Сообщения: 1522




23-07-2017 11:17

dima080383 писал:
Eex. Вы таким образом предлогаете ловить "паузы"?

Надо смотреть на шину, что там легче искать паузы или частоту. Предполагаю, что 22кГц не с проста, скорее всего они частотой делают "привязку нуля" на стороне приёмника. В таком случае частота, это состояние покоя линии, а пауза, это как раз полезный сигнал.

dima080383 писал:
Думаю, что в этом случае таймер будет считать половину периода частоты, а не паузу.

Вы заряжаете таймер на переполнение от 0.4мс (зависит от тактовой частоты контроллера, допустим значение TMR1 = 0xFF05), тогда таймер переполнится при значении 0xFFFF и это должно соответствовать 0.4мс. Каждый раз при внешнем прерывании (каждый спад частоты 22кГц) вы делаете TMR1 = 0xFF05. Таким образом пока на линии есть частота, таймер никогда не достигнет 0хFFFF. Если частота пропадёт (пауза), то таймер никто не сбросит и он достигнет значения 0хFFFF (то есть возникнет прерывание таймера). Если прерывание таймера случилось, то мы имеем как минимум паузу 0.5мс (более длинную, чем 0.4мс таймера). Далее продолжаем считать, перезаряжаем таймер опять на TMR1 = 0xFF05 и сравниваем с паузой 1мс. Никакие полупериоды таймер не считает.

dima080383 писал:
если "пауза" у вас возникла в результате какой либо помехи или при переключении напряжения или на границе между "частота-пауза" или "пауза-частота"?

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

dima080383 писал:
какого назначение диода VD1 между базой и землей?

конденсатор С2 удаляет постоянную составляющую из сигнала (делает переменку из частоты для привязки нуля), а диод VD1 защищает базу транзистора от отрицательного плеча этой переменки (пауза как раз и будет тем самым отрицательным плечом, её мы и пытаемся выделить). Получается, что пока идёт переменка 22кГц транзистор всегда открыт (коллектор на массе), от паузы (полезного сигнала) транзистор закроется. Какие там напряжения на линии и какой размах переменки?
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




23-07-2017 11:30

Ну я вас понял. Сложность еще и в том, что состоянием покоя может являться как "тишина", т.е. отсутствие частоты, так и частота 22 кГц. Она нужна для того что бы управлять гетеродином спутниковой головки (переключать из верхнего поддиапазона в нижний). Поэтому из соображений унификации эта частота и выбрана для передачи протокола управления переферийными устройствами (Diseq).

Добавлено 23-07-2017 11:38

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

Добавлено 23-07-2017 11:51

Сразу оговорюсь, что использую цифровой порт для анализа сигнала и внутренний генератор 4 МГц.

  DiSEqC™ - подробное описание стандарта.rar  159,88 КБ  Скачано: 21 раз(а)

Eex
Участник
Сообщения: 1522




23-07-2017 11:56

я не пользуюсь редактором MsWord и не смог открыть файл docx как надо, только текст из него.
Оказалось, что с началом пакета всё строго: "Первый байт - служебный (framing) - обязательный, он содержит постоянную последовательность "11100"". Принимаете байты пока не встретите первую последовательность. После этой последовательности и пакуете биты в байты как описано в протоколе в соответствии с длиной байта.

С физическим уровнем тоже более менее понятно (картинок в доке я не смог открыть). После конденсатора С2 (по Вашей схеме) уже становится всё равно линия молчит 0 вольт или линия молчит 22кГц (удалена постоянная составляющая и переменка имеет средневыпрямленное значение = 0). По Вашим вопросам, я полагаю, что проблема не в софте, а в схемном решении. Чтобы что-то анализировать, на контроллер придётся подать логические уровни. Формирование стабильных логических уровней и есть проблема в Вашем случае. Если схема уже составлена и в ней перемешиваются шумы и полезный сигнал, то придётся реализовывать цифровые фильтры.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




23-07-2017 12:06

С чего вы взяли, что при наличии 22 кГц линия молчит?? Я вставал осциллографом на коллектор транзистора, программировал повторитель с порта на порт, частота есть! Даже если поставить 47 нф с коллектора на замлю все равно частота есть!

Добавлено 23-07-2017 12:09

Ну а что бы ее не было (как вы говорите) нужно встать диодом на коллектор и затем на емкость в параллеле с резистором (подобрать конечно).

Добавлено 23-07-2017 12:12

А на счет 11100 у меня это заложено - при приеме первых семи бит анализируется их состав
В любом случае спасибо Вам. Буду пробовать с таймером, благо что предделителя не понадобится) при 400 мкс заполнение около 213
Eex
Участник
Сообщения: 1522




23-07-2017 12:59

Я, конечно, делаю выводы "на морской глаз". Уровней напряжений на линии у меня нет, нагрузок, ёмкостей и длины линии тоже нет. Я теоретизирую в надежде, что Вам откроется муза (идея).
На стороне коллектора нет смысла что-то ставить - там слишком низкое выходное сопротивление. Все изменения (фильтры) надо делать на базу транзистора.
Если частота есть, то это не проблема - предложенная мною структура с таймером и прерыванием нуждается в наличии частоты.
Надеюсь подал хоть какие-то идеи.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




23-07-2017 13:08

Скажите вы TMR1 взяли что бы не мучаться с TMR0? Ато у меня после CLRF TMR0 что то страшное начинает твориться(((
Eex
Участник
Сообщения: 1522




23-07-2017 13:11

Взял только, чтобы был более наглядный пример. Все подводные камни конкретного контроллера ложатся на плечи программиста
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




23-07-2017 13:13

Это ужас просто! После команды CLRF TMR0 он переходит в режим 1:4!!!
Konstantin_18
Участник
Сообщения: 3369




23-07-2017 13:31

Eex, Все подводные камни давно описаны в errarta-х . Ничего сложного там нет.
dima080383, смотрите ошибки компилятора или оптимизатора ....
Ужаса сам НЕТ . улыбка
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




23-07-2017 13:34

Да вроде нет ошибок...
просто нужно так делать:

CLRF TMR0
BSF STATUS, RP0 ; банк 1
MOVLW B'10000000' ; настройка OPTION предделитель для TMR0 1:2
MOVWF OPTION_REG ; подтягивающие резисторы отключены
BCF STATUS, RP0 ; банк 0
я так думаю...
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




23-07-2017 16:31

Вот набросал:




Данный фрагмент ловит отсутствие какого либо изменения на входном порту в течении времени не менее 0,2 мс и не более 1,1 мс. Предделитель тайиера 1:8
dima83
Новичок
Сообщения: 2




31-07-2017 16:26

Написал несколько вариантов с анализом пауз и частотных посылок, включая вышеприведенный фрагмент, и вроде как работает - реагирует на комманды, но не всегда. То ли внутренний генератор проявляет нестабильность то ли еще в чем то дело. А вообще возможна ли точная работа пика на тактовой 4 МГц с частотами порядка 20 кГц (распознавание пауз, частотных посылок и прочее)?
Eex
Участник
Сообщения: 1522




31-07-2017 17:17

dima83 писал:
вроде как работает - реагирует на команды, но не всегда.

на таких частотах можно пользоваться логическим анализатором для отлова багов. Вряд ли проблема в контроллере или стабильности его частоты.
dima83 писал:
возможна ли точная работа пика на тактовой 4 МГц с частотами порядка 20 кГц

надо переопределить понятие "точная". Для меня "точная" означает, что я хочу по каждому фронту зажигать лампочку, а по каждому спаду - её тушить. В моём случае контроллер успеет ещё "в носу поковырять" в паузах. Если вы хотите в паузах "точно" вычислить SHA-1 для принятого пакета, то у вас проблема. В любом случае контроллер подбирается под задачу, а не наоборот. Точное обнаружение фронтов и пауз проблем для контроллера не составит. Другое дело, что надо грамотно распорядиться ресурсами контроллера (использование модулей и оптимизация кода).
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




03-08-2017 16:00

Думаю, что наиболее точным будет анализ по частоте (точнее по ее длительности), а не по паузе. Или вообще комбинированный анализ и по частоте и по паузе. Такие анализы часто реализуют с использованием прерываний. А если от прерываний вообще отказаться и использовать метод прямого подсчета? Если например задать цикл длительностью 100 мкс и в этом цикле инкреминировать в какой нибудь счетчик при появлении лог.1 на порту?
Eex
Участник
Сообщения: 1522




03-08-2017 16:33

Анализировать надо не то, что нам с вами в голову взбрело, а то, что в протоколе описано. Я не читал описание протокола, по этому теоретизирую. Если в описании сказано, что бит состоит ОБЯЗАТЕЛЬНО из паузы и частоты, то вам надо анализировать то, что займёт минимум системных команд. Длительность паузы и частоты дают не за тем, чтобы вы обязательно после паузы нашли частоту и следили за ней. Время паузы и частоты дают для того, чтобы сообщить вам о ГАРАНТИРОВАННОЙ паузе в протоколе для обработки пойманного сигнала. Таким образом, если вы поймали паузу и дождались её конца, то у вас есть гарантированные 0.5 (или сколько там было?)мс на принятие решения по факту обнаружения и буферизацию полученных данных. Допустим вам сказали, что единица, это 0.5мс, а 0 - 1.5мс, но не сказали какая пауза между ними, то как вы обработаете пакет, если новый бит может придти как через секунду, так и через 2 наносекунды? Для обработки результатов за 2 наносекунды, вам потребуется как минимум пентиум улыбка. Чтобы разработчик подобрал ресурсы контроллера, ему указывают гарантированную паузу между сигналами. Чем именно будет заполнена пауза, это никого не волнует (высоким, низким уровнем или частотой 22кГц). Паузы между доминантными уровнями заполняют тем, что требуется для протокола. B вашем случае 22кГц требуется для других нужд приёмной головки и длительное отсутствие этой частоты повлияет на приём. Таким образом надо во все паузы засунуть 22кГц, нo это не значит, что их надо отслеживать именно в вашем устройстве, пусть за ней следит головка. Читайте протокол, делайте сюда цитаты из него, подкрепляя ими ваши догадки. Обсуждать надо именно цитаты, а не мнимые наблюдения на осциллографе.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




03-08-2017 17:23

В описании протокола ошибка. И как раз с помощью осциллографа я ее выявил. Сначало должна придти частота, а потом уже пауза! Иначе мы по-просту не поймаем первую паузу! Дело в том что, если реализовывать алгоритм по подсчету только пауз, то в начальный момент включения спутникового тюнера в сеть прием пакета может быть ошибочным, поскольку в результате переходных процессов в канале возникает дребезг и этот дребезг ошибочно воспринимается как пакет данных. А если ловить именно по частоте, то таких проблемм не наблюдается. Ловить периоды в 47 мкс на пике с тактовой частотой в 4 мгц (1 машинный цикл - 1 мкс) довольно проблемматично. Проще ловить куски, ну скажем, по 100 мкс. Куски должны быть заполнены частотой. Если будет "пустой" кусок то это признак того что частота закончилась и нужно обработать то, что приняли....
Eex
Участник
Сообщения: 1522




03-08-2017 18:00

dima080383 писал:
В описании протокола ошибка

давайте сюда ошибку, обсудим её. Если ошибка в переводе документа, то найдём оригинал без ошибок. Может так оказаться, что ошибка в вашем осциллографе, а не в описании.

dima080383 писал:
Сначалa должна придти частота, а потом уже пауза!

естественно! ведь пауза является информацией, а частота - заполнителем. Если при подаче питания в протоколе будет вначале идти пауза, то это то же самое, что устройство не запитано улыбка.

dima080383 писал:
Иначе мы по-просту не поймаем первую паузу!

мы ловим паузу не по тому факту, что частота идёт до паузы или после паузы. Мы ловим паузу по её длительности!!! Если пауза короче, чем нам надо (нижняя полу волна частоты, это тоже пауза, но она короче, чем нам надо), то эта пауза нам не годится. Если пауза длиннее, чем нам надо (короткое замыкание на шине или просто обрыв), то эта пауза нам тоже не годится. Если пауза именно той длины, что мы ищем (к примеру дребезг при подаче питания совпал по длине с нашей паузой), то эту паузу мы считаем за полезный сигнал!!! Этот полезный сигнал мы сохраним и потом сравним с байтом "начало передачи". Если наш сигнал не совпал с искомым байтом начала передачи, то мы поймали не нашу паузу (отличие дребезга от настоящего сигнала).

dima080383 писал:
в канале возникает дребезг и этот дребезг ошибочно воспринимается как пакет данных.

если дребезг содержит все атрибуты нашего пакета (начальный байт, биты чётности, количество байт в пакете, контрольные суммы и так далее), то мы можем считать, что разработчик протокола допустил грубую ошибку в протоколе. Однако что-то мне подсказывает, что протоколы не разрабатывают ламеры с бухты-барахты.

dima080383 писал:
А если ловить именно по частоте, то таких проблемм не наблюдается.

если нет проблем, то вы достигли искомого результата, не так ли? Если тема живёт, значит есть проблема!?

dima080383 писал:
Куски должны быть заполнены частотой.

вы однобоко симулируете проблему. Из вашего рассказа получается, что дребезг именно пауза. Но пауза между чем и чем? Что будете делать, если дребезг составит 18кГц? Вы примите его за полезный сигнал? Или вы таки сумеете кодом отличить 18кГц от 22кГц? Как собираетесь отличать 18 от 22 на вашем контроллере? В прочем, если проблема решена, то что мы воздух трясём? улыбка
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




04-08-2017 09:54

Начну с того, что на рабочей частоте в 4 МГц пик не сможет различить 18 кГц и 22 кГц. По этой же причине бесполезно ловить периоды данной частоты. Так, например, на одном тюнере я поймал 22 периода в течении 1 мс частоты, а на другом 17....
Видимо у каждого тюнера своя амплитуда. Теперь о дребезге. Он появляется в момент включения ресивера в сеть и воспринимается контроллером как полезный сигнал. Дребезг содержит в себе как элементы частоты так и элементы паузы. Замечу, что не все тюнеры формируют дребезг в момент включения. У меня два тюнера: один включается без дребезга, а другой (Openbox f300) c дребезгом. Я написал программу на прямом подсчете выборок по 100 мкс без каких либо прерываний. Так вот если после анализа заполненных выборок не поставить цикл ожидания лог "1" с выдержкой в 2 мс, то анализ при включении тюнера в сеть происходит с ошибками. Я не понимаю почему именно 2мс, а не 1. И как оно будет работать с другими ресиверами!? Там ведь тоже возможен дребезг![/img]

Добавлено 04-08-2017 10:14

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

  осциллограмма_дребезг.jpg  53,06 КБ  Скачано: 23 раз(а)
  осциллограмма_пакет.jpg  86,78 КБ  Скачано: 25 раз(а)

Eex
Участник
Сообщения: 1522




04-08-2017 11:22

dima080383 писал:
пик не сможет различить 18 кГц и 22 кГц.

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

dima080383 писал:
Дребезг содержит в себе как элементы частоты так и элементы паузы.

Дмитрий, вы меня абсолютно не слышите! Попробую надавить авторитетом: я программировал софтварно порядка 15-ти различных протоколов и знаю о чём говорю. Реализация софтварного МАСТЕРА, это задача достаточно простая, но вот софтварный ПОДЧИНЁННЫЙ, это весьма и весьма трудная задача. У меня так и не удалось реализовать софтварный SLAVE для шины I2C на PIC18 контроллере с тактовой частотой 40мГц. К примеру требования протокола говорят, что бит STOP может придти в любой момент времени и его длина всего пару микросекунд. Получается, что вы должны ОДНОВРЕМЕННО принимать бит на шине, следить за START/STOP сигналами, буферизировать и обрабатывать полученную информацию. Следить за этим весьма и весьма трудно. Код надо реализовывать через громоздкие свитчи и сплошные goto команды, которые не только занимают много тактов, но и такты эти не стабильны (если goto сработал, то 2 такта, если нет - один).
Если этот протокол рассчитан на софтварную реализацию, то он ТОЧНО не предполагает анализ частоты и точно определил как поступать с дребезгом. Считать такты в частоте, это как угадывать погоду. Если вы не можете отследить частоту, значит за ней не надо и пытаться следить. На ваших картинках дребезга я так и не увидел ничего похожего на принятый БАЙТ, не говоря о принятом ПАКЕТЕ. Вы же пытаетесь мне сказать, что прибываете в панике от принятого похожего БИТА. Не надо паниковать от бита в дребезге, дождитесь конца байта и решите был ли он правдивым. Если байт правдивый, то дождитесь принятого пакета и решите правдивый ли он. Если пакет правдивый, то ГАРАНТИРУЮ, что это не дребезг и его можно исполнять!

dima080383 писал:
Он появляется в момент включения ресивера в сеть и воспринимается контроллером как полезный сигнал.

Не контроллером, а вашим ошибочным алгоритмом. Не "как полезный сигнал", а как полезный БИТ. Бит, это не всё! Это даже не байт и уж тем более не пакет. Полезным же "сигналом" следует считать как минимум байт и не просто байт, а байт "начало пакета", который установлен в правилах протокола.

dima080383 писал:
Я написал программу ....... без каких либо прерываний.
..... анализ при включении тюнера в сеть происходит с ошибками

Вы написали как умели, но не достигли результата, от сюда и ошибки. Программа пишется не на базе знаний программиста, а от возможностей контроллера. Если в контроллере есть прерывания, а сигналы быстрые, то прерываниями надо пользоваться и ошибок будет меньше. Если в контроллере есть модуль уарт, а сигналы имеют частотные характеристики, то надо рассмотреть успользование уарта для анализа. Я хочу сказать, что если вы "на спор" пытаетесь написать трудную программу без прерываний, то это одно. Однако если стоит задача написать надёжную программу, которая будет выполнять свою функцию, то надо использовать инструменты контроллера.

dima080383 писал:
привожу начальный фрагмент пакета.

По вашему дребезг похож на пакет? Очевидно, что пару строк кода без труда отличат пакет от подделки.

Дмитрий, мы зря трясём воздух. Пользуйтесь цитатами из описания протокола. К примеру напишите мне так:
я анализирую именно частоту т.к. в протоколе сказано: "пауза в бите не нормирована по уровню и имеет произвольную длину", следовательно в бите надо анализировать ИМЕННО частоту т.к. это легче описать в коде.

Когда вы начнёте МНЕ пояснять свои действия цитатами из протокола, вы ДЛЯ СЕБЯ поймёте всё, что я говорю гораздо быстрее.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




04-08-2017 11:42

Это похоже на мой спор с главным редактором ж "Радиолоцман". Когда я пытался доказать ему, что подуляция протокола NEC ИК ПДУ производится не от сплошного линейного излучения светодиода, а от кратковременных вспышек. (Так и не смог доказать)

Дребезг виден на осциллограмме. Это иглы и всплески, которые воспринимаются кантроллером как частота и пауза. Это на сам пакет полностью, это его фрагмент! Я пытался писать прогу и на прерываниях от порта и на прерываниях от порта и от таймера, считал даже периоды! Но все бузрезультатно! Что то работало на дном тюнере, но не работало на другом... Моя паника по поводу дребезга, ошибочно принятого за бит, понятна. Ведь пакет передается один раз! А ошибочно принятый бит тожет сдвинуть его или вообще может помешать его принятию. Из этого я делаю вывод, что первый бит пакета нужно принимать гарантированно верно! И уж если мы его "зацепили", то все остальное пойдет как по маслу.

Добавлено 04-08-2017 11:44

Я так понимаю, что кроме нас с вами (не знаю к сожалению вашего имени) тут есть и другие участники форума? Может они что то дельное подскажут?

Добавлено 04-08-2017 11:51

Да и еще, модуля UART в PIC12f629 нет.
Eex
Участник
Сообщения: 1522




04-08-2017 12:15

В споре рождается истина. Если вы не смогли убедить редактора, то слабоваты были аргументы. В нашем споре вы вообще аргументами не пользуетесь. Я играю в вашего оппонента только для того, чтобы вы отстаивали своё мнение пользуясь цитатами из описания протокола. Написать программу по наблюдением за осциллографом, не опираясь на протокол, это тупиковый путь. Если вы не устанете от нашей беседы раньше меня, то я прочитаю протокол и вам придётся парировать мои цитаты. Вы увидите как продуманы бывают протоколы для решения их задач.

А пока уточните для меня вот что:
Вы уже справились с первой частью программы? Напомню, первая часть программы должна УВЕРЕННО обнаружить каждый бит на шине, включая ложные биты дребезга ( бит дребезга должен приняться как правдивый бит, если его длина совпадает по характеристикам). Также программа должна знать о слишком коротком бите и о слишком длинном бите (ошибочных битах). Вторая часть- коллекционирование и анализ битов.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




04-08-2017 12:17

Я скажу вам так: если человек не хочет слушать, то никакие аргументы его на это не сподвигнут. А статья была хорошая. Жаль что так на бумаге и осталась(

Добавлено 04-08-2017 12:28

Значит так. Первая часть программы: анализ первого (и последующих) битов
1) кручусь в цикле и жду "1"
2) открываю цикл на 100 мкс и инкриминирую в счетчик +1 если увижу на порту "1"
3) по окончании цикла проверяю счетчик на ревенство 0, если равен 0 - перехожу на п.7
4) инкременирую +1 в счетчик выборок (100 мкс)
5) проверяю счетчик выборок на больше 12 (1200 мкс), если больше - слишком долгая частота - обнуляю счетчик выборок (100 мкс) и ухожу на 2

7) проверяю счетчик выборок (100 мкс) на равенство нулю

таким образом если пришел достоверный бит, то в счетчике выборок (100 мкс) должно быть число от 5 (бит "1") до 10 (бит "0")

Добавлено 04-08-2017 12:35
Eex
Участник
Сообщения: 1522




04-08-2017 12:43

чтобы сказать "на него аргументы не действуют", надо как минимум пользоваться аргументами. Если аргументов нет, то это мнение одного против мнения другого. Мнения у всех разные и только истина одна. Чтобы узнать истину, надо обратиться к первоисточнику. В нашем случае, это описание протокола. Описание протокола, это технический документ, в котором учтены все условия, реализуемые в протоколе. Если в протоколе допускается дребезг, то это описано в протоколе (дребезг и прочие помехи на фоне сигнала описываются как "шум в канале передачи"). Если дребезг (и прочий шум) не допускаются в протоколе, то об этом будет сказано (не явно сказано, а косвенно, вроде "первый бит может появиться после подачи питания через 100мс" или "шина передаёт данные на расстоянии не более 50 см"). Однако не бывает "канала передачи данных" без шума. Если протокол не предполагает обработку шума, то этот протокол не указывает вообще физический уровень передачи данных (вроде УАРТА, в его описании есть только скорости, но нет уровней напряжений). В нашем же протоколе есть "канал передачи данных", а значит есть и шум и дребезг. Дребезг, это нормально, это жизнь и никто его не игнорирует, тем более разработчики протоколов.

Добавлено 04-08-2017 11:49

Смотрите, я не особо рвусь смотреть ваш код, ведь код, это дело индивидуальное. В нашей беседе главное не моё мнение о вашем коде, а работоспособность вашего кода. Если код работает, то цель достигнута. Если код не работает, то надо искать проблему не в коде, а в алгоритме (код, это реализация алгоритма). Пока у вас проблема не в реализации хорошего алгоритма, а в том, что ваш алгоритм не работает. Вначале надо составить концепцию, что искать и как это искать. Мы не можем договориться что искать потому, что никто из нас не читал описание протокола. Однако мне это не надо (это же ваш проект, а не мой), а вот вам без описания не обойтись.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




04-08-2017 13:55

Я вам в самом начале привел описание стандарта Diseq равно как и тов. А.Николаеву приводил цитаты из книги Ельяшкевича по работе ИК ПДУ. В принципе его журнал - его правила. Может он считает, что публиковать материал зарубежных авторов на заумные темы намного интереснее, чем печатать то, что будет инетерсно многим новичкам-любителям на злободневные темы. А может он просто не захотел платить за мою работу. Как бы то ни было все аргументы я ему привел, все пояснения дал и на словах и в виде иллюстраций. Человек возамнил себя профессором-преодавателем, перед которым все должна дрожать как студенты в дни зачета и чей авторитет должен быть неприрекаем. Пусть это будет на его совести!

Добавлено 04-08-2017 13:59

я вот другое думаю: наличие частоты это не только лог.1. на порту контроллера! По идее мы должны поймать в течении 100 мкс (2 периода частоты 22 кГц) несколько лог "1" и лог "0"? Иначе вылавливая только лог "1" мы рискуем принять длинную полуволну дребезга за какой-нибудь бит
Eex
Участник
Сообщения: 1522




04-08-2017 14:39

dima080383 писал:
Я вам в самом начале привел описание стандарта Diseqт

если понадобится, я и сам найду описание, тем более, что мне не доступен к просмотру формат вашего документа. Я же говорю, не о том, что в интернете есть ссылки на описание протокола. Я говорю, что вы его либо не читали, либо не понимаете. Если описание понятно, то давайте чётко и АРГУМЕНТИРОВАНО решим что именно в бите мы отлавливаем. Если мы ловим частоту, то приведите аргументы из описания в поддержку частоты. Если от отлова пауз приходится отказаться, то приведите аргументы, которые не позволяют надёжно отловить паузы. Если можно отлавливать как паузы, так и частоту, то прикинем длину кода для отлова того и другого и сравним затраченные ресурсы на оба варианта. Я предложил отлавливать паузы т.к. код будет содержать порядка 10 строк, при этом мы будем способны отличить короткую паузу, длинную паузу, единицу и ноль. При этом 80% времени контроллер будет находиться в цикле goto $, в котором можно будет обрабатывать что угодно в любое время. В вашем коде контроллер 95% времени находится в цикле подсчёта 100мс паузы, в которую проблематично что-то вставлять.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




04-08-2017 15:15

ну так это его основная задача - принимать сигналы с порта
все остальное можно уложить в оставшиеся 5 %

Добавлено 04-08-2017 15:17

да я хорошо помню предложенный вами вариант с загрузкой в таймер 0,4 мс по первому прерыванию и определению переполнился ли таймер по последующему прерыванию... а если он переполнился, но дважды?? или трижды????

Добавлено 04-08-2017 15:20

На самом деле, отлавливая только паузу или только частоту, мы выполняем лишь половину условий протокола, поэтому вероятнасть ошибки 50%. Есть мы дополним программу пресловутыми багами то повысим вероятность еще 20-30 %. Но в любом случае вероятность ошибки будет на уровне 20-30%

Добавлено 04-08-2017 15:25

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

Добавлено 04-08-2017 15:31

теперь что касается аргументов:

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

паузу же хорошо отлавливать если в неактивное время в линии частота...
однако при работе в нижнем поддиапазоне в неактивное время в линии будет тишина

казус

и самое страшное это моменты перехода из нижнего поддиапазона в верхний и наоборот
Eex
Участник
Сообщения: 1522




04-08-2017 15:38

таймер никогда не переполняется дважды или трижды. Таймер подбирается такой величины, чтобы смог отсчитать 0.4 мс без переполнения. После первого переполнения он перезаряжается и начинает считать заново т.е. не переполняется дважды.

Я открыл описание вашего протокола тут: https://ru.wikipedia.org/wiki/DiSEqC
если это не ваш протокол (там есть разновидности), то дайте мне знать.
И так, по поводу метода обнаружения они говорят вот что:
DiSEqC использует для передачи широтно-импульсную модуляцию, при которой от ширины огибающей импульсов зависит передаваемый бит. Время передачи одного бита составляет 1,5 мс и условно разделено на 3 равные части по 500 мкс (±100 мкс). Для бита 0 ширина огибающей составляет 1.0мс, что соответствует 22 импульсам, а для бита 1 ширина огибающей составляет 0,5 мс, а это 11 импульсов.

ключевым словом в этой цитате является термин "огибающая импульсов". То есть есть некая кривая, которая огибает частоту (не судите строго мою картинку, на ней красная линия демонстрирует "огибающую"). Таким образом наличие частоты не рассматривается в протоколе именно как частота (она имеет допуск в +- 20%, то есть не малый допуск), но рассматривается как поднесущая для сигнала. Приведённая цитата позволяет нам не только не следить за частотой, но вообще не доводить её до контроллера. Мы вольны довести до контроллера только огибающую, отфильтровав поднесущую железом (фильтрами). Именно так нам и следовало бы сделать в железе, но увы железо, это то, что мы имеем как данность и придётся тратить программный код на игнорирование частотной составляющей.

Untitled.png



dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




04-08-2017 16:01

Не получится поставить интегрирующий фильтр! Мне нужно просто поменять контроллер в готовом уже устройстве!
Вы понимаете как тяжело работать с ВЧ цепями! Я пробовал собрать устройство с нуля, там такие потери, такие шумы!

Добавлено 04-08-2017 16:05

Таймер не может перезарядиться сам! Нужно его ослеживать либо по остатку либо по переполнению! А отслеживатьь как? В простом опросе в цикле? Или реализовывать прерывания от него? Пробовал и так и эдак.Очень сложно и безрезультатно.
Eex
Участник
Сообщения: 1522




04-08-2017 16:10

таймер не надо отслеживать. Я уже писал в первых статьях - таймер перезаряжается в своём прерывании и его следующее прерывание состоится гарантировано через 0.4мс. Других значений для таймера мы не используем, только 0.4мс. Если мы попали в прерывание от таймера, то мы знаем, что прошли 0.4мс.

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

вот это аргумент! С вводом понятия "огибающая" и отсутствием фильтров, наша задача усложнится. Вынужден признать, что ловить придётся как частоту, так и паузу.

Предлагаю такую стратегию:
1. заряжаем таймер на 0.4мс (в доке 0.5мс +- 0.1мс)
2. другим счётчиком считаем частотные импульсы пока бежит таймер
3. когда сработает прерывание таймера, посмотрим что со счётчиком:
а. если мы насчитали 11 импульсов, то перезаряжаем таймер на следующие 0.4мс и ставим маркер "одна треть сигнала равна единице"
б. если мы насчитали 22 импульса, то перезаряжаем таймер и ставим маркер "две третьи равны единице"
в. если насчитали более 23 импульса, то на ставим маркер "на линии слишком длинная частота"
г. если 0 импульсов, то ставим маркер "одна треть рaвна нулю". Если маркер уже установлен, то ставим маркер "вторая треть рaвна нулю"
д. .............
е. .............
ж. ........ коллекционируем всю информацию и считаем количество прерываний.
з. если насчитали 3 прерывания, то анализируем маркеры и решаем что мы приняли
Список форумов » Программное обеспечение » Микроконтроллеры » Программный анализ сигналов На страницу 1, 2, 3  След.
Перейти:  
Текущий раздел » Программное обеспечение » Микроконтроллеры (Микроконтроллеры - AVR-ы, PIC-и и другие)


Похожая информация:
  • PIC18F442-I/P как правильно считать программный код?
  • ПРИБОРЫ - способы измерения, параметры сигналов







  • Электроника
    Прошивки и схемы на телевизоры, мониторы, dvd, телефоны. Schematic, Service Manual (mode), eeprom dumps Информация по ремонту для специалистов - справочники, инструкции, энциклопедия, советы и секреты ремонта,  настройка, сервисные режимы поиск и продажа электронных компонентов, магазины, datasheet, pdf, размещение в интернете рекламы на сайтах электронной тематики
    Powered by phpBB 2.0.18 © 2001, 2002 phpBB Group!