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

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

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

Насколько понимаю сейчас, все методы делятся на две группы. В одной из них, уровень сигнала сравнивается (по интервалам таймера) с предполагаемым в N-раз чаще (2, реже - 3), чем он должен меняться. Если смена уровня сигнала происходит раньше или позже, чем должно быть, считается, что на входе не посылка, а шум. Во второй группе алгоритмов используется не прерывание по таймеру, а Input Capture, то есть, замеряется реальная длительность импульса, которая сверяется с ожидаемой. Если она отличается слишком сильно, импульс считается шумом.

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

Ткните в правильном направлении, pls.

Сообщение отредактировал G.Simenon - Dec 12 2016, 16:51

на каких скоростях планируете работать, и на чем потом реализовывать? микроконтроллер или FPGA?
поскольку общие принципы похожие, но подход и методы радикально разные.

1 - 9600 - 19200, приблизительно
2 - на м/к. В настоящий момент - на АтМеге.

Похоже, что с Input Capture возни больше в части пропуска помех. Noise Canceler пропускает только помехи короче 4 системных тактов, поэтому, если на Input Capture Pin придет помеха длиннее, то, чтобы исключить ложный захват, придется складывать захваченное значение длительности с предыдущей и оставаться в том же режиме захвата (falling/rising edge)?
Кто-нибудь пробовал то и другое, может подсказать в каком направлении двигаться?

Подаете на UART. Преамбула делается под захват UART-ом сначала битовой, а потом байтовой синхронизации, потом в протоколе захват фрейма с данными.

Ширина импульсов бывает некратная, да и плавает она. Плюс ограничения UART на формат фрейма, ему стартбит нужен низкий, в сигнале же следующий бит, после уже принятых UARTом, может оказаться высоким.
Софтово бы решить.

Сообщение отредактировал G.Simenon - Dec 15 2016, 17:54

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

Повторяю: "Преамбула делается под захват UART-ом сначала битовой, а потом байтовой синхронизации". Так что все решается. Естественно, передатчик тоже UART, ну и то, что он "A" решает и проблему различия битовой частоты.

Софтово будете разбираться наличием битовой и байтовой синхронизации и выделением фрейма. А всем остальным железка займется.

Увы, передатчик не UART.

Ах, вот как, софтом определять моменты включения UARTa... звучит сложнее, чем просто софтовая реализация.

Спасибо за вариант.

А что? Тогда огласите что за кодировка идет в канале? Синхронный? Асинхронный? Как формируется фрейм, который предстоит выделять? Битстаффинг?

Причем тут какое-то неведомое "включение UART"?

Один из первых проектов был похож на ваш (RXQ1-433 + AT90S2313 + IAR, любительская разработка, использовали на своём предприятии для телеметрии).
Правда нам пришлось ввести байтстаффинг для устойчивой синхронизации начала пакета и заточен на наш протокол. Т.е. пока устройство не примет весь пакет, не проверит crc, не передаёт его по rs485 (ну и так же обратно). Код, конечно, не идеальный (давно это было в 2003), но устройство рабочее и можно посмотреть как мы это реализовали тогда.

Zltigo, Вы для меня слишком "гуру" - мне без примера непонятно, какое решение Вы имеете ввиду. Увидеть бы что-то из этой серии...

Dm37, спасибо за пример!

Сообщение отредактировал G.Simenon - Dec 15 2016, 18:36

в своё время рассматривал в основном два метода кодирования сигнала манчестер и вроде 4b/5b, почитайте о них.

Спасибо. С манчестером сталкивался, с "4b/5b" нет. Почитаю.

Сообщение отредактировал G.Simenon - Dec 15 2016, 18:56

Это не о том совсем, если я хоть что-то понимаю о пишет Автор.


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

UART'ом не стоит путать человека, надо привязываться к виду модуляции. В случае с ЧМ нельзя подавать uart-овские сигналы напрямую на модулятор: будет плавать постоянная составляющая. Потому либо Манчестер (легко декодируется Атмегой, но раширяет полосу вдвое), либо FSK/FFSK/GMSK на этих скоростях. С программой повозиться придется, да и далеко это будет от оптимального приемника. Но выпускаются модемы для этих способов (можно поискать у CML), либо DSP.