Если в пакете CRC вычисляется на основе 6 байтов данных (48 бит), таблица 1 в статье как раз для Вашего случая. Из нее следует, что лучшший полином для длины 48 бит - это 0хC86C (вторая строка в таблице). Для других длин и желаемой степени защиты от ошибок передачи см. репорт по старым и новым полиномам в таблице 3. В тексте статьи найдёте инструкции как ей пользоваться.
Практически во всех современных радиомодулях имеется встроенный движок CRC, автоматически считающий этот полином по данным пакета загруженного в FIFO для передачи и добавляет его автоматом к пакету. То-же самое происходит и при приеме и есть возможность проигнирировать пакет при несовпадении CRC, чтобы МК не отвлекать понапрасну. В некоторых этот движок может быть настроен на разные полиномы из списка, и даже иногда на произвольный.
Открыта удобная площадка с выгодными ценами, поставляющая весь ассортимент продукции, производимой компанией MEAN WELL – от завоевавших популярность и известных на рынке изделий до новинок. MEAN WELL.Market предоставляет гарантийную и сервисную поддержку, удобный подбор продукции, оперативную доставку по России.
На сайте интернет-магазина посетители смогут найти обзоры, интересные статьи о применении, максимальный объем технических сведений.
Если в пакете CRC вычисляется на основе 6 байтов данных (48 бит)...
Интересный вопрос... Выше уже проводили исследования длины пакета. От этого зависит максимальная дальность (важный параметр). Вероятность повреждения длинных пакетов (32...48 бит и т.д.) больше... требуется выше отношение С/Ш. Поэтому в последней схеме сделали передачу вообще одиночными байтами. При этом дальность заметно возросла.
Похоже мы слишком углубились))
Ser60 писал(а):
Практически во всех современных радиомодулях имеется встроенный движок CRC... В некоторых этот движок может быть настроен на разные полиномы из списка, и даже иногда на произвольный.
Да я почитал даташиты от разных производителей. Например популярный радиомодуль (часто используется для радиоуправления) https://yandex.ru/images/search?text=nr ... source=wiz Там предлагают только два полинома на выбор: CRC-8-CCITT 0x07 CRC-16-CCITT 0x1021 Мдя... Выбор не богатый)) Другие тоже предлагают только "популярные" (цитата) полиномы. Похоже "китайцы" не читали Вашу статью))
Единственное что мне не нравится в радиомодулях - низкая чувствительность (если верить даташиту)... Обычная рация имеет заметно больше чувствительность.
Продукция MOSO предназначена в основном для индустриальных приложений, использует инновационные решения на основе более 200 собственных патентов для силовой электроники и соответствует международным стандартам. LED-драйверы MOSO применяются в системах наружного освещения разных отраслей, включая промышленность, сельское хозяйство, транспорт и железную дорогу. В ряде серий реализована возможность дистанционного контроля и программирования работы по заданному сценарию. Разберем решения MOSO
подробнее>>
Ser60
Заголовок сообщения: Re: Радиоуправление. Переходим на МК.
Делать управление на этом модуле (nrf24l01+), работающим на частоте 2.4ггц, неразумно если требуется получить дальность в несколько сотен метров без дополнительных усилителей. Кстати, с последними и LNA+PA дальность на открытой местности увеличивается до пары-тройки километров и более. Чувствительность у 2.4Г модулей естественно ниже чем у низкочастотных; можете сделать лучше на такой частоте и скорости передачи? Но не Вам мне говорить, что чувствительность не единственный параметр, определяющий дальность надёжной передачи данных.
Я-бы делал управление в Sub-1G диапазоне. Например, на Si4467. Если говорить про чувствительность, то она у него -133dBm (0.05 мкв) на малой скорости. Силлабы, похоже, в курсе результатов исследования в статье, хотя-бы потому что выбор полиномов там больше и "рекордный" полином для малых длин сообщений из таблицы 0xC86C поддерживается.
Кстати, у меня студентка успешно занималась в этом семестре радиоуправлением на основе модулей ZETA-915 в диапазоне 915мгц, производимых английской фирмой RF Solutions (очень рекомендую) http://www.rfsolutions.co.uk/acatalog/FM-ZETA-915-Transceiver-module.html Модули эти основаны на силлабовских чипах Si4455, несколько, правда, устаревших, но все ещё актуальных. Если кому интересно, вот (кликабельные) схемы передатчика из её проекта и приёмника TSOPы на приёмном конце используются для автоматического обхода препятствий.
P.S. Только что заметил опечатку в схеме приёмника: он питается от 6в (4хАА батарей).
Делать управление на этом модуле (nrf24l01+), работающим на частоте 2.4ггц, неразумно
Модули (nrf24l01+), работающим на частоте 2.4ггц с усилителями LNA+PA как пишут работают до 1100 метров (максимум 1800 метров) по прямой. Не проверял... http://homes-smart.ru/index.php?option= ... Itemid=183 Мне не нравятся эти частоты. Просто гулял с Wi-Fi... Но по частотам - это уже отдельный вопрос.
Ser60 писал(а):
Но не Вам мне говорить, что чувствительность не единственный параметр, определяющий дальность надёжной передачи данных.
)) Я никому ничего не говорю... и не спорю. Я просто пишу тут все свои мысли, которые приходят в голову )) и делюсь своими надлюдениями. Не более...
Si4467 интересный модуль. Диапазон частот 142–1050 MHz. Я бы вообще выбрал 144...146. )) Но это отдельный вопрос... И мощность ниче так... Si4468 +20 dBm (0,1 Ватт) - пару км. потянет)) Si4467 +13 dBm (0,02 Ватт) - для ближней связи))
Да, согласно даташиту чуйка Si4467 -133dBm (0.05 мкв) при скорости 100 бит. Это важный параметр. Часто бывает что лучше передавать медленно, чем не передавать вообще)))
Надо будет погулять по радиорынку)) А пока есть ещё пару вопросов без ответа... На чём мы остановились... Продолжаем сходить с ума изучать новые технологии.)) Возвращаясь к последней схеме "кораблика"..
"кораблик")) Подведём итоги)) Задача была сделать схему радиоуправления, работающую без ложных срабатываний и на максимальную дальностью. Решили сделать схему с PCM-кодирования. Сам "Принцип PPM-кодирования" везде подробно описан. Поэтому останавливаться подробно не будем. http://www.rcdesign.ru/articles/radio/ppm_pcm
Меня больше интересует сам принцип кодирования и передачи по радиоканалу. Для начала мы взяли простую рацию... подключили к ней МК. Получили то, о чём уже писал выше aen тут viewtopic.php?f=28&t=5884&start=500 Я продолжу за aen... с его позволения)) Получили всё о чём писал aen.
aen писал(а):
ЧМ приемник выдает на выходе ЧМ детектора шум если на вход приемника не поступает никакого сигнала.
Если на вход приемника подать просто несущую без модуляции, т.е. передатчик включен, а на варикапы ничего не подается, то шумы на выходе частотного детектора пропадают.
Постоянная составляющая отсутствует. Поэтому переходные конденсаторы нам больше не страшны)) Получился самый обычный манчестер, точно такой же как в обычном заводском радиомодуле.
Передачу делаем байтами (8бит). Так МК проще считать)) Взяли байт 10101010 бит... Получили манчестер 1010101010101010 бит.
aen писал(а):
Все это справедливо при очень сильном сигнале поступающем на приемник. Если сигнал будет слабый, то на выходе частотного детектора получим наши импульсы команд зашумленные и чем слабее сигнал, то больше будут шумы и может наступить такой случай, что сигнал уже будет невозможно выделить из этих шумов... Выделение из шумов, если такое будет необходимо можно делать и программными методами и аппаратными.. при маленьком расстоянии импульсы будут довольно чистые и не зашумленные...
Выше ещё писали про ложные импульсы... viewtopic.php?p=2644775#p2644775 Мы сделали программными методами... Точно так же как и в заводском радиомодуле - каждый импульс проверяем много раз и считаем. Например в MRF49XA считаем 39 раз (если верить даташиту).
Чем больше выборок, тем лучше)) Ложные импульсы могут быть в начале.. в конце.. посередине... МК это не важно. Важна только общая длительность. Обычная проверка по выборкам. Это всё можно собрать и на какой-нибудь К155ИЕ5. Запускаем счетчик по первому импульсу и считаем сколько выборок в каждом импульсе. На выходе получаем "1" или "0". Так избавляемся от мелких помех и шумов. Обычный простейший цифровой ФНЧ))
Только этого недостаточно для надёжной работы. Потому что если подать на вход шум (выключить передатчик), то на выходе получим случайный набор цифр... 010111010101110011100110010101001... и т.д. Поэтому надо проверить на совпадение. Добавили "фильт манчестера" (я его так назвал). Как я писал выше... Каждому биту соответствует код "1" = |10| или "0" = |01|. Если получили так |11| или так |00|, то пакет поврежден. Например: |01|01|01|01|01|01|01|01| - всё нормально. Если хоть один бит не совпадает... |01|01|00|01|01|01|01|01| - пакет поврежден. На практике количество ошибок (ложных срабатываний) заметно уменьшилось.
Но и этого недостаточно. Ложные команды всёравно проскакивают.. Редко но проскакивают.
aen писал(а):
Не забывайте про помехи и сделайте программно их выявление. Это или передача контрольных сумм или дублирование команды, т.е. например если команда пришла два(три) раза подряд одна и та же, значит она истинна. Если две соседние команды начиная с паузы пришли разные, значит команда ошибочна и она игнорируется.
Сначала сделали два раза подряд после паузы... Оказалось мало)) одна ложная команда на 10.000 правильных. Сделали три раза подряд после паузы... 1.000.000 правильных. Ложных не зафиксировали. )))
Интересный момент.. Количество ложных команд зависит от уровня сигнала. -При сильном все команды проходят без ошибок. Это и понятно))).
-При выключенном передатчике (просто шум) ложных команд нет. Впринципе достаточно и одного повтора. 010111010101110011100110010101001... и т.д. Весь этот мусор отсеивает в основном фильтр манчеста и редкие проскочившие байты отсеиваются про повторе... Впринципе достаточно и одного повтора. Но для надёжности сделали три)))
-При слабом сигнале (определённом уровне) самая тяжёлая ситуация)) Из-за шума импульсы накладываются друг на друга и получаем максимальное число ошибок... Отдельные биты инвертируются... Фильтр манчестера их пропускает. 1001101010101010 При этом один поврот не справляется... 1001101010101010-1001101010101010 - Вероятность такой одновременной инверсии сразу в двух байтах ~1/10.000 ... Так показал тест (тестовая программа): количество переданных байт, количество принятых байт, количество принятых байт с ошибками. Собственно из-за этого и сделали три повтора. 1001101010101010-1001101010101010-1001101010101010 - Вероятность такой одновременной инверсии сразу в трёх байтах менее 1/1.000.000 ..
Нормально. Пойдёт ))) Всё надёжно как в танке )))
Дальше другая проблема. Задача была сделать схему радиоуправления, работающую без ложных срабатываний и на максимальную дальностью. Ну типа с первой задачей справились))
Больше дальность... слабее сигнал. Значит надо выделить сигнал из шумов. А что нам мешает? Много чего)) А то что количество ошибок в пакете пропорционально длине пакета. При передачи длинных пакетов (три повтора после паузы) среднее количество ошибок в пакете больше в три раза)) Т.к. даже одна ошибка в пакете... и выкидываем сразу весь пакет целиком. 1001101010101010-1010101010101010-1010101010101010 А что делать? Значит будем передавать отдельными пакетами... подумали - сделали))) Т.к. байты идут непрерывно в общем потоке, то ничего страшного если часть из них потеряется)) Возьмем из следующего пакета... В каком байте будет ошибка предсказать невозможно... но схематично выглядит так:
Взяли по 1-2-3 байта (как повезёт) ))) из каждого пакета и проверили на совпадение. 1010101010101010-1010101010101010-1010101010101010. Замечательно)) Дальность возросла... точно не мерил, но в 1,5 раза точно.. Теперь передаём при меньшем уровне сигнала (больше шума).
Но теперь вылезла другая проблема... Пакет слишком длинный получился... 1010101010101010-1010101010101010-1010101010101010 - это только одна команда! А всего их в простом кораблике 3 (это минимум) + пауза. Итого нам надо передать: 1010101010101010-1010101010101010-1010101010101010 (1) - 1010101010101010-1010101010101010-1010101010101010 (2) - 1010101010101010-1010101010101010-1010101010101010 (3) - + между ними паузы...
Ужали всё что можно (включая паузу) )) Слишком долго идёт передача. Для кораблика может и пойдёт, но хотелось бы побыстрей.)) Увеличивать скорость передачи мы не можем, т.к. для этого нужно увеличить полосу пропускания приёмника, а это уменьшит чувствительность приёмника и соответственно дальность... Значит надо ужаться))
es131245 писал(а):
Инверсией же приходиться пересылать в 2 раза больше данных...
Да, сначала передавали одним большим пакетом, с инверсией (как в пульте телевизора). 1010101010101010-0101010101010101-1010101010101010. Потом отказались... При повторах смысла нет инвертировать. И трудно передавать отдельными байтами с инверсией...
es131245 писал(а):
почему просто нельзя кинуть данные с битом четности и контрольной суммой. Если приёмник повторит контрольную сумму -всё ок, если нет выслать снова.? Вроде так и делают компы
Да, интернет протокол TCP/IP именно так и делает)) Только там уровень шума намного меньше... )) А у нас... радио.)) Дли пакета TCP/IP... не помню.. 1600 байт (мин<>макс)... Короче длинный)) При скорости интернета 100 МБит/с... повторно выслать не проблема))
Попробуем)) китайцы обычно в заводских радиомодулях используют CRC-8 или СRC-16... Например si4432
Передатчик посчитал... 1010101010101010(1) -1010101010101010 (2) -1010101010101010 (3) и добавил в конец CRC. Отправили всё одним пакетом (без паузы). ... )) 1010101010101010(1) -1010101010101010 (2) -1010101010101010 (3) -1010101010101010 (CRC).
Приёмник посчитал CRC... Должен получиться 0. 1010101010101010(1) + 1010101010101010(2) + 1010101010101010(3) + 1010101010101010 = 0. Всё работает. Нормальненько. )) Впринципе работает. Только опять дальность меньше... одна ошибка... и весь пакет опять выкидываем... )) 1001101010101010(1) -1010101010101010 (2) -1010101010101010 (3) -1010101010101010 (CRC). Надо что-то с этим делать))
Это было вступление)))
Вопрос. это можно как то разбить? Или это бредовая идея? (забыть и не мучаться) Просто я никогда не работал с полиномами и такими алгоритмами... поэтому вопросы могут быть бредовые))
А например китайцы ещё предлагают в даташите Si4467 разбить пакет на 4 блока и посчитать для каждого блока отдельно CRC... А потом можно посчитать CRC для всего пакета...
Silicon Labs - это американская компания, китайцы здесь не при чем. Структура пакета в их радио чипах с несколькими полями и отдельными CRC по ним предназначена для поддержки стандартов разных протоколов связи. Для борьбы с ошибками разработана теория помехоустойчивого кодирования. Для ее эффективного использования следует знать характер ошибок канала. В частности, при симметричных ошибках типа замещения для коррекции единичной ошибки в слове попробуйте вместо CRC код Хемминга или его расширение SECDED. Для коррекции двух ошибок попробуйте код Рида-Маллера, используемый в CD плеерах.
Характер ошибок канала... Ну я же писал... -Передаём байт например 11111111. -Передатчик переводит байт в манчестер 1010101010101010. -При передачи некоторые биты интвертируются из-за шума... -Получаем например 1001101010011010. -В приёмнике из манчетера собираем обратно байт и получаем ошибочные биты 10111011. Их надо вычислить и исправить. Делов то)))
Осталось написать программку... )) Потом проверим.
Ещё интересно про синхронизацию. В заводских радиомодулях для синхронизации используют преамбулу... типа 1010101010101010. И даже сняли осциллограмыы. Видно, что синхронизация нормально работает в шумах...
В даташите мало информации про это. Почему именно так сделали синхронизацию... Я например сделал проще: 1010101010101010111100001010101010101010... ,где 11110000 - синхробайт. Помоему так проще (лучше).
Насчет характера ошибок я имел в виду вероятность одной ошибки в слове, двух ошибок и пр., чтобы понять сколько ошибок должен исправлять код для безошибочной передачи слов с заданной минимальной вероятностью. Возможно, у Вас ошибки типа замещения с равной вероятностью замены 0 на 1 и 1 на 0, но из сообщений выше это неочевидно. Имеются коды и для несимметричного случая. И для ошибок, например, типа вставки/выпадения когда длины отправленного и принятого слов отличаются (похоже, не Ваш случай). Еще не совсем понятно искажаются-ли все биты слова равновероятно, или ошибкам подвержены группы последовательных битов. Для каждого перечисленного типа ошибок в канале (и многих других) имеются свои коды.
Цель преамбулы синхронизировать по времени скорость и временные характеристики передачи битов и их семплирование на приемном конце. Предполагается, что во время синзронизации некоторые биты преамбулы приемник может не распознать или распознать неверно. Длина преамбулы варьируется в настройках и зависит от канала и условий передачи. Обычно задается минимальное количество успешно принятых битов преамбулы для начала приема. При недостижимости этого условия обычно модем радиомодуля гененирует прерывание и далее уже программе решать продолжать-ли прием или ожидать новой посылки преамбулы. К концу передачи преамбулы предполагается, что приемник будет синхронизирован с передатчиком и после нее передается известное обоим синхрослово, успешный прием которого сигнализирует приемнику помещать последующие байты в буфер приема. При неправильном приеме синхрослова также можно затребовать генерацию прерывания. Ваш подход к синхронизации я не понял. Именно, куда вставляется этот синхробайт 11110000: между каждыми двумя принятыми байтами или один раз в промежутке между порциями преамбулы и почему именно такой? В любом случае мне не ясно, что именно Вы хотели улучшить/упростить по сравнению со стандартом начала приема через преамбулу и синхрослово.
Все биты слова искажаются равновероятно, типа замещения с равной вероятностью замены 0 на 1 и 1 на 0. Белый шум.
При слабом сигнала ошибки "равномерно" распределяются по всему пакету: ...1001101010101010111100001010101010011010111100001010100110101010111100001010101010101001... и т.д. ... бесконечно)), где _______ синхрослово. Код должен исправить... одну или две ошибки.. столько, сколько сможет. ))
При очень слабом сигнала ошибки так же "равномерно" распределяются по всему пакету, но их количество возростает: Если ошибок слишком много и исправить не получается: ...1001100101100110111100001001011001011001111100000110100110100101111100001001011001101001... и т.д. ... бесконечно)), где _______ синхрослово. , то приёмник выдаёт сообщение: "превышен максимально допустимый уровень ишибок" и приёмник "выключается" )) Кораблик останавливается и ждёт...
Если появляются ошибки группы последовательных битов, то это говорит о срыве синхронизации: 1010101010101010 > 0101010101010101 ... всё 8 бит ошибочно. В этом случае ждём пока приёмник нормально синхронизируется. Ничего не исправляем. )) Это сложно...
Или это говорит о постоянной помехи в радиоканала: 1010101010101010 > 0110101010101001 ... блок ошибкок в одном байте. Работает "чужой" передатчик. Наложение сигналов... И в этом случае исправлять блоки мы не будем. Это сложно... В этом случае переключаем каналы (если есть воможность). Если не помогает - переключаем диапазон...))
Про преамбулу ясно)) Просто не до конца прочитал даташит. (трудности перевода ). Там всё подробно написано)) И про минимальную/стандартную длину преамбулы 20 бит... и т.д.
Я смотрю в радиомодуле типа RFM69 есть режим "Неограниченный формат пакета". Похоже это мой случай)) Никаких преамбул... сразу непрерывный поток данных с паузой между байтами/пакетами: -синхробайт 11110000 вставляется между каждыми байтами. Не тратим время на преамбулу... Если надо знать частоту и фазу импульсов, то данные берём из общего потока: ...1010101010101010111100001010101010101010111100001010101010101010111100001010101010101010... бесконечно)), где _______ синхрослово.
11110000-почему именно такой? Для синхронизации байтов (начало/конец) в манчестере достаточно ввести простую последовательность, которая отличается от манчестера. В манчестере не может быть три (и более) последовательно 111 или 000. ...1010011001011001111101010101010101011110011001100110011111010101010101010... бесконечно)), где _______ синхрослово.
Минимальную длину 11110000 (синхрослово) я выбрал для: -выравнивания спектра передатчика: 1111+0000=0 ,постоянная составляющая отсутствует, спектр равномерный... -и с учётом шумов: ...1010101010101010101110001010101010101010011100011010101010101010111001001010101010101010... и т.д. ... бесконечно)) , где _______ синхрослово. Работа синхронизации в шумах... Это хотели сделать в перспективе... ))
Итого: должны получить схему работающую в шумах, с исправлением ошибок сообщения и синхрослов: ...10011001101010101011|100010101010011001100111|0001 1010101010100101... и т.д. ... бесконечно, где _______ синхрослово; | | - кадровая синхронизация; 01,10,0,1 - ошибки.
Размер кадра может быть любой (кратный восьми)... и т.д. и т.п. )))
Я смотрю что в заводских радиомодулях кроме CRC больше никаких кодов проверки и исправления ошибок не используют...
Метод кодирования оригинальный, каждый полубайт полезных данных в эфире передается 6ти битовыми словами, в которых 3 еденицы и 3 нуля. Это позволяет избавится от постоянной составляющей в сигнале, а еще кодововое расстояние таких слов 2 и более, поэтому без труда обнаруживается 1 кратная ошибка. Кадровая синхронизация обеспечивается 8ми разрядным словом. Обнаружение сигнала кадровой синхронизации и битовой синхронизации обеспечивается корреляционными алгоритмами...
А вообще хотел своими идеями поделится, нормальных цифровых каналов с ФАПЧ и корреляторами похоже моделисты не применяют, а без этого цифровой канал уступает ППМ, а я запихал это все в атмегу, да еще на СИ, это была большая работа. Хотел делать приемник с подавлением зеркального канала, гетеродин для этого имеет на выходе сигнал в 1.5 больше надобного, чтобы компенсировать потери на фазовращателях, но после полевых испытаний отказался, мне дальности хватает.
Нормального протокола в нете я тоже не обнаружил, максимум манчестер+CRC, но это дубовато.
Поясняю коррелятор - это сдвиговый регистр (в конкретном случае) его содержимое суммируется с весовыми коэффициентами, на выходе получается вроде степени совпадения содержимого коррелятора с эталоном. У меня этих регистров 2, один отличает 1 от 0 и обнаруживает границы между битами (для подстройки цифровой ФАПЧ) 2й обнаруживает начало кадра. При срыве синхронизации или обнаружении ошибок в боле чем 3х каналов, прога переходит в SAVE MODE, сервы в нейтраль, обратно возращается только если примет 7 кадров нормально.
Очень интересно... Да, манчестер+CRC схема немного "дубоватая" ...
ОК, про синхропосылки понял. Кстати, имеются самосинхронизирующиеся коды. Пакетная передача подразумевает конечную длину пакета. Режим непрерывного приема/передачи данных имеется практически во всех известных мне чипах. Однако, зачем непрерывно передавать поток байтов для радиоуправления?
Как правило кодирование с исправление ошибок в радиочипах возлагается на внешний МК, поскольку сделать кодек с возможностью настройки под любой требуемый код в зависимости от свойств канала и длины посылок, практически нереально. Однако, например СС1101 и его производные могут прозвести FEС данных по желанию. Этим не уменьшается число ошибок, просто они перераспределяются по слову и превращаются из групповых в негрупповые.
Так у меня тоже конечная длина пакета... ограничена синхрословом. Отличие от заводских радиомодулей - у меня нет преамбулы. Экономим время на передачу)).
Для радиоуправления нужен постоянный контроль и желательно с постоянной времени задержки передачи. Поэтому буфер FIFO можно отключить и использовать: "прямой режим", который обходит FIFO полностью. В прямом режиме, данные RX запрограммированы напрямую к GPIO и используется микроконтроллером для обработки данных без использования FIFO.(цитата из даташита).
Чтото кодеки получаются сложные)) Под вопросом что лучше: использовать коды с исправлением ошибок (увеличивается длина пакета и соответственно количество ошибок) или проверить CRC и в случае ошибки повторить пересылку... Помоему в идеале: разбить пакет и передать частями... В приёмнике собрать в кучу и проверить CRC всего пакета. Причём переслать не весь пакет а только часть. Интересно.. как определить по CRC какая часть повреждена)) перебрать все части... )) Интересно как это будет в программе)))
Заводской радиомодуль (согласно даташиту) к каждому пакету добавляет преамбулу для синхронизации приёмника:
Пакет 1: 1010101010101010(преамбула)-1010101010101010(синхрослово)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC). ОК. Первый пакет приняли. Передаём второй пакет. И опять всё сначала... И опять пакет начинается с преамбулы: Пакет 2: 1010101010101010(преамбула)-1010101010101010(синхрослово)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC). ОК. И т.д. ... Пакет 3: 1010101010101010(преамбула)-1010101010101010(синхрослово)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC).
Длина преамбулы (согласно даташиту) выбирается из расчёта уровня шума... Для надёжной синхронизации выбирается преамбула более длинная...
Вопрос: А зачем нам каждый раз передавать преамбулу? Для синхронизации приёмника? Так он и так уже синхронизировался)) Поэтому передаём преамбулу только вначале (при начальном включении передатчика). А делее передаём непрерывно только одни пакеты, без преамбулы: 1010101010101010(преамбула)-1010101010101010(синхрослово)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC)-1010101010101010(синхрослово)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC)-1010101010101010(синхрослово)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC).... бесконечно)) Пока включен передатчик.
Преамбула нужна для работы заводского радимодуля (если верить даташиту). А у нас в последней схеме самодельный радиомодуль (типа рация) )). Нам преамбула вообще не нужна. Включаем передатчик и передаём сразу данные: 1010101010101010(1)-1010101010101010 (2) -10101010|10101010 (3)-1010101010101010 (CRC)-1010101010101010(синхрослово)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC)-1010101010101010(синхрослово)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC).... бесконечно)) Пока включен передатчик. Приёмник синхронизируется по первым битам в первом пакете... С какого то момента (даже знаем с какого, это нам показал осциллограф) приёмник оказывается синхронизированным и далее синхронизация поддерживается по следующим битам: данные, синхрослово, CRC, данные, синхрослово, CRC,... Непрерывно передаём только пакеты... Получили непрерывный поток... Никаких преамбул)) Всё.
roman.com писал(а):
Интересно.. как определить по CRC какая часть повреждена
Ser60 писал(а):
Только по общей CRC никак.
А если подумать? ))) Далее... "мысли вслух" : Допустим приняли пакет. Проверили CRC. Оказалось что CRC не равно 0. Допустим произошла ошибка в байте (1). Пакет 1: 1010011010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC). Что делает в таком случае заводской радиомодуль? Да просто выкидывает весь пакет из буфера FIFO:
А мы не будем выкидывать, а сохраним в буфере МК...)) Далее ждём второй пакет. Если на пульте не дёргать джойстики, то следующий пакет будет точно такой же как первый... т.е. все байты в пакете 1 и 2 одинаковые. Но во втором пакете например тоже произошла ошибка. CRC не равно 0. Допустим произошла ошибка в байте (3). Пакет 2: 1010101010101010(1)-1010101010101010 (2) -1010101010100110 (3)-1010101010101010 (CRC).
Далее сравниваем пакеты по байтам методом замещения (или подстановки, как кому больше нравится) ))).
Берём пакет 2 и подставляем отдельные байты из пакета 1 и считаем CRC, пока не получим 0 :
1-Пакет 2:1010011010101010(1) -1010101010101010 (2) -1010101010100110 (3) -1010101010101010 (CRC). CRC не равно 0.
2-Пакет 2: 1010101010101010(1) -1010101010101010 (2) -1010101010100110 (3) -1010101010101010 (CRC). CRC не равно 0.
3-Пакет 2: 1010101010101010(1) -1010101010101010 (2) -1010101010101010 (3) -1010101010101010 (CRC). CRC равно 0. Ура ! ))) Мы определили что в пакете 2 была ошибка в байте (3).
Замечательно)) Метедом подстановки мы собрали из двух пакетов с ошибками один пакет без ошибок))
Наш кораблик может плавать с одиночными ошибками в каждом пакете... Правда требуется в два раза больше времени на передачу пакетов... Ну и ладно)))
Анологично с двойными, тройными ошибками...
Если использовать заводской радиомодуль, то между приёмом пакетов у МК есть куча свободного времени... В последней схеме (рация) тоже есть свободное время.. Вот пусть МК сидит и считает)) Перебирая все возможные варианты, пока CRC будет 0.)) Главное чтобы хоть один байт из каждого пакета был без ошибок... Вот.
Наверное надо добавить... Эти операции можно проводить только в случае если CRC пакета 1 и пакета 2 одинаковые. Тогда можно утверждать (с высокой вероятностью) что пакеты одинаковые... хеш-суммы))) Вообщем как то так)) Поправьте меня.
Преамбула и синхрослово должны быть разные, иначе как определить где кончилась преамбула и началось синхрослово. Если передавать пакеты один за другим непрерывно, то преамбула каждый раз может и не нужна. Но после какого-то времени рассинхронизация все-равно наступит, поскольку строго одинаковых частот не сушествует. Для этого, как я понял, у Вас и передаются вставки из синхрослов. В большинстве приложений передача идет нечастыми пакетами с молчанием на частоте между ними. Т.к. передача может возобновиться в любой момент асинхронно, приемник опять может быть рассинхронизирован с передатчиком, для этого и передается преамбула по-новой.
Цитата:
Преамбула нужна для работы заводского радимодуля
Нет! Ее можно в любой момент запретить передавать путем изменения битов конфигурации. Тоже самое про синхрослово. В силлабовких радио, например, более 150 параметров настройки практически под любую ситуацию.
Цитата:
Что делает в таком случае заводской радиомодуль? Да просто выкидывает весь пакет из буфера FIFO
Опять-же зависит от радио-чипа. На примере силлабовских, имеется возможность автоматически считать и передавать CRC пакета, но не проверять его на приемном конце. В этом случае пакет останется в FIFO для внешней обработки.
Весь смысл помехоустойчивого кодирования - это сократить до минимума избыточность передаваемой информации при соблюдении корректирующих свойств кода. Если имеется возможность, как у Вас, дублировать пакеты без конца, да еще и непрерывным потоком, то никакая теория не нужна.
Цитата:
Поправьте меня
Чего тут поправлять. Как исправить ошибки в приведенном выше сценарии путем замещения байтов я понял. Но существует и масса других ситуаций, не описанных выше. Например в пакетах 1 и 2 произошли ошибки только в их первых байтах из трех. Что будет делать приемник - подбирать первый байт до совпадения контрольной суммы или сдастся сразу? Неверняка можно напридумывать массу других подобных "заплаток". Может в данном конкретном случае и работоспособная система получится.
Преамбула и синхрослово должны быть разные, иначе как определить где кончилась преамбула и началось синхрослово
Да это понятно)) Я схематично обозначил)) На самом деле было там так: 1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC)-1/0(выравниватель)-11110000(синхрослово)-1(стартбит)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC)-1/0(выравниватель)-11110000(синхрослово)-1(стартбит)-1010101010101010(1)-1010101010101010 (2) -1010101010101010 (3)-1010101010101010 (CRC).... бесконечно)) ... Синхрослово - длинная последовательность 11110000 в манчестере... МК так проще найти синхрослово (в шумах) чтобы получить надёжную синхронизацию по синхрослову в шумах. Разбирать все биты - это долго)) Для начала общий принцип...
Вообще синхрослово можно вставлять между байтами или пакетами.. или... Короче так же как и с преамбулой, зависит от уровня шума и допустимой ошибки синхронизации...
Если вставлять синхрослово слишком часто, то увеличивается длина пакета и время передачи...
Если вставлять синхрослово слишком редко, то увеличивается время синхронизации... В случае срыва синхронизации, МК ищет следуещее синхрослово, при этом теряем пакеты...
Ser60 писал(а):
после какого-то времени рассинхронизация все-равно наступит, поскольку строго одинаковых частот не сушествует.
Это мы вкурсе)) Выше уже обсуждали. Собаку съели )). Зависимость частоты тактового генератора TX и RX от напряжения и температуры... Короче поставили кварц и больше не паримся)) Делаем вставки - синхрослово. По нему и синхронизируемся... Можно добавить ФАПЧ битовой синхронизации... По желанию))
Я так понял что заводские модули синхронизируются только по преамбуле... а далее "по инерции" )) Типа как в UART... Пишут: "Согласование скорости передачи битов между передатчиком и приемником должно быть лучше, чем 6,5%."
"Если есть разница в скорости передачи битов между Tx и Rx, то количество смежных битов можно оценить следующим образом: приблизительно 6 последовательных неуравновешенных байт, когда точность Bit Rate составляет 1%, что легко достижимо (кварц 50ppm до 100ppm)."
Как то так))
Ser60 писал(а):
В большинстве приложений передача идет нечастыми пакетами с молчанием на частоте между ними. Т.к. передача может возобновиться в любой момент асинхронно, приемник опять может быть рассинхронизирован с передатчиком, для этого и передается преамбула по-новой.
Ну в радиоуправлении обычно (сколько я видел) идёт непрерывная передача пакетов... Нужен полный контроль над моделью с минимальным временем обновления данных в приёмнике модели... И желательно с постоянной времени обновления данных (время отклика).
Ещё пишут: "преамбулу из 12 битов требуется для синхронизации... битовый поток должен иметь по крайней мере одну форму перехода '0' до '1' или '1' в '0 на каждые 16 бит "
Не понял... так радиомодуль постоянно синхронизируется по битам (битовая синхронизация) или ему каждый раз нужна преамбула??? (трудности перевода) ))).
Ser60 писал(а):
Весь смысл помехоустойчивого кодирования - это сократить до минимума избыточность передаваемой информации при соблюдении корректирующих свойств кода. Если имеется возможность, как у Вас, дублировать пакеты без конца, да еще и непрерывным потоком, то никакая теория не нужна...
Ну ... более плотных кодов чем CRC я пока не видел... Может они и есть.
Вопрос сложный... что лучше: исправлять ошибки (большая избыточность) или выкидывать пакеты с ошибками и принимать дальше))
Ser60 писал(а):
Например в пакетах 1 и 2 произошли ошибки только в их первых байтах из трех. Что будет делать приемник - подбирать первый байт до совпадения контрольной суммы или сдастся сразу? Неверняка можно напридумывать массу других подобных "заплаток". Может в данном конкретном случае и работоспособная система получится.
Метод "заплаток" ))) Хорошее название)) так и запишем))
Ну тут всё по желанию... Если два пакета с ошибками, то можно попытаться их исправить (собрать из двух один)... не получится исправить - ждём третий пакет и повторяем вычисления)) или сразу сдаться...
Вообще теоретически... методом "заплаток" можно локализовать и "залатать" все дыры в пакете...)))
Можно предварительно оцень примерно количество ишибок... сравнить два пакета: Пакет 1: 1001011010101010(1)-1010101010101010 (2) -1010101010100110 (3)-1010101010101010 (CRC). XOR Пакет 2: 1010101010100110(1)-1001101010101010 (2) -1010101010100110 (3)-1010101010101010 (CRC). = 1010011010100110(1)-1001101010101010 (2) -1010101010100110 (3)-1010101010101010 (CRC). Нашли 4 ошибки.. Далее думаем.. будем восстанавливать или ну его нафиг)))
А вообще - это не лекарство от ошибок, а просто типа дополнительная опция.. к пакетам с CRC... ))
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 16
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
)))
