roboforum.ru

[blindman]

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

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

[EdGull]

цель в создании (или адаптации готового) простого в реализации и надежного протокола.

полностью поддерживаю.

[frig]

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

в уарте нет такого количества ошибок.

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

задержки это одно. надо уметь выявить ошибку и передать данные повторно.

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

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

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

[blindman]

А если без общих слов? Конкретные предложения - вот, можно посмотреть это и это, их юзают X и Y и очень довольны.

[Digit]

Повторяю вопрос

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

[frig]

А если без общих слов? Конкретные предложения - вот, можно посмотреть это и это, их юзают X и Y и очень довольны.

вон Digit подсказывает

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

правда от платок эдгулловских прийдется отказаться наверное в случае с БТ.

Добавлено спустя 3 минуты 34 секунды:
радио - оно все паршивое и все со своими заморочками. у кого-то их меньше (тот же БТ), о других просто никто не знает.

можно, конечно, ради спортивного интереса городить свой радиоогород, но проблем в этом деле больше чем решений.

если говорить о точка-точка, то в принципе все решаемо, только много гемора. если говорить о том, что надо расходится в эфире с другими, то тут, пожалуй только TDM даст нормально работать. а всякие CSMA/CA только попортят кровь.

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

[avr123.nm.ru]

ну вот у меня есть XBee модули... и че?

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

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

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

Да зачем вам создавать то ??? СОЗДАН уже давно для cc2500 ! и раздается бесплатно
http://focus.ti.com/docs/prod/folders/print/cc2500.html
SimpliciTI Network Protocol SIMPLICITI
И исходники на Си и пример
eZ430-RF2500 Sensor Monitor Demo
и библиотеки готовые
CC1100 CC1101 CC2500 Examples Libraries

Добавлено спустя 7 минут 25 секунд:
ZigBee проекты контеста 2005 - http://www.jandspromotions.com/wireless ... index.html

Вот один из них: Robot Localization and Control
The well-designed ZigBee-based Robot Localization and Control project uses wireless nodes to simultaneously localize and control the humanoid robot Robosapien by Wow Wee. The ZigBee nodes’ outputs mimic the control signals the robot would normally receive. A user-friendly GUI display makes controlling the robot easy.

[=DeaD=]

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

К простым задачам, которые мы можем сами решить, я отношу:
1. Создание буфера RX, TX;
2. Выявление ошибок в информации при передаче;
3. Коррекция ошибок (если пользуем БЧХ-коды или что-то такое);
3. Повторный запрос, если неможем исправить ошибку.

Какая-то вероятность ошибки при этом конечно останется всё равно. Но её можно сделать практически нулевой, правильно подобрав параметры системы.

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

[frig]

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

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

Очень не хотелось бы влезать в вопросы разделения среды передачи, выбора канала и т.п.

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

где можно будет использовать такой радиоканал?

[=DeaD=]

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

[blindman]

Вроде SimpliciTY кажется очевидным, как решение от производителя чипа, но даст ли оно нам реальные преимущества? Насколько я знаю, подтверждения и повторная передача в случае ошибки там возлагаются на приложение - сам протокол их не реализует

[Digit]

Т.к. Эд сказал:

ZigNet.ru пока рабочее название... соответсвенно обсуждаемое...

а на мое предложение о

Назовите как-нить RoboRF

реакции не поступило, то я поменял тему обсуждения: к Зигби пока обсуждение отношения не имеет.

[=DeaD=]

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

[blindman]

Надо попробовать скомпилировать тогда его под AVR и посмотреть что получится с размером кода. Надо HAL сделать

[frig]

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

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