alx125

Может быть об этом речь? "Технология NearLink от Huawei передает данные эффективнее, чем Bluetooth и Wi-Fi" hightech.plus/2023/08/07/besprovodnaya-tehnologiya-nearlink-ot-huawei-peredaet-dannie-effektivnee-chem-bluetooth-i-wi-fi

Такого уже не может быть! Ну конечно, если Вы не используете внешний старый USB dongle. В компьютерах и смартфонах уже давно используются Dual Mode чипы Bluetooth. Они поддерживают Classic и BLE. Ну, а Windows 10, тем более, оба стека поддерживает. Другое дело, что у Classic гораздо больше стандартных профилей. И большинство из них отсутствует в BLE.

Добрый день! Подскажите пожалуйста бюджет разработки. (Можно в личку) Прежде чем что-то обсуждать, хотелось бы понять серьезность и адекватность намерений! Фразы: "несложного BT-устройства", "совместимым от 2.0 до 5.0 (в идеале) ", " И приобретаться модуль должен не на блошином рынке в Китае " удивляют. P.S. Часто, в постах присутствуют "стоп-фразы" , которые помогают воздержаться от дискуссии. С уважением.

Добрый день. Если договоримся, то сделаю. Дорого! Все будет очень маленькое. И при производстве низкая себестоимость. Электроника, батарейка, печатная антенна с цепями согласования ~4кв.см. При Вашем режиме работы вольтметра - батарейка CR1632 будет практически вечная! Расстояние, обычно, на открытом пространстве - метров до 50. Могу и дальше, но дороже. Уже выпускаемые изделия - много! Покажу Будет желание, пишите сюда: cc23byte[собачка]mail[точка]ru P.S. Если бюджет сильно ограничен, тогда можно не писать. Не интересно.

Извините за неточность Точнее было бы так: Вам не очень "дорог" CCS-9.2 Речь не о деньгах ;-)

Здравствуйте. Если потребность сохраняется и Вам не очень дорог CCS-9.2, то пишите на cc23byte[собачка]mail[точка]ru Технические подробности и сроки. Также укажите , пожалуйста, о финансах (не спрашивайте, пжста, "сколько мне для счастья надо" ;-) ). Если договоримся - сделаю. P.S. Но, консультации - не моя область работы.

Здравствуйте. Если потребность сохраняется, то пишите на cc23byte[собачка]mail[точка]ru Технические подробности и сроки. Также укажите , пожалуйста, о финансах (не спрашивайте, пжста, "сколько мне для счастья надо" ;-) ). Если договоримся - сделаю.

Если Вы в слово ble вкладываете смысл низкого потребления, то в данном случае это не так. Чип поддерживает стандарт v.4.2. Да. Но он, то что называется Dual-Band. Т.е. и BT Classic , и Low Energy. Для вашего применения будет задействована часть BT Classic. Отсюда и не очень уж низкое потребление (см. datasheet). Причем, там цифры приведены для очень "нежного" варианта использования, а не для "боевого". Там же есть и раздел Low Energy Consumption, но к передаче звука он не имеет отношения.

Добрый день. Подсчитаем: ..данные АЦП накапливаются (допустим на частоте дискретизации 300Гц до объема 4096 байт (это сейчас так сделано), потом высылаются, затем опять накапливаются и цикл повторяется.. Допустим, что выборка АЦП -это 2 байта (= 16 бит). (Если выборка АЦП это 1 байт - то все в 2 проще.) 300гц * 16 бит = 4800 бит/сек. - требуемая скорость Такую скорость для payload передаваемых пакетов может обеспечить даже BLE v4.0. !!! Допустим, что особенность проекта - обязательное накопление 4096 байт, а затем передача по BLE. (В противном случае все еще проще - передаем сразу же как накопится размер payload для пакета). Время накопления в буфере (вариант 2-х байтной выборки АЦП): T= 3.33ms * (4096 байт / 2) = 6.8 sec !!! И столько же времени накапливаются следующие 4096 байт. Т.е. (при наличии 2-х буферов) для передачи мы имеем ~7 сек, что позволяет нам спокойно передать содержимое буфера. И требуемая скорость - те же 4800 бит/сек. BLE прекрасно подойдет для вашей задачи. Все будет очень маленькое и малопотребляющее. При непрерывной работе (7sec передаем/7 sec накапливаем) и питании от CR2032, все проработает несколько месяцев. При редком включении BLE - годы. Если, все же, нужно быстрее - выбирайте SoC+SDK с поддержкай BLE v.4.2 или BLE 5 При этом , конечно, важны возможности второй стороны обмена. Но Вам требуется такая низкая скорость передачи, что все заработает без особых настроек... Обычно эти SoC содержат и ADC, и SRAM >4096 байт, что может упростить конструкцию прибора. Я, например, использую SoC от TI: CC2640, CC2640R ...Пробовал NRF51822 - передавать либо обновлением характеристики, либо через notofication - данные теряются, либо все вообще виснет... BLE работает "железобетонно". Только учтите, что вариант notification - это без подтверждения доставки пакета (как в UDP). (Лучше бы Indication). Или вообще измените логику работы: вторая сторона (например, Android) раз в 7 сек запрашивает соединение и читает 4096 байт. Тогда можно и без notification, Indication ..Нужно что-то типа SPP или A2DP.. Наверное Вы имели в виду SPP и протокол RFComm? Ни того , ни другого в BLE нет. Но это не проблема, т.к. написать приемлемый вариант эмуляции SPP не трудно. Профиль - это всего лишь для стандартизации и удобства.

А никто и не заявлял , что BLE v4.2 (версия написана в даташите) позволит скорость payload 1 мбит/с! Возможно, Вы имели в виду 1 МГц? Так это модуляция. На самом деле, с т.з. этого модуля , все не так и плохо для Вас! BLE v4.2 теоретически позволяет скорость payload до 200 кбит/с. Но! Тут важны нюансы: - возможности конкретной реализации стека BLE (см. SDK). - возможности чипа и стека (HW и SW) второй стороны обмена. - чтобы использовать новые предельные возможности BLE v.4.2 нужна тщательная настройка параметров взаимодействия двух BLE стеков. "По дефаулту" вряд ли Вы получите эти предельные характеристики. Что касается BLE v.4.0, то там (при тщательном подходе) достигаются скорости передачи payload до 80-100 кбит/с.

Добрый день. Лучше, если будут обозначены числа. Сколько задержка сейчас? Сколько приемлемо? Более подробно об условиях применения. В какие моменты возникают "неприемлемые задержки"? BT Classic не славится сильно экономичный потреблением! А BLE v4.x не подойдет для большИх скоростей обмена. (кроме , BLE v.5. Но мне известен лишь смартфон с поддержкой этой версии BT)

Добрый день. Термин Dual mode говорит о том, что модуль поддерживает режим Classic и Low Energy одновременно. В свою очередь, наличие режима BT- Classic говорит о том, что стек поддерживает протоколы ACL и SCO. А SCO - это и есть простейший протокол для передачи аудио. Например, он применяется в обычных BT-гарнитурах. А отсутствие удобного профиля, просто облегчающего жизнь программисту не так и страшно. Его легко "прикрутить" самостоятельно. P.S. Вообще в названиях много путаницы и указания Bluetooth 4.1 не отвечает на много вопросов о возможностях конкретного чипа И даже термины Smart и Smart Ready тоже не на все вопросы отвечают. Например, на алиэкспрессе полно устройств, где указано v4 протокола, но они не поддерживают режим Low Energy :rolleyes:

Добрый день С какими смартфонами (или др гаджетами ) хотите связать? Уже такие выпущены? ТС, если вопрос актуален, можете скинуть в личку (или здесь) бюджет проекта. Если будет интересно - сделаем. Кодек какой планируется? Высокого битрейда не получится! P.S. Ассемблер здесь вряд нужен :rolleyes:

Все просто Когда речь идет о использовании коммуникаций, то надо >= 2-х устройств Очень соблазнительно в качестве одного из них использовать, то что уже лежит у каждого в кармане

Добрый день. Подскажите пожалуйста парочку смартфонов/планшетов (или др. гаджеты) на рынке с BLE 5.0 ? Если получится, то и их процент от всего рынка смартфонов? А это вопрос объема рынка и совместимости.. Спецификация mesh (Ad Hoc), только анонсирована. Массово появится не скоро! (Ручную имитацию здесь не рассматриваю) Даже BLE 4.2 в полном объеме до сих пор встретишь не часто. В основном очень свежее, флагманское и дорогое А на BLE 4.0 (да и на 4.2) о скоростях передачи можно только мечтать... Наверное, все же, речь идет о стандартных BLE-сервисах? Стандартные профили BLE: GAP и GATT. Остальные варианты (в т.ч. любимый всеми SPP) могут эмулироваться программистами на базе стандартного ATT-протокола, который для этого ну совсем не приспособлен! Цель BLE была - экономия на всем! Отсюда и скорости...... Большое количество стандартизированный профилей это из BT-classic ( <= v2.1+EDR). При этом любой гаджет изначально (без доп. добавок) поддерживает очень мало этих профилей (~1-4) ! BT v.3 (>20MBit/s) не рассматриваем. Это экзотика. Наверное, использую только я :( Хотя, если кастомный профиль содержит только один сервис , эти понятия иногда используют взаимозаменяемо :) P.S. У Вас так много одновременных проектов! Скажите, как Вы успеваете все? TC, ведет как в китайской мудрости - сидит на берегу и ждет когда проплывет труп врага (читай - идея) Это комплименты )

Уточняю :-) "Pairing The procedure by which a temporary common security encryption key is generated to be able to switch to a secure, encrypted link. This temporary key is not stored and is therefore not reusable in subsequent connections. Bonding A sequence of pairing followed by the generation and exchange of permanent se‐ curity keys, destined to be stored in nonvolatile memory and therefore creating a permanent bond between two devices, which will allow them to quickly set up a secure link in subsequent connections without having to perform a bonding pro‐ cedure again."

Вдруг заинтересует (+комментарии+ссылки) https://geektimes.ru/post/284676/

Не удивительно, что не слышали. Спецификация про это молчит :-) Но ТС написал , "потерянные данные восстановит верхний протокол". Т.е. он это планирует взять на себя, а не на спецификацию стека BT возложить. В принципе - рабочий подход. Так реализовано было в Skype (по крайней мере до Microsoft). Чтобы сократить накладные затраты TCP, передачи велись ч/з UPD-пакеты. А доп.верхний уровень в случае необходимости запрашивал повтор. Что же касается FEC-кодов ( Forward Error Correction, FEC, помехоустойчивое кодирование), то это решение добавляет избыточность в передачу и конечно же уменьшает скорость для payload. Представьте на минуту, что он (код) выделил ошибку. То необходимо запросить (т.е. трафик в обратном направлении со всеми timeout-ами) повтор передачи. Какая уж тут гарантированная мин.задержка. Если же код не только с обнаружением , но и с коррекцией ошибок, то там и избыточность передачи выше и кодирование сложнее. А возможности коррекции ошибок очень даже ограничены. Например, можно исправить лишь 1-2 бита. Именно поэтому SCO изначально ориентирован на речь, т.к. там мелкие проблемы в передаче сгладит ухо+мозг.

Стандарт позволяет (про конкретный Ваш чип не скажу). Но! Спецификация (Classic BT): "Four packets are allowed on the SCO logical transport: HV1, HV2, HV3 and DV. These packets are typically used for 64kb/s speech transmission but may be used for transparent synchronous data" "The air coding by log PCM or CVSD may be deactivated to achieve a transparent synchronous data link at 64 kbits/s." Если Вы будете использовать "восстанавливающие коды FEC, и retransmission", то где же тут у Вас гарантированная задержка (latency)? Для Real Time, в этом случае, нужен существенный запас скорости. :-) Да и без "восстанавливающие коды FEC, и retransmission" макс. возможная скорость SCO может Вас не устроить.

Наверное, Вы имели в виду 10мс? Чтобы аддитивные составляющие разнополярных периодов синусоиды компенсировались при накоплении? А если, как это обычно бывает, частота не точна? Например, 49Гц - 51Гц? Что же получится после накопления? А если там чуть-чуть не синусоида?

Протокол Z-Wave становится открытым https://geektimes.ru/post/280822/ http://z-wave.sigmadesigns.com/design-z-wa...-specification/

Здравствуйте Уточните пожалуйста, о каком АЦП речь - их там два типа: SAR ADC и SDADC ? А также напишите про числа - частота ядра и про АЦП

Вопросы стоимости BT-проекта многие коллеги уже обозначили. Но уточним. Есть основных два подхода: Host микроконтроллер находится внутри или отдельно от BT-модуля (Есть еще вариант - место, где функционирует сам BT-стек и приложение). Наиболее привлекательный первый вариант (например модули BlueGiga), но эти модули + SDK + работа - это весьма дорого! Второй вариант кажется дешевле, но в реально очень много работы и трудностей + микроконтроллер. Уж не говоря о том, что если Вы ориентируетесь на китайские модули, то сюрпризом может быть одинаковость BTAddreess всех модулей! А это в классическом BT (v1.x - v2.х+EDR) работать не может! Это подойдет для случая связи со смарфоном, планшетом и т.п. Но не Вашем случае! Так что вопрос BT-разработки и себестоимости произодства (на малых партиях) не дешевый! Плюс возьня с аккумуляторами, ЗУ и жесткие условия эксплуатации. Думаю, что рациональнее оставить кабель. Может быть, найти более прочные и надежные разъемы. Приведу близкий пример. У фехтовальщиков тоже используется крепкий кабель (~1,5м). Но он тоже рвется, портятся контакты. Но есть и дорогие беспроводные системы судейства (кстати там речь идет о сотых долях секунды). По моим оценкам, эти технологии у нас в стране присутствуют в пропорции 95% и 5% соответсвенно. Как говорится: "Делайте выводы". Bluetooth - это технология мирового уровня, используемая на миллиардах устройств. Вопросам защищенности здесь уделено первостепенное значение! Когда кто-нибудь (без сопряжения) хочет подключиться к вашему смарфону/планшету и т.п., то у Вас появляется уведомление для разрешения. "Сопряжение" - это всего лишь один из многих вариантов Authentification/Authorization, предусмотренных технологией! "Сопряжение" удобно для тех случаев, когда хотя бы одно из двух устройств имеет клавиатуру и дисплей (а лучше оба устройства) Вы подошли со своим смартфоном к компьютеру и он сразу же подключился по BT и стал внешним диском, началась синхронизация. Кому-то нравится... Конечно, Можно PIN жестко зашить в прошивку, но тогда теряется преимущества именно этого способа Авторизации. Про раздел технологии Encryption не говорю, т.к. врядли кто-то будет перехватывать и расшифровывать данные... Параноя по поводу секретности/защищенности от подтасовок в данном применении - это ближе к Сноудену и АНБ. С чем могу согласиться - много зависит от проектировщика. Против его некомпетентности и злого умысла мало что поможет. Кстати, давайте уточним для какой технологии мы рассуждаем? А то в дискуссии произошло смешение терминологии. Речь идет о "Classic BT" (v1.x - v2.х+EDR) или BLE (v4.x)? (BT v3 не рассматриваю - это редкость) Для BLE вообще все сильно изменилось в подходах! Например, для BLE основной является "Connectionless Model" (Все для минимизации потребления) Так что, тема "разрыва соединения и его последующего восстановление" - вообще "до лампочки". Для Classic BT, то восстановление соединения - доли секунды. Проверено! Если это принципиально, легко ввести самодиагностику - светодиод (или звук) невосстановимой потери связи реализовать не сложно! "...скорости отработки программным стеком нештатных ситуаций..." - единицы миллисекунд. Но ведь ТС написал, что и в обратном направлении тоже есть передача: "..Итак из пистолета исходит сигнал курка и код попадания, в пистолет идёт код выстрела и включение светодиода.." Мой опыт - обратный! Очевидный пример - премиум BT (конечно ч/з SCO, а не ACL) стерео система для высококачественного звука (~$400): http://www.klipsch.com/products/kmc-3-wire...tem#description И много еще http://www.edifier.ru/speakers/bluetooth/

gaga2, Вы бы назвали сумму бюджета на разработку и желаемую конечнаю себестоимость изделия, которые Вы рассчитавете получить. Многое бы стало ясно и часть решений сразу бы отпало. А то тут слишком разгорелись теоретические споры. Решение на основе BT - только кажется дешевым! Про RF-интерференцию - окончательный вердикт возможен только после многочисленных испытаний Если же все же интеференция оказывает существенное влияние, то можно использовать только BT (или BLE). Bluetoth наиболее стойкая технология к RF-интерференции. Она разрабатывалась для случая, когда рядом множество работающих трансиверов (не только BT!!!) (Например, мобильный мессенджер FireChat (в основе коммуникация ч/з BT) во время беспорядков на Тайване устойчиво работал, когда вокруг сотни человек с включенным BT). Конечно пропускная способность падает, но все работает!!! Есть даже попытки применения BT для Real-Time коммуникаций прямо у двигателя под капотом автомобиля. Уж там то проблема RF-интерференции и Real-Time стоит в полный рост! Приведенная выше большая задежка для Bluetooth - это миф. Без проблем можно получить Real-Time для данного применения. А вот все сопутсвующие беспроводке накладные затраты и проблемы, упомянутые выше, - это реальность Кстати, из Вашего описанения я не понял - попадать ИК-лучем надо именно в пистолет противника? Только там ИК-приемник? Мне известны похожие разработки для тренировки для военных. Там несколько приемников находятся именно на жилетке. И кстати, слово "pairing", лучше перевести как "сопряжение", а не как "спаривание" :rolleyes: . По крайней мере это уже устойчивый термин в русскоязычном переводе технологии. И более того - в данном случае этого даже не нужно делать (сопрягать устройства) для коммуникации. Я ежедневно передаю ч/з Bluetooth десятки Мб без предварительного сопряжения устройств.

Молекулярный сканер SCIO забанили на Kickstarter https://geektimes.ru/company/medgadgets/blog/276486/ Kickstarter «забанил» проект в связи с нарушением авторских прав