Проблемы с Далласами, дохнут, врут... Опции

[GrayCat]

Приколы какие-то с этими Далласами, DS18S20 и DS18B20. У нас они в системе термометрии зернохранилищ, так что статистика есть по нескольким сотням штук.

1. "Портятся". Некоторые датчики (замечено за серией DS18S20) вдруг, начиная с некоторого момента, начинают "врать": показывать температуру T°±X, где X - случайно, да еще иногда и меняется. Поначалу грешили на переполюсовку, на статику, на повышенную нагрузку (1к1 в "подтяжке" это 4мА - на пределе, по даташиту)... Но последний случай это опроверг: только что датчик показывал комнатную температуру, через 10 минут гляжу: "-3.3°" ! При этом ничего не делалось, не переключалось, коробочка лежала на столе. Загадка...
2. Еще одна странность: некоторые DS18B20 при некоторых температурах начинают "дрожать" в пределах 2°. Т.е., например, 17° показывают стабильно, 18°, 22° и выше - стабильные показания. А в интервале 19°...21° - с каждым считыванием выдает "псевдослучайное" число из этого промежутка. При том, что все остальные датчики в этой шине ведут себя нормально.

Кто-нибудь с таким сталкивался? Это лечится?

[GrayCat]

Последним ~пяти ораторам:

Почитайте внимательно выложенный сюда документ APP247. Там более-менее подробно расписано, что и отчего. У нескольких партий датчиков выпуска 2004 года (а у нас именно они) повышена вероятность слета EEPROM в момент подачи питания. Небось, со встроенным Brown-out намутили.

В документе приводятся последовательности команд для считывания калибровочных констант, и для их записи. Даны также "усредненные" константы, которые гарантируют "некалиброванную" точность ±2°. Показано, как определить, "съехала крыша" у конкретного датчика, или нет (соответствие считанных констант неким маскам).

По результатам моих экспериментов, команды записи пишут именно в EEPROM датчика, так что после этой процедуры датчик становится "полноценным", но с гарантированной точностью ±2° вместо "калиброванных" ±0.5°. Нас это устраивает. Контроллер при старте запрашивает константы у всех датчиков, и если у какого-то сбой - перепрошивает "усредненные".

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

А что касается альтернатив - есть ли в природе другие варианты, как промерять температуру в нескольких точках (~15шт.) на некоей длине (~30м), не протягивая туда жгута из десятка проводов? Далласы это обеспечивают, хоть и не безгеморройно.

[rezident]

А что касается альтернатив - есть ли в природе другие варианты, как промерять температуру в нескольких точках (~15шт.) на некоей длине (~30м), не протягивая туда жгута из десятка проводов? Далласы это обеспечивают, хоть и не безгеморройно.

Дык при такой постановке задачи у вас проблема в линиях связи видимо, а не измерения. Можно ведь использовать интеллектуальные измерители температуры и другой интерфейс связи. Из двупроводных промышленных - RS485 или токовая петля, например.

[GrayCat]

Дык при такой постановке задачи у вас проблема в линиях связи видимо, а не измерения. Можно ведь использовать интеллектуальные измерители температуры и другой интерфейс связи. Из двупроводных промышленных - RS485 или токовая петля, например.

Та мы ж и не против!!! Одна из самых больших проблем MicroLAN - невозможность нормальной терминации, и ТТЛ-уровни не только на передачу, но и на прием (в отличие от тех же RS232, RS-485, где приемник -- компаратор с "нулем"). Как всегда, недостатки любого технического решения - продолжение его достоинств.

Конечно, очень привлекательной альтернативой Далласам выглядит исполнение каждой "точки измерения" на МК + термистор/термопара/RTD навешенной на RS-485. Дороговато, конечно, по сравнению с DS18*20, и гарантии отсутствия кучи специфических проблем не дает.

Но дело не в этом. В нашем случае (зернохранилища) такое не пройдет: "термоподвеска" (например, полый металлический трос с гирляндой датчиков внутри) должна быть как можно тоньше, дабы трение об зерно было поменьше. Имеющиеся конструкции (трос наружным диаметром порядка 20мм) испытывают при выгрузке зерна нагрузки порядка тонны, и их узел крепления к крыше частенько не выдерживает. Если же каждая "точка" будет целой печатной платой, такую конструкцию сметет в момент!

Короче, Далласы нас почти устраивают. Да и с проблемой недержания EEPROM мы уже научились бороться. Дальше у нас по плану -- корреляционный алгоритм приема бита от датчика...

[Rst7]

Та мы ж и не против!!! Одна из самых больших проблем MicroLAN - невозможность нормальной терминации, и ТТЛ-уровни не только на передачу, но и на прием (в отличие от тех же RS232, RS-485, где приемник -- компаратор с "нулем"). Как всегда, недостатки любого технического решения - продолжение его достоинств.

Я бы не говорил так категорично - RS485 в этом отношении с порогом 50мв имеет свои грабли - дабы в период тишины на линии не ловить начало пакета от помех надо либо делать некоторую принудительную поляризацию линии (ну допустим до уровня 0.7вольт, чтобы четко удержать лог. 1 на выходе приемника, пока нет никакой передачи), либо добавлять специальный байт 0xFF перед пакетом, причем при приеме его отбрасывать (передача такого байта обеспечит правильное определение старта для следующего байта независимо от состояния линии до начала передачи). Вообщем проблем тоже как грязи... Идеального ничего нет...

Короче, Далласы нас почти устраивают. Да и с проблемой недержания EEPROM мы уже научились бороться. Дальше у нас по плану -- корреляционный алгоритм приема бита от датчика...

Можно конечно попробовать... Но не стоит забывать, что сам датчик принимает информацию именно по семплу в одной точке... Так что таким образом можно подлечить канал только наполовину

[GrayCat]

Я бы не говорил так категорично - RS485 в этом отношении с порогом 50мв имеет свои грабли

Вот именно, как я уже говорил про "продолжение достоинств"

- дабы в период тишины на линии не ловить начало пакета от помех надо либо делать некоторую принудительную поляризацию линии (ну допустим до уровня 0.7вольт, чтобы четко удержать лог. 1 на выходе приемника, пока нет никакой передачи)

Ну так эти "растяжки" -- совершенно стандартный элемент схемотехники RS-485, вплоть до включения их в состав микросхем.

, либо добавлять специальный байт 0xFF перед пакетом, причем при приеме его отбрасывать

Не надо ничего "добавлять" и "выбрасывать". Достаточно включать передатчик на передачу лог. "1" за пару "байт" до собственно посылки информации в линию. Именно это предусмотрено, например, протоколом MODBUS RTU. Тогда низкий импеданс передатчика удавит помехи, а тот "мусор", который успел принять приемник до включения передатчика, будет отброшен алгоритмом по таймауту.

Вообщем проблем тоже как грязи... Идеального ничего нет...

Вот именно! НО! Для того же RS-485 эти проблемы тем или иным образом решаемы. Хотя бы, в крайнем случае, понижением скорости обмена. А у 1-wire -- принципиально нерешаемы. Никак

Можно конечно попробовать... Но не стоит забывать, что сам датчик принимает информацию именно по семплу в одной точке... Так что таким образом можно подлечить канал только наполовину

Вот именно это (низкая помехоустойчивость самих датчиков) я и имел в виду, когда говорил о "принципиальной нерешаемости".

[Rst7]

Ну так эти "растяжки" -- совершенно стандартный элемент схемотехники RS-485, вплоть до включения их в состав микросхем.

Криво это все... И, кстати, лишнее потребление от этих растяжек (ведь надо пересилить 60ом двух терминаторов (обычно), по 10 ком в + и в - речь не идет, это только если обрыв происходит)....

Не надо ничего "добавлять" и "выбрасывать". Достаточно включать передатчик на передачу лог. "1" за пару "байт" до собственно посылки информации в линию. Именно это предусмотрено, например, протоколом MODBUS RTU. Тогда низкий импеданс передатчика удавит помехи, а тот "мусор", который успел принять приемник до включения передатчика, будет отброшен алгоритмом по таймауту.

А вот такие вещи не работают, если делаешь репитер с автоматическим переключением направления... Точнее, работает только на сегменте от передатчика до первого репитера, а дальше уже нет, нет защитного интервала, репитер то включится только по старту...

Вот именно! НО! Для того же RS-485 эти проблемы тем или иным образом решаемы. Хотя бы, в крайнем случае, понижением скорости обмена. А у 1-wire -- принципиально нерешаемы. Никак
Вот именно это (низкая помехоустойчивость самих датчиков) я и имел в виду, когда говорил о "принципиальной нерешаемости".

согласен.

[GrayCat]

Криво это все...

Не более криво, чем "лог.1" по умолчанию на висящем ТТЛ-входе :D

И, кстати, лишнее потребление от этих растяжек (ведь надо пересилить 60ом двух терминаторов (обычно), по 10 ком в + и в - речь не идет, это только если обрыв происходит)....

Та ладно, обычно там где RS-485, лишние пара мА не проблема.

А вот такие вещи не работают, если делаешь репитер с автоматическим переключением направления...

Наверное, да. Нам пока что репитеры без надобности. А если и понадобится -- уже есть отработанная схема "свича" RS232/422/485 <-> RS422/485, на "двухпортовом" микроконтроллере, который сам все необходимые времянки отработает.

Но, увы, Далласам это уже никак не поможет...