Добрый день! Есть задача передать телеметрические данные по радиоканалу. Стандартные радиомодули не подходят, так как с ними удалось перекрыть только 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, судя по ваши постам, вы в теме происходящего, но вот почему-то дать подсказку - вы сразу шлете.

Сообщение отредактировал RA3MAH - Mar 27 2017, 18:05

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

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

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

Сообщение отредактировал arhiv6 - Mar 28 2017, 06:36

Понятие фрейма относится далеко не только к пакету с БАЙТАМИ, но и, например, к собственно в самому байту, если таковое деление используется. В потоке битов (после захвате битовой синхронизации, естеств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).

Сообщение отредактировал arhiv6 - Mar 28 2017, 10:03

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