Pull to refresh

Comments 63

Хорошая идея. А светом не дешевле/проще?
Как раз это была первая идея. Но тут сразу выяснился ряд проблем: только смартфон, ПК неудобно подносить к датчику. Вопрос с частотой, с которой я смогу «моргать» cancas'ом в разных браузерах и разной производительности железа. Получиться ли выжать хотя бы стабильные 10 Гц? Думал и «фонарик» использовать, но это уже приложение и я не уверен, что у всех телефонов он гарантирует хоть какую то стабильность времени включения / выключения. К тому же, это решение дороже, как ни странно… Если бы на телефонах не умер ИК порт, то и проблемы не было.
ИК-порт попадается, но всё реже.
Почему решение со светом дороже? Для этого всего и нужно, что фототранзистор да один свободный порт на контроллере.
Я цену считал где то месяца 3 назад. До статьи руки недавно дошли, в перерывах «пока компилируется». Электретный микрофон и ОУ дешевле вышли. И еще один момент. Для фотоприемника желателен коллиматор, пусть и простое, но дополнительное конструктивное решение. Микрофон не так требователен к месту расположения. И как ответили ниже: проще в использовании.
Можно же взять приемник типа TSOP, линза на корпусе, внутри сразу АРУ и детектор несущей, сигнал генерить так же, на звуковом канале, передавать светодиодом, воткнутым в аудиоджек.
Так в том и фишка, чтобы ничего никуда не втыкать. В противном случае проще использовать ИК-порт или вообще адаптер USB-UART.
Можно же взять приемник типа TSOP, линза на корпусе, внутри сразу АРУ и детектор несущей,

А можно пример такого приемника?

О, как оказалось у меня он есть)
Спасибо

Инфракрасным. Причем связь можно двустороннюю организовать. Это потребует правда небольшой аппаратной приставки — фототранзистора и ИК светодиода в разъём 3.5. Будет больше похоже на затычку.
Дешевле и проще. А вот для пользователя сложней, придется смартфон экраном прижимать к определенному месту прибора.
Есть детские игрушки — Покибот (пример). Управление в приложении реализовано как раз таким образом :)
Забавно. Прямо несколько минут назад прочитал статью «Кнопка Amazon Dash: ретроспектива» — habr.com/ru/post/468913
И в данном устройстве работает тот же принцип передачи конфигурации.
Всё придумано до нас :(
Спасибо за информацию. Интересная статья.
Я в случаях, когда девайс требует редкой настойки, вывожу вход/выход USART TTL и общий/питание на 4-контактный разъем, и на время настройки подключаю к нему Bluetooth модуль, после чего можно работать через терминальную программу на смартфоне. Но это решение для себя, не уверен, что оно подойдет простому юзеру.

Проблема в том, что как только появляется канал связи с устройством и разрабатываются соответствующие протоколы и реализации, следующим вопрос будет: "ОК, параметры программировать можем. Но теперь хотим иметь возможность передавать информацию и в обратном направлении". И во многих случаях это приводит к полной переработке интерфейса.


В вашем устройстве может произойти то же самое: пока 4-х семисегментников достаточно, но микроконтроллеры дешевеют, памяти в них полно, так почему бы дать возможность пользователю увидеть больше, чем показывают ваши светодиоды? Например смотреть все измерения одновременно, записывать логи на компьютере и т.д.


Лично я закладываю в свои изделия такое:


  • параметры пишутся во внешнюю EEPROM типа 24LC в DIPовском корпусе на панельке. Если надо перенести их на другое устройство/плату из-за неисправности или еще — просто выковыриваешь и вставляешь в другую плату. Массово программировать можно на программаторе.
  • Для телефонов будет BT модуль (опциональный) с приложением. Позволит как программировать параметры, так и наблюдать за работой изделия в реальном времени. Протокол там простой последовательный, так что любой микроконтроллер справится.
Чтобы выковырять и вставить надо разобрать полностью устройство и получить доступ к внутренностям. Это точно для простых пользователей? EEROM в DIP-корпусе да ещё с панелькой по нынешним меркам занимает чудовищно много времени.

Я видел такие решения довольно часто. EEPROM может находиться под крышечкой.

Черт, опечатался. То что времени на разборку устройства много надо, там же сама микросхема с панелькой много места занимает, особенно по высоте. Всякие там накладные выключатели и прочее в пролёте. А ещё попробуй выковырять тот чип без практики так чтобы не погнуть выводы… это решение для профессионалов, и то они тратить время на такую ерунду не будут — оставят внешний интерфейс и просто будут подходить к девайсу и «прошивать его» подключаясь к этому интерфейсу — минимум действий, минимум времени. На счетчиках электроэнергии примерно так и сделано — интерфейс оптический.

В обратном направлении можно тоже звуком передавать. Пищалки стоят ещё дешевле микрофонов, с генерацией звука любой микроконтроллер справится.
Такой способ использует, например, LG в своей бытовой технике.

UFO just landed and posted this here

Для флешки нужно на контроллере файловую систему поднимать. А это очень много кода для PICа.

UFO just landed and posted this here

Я не знаю. Поэтому в своих изделиях заложил коннектор для MicroSD карт(благо в ARMы простенький файловый стек легко входит), но вряд-ли SD карта будет использоваться для параметров, скорей всего для логов или обновления прошивки.
В одном изделии, например, у меня стоит речевой информатор, поэтому на карте хранятся wav файлы с именами 1_ru.wav, 2_ru.wav и т.д. в которых записаны слова "первый", "второй" и т.д. Нетрудно догадаться, что можно сделать _en файлы и провести интернационализацию. Ну а кто хочет, может перезаписать вообще свои образцы голоса.


PS, кстати, не стоит забывать достоинство этого метода в том, что все параметры можно настроить дома или в офисе в удобном, теплом месте, а на (холодном/темном/труднодоступном) объекте просто вставить нужную карту/флешку/EEPROMку без возни с кнопками и необходимости брать с собой инструкцию.

WiFi + WEB – стрельба из пушки по воробьям и махровая ардуринщина.

а причем тут адурина? можно и без нее.


Понижается надежность работы, как из-за усложнения прошивки, так и возросшей чувствительностью к ЭМП.

Ну с прошивкой бог с ней, сложнее, от прямоты рук программиста больше зависит. Но чувствительность к эмп? Это что ж за условия такие, в которых девайсина работает?

1. Конечно можно без нее. Это метафора о топорном, прямолинейном решении, отлично подходящем для хобби, но не для производства.
2. Повышение сложности ПО ведет к повышению вероятности ошибок. От этого никуда не деться. Понятно, что wifi стек с 0 никто не будет писать, а готовые библиотеки не гарантируют отсутствия багов.
3. Прибор работает бок о бок с контакторами (коммутация 230V — 400V, 25 — 40А на «фазу»).
Повышение сложности ПО ведет к повышению вероятности ошибок.

Тут, как бы палка о двух концах. WiFi стек вы на своем PICe подымать не будете — такие решения обычно идут вместе со своим контроллером, который будет отвечать за WiFi и WEB и все с ними связанное. В этом случае вам будет удобно разделить функции между двумя контроллерами, оставив PIC управлять ответственными вещами, а на WiFiечный контроллер посадить GUI, параметризацию, управление кнопочками, WEB, логи и т.д. В этом случае софт PICа даже упростится, так как он будет отвечать за меньший функционал, основная функция системы станет надежнее — если с ВаФаем что-то случится, PIC продолжит работать. Это в принципе достаточно распространенная архитектура встраиваемых систем управления — не самая дешевая по железу, зато удобная в разработке — код простой, реалтайм с нереалтаймом разделен физически(поэтому часто в таком случае ОСРВ на управляющем контроллере не нужна вообще), возможность работы командой — одна пилит стек, другая PIC, возможность независимых апгрейдов каждого модуля в отдельности, легкий апгрейд FW, защита от хакерских атак и т.д.

Именно так я поступаю на сложных проектах. В статье идет речь об очень простых устройствах. Которые надо конфигурировать один — два раза. Например, в одном из относительно сложных контроллеров я даже с ESP не стал связываться, сразу заложил модуль на OpenWRT. Жалко, что наш Черный Стриж загнулся, заложил бы его, а не noname из Китая…
Можно и без ардуины, только стоимость решения сразу вырастет до небес. Веб-сервер под АРМ, интерфейс настройки, все необходимые скрипты сами писать будете? И сколько на это уйдёт времени?
Веб-сервер под АРМ, интерфейс настройки, все необходимые скрипты сами писать будете?

Зачем на арм? речь идет о копеечных esp8266/32, которые вполне себе тянут простейшие http сервера. А скрипты чего их писать то? одна страничка с настройками, и ничего лишнего.


И сколько на это уйдёт времени?

https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/examples/protocols/http_server

Так там и есть ARM ядро. Ардуино-подход как раз и предполагает взять всё готовое и добавить сверху своих связующих соплей. А тут вам надо будет реализовать серверную часть сайта, как минимум.
Так там и есть ARM ядро.

Пишут что вот это внутрях:
L106 32-bit RISC microprocessor core based on the Tensilica Xtensa Diamond Standard 106Micro running at 80 MHz.


А тут вам надо будет реализовать серверную часть сайта, как минимум.

Ага, понятно, по ссылкам не ходим и не читаем. Вот например http сервер, поставляется прям вместе с ESP-IDF от espressif:
https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/protocols/esp_http_server.html
Осталось только прикрутить к нему обработчики и свою страницу. Это день-два, по первой может неделя, пока с апи разберешся.

в качестве варианта идеи пульт от теливизора? они есть у каждого. да там свой головняк со стандартами кодов сигналов но можно подумать…
И с инструкцией и обратной связью… Не будет пользователь вбивать 20 / 30 байт с пульта, даже если программа — конфигуратор отобразит последовательность. Я этот тип отношу к типу 2, рассмотренному в статье.
Выскажу свое скромное мнение.

Техническая кривизна не давала покоя. Для того, чтобы записать несколько байт в EEPROM городить огород с таким обширным стеком протоколов нерационально.


А зачем вам САМОМУ городить стек протоколов? Есть же готовые решения. И стоят они не дороже, чем ваши доработки по звуку.

Ваша идея со звуком — требует смартфона и спец. приложения.
Смартфон и так есть у всех (как вы сами описали тут). Это плюс. А спецприложение это минус. На все случаи жизни его не сделаешь.

Так почему не нравится «WiFi + WEB»?

Стоимость контроллера ESP8266 — около 100руб. Это очень дешево.

Как показала моя разработка (см. мои статьи о ShIoTiny или сайт) — на нем можно сделать развитый интерфейс практически с любой степенью удобства.

Мой редактор схем не заточен для мобильников. Но сделать отдельную страницу ввода параметров, доступную пользователю — не проблема. И заточить ее под мобильник тоже не трудно.

В общем, я думаю, что не надо плодить сущности. Надо по максимуму использовать то, что есть и по минимуму требовать от пользователя установки дополнительного ПО на смартфон.

Кстати, ваша идея — конфиг устройств с помощью звука — скорее всего очень подойдёт для подводных устройств. Звук в воде распространяется хорошо, а вот свет не всегда — мутная вода. Радиоволны тоже под водой не хотят распространяться.

Отлично, что Вы мне написали. Если честно, аналог Вашего контроллера у меня лежит в столе более 5 лет. Только предназначался он немного для другой цели. Не буду голословным:
image
и обратная сторона:
image
Плата даже переехала со мной из Подмосковья в Минск, но все руки никак не дойдут. Собрана на одной из первых ESPшек. Это чисто «для себяйка». Собрана наколенным методом еще до доступных PCB из Китая. Так что с этим решением я хорошо знаком и в статье его отметил как «стрельба из пушки по воробьям». Теперь по существу: Цена. Стоимость микрофона — 6 рублей, ОУ — чуть больше рубля (розница на известной Китайской торговой площадке). Еще с пяток пассивных компонентов. 10 рублей против 100. Но это не самое важное. На первую фотографию случайно попал кандидат AC-DC преобразователя. Заявленная мощность — 5В x 500мА, прототип устройства, для которого я планирую использовать звуковой загрузчик, в пике потребляет 50мА по 5V DC. На сколько я помню, ESPшке надо до 800мА (3.3V) в пике. То есть по источнику я сразу пролетаю + DC/DC 5->3.3. Это большие габариты, следовательно не укладываюсь в корпус. Температурный диапазон -40 +80. WiFi контроллер на это не рассчитан, хотя подобная плата на ESP у меня стоит в «скважинном домике» и прекрасно работает почти 5 лет. Но там температура ниже +7 не опускается. Как раз одна из задач «скважинного контроллера». Про приложение. Я как раз написал, что не требуется специализированного приложения. Достаточно WEB страницы. В прототипе пока генерируется Пайтоновским скриптом. Звуковой файл можно записать хоть на диктофон, компьютер и телефон не нужны. Просто у Вашего и моего контроллера абсолютно разные применения. Вы сделали универсальное программируемое реле, а у меня прибор для конкретной одной задачи. Кстати, подобный Вашему контроллер я делал еще на исходе нулевых. У него не было проблем с обратными связями, допускалось «монтажное или», которое разрешалось или запрещалось пользователем. Уперся как раз в GUI. Лучшее, что мог тогда придумать — трансляция KiCad нетлиста в прошивку симулятора схемы. Но это решение имеет много ограничений. Отладка в реальном времени неудобна, приходится часть параметров добавлять в промежуточном файле. По этому хотел спросить: Вы сами писали редактор, или брали готовое решение? Если сами — будите публиковать или продавать исходники?
На сколько я помню, ESPшке надо до 800мА (3.3V) в пике. То есть по источнику я сразу пролетаю + DC/DC 5->3.3.


Вот этим ESP питается www.chipdip.ru/product/ams1117-3.3
Если у вас такие же платы как на фото — то спокойно на них умещается. Или у вас настолько жесткие габариты?

Просто у Вашего и моего контроллера абсолютно разные применения. Вы сделали универсальное программируемое реле, а у меня прибор для конкретной одной задачи.


Согласен. Просто надоело мне решать «простые задачи» долго) Но у вас, как я понял, главный критерий — минимизация цены.

Звуковой файл можно записать хоть на диктофон, компьютер и телефон не нужны.


А как вы убедитесь, что контроллер понял прошивку правильно? Без ошибок принял новые параметры? Контрольная сумма?

По этому хотел спросить: Вы сами писали редактор, или брали готовое решение? Если сами — будите публиковать или продавать исходники?


Редактор писал сам на базе jquery и других библиотек. Но исходники по некоторым причинам отдать или продать (надеюсь, что пока) не могу.
Попробую ответить (немного привяжу характеристики текущего проекта):
1. Питание. Даже такой линейный преобразователь занимает достаточно места на плате. Плюс надо отводить (5-3.3)*0.8 = 1.36 Вт тепла в пике. Ладно, соединим с «земляной» заливкой. Микрофон по площади занимает меньше. Хуже, что AC/DC тоже меняется. Как по габаритам, так и по цене. На Али подходящий стоит уже не 50, а 140 рублей. Сравнимо со стоимостью ESP. И в корпус уже не влезает… Да, габариты жесткие. Размер как 2 однофазных автомата.
2. Да, минимизация цены. Сложные задачи я постоянно решаю на основной работе, в том числе и Xtensa приходится дебагировать. Иногда хочется чего то простого, но элегантного, решающего конкретные проблемы, с которыми столкнулся лично. Цена тут, скорее, вызов для себя.
3. Контроль ошибок? Диктофон, конечно, крайний случай, но если на приборной панели светодиод еще моргает — воспроизвести запись сначала. Контрольная сумма — само собой! И не на все данные, а на сегменты. Если сегмент корректный, прибор его игнорирует при повторной передаче.
Температурный диапазон -40 +80. WiFi контроллер на это не рассчитан

лист 2 esp8266ex datasheet:
1.2. Specifications
Table 1-1. Specifications

Operating Temperature Range –40°C ~ 125°C
...


А вот сами esp-07 уже от -20 до +85. И бяка ограничивающая температуру применения скорее всего — кварцевый резонатор. Собственно вопрос, а у Вас пик16 от чего тактируется?

Внутренний RC. Погрешность по частоте +-5% для конкретного контроллера не важна. Наличие встроенного датчика температуры позволяет выполнять подстройку частоты «на лету».
Внутренний RC.

Нет кварца — нет проблем :)
Кстати вспомнилось, работающая esp8266/32 греется, по ощущениям градусов на 10 минимум, так что думаю модуль в закрытом пластиковом корпусе вполне может и при -40 снаружи нормально работать.
Я совсем не в теме пока.
Но спрошу — модуль Bluetooth сильно дороже микрофона? Или сложнее в программировании?
«Спарить» устройство со смартфоном большинство сумеет, я думаю (наушники же подключают).
И с обратной связью легче. И к расстоянию меньше требований.

Промышленные, например Microchipовские BT модули стоят 6-10 евро. Микрофон с усилителем можно намного дешевле сделать.

Ого. Просто на Али видел, к примеру:
ESP32 ESP-32 Development Board Wireless WiFi Bluetooth Dual Core CP2104 Filters Power Module 2.4GHz RF for Arduino Nodemcu

Introduction:
ESP32 is already integrated antenna and RF balun, power amplifier, low-noise amplifiers, filters,
and power management module. The entire solution takes up the least amount of printed circuit board area.
This board is used with 2.4 GHz dual-mode Wi-Fi and Bluetooth chips by TSMC 40nm low power technology, power and RF properties best, which is safe, reliable, and scalable to a variety of applications.

$4 + доставка $2
И тут уже и BT, и WiFi…
Впрочем, я понимаю, что в «промышленном исполнении» будут сильно другие цены.

Не, ну в принципе вы правы. Модули на ESP32 сильно дешевле — 3-5 евро, даже в более-менее промышленном виде.

А зачем для модуля, который используется раз в год «промышленное исполнение»?

Я сильно сомневаюсь, что описанные устройства типа «реле времени» сделаны именно на «промышленных» элементах.

Можно вообще WiFi или BT модуль сделать отключаемым кнопкой. Подошел со смартфоном, нажал кнопку (включил WiFI или BT модуль), зашел на веб или в программу-конфигуратор, настроил, нажал кнопку (выключил WiFI или BT модуль). Все.

Про то, что устройство с wifi или BT будет «менее помехозащищенным» я вообще не понял. С чего бы?
А зачем для модуля, который используется раз в год «промышленное исполнение»?

"Промышленное исполнение" — это, в понимании разработчика, не только условия эксплуатации, а более комплексная характеристика, которая включает в себя:


  • наличие развитой поддержки от производителя и гарантии
  • повторяемое качество, отсутствие брака
  • возможность покупать данное изделие в количествах, нужных для серийного производства через надежных дистрибьюторов
  • гарантия того, что данное изделие будет производиться в этом виде хотя бы пару лет
  • наличие достаточных средств разработки, отладки и тестирования, которые дадут конструктору возможность гарантировать, что данное изделие будет надежно и без глюков работать после того, как его продадут.
  • в некоторых случаях можно добавить наличие second-source

Ну что-то такое.

Понятно что вы ищете и технически решение приемлемое. Спасибо за статью. Но хочу обратить внимание на не технический вопрос. Вам комфортно было бы жить в доме, где каждое устройство от розетки до выключателя и от лампочки до микроволновки обладают микрофоном и связью с внешним миром одновременно? Все они от разных производителей из разных стран и с закрытым кодом. Вот я упомянутую выше кнопку от Амазона не хотел бы иметь дома т. к. от этого бренда в первую очередь можно ожидать нововведений типа целевой рекламы по ключевым словам, прозвучавшим в помещении. Не говоря уже о других способах использования аудиоинформации, которые вы легко можете себе представить. И даже если не злобные производители, то всегда есть злобные хакеры. Конкретно вы можете решить свои задачи и через аудио, но массовым явлением это не станет никогда. Надеюсь.

Стараюсь придерживаться правила «критикуешь — предлагай». Первый вариант: Гораздо меньше опасений вызывает передача световых сигналов. Используйте мигание экрана смартфона и фототранзистор в 5 мм корпусе (чтобы встроенная линза собирала побольше света) на устройстве. Такое решение вроде уже применялось. Обратная связь через светодиод на устройстве и переднюю камеру на смартфоне. Сложное приложение? Из пушки по воробьям? Да! А что делать если у вас есть только пушка?

Второй вариант: RFID-образный обмен. Устройство просто слушает спиральную антенну, а для ответа замыкает ее ключом. Все идет к тому, что эта функция станет стандартной в смартфонах и скорее всего, что бы мы не придумали из костылей, со временем именно она станет стандартом.

За поднятую тему спасибо. Проблема программирования простых устройств действительно существует. Обязательно буду следить за обсуждением и вообще за вашими статьями.
Спасибо, что подняли интересную тему. По поводу микрофонов — как раз я рассматриваю класс устройств, где нет никаких других каналов связи. Ну если совсем заморочиться, то решается очень просто. Как на колонке от Google. Физический разрыв цепи от микрофона. Проверку такого решения сможет выполнить любой начинающий радиолюбитель. Думаю, если выключатель будет и будет фейковым — по репутации любого производителя будет нанесен жесточайший урон. Кроме того, мы постоянно ходим с нашими любимыми «прослушками» — мобильными телефонами. Пока никто не отказывается. Даже если не Google или Apple, то вредоносный софт достаточно легко сможет активировать прослушку. И микрофон физически не отключается. Да и не один он в телефоне. Но за замечание ОГРОМНОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО. С точки зрения паранойи не рассматривал. Если мои изделия и дойдут хоть до мелкосерийного производства, обязательно предусмотрю такой выключатель!
По поводу света. Как раз это был первый вариант исполнения. Я не уверен, что любой телефон сможет моргать экраном с частотой более 10Гц. Даже если 20Гц, давайте посчитаем: Нам нужен самосинхронный код. Берем манчестер. На один бит нам надо 2 периода сигнала. То есть, в лучшем случае получаем канал со скоростью 10бод. Для передачи 16 байт нам потребуется 12.8 секунд. В моем прототипе, который ограничен ну очень медленным по нашим временам контроллером, при использовании кода 1/2 2/1, не знаю его правильное название, но на 1 бит надо 3 интервала сигнала, я получил скорость 4 байта / сек или 32 бода. Это только на прототипе. 300 бод — вполне достижимая скорость, умел бы мой контроллер аппаратно умножать… То есть для передачи 16 байт надо уже 4 секунды. Плюс вопросы засветки (сталкивался с такой проблемой) или перекрытие приемного окошка проводами, например. И это решение — дороже. К тому же с ПК или ноутбука сложно передать данные. Да, такое решение было описано еще в ЮТ, вроде в 92 году. Приставка для управления нагрузками без необходимости разбора ПК. На экран монитора устанавливалось N фотоприемников и простая программа на Бейсике, подсвечивающая экран в нужном месте.
RFID — возможно, когда он будет в каждом утюге и будет доступ к модулю из WEB приложения…
Вы правы. Физическое отключение микрофона дает спокойствие. Например, на моем нетбуке камера физически закрывается шторкой и это действительно убеждает меня что камера ничего не подсматривает. Хорошее решение.

Справедливости ради замечу, что скорость перерисовки экрана вы явно занизили. Все не так плохо :) Скорость может быть гораздо больше.

Но давайте оставим оптику и посмотрим внимательнее на звук и RFID. Не настаиваю, но предлагаю рассмотреть варианты. Во-первых антенну передатчика можно подключить к звуковому разъему смартфона и получить полудуплексную связь. Стоимость аудиоджека и кусочка провода копеечная. Можно прилагать к каждому устройству.

А во-вторых почему бы не отказаться от микрофона или антенны вообще и соединять аудиовыход смартфона с устройством напрямую обычным аудиокабелем? Хотите чтобы пользователю не нужно было ничего искать? Припаяйте провод 10 см к устройству, а на другой конец аудиоразъем и сложите в нишу корпуса. Предсказуемое качество канала, не нужна тишина на время прошивки и т. д. Как следствие, намного бОльшая скорость. А звуковой сигнал, как вы гениально предложили, генерируется скриптом с веб-страницы.

Кроме того, хочу обратить внимание насколько важна обратная связь. Пока у вас производится одно устройство проблемы не заметите. Но появится другое и пользователи тут же начнут заходить на неправильную веб-страницу и пытаться запрограммировать устройство не предназначенными для него настройками. Конечно устройство отвергнет такую попытку, но отреагирует мигающим светодиодом т. к. не сможет отличить такую ситуацию от ошибки передачи. А пользователь после трех попыток будет уже сильно нервничать и не понимать что происходит. Лучше бы сразу закладывать возможность опроса устройства на предмет его модели, а еще лучше на скачивание всех текущих настроек и отражать их на в форме веб-страницы в качестве исходных.
В последний раз когда у меня торчал кусочек провода с компьютера(может быть любая техника) даже отключеного от сети во время грозы он погорел. Наводка на этот самый проводок. Поэтому, скрученные проводки — это до первой грозы. Или защиту от грозовых разрядов надо ставить. Иначе первая сильная гроза, неудачный момент и погорят девайсы. Тогда ещё погорела розетка — был четкий след с фазы на контакт заземления.
Вы Московские карты для проезда в метро видели? Они не выгорают во время грозы. Это потому, что защита от наводок делается совсем просто. Диодная сборка вроде BAT54S, крайние выводы на землю и питание, средний на сигнал. Но аналогичные диоды уже есть в микроконтроллере. Внешние могут понадобиться только если их не хватает, в чем я сомневаюсь.
Не выгорают, потому что антенна там используется замкнутая. Диодная защита не всегда помогает диоды сгорают после того как сгорела вся схема, или по крайней мере просто сгорают так что их приходится менять(и то и то на практике встречалось). И сбрасывать лишний ток на шину питания тоже не всегда хороший выход — актуально только когда минимальное потребление схемой тока всегда существенно больше чем предполагаемый импульс(сумма по всем входам) приходящий на вход — т.е. в реальных схемах это микроамперы и эти диоды ставятся совсем от другой угрозы — тиристорного эффекта паразитных структур на кристалле микросхемы сделанной по технологии CMOS и сходных, который происходит при токе через встроенные(на самом деле это паразитные) защитные диоды >2мА а на статике или близком грозовом разряде такое может с лёгкостью произойти. Если это происходит, то паразитный тиристор защелкивается и соединяет локальные шины питания в КЗ, выжигая часть кристалла если позволяет источник питания — ток больше ничем не ограничен. А если ток ограничить, то кристалл станет работоспособным только после того как снять с него напряжение.
Развивая мысль вашу… Можно было простo miniJack поставить разъем, и передавать можно было бы с любого смартфона(кроме последних айфонов) и ноутбуков.
Этот вариант я тоже рассматривал. Много проще в реализации, б'ольшие скорости, но нужен кабель. Как раз микрофон — замена кабеля.
Рассматривался ли вариант с NFC? Достаточно удобно, компоненты дешёвые и кол-во смартфонов с NFC растёт постоянно?
Да, но пока вижу 2 проблемы: NFC есть не в каждом смартфоне и необходимость разработки / публикации минимум для 2х мобильных платформ.

slowpoke Если вы рассматриваете вариант со звуком – почему бы не попробовать тоновые (DTMF) сигналы?
Есть в любом цифровом телефоне, даже проводном – всегда можно набрать команды руками, есть готовые приложения и онлайн-генераторы тонов, можно генерировать своим приложением или на сайте, где можно сделать конфигуратор и выбор из готовых вариантов/шаблонов.
В инете куча статей как дешифровать (одна из первых – на Хабре https://m.habr.com/ru/post/161993/), есть аппаратные декодеры.

Тоновое декодирование более ресурсоёмкое. требует достаточно быстрого АЦП и математики в виде БПФ. Тоесть контроллер, у которого тактовая частота 128кГц будет в пролёте. Или контроллер без поддержки аппаратного умножения…
Технически, с более-менее быстрым АЦП — можно использовать не совсем БПФ, но детектировать частоту на таймерах. Хотя на таких частотах будет действительно сложно без предусилителя микрофона, либо встроеного аналогового компаратора. Но сигнал должен быть без шума.
Всё гораздо проще. АЦП в этом деле вообще по сути не нужен. Ну, однобтный разве что. Шум до какого-то предела мешать не будет, и вообще даже математики адской не нужно. Ведь исходный сигнал можно описать лишь одним битом, амплитуда информации не несёт — только фронты сигнала и их временные характеристики. Берём оцифрованный сигнал и перемножаем на заранее просчитанные шаблоны, какой совпадёт с максимальной долей(но выше 80-85%) — значит поданный на вход набор частот соответствует характеристикам с которыми был просчитан шаблон. Как это в математике называется? Корреляционная функция. А поскольку сигнал однобитный, то и работать надо как с логикой. Даже несложный контроллер справится с перемножением небольших двоичных последовательностей для 16...64 вариантов кодирования символов в отведённое время(например за 1мс).
Аппаратный декодер тоже стоит денег, а использован будет, судя по описанию, один раз.
Обычная ЧМ в данном случае ничем не хуже.
Only those users with full accounts are able to leave comments. Log in, please.