roboforum.ru

Мы с DeaDом на волне успешного поднятия стандарта единой шины для роботов предлагаем обсудить единый стандарт передачи данных по радиоканалу на базе CC2500

Добавлено спустя 3 минуты 26 секунд:
ZigNet.ru пока рабочее название... соответсвенно обсуждаемое...
просто этот домен пока свободен...

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

zigbot.ru кстати тоже свободен...

Добавлено спустя 3 минуты 48 секунд:

frig писал(а):планируется рисовать свой стандарт передачи данных по радиоканалу??
если да, то затея имхо гнилая совсем. взять готовое.

да там тока в готовых типах модуляции черт ногу сломит...

Ну я бы не стал пока говорить про "единый стандарт передачи данных", хотя некоторую концепцию хотелось бы приземлить, если будем пользовать везде CC2500.

Одним из базовых применений модуля вижу беспроводной прозрачный UART - втыкаем в комп модуль, в робота модуль и имеем то же самое, что и конвертер RS-232 <=> TTL-UART.

Обсуждаем пока в этом ключе или шире?

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

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

Одновременно передавать и принимать модуль ведь не может? Надо буфер делать приёмки и передачи. Отправлять если накопилось или если время сколько-то прошло - так?

Добавлено спустя 2 минуты 25 секунд:
Безусловно за основу надо брать что-то уже работающее и на нем делать радио-уарт, если моя затея с ним принимается.

1. естетсвенно что речь идет пока только как о радиоуарте
2. у СС2500 есть свои буферы на прием и передачу.

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

EdGull писал(а):нужно сначала договорится по виду модуляции, скорости передачи и т.д.

Это самое простое. Сделать работающий протокол - задача, а выбрать вид модуляции и скорость - дело десятое. Берем готовые модули, подбираем устраивающие по скрости/проценту ошибок/дальности, и объявляем стандартом.

...а при чем тут зигби? Зигби - это забитое уже имя со своими стандартами.
Назовите как-нить RoboRF - чтоб не вводить в заблуждение людей похожестью названий! Суть то протоколов (зигби и разрабатываемого) разная будет...
А если суть не различна, тогда и выдумывать нефик

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

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


и т.д. и т.п. для того чтобы получить работающее радио - надобно изобрести ну очень большой велосипед. или использовать чье-то готовое.

кстати, если организовать своими силами канальный уровень, то сетевой и транспортный есть в виде tcp/ip под мегу. колько его тогда хорошо бы делать отдельно от радиво собственно, чтобы была возможность использовать другие физический и канальный уровень. хотьбы тот же ик или просто шнурок.

давай-те пока обсудим режим точка-точка

давай-те пока обсудим режим точка-точка

точка-точка должны работать в условиях других таких-же точка-точка рядом?

пока нет.

Как я вижу возможную реализацию:

имеем две функции : rx() и tx() - работающие на уровне байтов, так же как и уарт.

1. tx(). Поступающие данные буферизуются, пока не наберется пакет определенного размера, или с момента поступления последнего байта прошло определенное время. Затем пакет передается по радио.
2. rx(). По приему пакета данных он помещается в буфер. При вызове rx() данные берутся из этого буфера. Если он пуст - вызов блокируется до поступления пакета.

К этому простейшему программному интерфейсу прикручиваем уарт таким образом, чтобы при поступлении байта через уарт он уходил в функцию tx(), а то, что паступает из rx() выплевывается в уарт.

Это все впрочем очевидно.

По вопросу доступа к каналу, адресации и т.п - предлагаю взять за основу вот это : http://focus.tij.co.jp/jp/lit/an/slaa365/slaa365.pdf. Не уверен, как описанная там система справится со сколь-нибудь высокими скоростями, но основные идеи можем думаю использовать оттуда.

К этому простейшему программному интерфейсу прикручиваем уарт таким образом, чтобы при поступлении байта через уарт он уходил в функцию tx(), а то, что паступает из rx() выплевывается в уарт.

а если часть данных проходящих по каналу дропнется? шум, ошибка при передаче... как контролировать что тебе пришло ВСЕ и как контролировать что оно пришло не поврежденным?

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

так же как и уарте