Jump to content

    

alx125

Свой
  • Content Count

    208
  • Joined

  • Last visited

Community Reputation

0 Обычный

About alx125

  • Rank
    Местный

Информация

  • Город
    Novosibirsk

Recent Profile Visitors

2503 profile views
  1. TI CCS-9.2 + CC26x2

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

    Здравствуйте. Если потребность сохраняется и Вам не очень дорог CCS-9.2, то пишите на cc23byte[собачка]mail[точка]ru Технические подробности и сроки. Также укажите , пожалуйста, о финансах (не спрашивайте, пжста, "сколько мне для счастья надо" ;-) ). Если договоримся - сделаю. P.S. Но, консультации - не моя область работы.
  3. Здравствуйте. Если потребность сохраняется, то пишите на cc23byte[собачка]mail[точка]ru Технические подробности и сроки. Также укажите , пожалуйста, о финансах (не спрашивайте, пжста, "сколько мне для счастья надо" ;-) ). Если договоримся - сделаю.
  4. Если Вы в слово ble вкладываете смысл низкого потребления, то в данном случае это не так. Чип поддерживает стандарт v.4.2. Да. Но он, то что называется Dual-Band. Т.е. и BT Classic , и Low Energy. Для вашего применения будет задействована часть BT Classic. Отсюда и не очень уж низкое потребление (см. datasheet). Причем, там цифры приведены для очень "нежного" варианта использования, а не для "боевого". Там же есть и раздел Low Energy Consumption, но к передаче звука он не имеет отношения.
  5. Добрый день. Подсчитаем: ..данные АЦП накапливаются (допустим на частоте дискретизации 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 не трудно. Профиль - это всего лишь для стандартизации и удобства.
  6. BLE-модуль RN4871 от Microchip

    А никто и не заявлял , что 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 кбит/с.
  7. Добрый день. Лучше, если будут обозначены числа. Сколько задержка сейчас? Сколько приемлемо? Более подробно об условиях применения. В какие моменты возникают "неприемлемые задержки"? BT Classic не славится сильно экономичный потреблением! А BLE v4.x не подойдет для большИх скоростей обмена. (кроме , BLE v.5. Но мне известен лишь смартфон с поддержкой этой версии BT)
  8. Цитата(uriy @ Jan 18 2018, 20:21) Написано dual mode, но он тоже без аудио. Для BLE я предпочитаю Nordic NRF51822. Добрый день. Термин Dual mode говорит о том, что модуль поддерживает режим Classic и Low Energy одновременно. В свою очередь, наличие режима BT- Classic говорит о том, что стек поддерживает протоколы ACL и SCO. А SCO - это и есть простейший протокол для передачи аудио. Например, он применяется в обычных BT-гарнитурах. А отсутствие удобного профиля, просто облегчающего жизнь программисту не так и страшно. Его легко "прикрутить" самостоятельно. P.S. Вообще в названиях много путаницы и указания Bluetooth 4.1 не отвечает на много вопросов о возможностях конкретного чипа И даже термины Smart и Smart Ready тоже не на все вопросы отвечают. Например, на алиэкспрессе полно устройств, где указано v4 протокола, но они не поддерживают режим Low Energy
  9. Цитата(Mihail Gluhowchenko @ Jan 7 2018, 19:05) Она маркетингово совместима с 5.0... Добрый день С какими смартфонами (или др гаджетами ) хотите связать? Уже такие выпущены? ТС, если вопрос актуален, можете скинуть в личку (или здесь) бюджет проекта. Если будет интересно - сделаем. Кодек какой планируется? Высокого битрейда не получится! P.S. Ассемблер здесь вряд нужен
  10. Цитата(Plain @ Aug 13 2017, 05:16) Не понятно, о чём три страницы, какие ещё смартфоны дома? Придя домой всё уличное оставляют в прихожей, моют руки и далее пользуются стерильным домашним. Все просто Когда речь идет о использовании коммуникаций, то надо >= 2-х устройств Очень соблазнительно в качестве одного из них использовать, то что уже лежит у каждого в кармане
  11. Цитата(AlexandrY @ Aug 11 2017, 16:53) ... Связь по BLE 5.0, никаких Wi-Fi. Сомоорганизация в mesh сеть. Функции не придумываем, все уже отпрофилировано в Bluetooth SIG Смартфоны на лету подхватывают функциональность поскольку она стандартная: климат, освещение, охрана, дистанционное управление AV, автоматизация, indoor навигация ... Добрый день. Подскажите пожалуйста парочку смартфонов/планшетов (или др. гаджеты) на рынке с BLE 5.0 ? Если получится, то и их процент от всего рынка смартфонов? А это вопрос объема рынка и совместимости.. Спецификация mesh (Ad Hoc), только анонсирована. Массово появится не скоро! (Ручную имитацию здесь не рассматриваю) Даже BLE 4.2 в полном объеме до сих пор встретишь не часто. В основном очень свежее, флагманское и дорогое А на BLE 4.0 (да и на 4.2) о скоростях передачи можно только мечтать... Цитата(AlexandrY @ Aug 11 2017, 22:56) .. Управляется конечно через BLE и подозреваю по стандартному профилю. .. Наверное, все же, речь идет о стандартных BLE-сервисах? Стандартные профили BLE: GAP и GATT. Остальные варианты (в т.ч. любимый всеми SPP) могут эмулироваться программистами на базе стандартного ATT-протокола, который для этого ну совсем не приспособлен! Цель BLE была - экономия на всем! Отсюда и скорости...... Большое количество стандартизированный профилей это из BT-classic ( <= v2.1+EDR). При этом любой гаджет изначально (без доп. добавок) поддерживает очень мало этих профилей (~1-4) ! BT v.3 (>20MBit/s) не рассматриваем. Это экзотика. Наверное, использую только я Хотя, если кастомный профиль содержит только один сервис , эти понятия иногда используют взаимозаменяемо P.S. У Вас так много одновременных проектов! Скажите, как Вы успеваете все? TC, ведет как в китайской мудрости - сидит на берегу и ждет когда проплывет труп врага (читай - идея) Это комплименты )
  12. nRF51822 вопросы по работе с ним

    Цитата(AlexandrY @ Mar 18 2017, 11:09) Может поможет глоссарий в моей статье - https://geektimes.ru/post/276558/ Бондинг и пайринг, как следует из него совершенно разные вещи. Но прежде чем сделать бондинг надо сделать пайринг. За оба процесса отвечает слой GAP Уточняю :-) "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."
  13. Вдруг заинтересует (+комментарии+ссылки) https://geektimes.ru/post/284676/
  14. Цитата(uriy @ Nov 30 2016, 09:08) С FEC задержка как раз будет гарантированная и фиксированная. Про retransmission в SCO никогда не слышал. Зачем это для звука? Не удивительно, что не слышали. Спецификация про это молчит :-) Но ТС написал , "потерянные данные восстановит верхний протокол". Т.е. он это планирует взять на себя, а не на спецификацию стека BT возложить. В принципе - рабочий подход. Так реализовано было в Skype (по крайней мере до Microsoft). Чтобы сократить накладные затраты TCP, передачи велись ч/з UPD-пакеты. А доп.верхний уровень в случае необходимости запрашивал повтор. Что же касается FEC-кодов ( Forward Error Correction, FEC, помехоустойчивое кодирование), то это решение добавляет избыточность в передачу и конечно же уменьшает скорость для payload. Представьте на минуту, что он (код) выделил ошибку. То необходимо запросить (т.е. трафик в обратном направлении со всеми timeout-ами) повтор передачи. Какая уж тут гарантированная мин.задержка. Если же код не только с обнаружением , но и с коррекцией ошибок, то там и избыточность передачи выше и кодирование сложнее. А возможности коррекции ошибок очень даже ограничены. Например, можно исправить лишь 1-2 бита. Именно поэтому SCO изначально ориентирован на речь, т.к. там мелкие проблемы в передаче сгладит ухо+мозг.
  15. Цитата(gerber @ Nov 29 2016, 01:38) Может, подскажет кто - неужели нельзя использовать 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." Цитата(gerber @ Nov 29 2016, 11:57) Скорость нужна немаленькая, хотя бы 115200 бит/с. Тот канал SCO, который я сейчас вижу, пересылает по 60 байт каждые 3,2 мс, вроде как, нормально, если пойдут через него raw-данные. Это как раз не проблема, потерянные данные восстановит верхний протокол. К тому же там есть механизмы, улучшающие вероятность доставки пакетов, это и восстанавливающие коды FEC, и retransmission. Но гарантии доставки, как у ACL, нет, это понятно. Если Вы будете использовать "восстанавливающие коды FEC, и retransmission", то где же тут у Вас гарантированная задержка (latency)? Для Real Time, в этом случае, нужен существенный запас скорости. :-) Да и без "восстанавливающие коды FEC, и retransmission" макс. возможная скорость SCO может Вас не устроить.