Futaba S.Bus

[ilyxa]

Боян?

http://goo.gl/fpFj

Ааа нет я этого по крайней мере не смотрел - с неплохими, хоть и поверхностным, пояснением.

Собственно, для вертолета выгоды никакой - мало приводов, обратной связи (судя по всему), кроме id сервы - никакой. Пока не актуально. Пока.

Хотя - сервы теперь "умные" - где-то после 7:40 он рассказывает любопытные вещи.

[morro_lucky]

Новинки уже в каталоге
Да и на Башне обещают в мае-июне продажи стартонуть...

[ilyxa]

А автор темы (или модераторы?) могут переименовать темку в что-то более благообразное - аля "Futaba S.Bus" - фактически, через пару-тройку месяцев обсуждение "попрет" в полный рост, а тут будет как бы все готово

[ilyxa]

http://www.rcmodelreviews.com/futabasbus.shtml

любопытная статейка.

Во первых, затронуты вопросы потребления: три сервы с потреблением по пять ампер, в схеме s.bus  дадут "толстые" кабеля для 15А, что приводит  банальному увеличению сечения и меньшей гибкости прокладки кабелей.

Во вторых, одновендорное решение - стандарт полностью закрыт, JR/Hitec/etc будут изобретать свой ни с чем не совместимый "велосипед" - и не факт, что будут.

В третьих - добавление активных устройств (хабов в терминологии s.bus) добавляет точек отказа в системе сервоприводов отказа.

Кстати, удивительно, что я в свете знакомства с модельными технологиями так и не увидел ассортимента полноценных отказоустойчивых решений - один компонент - одна "нитка" - при стоимости моделей > $2000-3000 такие решения, ИМХО, по идее должны быть актуальны - s.bus не предлагает решения этой проблемы.

[AlexSr]

Да. К стати, по зрелому размышлению, действительно - у этой концепции могут вылезти слабые стороны.
Про питание - понятно. Его всё равно придётся разводить как то - отдельно. Иначе - последовательное соединение питающих шин приведёт к серьёзным проблемам (особенно в "крайнем" устройстве).
Но, тут вылазит ещё вопрос надёжности.
Дело в том, что обрыв провода шины  - приводит к "отрезанию" ВСЕХ устройст на нем висящих далее по цепочке!
Так что, по идее, надо "кольцевать" шину, как минимум (резервирование).
Или, вести сигнальные - звездой, по одному проводу. Но тогда смысл?  

Так что, не всё ещё понятно с "шинной" технологией.

P.S. - Другое дело, что по шине идёт цифровой сигнал. Отсутствуют лишние цифро-аналоговые и аналогово-цифровые преобразования. Это положительно сказывается на точности и стабильности. И быстродействии.

[AlexSr]

На сайте со статейкой попалась на глаза хорошая штучка - [attachimg=#1]

ЮСБ донгл для программы спектр-анализатора диапазона 2.4 ГГц.
Со временем, может стать актуальным  

[ilyxa]

Да. К стати, по зрелому размышлению, действительно - у этой концепции могут вылезти слабые стороны.
Про питание - понятно. Его всё равно придётся разводить как то - отдельно. Иначе - последовательное соединение питающих шин приведёт к серьёзным проблемам (особенно в "крайнем" устройстве).
Но, тут вылазит ещё вопрос надёжности.
Дело в том, что обрыв провода шины  - приводит к "отрезанию" ВСЕХ устройст на нем висящих далее по цепочке!
Так что, по идее, надо "кольцевать" шину, как минимум (резервирование).
Или, вести сигнальные - звездой, по одному проводу. Но тогда смысл?  

Так что, не всё ещё понятно с "шинной" технологией.

P.S. - Другое дело, что по шине идёт цифровой сигнал. Отсутствуют лишние цифро-аналоговые и аналогово-цифровые преобразования. Это положительно сказывается на точности и стабильности. И быстродействии.

Дописал выше соображения

Фактически - звезда и есть, но только шина по огранизации Центр - передатчик, следом - хабы, каждое устройство - оконечник со своим ID. Кольцевать эту шину, ИМХО, не получиться - аналогия Token Ring и Ethernet - разные принципы организации передачи. Кстати, еще вопрос - с точки зрения технологии - кто-то должен в такой топологии выступать инициатором передачи - подразумевается, что это всегда передатчик, который шлет пакет аля для всех, "флудит" в порт s.bus, но со встроенным ID в кадр посылки - а устройство с искомым ID "схватит" свой пакет и обработает должным образом. Минус такой схемы - увеличение количества устройств как раз таки отрицательно скажеться на общей производительности системы, равно как и на ее точности (см. разрешение 2048 для сервоприводов - а достижимо ли оно с большим количеством серв - множество посылок скажуться на точности однозначно).

Плюс пока ни слова про обратную связь. А это сильная вещь.

PS: частично наврал про отсутствие отказоустойчивости - не в том ценовом сегменте смотрел - http://www.rcmarket.org/s-bus-pg-32.html

[ilyxa]

http://www.flightronic.com/index.php?page=futaba-s-bus-protokoll - разобраный фрейм протокола S.Bus... Любопытно.

[ilyxa]

Еще на англицком: http://forums.openpilot.org/topic/1549-receiver-interfaces/page__view__findpost__p__4468