Да стандартные приложения вообще оч плохо дружат с BT-микрофонами, мне когда-то нужен был диктофон для записи с BT-устройства - замучился перебирать приложения, еле нашёл подходящее. Правда давно это было.
Может действительно что-то своё запилили, но сомневаюсь. ИМХО, просто приложение камеры допилили для работы с HSP/HFP.
"Полный спектр" BT HSP/HFP не тянет, там mSBC кодек, он даёт качество чуть лучше УГ (причем в обе стороны).
А вот почему микрофон в кейсе лучше - мне тоже не понятно. Он же подключен через тот же BT (и точно так же зарезается им по полосе частот).
А ещё непонятно зачем, ведь если в руках всё равно надо какую-то фиговину держать - так телефон же уже есть, и он уже оснащен хорошим, годным микрофоном с полным спектром (уже без кавычек, ибо mSBC его не режет).
Да и человек разговаривающий с телефоном выглядит уже привычно и нормально, а вот разговаривающий с непонятным яйцом - малость странновато)
Примерно так (termux потому что мобила в руках, но работает во всех линуксовидных осях):
Report issues at https://termux.dev/issues ~ $ which sleep /data/data/com.termux/files/usr/bin/sleep ~ $ cat /data/data/com.termux/files/usr/bin/sleep > sleep ~ $ chmod +x sleep ~ $ ./sleep 60& [1] 7678 ~ $ echo test > ./sleep bash: ./sleep: Text file busy ~ $
Но это явно не частый случай, иначе любое обновление используемых библиотек или запущенных демонов заканчивалось бы ошибкой
Выше уже упомянули, что пакетные менеджеры не пишут в исполняющиеся бинари/либы, а создают рядом новые файлы и затем переименовывают/удаляют старые бинари-либы а новые временные файлы переименовывают во имя старых.
При этом открытые дескрипторы (и их ммапы) остаются валидными, но привязанными к старым файлам (которые можно даже удалить, но при этом дисковое пространство освободится только когда последний открытый дескриптор закроется), а вновь запускающиеся процессы будут работать с уже обновлёнными файлами.
А вот что происходит при записи в исполняющийся текстовый файл:
Что тут происходит (лучше в динамике посмотреть самому):
~ $ linenew - это не я набрал, это bash вывел приглашение ~ $ и затем через время скрипт вывел linenew и завершился. Потом я нажал ENTER и bash сообщил что скрипт в фоне завершил работу.
На USB2.0 (и 3.0 по линиям 2.0) работают QC2.0 (аналог PD 2.0 с фиксированными профилями), QC3.0 (аналог PD3.0 PPS с плавным регулированием напряжения), а также всякая проприетарщина. Но они используют не линию CC (её в этих портах ещё не завезли) а линии D+/D-.
Кстати, а есть какие-то протоколы зарядки, которые работают через пары TX/RX от USB3.0?
Единственное что работало на USB2.0 это PD1.0 (ещё более странное недоразумение чем QC1.0):
USB Power Delivery 1.0 был предложен в 2012 году, раньше Quick Charge 1.0. Этот протокол был значительно сложнее всего описанного выше — гаджет и ЗУ общались по линии VCC цифровым кодом частотной модуляцией на частоте 24 МГц. Использовался мало.
Лично мне такие зарядки и устройства не попадались (а QC2.0/3.0 полно). В PD2.0 уже перешли на TypeC и работу по линии CC.
Если мост на двух реле собран - реле похоже имеют несколько контактных групп (минимум по две). Если групп 3 или больше - можно сделать аппаратную электрическую взаимоблокировку (по схеме как у контакторов вспомогательные блок-контакты подключаются в реверсивной схеме, но там по хорошему ещё и механическая взаимоблокировка дополнительно подстраховывает).
В принципе можно блокировку сделать и с двумя контактными группами, но это малость сложнее и требует дополнительных компонентов (прежде всего приходят на ум транзисторные ключи на размыкание питания катушек крест-накрест друг от друга).
Не знаю, то ли мне так не везло, то ли реально так, но в 2/3 случаев если на рейсе со мной такая система есть - она либо глючит, либо вообще не воркает(
Не прекращается а продолжается пока ЭДС аккумулятора не достигнет напряжения окончания заряда (с отсечкой на 5..10% от номинального тока, так что не совсем достигает а приближается). Если по окончании стадии CC снять напряжение зарядки - напряжение холостого хода на АКБ снизится.
Ну и да, и свинец и литий заряжаются одним и тем же CC-CV алгоритмом, просто коэффициенты разные у разной химии
Не сказал бы что снижение порога зарядки АКБ не имеет смысла.
Есть у меня планшетник, я его долгое время как LTE-модем использовал, соответственно он был всё время на зарядке, на 100% (4450mV) и больших циклов не происходило, только небольшой дозаряд временами.
Однажды обнаружил, что АКБ вздулись и выдавили дисплей (благо, не сломав а просто отклеив) - пришлось разбирать и менять батареи.
Во избежание повтора пропатчил ядро и добавил в sysfs настройки vFloat (так называется это напряжение в коде ядра) для зарядных чипов (у MiPad4 на SDM660 их оказалось два, как я понял один отвечает за медленную зарядку от порта, а другой за быструю от БП) и прописал на компе в udev хук который по adb выставлял в sysfs напряжение 3900mV.
После этого зарядка стала останавливаться на 56% (причём со стадией CV (проверял), только держалось напряжение 3900mV а не дикие "родные" 4450mV), а новые батареи до сих пор живы, где-то год в режиме модема точно проработал этот планшетник после замены батарей и настройки).
Причём, что забавно, если подключал заряженный на 100% планшетник - он потихоньку разряжался до 56% и дальше останавливался на этом уровне. Думаю, можно было ставить и 4100..4200mV, не сильно хуже было бы, но я решил поберечь батареи.
Ну и да, когда я хотел взять планшетник с собой - я либо вручную возвращал номинальные 4450mV, либо просто ребутал планшетник и дозаряжал его от БП.
Да не, у меня тоже бывают такие причудливые моменты, к примеру беспроводная клавиатура не желает ни в какую заряжаться от PD-зарядника в мониторе, а от Type-A порта в том же мониторе заряжается.
Предположу, что в ней не провели от разъёма линию CC, а PD зарядники требуют её, и не хотят даже 5V отдавать.
Если (как там говорят) будет попиксельное обновление - перерисовать курсор и фон там где был курсор 75 раз в секунду вряд ли будет дороже чем 10 раз перерисовать весь экран полностью. А выглядеть будет гораздо плавнее.
Если юзать грамотно, с минимумом анимаций и переходов - имхо вполне хорошо будет. Ну и понятно, что такие экраны не про полноэкранное видео и игры.
У коллеги Intune Portal пару раз вайпал данные с рабочего телефона по аналогичной причине, случайная активация экрана в кармане и несколько раз неверно набраный пароль от телефона. Пришлось отучать софт от этой пакости прежде чем ставить.
Да стандартные приложения вообще оч плохо дружат с BT-микрофонами, мне когда-то нужен был диктофон для записи с BT-устройства - замучился перебирать приложения, еле нашёл подходящее. Правда давно это было.
Может действительно что-то своё запилили, но сомневаюсь. ИМХО, просто приложение камеры допилили для работы с HSP/HFP.
"Полный спектр" BT HSP/HFP не тянет, там mSBC кодек, он даёт качество чуть лучше УГ (причем в обе стороны).
А вот почему микрофон в кейсе лучше - мне тоже не понятно. Он же подключен через тот же BT (и точно так же зарезается им по полосе частот).
А ещё непонятно зачем, ведь если в руках всё равно надо какую-то фиговину держать - так телефон же уже есть, и он уже оснащен хорошим, годным микрофоном с полным спектром (уже без кавычек, ибо mSBC его не режет).
Да и человек разговаривающий с телефоном выглядит уже привычно и нормально, а вот разговаривающий с непонятным яйцом - малость странновато)
Будильник не обязательно слышать, есть же всякие часы-браслеты с будильником на вибрации.
Примерно так (termux потому что мобила в руках, но работает во всех линуксовидных осях):
Report issues at https://termux.dev/issues
~ $ which sleep
/data/data/com.termux/files/usr/bin/sleep
~ $ cat /data/data/com.termux/files/usr/bin/sleep > sleep
~ $ chmod +x sleep
~ $ ./sleep 60&
[1] 7678
~ $ echo test > ./sleep
bash: ./sleep: Text file busy
~ $
Выше уже упомянули, что пакетные менеджеры не пишут в исполняющиеся бинари/либы, а создают рядом новые файлы и затем переименовывают/удаляют старые бинари-либы а новые временные файлы переименовывают во имя старых.
При этом открытые дескрипторы (и их ммапы) остаются валидными, но привязанными к старым файлам (которые можно даже удалить, но при этом дисковое пространство освободится только когда последний открытый дескриптор закроется), а вновь запускающиеся процессы будут работать с уже обновлёнными файлами.
А вот что происходит при записи в исполняющийся текстовый файл:
~ $ cat test.sh
#!/usr/bin/env sh
echo line1
sleep 30
~ $ ./test.sh&
[1] 19211
~ $ line1
~ $ echo >> test.sh 'echo linenew'
~ $ cat test.sh
#!/usr/bin/env sh
echo line1
sleep 30
echo linenew
~ $ linenew
[1]+ Done ./test.sh
~ $
Что тут происходит (лучше в динамике посмотреть самому):
~ $ linenew - это не я набрал, это bash вывел приглашение ~ $ и затем через время скрипт вывел linenew и завершился. Потом я нажал ENTER и bash сообщил что скрипт в фоне завершил работу.
Можно грабить корованы?
И что, теперь ходить всем непрокачаными нубасами первоуровневыми?(
Ура-ура, теперь PS5 будет разряжаться и работать медленнее!
Хотя подождите, она же без аккумулятора!
А родителя им предъявить там не надо при этом?
Ну так, на всякий случай, должен же кто-то родительский контроль реализовывать?
И как теперь геймпад выключать? Что, каждый раз батарейки вышелушивать??
Неа.
На USB2.0 (и 3.0 по линиям 2.0) работают QC2.0 (аналог PD 2.0 с фиксированными профилями), QC3.0 (аналог PD3.0 PPS с плавным регулированием напряжения), а также всякая проприетарщина. Но они используют не линию CC (её в этих портах ещё не завезли) а линии D+/D-.
Кстати, а есть какие-то протоколы зарядки, которые работают через пары TX/RX от USB3.0?
Единственное что работало на USB2.0 это PD1.0 (ещё более странное недоразумение чем QC1.0):
Лично мне такие зарядки и устройства не попадались (а QC2.0/3.0 полно). В PD2.0 уже перешли на TypeC и работу по линии CC.
Если мост на двух реле собран - реле похоже имеют несколько контактных групп (минимум по две). Если групп 3 или больше - можно сделать аппаратную электрическую взаимоблокировку (по схеме как у контакторов вспомогательные блок-контакты подключаются в реверсивной схеме, но там по хорошему ещё и механическая взаимоблокировка дополнительно подстраховывает).
В принципе можно блокировку сделать и с двумя контактными группами, но это малость сложнее и требует дополнительных компонентов (прежде всего приходят на ум транзисторные ключи на размыкание питания катушек крест-накрест друг от друга).
TypeB не может поддерживать PD, там нет линии CC.
TypeA кстати тоже, PD водится строго в TypeC-TypeC кабелях.
Не знаю, то ли мне так не везло, то ли реально так, но в 2/3 случаев если на рейсе со мной такая система есть - она либо глючит, либо вообще не воркает(
Если лицензия это товар - её можно продать.
Если лицензия это не товар - её невозможно украсть (и пиратство - не преступление).
О, наконец-то они решили выбросить нафиг эту UWP
Не прекращается а продолжается пока ЭДС аккумулятора не достигнет напряжения окончания заряда (с отсечкой на 5..10% от номинального тока, так что не совсем достигает а приближается). Если по окончании стадии CC снять напряжение зарядки - напряжение холостого хода на АКБ снизится.
Ну и да, и свинец и литий заряжаются одним и тем же CC-CV алгоритмом, просто коэффициенты разные у разной химии
Не сказал бы что снижение порога зарядки АКБ не имеет смысла.
Есть у меня планшетник, я его долгое время как LTE-модем использовал, соответственно он был всё время на зарядке, на 100% (4450mV) и больших циклов не происходило, только небольшой дозаряд временами.
Однажды обнаружил, что АКБ вздулись и выдавили дисплей (благо, не сломав а просто отклеив) - пришлось разбирать и менять батареи.
Во избежание повтора пропатчил ядро и добавил в sysfs настройки vFloat (так называется это напряжение в коде ядра) для зарядных чипов (у MiPad4 на SDM660 их оказалось два, как я понял один отвечает за медленную зарядку от порта, а другой за быструю от БП) и прописал на компе в udev хук который по adb выставлял в sysfs напряжение 3900mV.
После этого зарядка стала останавливаться на 56% (причём со стадией CV (проверял), только держалось напряжение 3900mV а не дикие "родные" 4450mV), а новые батареи до сих пор живы, где-то год в режиме модема точно проработал этот планшетник после замены батарей и настройки).
Причём, что забавно, если подключал заряженный на 100% планшетник - он потихоньку разряжался до 56% и дальше останавливался на этом уровне. Думаю, можно было ставить и 4100..4200mV, не сильно хуже было бы, но я решил поберечь батареи.
Ну и да, когда я хотел взять планшетник с собой - я либо вручную возвращал номинальные 4450mV, либо просто ребутал планшетник и дозаряжал его от БП.
Да не, у меня тоже бывают такие причудливые моменты, к примеру беспроводная клавиатура не желает ни в какую заряжаться от PD-зарядника в мониторе, а от Type-A порта в том же мониторе заряжается.
Предположу, что в ней не провели от разъёма линию CC, а PD зарядники требуют её, и не хотят даже 5V отдавать.
Если (как там говорят) будет попиксельное обновление - перерисовать курсор и фон там где был курсор 75 раз в секунду вряд ли будет дороже чем 10 раз перерисовать весь экран полностью. А выглядеть будет гораздо плавнее.
Если юзать грамотно, с минимумом анимаций и переходов - имхо вполне хорошо будет. Ну и понятно, что такие экраны не про полноэкранное видео и игры.
У коллеги Intune Portal пару раз вайпал данные с рабочего телефона по аналогичной причине, случайная активация экрана в кармане и несколько раз неверно набраный пароль от телефона. Пришлось отучать софт от этой пакости прежде чем ставить.