- Mon May 07, 2018 2:55 am
#75811
I was running two DS18B20+PAR temperature sensors without any problems for the last two years on an ESP-01 module running on 3.3V using a 4.7K pullup resistor.
Now, wanting to develop a new firmware I started the development with new versions of everything (Arduino IDE and libraries), but now, with the exact same hardware setup that worked flawlessly for two years, the sensor always returns 85°C (error code for reset during conversion). I suspect that somehow, I don't know how, the ESP does not leave the data pin powered anymore.
To test this, I recompiled and flashed my old firmware that was running fine for two years and lo and behold, it still returned 85°C. Trying to isolate the issue, I flashed the old binary of the firmware and it returned the correct temperatures again.
To isolate the issue further, I tried numerous versions of the OneWire (2.3 to 2.3.2) and DallasTemperature (3.7.3 to 3.7.9) libraries, but to no effect. I am still getting 85°C all the time.
I also tried to compile it using Arduino IDE and PlatformIO, but both yielded the same issue still.
Trying on another ESP8266 (Wemos D1 mini and nodeMCU) did not change anything.
Slowly I am suspecting that the issue lies in the ESP8266-Arduino framework updating something or a change in the compiler, which now breaks keeping the data pin configured as output during the conversion.
A workaround, of course, is to use a lower value pullup resistor so that the sensors take power through that instead of the powered microcontroller pin. (One parasitic sensor requires 1K, two 470 Ohms) But this is not a solution.
I will update this issue in the following days by testing on other platforms (older Arduino IDE, older Arduino-ESP8266 version, different OS) and hooking a oscilloscope up to the data line to see if the issue really lies in voltage sag during conversion.
Also, I want to try out the OneWire library fork from orgua to see if the issue happens in his library too.
So, to conclude: I can rule out a hardware isse, I think it's not an issue with library versions and I suspect something in the ESP8266-Arduino framework or Arduino IDE (compile options).
I am looking forward to help fix this issue soon.
Now, wanting to develop a new firmware I started the development with new versions of everything (Arduino IDE and libraries), but now, with the exact same hardware setup that worked flawlessly for two years, the sensor always returns 85°C (error code for reset during conversion). I suspect that somehow, I don't know how, the ESP does not leave the data pin powered anymore.
To test this, I recompiled and flashed my old firmware that was running fine for two years and lo and behold, it still returned 85°C. Trying to isolate the issue, I flashed the old binary of the firmware and it returned the correct temperatures again.
To isolate the issue further, I tried numerous versions of the OneWire (2.3 to 2.3.2) and DallasTemperature (3.7.3 to 3.7.9) libraries, but to no effect. I am still getting 85°C all the time.
I also tried to compile it using Arduino IDE and PlatformIO, but both yielded the same issue still.
Trying on another ESP8266 (Wemos D1 mini and nodeMCU) did not change anything.
Slowly I am suspecting that the issue lies in the ESP8266-Arduino framework updating something or a change in the compiler, which now breaks keeping the data pin configured as output during the conversion.
A workaround, of course, is to use a lower value pullup resistor so that the sensors take power through that instead of the powered microcontroller pin. (One parasitic sensor requires 1K, two 470 Ohms) But this is not a solution.
I will update this issue in the following days by testing on other platforms (older Arduino IDE, older Arduino-ESP8266 version, different OS) and hooking a oscilloscope up to the data line to see if the issue really lies in voltage sag during conversion.
Also, I want to try out the OneWire library fork from orgua to see if the issue happens in his library too.
So, to conclude: I can rule out a hardware isse, I think it's not an issue with library versions and I suspect something in the ESP8266-Arduino framework or Arduino IDE (compile options).
I am looking forward to help fix this issue soon.
