Здравствуйте!
Датчик 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 дурит. Я свой уличный датчик читаю один раз в минуту и то думаю , что это очень часто.

На 485 не похоже, т.к. кроме температуры читаются другие датчики, их показания верны. Да и протокол с контрольной суммой.

Кстати, ошибка КС датчика исчезла. Сегодня утром проверяю температуру - на датчике -15, перезагрузил программно устройство, появилась реальная температура -20.

Такое ощущение, что то ли задача перестает выполняться (опрашивать датчик), то ли какие-то сервисы ОС перестают функционировать... данные с датчика как бы "замирают", "замораживаются".

Ладно, буду работать дальше... О результатах сообщу, м.б. кому-нибудь и будет полезен этот материал.

Была ситуация очень напоминающая Вашу, только датчик как бы... "сжаривался" при t > 90C.
Вообще не отрабатывалось условие START.
Времянки делал через UART (распространенное явление), так вот при высокой температуре времянки датчика "уплыли" и в UART приходило не то, что ожидалось.
Поборол софтово.

А то что у Вас АВР на улицу вынесен, случаем не с длиной проводов связано, в том смысле что на 10м провода сбои появляются, а на 0.5 нормально работает? И датчик с паразитным питанием или полным?

На длину проводов не похоже, т.к. идет достаточно частый (каждые 150 мс) обмен с МК, за сутки непрерывной работы 2 ошибки из 46 тыс. переданных и принятых пакетов. Другие датчики нормально опрашиваются.
Датчик с полным питанием.

И все таки все больше похоже, что низкоприоритетная задача опроса датчика наглухо перестает работать. Выходишь на улицу, дышишь на датчик, держишь его в теплых руках, а программа на компе "исправно" показывает -14. При нормальной работе, показания всегда меняются. Что интересно, задачи более высокого приоритета продолжают работать (там АЦП опрашивается). А задачи приоритетом еще ниже тоже встают, это видно по отсутствию мигания служебного светодиода.

Вот так вот я совершенно зря подозревал датчик...)))

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

В чем было дело? Элементарно неверно былиз заданы размеры стеков для задач. После увеличения размера стеков задача опроса датчика и еще одно (приоритетом ниже), сбои пропали.

Большое спасибо Всем за помощь, участие и советы!!!

И все таки оно плавает.... Столкнулся с этим вот сейчас. Вчера все работало. Сегодня утром - ошибка CRC. Что интересно, датчик расположен на этот раз на плате. Тот же самый код великолепно читает DS1990.

Вот прикоснулся рукой к DS18B20, температура изменилась - и КС снова совпала... Я уже разочаровался в этом мире) Еще 1 января)

Если игнорировать КС, то температура адекватная.

Либо стека всё же не хватает, либо неверна процедура подсчёта CRC, таковы мои версии

Две разные процедуры подсчета выдают одно и тоже значение вкупе с онлайн-калькулятором
Причем если датчик "погреть" пальцами, то CRC начинает сходится...

Я же правильно считаю:
1. Принимаю scratchpad в буфер - 9 байт.
2. Подсчитываю CRC8 для 8 байт буфера.
3. Сравниваю эту КС с 9-м байтом буфера.

Уже шарики за ролики заходят)

А еще бывает, что тайминги "плывут" взависимости от температуры.

Да нормааааально
Я же это с другими делами делаю)

Да, похоже, что дело чисто программное.

Снова напоролся на свои же грабли.

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

Ну EEPROM они победили и даже аппноут убрали с сайта. Я им лично вопрос по сему поводу задавал. Сейчас проверил , аж три датчика на одной линии с калькулятором - ни разу CRC не сошлась , а температуру показывают адекватную и дружненько так. Проверяю по BMP085.

Энто как? Может быть у Вас тоже дело в софте?

Еще и времянки в драйвере 1wire были "замечательными": при положительной температуре все считывается отлично. Выставляешь датчик на улицу - температура плюс/минус за тысячу, КС не сходится))) Как я понимаю, у датчика RC-генератор внутри, которые от температуры немного плавает, и времянки шины плывут... Ну тема для начинающих, а!

________________________________
З.Ы. Все в куче: стэк, времянки, праздники...

Да скорее не в софте, USART- там думать ни о чём не надо. Вот только драйвер согласования на биполярниках , что-то мне кажется "дурит", соберу его на полевиках , посмотрю что-будет.

тактовый да. а измеряющий - снаружи естественно резистор, термо который

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

и вообще С Новым Годом!

Тоже самое и с полевиками, фронты - мама не горюй , все регистры читаются как положено , даже загонял значения в USER's registers - . Резервные 5 и 8 выдают строго по DS.
6 байт - о котором нет ни слова , каждый раз выдаёт новое значение, хотя на полученной температуре сие не сказывается.
Один из трёх (дома на макетке) "уложил в талую воду. Ну скачет температура у датчика +/- 0,0625 ( использую 12 разрядов точность ) , но CRC всё равно не сходится хоть ты ее тресни. Второй обнял ВМР085- и они дружненько так показывают одинаково температуру до запятой , сточностью у них понятненько есть разница.
Третий с таким же собратом только от другого проекта , болтаются на улице, и здесь наблюдается единое мнение до 2 знака после запятой.
Ну ее на хрен эту CRC.

Как так - на хрен?
Тогда уж лучше с плеча - 1-wire на хрен.
Если без CRC, то как тогда отличать, где верно, а где нет?

P.S. Есть ли адекватная замена 1-wire?

Всю ночь мой датчик проработал на улице. CRC совпадает. Без CRC строго не советую работать, температуры чудные выходят)


1-wire over RS-485?

C какой точностью работаешь?


У этих датчиков есть один неприятный момомент , при частом опросе идёт саморазогрев, если CRC не совпало нужно повторить преобразование - чтение. Хорошо , если со второй попытки совпало , а если нет? Я бы не стал доверять такой температуре. У меня в MENU забит пункт - TIMEOUT опроса датчиков. Минимум , который можно задать- 1мин.

Та, которая по умолчанию - 12 бит.

Я опрашиваю датчики не чаще 30 секунд. Причем интервал разбит на две части:
1. Команда на конвертацию.
2. Пауза 15 сек.
3. Чтение температуры.
4. Пауза 15 сек.
5. Переход к п. 1.

Такие паузы пришлось взять по причине использования ОС. А для формирования точной времянке на шине, приходится использовать критические секции (читай запрет прерываний). Чтобы часто систему не вешать - интервал взять большой. По сути для уличного измерения температуры его можно увеличить вплоть до 30 минут, чаще вряд ли оправдано. Для дома (ИМХО) - 1 минута, если датчик работает как противопожарный. И до 10 - 20 минут, если "просто" измеряет.

Как-то так)

+ (~)750ms (обычно меньше)= данные. 0xF0 0x55 Rom 0x44 750ms 0xF0 0x55 Rom 0xBE ~= 800ms
У меня таймер работает по секундно , очень удобно 1Гц получать из USART-ого кварца.
Я это к чему, в течении 1 сек можно конвертировать и прочитать. Зачем

Так КС-то до сих пор не сходится?

Празник, не дадут посидеть нормально.

все с этого начинали. с синхронизации с другими критическими событиями в девайсе. но если присмотритесь повнимательней к протоколу, то точно выдерживать временной срез необходимо только в одном месте - от синхроимпульса до начала тайм-слота. всё остальное апсолютно не критично. если весь сыр-бор загнать в прерывание, то собственно общение по 1wire ни с кем конфликтовать и не будет в принципе...

типа совет дня.

Спасибо, очень ценный совет!
В будущем, будет время заняться - попробую внедрить тему... Жаль в "ходовых" мегах один USART. Ну да ладно, таймерное прерывание лишнее найти думаю не проблема...

И чему это мешает?
1-USART = N-sensors 1-Wire+4-KNOB(можно больше, но мне не надо)+LCD+(прикручиваю в данный момент)радиомодуль. Требует мультиплексор =1 транзистор +2 сигнала квинтирования. Естественно все используют свои прерывания.
Используй 164P- там их два. Если пишешь на С - максимальная версия этой линейки 1284

Охренеть ( личная цензура внесла коррективы в это слово) . Чем думал пИсатель этой проги от МАКСИМ. Всё раком.

Сложно
У меня один USART постоянно под RS-485 занят)


Да уж... тут же невоороженным глазом видно, что две суммы не сходятся...

Да всё сходится и на первой и на второй картинке , только найдите семь отличий, такое вот предрождественское развлечение. А вот в конец можно писать слово из трёх букв и всё будет нормально.

сдался вам этот USART. можно в фоне, ногодрыганьем. да - таймер лучше разгрести. слишком разные временные интервалы - пришлось в своё время отказаться от "универсального временного задатчика" - таймер подправляю на лету, в зависимости от нужного интервала. обработчик зависит от карты считываемой из флэша. получается некая аля стэйт машина молотящая в фоновом режиме необходимые команды, описанные (и корректируемые уже чисто отдельно в таблице). сами мат. вычисления происходят в "основном потоке". для этого добавлены такие команды как: ожидание, перейти на начало и несколько ещё специфичных...реально в боевом железе надо быстро сканировать все датчики (штук 6-8), посему они все на одном порту и за каждую секунду реальная картина необходимая для принятия решения каждый раз известна. разогрев самих датчиков обычно лежит в пределах 0,2 градуса и при необходимости повышения точности - можно учитывать при задании корректирующего значения после линии сборки на самом производстве изделий (характеристика резисторных датчиков линейна - так, что достаточно одной точки).
речь шла о мега128, кварц 14,7456 МГц но в своё время реализовывал и на 51 серии с кварцем 24 и тактовой 2МГц. работает на ура.

Стейт-машина - я понял Вашу идею!!! Спасибо!

На счет саморазогрева. У меня уличный датчик показывает температуру в пределах погрешности.

Два независимых термодатчика дома показывают температуру одинаковую, но несколько выше (на 3 градуса) относительно термометра с биметаллической пластинкой. В нем стрелка на циферблате показывает температуру. В чем может быть дело? Алгоритм обработки датчиков - везде один. Сумасшедний разогрев? Вряд ли, датчик - не печка. Могут влиять какие-либо другие факторы на цифровые датчики? Типа инфраизлучение, фаза луны и настроение мысли?)))

З.Ы. Почему я верю механическому термометру? Не верю. Но его значение сходится со спиртовым... В общем КС сходится, но появилась "погрешность"...

Купите TMP275A или LM92C - они проверено врут в пределах допустимого по даташиту с учетом всех этих виртуальных саморазогревов. И сравните с их результатом - будете знать, кто прав, а кто нет.

Дежа вю
http://caxapa.ru/378469.html
Вот вспомнил про него почитай

Мама моя женщина) Как все сложно/просто)

Кажится тревого ложная. Механический термометр показал сегодня температуру с разницей в один градус. Вчера дома печка топилас. Наверно у механики большая постоянная времени, и он просто не успевал за цифровым коллегой) Да и не могут два цифровика ошибаться. У них результаты сходились и сходятся с оглашенной погрешностью по даташиту (0,5 градуса).


Спасибо! Я учту предложение

Когда я только начинал применять DS18B20, в моем распоряжении был термошкаф с точностью поддержания температуры в 0.05 градуса. Вот установив там вентилятор, уложив кучку DS'ов и поверенный ртутный термометр с точностью 0.1 градуса в камеру, через часа 4 после включения выровнялись все температуры, и я увидел разброс между датчиками и образцовым термометром в 0.1 градуса. Проверил еще пару точек, все было аналогично. Правда, эти точки были выше 35 градусов (ибо холодильника не было).