задачка... - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: задачка...

Quoted text here. Click to load it
 
  А кстати, это ещё вопрос, имеется ли механизм обнаружения коллизий.
Касательно к моему предыдущему письму...  


Re: задачка...
  Hi, Nickita!

21 декабря 2006 20:37, Nickita A Startcev писал к Evgeny Kalinin:

 EK>>  А при долгом отсутствии связи с опрашивающим устройством устройства
 EK>> "забывают" свой слот.

 NS> Зачем?
 NS> Может лучше наоборот, хорошо помнить и перенастраиваться только по явной
 NS> команде и/или при наличии коллизий?

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

 И ещё, вопрос к Владиславу: устройства с течением времени меняют своё
местоположение ? Если нет, то можно подумать ещё о назначении слотов по
территориальному принципу (примерно, как назначаются частоты секторам базовых
станций в сотовой связи).

  W.B.R., Evgeny A. Kalinin.


задачка...
                           Пpивет, Evgeny!

*** 22 Dec 06 22:45, Evgeny Kalinin wrote to Nickita A Startcev:

 EK>  И ещё, вопрос к Владиславу: устройства с течением времени меняют своё
 EK> местоположение ? Если нет, то можно подумать ещё о назначении слотов
 EK> по территориальному принципу (примерно, как назначаются частоты
 EK> секторам базовых станций в сотовой связи).

Устройства (абоненты) - не меняют. Hо вот устройство сбора (опрашивающее) -
меняет. Hет, идея жесткого распределения не подходит из-за неудобства
проектирования. А так бы да, я бы просто разнес по слотам по младшему байту
номера или вообще дип-свичом. Hе. Ладно, я еще раз говорю - вопрос с моей
стороны закрыт, вариант с рандомизацией, похоже, единственно приемлемый. И
разработчики UHF RFID придерживаются того же мнения, учитывая применяемый
способ решения той же проблемы.


                                      с уважением Владислав

задачка...
Привет, Vladislav !


 25 Dec 06 , 12:40  Vladislav Baliasov писал к Evgeny Kalinin:

EK>>  И ещё, вопрос к Владиславу: устройства с течением времени меняют
EK>> своё местоположение ? Если нет, то можно подумать ещё о
EK>> назначении слотов по территориальному принципу (примерно, как
EK>> назначаются частоты секторам базовых станций в сотовой связи).

VB> Устройства (абоненты) - не меняют. Hо вот устройство сбора
VB> (опрашивающее) - меняет. Hет, идея жесткого распределения не подходит
VB> из-за неудобства проектирования.

сделать мальнькую коробочку 'адресатор', тыкать этой коробочкой в каждого
клиента после установки на месте. клиент получает свой адрес и пишет его в свой
ЕЕПРОМ.
Чем такое не нравится?


.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... Шагающий авианосец

задачка...
                           Пpивет, Nickita!

*** 28 Dec 06 09:36, Nickita A Startcev wrote to Vladislav Baliasov:

 VB>> Устройства (абоненты) - не меняют. Hо вот устройство сбора
 VB>> (опрашивающее) - меняет. Hет, идея жесткого распределения не
 VB>> подходит из-за неудобства проектирования.

 NS> сделать мальнькую коробочку 'адресатор', тыкать этой коробочкой в
 NS> каждого клиента после установки на месте. клиент получает свой адрес и
 NS> пишет его в свой ЕЕПРОМ. Чем такое не нравится?

Hетехнологично, неудобно. Меня бы и dip-switch не напряг бы, если уж на то
пошло и нужна была бы индивидуальная адресация. Hо планирование такой системы
действительно неудобно. Проще надо быть, проще... Короче, решение принято, всем
спасибо.

                                      с уважением Владислав

задачка...
                           Пpивет, Evgeny!

*** 19 Dec 06 22:35, Evgeny Kalinin wrote to Vladislav Baliasov:

 VB>> которые время от времени надо опрашивать... Как реализовать
 VB>> опрос, и чтобы датчики при этом не забивали друг друга при ответе
 VB>> ?

 EK>  Если система только в проекте, может быть, стоит подумать о частотном
 EK> разделении каналов или/и нескольких трансиверах на опрашивающем
 EK> устройстве, которые работают каждый на своей частоте/частотах ? Или

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

 EK> как-нибудь ещё изощрённее (на опрашивающем устройстве несколько
 EK> каналов, занимающихся определением адресов вновь появляющихся
 EK> устройств и назначением им рабочего канала и слота, и несколько
 EK> рабочих каналов) ?

Это приемлемо лишь для стационарной системы. А у меня мобильное устройство
сбора.

 EK>  Хотя, возможно, при этом могут возникнуть проблемы
 EK> периодически передавать в эфир список свободных слотов; устройства,
 EK> ещё не получившие свой номер слота, передают свой адрес в случайном
 EK> слоте из свободных.

Все оказалось проще. Моделирование показывает, что при 256 тайм-слотах простая
рандомизация позволяет "разрулить" несколько сотен устройств за приемлемое
время (вполне разумное число циклов), предел где-то 1200 - но там уже тяжело.
Hо такое количество единовременно - нереально, изначально я полагал максимум до
30-50 штук за раз, это типично два-три цикла. Конечно, это дольше, чем блок
последовательно взятых номеров, расставленных по младшему байту, но все равно
вполне нормально.
К тому же я потом сообразил, что "засветка" (длинный маркерный сигнал до первой
фазы приема, чтобы периодически опрашивающие эфир датчики обнаружили сей факт)
нужен лишь однократно, потом можно какое-то время всех подержать на активном
приеме и повторный опрос будет занимать около четверти секунды... В UHF RFID
примерно то же самое, так что более продвинутого алгоритма все равно пока не
придумано...


                                      с уважением Владислав

Re: задачка...
Привет, Kirill !


 22 Dec 06 , 17:31  Kirill Frolov писал к Nickita A Startcev:

Quoted text here. Click to load it

KF>   А кстати, это ещё вопрос, имеется ли механизм обнаружения коллизий.
KF> Касательно к моему предыдущему письму...

'хост', который опрашивает 'слейвов' опознавать коллизии не умеет?

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... редкие выходные обходятся без падения какого-нибудь регионального хаба

Re: задачка...

Quoted text here. Click to load it

  Честно говоря, не очень вникал в сказанное многими подписчиками.
Но что хочу сказать: разделение по временным слотам (вроде GSM, slotted
ALOHA) имеет смысл использовать вместо обнаружения коллизий, в первую
очеред в том случае, когда *имеется задержка* распространения сигнала.
Думаю, очевидно почему. На расстояниях порядка сотни-другой метров, что
в ethernet, что по радиоканалу фактом задержки сигнала можно пренебречь
и использовать более простой метод, положенный в основу ethernet.
Который даёт к тому же достаточно большой процент полезного
использования канала против некоторых обсуждаемых методов. Ну и нет
никакого выделенного узла управляющего доступом к каналу -- это скорей
плюс.


Re: задачка...
Привет!

"Vladislav Baliasov"

VB>   Сижу, думаю, ничего придумать не могу... Вдруг у кого-нибудь свветлая
мысль
VB> возникнет ?

Светлая мысль есть и даже не одна. У меня была похожая задача. Мимо прибора
учёта едет корзина, в ней некоторое количество предметов с маячками навроде
RFID (до 50 одновременно). Нужно за 1 секунду разобраться, какие именно и
сколько наличествуют. Сорри, протокол уже коммерческая тайна, но подсказать
могу. Посмотри, как на шине ISA протокол PnP реализован. ;-) Задержка
распознавания пропорциональна количеству одновременно присутствующих
предметов, радует, что не квадрат (или иная степень) и не экспонента.

 С уважением,

Виталий Насенник



Site Timeline