Схематехника бортового компьютера модели (WiFi).
Народ! Вот вы все про протоколы, гарантии доставки и прочую виртуальную внутренность wi-fi, а вы не подумали о более приземленных вещах?
Как насчет передатчиков(у самолета-wifi тоже ведь передатчик стоит)? Как с антенной поступите? В wi-fi нет проволочных антенн как у наших RC-аппаратур. wifi пользует:
- всенаправленные антенны(стержни), которые светят довольно сплющенным тором.
- направленные секторные антенны с раствором 65х65 градусов
- узконаправленные антенны(Яги, дип-диш aka тарелки) с раствором до 10-15 градусов.
Ну и какие антенны вы хотите ставить на модель??? Всенаправленную? А как ориентировать будете? Даже если на передатчике пилота будет антенна типа Яги, тор излучения всенаправленной антенны у модели ориентирован своей плоскостью по плоскости крыла, и скажем самолет к нам повернут брюхом(высоту набирает), то хрен чего от модели долетит до вас - вне зоны покрытия пилот будет и все - телемаркет.
Увы, но точечные изотропные всенаправленные антенны еще не придумали.
PS: Или будете вешать на модель дип-диш антенну с интеллектуальным наведением луча на пилота?! 😄
Для передачи информации не обязательно организовывать сокет TCPIP, достаточно использовать более быстрый UDP протокол. Да он не обеспечивает надежности доставки, но это не обеспечивает и сегодняшний РСМ ибо нет обратной связи от модели. Только тест и требования по управлению различными типами моделей будут компетентным ответом.
Вы невнимательно читали нашу переписку с nicetry. TCP для управления моделью не подходит в принципе. UDP подходит, но есть ряд недостатков. В частности, nicetry пишет, на примере протокола VoIP (который, естественно, работает по UDP), что голос передаваемый по wifi “запинается”. Почему это происходит и как этого избежать - мы тут долго обсуждали. Возможно, выход в использовании режима передачи потоковых данных. Но это на более низком уровне, чем IP.
Если просто тупо использовать IP, то скорость, скорее всего, будет недостаточна для летающих моделей. В IP еще ко всему - просто чудовищная избыточность. 5 dword’ов только IP хедер, еще два дворда UDP-lite хедер… Не считая прочих накладных расходов. Да весь пакет PCM1024 укладывается только в заголовки одного UDP пакета. 😃 Для управления глобальность всемирная не нужна. Предлагаю спуститься на уровень ниже.
Конечно, пропускная способность канала выше, но чем меньше пакет, тем выше вероятность, что он проскочит без ошибок.
Кстати, IP адреса модели и передатчики будут по DHCP получать? 😃
Думаю, что с одной стороны все ждут появления двух сторонней телеметрической аппаратуры, но в тоже время ее технология несколько наукоемка и не общедоступна.
Боюсь вас огорчить, но вообще-то вся эта двусторонняя телеметрия нафиг не нужна. Ну не то чтобы это было совсем неинтересно, но никакого “прорыва” реально это не дает. Я вот даже не знаю какая телеметрия мне нужна на вертолет… Даже если помечтать и представить что все возможно, любые датчики, камера, звук… Да никакая, я и на передатчик-то в полете не смотрю, как и подавляющее большинство пилотов.
Гораздо интереснее другое свойство wifi – возможность совместной работы большого количества устройств без создания помех друг другу.
Даже дома распаять чип на 208 ножек позволит себе не каждый.
Это надуманная проблема. Китайцы все могут, однако что-то не особо паяют. Видимо это просто дорого, по традиционной технологии дешевле и больше прибыль.
однако он не станет лучше FUTABA 14 если несколько десятков горячих голов не напишут софт на все случаи жизни моделистов.
Это утопия. Такое “если” никогда не случится. Надо начинать с малого:передатчик с двумя ручками (4 канала) и приемник. Если это все будет работать достаточно хорошо и быстро, то будет смысл писать какой-то более интелектуальный софт.
ps: Кстати, прочитал вашу стратегию… В общем, интересно, но пример с гувернером не очень удачен. Потому что это не просто датчик и и какая-то примитивная программка, у него внутри довольно сложный специфический софт. Вы бы еще пример с гироскопом привели: цепляем к шине датчик, пишем программу и пожалуйста вам, heading hold и все дела. Попробуй, напиши! 😃 Это только в теории все легко и просто, на самом деле это отдельные сложные задачи. Если бы все так было просто - китайцы бы давно наклепали клонов из трех деталей по 5$ за пучок. Heading Hold’у уже сколько лет, а дешевых гиро что-то не очень… Только-только стали появляться, но качество еще оставляет желать лучшего.
Я тоже считаю что интеграция КПК с интерфейсным контроллером весьма простая и оптимальная (цена/качество) конструкция.
Стоило бы сразу чётко расписать функции контроллера и КПК в этой связке. Вы, как я понимаю, планируете реализовать основной функционал пульта на стороне КПК, оставив за контроллером роль передаточного звена “датчики -> КПК” и “КПК -> ВЧ модуль”. Боюсь и здесь вас тоже ждет много засад. Основные из них: совершенная непригодность Windows CE для систем реального времени и (опять же!) заметное усложнение и суженный тракта прохождения команд.
Я бы предложил положиться на другую схему, которую использует ваш излюбленный конкурент в своей аппаратуре 14MZ. Там WinCE-устройство с цветным экранчиком выполнят исключительно роль конфигуратора и хранилища настроек для основного микроконтроллера передатчика, на которого и возлагаются все основные функции.
Стоило бы сразу чётко расписать функции контроллера и КПК в этой связке. Вы, как я понимаю, планируете реализовать основной функционал пульта на стороне КПК, оставив за контроллером роль передаточного звена “датчики -> КПК” и “КПК -> ВЧ модуль”. Боюсь и здесь вас тоже ждет много засад…
Все уже реализовано, но я пока не опубликую информацию для массового повторения. Есть некоторые задумки, которые нужно добавить. В текущей версии передатчика ( www.i158.com/index.php?option=com_content&task=vie… ) все как вам хочется:) Все делает микроконтроллер ATMeaga16. КПК только хранит конфигурацию моделей, предостовляет возможность сделать необходимые настройки модели и т.п. Во время запуска модели КПК только отображает параметры настройки. Цитирую:
"…В первом режиме работы ИК получает от КПК информацию о модели из банка памяти и формирует РРМ сигнал в соответствии с настройками модели и положением ручек управления. РРМ сигнал поступает на вход съемного ВЧ модуля и далее передается на приемник модели.
Во втором режиме схожая ситуация, только ИК формирует РСМ последовательность, добавляются расширенные возможности управления моделью. Часть расчетов происходит на КПК. Используется модифицированный приемник…"
(с) 2005 i158.com
😃
шикарно. осталось только дождаться деталей реализации 😉
Гораздо интереснее другое свойство wifi – возможность совместной работы большого количества устройств без создания помех друг другу.
Не совсем так - на практике рекомендуют таки разносить каналы для разных сетей. В рамках же одной сети при одновременной работе узлов - сильно падает скорость - и думаю не последнюю роль тут играет коррекция ошибок в результате взаимных помех.
Еще про антенны выше сообщение было интересно.
Кроме того - по личному опыту - WiFI кушает довольно много энергии.
Это тоже может быть проблемой.
IMHO узкоспециальный передатчик/приемник с хорошей системой распознавания/компенсации помех - более перспективен.
Удачи!
Андрей
И дешевле 😃
Решения основанные на IP как было сказано не гарантируют временные интервалы доставки IP датаграммы, поэтому из этого вытекают проблемы которые меня вынудили плюнуть на WiFi и иже с ним. Щас делаю дуплексный канал на трансивере Atmel AT86RF211S, скорость у нее маленькая но для реализации радиокомандной линии и линии телеметрии вполне достаточно. 211S - мощный (+16дБм на 433мГц выходная мощность передатчика) вариант 211 без индекса, заявлено 1км прямой видимости. АргусСофт обещает привезти их в текущем квартале. Если хош 2,4 ггц то тоже есть решения, только тогда нада еще один корпус впаивать - антенный переключатель+выходной усилитель передатчика. Тогда с 50 метров можно поять 1км получить на прямой.
Если очень нада высокая скорость до 10мБит/с рекомендую Cipcon CC2400 , 2420 и рядом с ними в модельной линейке - нормальные вроде радиомодемы на несущей 2,4. Сам на них не пробовол - для радиокомандной линии слишком наворочены и маломощны, для передачи видео с борта слабоваты по скорости.
По поводу линукса. У меня до него руки не дошли но есть такая идея - использовать на борту не сам линукс а его производные для встраиваемых систем - ECOS например. В качестве процессора рекомендуют в таких условиях как наши авиамодельные , использовать платформу ARM - ничего страшного и сложного.
По поводу видео с борта в цифровом виде. Нашел микросхемку - видео кодек в каталоге преспективных издели AnalogDevice как называется не помню но заинтересовало что она умеет - берет RGB!!! видеосигнал с камеры , зажимает в jpeg2000 както присобачивает звук тудаже и потоком гонит через цифровой интерфейс. На схемке пункиром был нарисован рядом передатчик! Я еще не разбирался с ней но чует мой спинной мозг что скоро на ноутбуке летать будем. Время блин на все не хватает.
По поводу линукса. У меня до него руки не дошли но есть такая идея - использовать на борту не сам линукс а его производные для встраиваемых систем - ECOS например. В качестве процессора рекомендуют в таких условиях как наши авиамодельные , использовать платформу ARM - ничего страшного и сложного.
Боюсь Вы плохо представляет что такое линукс и с чем его едят - я уже не говорю - про лялик на однокристалках - если Вы можете писать софт для однокристалок от атмела под ляликом- то Вы достаточно богатый человек чтоб не заморачиваться подобной ерундой…
хотя стремление к прекрасному можеть дать освоение оч интересных технологий и соответственно независемость в жизни 😃
ЗЫ: а пакетные можемы - они не сложны - весьма и весьма доступны 😃
Для кого вообще в России выделена частота 433мГц?
Это частота радиолюбителей. Там же кусочек для бесплатный микромощных систем , к примеру сигнализации автомобильные и пейджеры. Диапазон достаточно загажен, в столице, по крайней мере. В провинции - у меня вариометр в этом диапазоне работает - пока никто не мешал.
Рассуждения в теме как то ушли от сущности стандарта 802.11. Стандарт определяет протокол канального, физического уровня. В радиоизернете поверх него добавлены логический и пакетный уровень. Но они к стандарту отнощения не имеют. Если написать свой софт, который будет работать напрямую с физическим уровнем - временнЫх проблем не будет.
Будут другие. Конкретный чип-сет, применяемый в компьютерных картах расчитан на расстояния в десятки метров. На сотнях и километрах он будет плохо работать. Проблема в динамическом диапазоне радиочастотной части модема.
У нас сделали свою радиочастотную часть - работает на дальностях в десятки километров, в пределах прямой видимости. Но это уже совсем другая история - хотя стандарт тот же.
Динамический диапазон как раз и определяет пропускную способность в условиях применения нескольких устройств одновременно. Я не буду вдаваться в теорию, но, к примеру, в CDMA устройства работают совместно в одном диапазоне исключительно в силу управления излучаемой абонентом мощности. Тонкое управление с высокой точностью. Только оно и делает жизнеспособной систему коллективного использования общей полосы частот с невысоким динамическим диапазоном радиомодемной части.
В целом, по отношению к моделизму 802.11 стандарт уже опаздывает. Ему в затылок дышит 802.16 протокол. Сейчас у нас идут работы по созданию под него базовой станции. Чип модема уже есть. Года через два в Москве будет уже опытный район сотового оператора под этот стандарт. Под ним можно будет и летать.
Если, конечно, Чубайс не будет повторять регулярно “Конец света”. 😁
а как обстоят дела с загаженностью 2.4GHz ? мне почему-то кажется, что это наиболее перспективный диапазон.
относительно линукса: не всё так сложно, как кажется. главное - чтобы была сборка ядра под рассматриваемую платформу с нужными нам дровами, остальное будет не сильно отличаться от настольной писишки (тут уж мне поверьте, софт под встраиваемый линукс - это моя текущая работа). И арм от атмела в качестве платформы (скажем AT91RM9200) - был бы прекрасным выбором. Хотя если зацикливаться на вай-вае, то RTL8181 наверно всё-таки подходит больше.
относительно линукса: не всё так сложно, как кажется. главное - чтобы была сборка ядра под рассматриваемую платформу с нужными нам дровами, остальное будет не сильно отличаться от настольной писишки (тут уж мне поверьте, софт под встраиваемый линукс - это моя текущая работа). И арм от атмела в качестве платформы (скажем AT91RM9200) - был бы прекрасным выбором.
ну как тут не понять - что железок по начинке - придется напихать сравнимо с КПК.
Причем использовать КПК (на борту) - это наиболее доступный и дешовый вариант.
кристалы денег стоят ( и нужно много и разных - начиная от флешек - до оперативки итд) писибишку изготовить ( да конечно под смд ) тоже денежка - и хорошая будет - стоимость такого самика будет в 3-4 раза превышать нынешнгие конструкции
Я с ляликом знаком не первый год - и даже если есть опыт девелоперства под встр лялик - могу заявить - что данный проект реализовать с /dev/null даже если ты спец с опытом работы в avr-gcc - задача нетривиальная и дорогая как по времени так и по денежке (я молчу про фактическую разработку железячной платформы)
делать всё с нуля не предлагается. есть куча готовых плат, есть куча готового софта. в самом крайнем случае тот же КПК, ипук 36XX с разбитым экраном с рук стоит 20 баков, водружаете на него familiar - вот вам борт в первом приближении.
PS: Хотя лично мне интеллектуальный борт пока нафиг не нужен, я пишу с мыслями о плате контроллера для передатчика.
делать всё с нуля не предлагается. есть куча готовых плат, есть куча готового софта. в самом крайнем случае тот же КПК, ипук 36XX с разбитым экраном с рук стоит 20 баков, водружаете на него familiar - вот вам борт в первом приближении.
PS: Хотя лично мне интеллектуальный борт пока нафиг не нужен, я пишу с мыслями о плате контроллера для передатчика.
ага и много таких разбитых за 20 бачей КПК (тем более речь не о штучном изделии)? и как ты их инициализирровать то собрался без экрана ? да еше на ипак лялик сажать ? нет можно конечно заурус присобачить - но это уже не та цена 😃 да и лялик там сильно особенный 😃
идем дальше - если на передатчике ви-фи - то и на приемнике ви-фи - а дальше что ты на борте с голым вифи делать будешь ? вот - вот и выплывает - что надо сгондобить отдельный модуль (железо + софт) для борта и тоже для оператора на земле… а теперь приблизительный подсчет такой аппаратуры ? меня вот тоже постоянно мучает зуд сделать машинку на ви-фи - по офису гонять - с экрана моника подглядывать в камеру ( по мотивам красной офисной крысы)… но как только я подумаю во сколько мне встанет начинка для для такой машинки - все желание сразу отпадает. Можно купить оч дешево бук старый - и на нем все организовать - там писать софт вообще красота - но тогда машинка дюже большой получается - и уже неинтересно.
ипаков таких много, когда понадобилось - нашел парочку без проблем.
про “лялик на ипаке” вы, я вижу, мало что знаете (хотябы потому что упорно называете эту ОС ляликом. серьезные, разбирающиеся люди так не делают) спросите “как сделать” - расскажу, а попусту спорить с вами не стану.
IPAQ на борт, хоть разбитый хоть какой, конечно, не нужен. С точкой доступа (или что там, маршрутизатор, за 30$ который) - гораздо интереснее. Для машинки - гонять по дому - годится и IP. Если рулить с компа, то софт передающей части получается очень примитивный. В цикле формировать и отправлять UDP пакет с информацией от джойстика - листинг пол-странички на си.
Для приемной части некоторую сложность представляет генерация PPM для серв. А в частности измерение точных временных интервалов, тут, возможно, потребуется дополнительное устройство.
Для первых опытов - вполне сойдет. Просто для испытаний… Для меня лично основная засада - в подключении железок к точке доступа. Кому-то писать программы сложнее, а с подключением железок - проблем нет.
Здесь написал несколько слов о применении UDP для управления моделями
www.i158.com/index.php?option=com_content&task=blo…
😃
ипаков таких много, когда понадобилось - нашел парочку без проблем.
про “лялик на ипаке” вы, я вижу, мало что знаете (хотябы потому что упорно называете эту ОС ляликом. серьезные, разбирающиеся люди так не делают) спросите “как сделать” - расскажу, а попусту спорить с вами не стану.
Ой простите ламерюку страшного - виндузятника позорного 😃
насколько я знаю - попытки воткнуть ЛЯЛИК ( как хочу так и называю) на ипаки были - но успешными и законченных решений - нет. Тему про КПК и GNU/Linux закрываем - так как офтопик.
Добавлено
IPAQ на борт, хоть разбитый хоть какой, конечно, не нужен. С точкой доступа (или что там, маршрутизатор, за 30$ который) - гораздо интереснее. Для машинки - гонять по дому - годится и IP. Если рулить с компа, то софт передающей части получается очень примитивный. В цикле формировать и отправлять UDP пакет с информацией от джойстика - листинг пол-странички на си.
Для приемной части некоторую сложность представляет генерация PPM для серв. А в частности измерение точных временных интервалов, тут, возможно, потребуется дополнительное устройство.
Для первых опытов - вполне сойдет. Просто для испытаний… Для меня лично основная засада - в подключении железок к точке доступа. Кому-то писать программы сложнее, а с подключением железок - проблем нет.
вот в том то и дело - что одного ви-фи для управления сервами - мало - нужно устройство - даже не устройство - а УСТРОЙСТВО - с ОС на борту и еше раз повторюсь - данный прожект надо расматривать комплексно - от железок до софта включительно
отрезать лишнее от девайса, разведенного на четырех- или более слойной PCB врядли выйдет, DACов у 8181 нет - машинки не подключиш… как ни крути без своей электроники на борту не обойдешся. Вывод ? У меня такой: следует забить на вай-фай и делать что-то более реальное 😉
Здесь написал несколько слов о применении UDP для управления моделями
Для управления нормальной моделью: самолетом, вертолетом, IP подходит плохо. Непонятно, например, как решать вопрос с адрессацией. У вас что, передатчики и модели будут получать IP адреса по DHCP? Кто гарантирует от пересечения по IP адресам? 😃 Если вы хотите использовать широковещательную рассылку, то как модель узнает что это “её” пакет? По обратному адрусу? Как ее настроить перед полетом на этот адрес? Внутри датаграммы сделаете еще один признак? Заголовки IP + UDP занимают минимум 28 байт, плюс еще в пакете идентификация? Зачем, спрашивается, IP?!
Кстати, сколько времени занимает отсылка 10.000 пакетов? Чтобы среднее время подсчитать.