Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Как обеспечить разбивку на кадры в радиоканале?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Вопросы системного уровня проектирования
ataradov
Есть радиоканал. Физическая суть не важна. Важно то, что есть поток бит (на битовой скорости). Если передатяик ничего не передает, то поток бит - мусор, если передает, то полезные данные.

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

Может есть какое описание? Я в принципе представляю как это можно сделать, но хотелось-бы почитать как другие делают. В книгах по связи этот вопрос обычно разоран в постолшьку-поскольку.
PSP
Обычно перед пакетом делают преамбулу, например несколько десятков 0x00. Затем признак начала пакета, данные и контрольная сумма с байтстаффингом, признак конца пакета. Как простейший пример можно посмотреть реализацию SLIP.
petrov
Вначале преамбула с достаточным количеством символьных переходов для обеспечения всех синхронизаций. Затем стартовая последовательность с хорошей автокорелляционной функцией, обеспечивающая вероятности пропуска и ложного обнаружения. Потом длина кадра(на передаче придётся буфиризировать и считать перед тем как передавать) или можно использовать фиксированную длину. Важно обеспечить надёжную передачу признаков кадра поскольку от них зависит приём всего кадра данных. Важно наличие lock-индикаторов синхронизаций, оценки качества сигнала и т. п. чтобы не ловить стартовую последовательность, не считать CRC по шумам или плохому сигналу, поскольку гарантировать ничего нельзя.
mdmitry
Посмотрите описание NanoNet на сайте www.nanotron.com Там есть описание пакета для передачи.
ataradov
Я как раз и имел ввиду не класические схемы. Битовый поток уже есть. Зачем нужна стартовая последовательность с хорошей автокорелляционной функцией? Почему не любая последовательность?

Более того, так как происходит выделение битов даже из шума, то вероятность выделения последовательности из 16 нулей маловероятно. Таким образом в данном случае может оказаться выгоднее использовать для обнаружения последовательность 16 нулей и две единицы (для определения действительного начала).

Я вот про такое.
petrov
Цитата(Taradov Alexander @ Oct 12 2007, 11:45) *
Я как раз и имел ввиду не класические схемы. Битовый поток уже есть. Зачем нужна стартовая последовательность с хорошей автокорелляционной функцией? Почему не любая последовательность?

Более того, так как происходит выделение битов даже из шума, то вероятность выделения последовательности из 16 нулей маловероятно. Таким образом в данном случае может оказаться выгоднее использовать для обнаружения последовательность 16 нулей и две единицы (для определения действительного начала).

Я вот про такое.


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

Посчитайте насколько это маловероятно. 16 нулей и 2 еденицы - крайне плохая последовательность. Не в коем случае нельзя чтобы приёмник работал по шумам и плохому сигналу, прецеденты безграмотной разработки бывали когда например произвольно открывались задвижки в газопроводах.
ataradov
Дело вот в чем. Предполагается, что последовательность принята правильно. Следовательно обнаружение будет вестись не по превышению некоторого порога КФ, а по точному совпадению принятой последовательности с опорной.

Приложение не критичное smile.gif
r_dot
Цитата(Taradov Alexander @ Oct 12 2007, 12:48) *
... Приложение не критичное


Во времена "синклеров" и "микрошей" программы хранились на магнитофонных кассетах. Качество этой "среды передачи" где-то сравнимо с радиоканалом. Раз приложение "не критичное", то, наверное, вполне может хватить того формата:

В промежутках и в начале записи гнались "нули" для постоянной битовой синхронизации и вхождения приёмника в режим ожидания начала передачи, в том числе после сбоев приёма (наверное, не трудно гнать их вместо имеющегося "мусора" в паузах). За ними в начале пакета давался байт синхронизации Е6h. По нему же определялось, инвертирован сигнал, или нет. То есть, в ожидании начала пакета приёмник ждал последовательность не менее 64 битов "0", потом, задвигая по биту, байта E6h (или 19h - признак инверсных данных, так как разные магнитофоны могли как не инвертировать, так и инвертировать выходной сигнал).
За байтом синхронизации - два байта длины пакета.
В конце - два байта циклической контрольной суммы.

Ни битов коррекции ошибок, ни даже битов контроля чётности не было.

Думаю, в данном случае вполне можно использовать этот формат. Работал он вполне прилично, программы грузились без ошибок даже с довольно паршивых кассетников.
dac
МОжет и не совсем правильно, но делали так:
При включении передатчика идут несколько байт подряд 0хАА - меандр для синхронизации приемника, затем в течении трех байт передается неактивный уровень - пауза, что бы приемник сбросил "неправильные биты" перед началом нового байта и затем данные, с заголовком, в конце CRC.
Alexandr-spb
Закрылась тема?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.