Да, я тут посчитал - скорее всего игра не стоит свеч. Или скорость получится очень низкая или процессор нужен будет более мощный.

я действительно не в курсе этих стандартов, обязательно ознакомлюсь. спасибо!


Александр, а насколько низкая скорость будет?
Если можно, расскажите хоть в двух словах как это все реализуется или ткните меня носом где можно про это почитать (желательно бы на русском языке, лучше доходит до меня).

Все-таки мне желательно в данный момент все это запустить на trc102 либо cc1100(на этой микросхеме у меня собрана охранная система, которую я хочу довести до ума).

... собрана охранная система...
Так у вас есть еще усилитель для Tx?

нет, у меня стандартная обвязка у CC1100 из даташита. Дальность мне в принципе сильно большая тут не нужна, однако я ее планирую расширить за счет той самой маршрутизации.
TRC102 меня интересует с точки зрения стоимости, простоты и удобства монтажа.

В данный момент мне все это нужно запустить на TRC102, это первостепенная задача. Просто есть железо, которое нужно запустить.
А все остальные решения это уже развитие дальнейшее этого железа, модернизация.

Сообщение отредактировал Pasha_a13 - Aug 11 2013, 18:07

Основная идея такая (самый простой вариант):
1. заменяем каждый бит на последовательность бит, обладающую АКФ приближающейся к дельта-функции, то-есть АКФ в 0 равна 1 и как можно ближе к нулю во всех остальных точках. Таким свойством обладают коды Баркера и М-последовательности, например. Пример М-последовательности длинны 15: {0, 1, 0, 1, 1, 0, 0, 1, 0, 0, 0, 1, 1, 1, 1}.
2. Заменяем 0 на прямую последовательность, 1 - на инвертированную. Ест вариант использовать две разных последовательности для 0 и 1.
2. На приеме оцифровываем принятый сигнал с частотой дискретизации в несколько раз больше, чем битовая скорость (4-8 раз).
3. Проводим согласованную фильтрацию на оцифрованного сигнала. В качестве коэффициентов фильтра берем исходную М-последовательность развернутую задом на перед.
4. Там где входной сигнал совпадет с последовательностью на выходе фильтра будет пик, знак пика покажет 0 или 1 приняли.
5. Далее из последовательности битов нужно обратно собрать байты.

3 этап вычислительно самый сложный, так как на каждый принятый отсчет для длинны М-последовательности 16 и 4-х отсчетов на бит нужно проделать 4*15=60 операций MAC (умножение + сложение). На самом деле умножать придется на 1 и -1, так что умножать ничего не нужно, но все-равно, даже просто 60 сложений - это уже довольно много для простого МК.

Выигрыш тут происходит из-за увеличения времени передачи бита, игры с М-последовательностями нужны для синхронизации.

Описание довольно корявое, но в целом нужно смотреть в сторону описания М-последовательностей, их АКФ и согласованной фильтрации.

Все это не применимо к TRC102, так как оно не умеет передавать OOK сигнал.

Александр, спасибо за описание!
Тут мне сначала нужно еще довольно неплохо теорию по цифровой обработке и математике подтянуть чтобы понять получше это все. Займусь этим.
Но вообще алгоритм получается довольно непростой. Я правильно понял что использование подобного алгоритма мне даст возможность вычислять LQI а также немного улучшит качественные показатели радиоканала, помогут повысить дальность?
Получается я действительно наверное ничего не выиграю, т.к. придется ставить контроллер явно помощнее, следовательно как минимум цена устройства возрастет.
Но вообще интересно будет разобраться получше с тем алгоритмом что Вы описали, уверен что многое для себя почерпну.



А вообще ведь я изначально делал максимально простой радиоканал , потом решил добавить маршрутизацию-ретрансляцию и пошло-поехало , в итоге я уже и забыл с чего начинал и какая у меня цель была.
Попробую как-то попроще слепить из RSSI+кол-во хопов какое-то подобие LQI, наверное это будет более простое решение для меня.

LQI вычисляется исходя из уровня пиков в отношении к уровню шума, грубо говоря он показывает насколько принятый сигнал отличается от идеального с которым сравнивает фильтр. При желании так можно вычислять средний LQI всех бит, IEEE 802.15.4 радио делают это только для преамбулы, но там и модуляции другие используют.

Да, это скорее всего просто поиграться с математикой, если интересно, на практике проще купить радио немного дороже, но которое все это само сделает в железе.

а сколько градаций у LQI? Я вроде бы помню что Вы где-то писали что 0 и 1. Или это я что-то перепутал....
Просто у меня ж уровень шума средний и так замеряется постоянно когда я в RX, и когда я принимаю пакет, то я ж могу замерить уровень несущей, в итоге вычислить соотношение....а дальше я так понимаю эксперименты и эксперименты чтобы понять насколько минимально уровень несущей должен быть больше уровня шума чтобы получить нормальные условия связи.



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

256 обычно, потом для удобства вычислений они масштабируются в диапазон 0-1.

LQI - это не соотношение уровней, это показатель того сколько отсчетов в принятом сигнале совпали с тем, что мы ожидали, при условии, что совпало достаточно много, чтобы принятый бит был засчитан.

Самый хороший вариант - не измерять уровень шума совсем, а масштабировать входной сигнал (используя АРУ) к уровню -1 -- 1. Тогда абсолютный максимальны уровень пика для прошлого примера будет равен 60 - это произойдет только если все отсчеты совпали идеально, то-есть шума в канале нет вообще, то-есть LQI максимален.

вот теперь я наконец-то наверное понял почему нужна AM модуляция...чтобы мы не уровни несущей меряли а именно информационную наполненность так сказать правильными данными - чтобы мы считали пришедшие импульсы, просчитывали ожидаемое значение и сверяли.
Я правильно понял?


Т.е. получается потом по каким-то критериям считаем устраивает ли нас канал связи или нет и выбираем 0(нет связи) и 1(есть связь).


вот тут сходу не понял алгоритма, надо посидеть обдумать.

Типа того. Любая модуляция подойдет, AM просто проще всего демодулировать.

Фильтр - это шаблон того, что мы ожидаем увидеть, при фильтрации мы двигаем этот шаблон вдоль принятого сигнала и проверяем сколько бит совпало. Если совпало достаточно, то мы считаем бит принятым. Трюк заключается в использовании М-последовательностей, которые дают только один пик, кода совпадение точное и уровень боковых лепестков примерно 1/sqrt(N), где N - длинна последовательности.

Я вот подумал а что если ввести в данные избыточность+увеличить скорость, чтобы даже при условии небольших помех более успешно восстанавливать данные.


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

Нет, это не обязательно целые числа, это могут быть и дроби. Смысл в том, что бы привести LQI к вероятности передачи кадра без потери. А все вероятности в диапазоне от нуля до единицы.

Хранить естественно как float их не обязательно, можно (и даже нужно) как fixed point.

Тоже вариант. Только скорость увеличивать не нужно, если есть возможность.

понял. Спасибо за доходчивые объяснения!
у меня есть вопрос который меня все мучает и на который я не придумал ответа - как быть в ситуации когда например при поиске маршрута маршрут вычисляется, вроде между всеми узлами маршрута качество нормальное, однако через некоторое время, когда собственно бегают пакеты, между узлами возникло временное препятствие(прошел человек, пролетела помеха и т.п.), качество связи временно ухудшилось в результате чего пакеты потерялись. И получается что вроде как и маршрут нормальный и проблемы на его пути периодически возникают. Накапливать статистику по качеству сигналов между узлами?
Ведь та же вероятность при просчете маршрута не учтет этого никак в случае если помеха не побьет биты пакета routeDiscoveryRequest-routeDiscoveryReply.

Повторять передачу и уменьшать счетчик в таблице маршрутизации. Если счетчик достиг нуля, то убирать запись и заново искать маршрут. Если препятствия частые, то есть шанс, что оно будет там при поиске и найдется более хороший маршрут. Других вариантов нет, если не хочется копить статистику и учитывать ее при поиске.