Добрый день! Есть задача передать телеметрические данные по радиоканалу. Стандартные радиомодули не подходят, так как с ними удалось перекрыть только 1000 метров, требуется несколько км. В качестве устройств передачи будут использоваться радиостанции. Передача в спектре голосовых частот. Передатчик излучает либо 1000 гц это логический 0, либо 2200 это 1. Частоты манипуляции могут быт любыми. Оптимальное решение - baycom модем, но к сожалению не могу найти исходный код, дабы дописать под свои нужды. С передатчиком проблем не возникло. Передаваемое событие будет содержать либо 5, либо 9 байт, если получится нормально реализовать. Байт состоит из 4 бит. Например, событие 123456789 будет кодировано и передано, как 0001 0010 0011 0100 0101 0110 0111 1000 1001. 0 - тон 1000 Гц, 1 - 2200 Гц. Проблема возникла с демодулятором. Понимаю, что нужно реализовать алгоритм Герцелля или Быстрое преобразование Фурье. Но в математике не очень. Пишу на BASCOM-AVR. Может кто-то делал подобное? и не обязательно на AVR и готов поделиться кодом или показать пример. Считать импульсы переходом через 0 корректно не получилось. Так как, если выключить у радиостанции шумоподавитель - появится эфирный шум (пшшшшш), и из-за этого микроконтроллер выдает ересь. DTMF оставил на крайний случай, так как скорость передачи очень мала. Передача будет односторонняя, достоверность доставки сообщения будет обеспечена избыточностью, т.е. сообщение будет передано много-много раз в течении, например 10 минут. Спасибо.

Вообще то уже "возникло".
1) Необходима передача некой последовательности по которой приемник сможет захватить, как минимум, битовую синхронизацию.
2) Надо что то обеспечивабщее фрейминг.
3) Напрашивается избыточное кодирование при передаче.

Займитесь лучше чем нибудь другим. Не программированием.

1)Реализовать стартовый бит не проблема
2)Что-то непонятное и ненужное
3)Зачем кодировать телеметрию?
4)Я и занимаюсь. Было бы намного полезнее, если бы, Вы, объяснили, показали, собственно для чего и нужен форум, а не рассуждали кому и чем заняться.

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

Не понятен вообще смысл вашего ответа в теме, если, к сожалению, никаким советом вы помочь не можете. Зачем писать пустые посты, если вы не в теме происходящего. Без обид.

zltigo, судя по ваши постам, вы в теме происходящего, но вот почему-то дать подсказку - вы сразу шлете.

Принятый пакет вы можете разобрать только захватив его от начала и до конца. А если один бит вначале пропустили, или часть пакета из-за помех потеряли или приняли лишний бит в конце? Данные будут невалидны. Чтобы этого не произошло - во-первых необходимо чётко определить что в радиоканале началась передача данных - определить начало пакет. Делается это с помощью синхронизации - в начало пакета добавляется преамбула, которую легко и однозначно можно будет определить даже в условиях помех. Далее, определив начало пакета нам необходимо знать, когда пакет закончится и необходимо прекратить захват. Если длинна пакета не фиксированна и неизвестна для этого применяют фреймеры (почитайте про SLIP/COBS), если длинна пакета фиксированна - без этого можно обойтись. После приёма необходимо проверить - а правильно ли данные приняли, т.к. из-за помех часть данных могла быть повреждена, для чего в пакет добавляется контрольная сумма, которая в приёмнике проверяется. Кодирование может потребоваться для коррекции ошибок или повышения чувствительности.

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

ТС, вам скорее всего проще сделать так: копить небольшие пакеты данных, в конце добавить контрольную сумму, обернуть в SLIP фрейм и закодировать в DTFM кодере. На приёмном конце раскодировать, пропустить через дефреймер, проверить crc и всё, данные получены.
Реализаций CRC, SLIP и DTFM в сети полно, проблем с переносом с С на BASIC проблем возникнуть не должно, все три части можно независимо друг от друга реализовать и проверить. Но лучше переходите на С, даже переписывать ничего не придётся.

Понятие фрейма относится далеко не только к пакету с БАЙТАМИ, но и, например, к собственно в самому байту, если таковое деление используется. В потоке битов (после захвате битовой синхронизации, естествeнно) Вы должны найти НАЧАЛО передаваемой информации. Так что понятие фреймнига есть ВСЕГДА без него не обойтись.
В остальном все правильно.

А чем готовое не устраивает?
Вот, например, как раз то что Вам нужно: http://mir-omsk.ru/products/equipment/for_info/modem_mp_04/



Это в какой вселенной???? Подучите терминологию хотя-бы. То что Вы имели в виду, называется "слово".


Ни то и ни другое не нужно.
Фильтрация - разложение на квадратуры - опять фильтрация - автокорреляционный (вроде?) демодулятор - битовая синхронизация - кадровая синхронизация. Примерно так упрощённо выглядит структурная схема приёмника.


Без математики в такой теме делать нечего. И тем более с BASCOM и AVR.
Устройство по ссылке выше например выполнено на DSP TMS320VC5502. Этот DSP там загружен примерно на 30% при приёме nQPSK pi/4 на 9600 бод при работе на ~220МГц тактовой и коде демодулятора написанном на асме.
На CPFSK и на малой скорости там конечно нагрузка гораздо ниже, но всё равно имхо - для AVR - запредельная.


Могу показать пример реализации на асм для TMS320VC5502. Надо?


Детский сад какой-то....
Вам читать и читать теорию много дней, потом моделировать блок-схему в матлабе, прежде чем подходить к компилятору.

Я не понимаю этого снобизма. Не о чём говорить - не говорите. Бейсик автору не подходит? Укажите почему и посоветуйте альтернативу.
А так - это оскорбительное мнение, которое вполне можно было оставить при себе.


Это вполне может называться и байтом. 8-битный байт всего лишь частный случай и существовал не всегда даже в нашей вселенной...

Это всё если демодулировать в реальном времени. Можно конечно демодуляцию делать не в реальном времени, но тогда потребуется внешняя память (для захвата сэмплов сигнала), ибо внутренней в AVR не густо.


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

Большое спасибо, тем кто откликнулся помочь) Преамбулу хотел вводить, просто забыл про неё написать. При исследовании посылки заводского оборудования было выявлено, что во всех устройствах она имеется. Где-то риализована тоном отдельной частоты, где то методом FSK, но определённым началом посылки. Пакет будет иметь фиксированную длинну 9 байт. Байт состоит только из цифр от 0 до 9, поэтому и было принято решение о кодировании байта 4-мая битами. Но вопрос по прежнему актуален в разборе посылки, то есть алгоритме или примере кода. То есть, что бы при тоне 1000 гц в переменную записывался 0, а при тоне 2200 - 1. Преамбулу уже додумаю сам, в случае необходимости введу бит синхронизации и окончания пакета. Я пробовал вычислять частоту тона измерением перехода через 0, но этот метод не практичен. Хотелось бы методом цос реализовать БПФ, что бы тон был корректно распознан, но на баскоме не нашёл примеров. Может есть у кого на Си? На асме будет тяжко, но тоже не откажусь. Спасибо.

Для детектирования 2х частот БПФ не нужен - используйте алгоритм Гёрцеля. Посмотреть реализацию - можно в любом DTFM декодере (например AN218 от SiLabs).

Реализовали подобную задачу на FX604. Дальность при прямой видимости - до 10 км.
Но основные проблемы использования - лицензирование частоты.

Дальность вообще-то должна зависеть от радиостанции, её вых. мощности и антенн.


Начнём с корня квадратного. TMS320VC5502, CCS3.3:


пожалуйста

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

Если четырехбитные слова, тем более имеет смысл обойтись DTMF. Синтезировать программно, принимать аппаратным декодером. Дешево, надежно практично.

Я делал подобное, односторонняя передача, 7 слов за 280ms(один пакет данных). Преамбула - решетка, фиксированная длина данных, КС из двух слов. 20мс передача, 20мс пауза.

Вот на счет "надежно" - плавали, знаем (применительно к DTMF). В реальном эфире - паршиво. Да, с аппаратным декодером (8870, 8880). А все равно паршиво. А вот модем SmarTrunk-2 (топикстартеру я его в качестве примера приводил) - как часы. Через аудиоконтакт, в шумах - а все равно работает. Но, конечно, на бейсике это не написать... Ресурсы - хватало PIC16x84 @ 4 MHz.

Что есть куча решений, лучше чем DTMF, никто не сомневается. Но тогда надо плотно лезть в цос и связь, иметь инструменты для верификации решений. А это немалое время и немалые деньги. Тут уже Тсу решать.

Предлагаю С/С++ ибо в эмбэддэд мире все примеры/библиотеки и даже люди, у которых можно спросить совет, живут на С/С++. Также лично я не верю, что какой-то там бейсик компилятор будет обеспечивать сравнимую с современными С компиляторами оптимизацию.
Таким образом человек, который программирует микроконтроллеры на бейсике заранее стиавит себя в очень неудобное положение.

Все же ассемблер я не потяну... Подскажите, пожалуйста, ссылочки по БПФ на си. Более разумно получится.

это общая библиотека так сказать полнофункциональная и на Си
http://sourceforge.net/projects/kissfft

Вот на авр дэмка(с другой библиотекой, более подходящей для авр)
https://sourceforge.net/projects/avrfftlcd/

Вставлю свои 5 копеек. Конечно ЦОС на DSP это всё здОрово, но для FSK/MSK вполне можно обойтись из без этого. Взять хотя бы тот же CMX469 который выделяет MSK сигнал на фоне шумов без сложных алгоритмов, просто по переходам через ноль, и надо сказать выделяет очень неплохо.
А когдато давно были еще АОНы
где весь алгоритм обрабатывался на процессоре типа Z80, правда там битовая (или символьная) скорость очень низкая -несколько символов в секунду, но и AVR куда мощнее процессоров 30летней давности.

Основа CMX469 и аналогичных, как я понимаю, это цифровой генератор с ФАПЧ, который во время преамбулы настраивается на среднюю частоту между нулем и единицей и далее по сигналу с ФАПЧа (в режиме частотного дискриминатора) определяет что передается - ноль или единица. Если 1 символ кодировать несколькими периодами сигнала (СМХ работает по одному или половинке периода), то выделение будет еще надежнее ИМХО.

"Просто по переходам через 0" - это на фоне даже сравнительно небольших шумов работать не будет.
Хотя всё конечно зависит от....
При отсутствии какого-то намёка на ТЗ или хотя бы требований, гадать невозможно.
Какая требуется символьная скорость? При каком минимальном SNR требуется устойчивый приём? Какова полоса частот в которой нужно работать?
Какова АЧХ тракта передачи (ЦАП/АЦП+цепь_согласования+р/ст) в этой полосе (её линейность)? Какова требуемая скорость работы алгоритма? И т.п.
Без этого всё это - гадание на кофейной гуще.
Может и AVR справится. Всё зависит от требований.
Может есть куча памяти, в которую можно принять поток сэмплов, и куча времени чтобы этот поток потом неспешно декодировать даже самыми сложными алгоритмами хоть на бейсике.
Да и ТС никакую теорию изучать не хочет, хочет чужой говнокод прикостылить.... А значит - ничего путнего сделать не сможет.

С/Ш=12 дБ и ниже до 8дБ -работает нормально.

А не подскажите аналоги микросхемы?

Прямых аналогов нет (или я их не встречал), есть как более навороченные, так и узкозаточенные под конкретное применение, с пакетной обработкой и с конкретными протоколами. Например CMX969 с форматами RD-LAP и MDC, CMX909 с mobitex-ом (модуляции FSK и GMSK). Есть CMX7164/7143 -у этих возможностей еще больше, но они и сложнее в использовании.
Модемы
Мой коллега делал функциональный аналог 469го на транзисторах -в симулякре, в духе импортозамещения, вытягивал сигнал из шумов даже когда сигнал визуально не было видно, были варианты для детектирования не только MSK сигнала по типу CMX469, но и MSK-3 и даже манчестерского кода. Основная проблема сколько помню была не столько выделить полезные биты информации, сколько необходимость осуществлять непрерывную битовую синхронизацию. К сожалению дальше симуляции дело не пошло

Тот модем на DSP, что ссылку я приводил выше - тоже нормально принимал данные даже когда сигнал на глаз был не различим на фоне шумов. Проблема с битовой синхронизацией была там решена (непрерывная и не нужна - нужно в начале кадра засинхронизироваться, а в пределах кадра точка синхронизации не успеет выйти за пределы бита).
И он уже больше 10 лет производится и продаётся.

Очень хорошо, тогда почему нет этих данных на страничке с тех.характеристиками? Есть только расплывчатые параметры диапазонов скоростей и чувствительность входа интерфейса радиостанции. Но нет самого главного - отношения C/Ш при конкретной битовой ошибке. Может я чего не понимаю, но если я хочу включить сей девайс между приемопередатчиком и системой которая собирается обмениваться по RS232, то чтобы просчитать параметры системы мне нужно знать хотя бы минимальный С/Ш при котором Ваш модем обеспечивает конкретную битовую ошибку (например 10Е-3) при конкретной скорости обмена (например 4800), требуемая ширина полосы канала приемопередачи и её допустимая неравномерность (это если я хочу использовать не какуюто стандартную радиостанцию, а свой собственный приемопередатчик). Вы можете привести такие данные?

Описание выкладывал не я - так что не знаю. По нему было больше документации (ТУ и т.п.), но выложили только РЭ - не мне это решать.
Было это довольно давно уже (больше 10 лет назад), но помнится что на скоростях 4800 и 9600 использовалась полная вся полоса Motorola GM340/350 (7100 Гц вроде) с выключенным фильтром. На меньших скоростях - используемая полоса уже. Для указанных р/ст измерена и занесена в ПО таблица корректировки АЧХ для эквалайзера (так же есть вариант работы на проводную линию, в котором корректируется только АЧХ внутренних цепей модема).
Корректировка эквалайзером критична только для 9600, ну может ещё 4800, на меньших скоростях искажения АЧХ трактом р/ст почти не влияли на работу. На 9600 там - pi/4 nQPSK, на 1200, 2400, 4800 - CPFSK.