roboforum.ru

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

не прокатит. тот кто не заметил - может переключить передатчик вместе со вторым.

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

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

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

а еще можно сделать совсем круто и предусмотреть приоритеты доступа к среде. тот у кого установлен rts длиннее при максимальной загрузке будет иметь выше приоритет.

RTSr длинее, а пауза - короче.
А чего тут предусматривать? Оно само собой не получицца? - отключил в библиотечке рандом - и усе. RTSr будет в значении по умолчании, которое можно и поправить (опять же ручками)

чего-то я не въезжаю.

Наибольший приоритет по доступу к среде когда RTSr длинее, а пауза - короче. Это я в продолжение своего предложения свести воедино твой, Фриг, подход, и подход Бойца. Ты предлагаешь коллизии решать разной длиной RTS, а Боец - разной длиной паузы после RTS. А я предлагаю и тем и другим.

а Боец - разной длиной паузы после RTS.

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

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

длина передачи у 2-х станций должна различаться не менее чем на время переключения+. а сама посылка должна быть не короче чем все то же время переключения.

а, значит я Бойца не понял.
Твой вариант я понял - разумный.

Я чуток поясню. Моим вариантом тут сейчас назвали мой raw-вариант. То есть отправка короткого RTSr пакета и ожидание на приеме в течение того самого времени, которое frig предложил в качестве длины RTSr (случайное, ступенчатое, с приоритетами - все точно так же, только приоритет имеет более короткое время). Если в течение этого времени что-то принято - ждем освобождения канала и заново передаем RTSr. Если нет - значит начинаем передавать дата-пакет. Тогда получится так. Если пакет RTSr один - то все работает как обычно, все принимают передачу и анализируют ее. Если пакетов RTSr налепилось скажем два и оба передававших не заметили коллизии (остальные эту коллизию приняли и замолчали) - то они прождут разное время, тот у кого оно короче - начнет передачу дата-пакета, а второй - начнет принимать этот дата пакет и поймет, что ему передача не удастся. Таким образом реализуется арбитраж в среде. Мне кажется это равносильно передаче RTSr разной длины.

Добавлено спустя 12 минут 32 секунды:
Я тут правда сам щас заметил неудобство. Получается, что станция в режиме ожидания, приняв любой мусор из эфира, должна подождать максимально возможную паузу - на всяк случай, а вдруг это была коллизия. А в варианте frig достаточно подождать простого освобождения канала. Вот это наверное аргумент в пользу переменных длинных RTS.

Сорри - я не пропал, работа над черновиком протокола идет, но медленнее чем ожидалось - ну просто тут в Вене достопримечательности и пиво вкусное . Но как будет что выкладывать - выложу.

Сорри - я не пропал

надеюсь, что так оно и есть

Вене достопримечательности и пиво вкусное

не долго и пропасть.

АП!

boez, ну как там дела? нельзя хоронить такую затею!

Да времени нема вообще, а когда есть - то есть какие-то другие задачи, типа создать семью и обеспечить ее квартирой , в общем почему-то жизнь одними МК и роботами не ограничивается .

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

По протоколу пока был в командировке, нарисовал пару диаграмм и табличек с форматом пакетов, а потом еще раз подумал - и теперь вот сам склоняюсь к мысли, что нафиг не нужен на роботах этот MACAW, как тут в этой теме неоднократно говорилось моими собеседниками . А достаточно вообще простого контроля чистоты канала своим приемником, плюс случайные задержки перед доступом к каналу и Exponential Backoff на коллизиях - коллизии ловить просто переключаясь на прием сразу после передачи. Подтверждения слать на уровне транспортного протокола, который можно аккуратно слямзить с USB Bulk Transfer - там однобитные "серийные номера" пакетов, этого достаточно для контроля успешной передачи.

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

Да времени нема вообще, а когда есть - то есть какие-то другие задачи, типа создать семью и обеспечить ее квартирой , в общем почему-то жизнь одними МК и роботами не ограничивается .

как я тебя понимаю...

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

и в этом тоже.

в общем ждем натхнэння и времени.

Всем привет.
Ну как дела по сабжу: во что вылилось это море разговоров?