Схематехника бортового компьютера модели (WiFi).
После поисков аппаратной платформы для схемотехники бортового компьютера модели и передатчика WiFi стандарта 802.11b была рассмотрена возможность хакнуть стандартное сетевое изделее.
Подробности и фото на сайте i158: www.i158.com/index.php?option=com_content&task=vie…
Вот еще такая ссылка есть: www.ixbt.com/comm/wrls-edimax-br-6104k.shtml Особенно там интересен раздел “ссылки”. Такой вообще 35$ стоит если не дешевле.
Вот еще такая ссылка есть: www.ixbt.com/comm/wrls-edimax-br-6104k.shtml Особенно там интересен раздел “ссылки”. Такой вообще 35$ стоит если не дешевле.
_Обратите внимание модель 6104k не имеет WiFi 802.11 модуля, отсюда и цена 35 USD. В тоже время Edimax выпускает три модели на чипсете RTL8181
- EW-7206APB
- EW-7207APB
- BR-6104WB
на которых стоят Филипсовые ВЧ модули.
И пока цена на подобные дешевые (китайские бренды) не сэконд хэнд Wifi устройства лежит в пределах 35-50 USD_
Я свой купил за 32 зеленых 😋 Кажется цена проекта i158 со 100 баксов резко падает примерно до 70 😇 и будет падать ибо девайсы на 11Мбит выходят из моды. Мне еще нравятся две модельки компаний X-Micro members.chello.hu/b.globekom/xmicro/, и конечно Minitar melbourne.wireless.org.au/wiki/?minitar благодаря открытости самих разработчиков. Есть сходства 😃
В одной из статей по хаку линукс девайсов проскакивала схемка разводки платы девайса на RTL8181 с филипсовым ВЧ модулем в формате orCAD. Если кто встретит, плз. напишите ссылочку на denis@i158.com На моей плате модульность устройств соблюдена, хоть сейчас пили на кусочки. Но не у всех производителей все так хорошо. Хочется свою платку сделать 😒
Хочется свою платку сделать
Кроме самого девайса нужно еще софт написать, а это несколько сложнее.
Приемник не слишком громоздкий получается?
Точка доступа, я так понимаю, будет в передатчике?
Вы на модель данные по 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 не так уж плох. Наверное, есть какие-то иные подводные грабли.