Jump to content

    

Mesh сеть между подвижными объектами.

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

 

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

Edited by Taradov Alexander

Share this post


Link to post
Share on other sites

Добрый день, Александр!

Я немного запутался - подскажите пожалуйста я правильно понял что nwkSeqNum инкрементируется каждым узлом, который:

- либо шлет пакет routeDiscovery, routeReply или routeError,

- либо принял пакет routeDiscovery, routeReply или routeError и ретранслирует его дальше,

- либо посылает подтверждение (ACK),

- либо посылает Data(не ретранслирует а именно посылает, т.е. является инициатором посылки данных)?

 

Номер macSeqNum в свою очередь инкрементируется каждый раз когда что-либо передаем-ретранслируем(ищем маршруты, передаем данные, пересылаем данные и т.п.)?

 

Share this post


Link to post
Share on other sites

Александр, у меня еще вопрос по поводу функции nwkRxRejectDublicate():

1) Когда происходит первая запись в таблицу nwkRxDuplicateRejectionTable? Тогда когда узел принимает первый пакет и вызывается функция nwkRxRejectDublicate?

2) Например у нас пришел пакет с nwkSrc=1, nwkSeq=1.

//Сделали запись в таблицу
      Entry->src = 1;
      Entry->seq = 1;
      Entry->mask = 1;
      Entry->ttl = DUPLICATE_REJECTION_TTL;
//Пришел следующий пакет с nwkSrc=1, nwkSeq=2
//Запись изменилась
      Entry->src = 1;
      Entry->seq = 1;
      Entry->mask = 0b00000011;
//Пришел следующий пакет с nwkSrc=1, nwkSeq=3 
diff=0b00000010;
(entry->mask & (1 << diff)) = (0b00000011&0b00000100)=0;
//Запись изменилась
      Entry->src = 1;
      Entry->seq = 1;
      Entry->mask = 0b00000111;
//Пришел следующий пакет с nwkSrc=1, nwkSeq=4 
diff=0b00000011;
(entry->mask & (1 << diff)) = (0b00000111&0b00000110)=1;
//Пакет не обрабатывается, запись не меняеться
      Entry->src = 1;
      Entry->seq = 1;
      Entry->mask = 0b00000111;
//Пришел следующий пакет с nwkSrc=1, nwkSeq=5 
diff=0b00000100;
(entry->mask & (1 << diff)) = (0b00000111&0b00001000)=0;
//Запись изменилась
      Entry->src = 1;
      Entry->seq = 1;
      Entry->mask = 0b00001111;
//Пришел следующий пакет с nwkSrc=1, nwkSeq=6 
diff=0b00000101;
(entry->mask & (1 << diff)) = (0b00001111&0b00001010)=1;
//Пакет не обрабатывается, запись не меняеться
      Entry->src = 1;
      Entry->seq = 1;
      Entry->mask = 0b00001111;

Почему одни пакеты пропускаются а другие нет?

Edited by Pasha_a13

Share this post


Link to post
Share on other sites
Я немного запутался - подскажите пожалуйста я правильно понял что nwkSeqNum инкрементируется каждым узлом, который:

 

Вы придумываете слишком сложные правила. macSeqNum увеличивается при каждой физической отправке кадра. nwkSeqNum увеличивается только узлом источником кадра, транзитные узлы его не трогают.

 

Все остальное вытекает из этих правил.

 

Происходит разделение на логические уровни. Поиск маршрута происходит уровнем выше, чем все эти увеличения номеров.

 

routeDiscovery отправляется как локальный броадкаст - только узлы в прямой видимости могут его принять. Приняв его, они формируют новый кадр и заново его отправляют. Это не маршрутизация, это именно создание нового кадра, который не имеет ничего общего с прошлым.

 

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

 

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

 

 

Почему одни пакеты пропускаются а другие нет?

У вас ошибка в сдвигах.

 

Если diff=0b00000101, то (1 << diff) = 0b00100000.

 

При сдвиге 1 на сколько угодно в результате будет только 1 единица.

Share this post


Link to post
Share on other sites
У вас ошибка в сдвигах.

 

Если diff=0b00000101, то (1 << diff) = 0b00100000.

 

При сдвиге 1 на сколько угодно в результате будет только 1 единица.

Прошу прощения, я ошибся. Я почему-то посчитал что не 1 сдвигается на определенное число разрядов, а diff сдвигается на один разряд.

Share this post


Link to post
Share on other sites

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

uint8_t diff = (int8_t)entry->seq - header->nwkSeq;

если например entry->seq=2 а header->nwkSeq=5. Итого я так понимаю -3=0xFD.

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

и зачем здесь делается операция унарного минуса а потом приводиться к беззнаковому?

 uint8_t shift = -(int8_t)diff;

Share this post


Link to post
Share on other sites
Зачем сначала преобразуется число в знаковое, потом результат приводится к беззнаковому?
Чтобы отрицательные числа превратились в большие положительные. Иначе "diff < 8" будет верно и для -3, а это не то, что нужно в данном случае. Нужны только положительные сдвиги.

 

и зачем здесь делается операция унарного минуса а потом приводиться к беззнаковому?

 uint8_t shift = -(int8_t)diff;

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

 

Share this post


Link to post
Share on other sites
macSeqNum увеличивается при каждой физической отправке кадра.

nwkSeqNum увеличивается только узлом источником кадра, транзитные узлы его не трогают.

routeDiscovery отправляется как локальный броадкаст - только узлы в прямой видимости могут его принять. Приняв его, они формируют новый кадр и заново его отправляют. Это не маршрутизация, это именно создание нового кадра, который не имеет ничего общего с прошлым.

Александр, спасибо Вам большое за пояснения!!!

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

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

Теперь еще попытаюсь понять как формировать и рассчитывать этот показатель качества пути.

 

Share this post


Link to post
Share on other sites
Теперь еще попытаюсь понять как формировать и рассчитывать этот показатель качества пути.
И тут скорее всего придется много экспериментировать. LQI из IEEE 802.15.4 чипов удобен тем, что показывает насколько легко было принимать кадр и не зависит от RSSI. В вашем же случае только на RSSI опираться опасно, так как внешний шум будет приводить к увеличению RSSI, но ухудшению качества приема. Придется играться еще и длинной маршрута, и возможно, историей связи с конкретными узлами.

 

Share this post


Link to post
Share on other sites
И тут скорее всего придется много экспериментировать. LQI из IEEE 802.15.4 чипов удобен тем, что показывает насколько легко было принимать кадр и не зависит от RSSI. В вашем же случае только на RSSI опираться опасно, так как внешний шум будет приводить к увеличению RSSI, но ухудшению качества приема. Придется играться еще и длинной маршрута, и возможно, историей связи с конкретными узлами.

Нет, внешний шум не приводит к увеличению RSSI. Поскольку измеряют его на сигнале а не на шуме. Зависимость LQI от RSSI есть но она не простая.

Но согласен, что только на RSSI опираться опасно, из за особенностей канала передачи.

 

Share this post


Link to post
Share on other sites
Нет, внешний шум не приводит к увеличению RSSI. Поскольку измеряют его на сигнале а не на шуме.
Какая магия исключает шум во время приема сигнала?

 

Share this post


Link to post
Share on other sites
Какая магия исключает шум во время приема сигнала?

При измерении RSSI измеряется мощность сигнала, а не спектральная плотность мощности шумов в полосе приёма.

Share this post


Link to post
Share on other sites
При измерении RSSI измеряется мощность сигнала, а не спектральная плотность мощности шумов в полосе.
Откуда приемник узнает сигнал это или шум? Если в измеряемой полосе есть шум, то его мощность добавится к мощности сигнала.

 

PS: Ну и от радио зависит метод измерения.

Edited by Taradov Alexander

Share this post


Link to post
Share on other sites

RSSI (Received Signal Strength Indication), слова шум (Noise) как-то не пишут. Для того и приёмники те деланы, чтобы знать где синал, а где шум.

В параметрах приемника задается предельная чувствительность для указанной полосы (как пример -128dBm, для полосы 1KHz) Приемник, для детектирования должен иметь превышение (по разному от вида модуляции) ~ от 3 до 10dB. Определяется RSSI по синхропосылке или позже. Без приема синхры, как правило нет смысла в измерении RSSI. Поробуйте поэкспериментируйте, подав шум на вход приемника, чтение из регистра RSSI даст минимальные значения.

Share this post


Link to post
Share on other sites
RSSI (Received Signal Strength Indication), слова шум (Noise) как-то не пишут. Для того и приёмники те деланы, чтобы знать где синал, а где шум.
Signal тут больше для обозначения всего что принято, так как приемник (да и человек тоже) не может отличить в оцифрованном сигнале что шум, а что нет.

 

RSSI - это не какой-то фиксированный параметр, на просто общий термин. Говорить о том, что именно он означает бессмысленно в отрыве от конкретного радио. К примеру из DS на ATmega256RFR2:

The RSSI is a 5-bit value indicating the receive power in the selected channel in steps

of 3 dB. No attempt is made to distinguish IEEE 802.15.4 signals from others. Only the

received signal strength is evaluated.

Для других радио определение будет другое, но похожее, так как отделить сигнал от шума при измерении мощности физически невозможно.

 

Поробуйте поэкспериментируйте, подав шум на вход приемника, чтение из регистра RSSI даст минимальные значения.
Пробовал много раз на IEEE 802.15.4 - RSSI растет, так как это просто мощность принятого сигнала (в широком смысле, включая шум).

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this