Схематехника бортового компьютера модели (WiFi).
а какое отношение имеет протокол коррекции ошибок к подтверждению доставки ?
если бы я, к примеру, предлагал пакеты без контрольных сумм слать - ваша аналогия была бы уместна 😃
протокол коррекции ошибок либо исправляет канальные ошибки, либо не пропускает данные, ошибки в которых он исправить не может, а контроль доставки пакетов данных осуществляет всё тот же TCP.
а какое отношение имеет протокол коррекции ошибок к подтверждению доставки ?
Есть целое семейство протоколов (ну например для модемов), которые гарантируют доставку данных, либо определяют были ли доставлены данные. Алгоритм в TCP реализован на слишком общем уровне, чтобы одинаково хорошо работать во всех средах. У телефонной линии своя специфика, у радио - своя. Мы же не специалисты по разработке беспроводных протоколов…
И потом. Например, передается какой-то пакет по WiFi. Ну, скажем, передается он достаточно долго. Возможность сброса текущего пакета и передачи вместо него другого, более нового пакета, определяет используемая железка и драйвер этой железки. Стандарт не запрещает этого делать. Другой вопрос, что и новый пакет вместо него так же не будет долгое время проходить. Но какая тут принципиальная разница с PCM, работающем в режиме активных помех? Да никакой.
Засада с подтверждениями - в другом. Просто протокол точка-точка с подтверждениями работает существенно медленнее, чем без них. И вместо десяти мегабит мы имеем, например, пять. Но в нашем случае скорость и так избыточна.
прям целое семейство протоколов коррекции ошибок для модема, которые ГАРАНТИРУЮТ доставку данных ? заинтриговали! хотелось бы услышать парочку названий, для общего развития 😉
в итоге хотелось бы задать последний вопрос: ну если всё так чудесно и избыточно, как вы говорите, то почему до сих братья-китайцы не штампуют такую аппаратуру вагонами ? идея то далеко не нова, переодически тут такое кому-то в голову приходит.
прям целое семейство протоколов коррекции ошибок для модема, которые ГАРАНТИРУЮТ доставку данных ?
v42bis например. Либо данные доставляются в неизменном виде, либо возникает ошибка типа “разрыв связи”.
Так как это алгоритм сжатия, а словари и частотные таблицы не передаются а накапливаются на каждой стороне независимо, в алгоритме предусмотрена система синхронизации отправленного и принятого потоков. Побочный эффект, можно так сказать, потому, что если какой-то байт из потока выпадет или будет неправильно передан, то все последующие принятые байты будут неправильно распаковываться.
Мы отвлеклись.
в итоге хотелось бы задать последний вопрос: ну если всё так чудесно и избыточно, как вы говорите, то почему до сих братья-китайцы не штампуют такую аппаратуру вагонами ? идея то далеко не нова, переодически тут такое кому-то в голову приходит.
А я не говорю что все чудесно. Возможно, есть какие-то определенные засады, я не знаю. Граблей-то полно… Не знаю, честно. По-этому и проявляю интерес к этому проекту.
Вы предположили, что дело в скорости работы wifi. Я попытался это опровергнуть, может я не прав, может вы неправы. Но сам стандарт 802.11g не так уж плох. Наверное, есть какие-то иные подводные грабли.
У меня сейчас период выбора оптимального решения, которое бы подошло большей части моделистов. Поэтому стараюсь на сайте i158.com отражать происходящую ситуацию так, как она есть и надеюсь как и сейчас получать от вас обратную связь.
Я тоже считаю что интеграция КПК с интерфейсным контроллером весьма простая и оптимальная (цена/качество) конструкция. Уверен она подойдет любителям любых моделей от 2-х метровых самолетиков до мини-комнатных хели. И при развитии проекта разработки софта не уступит FUTABA 14. При встроенной в КПК карточке WiFi или установленной CF или SD карточки WiFi мы получаем дополнительные функции. Первое - двухсторонний обмен данными модель - оператор, второе наземный контроль на клубной площадке за моделистами и их моделями.
Если полностью отказаться от FM режима, то хак AP на базе RTL8181 стандарта 802.11b весьма выгодное дельце. Чип RTL8181 имеет GPIO, которого хватит, для подключения необходимых органов управления пульта. Так же никто не мешает использовать его совместно с КПК. Сказать больше можно подключить графически дисплейчик. На процессоре Lexra интегрированном в RTL8181 можно в DOOM играть, тот же КПК. Стоимость реализации КПК+Интерфейсный контроллер+ВЧ ФМ модуль и КПК+АР почти одинаковая, но во втором случае мы прощаемся с ФМ на всегда.
to toxa:
АР для пульта по размерам подходит без проблем, но не на все модели его можно установить по габаритам и массе. Есть варианты:
- Выбирать для хака платы с модульной разводкой, которые легко могут быть распилины на более мелкие модули. Мне от этого не множко не по себе.
- Можно сделать свой релиз PCB все поместится на 50 кв.см. Тогда отпадет необходимость хака готовых изделий, ибо модули в приемнике и передатчике одинаковы(микрокомпьютер+WiFi).
Linux на девайсе обеспечивает нам по сути половину решения. Скачаете SDK по ссылке в конце статьи на www.i158.com/index.php?option=com_content&task=vie… чтобы посмотреть перечень устройств которые могут быть нами задействованы. Нам по крайней мере не придется повторять подвиг ребят из Ethernut. Linux нам дает среду для программ, стандартные интерфейсы устройств и интерфейсы программирования в одном из стабильнейших, проверенных временем стандартов POSIX.
Тема которую затронул nicetry весьма актуальна. Например в аппаратуре DSM выделяются вполне конкретные ресурсы обеспечивающие надлежащее качество канала связи с моделью. В компьютерных сетях несколько другой подход, но теже функции тоже можно реализовать. Для передачи информации не обязательно организовывать сокет TCPIP, достаточно использовать более быстрый UDP протокол. Да он не обеспечивает надежности доставки, но это не обеспечивает и сегодняшний РСМ ибо нет обратной связи от модели. Только тест и требования по управлению различными типами моделей будут компетентным ответом.
Думаю, что с одной стороны все ждут появления двух сторонней телеметрической аппаратуры, но в тоже время ее технология несколько наукоемка и не общедоступна. Даже дома распаять чип на 208 ножек позволит себе не каждый.
Я стараюсь делать проект не коммерческим, а открытым, это значит что не только все смогут воспользоваться его результатом, но и все могут учавствовать в его развитии. Например проект КПК+Интерфейсный контроллер+ВЧ ФМ модуль по железу не уступит FUTABA 14, однако он не станет лучше FUTABA 14 если несколько десятков горячих голов не напишут софт на все случаи жизни моделистов. Обязательно прочитайте здесь стратегию проекта www.i158.com/index.php?option=com_content&task=vie… . Если вы профессионал в какой то тематике проекта и готовы участвовать в его развитии, то пишите на tech@i158.com . На главной страничке i158.com размещен опрос, пожалуйста проголосуйте 😃
Ну, скажем тот же Hitec уже запустил в продажу 2.4Ггц 80-ти канальный модуль. причем помехозащищенность подобных систем, мне думается, строится на передаче данных сразу на нескольких (как правило 8) каналах…
Подтверждения приема пакета скорее всего нет, а вот скнирование эфира при включении и передача о частотах наиболее “чистых” каналов в приемник вполне могут иметь место…
Но это пока просто просто предположения, точно я пока не выяснял.
Народ! Вот вы все про протоколы, гарантии доставки и прочую виртуальную внутренность 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 бачей КПК (тем более речь не о штучном изделии)? и как ты их инициализирровать то собрался без экрана ? да еше на ипак лялик сажать ? нет можно конечно заурус присобачить - но это уже не та цена 😃 да и лялик там сильно особенный 😃
идем дальше - если на передатчике ви-фи - то и на приемнике ви-фи - а дальше что ты на борте с голым вифи делать будешь ? вот - вот и выплывает - что надо сгондобить отдельный модуль (железо + софт) для борта и тоже для оператора на земле… а теперь приблизительный подсчет такой аппаратуры ? меня вот тоже постоянно мучает зуд сделать машинку на ви-фи - по офису гонять - с экрана моника подглядывать в камеру ( по мотивам красной офисной крысы)… но как только я подумаю во сколько мне встанет начинка для для такой машинки - все желание сразу отпадает. Можно купить оч дешево бук старый - и на нем все организовать - там писать софт вообще красота - но тогда машинка дюже большой получается - и уже неинтересно.