Универсальный дешифратор диапазонов с индикацией на PIC16F628A

[UN7GCE]

Для Евгения, не понятно, для чего у Вас на выходе сигнала блокировки поставлена интегрирующая емкость довольно большая?

Верно, Юрий!
Я в 27 сообщении выложил измененную схему, где R3, C7 вообще можно ликвидировать. Они должны стоять в РА. Импульс формируется программно. Как закажете - так и будет.
Насчет алгоритма работы программы.
В принципе всё именно так и работает.
Если нет сигнала, то счетчик крутится сам в себе. Каждые 100 uSec делает измерения. Я ошибся выше, написав, что измерения идут до 100 кГц. Измеряется с точностью до 10 кГц. Если при измерении буфер счетчика пустой, то никаких других действий не производится. Просто крутится сам в себе.
Появился сигнал. Буфер заполнился (у DK4DDS загорается диод). В моей программе буфер частоты заполняется только десятым измерением и поднимается флаг заполнения буфера. Далее запускаются подпрограммы сравнения, дешифрации. Если код бенда не совпал с ранее записанным, запускается формирование импульса блокировки РА и меняется код на выходе. Уходим в начало.
Измерение частоты продолжается, буфер частоты не пустой, (горит диод у DK4DDS), но флаг стоит.
Никаких действий не производится. Уходим в начало.
Появилась пауза. Флаг буфера сбрасывается (гасится диод). Измерение частоты продолжаться, но буфер частоты пуст. Ничего нет делается. Возврат в начало. Кольцо.
Вот и весь алгоритм. Довольно простой и несложный.
Мне кажется, что тут нужно организовать задержку перед первым измерением. Теорию подогнать не могу – не знаю. Остаётся подобрать эмпирическим путём. Вот и маемся :-)

[Владимир_К]

Считаем по переднему.
Вопрос – сколько времени занимают переходные процессы переднего фронта? На этот период ставим задержку счета.
Сколько времени занимает передний фронт SSB сигнала? На этот период ставим задержку счета.
Сам счет занимает 100 uSec.

Мне кажется, было бы проще завести еще один сигнал на свободный порт процессора, тем более он у Вас есть на разъеме (RB7), не надо ковырять плату. Сигнал взять с датчика потребляемого тока УМ или с выхода КСВ-метра. Измерение надо начинать тогда, когда этот сигнал появился после паузы. Подробнее. Проверяем состояние порта RB7. Есть сигнал - уходим, проверяем снова и, так до тех пор пока не обнаружим паузу. После чего ждем появление сигнала и уже тогда начинаем измерение частоты. Выше RV3DLX, как раз и описал такой алгоритм.

[UN7GCE]

Есть сигнал - уходим, проверяем снова и, так до тех пор пока не обнаружим паузу.

Владимир, пауза определяется очень легко!
Если буфер частоты пуст, то флаг Z=1
movf Freq,F
btfss STATUS,Z
goto n1
goto n2

[Владимир_К]

Если нет сигнала, то счетчик крутится сам в себе. Каждые 100 uSec делает измерения. Я ошибся выше, написав, что измерения идут до 100 кГц. Измеряется с точностью до 10 кГц. Если при измерении буфер счетчика пустой, то никаких других действий не производится. Просто крутится сам в себе.
Появился сигнал. Буфер заполнился (у DK4DDS загорается диод). В моей программе буфер частоты заполняется только десятым измерением и поднимается флаг заполнения буфера. Далее запускаются подпрограммы сравнения, дешифрации. Если код бенда не совпал с ранее записанным, запускается формирование импульса блокировки РА и меняется код на выходе. Уходим в начало.
Измерение частоты продолжается, буфер частоты не пустой, (горит диод у DK4DDS), но флаг стоит.
Никаких действий не производится. Уходим в начало.
Появилась пауза. Флаг буфера сбрасывается (гасится диод).

Не нравится мне такой алгоритм... Почему? Допустим у Вас пауза - но счетчик крутится. Во время когда он крутится (например посредине цикла счета) появился сигнал. В буфере появится число. Но оно не соответствует истинному, так как начало счета наступило раньше чем появился сигнал. Поэтому все же обратите внимание, что я написал выше.

[UN7GCE]

Не нравится мне такой алгоритм... Почему? Допустим у Вас пауза - но счетчик крутится. Во время когда он крутится (например посредине цикла счета) появился сигнал. В буфере появится число. Но оно не соответствует истинному, так как начало счета наступило раньше чем появился сигнал.

Разбираем этот случай. Пауза, крутится счетчик. Флаг частоты = 0. Появился сигнал. Я в буфер частоты пишу четвертое , или десятое измерение. Что тут плохого? По времени десятое измерение это всего 1 mSec

[RV3DLX]

Владимир, ну зачем так усложнять, не нужно никакой обратной связи по току или по КСВ, все и без этого работает. Анализироваться должен только входной сигнал. Ну и мне кажется не нужен измеритель периода или длительности импульсов, нужен элементарный частотомер, когда известный временной интервал должен заполнятся входными импульсами, поскольку точность измерения здесь не нужна, время измерения может быть очень маленьким, поэтому если делать даже несколько измерений, то это время будет практически незаметно.
Юрий.

[Владимир_К]

Разбираем этот случай. Пауза, крутится счетчик. Флаг частоты = 0. Появился сигнал. Я в буфер частоты пишу четвертое , или десятое измерение. Что тут плохого? По времени десятое измерение это всего 1 mSec

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

[Integral]

Следующий я ещё не пробовал, но на праздники постараюсь сделать. Суть его такова. Делаем 4 (10) измерений и за правильное значение берем самое большое.

Этот вариант действительно нужно опробовать. Ложные срабатывания в SSB происходят только ниже включенного диапазона. Это видно по видео, которое мы выложили в начале темы. Здесь нужно практически определить оптимальное количество выборок (измерений).

Добавлено через 6 минут(ы):

Остается только предположить следующее. Не фиксирует ли девайс просто переходной процесс (например - щелчок при включении на передачу, когда "алекать" еще не начали).

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

[UN7GCE]

Этот вариант действительно нужно опробовать. Ложные срабатывания в SSB происходят только ниже включенного диапазона. Это видно по видео, которое мы выложили в начале темы. Здесь нужно практически определить оптимальное количество выборок (измерений).

Мне ещё не приходилось заниматься сортировкой на ПИКе, начнем с двух значений, затем на четыре... Может поймаем мышку.

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

Вот этот момент мне, честно говоря, до сих пор не понятен. Что значит при нажатии на тангенту? Срабатывает на остаток несущей? Или это фон с микрофона? В чисто телеграфном режиме тоже так?

[Integral]

Что значит при нажатии на тангенту? Срабатывает на остаток несущей? Или это фон с микрофона? В чисто телеграфном режиме тоже так?

Если перещелкнуть тангентой в SSB на любом диапазоне или просто перейти на передачу, но ничего в микрофон не говорить, дешифратор правильно определяет диапазон. Дальнейший разговор в тангенту приводит к случайному определению диапазона, находящегося ниже рабочего.
А вот правильное определение диапазона происходит по остатку несущей или по короткому всплеску пока не ясно, мы еще не выясняли. Да и наврядли узнаем, слишком быстро это происходит. Замерить нечем, разве что С1-94.