roboforum.ru

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

 

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

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

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

Сообщение frig » 19 сен 2008, 10:48

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


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

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


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

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


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


дык еще не все потеряно. ты ссылки, ссылки давай :D
frig
 
Сообщения: 1640
Зарегистрирован: 12 фев 2007, 12:25
Откуда: Днепр

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.. много кода под него написано. а ссылки то что.. гугль..
У меня в голове опилки и длинные слова меня только огорчают.
Аватара пользователя
hudbrog
 
Сообщения: 1567
Зарегистрирован: 14 май 2008, 15:49
Откуда: Минск
ФИО: Алексей

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

Сообщение Виталий » 19 сен 2008, 11:19

Ну давайте говорить так, одним контролем коллизий в Wi-Fi не обошлись я думаю. Там куча каналов, поднесущих и прочей специфики которую нам не потянуть.
Я не понимаю, зачем нам разбираться с коллизиями? Разве нет нормальных чипов которые этим занимаются сами? Если есть надо их и использовать.
Все новости о моих проектах http://savethebest.ru
Аватара пользователя
Виталий
 
Сообщения: 2114
Зарегистрирован: 08 окт 2004, 16:43
Откуда: St. Petersburg
Skype: quark-bot
ФИО: Клебан Виталий

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

Сообщение =DeaD= » 19 сен 2008, 11:24

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

Добавлено спустя 1 минуту 15 секунд:
Главное чтобы можно было в помещении до 5-10 каналов организовывать и всё. На выставках даже наверное хватит первое время, а потом и поменять успеем. Вот только запайка CC2500 на плату это всё портит - менять канал надо будет и платы менять тогда :( или на плате будет простаивать модуль.
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24053
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: Pascal / C++ / PHP / 1C
ФИО: Антон Ботов

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

Сообщение frig » 19 сен 2008, 11:53

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


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

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


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

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

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

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


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


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

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


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

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

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

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


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


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

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


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

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


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

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


вполне реально. главное точно описать все ограничения, чтобы потом небыло непоняток и проблем.
frig
 
Сообщения: 1640
Зарегистрирован: 12 фев 2007, 12:25
Откуда: Днепр

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

Сообщение EdGull » 19 сен 2008, 12:04

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


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


золотые слова!!!
Аватара пользователя
EdGull
 
Сообщения: 10211
Зарегистрирован: 28 дек 2004, 20:33
Откуда: Тольятти
Skype: Ed_Gull
прог. языки: Bascom AVR Basic
ФИО: Гуль Эдуард Викторович

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

Сообщение frig » 19 сен 2008, 12:13

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


ты лучше скажи золотые слова, что не будешь встраивать это радио на плату. :)
frig
 
Сообщения: 1640
Зарегистрирован: 12 фев 2007, 12:25
Откуда: Днепр

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

Сообщение hudbrog » 19 сен 2008, 12:16

Да что вам оно сдалось-то так, чтоб его впаяно не было...
Сами говорите, что готовы платить лишние 300 рублей за отдельный модуль.. а чип, стоимостью всего в 100 рублей, пусть будет впаян.. есть-пить он не просит, живет там себе и живет, в режиме сна даже электричества потребляет меньше микроампера.
У меня в голове опилки и длинные слова меня только огорчают.
Аватара пользователя
hudbrog
 
Сообщения: 1567
Зарегистрирован: 14 май 2008, 15:49
Откуда: Минск
ФИО: Алексей

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

Сообщение EdGull » 19 сен 2008, 12:24

а можно его просто не впаивать...
тогда оно ваще ничего ни денег не электричества не будет потреблять... :wink:
Аватара пользователя
EdGull
 
Сообщения: 10211
Зарегистрирован: 28 дек 2004, 20:33
Откуда: Тольятти
Skype: Ed_Gull
прог. языки: Bascom AVR Basic
ФИО: Гуль Эдуард Викторович

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

Сообщение frig » 19 сен 2008, 12:26

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


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

откуда такая принципиальная позиция относительно расположения этого модуля на плате?
frig
 
Сообщения: 1640
Зарегистрирован: 12 фев 2007, 12:25
Откуда: Днепр

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А... и в общем-то свободного места еще осталось достаточно для какой-нить другой фигни..
У меня в голове опилки и длинные слова меня только огорчают.
Аватара пользователя
hudbrog
 
Сообщения: 1567
Зарегистрирован: 14 май 2008, 15:49
Откуда: Минск
ФИО: Алексей

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

Сообщение frig » 19 сен 2008, 12:32

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


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

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


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


а саму плату можно сделать меньших размеров.
frig
 
Сообщения: 1640
Зарегистрирован: 12 фев 2007, 12:25
Откуда: Днепр

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

Сообщение =DeaD= » 19 сен 2008, 12:38

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

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

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

PS: Еще остается вопрос с тем сколько места на плате займёт Mega88 + CC2500 + Антенна и насколько это будет плохо что антенна окажется потом при подключении всей периферии под кучей проводов и может быть даже других печатных плат.
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24053
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: Pascal / C++ / PHP / 1C
ФИО: Антон Ботов

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

Сообщение frig » 19 сен 2008, 12:49

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

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


это тоже еще надо проверять. это ж все же не тсоп и не светодиод.
frig
 
Сообщения: 1640
Зарегистрирован: 12 фев 2007, 12:25
Откуда: Днепр

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

Сообщение hudbrog » 19 сен 2008, 12:52

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

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

frig, а зачем делать плату меньших размеров? =)
У меня в голове опилки и длинные слова меня только огорчают.
Аватара пользователя
hudbrog
 
Сообщения: 1567
Зарегистрирован: 14 май 2008, 15:49
Откуда: Минск
ФИО: Алексей

Пред.След.

Вернуться в Коммуникации

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

Mail.ru counter