Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

Wearable-> Internet. Правильная архитектура?

Тема в разделе "Железные вопросы по esp8266", создана пользователем achest, 6 мар 2019.

  1. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.391
    Симпатии:
    1.271
    Дети изготавливают поделки с использованием пластилина и не одну, в день... Обычно после сборки поделка разбирается... Это аналогично использованию ESP. Осуждать их в практичности не имеет смысла, т.к. это процесс обучения и не имеет других целей.

    Из имеющихся на рынке решений, поставленных в головном запросе, есть всего одно: “Умные часы” (смарт-часы). ESP там не наблюдается. SDK/DDK к таким часам есть, но они “проприетарные” и “для дома для семьи” не годятся, т.к. @nikolz не создал и ничем не приблизил создание открытой бесплатной среды разработки на них.

    Карта устройства описанного в заголовке требует необходимость решения таких тех. задач:

    1) Организация связи с внешним миром путем использования стандартных протоколов.

    2) Накопление и обработка данных.

    3) Время разработки и внедрения.

    4) Малое потребление.

    В зависимости от типа связи (п.п1) и требований надежности получения данных в общей системе, пп2 распределяется на само устройство и внешние сервисы. Доля накопления поступающих/обрабатываемых и прочих диагностических данных на самом устройстве не может быть нулевым и полностью вынесенным за пределы самого устройства. В итоге, чем больше требуемая надежность системы, тем большая часть данных и диагностики должна буферизироваться на самом устройстве, что требует у малых модулей SoC дополнительных ресурсов RAM и/или применения раздельных накопителей (с большой Flash и т.д).

    Организация ESP и многих малых SoC не позволяет использовать для буферизации их Flash, т.к. в таких случаях сильно падает производительность и увеличивается потребление, что сказывается на общее время реакции устройства на все события, вызывая большой лаг для реал-тайм системы. Т.е. такая система уже не может обеспечивать нормальный реал-тайм режим. У первых RTL программа и данные, как и у многих малых Linux систем, работает из RAM, а Flash задействуется исключительно в случаях обращения к файловой системе или организованного в ней FIFO для данных, что запросто распределяется на малые атомарные задачи, исключая системные лаги возникающие при записи/стирании страниц Flash и опустошений программного кеша.

    К примеру, реакция корректированной Embedded Linux (специально оптимизированной OpenWRT), на одноядерном MIPS с 300 MHz, дает джиттеры на внутренние пересылки между задачами или на внешние (IP) запросы до 5 мс, а в среднем менее 1 мс. Аппаратные прерывания обрабатываются в микросекунды… При наличии встроенного в такой SoC WiFi устройства без своего MCU о реал-тайм можно забыть, не увеличивая кол-во ядер и их частоты, что ведет к дикому потреблению, лишнему нагреву и удорожанию.

    Применение MMC/SD карт усложняет и удорожает устройство более чем в два раза на систему “бесперебойного” экстренного питания на завершение операции с ними, разъемы и температурные диапазоны работы, малое ко-во гарантированных перезаписей... Т.е. нет смысла говорить о какой-либо надежности сохранности данных на них – но возможно использование в пластилиновых поделках (с) @nikolz :)

    Изученных и проверенных факторов ещё много, а создавать их полное описание я пока не намерен. По тому в краце:

    На сегодня уже куча дешевых китайских SoC со встроенной RAM более 32 Мб, способных удовлетворительно работать с Embedded Linux, обеспечивая приемлемую реал-тайм систему и небольшое потребление. Так-же куча модулей с раздельными шинами к раздельным типам памяти, которые при ненавязчивой оптимизации позволяют получать требуемый уровень реал-тайм всей системы. И становиться совершенно безразлично, какой встроенный или доп. модуль обеспечивает связь устройства с внешним миром, т.к. ресурсы позволяют незаморачиваясь использовать на них Linux подобные системы, а не ковыряться с пластилином.
     
  2. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.391
    Симпатии:
    1.271
    Эти решения не обеспечивают современных требований.
    Не путайте архитектуру аппаратного драйвера связи с датчиком с "архитектурой устройства".
    Времена получения данных 1 бит в час прошли. Магазины завалены готовыми простейшими беспроводными датчиками и их воссоздание на ESP или контроллерах Ti "для дома для семьи" не требуется. У вас гигантомания - вы разрабатываете устройство с миллионными тиражами на форуме для игры в вечерний блог с ESP? :)
    На 1 бит от датчика к передаче в систему требуются: время события, качество сигнала, статистика отказа, время наработки, ...
    Выборка в 1 точку в пять минут от вашей ESP не несет никакой информации и не дает возможности анализа и прочей для системной диагностики.
    При малой полосе канала большинство современных систем ведут усреднение потока от датчиков с выводом доп.информации типа максимума/минимума и других характеристик сигнала за период, чего не наблюдается в предложенной вами системе :p Используются и диагностические режимы, буферизации raw значений для последующей передачи...
     
  3. nikolz

    nikolz Гуру

    Сообщения:
    3.982
    Симпатии:
    426
    Увы Вы не в теме рынка мед сенсоров. Признайте?
    Я вам покажу лишь один пример
    Системы непрерывного мониторинга уровня глюкозы (CGM)
    В настоящее время есть три сертифицированные по международным стандартам системы
    две из них построены на чипах Ti (CC2500, СС 2510, СС 2640) - в порядке создания модификаций.
    А умные часы - это игрушки (об одном чипе для них с линуксом и андроидом с Гбайтами я вам говорил еще 5 лет назад , так как получал тогда их для экспериментов. Для медицины они не пошли.
    Для фитнесов - применяется сейчас и китайские разработки и те что я указал выше.
    --------------------------
    Но спорить с Вами не буду, не интересно.
     
  4. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.391
    Симпатии:
    1.271
    Нет, не в теме "рынка мед сенсоров", но в мед.теме и имеем необходимые разрешения и выпускаемую продукцию для медицины и прочие бумажки/плюшки на данную тему. На это давно уже было убито более года работы нескольких сотрудников, сопровождается далее и вложены некие средства, гораздо более цены сотен выданных вам для пиара микрух от Ti :)
    Например без разницы - купить новые микрухи или получить из бесплатно, в качестве семплов. Лучше купить - это дает меньше проблем в дальнейшем :p
     
  5. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.391
    Симпатии:
    1.271
    И между прочим, все эти установки, используемые в сотнях больниц РФ требуют систему оповещения местного персонала и другой диагностической информации для их обслуживания уже нами. Потому и готовлю сервис с применением уже NB-IoT, т.к. оно имеет большее проникновение, дальность и в будущем покрытие… А вот с WiFi/Lora/BT и подобным дело не очень, т.к. имеет местные проблемы связи и обслуживания, завязанные на частном учреждение и их “внутренних конфликтах”, где эксплуатируются наши установки, что дает низкую надежность и лишние затраты на сервисное обслуживание...
    И какой спор может быть, если у вас нет многолетней практики работы с клиентами по данной тематике?
     
  6. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.391
    Симпатии:
    1.271
    Вас загрузить текущими проблемами в рос. пром.оборудовании?

    Резервирование – кое-как осваивается, т.к. дело не очень сложное...

    Автоматическая адаптация системы к поломкам и прочим факторам, как и автоматический анализ износа компонентов с выработкой решений (на местном оборудовании) для эксплуатационников – пока нулевая. Нет или не хватает накопленных данных, обратной информации, т.к. не сформированы системные сервисы, нет надежных каналов передачи данных с оборудования для сбора статистики разработчиком-производителем и т.д. Развитие в данной области для малого и среднего “бизнеса” только начинается. Специалистов по данному поводу вообще нет. Такие работы ведутся исключительно на западные корпорации и разрабатываются у поставщиков оборудования типа Siemens, т.к. другие в РФ-ии не развиты (мало платят взяток?). В итоге в уже имеющейся инфраструктуре это могут позволить и использовать одни монополисты…

    Посмотрите на ваши “пиары” – они нацелены на посадку на иглу от Ti и никакого развития :p
    Общество потребления ESP :)
     
  7. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.391
    Симпатии:
    1.271
    На счет ваших соображений про использование старых модемов – куда деваются снятые с производства 2G модемы?
    upload_2019-3-10_12-36-7.png

    Берем компрессор Atlas Copco. “В нагрузку” в нем установлен 2G GSM модем, даже если вы его не заказывали. Если хотите получить компрессор без него, то надо специально оповещать и договариваться при заказе (поставщик выдернет его :) ). Можно его выдернуть и самому – на работу он не влияет, местоположение его работы производитель не узнает и к вам не придет навязчивое сервисное обслуживание (только если вы сами запросите его). Стоит данный стукачок-модем нуль. Если он вам нужен, то по запросу при заказе ТО его заново бесплатно установят.
    В комплект входит старый 2G модем с поддержкой LUA, сим карта Vodafone с оплаченным обслуживанием по всему миру, антенна и БП.
    Сам модем уже давно снят с производства... Раритет. ПО,SDK к нему ныне не поддерживается.
    upload_2019-3-10_12-40-37.png
    >ati
    Sierra Wireless
    FXT009 Product
    OK

    В модеме стоит платка расширения Ethernet на дедушке ESN28J60.
    upload_2019-3-10_12-38-55.png
    При включении модем сразу стучит во все дыры UDP пакетами…
     

Поделиться этой страницей