[zheka 1]

Господа, передаю по радиоканалу данные. За основу взята рация и программный низкочастотный модем, над которым собственно и работаю.

 

Демодулятор измеряет длину импульсов, и раз в один период равный 1/скорость по большинству импульсов определяет что же было - единица или ноль. Синхронизация байта по стартовому биту - 6 нулей.

 

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

 

Для наглядности в терминале это выглядит так:

0123456
0123456
0123456
0123456
0123456
0123456

 

 

Ошибочные байты - полбеды. ИНогда возникает ситуация, когда какой-то шум умудряется попасть под критерии стартового бита и программа начинает весь мусор, который за ним следует распознавать как байт. А модулятор на самом деле в это время ничего не модулирует.Таким образом появляется лишний байт в пакете и происходит десинхронизация.

 

Для наглядности в терминале это выглядит так:

 

 

0123456
0123456
?012345  //? - мусорный байт
6012345
6012345
6012345
6012345

 

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

 

Как же синхронизировать пакеты? МОжно придумать стартовый байт, но вдруг такой же байт попадется внутри пакета?

Как сделать чтобы несмотря на принятый мусорный байт, настоящий байт распознавался бы не как второй, а как первый?

Что посоветуете?

 

 

[GenaSPB 11]

МОжно придумать стартовый байт, но вдруг такой же байт попадется внутри пакета?

Погуглите по словам byte stuffing, octet stuffing - первая же ссылка приведёт Вас на википедию.

Найдите описание протоколов HDLC, PPP - Все эти проблемы уже решали до Вас...

Изменено 22 апреля, 2012 пользователем Genadi Zawidowski

[AHTOXA 18]

Что посоветуете?

Посмотрите протокол wake, просто и со вкусом.

[ReAl 0]

wake, в свою очередь, появился под влиянием SLIP, хотя есть (на мой взгялд — неоправданное) отклонение.

Он же (SLIP) используется в KISS, но для общения с модемом, точнее, TNC.

И вообще на AX.25 посмотрите внимательнее. В эфире, мне кажется, стоит гнать чисто битовый поток с бит-стаффингом, как в том же HDLC, ради ухода от которого в обмене комп<->модем KISS и придумали.

 

p.s. По поводу байт-стаффингов — кроме byte stuffing типа SLIP, при неудачном стечении обстоятельств сильно раздувающего пакет, есть еще Consistent Overhead Byte Stuffing. Только для его реализиции может понадобиться больше ОЗУ, так как надо забегать наперёд. Хотя буфер пакета обычно есть и в нем обычно весь пакет до начала передачи готов.

[zheka 1]

Сделал проще.

Скорость нужна невысокая, а надежность - чем выше, тем лучше.

Поэтому пренебрег избыточностью и сделал так: Первые два байта 0xAA - синхронизирующие. По их получении обнуляется все. Остальные байты чередуются с 0x55. Таким образом, последовательность 0xAA никогда в теле пакета не встретится. А в буфер читаются только четные байты кадра.

 

ПРограмма прорабтала час. ПОка ни одного битого пакета не одобрила и с толку не сбилась.

[AHTOXA 18]

Скорость нужна невысокая, а надежность - чем выше, тем лучше.

Для надёжности ещё контрольная сумма бы не помешала.

[zheka 1]

АНТОХА, во первых она есть, см.выше.

Во вторых, как CRC поможет при рассинхроне? Приемник в этом случае даже CRC не там искать будет.

[eugen_pcad_ru 0]

А режим обучения можно предусмотерть?

Тогда по накопленной статистике всё должно работать ок (до момента выключения).

 

[AHTOXA 18]

АНТОХА, во первых она есть, см.выше.

Во вторых, как CRC поможет при рассинхроне? Приемник в этом случае даже CRC не там искать будет.

CRC не от рассинхрона, а для достоверности. А от рассинхрона вы уже защитились при помощи пилота. Если CRC есть, то всё в порядке.

[=GM= 0]

передаю по радиоканалу данные. За основу взята рация и программный низкочастотный модем, над которым собственно и работаю.

 

Как синхронизировать пакеты? МОжно придумать стартовый байт, но вдруг такой же байт попадется внутри пакета?

Как сделать чтобы несмотря на принятый мусорный байт, настоящий байт распознавался бы не как второй, а как первый?

Что посоветуете?

1) При передаче по радиоканалу следует учитывать физику передачи. В вашей рации есть АРУ, если рация принимает сигнал, АРУ подстраивает усиление, чтобы на выходе был заданный уровень. Если сигнала нет - АРУ вытягивает шумы, чтобы на выходе опять был заданный уровень. Поэтому всякая передача должна начинаться с преамбулы - несколько нулевых байт, чтобы за это время АРУ вышла на заданный уровень.

 

2) Далее обычно передают последовательность 0/1, чтобы выработать битовую синхронизацию, думаю, достаточно будет 0х55, 0х55. Её тоже относят к преамбуле.

 

3) После битовой синхронизации передаётся синхрослово. Длина СС определяется, исходя из двух противоречивых требований - вероятности пропуска переданного пакета и вероятности приёма ложного пакета. Как правило, длина СС кратна длине байта и лежит в диапазоне 8-32, хотя у меня попадались СС длиной в 288 бит. Как правило, автокорреляционная функция СС имеет ярко выраженный пик (как у кода Баркера длины 13, это только пример, поскольку код Баркера несимметричный)

 

4) Непосредственно после синхрослова передаются собственно данные с ЦКС в конце. Вычисленная ЦКС данных совместно с принятой ЦКС обычно даёт 0, что удобно для контроля.

 

5) Принятый пакет считается достоверным, если перед приемом пакета была пауза 1с, было принято синхрослово с заданным числом ошибок, ЦКС совпала.

 

[toweroff 1]

=GM=, очень похоже на Спектрумовскую работу с лентой (да и любого компьютера тех времен - БК, РК и тд)

или это оно и есть? Может тогда ТС есть смысл почитать в сети инфу по этим алгоритмам?

[zheka 1]

Рация посылает CTSS коды. Так что и сама передача начинается через 0.5 сек, и прием данных идет через 0.5 сек после включения передатчика и после обнаружения несущей приемником.

 

По крайней мере на осцилограмме с сигналом все ОК.

Вот только почему-то не получается у меня пинг-понг с пакетами организовать....

ПОковыряюсь еще...

[mdmitry 0]

А может не изобретать своё, а посмотреть как сделаны радиоканалы ZigBee, Nanonet, Wi-FI и другие. Структура пакета описана, можно воспользоваться идеями. =GM= вкратце описал уже.

[zheka 1]

А может не изобретать своё, а посмотреть как сделаны радиоканалы ZigBee, Nanonet, Wi-FI и другие. Структура пакета описана, можно воспользоваться идеями. =GM= вкратце описал уже.

 

А голос? Рация то неспроста взята.

Изменено 23 апреля, 2012 пользователем zheka

[=GM= 0]

=GM=, очень похоже на Спектрумовскую работу с лентой (да и любого компьютера тех времен - БК, РК и тд)

или это оно и есть? Может тогда ТС есть смысл почитать в сети инфу по этим алгоритмам?

Чтобы не изобретать велосипед, есть смысл почитать, что сделали до ТС. Я просто описал стандартный подход для пакетной передачи по радиоканалу. Так сделано, например, в коммерческой системе связи Инмарсат (стандарт А), да и в других, известных мне системах связи, сделано похоже с различными вариациями. Спектрумовцы просто применили подобную технологию к работе с магнитной лентой, ну там, сами понимаете, вместо модема - компаратор, а так, да, похоже.

 

 

А голос? Рация то неспроста взята

Ну голос с цифрой трудно совместить, конечно, и главное трудно отсепарировать на приёме. DTMF не пробовали? Комбинация 0хFE-начало пакета, 0x01, 0x02-десятичные цифры.