This is part 2 of a series of blog posts documenting how I designed and built a multi-node wireless temperature sensor system. Links to all of the posts in the series:
- Part 1: Requirements and general design
- Part 2: Sensor module hardware
- Part 3: Sensor modules software
- Part 4: The base station
All hardware and software files for the project can be found in my GitHub repository.
In the previous post I talked about how and why I selected some of the major components that went into the sensors. Now let’s cover the schematic and board design in more detail. Important disclaimer: I’m not an expert at electrical engineering, I’m just a self-taught hobbyist. I’m sure I made mistakes along the way. If you see something in my design that’s wrong, feel free to leave a comment with constructive criticism!
Here’s the schematic for the sensor board (click for larger version):
Let’s walk through it piece by piece.
In the top left we have the power subsystem with the MCP1700 regulator that I picked out. The MCP1700 needs 1µF capacitors on the input and output for stability, and general advice from people who have used the nRF24l01+ radio is that it benefits from a 100µF capacitor nearby to help satisfy current spikes as the radio turns on and off. I was a little worried about leakage current through the electrolytic capacitor but in practice it appears to be insignificant.
In the top right we have the AVR ICSP header that we’ll use to program the ATMega328P. In the lower left we have the pin headers for the nRF24L01+ radio to plug into.
The ATMega328P processer is in the bottom middle, obviously, and we have a decoupling capacitor on the power inputs and a pull-up resistor for the reset line. I debated whether or not to include the reset line pull-up, because it’s not strictly necessary (the reset line has a weak internal pull-up built in), but decided to go ahead and do it in order to avoid potential problems. I named and labeled the nets for the various data lines and didn’t run actual wires everywhere, which simplifies the diagram. I went ahead and connected the IRQ line to the radio and the ALERT line to the MCP9808 even though I have no specific plans to use them right now, but they’ll be there if I change my mind.
Finally, in the lower right you will find the MCP9808 temperature sensor and its decoupling capacitor, plus an indicator LED which is very useful for diagnostics and displaying various bits of information about how the sensor module is operating. I’ve made it a strong rule of thumb to always include at least one diagnostic LED on every board I make, whether I think I need one or not. It always ends up saving my hide at some point.
The MCP9808 uses I2C for communication and I2C requires pull-up resistors in order to work correctly. However, I really didn’t want to include external pull-up resistors on this board because a) that means more parts to place and b) the smaller the pull-up resistors are, the more current flows during I2C communication and we want to drive our current needs as low as possible. I ended up just relying on the internal 20KΩ pull-ups in the ATMega328P and hoped that would be sufficient given the expected low capacitance of the data lines. (Spoiler alert: it was, just barely. More on that later.)
Here’s the board layout (click for a larger version):
This is a two-layer board with a ground plane on the bottom and traces on the top. I tried to minimize the number of traces on the bottom because they can break up the flow of return ground currents if poorly placed but I did have to use a few. Making a good board layout is definitely an art form, and it probably helps if you’ve played a lot of Tetris. For me, anyway, it’s largely a process of trial and error. I start by grouping things that are connected to each other close together on the board, then I nudge things around and rotate parts trying to get the minimum number of crossed wires. There are certain tricks you learn, like a resistor or capacitor gives you a free bridge to get from one side of a wire to the other, but mostly it’s a giant game of “what if?”
The power connector pads are sized for a standard terminal block but I pretty much ended up soldering the battery pack wires directly to the pads in order to save time and vertical space.
The ICSP header block can be populated with pins or left empty; I have a nice little pogo pin ICSP adapter that allows me to just touch the adapter to the ICSP pads on the board and quickly program the board. (More about programming in a later post.) The 100µF capacitor is a small 10V model that isn’t very tall. The radio gets soldered directly into the 2×4 header in the middle of the board such that the body of the radio module is to the right of the header. (As I was writing this I noticed that I didn’t do anything to mark that in the silkscreen, which is a mistake I should fix.)
The physical dimensions are roughly 42mm by 18mm, which is nice and small. There’s one mounting hole and I rounded the corners of the board a bit to make it look nice.
I had the boards manufactured by OshPark (project shared here) and it cost me $5.75 for three of them, which is mind-blowing. This really is a golden age for hobby electronics. Everything worked on the first try, which I was pleased with.
This was one of my first SMT projects and I learned a lot about SMT soldering techniques. My purpose here is not to write a general SMT soldering tutorial because there are lots of excellent ones already available and I can’t improve on them, but here are some general tips that were particularly useful for me:
- Watch a lot of how-to videos on YouTube. Don’t stop with just one; each video adds something unique and gives you a better overall picture of how it works.
- Liquid flux is an absolute must-have. If you try to skip it, you’re going to have a bad time. Trust me on this.
- Use a small pointy tip on your soldering iron for soldering small components like resistors and capacitors. Apply a bit of solder to one pad, then slide the component onto the pad from the side while reflowing the solder, then do the other pad. You might touch up the first pad with a bit more solder or use some liquid flux to get a great joint.
- A hoof tip for your soldering iron makes drag soldering the processor package a breeze (as long as you use lots of liquid flux!)
- Don’t stress too much about solder bridges when doing multi-pin packages. They’re really easy to fix with solder braid if you mess up.
- Remember that the LED is a polarized part so orientation matters. Different manufacturers do different things to mark the anode and/or cathode so there’s not just one reliable standard. Carefully check the datasheet for your specific LED, or even better, if your multimeter has a transistor testing function, use that to light up the LED before you solder it and confirm for certain which direction the current flows through the part.
- I didn’t find solder paste and a hot air gun to be as effective as I expected. It worked pretty well for small components but for multi-pin packages I had a hard time manually applying just the right amount of paste to prevent solder bridges. A paste stencil would work better, I’m sure, but I didn’t bother with that. Hand soldering on a small board like this is just fine.
- Practice, practice, practice. You can buy inexpensive SMT soldering practice kits on EBay which allow you to solder to your heart’s content without worrying about destroying anything valuable. Highly recommended. The ones I bought on EBay were literally junk; they were just pads and parts and didn’t create a useful circuit. That was fine – it gave me freedom to experiment without fear. The ones I linked above appear to result in some kind of functioning circuit when complete which would be nice to tell you that you did it right, but then you have to worry more about messing up.
Here’s what the sensor module looks like when assembled (except for the radio):
And here is a shot with a bare board, an assembled board minus radio, and an assembled board with radio and attached to a battery pack:
I mentioned earlier that I left out the usual external pull-up resistors on the I2C data lines, hoping that the ATMega328P internal pull-ups would be sufficient. After I assembled and programmed a sensor board I double-checked the bus timing with my oscilloscope and it turned out that I bet correctly, just barely. The I2C spec says that for a standard rate data bus (100 kbit/s), the maximum rise time must be 1µs or less, where rise time is defined as the time it takes to go from 0.3VDD to 0.7VDD. In our case VDD is 3V, so we’re looking for the time it takes for the rising edge to go from just under 1V to just over 2V. It turns out that we’re squeaking in just under the limit:
That’s good enough for my own personal use. If I were designing a commercial product I would want a bigger margin of safety there.
When I tested the sensor module before adding low-power sleep modes to the software, I found that the processor would actually heat up the board a bit with its dissipated power and skew the temperature readings upward by about 0.5°C. It’s not a big effect but it’s a noticeable error with the MCP9808 that I’m using. At first I thought I would need to redesign the board to include isolation slots to better shield the temperature sensor device from the rest of the board, but then I found that adding low-power sleeps between sensor readings reduced power dissipation enough that any remaining skew was insignificant, so that crisis was averted.
I’ll save an in-depth discussion of low-power sleep modes for the post on the sensor module software, but here’s the general idea. The software puts the processor, the radio, and the temperature sensor to sleep and sets a timer for eight seconds. When the timer fires, the processor wakes up, wakes up the radio and temperature sensor, gets the current reading, and sends the data. It then puts everything back to sleep for another eight seconds.
Here is the best result I was able to achieve during the eight-second sleep time (measured with an EEVBlog µCurrent):
The µCurrent was set to the µA range, so every µA of current across the input terminals produces 1 mV of voltage across the output terminals. As you can see, I’m using 6.3 µA of current during sleep, which is great.
When the system wakes up to take a measurement and send data it uses more current, of course. To characterize that transient behavior I hooked up the µCurrent to my oscilloscope. I switched the µCurrent to the mA range, but the active current draw (and thus voltage signal) turned out to be right down in the noise for the oscilloscope. I heavily filtered the signal and was able to get an idea of the duration (about 12 ms) and current draw (a quick spike to 23 mA then steady at ~14 mA for the rest of the wake period).
14 mA is a lot of current, relatively speaking, but the length of time we’re drawing that kind of current is quite short. If I did my math right, it averages out to about an extra 1.5 µA over the course of an eight-second cycle, so our average current draw over time is approximately 8 µA. The self-discharge rate of an AA battery is also roughly 8 uA so the life of our batteries is going to be 50% of what it would be if they were just sitting on a shelf, which is to say that the expected lifespan of these sensor modules is well over a year, at least. We’ll see if it actually turns out that way in practice but I’ve had three sensor modules running continuously since March and their batteries are still going strong so things are on the right track.
Current measurement side notes
Characterizing current draw for a low-power device can be tricky because of the dynamic range of the current draw over time. In my wireless sensor, the difference between the sleep state and the peak active state is three orders of magnitude (~3,650x). The µCurrent is a great device but its measurement ranges cover nine orders of magnitude (1 nA to more than one amp) and compromises must be made. The maximum voltage output of the µCurrent is 1.4V so you can measure up to about 1.4mA on the µA range for example (giving an output of 1.4V) then you have to switch to the mA range (giving an output of only 1.4mV). A 1.4mV signal is going to be completely lost in noise on an oscilloscope so now you’re stuck in a very awkward position if you want to measure fast transients. I don’t know of a great solution for this problem; maybe a secondary amplifier to boost the signal into a range that the oscilloscope is happy with?
Also, doing extremely low-current measurements is really tricky because external noise can easily swamp the signal you’re trying to measure even if it’s supposedly at a good level for your test instrument. At the nA range, every test lead is an antenna pulling in all kinds of EMI and you have to be very careful how you set up your experiment. It’s super-easy to get nothing but nonsense from your instrument if you do it wrong.
I think that’s all I wanted to cover for the sensor module hardware. Next time we’ll talk about the software that makes it do useful stuff.
3 thoughts on “Building a wireless temperature sensor network, Part 2”