AM2315 Update

Hello to all my smoke-eating Maker friends. O’l Sopwith has a story to tell. In my February 1st post, I posted the pure Python source code and updated the implementation documentation for the ever-so-popular AM2315 temperature sensor.

I did this after receiving an Email from a fellow Maker who wanted to know why my sample AM2315 code did not work with Python3. The day after I published that blog entry, a comment was posted stating they could not get their sensor working. The AM2315 was visible in the i2cdetect test, but it would not return any data. The Python code crashed and burned.

About a week of communicating back-and-forth to troubleshoot the problem, this is what we did:

  • Turned on Debug mode in the python script
  • Made sure the device was wired correctly
  • Made sure the correct software was installed
  • Disconnected all other devices from the Pi
  • Ran the SwitchDoc Labs test script (same stack trace)
  • Ensured the Pi had a 2.0 amp power supply

About the same time this was going on, the mate who asked about the Python3 port downloaded and tested the new code. He could not get it to work either. Thinking he had a bad sensor, he set up a test harness and tested his sensor on an Arduino. It worked fine. After some fiddling around, he determined the MAXREADATTEMPT = 3 on line 23 was too small a value. He changed it to 10, and his sensor worked fine.

This code change immediately fixed the other problem I was working on. I have updated my source code and reposted it to reflect this change.

It interesting to me that the MAXREADATTEMPT = 3 setting worked fine with my AM2315. I have never had it fail. It clearly does not work with some other devices.

The technical reason for this is due to the fact that the digital output of the Pi GPIO was really never meant to work with a device like the AM2315. Because of timing issues, in software, the Pi has to do what is called ‘bit-banging.’ This essentially means you have to shoot signals to the device and hope the timing signals are ‘close enough’ to get it to respond. If the timing is off, then you either get back no response or garbage. That is why you have to use a loop to try multiple times to get the right response.

The default loop value in the original code only tried 3 times and this was not enough for some devices. I am glad that two Makers can move on with their projects and put the AM2315 to work.

Lesson learned? Never, ever give up on a problem until you solve it. Don’t be intimidated because you do not know what to do. Try something! Also – ask for help. One more thing – most electronic devices today are manufactured to such high standards, they rarely fail. If they are going to fail, they usually do so in the first few hours of use. Most of the time in the first few minutes. After that, they almost always provide years of service.

Unless of course, you do something that makes them emit smoke.


1 thought on “AM2315 Update

  1. I’ve upped the Max retries to 10 in the main archive:

    We are still tracking a rare issue on both ESP32 and Raspberry Pi based systems where the read fails or give the wrong data (very, very rare – but it is with a good CRC which is very odd) typically like a bit flip (2,4,8,16,or 32 degree C error).

    We are thinking that increasing the max tries to 10 may help the first issue, although it is not clear to me that we aren’t masking a symptom instead of the cause.

    Thank you for your help!


Leave a Reply

Your email address will not be published. Required fields are marked *