Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Потеря битов при приеме. Должно так быть?
Форум разработчиков электроники ELECTRONIX.ru > Аналоговая и цифровая техника, прикладная электроника > Rf & Microwave Design
bukvy
Привет всем. Собрал на СС1020 и MSP430 пару трансиверов. Скорость передачи в радиоканале 4800, Манчестер код. После передачи 5-10 байт, один бит теряется. Посылаю данные без всякого специфического протокола - пилот тон, слово синхронизации и далее по 8 бит подряд. После передачи 5-8 байт один бит теряется, информация искажается. Так должно быть ? Или Манчестер код должен держать синхронизацию постоянно? Если кто передавал большие пакеты, поделитесь информацией. Хотя бы принципами передачи данных по радио. Пожалуйста.
deemon
Манчестер должен держать синхронизацию постоянно . Так что это у вас какой-то глюк ..... может быть , глюк трансиверов .
bukvy
Цитата(deemon @ Oct 23 2007, 12:31) *
Манчестер должен держать синхронизацию постоянно . Так что это у вас какой-то глюк ..... может быть , глюк трансиверов .

Спасибо за ответ. Пролопачу вечерком программку - может где-то прерывание не успевает. А вот реально ли использовать сразу UART в СС1020 ( там есть такой режим - сразу передавать UART).
Есть такой опыт?
Энтомолог
Цитата(bukvy @ Oct 23 2007, 12:22) *
Манчестер код должен держать синхронизацию постоянно?



Манчестер "держать" ничего не должен. Использование манчестера при неустойчивом приеме от потери бит никак не спасает. Помехоустойчивость выше, чем у NRZ, но не более того. Если у вас трансиверы расположены на расстоянии 1м и Вы уверены, что в программе глюков нет, рекомендую проверить частоту работы опорных генераторов, возможно она несколько отличается от той которая написана на кварце. Для проверки частоты, включите трансивер на передачу последовательности 0 или 1 и измерьте частоту несущей. Хотя, для начала, можно поступить проще - попробуйте перестроить частоту приема трансивера в небольших пределах и посмотрите, что будет с ошибками.
deemon
Кстати , манчестер хорош уже хотя бы тем , что не требует передавать постоянную составляющую , как при коде NRZ ( правда , ценой расширения полосы ) . А поэтому позволяет применять более простые приёмники . Я наблюдал похожие потери битов в схемах , где после приёмника , который не пропускал постоянную составляющую , стояла схема восстановления ( триггер , работающий по перепадам сигнала ) . Так был сделан , например , однокристальный трансивер Nordic nrf401 . На малых расстояних всё работало , а при удалении от передатчика резко возрастал уровень ошибок , хотя сигнал казался ещё достаточно сильным . При исследовании этого дела и выяснилось , что глюки возникали в этой схеме восстановления постоянной составляющей . Мы тогда вообще отказались от однокристальных решений и я сделал свой радиоканал , который правильно передавал 0 и 1 . А манчестерский код , кроме самосинхронизации , позволяет обойтись без этих штучек ........
Qwertty
Третий день пытаюсь победить чертов чипкон sad.gif Причем модуль не собирал, взял готовый PAN-2350 на cc1020. В регистры пишу/читаю, на этом успехи и закончились. Калибровка ни в какую не идет sad.gif Вроде все делаю как в AN swra067, но результат калибровки так и не появился. Нет ли там еще каких граблей, кроме описанных в Errata Note 04 ?
Qwertty
Цитата(Qwertty @ Oct 26 2007, 14:52) *
Третий день пытаюсь победить чертов чипкон sad.gif Причем модуль не собирал, взял готовый PAN-2350 на cc1020. В регистры пишу/читаю, на этом успехи и закончились. Калибровка ни в какую не идет sad.gif Вроде все делаю как в AN swra067, но результат калибровки так и не появился. Нет ли там еще каких граблей, кроме описанных в Errata Note 04 ?

Отвечу сам себе - грабли не в cc1020, а в RF Studio. Иногда при смене настроек регистры на самом деле не меняются. Это видно если вернуться в Normal из просмотра регистров. sad.gif Я заметил не сразу, но зато когда заметил все стало понятно. Теперь работает smile.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.