Comments 10
можно будет микроприёмник держать на самом хедсете и играть без проводов.
Так ведь сам шлем уже содержит блютуз. А еще там есть USB, в который можно подключить например USB блютуз свисток, если встроенный чем-то не устраивает.
Кстати по поводу этих свистков - если не устраивает блютуз стек ОС - можно общаться напрямую с USB устройством, для винды например достаточно написать inf чтобы сменить драйвер с блютузного на winusb, с которым уже можно работать из user mode.
Кстати а в нативках эта платформа вообще работает? Ведь шлем отслеживает перемещение относительно окружения, и топтание по платформе для него ничего не значит.
Так ведь сам шлем уже содержит блютуз.
Да, содержит, но стек не даёт доступа до пакетов как есть, о чем я и писал в начале. :(
Кстати по поводу этих свистков - если не устраивает блютуз стек ОС - можно общаться напрямую с USB устройством
Свистки разные, с разным уровнем торчания их радиотракта. Нужны те, которые дают сырой HCI достаточно низкого уровня, чтобы получать пакеты в сыром виде.
Я уж не говорю про Bluetooth Sniffer -- для которого вперёд, покупать свисток, на котором можно добраться до сырого радиотракта (и брать прошивку типа https://github.com/bluekitchen/raccoon).
У меня сейчас лежит в счисле общей кучки девайсов BleuIO. Вот он тоже отказывается отдавать пакеты как есть :(
В любом случае, если всё равно нужен внешний свисток -- так почему бы не сделать на нём полную имитацию исходного ресивера?
для винды например достаточно написать inf чтобы сменить драйвер с блютузного на winusb, с которым уже можно работать из user mode.
Что делает user-unfriendly. Всё равно надо какое-то доп железо (уже имеющееся не подойдёт), плюс телодвижения по установке дров, и добро пожаловать в мир поддержки зоопарка, так как HCI нифига не стандартизован, а блокировка пакетов происходит вообще где-то в недрах виндовых частей, в которые в Win10 еще можно залезть, то в Win11 я даже не нашел где и кто за них в ответе. Впрочем, я не так долго искал, решил пойти другим путём раньше.
Кстати а в нативках эта платформа вообще работает?
Некоторые игры -- да, поддерживает в стандалон режиме.
Для нативок у них есть свой APK который ставится прямо на хедсет и патчит игры для инъекции туда обработки, поток для обработки идёт с отдельного девайса (Nexus) к которому подключается платформа. До этой части (и её исправления/улучшения) я дойду позднее :)
HCI нифига не стандартизован
Вообще стандартизирован, я тоже возился с блютуз свистком (дешевым китайским) и там все внезапно по стандарту. Как раз заводил его через winusb. Может мне конечно повезло, и первый попавшийся китайский свисток внезапно оказался вменяемым.
блокировка пакетов происходит вообще где-то в недрах виндовых частей
Блокировка то происходит если винда работает со свистком как с блютуз девайсом, а если поставить драйвер winusb - со свистком можно работать напрямую, посылая ему пакеты по спецификации, а винда вообще не будет его считать блютуз девайсом и вмешиваться в обмен.
Тут главный вопрос - насколько кривой протокол этой платформы и будет ли стандартный свисток выдавать нужные пакеты.
P.S. Еще возился с ИК трансивером, так он был какбы HID устройством, но HID там был реализован криво, и нормально не работал. Пришлось тоже через winusb заводить.
Вообще стандартизирован
Да, но огромный пласт Vendor-Defined HCI Commands. Для моих целей ключевое было -- если я не могу полагаться что заведётся на том железе, которое точно у юзера есть -- то лучше пусть будет то железо, которое я могу контролировать.
Да, свисток стоит $10, но он отлажен и точно работает. Либо перебирать $3 свистки с вероятностью что он работать не будет...
К слову -- я бы с удовольствием почитал про запинывание BLE свистка напрямую через WinUSB!
Вообще есть опенсорс либа btstack, она как раз работает в том числе со свистками через winusb, но я делал самопал на основе линуксовых драйверов, а потом уже наткнулся на btstack. Но с ним были какие-то проблемы - вроде свисток находил но проблемы толи с соединением толи с отправкой. Поскольку уже был рабочий самопал - не стал особо заморачиваться с выяснением причин.
По поводу статьи - не знаю, я делал под конкретную цель (BLE, но там протокол оказался более-менее стандартный) временную тулзу - соответственно все настройки правкой исходников, и это было уже давненько. У меня есть статья про ИК трансивер через winusb.
А платформа получается общается по BLE только со своим комплектным приемником? Интересно какой смысл так делать, если можно общаться напрямую с компом или шлемом?
Речь про https://github.com/bluekitchen/btstack ? Это не очень простая вещь чтобы заставить её работать в более-менее универсальном виде. Для конкретного железа, впрочем, может подойти. Буду иметь ввиду, спасибо.
По поводу статьи - не знаю, я делал под конкретную цель (BLE, но там протокол оказался более-менее стандартный) временную тулзу - соответственно все настройки правкой исходников, и это было уже давненько
Мы на хабре, это никого не смущает :)
У меня есть статья про ИК трансивер через winusb.
Её уже читал, пару лет назад. Реверс части были интересные, про winusb я не запомнил ничего, даже слов таких. Перечитал пару дней назад после комментария -- и понял, почему: эта часть осталась не раскрытой.
Речь про https://github.com/bluekitchen/btstack ?
Да, оно. В общем добрался таки - скачал последнюю версию, глянуть что изменилось, пофиксили ли старые баги. Так походу еще и новые добавили. Запустил gatt_device_information_query - сканирует, находит девайс, но почему-то пытается подключаться по нулевому MAC-у, хотя при скане MAC нормальный. При повторном запуске вообще гарантированно падает.
Стал разбираться - оказалось там для подключения используется переменная report, но она вообще нигде не инициализируется - потому и MAC нулевой. А при повторном запуске читается файл tlv, но в функции чтения в вызове ReadFile аргумент, в который винда возвращает число прочитанных байтов - NULL, а NULL там недопустим. В общем исправил все это - тулза кое-как заработала, и даже иногда выдавала правдоподобную инфу, но чаще просто висла. Дальше уже не стал разбираться.
Я вообще не понимаю как они эту либу пишут - они ее хоть запускать то пробовали? Или там намеренная диверсия? С другой стороны - как-то это все-таки работает. Может если появится какая-то конкретная цель - попробую таки довести эту либу до ума.
А платформа получается общается по BLE только со своим комплектным приемником? Интересно какой смысл так делать, если можно общаться напрямую с компом или шлемом?
Я в голову их не могу залезть, но причин вижу несколько:
Обеспечение стабильных задержек. Своя железка, которая занята только ими, может более-менее (если рядом не работает какой-нибудь сварочник) обеспечить стабильные задержки на обновление вне зависимости от нагрузки от игр
Legacy: платформа это 3е или 4е поколение их решений для locomotion, и совместимость софта между всеми версиями + прототипирование на уже имеющихся наработках
Совместимость: у них есть решение для standalone (платформа подключается в их коробочку, с которой общается софт на хедсете), для PSVR (спец девайс включается в разрыв контроллера и плойки), еще обещают PS5VR... Там достаточно гемора с инжектом движения -- увеличивать сожность еще и гемором с блютусом может оказаться слишком дорого.
KatWalk C2: ч.3: отрезаем провода