roboforum.ru

Технический форум по робототехнике.

Разработка стандарта передачи данных по радиоканалу (СС2500)

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

frig » 19 сен 2008, 10:48

Ну и почему в нашем случае не реализовать тот же csma/ca? там схема-то прсотейшая..


там и проблем много. коллизии и проблема скрытого узла.

насколько я понимаю, отличий от csma/cd почти нет..


есть. первый предупреждает коллизии - второй определяет. csma/cd в эфире работать не будет.

можно, конечно реализовать, но одинаково лучше юзать готовое. тонкостей много, спецы нужны... они есть?


А вообще, выбрали бы изначально чипы от nordic'а, щаз бы проблем не знали =( Там уже протокол зашит и с определением корректности посылки, и с ретрансмиссиями автоматическими и прочим подобным..


дык еще не все потеряно. ты ссылки, ссылки давай :D

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

hudbrog » 19 сен 2008, 11:05

frig писал(а):
Ну и почему в нашем случае не реализовать тот же csma/ca? там схема-то прсотейшая..

там и проблем много. коллизии и проблема скрытого узла.
насколько я понимаю, отличий от csma/cd почти нет..

есть. первый предупреждает коллизии - второй определяет. csma/cd в эфире работать не будет.

В том-то и дело, что вся эта бодяга для предотвращения коллизий в проводных системах все еще активно развивается только по причине того, что народ хочет выжать из кабелей максимальную пропускную способность. И CSMA/CD - не единственное решение, и, вообще говоря, не самое лучшее. Мало того, оно также допускает коллизии, просто может их определить в момент передачи и сразу прекратить, после чего заснуть на рандомный промежуток времени.
А есть и более правильные системы арбитража, как, например, в token ring, коллизии не могут произойти просто по определению =) Хотя косяков это своих превносит тоже.
А для нас все эти проблемы типа скрытого узла и т.п. - фигня и мелочи жизни. Потому что пропускная способность выше определенной нам не нужна. А еще, основательный вопрос, нужен ли нам multicast и прочее. А приняв такие условия, можно уже разработать вполне конкретные решения. Например, изначально мы общаемся в общем эфире, как только два устройства решают, что им надо установить соединение, они берут, и уходят на другую частоту. Благо тот же СС2500 поддерживает дофига каналов, если мне память не изменяет около 80 (или это не он?.. =(( ), соответственно выбрав один канал как общий, мы получаем возможность одновременной работы кучи пар без коллизий. А для работы по общему каналу вводятся правила наподобие csma/cd - само собой, перед тем как отправлять что-то, мы смотрим, есть ли несущая в эфире. Если есть - ждем рандомный промежуток времени, проверяем еще раз. Причем рандомный промежуток должен быть не менее, чем вполне себе четко рассчитаное значение, требуемое для передачи полного пакета + подтверждения его принятия. Если нет - начинаем передачу. Само собой, есть шанс что передача начнется одновременно. Тогда мы не получаем подтверждения получения этого пакета и опять засыпаем на произвольный промежуток времени перед повтором передачи.
А еще в пакет запихнем CRC вконец.. байта на 2-4, и подтверждение получения будет включать непосредственно и проверку корректности получения, и сразу появица авто-повторы..
Правда, все это будет тормозить основательно, но на общем канале не нужна будет производительность, для этого будут частные.
Есть конечно еще пара мелких косяков, таких как необходимость, работая на частном канале, продолжать иметь представление что происходит на общем.. но это уже решаемые в рабочем порядке мелочи...

дык еще не все потеряно. ты ссылки, ссылки давай :D

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

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

Виталий » 19 сен 2008, 11:19

Ну давайте говорить так, одним контролем коллизий в Wi-Fi не обошлись я думаю. Там куча каналов, поднесущих и прочей специфики которую нам не потянуть.
Я не понимаю, зачем нам разбираться с коллизиями? Разве нет нормальных чипов которые этим занимаются сами? Если есть надо их и использовать.

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

=DeaD= » 19 сен 2008, 11:24

Как вариант - можно сделать на CC2500 недорогой канал, но не сильно надежный - для большинства домашних испытаний и т.п. хватит. Надо работать в тяжелых условиях - вынимаем модули на CC2500 вставляем более дорогие BT или WiFi или еще какие и вперед.

Добавлено спустя 1 минуту 15 секунд:
Главное чтобы можно было в помещении до 5-10 каналов организовывать и всё. На выставках даже наверное хватит первое время, а потом и поменять успеем. Вот только запайка CC2500 на плату это всё портит - менять канал надо будет и платы менять тогда :( или на плате будет простаивать модуль.

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

frig » 19 сен 2008, 11:53

И CSMA/CD - не единственное решение, и, вообще говоря, не самое лучшее.


на проводах уже давно не актуально. по проводам full duplex и никаких проблем с разделяемой средой передачи.

А есть и более правильные системы арбитража, как, например, в token ring, коллизии не могут произойти просто по определению =)


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

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

но и НИЖЕ определенной тоже плохо. а на радио гарантировать скорость нельзя в условиях систем не маркерного доступа.

А еще, основательный вопрос, нужен ли нам multicast и прочее.


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


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

Если есть - ждем рандомный промежуток времени, проверяем еще раз.


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

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

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

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


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


в гугль посылать все горазды.

Добавлено спустя 3 минуты 9 секунд:
Я не понимаю, зачем нам разбираться с коллизиями? Разве нет нормальных чипов которые этим занимаются сами? Если есть надо их и использовать.


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

Вот только запайка CC2500 на плату это всё портит - менять канал надо будет и платы менять тогда :( или на плате будет простаивать модуль.


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

Как вариант - можно сделать на CC2500 недорогой канал, но не сильно надежный - для большинства домашних испытаний и т.п. хватит.


вполне реально. главное точно описать все ограничения, чтобы потом небыло непоняток и проблем.

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

EdGull » 19 сен 2008, 12:04

Как вариант - можно сделать на CC2500 недорогой канал, но не сильно надежный - для большинства домашних испытаний и т.п. хватит.


вполне реально. главное точно описать все ограничения, чтобы потом небыло непоняток и проблем.


золотые слова!!!

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

frig » 19 сен 2008, 12:13

золотые слова!!!


ты лучше скажи золотые слова, что не будешь встраивать это радио на плату. :)

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

hudbrog » 19 сен 2008, 12:16

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

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

EdGull » 19 сен 2008, 12:24

а можно его просто не впаивать...
тогда оно ваще ничего ни денег не электричества не будет потреблять... :wink:

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

frig » 19 сен 2008, 12:26

а можно его просто не впаивать...
тогда оно ваще ничего ни денег не электричества не будет потреблять... :wink:


он будет нещадо жрать место на плате :-) да и площадь платы увеличится, а значит и стоимость.

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

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

hudbrog » 19 сен 2008, 12:27

а по поводу прошлого..
мне бешено лень поднимать пугающие объемы цитирования..
Частот хватит на полсотни пар устройств как пить дать, больше для хобийных роботов нафиг не надо. Определение занята ли частота - какое-то время слушать на тему наличия несущей например, или послать пробный пакетик броадкастовый на этой частот. можно в общем что-нить придумать )

по поводу нордика.. ну вот ссылка, раз лень слово nordic в гугле вбить:
http://www.nordicsemi.com/index.cfm?obj ... lay&pro=94
Там еще и описания протоколов есть разных..

Добавлено спустя 1 минуту 23 секунды:
frig писал(а):
а можно его просто не впаивать...
тогда оно ваще ничего ни денег не электричества не будет потреблять... :wink:


он будет нещадо жрать место на плате :-) да и площадь платы увеличится, а значит и стоимость.

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

А нафига вам столько свободного места на плате? У меня вот на плату 95х95 вместился и arm контроллер, и пачка разъемов под все, и цц2500, и два моста на 30А... и в общем-то свободного места еще осталось достаточно для какой-нить другой фигни..

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

frig » 19 сен 2008, 12:32

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


в принципе верно.

послать пробный пакетик броадкастовый на этой частот.


и вызвать коллизию если частота занята :-)
А нафига вам столько свободного места на плате? У меня вот на плату 95х95 вместился и arm контроллер, и пачка разъемов под все, и цц2500, и два моста на 30А... и в общем-то свободного места еще осталось достаточно для какой-нить другой фигни..


а саму плату можно сделать меньших размеров.

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

=DeaD= » 19 сен 2008, 12:38

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

Поэтому надо предусмотреть возможность миграции с него сразу при покупке робота или при дальнейшем переходе.

В принципе решение EdGull'а вполне укладывается в эту схему. На плате головного контроллера он разводит место под CC2500 и Mega88, продавать можно в принципе как с запаянными - это тем кому надо сначала такой канал, так и с незапаянными (на пару копеек дешевле и вообще поставку таких контроллеров можно потом начать только если народ массово будет уходить с СС2500) - кому всё равно сразу BT надо. Отличие основное отрицательное BT - на нем неясно как делать, чтобы роботы между собой общались без особо жестких заморочек.

PS: Еще остается вопрос с тем сколько места на плате займёт Mega88 + CC2500 + Антенна и насколько это будет плохо что антенна окажется потом при подключении всей периферии под кучей проводов и может быть даже других печатных плат.

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

frig » 19 сен 2008, 12:49

Дайош СС2500 отдельным модулем!

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


это тоже еще надо проверять. это ж все же не тсоп и не светодиод.

Re: Разработка стандарта передачи данных по радиоканалу (СС2500)

hudbrog » 19 сен 2008, 12:52

Блютус - очень непросто и дорого..
Места на плате.. если делать с печатной антенной как у Эда - примерно 50х25, чуть меньше даже... но там можно еще извратиться, и сделать сильно меньше. Если покупать чип-антенны за 40 рублей, то примерно 15х15, может меньше. В зависимости от форм-фактора smd-компонентов используемых )

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

frig, а зачем делать плату меньших размеров? =)


Rambler\'s Top100 Mail.ru counter