Перейти к содержанию

    

alx125

Свой
  • Публикаций

    204
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о alx125

  • Звание
    Местный

Информация

  • Город
    Novosibirsk

Посетители профиля

2 266 просмотров профиля
  1. Добрый день. Подсчитаем: ..данные АЦП накапливаются (допустим на частоте дискретизации 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 не трудно. Профиль - это всего лишь для стандартизации и удобства.
  2. 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 кбит/с.
  3. Маленькая беспроводная сеть

    Добрый день. Лучше, если будут обозначены числа. Сколько задержка сейчас? Сколько приемлемо? Более подробно об условиях применения. В какие моменты возникают "неприемлемые задержки"? BT Classic не славится сильно экономичный потреблением! А BLE v4.x не подойдет для большИх скоростей обмена. (кроме , BLE v.5. Но мне известен лишь смартфон с поддержкой этой версии BT)
  4. Цитата(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
  5. Цитата(Mihail Gluhowchenko @ Jan 7 2018, 19:05) Она маркетингово совместима с 5.0... Добрый день С какими смартфонами (или др гаджетами ) хотите связать? Уже такие выпущены? ТС, если вопрос актуален, можете скинуть в личку (или здесь) бюджет проекта. Если будет интересно - сделаем. Кодек какой планируется? Высокого битрейда не получится! P.S. Ассемблер здесь вряд нужен
  6. Цитата(Plain @ Aug 13 2017, 05:16) Не понятно, о чём три страницы, какие ещё смартфоны дома? Придя домой всё уличное оставляют в прихожей, моют руки и далее пользуются стерильным домашним. Все просто Когда речь идет о использовании коммуникаций, то надо >= 2-х устройств Очень соблазнительно в качестве одного из них использовать, то что уже лежит у каждого в кармане
  7. Цитата(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, ведет как в китайской мудрости - сидит на берегу и ждет когда проплывет труп врага (читай - идея) Это комплименты )
  8. 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."
  9. Ищу исходники AN4229 (вокодеры) от ST

    Вдруг заинтересует (+комментарии+ссылки) https://geektimes.ru/post/284676/
  10. Цитата(uriy @ Nov 30 2016, 09:08) С FEC задержка как раз будет гарантированная и фиксированная. Про retransmission в SCO никогда не слышал. Зачем это для звука? Не удивительно, что не слышали. Спецификация про это молчит :-) Но ТС написал , "потерянные данные восстановит верхний протокол". Т.е. он это планирует взять на себя, а не на спецификацию стека BT возложить. В принципе - рабочий подход. Так реализовано было в Skype (по крайней мере до Microsoft). Чтобы сократить накладные затраты TCP, передачи велись ч/з UPD-пакеты. А доп.верхний уровень в случае необходимости запрашивал повтор. Что же касается FEC-кодов ( Forward Error Correction, FEC, помехоустойчивое кодирование), то это решение добавляет избыточность в передачу и конечно же уменьшает скорость для payload. Представьте на минуту, что он (код) выделил ошибку. То необходимо запросить (т.е. трафик в обратном направлении со всеми timeout-ами) повтор передачи. Какая уж тут гарантированная мин.задержка. Если же код не только с обнаружением , но и с коррекцией ошибок, то там и избыточность передачи выше и кодирование сложнее. А возможности коррекции ошибок очень даже ограничены. Например, можно исправить лишь 1-2 бита. Именно поэтому SCO изначально ориентирован на речь, т.к. там мелкие проблемы в передаче сгладит ухо+мозг.
  11. Цитата(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 может Вас не устроить.
  12. STM32. Диапазон напряжений АЦП 0-5В.

    Цитата(scifi @ Nov 10 2016, 21:43) Тогда ещё напомню, что нужно накапливать сумму показаний АЦП с равномерным шагом по времени за 20 мс. Тоже подавление 50 Гц. Наверное, Вы имели в виду 10мс? Чтобы аддитивные составляющие разнополярных периодов синусоиды компенсировались при накоплении? А если, как это обычно бывает, частота не точна? Например, 49Гц - 51Гц? Что же получится после накопления? А если там чуть-чуть не синусоида?
  13. Оборудование, протоколы

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

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