=AK=

Типовая однополярная схема включения прекрасно работает с частотами до 1 Гц, ошибка на этой частоте всего 0.1% при входном кондере 47 мкФ. А вы на каких частотах rms мерять собираетесь? Микрогерцы?

В честь чего вы так решили? В даташите прямо на первой странице черным по белому написано - однополярное питание, от 4.5 до 5.5 В. Среди трех типовых схем включения fig.9 только одна с двуполярным питанием, а две - с однополярным. Зачем вам двуполярное питание?

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

А вот здесь, например, изолируют фторопластом, и даже лентой фум советуют пользоваться: Изолируем вторичную обмотку фторопластовой лентой толщиной 1 мм, такая изоляция выдерживает не менее 1000 В. Так же дополнительно пропитываем лаком, это еще +600В к изоляции. Если нету фторопластовой ленты, то изолируем обычным сантехническим фумом в 4-6 слоев. Это тот же фторопласт, только 150-200 мкм толщиной.

Ссылка битая. А сам сайт Эфо - помойка, самостоятельно статью найти невозможно. Таких несолидных поставщиков лучше избегать, поскольку бардак в объявлениях и бардак на сайте скорей всего являются отражением неизбывного бардака в самой компании. :)

Можно. Однако проще видео передавать по обычному эзернет кабелю Cat5/Cat6. В нем 4 витых пары, по одной паре передавать видео, оставшиеся 6 проводов использовать как захочется.

Довольно смешно это читать, зная что AllJoyn тоже использует модель клиент-сервер. БАКнет - он старенький, громоздкий и кривой. Зато он уже есть и кое-где применяется, a его опенсорс с либеральной лицензией для разных платформ на Соурсфордже лежит. А AllJoyn будет ли жить или нет - бабушка надвое сказала, особенно учитывая наличие прямого конкурента в виде OIC/IoTivity. Наслушавшись прогнозов, все дружно бросились столбить участки в полях IoT, надеясь на золотые россыпи. Надувают очередной пузырь, а получится как всегда.

Судя по этой реплике, вы совсем не понимаете, что такое БАКнет. В истоках его лежит точно такая же инициатива, как у AllJoyn: объединить в одно целое разнородные устройства разных производителей. Только проявлена эта инициатива была на 25 лет раньше и, соответственно, названа так, как было модно называть что-то новое в то время - "протокол". Сейчас слово "протокол" вышло из моды, поэтому AllJoyn использует то слово, которое модно в настоящий момент, "фреймворк". А по сути это ничем от БАКнета не отличается, БАКнет тоже можно "фреймворком" назвать, если хочется. И перспективы у AllJoyn точно такие же, как у БАКнета, если не хуже.

LiFePO4 не взрываются. В Новосибирске построен крупный завод Лиотех по их производству. На мелкие литиевые аккумуляторы, действительно, часто ставят контроллеры заряда, но это не универсальное решение, а заплатка, придуманная для ноутбуков и перекочевавшая оттуда даже в китайские электровелосипеды. Для больших аккумуляторов такое решение теряет смысл.

Лет 10-15 назад точно так же растопыривал пальцы BACnet. И кто его сейчас вспомнит? А MQTT никаких авансов не раздает, в барабан не лупит и флагами не размахивает, а просто работает.

Заряжать не полностью свинцовые аккумуляторы можно, ничего плоxого с ними от этого не случится. Беда в другом, их глубоко разряжать нельзя. Должно оставатся хотя бы 30% заряда, иначе они очень быстро испортятся. Вот и получится у вас, что вы будете заряжать до 70%, разряжать то 30%, используя всего 40% от иx емкости. Глубоко разряжать (до 0) можно щелочные аккумуляторы. Поэтому их используют в подлодках. Литиевые тоже можно глубоко разряжать, но дороговаты они. Сxодите вот на этот форум, там много инфы полезной: https://www.forumhouse.ru/forums/162/

Ага. А вас по каким-то причинам напрягает операция XOR? Религия не позволяет, или типа того? Ну тогда не делайте, посылайте как есть, на практике результат будет одинаковый. Да хоть миллиметр. Помехи-то все равно пройдут сквозь него. Наведутся они вовне, а пройдут сквозь ваш короткий USB, если им деваться больше некуда. Опторазвязка может помочь частично, но за счет паразитных емкостей помехи все равно пройдут.

Когда используется COBS, то удобнее всего при кодировании как специальный символ использовать 0. Поэтому, если надо получить на физическом уровне специальный символ 0xFF, то проще всего делать XOR 0xFF. Что же касается 0xF0 в том топике, то там мой (радио)канал требовал, чтобы количество 0 и 1 в последовательности было равно. Поэтому я использовал именно 0xF0 как специальный символ для байт-синхронизации и взвешенное кодирование 6b8b для данных, и все прекрасно работало с обычным микроконтроллерным UART-ом.

А какая разница? Как ни сделай, хоть бы даже вообще тупо на подтяжки понадеяться, все равно первым сбиваться будет USB, а не RS485. Тем более что у ТС изохронная труба, которая не гарантирует доставку.

Если уж закладываться на кривизну PC16550, то проще всего делать XOR 0xFF каждого байта при приеме и передаче. Тогда два 0 в начале и 0 в конце передачи на линии появятся как 0xFF. Варианты с задержками (в частности, Modbus RTU) обсуждались ранее. Интереснее сделать вообще без задержек, на одном UART-е, без использования таймера.

"а это уж вы сами" © Щербаков К сожалению, вы ничего не поняли, даже какой-то "номер пакета" вдруг выдумали и приплели ни к селу ни к городу. Никакой шум в паузе не повлияет на прием пакета из-за того, что передатчик передает два 0 до начала пакета. После паузы приемник гарантировано получит хотя бы один 0, после чего "шумовой" пакет будет проверен и отвергнут из-за несовпадения CRC, а также из-за несоответствия правилам COBS. А следующий сразу же вслед за этим истинный пакет будет принят без искажений.

А вы этот номер передавайте в самом байте дважды: в младших 4 битах сам номер, а в старших четырех битах - его инверсию. Так вы любые одиночные ошибки в этом байте обнаружите.

Тогда пусть все датчики ставят в нужное место номер 1, кодируют и отправляют. А ваш МК1 просто заменит номер 1 в этом месте на действительный номер датчика. Если он не будет равен 0, то на COBS это никак не повлияет. Однако при этом придется обойтись без CRC на все сообщение, поскольку CRC надо добавлять до того, как кодировать по COBS. Можно, конечно, CRC считать в датчике, а "1" добавлять потом, но при этом номер датчика не будет охвачен CRC. Это не очень хорошо, но работать будет. Какой счетчик? Взятый в тот момент, когда вы получили сообщение, или в тот момент когда вы его сформировали в буфере для отправки? Неужто вы думаете, что он будет отправлен в том же фрейме? Ведь вы же BULK используете, а он асинхронный. Специфиkация USB: 5.12.4.1.1 Asynchronous Asynchronous endpoints cannot synchronize to SOF or any other clock in the USB domain.

А почему датчик не может сразу добавить свой номер и CRC, а потом закодировать сообщение? Добавить байт (т.е номер датчика) к уже закодированному COBS сообщению - вообще-то проблема, даже если этот номер не равен 0. Потому что в корректной реализации при раскодировании сообщения на месте этого байта должен быть или 0 (это значит, что сообщение закончено), или число последующих ненулевых байт в сообщении. Конечно, можно наставить костылей, например, если длина сообщения фиксирована, то последний байт обрабатывать не так, как остальные. Только нехорошо это. Потому иначе намного больше вероятность, что что среди ложных сообщений будет такое, что пройдет проверку. SOF-ы автоматически считаются "на нижнем уровне". А накой вам этот счетчик?

Я не понимаю о чем вы говорите. Выражайте свои мысли яснее. Тот, кто отсылает сообщение, может добавить в сообщение что угодно, затем закодировать и переслать. Приемник раскодирует принятое сообщение обрабатывает как требуется, если надо - добавляет номер датчика. В чем проблема-то? Не играет роли кто является приемником, кто передатчиком. И что вы там в своем железе нагородили, кто у вас там "датчик", кто "МК", причем тут ДМА, и кто чего должен добавлять, то ли на передающем конце, то ли на приемном - так телепатов нет. Кстати, однобайтная контрольная сумма - это мало, так вы ложные сообщения не отсеете. Используйте двухбайтный CRC.

На чем угодно. Хоть на брэйнфаке. Мизер. Посмотрите сами на код в Википедии и не задавайте таких вопросов. Причем, там приведен "сложный" вариант кода, поскольку они обрабатывают сообщения произвольного размера, а потому перекладывают из одного буфера в другой, чтобы по ходу можно было вставлять дополнительные байты. В случае же коротких сообщений (меньше 255 байт) все гораздо проще, поскольку заранее все известно: один дополнительный байт появится в начале. Поэтому и перекладывать ничего не надо, одного буфера достаточно, просто незакодированное сообщение надо в него класть начиная не с 0-го байта, а 1-го. Потом просто пробегаете по буферу и заменяете нули. Да какая может быть разница, что вы там запихнете в свое сообщение? COBS-у это абсолютно по барабану. На передающем узле закодировали, на приемном раскодировали.

При использовании COBS длина вашего (короткого) пакета увеличится на 1 байт. После преобразования COBS в вашем пакете не будет нулей. Для очистки грязи из приемного буфера надо дважды передать 0 до начала самого пакета. Первый 0 может оказаться испорченным, зато второй дойдет и очистит буфер. Для простоты можно еще раз передать 0 по завершению пакета. "Простота" заключается в том, что это позволяет не парсить приходящие байты "на лету", надо ловить только 0 и проверять валидность пакета целиком после прихода нуля. Итого, 4 байта накладных расходов. И никаких таймеров и пауз, это лишнее, если делать с байт-стаффингом. Таймеры и паузы нужны для Модбаса RTU и подобных ему протоколов. Правда, не все липовые "специалисты" это способны понять.

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

Ну а если совпадает? Одного "признака начала" недостаточно. "Байт-стаффинг" - это более точное указание на то, что требуется. Я уже писАл, что байт-стаффинг проще, чем Модбас. Более того, предлагал ТС использовать COBS. Конечно, можно слепить какой-то "недо-байт-стаффинг", некий упрощенный вариант, играя на том, что требуется не полная сеть, а всего лишь пара мастер-слэйв. А оно надо? Разумнее не плодить ублюдков.

Так сделано в Модбас RTU, который вы еще недавно обсдавали пометом Однако, несмотря на растопыренные пальцы, вы кажется даже не догадываетесь, что "включение передатчика заранее" само по себе проблему не решает. На приемном конце необходимо произвести некие действия, а имено - определить, что появилась пауза и, если в приемном буфере что-то есть, очистить буфер. А чтобы можно было определить наличие паузы, необходимо, чтобы между байтами в настоящем пакете пауз не было. Так, шаг за шагом, постепенно вырисовывается как раз таки Модбас RTU, поскольку он логично и последовательно реализует этот подход. В случае ТС использование Модбас будет несколько избыточным, зато надежным решением. При помощи байт-стаффинга проблема решается проще, но ТС эти предложения игнорирует (вероятно, не понимает что это и зачем), а вместо этого предпочитает громоздить что-то свое, пусть и хуже, чем Модбас, зато понятное.