=AK=
-
Постов
3 279 -
Зарегистрирован
-
Посещение
-
Победитель дней
5
Сообщения, опубликованные =AK=
-
-
Какие сказки про белого бычка? Че за знаки "ты идиот"?
- Ответил
- Изначально я спрашивал, что если не RS-485? - соврал; возможно это тролль?
- Понятно. Спасибо. То бишь RS-422 самый стойкий к помехам? А CAN bus? - вроде бы дошло, но не совсем
- Ответил
- И при чем тут "правильный протокол"? - опять двадцать пять; oбщее поведение соответствует поведению тролля.
- Обьяснил еще раз, однако отметил нарочитую тупость.
- Не хамить воспитание не позволяет? - ну точно, тролль, вишь как обрадовался кормежке
- совок он и есть совок, хоть куда переедь, из души не вытравить. - однозначно тролль, жирный и нахрапистый
Некоторые (условно назовем их "остальные") использует протоколы, которым все равно что происходит на линии в то время, когда данные по ней не передаются. Как результат- эти некоторые (и разработанные ими устройства) не видят разницу между "линией, в которой есть неопределенность при отсутствии передачи" и "линией состояние которой между передачами детерменировано"Это не является достаточным условием для помехоустойчивого протокола. Вполне обеспечивается, например, хорошим CRC. Однако никакой гарантии от глюкавости в условиях сильных помех не дает. Сообщение просто никогда не дойдет до адресата. Так что все-таки "остальные" пусть постоят тихонечко где-то в сторонке, они, действительно, даже до "гурманов" не дотягивают.
-
имелось ввиду, что если выдерживать паузу с переключением на приём, после передачи полезной информации и постоянно вести обмен
на линии - то устойчивость к помехам возрастает.
Уж не знаю, кто это имел ввиду, однако из этого сбивчивого описания я лично не выудил ровно никакого смысла. Паузу после передачи информации выдерживать бесполезно, поскольку все проблемы возникают до начала передачи или в самом начале передачи пакета, а приводят они к порче пакета.
Поэтому можно включить передатчик и выдерживать паузу до начала передачи пакета, при этом в самом пакете не должно быть больших пауз между байтами, а приемники при обнаружении пауз должны очищать свои приемные буфера. Так сделано в Modbus RTU, про который я упоминал.
Или же вместо пауз и таймаутов можно использовать байт-стаффинг для управления потоком. Тогда в начале передачи достаточно дважды передать символ "начало пакета". Второй из этих двух символов гарантированно придет неиспорченным и очистит буфера приемников, после чего пакет будет доставлен правильно.
Некоторые (условно назовем их "остальные") использует протоколы....Выше я в общих чертах описал два существующих подхода к построению правильного протокола для RS-485. Других нет, так что "остальные" со своими растопыренными пальцами могут покурить в сторонке.
Еще более некоторые (назовем их "гурманы"), предпочитают, чтобы их драйвер RS-485 не выдавал ложных переходов в микроконтроллер если линия в неопределенном состоянии. Они действуют двумя способами:1) применяют драйверы RS-485, которые при неподключенной линии выдают неактивный уровень в RX, например SN75LBC184
2) применяют резисторы, "растягивающие" линию из неопределенного состояния в определенное.
3) применяют (1) + (2) вместе.
Хоть кол на голове теши. Я уже много раз повторил, что этот подход обеспечивает невысокую помехоустойчивость, которая в десятки-сотни раз уступает помехоустойчивости RS-485 с правильным протоколом, или помехоустойчивости RS-422. Я за свою жизнь вдоволь насмотрелся на поделки таких "гурманов", они хорошо работают на столе в лаборатории, однако бездарно глючат в полевых условиях.
-
Для организации питания планируется поставить первичный БП подключенный к бортовой сети.
...
Как оценить уровень ожидаемых помех?
Уровень помех вообще-то никак не связан с питанием. Когда вы это поймете, можно будет продолжить разговор.
-
И при чем тут "правильный протокол"?
При том, что сеть RS-485 с правильным протоколом настолько же помехоустойчива, насколько помехоустойчива связь по RS-422. Че-то до вас ничего не доходит, по пять раз прихoдится повторять. Сказка про белого бычка... :01:
-
То бишь RS-422 самый стойкий к помехам?
RS-485 с правильным протоколом ничуть не хуже.
А CAN bus?Примерно такой же, как RS-485 с плохим протоколом и резисторами растяжки.
-
=AK=
Вы смеетесь? Про 485 и 422? В устройствах что я смотрел микросхемы драйверов одинаковые.
Разница первый полудуплекс второй полный.
Мне больше плакать хочется, когда я снова и снова слышу наивное недоумение по этому поводу. :cranky: Да, разница именно в этом. Низкое выходное сопротивление постоянно включенного драйвера RS-422 очень эффективно давит наведенные в линии помехи. Давит намного эффективнее, чем вшивые резисторы растяжки. Настолько эффективнее, насколько ниже выходное сопротивление драйвера в сравнении с резисторами растяжки. RS-422 десятки и сотни раз более помехоустойчив, чем RS-485 с паршивым протоколом, который в плане помехоустойчивости полагается только нa растяжки.
2. В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?RS-422 - это "точка-точка", передатчик постоянно включен. А RS-485 - это шина, все передатчики большую часть времени выключены и линия свободно болтается, ловя любые помехи.
-
Изначально я спрашивал, что если не RS-485?
У вас что-то с памятью. Изначально вы спрашивали "а что не так с 485?". Вам обьяснили, что сам по себе RS-485 не является панацеей, без применения правильного протокола, за счет одних только резисторов подтяжки, его помехоустойчивость совсем не выдающаяся, а при поганом протоколе и отсутствии резисторов подтяжки - абсолютно дрянная. Отмечу, что резисторы подтяжки не являются частью RS-485, так что в "чистом виде" RS-485 вообще говоря обладает крайне низкой помехоустойчивостью.
Вот с RS-422 все в порядке, ему не требуется ни "правильных" протоколов, ни дополнительных резисторов, его помехоустойчивость обеспечивается аппаратно.
-
И че делать? CAN?
Modbus RTU, Bitbus и т.п.
-
а что не так с 485?
Чувствительность у приемников 485 довольно высокая. Очень часто для защиты от наведенных помех надеются только на резисторы растяжки, качественные (и очень дорогие) витые пары и экранированные кабели. А этого в промышленных условиях недостаточно для надежной работы 485.
-
Это только "настольное" и "игровое" делается под USB... А промышленное и длительно-работающее - никогда.. Вот подвиснет ночью у Вам USB и что будете делать? Вручную кабель передергивать?
Для конфигурирования оборудования USB применяется сплошь и рядом. Для управления оборудованием - нет. Собственно, точно то же самое было и с RS-232, для управления оборудованием его применяли разве что по недоумию. Впрочем, в таком случае и RS-485 был не впрок, чему есть масса примеров.
-
подскажите пожалуйста решения возможно с другим интерфейсом, или вообще концептуально другие, максимально подходящие для этих средств.
Zigbee, Bluethooth LE, DASH-7
-
1. На источнике питания +2В. Осцилографом меряю напряжение на первичной обмотке, там 10Vpp. Я так понимаю это так индуктивность влияет ?
Скорей всего так влияет индуктивность рассеяния. А вообще-то неплохо было бы на осциллограммку взглянуть.
2. Про демпфирующую цепочку я почитал, там она расчитывается на определенную частоту. А мне хотелось бы работать в широком диапазоне частот (500 кГц - 2 МГц). Может какой нибудь стабилитрон в качестве гасящего элемента поставить ?Впервые слышу, что демпфирующая цепочка "расчитывается на определенную частоту". Если там частота и участвует в расчетах, то разве что для того, чтобы расчитать потери мощности в диоде. Ну или для того, чтобы поставить кондер поменьше и огрести за это пульсации на нем и, соответственно, частотнозависимое рассеяние мощности резистором. А в остальном демпфирующей цепочке фиолетово, какая частота.
Супрессор - это разновидность стабилитрона. Диод+супрессор по сути не так уж сильно отличается от демпфирующей цепочки диод+(резистор||кондер).
-
Он у меня перегревается (отпаивается от нагрева).
У супрессора очень большая емкость, из-за чего ток 1 МГц лихо скозь него свиндячит и нагревает. У варистора, кстати, емкость еще больше.
Поставьте последовательно с супрессором диод с малой емкостью. Тогда при старте емкость супрессора один раз зарядится и больше мешать не будет, а ток 1 МГц будет свиндячить через емкость диода и греть его.
А вообще-то сомнительно, чтобы в вашей схеме вообще надо было бы заботиться о защите от индуктивных бросков. Чтобы эти броски играли рояль, в сердечнике транса должна накапливаться большая энергия, которой некуда деваться. А у вас, похоже, нагрузка все время подключена ко вторичке, вот она все и заберет на себя. Так что не о чем беспокоиться.
-
я задавал вопросы по расчету снабберов, все как-то туманно и по графикам. Где-то в просторах нашел информацию, что от искрения подобных вещей такая цепочка - нормально... :05:
Абстрактно-теретицки сопротивление резистора в RC-цепочке должно быть равно внутреннему сопротивлению источника помехи, тогда помеха рассеится быстрее всего, с минимумом колебательности. Однако вас прежде всего должна интересовать не низкочастотная составляющая помехи, которая несет много энергии, однако сравнительно безвредна в смысле EMC. Поэтому в вашем случае большую пользу может принести просто конденсатор 1000 пФ в питании, параллельно снабберу.
Не забывайте, что конденсаторы должны быть класса X или Y, т.е. безопасные для работы в цепях сетевого напряжения.
-
ок, сегодня попробую параллельно нагрузке навесить 0.1мкФ и 100 Ом
Для начала нормально. И дросселечки добавить не забудьте.
-
здесь дело в том, что характер нагрузки заранее неизвестен и влезать в нагрузку, чтобы в нее встраивать искрогасящие схемы, никто не будет
Однако никто не мешает ставить искрогасящие цепи как можно ближе к нагрузке. Скажем, прямо в ту розетку, к которой подключаются эти неизвестные заранее нагрузки.
То есть, первым делом надо "окуклить" источник помех: обеспечить помехам максимально короткий и удобный контур для циркуляции (кондеры), плюс как-то "изолировать" этот контур от всего прочего окружения (дроссели, бусины). Пусть источник "варится в собственном соку" и сам себе пускает помехи. И только потом давить остатки помех, попавших в питание через "изолирующие" элементы.
-
Посоветуйте что-нибудь...
Помехи эффективнее всего давить там, где они возникают. То есть, встроить искрогасящие цепочки непосредственно в "некое устройство, типа старой раздолбаной дрели".
-
лучше есмкость добавьте 10..100нФ
А разве второй закон коммутации уже отменили?
-
Тут на форуме нашел общую рекомендацию по поводу 20мА. Хватит ли?
Больше 10 мА не нужно и даже вредно.
-
Кажется я немного перемудрил с подключением кнопки?
Угу. Этот узел вообще работать не будет. Нужен резистор параллельно D1.
Кто что скажет?Радиолюбительская поделка.
Профессиональная автоэлектроника сделана надежнее, она выдерживает подачу питания инверсной полярности и длительные выбросы до 60В. А тут регулятор питания держит всего 30В, а элекролит вообще на 25В, стыд и срам.
5 резисторов по 1.1к для подтяжки кнопки - полный маразм. Пользы от них никакой, только греются зазря, и еще контакты кнопки будут обгорать и быстрее выйдут из строя.
Резисторы R2...R7 - тоже очевидный маразм, они бесполезны.
Развязывающие кондеры 330 нФ выполняют свою роль хуже, чем обычные 100 нФ.
Диоды D3 должны стоять параллельно обмоткам реле, а не пaраллельно транзисторам.
-
Для всего этого необходимо разработать микроконтроллер для сбора и анализа данных.
Микроконтроллер под такую задачу разрабатывать не надо, есть множество готовых, незачем изобретать велосипед. Более того, микроконтроллерную плату тоже разрабатывать не надо, тоже по причине наличия множества готовых на выбор. Однако скорей всего для этой задачи лучше не опускаться на низкий уровень железа и программ, а взять какой-нибудь писюк и привязать его к стенду готовыми модулями ввода-вывода. А посему искать вам надо не электронщика (и уж тем более не микроэлектронщика), и даже не программиста, а интегратора, который из готовых кубиков соберет нужную вам систему и быстренько наваяет программу на лабвью или чем-то подобном.
-
Один порт в USB2.0 не может дать более 500 мА
Эта цифра есть трeбование спецификации USB. Чтобы уложиться в требования, устройство всегда дает больше. Насколько больше - зависит от реализации. На практике 90+% устройств стабильно дают ток до 700 мА, а при 800...900 мА у них срабатывает пороговое устройство защиты от кз, стоящее на каждом порту. Реальный вытекaющий ток никто не меряет, по крайней мере, ни разу такого не встречал. Величины потребляемых токов, запрашиваемые и "устанавливаемые" при энумерации, берутся "на веру" и используются для расчета суммарного потребления. А так - можете запросить 2 мА, но на самом деле при этом отсосать 700 мА, и ни хост ни хаб ничего не заметят, пока не сработает защита.
-
сигналы, то в моей схеме не дифференциальные...
Дифкаскаду все равно. Он сам "унутре себя" автоматически превращает сигнал в диффиренциальный.
-
усиление регулируется номиналом резистора R4. При 0 кОм - максимальное, при 10 кОм - минимальное.
Усиление регулируется за счет изменения токов дифф. каскадов. В идеале суммарный ток двух диффкаскадов должен оставаться постоянным, а соотношение токов правого и левого каскадов определяет усиление. При равенстве токов суммарное усиление равно нулю, поскольку по сигналу правый и левый каскады работают в противофазе и на выходе их сигналы взаимно вычитаются друг из друга. Когда токи каскадов не равны, то каскад с большим током имеет большее усиление и, соответственно, его сигнал доминирует, чем больше неравенство - тем сильнее.
умный дом [выбор интерфейса]
в Интерфейсы
Опубликовано · Пожаловаться
Я говорил, что CAN, в силу своего слабоватого физического уровня, по помехоустойчивости не может тягаться с RS-485 c качественным протоколом. Его помехоустойчивость сравнима с помехоустойчивостью интерфейса на базе RS-485, где есть резисторы растяжки, но используется плохой протокол. "Жесткость" протокола, использование CRC и т.п. отнюдь не делают протокол автоматически "хорошим", а плохой физический уровень погубит любой протокол, как бы он ни был хорош.
Когда-то давным-давно я лично наблюдал за мытарствами неких изобретателей самопальных протоколов, которые свято верили в силу резисторов растяжки на RS-485. Программист незнамо зачем (сам он не мог объяснить своих мотивов) переводил трансивер в 3-е состояние после каждого переданного байта, то есть, делал нечто напоминающее физический уровень CAN. На объекте система дико и регулярно глючила, надолго теряя связь, что по условиям задачи было недопустимо. Туда в командировку несколько раз посылали электронщика. Его действия сводились к уменьшению сопротивления резисторов растяжки и замене кабелей на все более дорогие экранированные витые пары. Частота глюков немного снижалась, однако оставалась заметной, система работала ненадежно.
В случае CAN тишина до и после пакета позволяет уменьшить количество коллизий, однако никак не спасает от помех.