Skip navigation

So I mentioned in a previous post that I was getting the occasional bad reading from the DS18B20 temperature sensor that I was using to monitor beer fermentation.  I noticed the issue because I was getting very ‘choppy’ temperature profiles.  It was obvious that really low temperature values (in this case it turned out to be a value of -0.06, not sure why) were getting averaged into the temperature readings (the system averages 60 readings at an interval of approximately 1/sec, and then sends that average across the network).  While I was aware of the issue pretty soon after getting the system up and running, I was a bit pressed for time and decided to put fixing the issue on the back burner.

LoggerIssue

Example of the impact of the bad reads. Every few minutes, a bad read would get averaged into one of the data points, causing the temperature to appear lower, resulting in this ‘spiky’ profile.

Coincidentally, the issue ended up fixing itself (sort of).  After a few successful trial runs, I added an additional temperature sensor to the Arduino, and  in order to be able to identify the data coming from the two sensors, I needed to pull the serial addresses.  Turns out that the bad reads that I was getting also resulted in a bad address, so I added some code to throw out that data.

LoggerIssueFixed

Notice how the fluctuations are on the order of magnitude of ~0.1 degree F, as opposed to ~1 degree F previously. Much better!

So I should probably mention that this entire issue would have been avoided if I had just copy and pasted the Arduino sketch code for the DS18B20.   In the example code, they have a few different checks, such as a check that ensures the sensor is of the right type, as well as a CRC (cyclic redundancy check) validation.  The CRC is very similar to a checksum,the senor performs a mathematical operation on the data and then sends along the value (the CRC) of the operation.  This allows the person to verify that the data was successfully transmitted by re-performing the operation and comparing it to the CRC value.  If the values do not match, it probably means that there was an issue with sending the data across the wire.  The code in question is below.

 if ( OneWire::crc8( addr, 7) != addr[7]) {
      Serial.print("CRC is not valid!\n");
      return;
}

Had I included the above code in my sketch, this issue would have been avoided entirely.  But considering I am doing this project for fun and for the experience/education, I think writing the code from scratch is a good thing to do.  I have certainly created some unnecessary bugs with this approach, but I have also learned a lot more by not copying and pasting code.  But this is also a good lesson in making sure to inspect example and tutorial code very thoroughly to ensure that you are not leaving out anything important.  In this case, leaving out the sensor type check code (the one wire library can work with multiple digital sensor types running on the same pin) made sense because I knew I was only using a certain type of sensor.  Nut leaving out the CRC validation was a bad call.

  • Transferring the Single Hop Cascade and Single Hop Simcoe to secondary.

I brewed two more one-gallon batches of Single Hop Pale Ale.  I used Armarillo in one, and Sorachi Ace in another.  Looking forward to drinking these.  I’ve got a lot more work to do on the project, and will try and fit it in here and there, so stay tuned.