Алгоритм отлова пакета в радио канале. Help pls! Опции

[G.Simenon]

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

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

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

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

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

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

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

[G.Simenon]

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

[zltigo]

...может подсказать в каком направлении двигаться?

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

[G.Simenon]

Подаете на UART.

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

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

[zltigo]

Ширина импульсов бывает некратная, да и плавает она.

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

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

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

Софтово бы решить.

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

[G.Simenon]

Естественно, передатчик тоже UART, ...

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

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

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

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