A Particle Photon Temperature Sensor to Monitor Wood Stoves

Every project has it’s beginnings. Mine began with a simple hypothesis:

“Could I, using the Particle Photon, to monitor a wood-stove for a winter season running on two AA lithium batteries.“

So, there were two things to think about during this process

• Constraints of the batteries
• Functionality of the design

In order to get the best battery life, the system has to be in a very low power draw state most of the time. The best way to do this, especially if you’re, for example, reading temperature sensors on a consistent duration, is to power everything off except for a Real Time Clock (RTC) for time keeping and to power things on when it’s time to make a measurement.

The typical power draw of the RTC that I had development board was about 450nA (that’s NANO amps people!) at room temp. By the way here’s the specific part I’m using: NXP PCF85063ATL

Whereas the DEEP_SLEEP mode draws about 10x that at approximately 100uA. (When I actually prototyped everything, I was getting much more which could have been due to a slew of different factors..)

Either way, I wanted for this device to last a season of wood burning. Worst case 24⁄7 for folks who are in the northern boonies who burn all the time.

Get the puzzle pieces together

Here are the development boards that I used get everything up and running.

• Display
• RTC
• Si7021
• MCP9600
• PIR Sensor
• Particle Photon

Note: one of the main reasons for so many Digikey links is their mindbendingly fast warehouse. I can consistently get things in two days if I order before 8p CT. I don’t even bother half the time ordering directly from Sparkfun or Adafruit because they’re just too darn slow.

Two short days later, wiring them together took less than an hour and I was compiling some Hello World code within that same timeframe. It’s probably the fastest I’ve gotten functionality out of so many devices at the same time.

One of the reasons I was so speedy was because of the prototyping techniques used. As you can see above, I utilized both wire-wrap and a solder-less breadboard to make all the connections. I love wire-wrap enough that I wrote up a guide about it over at Circuit Dojo. Needless to say, you should get familiar with both if you haven’t already!

Now, some of you probably already clicked the links to the development boards above and nearly keeled over in your chair. They are a bit costly. For instance, the one that I bought for the thermocouple set me back about $75. But, was it worth it?

Yup, because if I spent the time on designing a board, spinning it, waiting for it to arrive, getting the parts, assembling it, and potentially finding issues, I would have been out a whoooole lot more money than that $75. Plus it already came with a thermocouple. 👌

Develop the code

Now that the “hard” part is done.. (get it) lets get to next step in our journey, The Software.

Between the Particle Reference documentation and the various data sheets for the parts I was using I was able to assemble the various bits and pieces to get every block minimally functional.

Let me save you some time and let you know what the default I2C addresses for each of the devices are because honestly we all know that’s half the battle right there.

#define RTC_ADDRESS 0x51
#define SI7021_ADDRESS 0x40
#define MCP9600_ADDRESS 0x60
#define DISPLAY_ADDRESS 0x70 

After figuring out what the address was for the Si7021 (humidity + ambient temp), only two commands have to be issued in order to get both ambient temperature and relative humidity readings.

Here’s the exact code I was using

uint16_t get_onboard_temp() {
 // Si7021 Temperature
 Wire.beginTransmission(SI7021_ADDRESS);
 Wire.write(SI7021_TEMP_READ_CMD); // sends one byte
 Wire.endTransmission();           // stop transaction
 Wire.requestFrom(SI7021_ADDRESS, 2);
 // Serial1.print("temp:");
 uint16_t temp_code = (Wire.read() & 0x00ff) << 8 | (Wire.read() & 0x00ff);
 uint16_t temp = ((175.72 * temp_code) / 0xffff - 46.85) * 100;
 // Serial1.printf("%dC", temp); // print the temperature
 return temp;
}
uint16_t get_onboard_humidity() {
 // Si7021 Humidity
 Wire.beginTransmission(SI7021_ADDRESS);
 Wire.write(SI7021_HUMIDITY_READ_CMD); // sends one byte
 Wire.endTransmission();               // stop transaction
 Wire.requestFrom(SI7021_ADDRESS, 2);
 // Serial1.print("\nhumidity:");
 uint16_t rh_code = (Wire.read() & 0x00ff) << 8 | (Wire.read() & 0x00ff);
 uint16_t rh = ((125 * rh_code) / 0xffff - 6) * 100;
 // Serial1.printf("%d%%", rh); // print the humidity
 return rh;
}

What’s handy for each of them is that the chip uses clock stretching to hold the processor in place until the measurements are ready. That way there’s no polling or interrupts to worry about. The downside is that it’s blocking (i.e. the Particle technically can’t run any of your code while it waits) but it doesn’t matter in such simple project such as this!

The thermocouple IC was similarly organized. It required a read first to make sure the data was available and then another read of the compensated “hot” register.

float get_thermocouple_temp() {
 // MCP9600 Temperature
 Wire.beginTransmission(MCP9600_ADDRESS);
 Wire.write(MCP9600_STATUS_REGISTER_CMD); // sends one byte
 Wire.endTransmission();                  // stop transaction
 Wire.requestFrom(MCP9600_ADDRESS, 1);
 uint8_t status = Wire.read();
 // Check to make sure the sample is ready
 if (status & MCP9600_UPDATE_AVAIL_BITMAP) {
   // Serial1.println("Sample is ready");
 } else {
   Serial1.println("Error: Sample is NOT ready");
 }
 // MCP9600 Temperature
 Wire.beginTransmission(MCP9600_ADDRESS);
 Wire.write(MCP9600_TEMP_HOT_CMD); // sends one byte
 Wire.endTransmission();           // stop transaction
 Wire.requestFrom(MCP9600_ADDRESS, 2);
 // Serial1.print("\nt-temp:");
 uint8_t upper = Wire.read();
 uint8_t lower = Wire.read();
 float temp = 0;
 // Depending on if its positive or negative
 if ((upper & 0x80) == 0x80) {
   temp = ((upper * 16 + lower / 16.0) - 4096);
 } else {
   temp = (upper * 16 + lower / 16.0);
 }
 // Serial1.printf("%f\n", temp);
 return temp;
} 

I digress, once things seemed to be minimally useful, I set my sights on the hypothesis I had yet to prove or disprove.

By the way, I did upload the code thus far to Github here. For those who are interested I also made a separate branch, called powertest for the power measurements described below.

Test my battery hypothesis

You would think this is simple, right?

The goal here was to determine through some measurements and through calculation whether or not my device would make it a full season of burning.

One thing anyone should ever do before creating a battery life constrained project is to take a look at the data sheet. That’s usually the first litmus test of performance.

What we’re most interested in is the WIFI+Processor on current.

If you were to run this device 24⁄7 without any power saving measures you’d need 518.4Ah battery to last a whole season. So that idea is definitely out of the picture.

So, I tweaked the firmware until I got it as optimized as possible.

• Power on
• Get measurements
• Connect to wifi and backend
• Push measurements
• Receive ACK
• Power off

Measuring how long this would take would be the deal maker or deal breaker. I used the transitions on the I2C as the start of them measurements and measured the output of my handy dandy uCurrent to see when it finally dropped off once done transmitting.

I saw results ranging from about 4 seconds all the way past 10 seconds. In most cases, if I waited about 30 seconds between updates, it would take about 7-8 seconds to update to the cloud. 8 seconds in the embedded world is a loooooong time.

I popped everything into the quick and dirty power model I made but kept running up against roadblocks. The frequency of measurements was important but I thought maybe when the burn is going good I could change the interval from 30 seconds to 5 minutes. That saved some power but even with that I could get maybe 64 days of continuous use and updates.

So, the hypothesis thus far is not looking good. At this point my investigations are on going but the idea of potentially updating 5-10 minutes of data at a time may save the prospect of running off of 2 lithium batteries.

This is an ongoing project so stay tuned. 😎

Originally posted on my blog here.