Pull to refresh
406
-16
Роман @Ariman

ML-исследователь

Send message
Раньше, вроде как, эпоксидкой заливали устройства. До того, как печатные платы появились. Неремонтопригодно, зато на века.
Ну а почему бы и не STM32? У него есть объективные преимущества — встроенные ЦАП и АЦП с очень удобными фичами (возможность задать оффсет сигнала, инжектированные каналы, scan-режим — это из того, что используется в девайсе), большое количество удобных таймеров, включая системный, гибкий вочдог с ртц.
При этом данный чип стоил 19-20 рублей.
Какой бы предложили вы?
Я же специально для вас оставил ремарку в статье
>Если вы не прочь потратить это время на возню с хлорным железом, то можно развести описанную схему на небольшой плате и пропустить следующие пункты.

Прошло то время, когда я делал платы ЛУТом и резистом, я зарекся брать хлорид в руки. Теперь — только заказные. Но для игрушки я заказывать плату не собирался и обошелся dead bug методом.
Спасибо, я еще помню закон Ома. Но я вроде как еще в статье сказал, что не уверен в значении резистора, который впаял, поэтому мне по-прежнему интересно, насколько же упадет потребление.
Каким образом устройство «будет жить месяцами», если сейчас оно потребляет порядка 750 мкА? Ну станет потреблять в лучшем случае 625. А если я взял тот резистор, который и собирался, то уменьшится не на 125, а всего на 60 мкА и разницы почти не будет.

Сигнал симметричный на определенном интервале времени, если взять интервал меньше, запросто можно получить «перевес».
Отчасти, может, и можно, ценой амплитуды сигнала — то есть, наверное, можно сделать фильтр, который сгладит ее пики.
Но что делать со впадинами?) Я имею в виду, что до 1 КГц и после 6 КГц она очень сильно спадает, никакие фильтры не заставят пищалку воспроизводить звук с нормальной громкостью на 500 Гц или на 8 КГц.
Да, питать потенциометр точно нужно было от GPIO. В принципе это еще возможно пофиксить — провод питания к нему идет достаточно близко к поверхности эпоксидки, можно перерезать, а вместо него подключить один свободный с отладочного разъема.
Интересно, насколько упадет потребление.
О движковых думал, да, но что-то мне показалось, что будет еще менее удобно, чем с крутилкой — очень уж он короткий.

В данном случае это не важно, не уплывут они настолько, чтобы это было критично. Да и просто так вычислять среднее не получится, где гарантия, что в данный момент нет фонового шума?
И что сие должно символизировать?
Ну так в данном-то случае у меня на выходе стоят пищалки, что мне на них ЦАПом выводить — синус или семплы не шибко с них звучат.
Я в первой версии девайса генерил звук гитарной струны известным алгоритмом и выводил его через ЦАП на пищалки, результат меня не порадовал (хотя если выводить на динамик, то звучит нормально).
Поэтому я остановился на прямоугольном сигнале — он богат гармониками, да и пищалки в таком режиме звучат намного громче.
Вот и все плюсы, они продиктованы исключительно устройством вывода звука.
Действительно, там же микрофон для этого — в статье описано, как сигнал с него управляет огибающей звука.
Некую UHU Plus SCHNELLFEST, на хрупкость не проверял, но обещают 130 кг на отрыв. Склонен верить, т.к. видел склеенную ей металлическую стойку в магазине, где мне ее продали)
Да, сам думал про NFC, хотя и создает определенные препятствия (да и будет ли меньше потреблять, чем BT?)
А что за «wearable mesh»?
Не придется, если подумать над потреблением.
Я говорю о следующем — да, проект отличный, в том плане, что это не очередная ардуина, а доведенное до финала электронное устройство. Но теперь пришло время подумать о некоторых улучшениях — ведь обычных часов с BT хватает, особенно тех, что живут меньше дня.
Понятное дело — меняем дисплей на шарповский, сразу избавляемся от подсветки и резко снижаем потребление. Выбираем самый низкопотребляющй контроллер, желательно со встроенными RTC, тоже понятно.
И приходим к проблеме — на данном этапе при правильном выборе элементов и грамотно составленной схеме, часы почти не будут потреблять и-таки смогут неделями жить от одной литиевой батареи. Ничего менять не придется.
Но остается нерешенным вопрос связи с телефоном — именно добавление BT-модуля невероятно повышает потребление. Вот задача, которую надо решить: связь с телефоном без адского потребления.
Так это ж DIY, с каких пор DIY-проекты меряются с позиции «потратить N рублей и ничего не делать»? Если мне нужен Pebble, я пойду и куплю Pebble.
А если мне нужно что-то чего в Pebble нет (в том числе и самого процесса разработки!) — то покупка не поможет.
Хм, на сайте одно из требований к стартапу звучит как «высокий потенциал роста капитализации стартапа», то есть «акселерацию» проходят только те стартапы, которые вот-вот принесут высокие прибыли? Не то чтобы я не понимал позицию «акселератора», но в то же время, если разработчики на сто процентов уверены в том, что проект выстрелит огромными деньгами сразу после выхода, то зачем им акселератор?

Меня вот что беспокоит — кикстартер, например, дает возможность людям (резидентам тех стран, с которыми он сотрудничает, не нашим) проверять свои идеи с минимальными затратами — пусть даже на первый взгляд не самые лучшие, либо не самые массовые.
Можно вывести проект на кикстартер буквально из гаража — ну провалится и ладно, выведу второй.
Мы же лишены такой возможности. Выход на краудфандинг для нас сопряжен с поиском посредник и серьезной тратой денег. Поэтому уже не получится проверить свои идеи, если не уверен хотя бы на 80 процентов в ее успехе. У меня, допустим, есть несколько идей, но я не рискну вот так брать и выводить их на КС, буду мусолить одну, пока не доведу до вылизанного прототипа, и то, потом еще сто раз подумаю.

Вот этого мне не хватает. Не очередных обычных инвесторов, которые готовы вложить в проект с «высоким потенциалом роста капитализации» — таких полно. А системы, которая позволит мне с минимальными затратами проверять свои идеи. Я разговаривал с другими инженерами, многие со мной согласны — не будь у нас такого препятствия по выходу на краудфандинговые платформы (наш бумстартер предлагать несерьезно, достаточно посмотреть на «выстрелившие» там проекты и на собранные суммы), мы бы могли тестировать намного больше наших идей, а значит, потенциально обеспечить большое количество оригинальных продуктов.
Посмотрите на проект на кикстартере, светодиод, вставляющийся в USB. С нулевой себестоимостью, практически. С нулевой сложностью.
Он собрал сотни тысяч долларов, значит — востребованный продукт.
Какой из акселераторов у нас бы такой пропустил?
Ну так то вибромотор, человек же вибратор просит)
Еще как напрягает, вы что. Разумеется, я бы предпочел телефон, который надо было бы заряжать раз в месяц, а не раз в день.
И потом, одно дело заряжать каждый день телефон, другое — часы. Часы можно спроектировать так, что заряжать придется максимум раз в неделю. То есть снизить среднее потребление до таких величин, что саморазряд аккумуляторов будет очень заметен.
Неплохо. Но, думаю, литий-ион совсем не подходит для задач такого типа.
Конечно, очень бы хотелось иметь перезаряжаемые часы, но уж слишком высоки его токи саморазряда и, главное — скорость деградации. Даже если он отключен от всего и лежит на полке, он теряет заряд и емкость.

Идеальное решение для умных часов — литиевая батарейка. Они могут лет 10 лежать, не деградируют и почти не разряжаются сами.
А расскажите подробнее про потребление? «Меньше миллиампера» довольно растяжимое понятие. 0.5мА это тоже меньше миллиампера, но для слип-мода это очень, очень много.
Наверное, нарвусь на минусы, но все же. Объясните мне практическое приложение конкретно этой задачи?
Мне кажется, она очень узко сформулирована и полученный результат (на который потратили три месяца времени суперкомпьютера) не особо применим в реальном мире и, т.к. это просто численное решение, а не аналитический вывод некоего закона, даже не открывает никаких теоретических горизонтов.
Тогда зачем? Кроме как «because we can»?
ОС нужна чтобы код не превращался в, извините, говно.
FreeRTOS дает необходимый минимум, при этом практически не влияя на задержки, самые критичные части могут вообще работать параллельно с системой, она на них не будет иметь влияния. При этом это полноценная ОСРВ, все задержки предсказуемы.
Поверьте, код задач РТОС намного приятнее читать, поддерживать и отлаживать, нежели код, в котором то же самое реализовано своими велосипедами и костылями — а именно переключение между задачами по средством всяких флагов в интерраптах, синхронизация глобальными переменными и прочим.
Главное следите, чтобы не было уязвимостей в вашем сервисе, а то кто-нибудь ломанет и засыплет кормушку доверху семечками)

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity