Схематехника бортового компьютера модели (WiFi).
Хочется свою платку сделать
Кроме самого девайса нужно еще софт написать, а это несколько сложнее.
Приемник не слишком громоздкий получается?
Точка доступа, я так понимаю, будет в передатчике?
Вы на модель данные по IP гнать собираетесь? Интересно понять, что останется от линукса, что потребуется дописать?
игрушки всё это. время прохождения команды от пилота на борт по вай-ваю будет просто ЧУДОВИЩНЫМ. и ничего тут не поделать.
2 Denis G:
айпак сейчас принимает какое-либо участие в жизни передатчика ?
время прохождения команды от пилота на борт по вай-ваю будет просто ЧУДОВИЩНЫМ.
Какое оно? 😃 Желательно цифры.
Блин, ну нельзя сравнивать wifi который компьютерный! Потому что поверх 802.11 еще идет IP, потом TCP, поверх него netbios и так далее, только в самом конце идет передача файла. Избыточность чудовищная. Если вы по TCP что-то из интернета качаете и сидите еще при этом за NAT и хост тоже где-то довольно далеко находится… Только все это не имеет отношения к 802.11.
Какое оно? 😃 Желательно цифры.
Блин, ну нельзя сравнивать wifi который компьютерный! Потому что поверх 802.11 еще идет IP, потом TCP, поверх него netbios и так далее, только в самом конце идет передача файла. Избыточность чудовищная. Если вы по TCP что-то из интернета качаете и сидите еще при этом за NAT и хост тоже где-то довольно далеко находится… Только все это не имеет отношения к 802.11.
забыли упомянуть HTTP для пущей убедительности 😁
я говорю что сам по себе 802.11b(g) не настолько шустрый, чтобы возможно было использовать его в вашей ситуации в качестве носителя второго уровня. а цифры вы сами узнаете, ели конечно дело до этого дойдет. спорить и убеждать кого-то я не хочу, я всего лишь предлагаю более критично отнестись к этой идее. У автора хороший потенциал, жаль тратит он его на заведомо гиблое дело 😉 ИМХО.
Добавлено
Хочу просто добавить: мой интерес не праздный, если бы автор продолжал движение своей идеи в сторону переделки готового передатчики и оснащения его микроконтроллером в качестве формирователя сигнала и айпаком в качестве интерфейсной части - то, к примеру, лично я бы с удовольствием постарался оказать посильную помощь проекту… а машинки на вай-вае пускать - в этом мало интересного 😉
я говорю что сам по себе 802.11b(g) не настолько шустрый, чтобы возможно было использовать его в вашей ситуации в качестве носителя второго уровня. а цифры вы сами узнаете, ели конечно дело до этого дойдет.
Хорошо. Вы задумывались, насколько шустрый, например, PCM1024? Минимальная скорость обновления канала = 14.25 мс. Какой при этом битрейт? Меньше 6 КИЛОБИТ.
спорить и убеждать кого-то я не хочу, я всего лишь предлагаю более критично отнестись к этой идее.
Поймите правильно. Я не спорю с вами, просто мне интересно узнать, действительно ли есть какие-то серьезные проблемы, если есть, то в чем конкретно они заключаются. Фразы вроде “802.11b(g) не настолько шустрый, чтобы возможно было использовать его в вашей ситуации” звучат несколько голословно, особенно в сочетании с “а цифры вы сами узнаете”.
Это вам так кажется, или у вас есть какие-то фактические данные?
Я не говорю, что это все супер круто и клево. Просто мне интересно, что из этого получится. На свой вертолет я бы это не поставил, но какой-нибудь самолетик-тренер бы для эксперимента нашел.
основная засада не в мегабитах в секунду, а во времени гарантированной доставки. у PCM этот параметр известен и стабилен (относительно), а у вай-фая подобная характеристика крайне размыта (другими словами - её попросу нет).
поэтому, к примеру, до сих пор AFAIK нет нормальной рабочей реализации хождения VoIP (протокол очень критичный к таймаутам) по вай-ваю (всякие скрипелки типа скайпа тут не в счёт, я говорю о нормальном качестве услуги) - на основании этого, в основном, я и делаю свой вывод.
основная засада не в мегабитах в секунду, а во времени гарантированной доставки.
Ни о какой гарантии в PCM речи не идет. Время доставки при двух одновременно включенных передатчиках на одной частоте не определено.
Отправив пакет мы не знаем, будет ли он доставлен. Точно так же можно работать и по WiFi.
до сих пор AFAIK нет нормальной рабочей реализации хождения VoIP
Проблемы VoIP, насколько я понимаю, не столько в WiFi сколько в IP. Аналогия с голосом в нашем случае некорректна так как нам нужно воспроизвести с максимальной точностью в реальном времени _процесс_. Что же касается модели, то нас интересует только самое последнее состояние ручек передатчика. В какой последовательности моделист их переводил чтобы достичь этого состояния - модели все равно, лишь бы более старое состояние не заменило собой более новое.
Ни о какой гарантии в PCM речи не идет. Время доставки при двух одновременно включенных передатчиках на одной частоте не определено.
Отправив пакет мы не знаем, будет ли он доставлен. Точно так же можно работать и по WiFi.
Проблемы VoIP, насколько я понимаю, не столько в WiFi сколько в IP. Аналогия с голосом в нашем случае некорректна так как нам нужно воспроизвести с максимальной точностью в реальном времени _процесс_. Что же касается модели, то нас интересует только самое последнее состояние ручек передатчика. В какой последовательности моделист их переводил чтобы достичь этого состояния - модели все равно, лишь бы более старое состояние не заменило собой более новое.
- чем проще механизм - тем надёжней он работает. это можно назвать гарантией.
- время определено, вы сами его упоминали.
- в 802.11 пакет считается доставленным после подтверждения пира, а до тех пор пакет будет долбиться в эфир опять и опять (именно в этом проблема с VoIP, а не “в IP”, через ethernet всё работает).
- одно соединение в рамках VoIP порождает небольшой трафик, но поток данных должен быть гарантированно постоянным, считаю аналогию уместной.
вобщем - успехов! хочется верить, что вы НА ДЕЛЕ докажите, что я был не прав.
- в 802.11 пакет считается доставленным после подтверждения пира, а до тех пор пакет будет долбиться в эфир опять и опять (именно в этом проблема с VoIP, а не “в IP”, через ethernet всё работает).
Насколько мне известно, стандартом предусматривается так же режим потоковых данных. Подробности тут: www.ixbt.com/comm/wlan.shtml
Почему я сказал что проблема VoIP в IP? Потому что для более эффективной работы IP удобнее использовать режим передачи с подтверждениями. VoIP - попытки применить, в общем, не очень предназначенную среду для передачи непрерывных процессов, в частности голоса. Надо сказать, двольно удачная, но если заглянуть внутрь, то становится ясно, насколько IP плохо предназначен для подобных вещей.
ага, предусматривает. через одно место.
кстати, источник не аффтаритетный (дискридитировал он себя уже давно).
давайте просто подождем новых достяжений нашего автора ? 😉
PS: У VoIP есть свои проблемы, но не надо мешать всё в общую кучу. Без подтверждения доставки на уровне физическго носителя работает нормально.
Без подтверждения доставки на уровне физическго носителя работает нормально.
Ну отключите у модема протоколы коррекции ошибок, соединитесь 14400/none и попробуйте поработать по TCP. 😃 Уверяю, работать будет просто невозможно. 😃
а какое отношение имеет протокол коррекции ошибок к подтверждению доставки ?
если бы я, к примеру, предлагал пакеты без контрольных сумм слать - ваша аналогия была бы уместна 😃
протокол коррекции ошибок либо исправляет канальные ошибки, либо не пропускает данные, ошибки в которых он исправить не может, а контроль доставки пакетов данных осуществляет всё тот же 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
😃