[Alt.F4 0]

Здравствуйте.

 

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

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

Может быть кто-нибудь в курсе данного вопроса?

Спасибо.

 

P.S. Как мне видится, то наверное надо повторять передачу каждому узлу с рандомной задержкой или синхронизировать как-то устройства.

[x893 40]

Это называется коллизией и как видится - так и сделано (SimpliciTI). LWMesh не смотрел - не скажу, но думаю, что так же.

[Слесарь 9]

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

 

Помнится, требует прослушки эфира перед передачей даже какой-то эвропейский стандарт по использованию частот 430 МГц для устройств LPD.

[Alt.F4 0]

Слесарь , но может возникнуть ситация, что они одновременно послушают эфир и одновременно решат, что можно передавать.

Кстати, рандомное число не так просто достать (хотя, при наличии АЦП можно оставить болтаться ножку в воздухе дабы наловить помех).

 

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

i*Addr*(время передачи пакета), где i - номер попытки от 1 до 5.

Например, узел с адресом 3 ожидает = 1*3*(время передачи пакета), затем 2*3*(время передачи пакета) и т.д.

[VCucumber 0]

зачем в воздухе, диодик генерит прекрасную rnd-последовательность

 

[Alt.F4 0]

зачем в воздухе, диодик генерит прекрасную rnd-последовательность

А каким образом, или речь о стабилитроне?

[rx3apf 0]

Кстати, рандомное число не так просто достать (хотя, при наличии АЦП можно оставить болтаться ножку в воздухе дабы наловить помех).

Если есть хоть какое-то взаимодействие с пользователем (кнопка) - то просто. Если ADC - можно, конечно и ногу, а можно встроенный опорник (если есть) померять. Но ведь у устройств в реальном эфире есть, наверное, и серийные номера ? Тогда от них "затравку" сделать. Еще можно от прослушивания реального эфира (мусор с дискриминатора, если доступ есть).

 

[VCucumber 0]

или речь о стабилитроне?

или или

http://electroshema.com/data/tom3/355.php

 

 

Если есть хоть какое-то взаимодействие с пользователем (кнопка) - то просто.

а можно ещё crc32 от чего-нибудь считать - для случайного доступа к среде более чем

Изменено 22 февраля, 2016 пользователем Огурцов

[zltigo 1]

Кстати, рандомное число не так просто достать (хотя, при наличии АЦП можно оставить болтаться ножку в воздухе дабы наловить помех).

Поскольку, как Вы и сами написали, есть уникальные адреса, то и рандомная функция получается от генератора псевдослучайной последовательности не просто, а очень просто.

и такого:

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

i*Addr*(время передачи пакета), где i - номер попытки от 1 до 5.

Например, узел с адресом 3 ожидает = 1*3*(время передачи пакета), затем 2*3*(время передачи пакета) и т.д.

изобретать не надо.

[Alt.F4 0]

Поскольку, как Вы и сами написали, есть уникальные адреса, то и рандомная функция получается от генератора псевдослучайной последовательности не просто, а очень просто.

Где-то натыкался, что есть функция расчета рандомного числа из стандартных библиотек, которой надо установить только стартовое значение, Вы это имеете ввиду?

 

изобретать не надо.

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

[zltigo 1]

Где-то натыкался, что есть функция расчета рандомного числа из стандартных библиотек, которой надо установить только стартовое значение, Вы это имеете ввиду?

Генераторов вообще много. В том числе, конечно и стандартный сишный. srand() и rand() для этого годятся полностью.

Вот прямо из старого своего проекта, котрый прямо сейчас переношу на совместимое устройство:

    srand( uid );

и потом по необходимости: 

                // Backoff for a random period specified by the message, then transmit it.
                // The random time-slot is based on the no_slt variable which is simply a
                // power of 2 -1 mask, ie 0,1,3,7,15,31,63,127 for the 8 possible choices
                // added with a random number from 0 to 127
                delay_uhf_ts( (BYTE)( rand() &( (1 << uhf.pkt.bi.no_slt ) - 1 ) ) );

[turnon 1]

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

Меня тоже беспокоит этот вопрос. Вот здесь несколько прояснили, спасибо. Пока лучшее решение - это разделение по времени и наличие на каждом узле RTC.

 

Удивляет то что в SimpliciTI и LWMesh этот вопрос никак не решен, или я не нашел как. Получается сеть реализованая на чистом SimpliciTI - неработоспособна.

 

Кстати тот же (чисто теоретический) вопрос у меня и по проводной сети, как это решается например в Ethernet?

 

Это называется коллизией и как видится - так и сделано (SimpliciTI).

А как сделано? Или никак не сделано?

 

[111 0]

Можно банально сделать разный период прослушивания эфира у разных девайсов.

Тогда вероятность коллизий снизится

 

Снизится она почти до нуля. Имеется в виду повторных коллизий.

(Правда это в том случае, когда устройства просыпаются редко (гораздо реже чем период арбитража среды).

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

 

При этом устройство с меньшим периодом прослушивания получит как бы больший приоритет и поэтому ВСЕГДА будет захватывать среду передачи при разрешении первой же коллизиии и больше времени будет занимать эфир, чем устройство с бОльшим периодом (в случае если процент времени, когда эфир занят, достаточно велик и первичные коллизии возникают часто). Т.е. хотя коллизий (имеется в виду повторных коллизий) не будет, но будет не симметричная по устройствам пропускная способность эфира: устройство с низким приоритетом сможет передавать только тогда, когда эфир не занят устройством с высоким приоритетом. Плюс величин "паузы" (когда устройство готово передавать, но выжидает) будут больше.

 

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

 

При "методе случайного доступа" и большом кол-ве (например 32 и более) устройств вероятность повторных коллизий больше.

 

Правда если устройства просыпаются через достаточно большие периоды (например раз в сутки), то вероятность того, что 2 и более устройств проснуться одновременно (с точностью до максимального времени не занятости среды, после которого устройство начинает передавать) при не занятом эфире мала.

 

Можно ещё сделать sleep timer, который будет "будить" устройства по расписанию. И установить у каждого устройства своё время пробуждения.

Тогда даже первичные коллизии могут возникнуть только при сбое.

 

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

Изменено 19 марта, 2016 пользователем Herz

[Aner 3]

Почитайте как реализовано в GSM (G2, G3, G4 ) стандартах связи вопросы по наложению пакетов, разбору коллизий, помехам, шумам и тд, может и не нужно еще раз "наступать на грабли" ?

 

Или по незнанию, сильно как хочется... .

 

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

[111 0]

Присоединяюсь к совету Aner.

Топикстартер! Почитайте