Главная arrow Форум  
11.12.2018 г.
Главная
Проекты
Статьи
Начинающим
Архив новостей
Ссылки
Контакты
Поиск
Файлы
Форум
Карта сайта
Авторизация





Забыли пароль?
Ещё не зарегистрированы? Регистрация
Поддержи наш сайт!
Через WebMoney

 R785211844650
 Z210696637574
 E368177590409

Простые устройстваОтличные товары по превосходным ценамОтличные товары по превосходным ценам
Форум ARV Research
Добро пожаловать, Гость
Пожалуйста Вход или Регистрация.
Забыли пароль?
Концепция, протокол обмена и т.п. (1 просматривает)
_GEN_GOTOBOTTOM Ответить

TOPIC: Концепция, протокол обмена и т.п.

#1316
ARV (Администратор)
Администратор
Постов: 2384
graph
Концепция, протокол обмена и т.п. 10.09.2008 07:29 Репутация: 175  
Давайте обсудим то, что я уже "надумал" (см. прилагаемый файл - 0,4Мб).
Это - общая концепция, протокол обмена, некоторые технические подробности. Думаю, что важность протокола никто не станет оспаривать. Документ не полностью завершен, да и вообще пока никем, кроме меня, серьезно не обдуман... Возможно, есть просчеты.

Содержимое поста отредактировано: ARV, в: 10.09.2008 07:32
Не стыдно не знать, стыдно не учиться
  Для добавления сообщений Вы должны зарегистрироваться или авторизоваться.
#1332
Eugene (Пользователь)
Новичок
Постов: 2
graphgraph
В ответ на: Концепция, протокол обмена и т.п. 12.09.2008 08:43 Репутация: 0  
Здравствуйте!
На первый взгляд в документе явных ошибок нету.
Мои мысли про проверки ошибок: алгоритм формирования контрольной суммы (CRC) можно взять из протокола Ethernet, а про код исправляющий ошибку (ECR) я вообще если честно не слышал.
Возник вопрос по концепции: о процедуре приема пакета, формула расчета времени START: PR*255*t, здесь PR-это имеется в виду приоритет самого ПУ или ВУ, и если ВУ, то как ПУ PR другого ВУ?

Содержимое поста отредактировано: Eugene, в: 12.09.2008 08:46
  Для добавления сообщений Вы должны зарегистрироваться или авторизоваться.
#1334
ARV (Администратор)
Администратор
Постов: 2384
graph
В ответ на: Концепция, протокол обмена и т.п. 12.09.2008 09:08 Репутация: 175  
Разумеется, принимающий пакет не может знать приоритет передающего - он ориентируется только на свой приоритет. то есть СТАРТ определяется так: слушаем тишину в линии, обнаруживаем наличие сигнала - начинаем измерять длительность этого сигнала. если непрерывно сигнал присутствует в течение времени по упомянутой формуле - считаем, что это старт, и начинаем ждать конца этого импульса. когда дождались - ожидаем начала передачи первого бита - время этого ожидания так же должно вычисляться по формуле для передатчика с максимальным приоритетом. если за это время передача не началась - считаем, что был какой-то сбой.

похоже, все-таки есть какой-то баг в протоколе - наверное, СТАРТ и пауза после него должны вычисляться по формуле, ориентированнаой на САМЫЙ НИЗШИЙ приоритет... как считаешь?
Не стыдно не знать, стыдно не учиться
  Для добавления сообщений Вы должны зарегистрироваться или авторизоваться.
#1335
ARV (Администратор)
Администратор
Постов: 2384
graph
В ответ на: Концепция, протокол обмена и т.п. 12.09.2008 09:10 Репутация: 175  
Да, на счет CRC - можно взять что-то и попроще, типа алгоритма для 1-Wire - в сущности, это не проблема. а вот на счет ECR - это, скорее всего, я перемудрил - сложный он довольно-таки, вряд ли разумно его внедрять в устройства...
Не стыдно не знать, стыдно не учиться
  Для добавления сообщений Вы должны зарегистрироваться или авторизоваться.
#1561
Надя (Пользователь)
Новичок
Постов: 24
graphgraph
В ответ на: Концепция, протокол обмена и т.п. 14.12.2008 23:50 Репутация: 0  
ARV писал(а):

похоже, все-таки есть какой-то баг в протоколе - наверное, СТАРТ и пауза после него должны вычисляться по формуле, ориентированнаой на САМЫЙ НИЗШИЙ приоритет... как считаешь?

Мне кажется, что у Вас сейчас все верно написано, если я, конечно, правильно поняла: например, по нажатию кнопки, ВУ начинает прослушивать линию. При этом ВУ с меньшим приоритетом должно слушать линию дольше, чем ВУ с более высоким PR. Но длительность импульса СТАРТ ВУ с более высоким PR должна быть больше, чем у ВУ с более низким PR.

Но,как я понимаю, одного протокола для реализации этой идеи маловато будет... как минимум нужно бы электрическую схему устройств проработать...
Ау, тут есть еще кто нибудь?
  Для добавления сообщений Вы должны зарегистрироваться или авторизоваться.
#2127
Toledo (Пользователь)
Гуру
Постов: 1026
graphgraph
В ответ на: Концепция, протокол обмена и т.п. 23.03.2009 20:34 Репутация: 5  
Я в этом может и мало понимаю но рискну выложить свои умозаключения:
1. Удобнее всего делать шину при минимуме проводников, общий и сигнальный, это позволить просто интегрировать устройства с радио, ИК и тп. соединением.
2. Чтобы не было путаницы кто куда что в данный момент пересылает перед передачей данных устройство "роняет" шину на строго определённое время, другие устройства в этот момент если захотят чтото передать то должны сначала проверить не была ли шина уронена на это определённое время. как только шина освобождается то могут начинать передачу. хотя есть риск что события так совпадут что например чайник и выключатель люстры одновременно уронят шину, хотя вероятность такого события которое должно на 100% совпасть по времени ничтожно мала но всё же надо что то придумать для исключения этого.
3. каждому устройству назначить свой адресномер, и диапазон доступных команд. Если от чайника придёт команда 451845 а принимающее устройство знает что у чайника доступный диапазон команд 450000...451800, то это для принимающего устройства повод задуматся не хотят ли его обмануть
"Главным изобретением человечества до сих пор остается палка, из-под которой оно работает". Стас Янковский
  Для добавления сообщений Вы должны зарегистрироваться или авторизоваться.
#2128
ARV (Администратор)
Администратор
Постов: 2384
graph
В ответ на: Концепция, протокол обмена и т.п. 23.03.2009 20:39 Репутация: 175  
Toledo, прочти концепцию протокола - все твои идеи уже давно обдуманы и предложен протокол для их реализации.
Не стыдно не знать, стыдно не учиться
  Для добавления сообщений Вы должны зарегистрироваться или авторизоваться.
#2129
Toledo (Пользователь)
Гуру
Постов: 1026
graphgraph
В ответ на: Концепция, протокол обмена и т.п. 23.03.2009 20:58 Репутация: 5  
- Мне лично интересно как просто и дешево сделать надёжный приёмопередатчик для сети 220в, а также ту часть схемы которая должна обеспечить этот приёмо-передатчик питанием при этом имея разумный кпд и стоимость.
- Насчёт помех и прочего в сети, если сделать передачу одной команды 10 раз то используя код Рида-Соломона при приёме можно даже при 90% повреждении всех 10 передач восстановить принятую команду.
- А вот зачем использовать пассивные устройства в системе умного дома мне непонятно, по моей логике любое устройство должно иметь возможность ответа, причём используя программное обеспечение в МК встроенного в устройство можно будет контролировать множевство его параметров. пример:
Подаём команду - включить светильник №3 в комнате №2. при этом МК принявший эту команду испольняет запрос, т.е. включает свой светильник и в ответ не просто отсылает команду что светильник включён, но перед отправкой проверяет наличие тока через спираль и отсылает ответ что светильник включён, ток через спираль такой-топрисутствует. для чайника в ответе может содержатся также информация о остаточной температуре воды или её уровне, т.к. пусть даже и дистанционное но включение чайника без воды скорее всего приведёт к не хорошим последствиям .
"Главным изобретением человечества до сих пор остается палка, из-под которой оно работает". Стас Янковский
  Для добавления сообщений Вы должны зарегистрироваться или авторизоваться.
#2130
ARV (Администратор)
Администратор
Постов: 2384
graph
В ответ на: Концепция, протокол обмена и т.п. 23.03.2009 21:58 Репутация: 175  
Toledo писал(а):
- Мне лично интересно как просто и дешево сделать надёжный приёмопередатчик для сети 220в, а также ту часть схемы которая должна обеспечить этот приёмо-передатчик питанием при этом имея разумный кпд и стоимость.мне тоже это интересно задумки есть, но времени проверять/испытывать не хватает...
- Насчёт помех и прочего в сети, если сделать передачу одной команды 10 раз то используя код Рида-Соломона при приёме можно даже при 90% повреждении всех 10 передач восстановить принятую команду.простой повтор - не самый лучший способ... надо думать...- А вот зачем использовать пассивные устройства в системе умного дома мне непонятно, по моей логике любое устройство должно иметь возможность ответа, причём используя программное обеспечение в МК встроенного в устройство можно будет контролировать множевство его параметров. пример:
Подаём команду - включить светильник №3 в комнате №2. при этом МК принявший эту команду испольняет запрос, т.е. включает свой светильник и в ответ не просто отсылает команду что светильник включён, но перед отправкой проверяет наличие тока через спираль и отсылает ответ что светильник включён, ток через спираль такой-топрисутствует. для чайника в ответе может содержатся также информация о остаточной температуре воды или её уровне, т.к. пусть даже и дистанционное но включение чайника без воды скорее всего приведёт к не хорошим последствиям .
все так, но... устройство с интеллектом само не должно включаться, если это опасно (чайник без воды), т.е. подали команду "включить", а в ответ - не выполнено... а почему не выполнено - это мы подаем другие команды и выясняем. мой протокол - это как бы заготовка, довольно низкий уровень... его можно и нужно развивать...

а пассивные устройства - это просто способ удешевить систему...

Содержимое поста отредактировано: ARV, в: 23.03.2009 22:00
Не стыдно не знать, стыдно не учиться
  Для добавления сообщений Вы должны зарегистрироваться или авторизоваться.
_GEN_GOTOTOP Ответить
© Copyright 2007 Best of Joomla, Работает на FireBoardполучить последние сообщения прямо на Ваш рабочий стол