BandData decoder для Kenwood

[Serg_PRQ]

Давайте попросим модератора выделить отдельную тему о Kenwood band data decoder, начиная с моего сообщения "вот бы такое для кенвуда"?

Сергей, а кто мешает создать свою тему здесь в общей ветке, коль Вам это интересно и нужно? Лично у меня "кенвуда" нету, поэтому практическое применение не грозит
Ну чем смогу- поддержу тему, "с миру по нитке ....", как говорится.

[ut1wpr]

Давайте попросим модератора выделить отдельную тему о Kenwood band data decoder, начиная с моего сообщения "вот бы такое для кенвуда"?

Да ну его, полупустые темы плодить. Не боярское это дело. Эта самая веточка поживет-поживет, да и канет в лету. Даже независимо от результата.
Я сейчас намалевал (с трудом к программированию отнести можно ) фрагмент приема блока символов от Кенвуда. И вот вопрос. Есть ли смысл принимать все 38 байтов, чтобы убедиться в наличии финализирующего ";" или можно просто после приема "IF" проверить отсутствие ";" (исключить запрос), отсчитать наличие трех нулей и взять два байта частоты? Так вроде, пошустрее будет. А с другой стороны, куда спешить. Что 38 байтов, что 7... На какие-то десятки миллисекунд задержится отработка переключения.
Еще добавил механизм отработки прерывания по смене состояния пина плюс старт таймера. Там же Обработчик прерывания этого таймера.
Любопытно было взглянуть на выходной листинг. Взглянул. Безошибочная компиляция. Что захотел, то и получил. А что захотел - это уже вопрос...

[Serg_PRQ]

И вот вопрос. Есть ли смысл принимать все 38 байтов, чтобы убедиться в наличии финализирующего ";" или можно просто после приема "IF" проверить отсутствие ";" (исключить запрос), отсчитать наличие трех нулей и взять два байта частоты? Так вроде, пошустрее будет.

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

Насчет АВ: сомневаюсь, что большинство здесь присутствующих что-то понимает в этих диаграммах, поэтому нет смысла доводить все это до народа Чтобы понять, как это работает, хотя бы на 90%, нужно работать с самим АВ.
Я, например, как-то пытался было разобраться- но что-то не смог преодолеть планку, а сейчас и не вижу большого смысла для себя, вот сишный код глянуть еще можно, только он не будет таким простым...
Все это узкоспециализированн ое хорошо, только для тех кто уже прошел по этим граблям, а таких здесь можно по пальцам пересчитать, да и не интересно им здесь, в отличии от Вас, Виктор.
Только получается, что сами с собой будете здесь все обсуждать, что-то желающих все это дело пробовать не находится, либо ждут что получится. Наверное пока все заняты, подождем как будет посвободнее, сам такой :?

[ut1wpr]

И вот вопрос. Есть ли смысл принимать все 38 байтов, чтобы убедиться в наличии финализирующего ";" или можно просто после приема "IF" проверить отсутствие ";" (исключить запрос), отсчитать наличие трех нулей и взять два байта частоты? Так вроде, пошустрее будет.

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

Насчет АВ: сомневаюсь, что большинство здесь присутствующих что-то понимает в этих диаграммах, поэтому нет смысла доводить все это до народа Чтобы понять, как это работает, хотя бы на 90%, нужно работать с самим АВ.
Я, например, как-то пытался было разобраться- но что-то не смог преодолеть планку, а сейчас и не вижу большого смысла для себя, вот сишный код глянуть еще можно, только он не будет таким простым...
Все это узкоспециализированн ое хорошо, только для тех кто уже прошел по этим граблям, а таких здесь можно по пальцам пересчитать, да и не интересно им здесь, в отличии от Вас, Виктор.
Только получается, что сами с собой будете здесь все обсуждать, что-то желающих все это дело пробовать не находится, либо ждут что получится. Наверное пока все заняты, подождем как будет посвободнее, сам такой :?

ОК. Принято.

[Serg]

Сергей, а кто мешает создать свою тему здесь в общей ветке, коль Вам это интересно и нужно? Лично у меня "кенвуда" нету, поэтому практическое применение не грозит

У меня нет таких полномочий, чтобы разделять тему и переносить сообщения в новую. Раз Вы и Виктор пропозицию не поддержали, ладно, давайте здесь общаться... Во всяком случае, пока нас никто не попер отсюда...

Конструкция нужная - ко мне обратились уже несколько друзей-кенвудистов и говорят ждем тоже!

По поводу выкладок, я к сожалению микроконтроллерами никогда не занимался, хотя навыки в программировании на РС имеются и кое какие процессы понимаю, не совсем все-таки "тупой пользователь".

И вот вопрос. Есть ли смысл принимать все 38 байтов, чтобы убедиться в наличии финализирующего ";" или можно просто после приема "IF" проверить отсутствие ";" (исключить запрос), отсчитать наличие трех нулей и взять два байта частоты? Так вроде, пошустрее будет. А с другой стороны, куда спешить. Что 38 байтов, что 7... На какие-то десятки миллисекунд задержится отработка переключения.

Затрудняюсь ответить, здесь, наверно, только эксперимент даст ответ...

P.S. Тип контроллера уже окончательно выбран, можно начинать разводку? Я хочу поставить там еще пару сборок ключей для управления реле ULN2004 (по 6 в каждой)...

[ut1wpr]

Сергей, а кто мешает создать свою тему здесь в общей ветке, коль Вам это интересно и нужно? Лично у меня "кенвуда" нету, поэтому практическое применение не грозит

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

Не надо путать тему и ветку. Суть разные вещи.

Конструкция нужная - ко мне обратились уже несколько друзей-кенвудистов и говорят ждем тоже!

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

P.S. Тип контроллера уже окончательно выбран, можно начинать разводку? Я хочу поставить там еще пару сборок ключей для управления реле ULN2004 (по 6 в каждой)...

С ключами поаккуратней. Внимательно изучи даташиты. Есть мс на 6, 7 и 8 ключей. И в каждом виде есть свои подгруппы. Не возьми случайно CMOS-уровневые для стыковки с TTL. Не откроются полностью.
Насчет выбора контроллера, не убежден. Я пока буду макетировать на том, что есть под рукой. Мега48. Tiny2313 по заверениям продавцов будет через неделю, не раньше. Развести пару ножек - вопрос короткого времени. Не торопись, а то успеешь

[Serg_PRQ]

Насчет выбора контроллера, не убежден. Я пока буду макетировать на том, что есть под рукой. Мега48. Tiny2313 по заверениям продавцов будет через неделю, не раньше. Развести пару ножек - вопрос короткого времени.

Гонялся за 2313-ми почти месяц. Когда привезли- навалилась работа и другие планы, валяются теперь невостребованные. Конечная цена оказалась почти равной меге-8, я понимаю, конечно, что это типа из "пушки по воробьям"- но такова объективная реальность у нас в области. Потому можно сильно не зацикливаться на контроллере- подойдет практически все что удасться найти подешевле, а перетранслировать код на другие порты- пустяки.
Насчет ключей- дело вкуса, конечно, щас много интересных драйверов, вопрос в возможностях. Лично я бы не заморачивался- поставил по 1 ключику типа КТ815 (что за релюхи, а то и КТ315 хватит) + 1 резистор в базе. Себестоимость практически нулевая, авр потянет с запасом даже мелкий. Насчет повторяемости вообще молчу

[Serg]

Развести пару ножек - вопрос короткого времени. Не торопись, а то успеешь

Я не спешу и не тороплю тоже Тем более, радио пока на TX не работает, драйвер полетел...

Почему сборки ключей - там уже и диоды есть защитные внутри. Меньше паять и сверлить.

[ut1wpr]

За неимением нужного аппарата приходится писать эмулятор.
Чем сейчас и занимаюсь.

[ut1wpr]

За неимением нужного аппарата приходится писать эмулятор.
Чем сейчас и занимаюсь.

Наваял эмулятор. Теперь с его помощью легче будет проверить концепцию "повторителя" :-)
Если кто может, протестируйте контролем осциллографа по выходу на порту. У меня вроде работает

На первом "снимке" можно оценить длину передачи полного пакета из 38 байтов.
На втором четко читаются коды символов "IF000". 49h,46h,30h,30h...
На третьем по длительности стартового импульса можно определить бодовую скорость передачи.