Температурная нестабильность при получении ID для DS18B20
- Войдите на сайт для отправки комментариев
Обнаружил интересную проблемку. Датчик DS18B20 подключен к Мини по 2-х проводной схеме. Все, больше ничего.
В сетапе производится поиск подключеного датчика и определение его ID.
В лупе датчик постоянно опрашивается по ID результаты пихаются в Serial. В общем простейший термометр, ничего более.
Работает как задумано. Но в процессе эксплуатации обнаруживается, что ребут при горячем датчике приводит к неполучению его ID. Наблюдается изредка при 88С, чем теплей, тем чаще и стабильно при 96С и выше. Но трабла только при получении ID, если охладить, получить ID то температура получается корректно и при 99С.
Предположил, что интервалы в протоколе плывут при нагреве. Похоже так и есть, но обнаружилось это на приеме 0 с датчика при получении ID. Там при получении ID хитрый алгоритм для арбитража при нескольких датчиках, у него есть невозможная ситуация, в которую и влетал.
Решилась проблема сокращением интервала до опроса ответа датчика после подема шины. По даташиту там до 45мкс, я работал на 8мкс, теперь стало 4мкс.
Отака фигня.. проверяйте работу во всем диапазоне.
ПС. Призадумался, по даташиту резистор подтяжки шины 4,7КОм, я поставил 2,2КОм, что было под рукой, может и это повлияло.
Попутал маленя, по даташиту там не до 45мкс а от 1 до 15мкс. Потому и было 8мкс - среднее, дискретность 4мкс.
Подтяжка могла повлиять, выходному транзистору датчика получается нужен больше ток для открытия
при одном датчике на шине в общем то ID не нужен совсем
одном датчике на шине в общем то ID не нужен совсем
Как бы да, но либа универсальная, на N датчиков и в дальнейшем в этом проекте тоже 2 нужно. Второй в нержавеющей трубке все никак с китая не доедет. Потому сразу и делаю с ID.
А роль подтяжки интересна, не часто встречаются даташиты с четко указаным номиналом для такой цели. Может и не зря так, по идее он должени зависить от сопротивления и емкости линии. В общем непонятно до конца, и не охота лезть в работающее устройство ради эксперимента.
Понимаю, что лезть неохота, но я не понял проблема ушла или нет?
я не использую универсальный код ибо тогда библиотека бывает жрет слишком много памяти. Обычно это несколько кб. В моем случае когда нужен всего один датчик на линии код требует меньше 0.5 кб
Ушла. С утра ушла и пока не вернулась ;) Будущее покажет на совсем ли, но учитывая стабильность воспроизведения и резкое исчезновение, то думаю да.
Лишнее ОЗУ?! Ни-ни. Ни на грамм, тьфу, байт (эти праздники - писец). Сам для себя писал, все оптимально, это вобще либа таймера, к нему обявляется таблица устройств, совместно использующих таймер одно из них OneWire, там вcе четко.
Не озу, флэш
А по флешу вобще без разницы, с чего код дублировать? Ну разве что из лупа вызвать где надо опрос одного датчика, потом второго. Такито это будет один вызов, только указатели на ID и буфер для результата будут менятся.
А по размерам общим посмотрел, прога тянет на 5,8КБ, убрал вывод в Serial, стало менше 4, убрал поиск на шине, типа по прописаному константой ID менше 3. В общем более чем устраивает.