Здравствуйте!
Датчик DS18B20 подключен к AVR'ке проводом длиной 50 см. Система находится на улице и подключена к компьютеру через интерфейс RS485.
При чтении температуры иногда появляются ошибки. На улице -15, термометр показывает -3. Иногда появляются ошибки в контрольной сумме, но значение температуры верные, но это бывает очень редко (ошибка КС). Поскольку КС можно сказать, что сходится всегда, возникает вопрос, почему датчик выдает ошибочную отрицательную температуру? С положительной все ОК. Преобразование из дополнительного кода проводится правильно, т.к. иногда отрицательная температура читает правильно. Не могу уловить зависимость между правильными и неправильными показаниями.
Что еще интересно, по умолчанию при включении питания датчик настроен на 12-ти разрядный результат, что определяется конфигурационным регистром в "скратчпаде" (он равен после сброса питания 7F). Спустя некоторое время его значение становится 5F, хотя я не использую команду записи в "скратчпад".
Далее в документации на датчик написано, что байты 5 - 7 (считаем от нуля) имеют вполне определенные значения: FF, 0C, 10. Так вот, 5 и 7 читаются как надо, всегда причем, а 6 - изредко 0C, а так 04, 08.... Меняется иногда вместе с изменением температуры.

Да, как бы есть едва угадываемая закономерность: чем меньше температура (ближе к -14, -15), тем вероятнее ошибка. Но у нас на улице сейчас -8, так что пока все ОК, и нет возможности проверить гипотезу.

Теряюсь в догадках, думал датчик другой стоит (DS1820, DS18S20), но нет, проверил, все ок.

Заранее благодарен за любые советы!

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

если преобразования ведутся согласно формуле из даташита - должно всё быть пучком. особенно в плюсовом диапазоне. в минусовом там немного переворачивается - но суть та же. про доп. код станет более понятно если зададитесь вопросом как устроен сам датчик. думаете там АЦП стоит? у вас доп. код = два числа. один дополнение (сколько не уложилось в квант), второе - собственно сам квант. квант подстраивается под внешнии условия (возможно корректировка стоит) - посему изменяется но не сильно.

(круглый)

В документе на DS18B20 нет формулы) Там же весы (или веса) битов расписаны...
Преобразования делаю так: пусть с датчика получен LSB:MSB = 5F:FF.
Отбросим дробную часть и "лишние" знаковые биты S коих несколько, получим целую часть F5, что дает -11 гр. Цельсия. Ну с учетом дробной части это будет -10 с копейками. Это неправильно? Я буду рад, если ошибся в алгоритме. Датчики еще в наличие есть, но жаль тратить их)))
Кстати, сейчас 6й байт равен 1 (единица).

Как выполнять преобразования? В "даташитах" на более старые версии датчиков есть формула, на этот датчик нет... Или я путаю версии датчиков?

Вот сейчас на улице -14. С датчика приходит это

Порядок "scratchpad'а" такой же как и в документации.

А вот эту КС считает программа

CODE

FA != 1F

Хотя еще 15 минут назад все было ОК, и весь день КС сходилась, температура была правильная. Такое ощущение, что датчик "замерзает", "боится холода"...

Вот еще для коллекции данных с датчиков. Температура похоже на верную... КС не сходится...

1C FF 25 A3 BF 7F 2 88 F4
1B FF 25 A3 BF FF 2 88 F1
1C FF 25 A3 BF 7F 2 88 F4
1B FF 25 A3 BF FF 2 88 F1
1C FF 25 A3 BF 7F 2 88 F4
Что же делать?

На этот срочно шубу .
Вы же говорили , что есть другой , что будет с ним

Другие проверю, но немного позже.

Просто мало ли, может быть нечто подобное уже было у кого-нить)

З.Ы. Только сейчас опечатку в названии темы заметил)))

Если до 1 С, то T = (signed char) ((Th<<8) | Tl) / 16;
Если хочется больше цифр (правда, не знаю зачем, если датчики не калибруются) и не страшна плавучка, то T = (float) ((Th<<8) | Tl) / 16.0;
имхо, у Вас программные проблемы с обменом по ванвари. Добейтесь таки устойчивых 0xFF 0x0C 0x10 в скречпаде.

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


Хотя, стоп! Когда последовательность 0xFF 0x0C 0x10 не наблюдается, КС считается верно, но это бывает, как я уже говорил, не всегда.

Упс-с, уже забыл. Глянул в ДШ:

Перепутал с 0x05 0x50, которые должны возвращаться в Th:Tl до первого измерения.
0xFF 0x0C 0x10 в 5, 6, 7 байтах также будут только до первого измерения.

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

1) Не правельное измерение температуры может происходить по пречине просадки напряжения на датчике во время измерения температуры.
2) Вычитывается температура с датчика раньше чем происходит измерение температуры (измерение температуры происходит порядка 0,8 секунды). Поэтому чаще 1 секунды вычитывать с датчика температуру я бы не рекомендовал.

Если будет сбоить интерфейс то контрольная сумма не сойдется.

Гм... ритмика происходящего говорит о том, что это достаточно постоянный, стабильный негативный фактор. Просадки долгими не часто бывают, а у меня нет мощных потребителей на линии.

У меня температура считывается раз в 1,5 - 3 сек.

Маленько поправил функции обмена по шине. Ждем -15, на улице зима и как назло -12...

У меня получилось, что низкочастотная болтанка по питанию (10..20..50..100 Гц, 3..5 В) не вызывает погрешностей, выходящих за даташитные.

Никакого смысла - постоянная времени датчика в still air у меня получилась 30..40 с, - а ошибку от саморазогрева (+2..3 С) получите.

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

Похоже датчику придется принести извинения, т.к. если программно (т.е. не отключая питание) перезагрузить устройство, то температура начинает считываться правильная, все ошибки исчезают... ЗНаччит датчик не причем?! Что-то с программой, т.к. на датчике не прерывается питание, просто прекращается обмен на несколько секунд.
Программа с применением ОСРВ, теряюсь в догадках. Увеличил стек задача опроса датчика. Критические секции (запрет прерываний) во время опроса датчика имеются.


Да, смысла нет. Увеличить время опроса не проблема.

Так может , это вообще не датчик , а RS485 дурит. Я свой уличный датчик читаю один раз в минуту и то думаю , что это очень часто.