This project's goal is to develop and build a temperature logger that can:
• Sense temperature with close to 0.1°C accuracy,
• Sample temperature every 10 minutes exactly,
• Store records for at least 180 days,
• Operate for at least 180 days on a coin cell battery,
• Easily transfer data to a computer via cable,
• Fit in a dirt-cheap watertight case,
• Cost per unit less than €5, including case.
I will make two of each prototype designs and then produce a batch of fifty for sea turtle nest incubation research.
The MCU chosen for this project is the Atmega328PB simply because I'm familiar with it and it fits the requirements. I could also use the Attiny817 but the cost difference isn't worth the learning time.
Temperature is one of the primary factors for sea turtle egg incubation success as well as sex determination. While a lot is already known, the onset of climate change makes more research a priority to mitigate the impact of increasing temperatures and changing climate patterns across sea turtle nesting habitats.
One of the challenges is the collection of enough data for statistically robust results. Deploying a large number of loggers is only an option for large institutions. Even there, researchers want to stop using them after they've lost a few in the field.
While I'd still recommend buying a commercial logger for anyone who just needs a few, I specifically started this project with the goal of building 50 units without the need to seek external funding.
The temperature sensor used in this logger fits four requirements: High accuracy, digital output, small footprint, and low cost. The MAX30205 has an I2C interface. A sensor with an analogue output would require a small army of external components to achieve anything over the AVR's 10-bit resolution. This wouldn't fit with the size restrictions but would also consume too much power. The above sensor can achieve 16-bit resolution at a fraction of consumption and cost. While choosing, I was also considering Silicon Labs' Si7051 and Texas Instruments' HDC1080. I preferred the MAX30205 because it had more details on accuracy over its operating range, which is preferable for scientific research.
The temperature sensor gives its reading in two bytes. 180 days of ten-minute readings need 414720 bits plus some extra, so a 512kbit memory will do. The cheapest memory chip that's not a SOIC8 is Adesto's AT25DN512C. That comes in a TSSOP-8 package, which is small enough. The same package is available in up to 4Mbit versions, so extra memory can be used if needed.
The WSTL18 temperature logger is slightly larger than a CR2032 coin-cell battery. With most of the Atmega328PB's pins broken out to headers around the board's perimeter, it doubles as a coin-cell development board.
To make expansion shield making easier, I've made a template shield with all pins labeled. The entire board plus shield will fit in a readily available 5ml acrylic jar, as long as common-sized components are used. For anything larger, such as a LoRa module or LCD screen, you'll have to find another casing solution.
The shield includes a milled opening not seen in this rendering, to allow access to the uart connector pads on the WSTL18 below.
The shield template is available in Eagle format on the project's Github (go to Eagle -> WSTL18_SHIELD).
The WSTL18 uses an AVR microcontroller. Its in-system programming interface, whose six wires include the SPI, power lines, and reset. Those have all been broken out to a 6x1 1.27mm header for programming as well as availability of the SPI to any expansion shields.
Connecting single-core wires to the headers is ok for code development on a prototype, but not practical at all for (workshop) production programming, so I've designed an adaptor for the regular 2x3 ISP header.
On the board side, to the right, I placed both a 6x1 1.27mm header as well as long smd pads to solder pogo pins on, something like this but with all six pogos in a row.
On the AVR programmer connector, on the left, I've placed a traditional 2x3 0.1" connector as well as a 0.1" edge connector. This flexibility wasn't required but I've wanted to try these connections for a while, so this was my chance. I've added the eagle files for this on the project's Github ( go to Eagle -> WSTL18_ISP).
I've now hooked up the temperature logger's AVR ISP cables (right above) to program the device, as well as the uart through an FTDI cable to my computer to test and develop the data exchange protocol with the help of some python code. Of course on a working device this will be done with a special connector, but I'm not making one just yet because the pads have changed between the first and the second prototype designs, but I've only built the first prototype. The code won't need to change much, so this setup is fine for coding. I'm also planning to make the firmware user-updatable through the uart by use of a bootloader, so regular users will only ever need one cable. But that's another story...
On the right, above, you'll notice a loose cable almost touching the right-most header. I've done this to simulate the fourth connector, which on my designed second prototype will short pin PD2 to ground, allowing the mcu to detect when the uart cable is connected. And that's also another story.
The connector board, firmware, and computer software will all be open-source and added here in due time. There's a long way ahead!
(Check out the Github for the current firmware state and eagle files)
After applying a few lessons from the first prototype, feedback from this wonderful community, and a few thoughts of my own, I've come to a point where I consider the second prototype of the WSTL18 temperature logger complete. I hope this will be the final design, minus any bug corrections.
I didn't change any components or functionality of the logger. The main correction I made was to make the SMD pad stencil openings (cream layer) smaller because the stencil I made for the first prototype allowed too much solder and caused bridges all over the place, so I had to fix the first assembled board and remove solder from the other two before placing the components on.
Most other changes are related to the headers around the perimeter of the board, the UART connector pads, and the battery holder pads. Here are some of the main changes from the first prototype:
1. The TWI/I2C traces are now accessible via the headers. I also placed a VCC and a GND header right next to them. This will allow adding other sensors or even low-power LCD screens. Bobricius mentioned using this board for a watch and voja wants to make a LoRa expansion shield, so this shield should make expansions like this easier.
2. I added a fourth pad to the UART connector. This is connected to pin PD3 on the Atmega328PB, which is the INT0 interrupt. That's available in power_save mode, which will allow the uart to be switched off during power_save, allowing further power savings. Notice that the holes on each pad are just holes, not vias. Vias would allow any of these traces to contact the battery on the other side. Holes remove that risk but still allow centering of pogo-pins or even one-side soldering of 0.1" headers. I don't plan to do the last one, but it's an option.
3. For the battery holder, I added two through-holes on each cathode pad but also left the SMD pads there (right). This allows the use of either the SMD version of the battery holder, which can be machine-assembled, or the through-hole version which can be hand or wave soldered but has a stronger hold on the pcb. I also changed the anode (GND) pad from two near the center of the board to one elongated pad at the center of the board (Left, many thanks to Zequing for this suggestion). The elongation serves to prevent any unwanted contacts while the battery is inserted or removed. That's still much smaller than the battery itself and must be flooded with solder to create a mound slightly higher than the pcb's solder mask
4. I moved the LED over to the left side of the pcb so it's close to the VCC trace. I've added one more resistor pad after the LED, so now there's one connecting to GND and one to VCC. This allows the user to place one resistor on either pad and place the LED in forward or reverse direction to select if the LED will be HIGH-ON or LOW-ON. The LOW-ON configuration may have a slightly lower current leakage. I haven't tested this claim but if a leakage current difference is there, it will be present at all times so it's worth testing.
5. I added a 0402 capacitor pad on either side of the RTC crystal. The crystal I selected has very low capacitance so there's no capacitors needed (as far as I understand) but I thought I'd place those capacitor pads there just in case.
6. I disconnected the EEPROM's WP (write protect) and HOLD pins from VCC. Adesto's datasheet specifies these are internally pulled-up to VCC but "whenever possible they should be externally connected to VCC". I went with the disconnect option to simplify the PCB and allow more margin space for the other traces. I don't think this is a noisy enough environment for this choice to cause bugs.
You'll notice there are no labels on the board. There's just not enough space to add labels without making the board look cluttered.
Eagle cad files are available on the project's Github repo (go...
I found a quarter laying around, so I thought I'd take a couple of photos for size comparisons. Here's the WSTL18P1 with a quarter on its left, a euro on its right, and the case it's been designed to fit in at the top. The lid and a CR2032 battery are also seen at the bottom.
With a 0.922 inches diameter, the WSTL18 is just a few mils smaller than a quarter (0.955 inches) and just narrowly larger than a euro (0.915 inches). The next photo gives a closer comparison between a quater (left), a euro (center), and the WSTL18 (right).
On the first prototype of the WSTL18, I've placed three pads for uart connection. Rx at the bottom, Tx in the middle, and ground at the top.
But how will the microcontroller know when the cable has been connected so it can listen for commands?
My first thought was to have the uart receive interrupt enabled, so the computer on the other end can just begin sending commands at any time. The problem with that is that uart is not allowed at "power save" mode, which is the lowest power consumption mode that will allow the real time counter to run. So that's out of the window because any higher power mode will kill the battery.
A second thought was that each time the mcu wakes up, which is every eight seconds clocked by the real time counter, it can send out a character over the uart and see if someone will respond. This means that the uart module has to be powered on every eight seconds, which will also reduce battery life, though not as much as the original option.
Finally, I decided to use a fourth pad that will make pin PC3 of the AVR available. The pin will be an input with the AVR's internal pull-up enabled. The uart cable connector will have to short this pin to ground. Every eight seconds, the mcu will check pin PC3, and if it is low it will mean a uart cable is connected. The mcu will then send a "ready" character, and the computer on the other end will have a 10ms timeout to send a preset command, such as "begin logging" or "dump all logs", etc.
This means I'll have to add one more pad connected to PC3 on my next prototype, but for the moment that's available for prototyping on the marked header around the logger's perimeter.
Any thoughts or experience on ultra-low power cable-connected detection please comment below!
I recently received the stencil for WSTL18 from OSHStencils. With only a handful of components I already had waiting on my workbench, I was able to quickly assemble three prototypes.
The four main components are the microcontroller (Atmega328PB) at the center, temperature sensor (MAX30205MTA+) at the top, non-volatile memory (AT25DN512C) at bottom-right, and real-time counter crystal (ECS-.327-7-34B-C-TR) on the left. The rest are decoupling capacitors, pull-up resistors for I2C, the temperature sensor's interrupt line, and the reset line, a light-emitting diode indicator, and a current-limiting resistor in series with it just under the logo.
A soldering trick for the coin-cell battery holder
The only component on the back of the PCB is the battery holder.
The battery holder only connects the positive side of the battery. Lynx, the maker of this battery holder, specifies that almost the entire side of the board under the battery holder should be a flat contact for the negative side of the battery. With a 2-layer PCB, this would make it impossible to make all necessary connections without going around the battery holder area, which would mean the PCB should be much larger than the battery. To avoid this issue, I only designed two narrow strips as battery contacts on the PCB, but flooded them with solder to create a mound and allow a good contact with the battery. The battery rests on the mounds and doesn't contact the rest of the PCB, which is also covered by the solder mask, as long as the vias are covered. The battery holder has to be hand-soldered last. On this prototype I'm using the surface-mount version of this battery holder, but I've already changed the next prototype's design to the through-hole version to ensure a stronger attachment to the PCB.
With all components assembled on the board, the WSTL18 fits snugly in a 3ml acrylic screw-cap vase.
The connectors on the bottom-right are the six AVR in-system programming lines. For now, I'm using six narrow cables to bridge my Atmel-ICE to them. In the long term I plan to create a special connector but may redesign mCU programming options entirely.
I programmed a simple blinking program as an initial check that the board is operational and it's working just fine using the real time counter.
My first concern with the PCBs was to see which case they would fit in. And by case I mean acrylic cosmetic lotion jar, like the ones you can see below.
The distributor's website only listed their internal volume (Left 5ml, right 3ml) and their external diameter, so I had to calculate the internal diameter by counting pixel on available photos and intrapolating from the external diameter. I also had to guess a margin because these jars tend to get narrower towards the bottom.
The 5ml jars are only a couple mm wider than the 3ml ones, but they are considerably taller so I'd prefer the PCB to fit in the 3ml jar. And it did.
It fits so well that it can't move at the bottom. Once the battery holder is soldered on the underside of the board, there should be half a mm or so of marginal space.
I like these jars because of their very low cost (€0.35 for the 3ml ones, €0.21 for the 5ml ones) but also for their ease of use - just a screw-cap to open/close them. No screwdriver. However, they are certainly not waterproof, and I need them to be.
Since these temperature loggers are going to be inserted in the sand and left there for anywhere between two and six months, regular opening won't be required. To keep costs low, I'd prefer to add a small amount of food-grade silicone (so no contamination will be caused to the environment) on the thread before screwing the cap on. After the data logger is retrieved, the seal can be easily broken open and discarded. The loggers will have to wait for at least 12 hours for the sealant to cure before deployment. Luckily, deferred start of logging should be an easy feature to implement.
Next I plan to hot-plate solder a couple of boards and begin programming them, but also to perform some testing on the sealing process mentioned above and the results in water-tightness.
Last weekend, I ordered parts for the first prototype from Mouser and PCBs from Seed Studio. I also ordered a stencil for the top side from OSH Stencils. The parts arrived first, and while waiting for the boards I made a print-out to verify the battery holder fits well on the circuit board.
I opted to use a CR2032 battery because it's a good combination of size, capacity, and low-cost availability. The BAT-HLD-001 holder by Linx offers smallest footprint and by far the lowest price between holders for this battery. I've placed it on the bottom side of the board, so I'll have to assemble the device's top side first and then solder the battery holder on the bottom.
The battery holder attaches to the board with SMD pads, but on the next prototype I'll use its available through-hole version (Linx BAT-HLD-001-THM). That one will be easier to hand-solder, will allow slightly smaller board size, and will have a stronger hold on the board, which can help since the device will be handled during battery change and data transmission.
The battery holder is the largest part by far and alone defines the size of the board. All other parts can easily fit on the other side of the board.
The next smaller available battery that's between 2.7V and 3.3V is the CR1632 at 140mAh, which isn't bad and saves 4mm. But changing to this battery would have a few drawbacks: the cheapest battery holder for that size is €0.30 more expensive than for the CR2032 and batteries aren't cheaper. You also can't find a CR1632 at a corner store, but you can find a CR2032 almost everywhere.
Most importantly, I currently don't have a reason to switch to a smaller battery because the CR2032 will fit in the dirt-cheap case I've selected, and a smaller size of that type of case isn't available. I'll discuss the case in my next post.
A final word on this battery holder and my design: In my previous post I discussed making 14 MCU pins available near the edges of the board. I had to use 1.27mm (0.05") pitch holes, but at the time I didn't think that the battery holder would be right over the holes.
This only occurs on one side, as the other side of the holder is open for battery insertion. I've included the 1.27mm (0.05") header here to show that if it was inserted in the holes it would touch the holder, which is the positive battery pole.
On the other side, the headers wouldn't touch the holder but the battery would touch them while inserted or removed. To solve this problem, one can do one of the following:
Don't use the pins, this is a temperature logger, not a development board. This will apply to most cases.
Clip the header's underside after soldering and before placing the battery holder.
Don't insert the headers all the way in. Keep them flush with the underside. This is probably the best solution.
Don't use headers. Insert any cables directly into the pcb and solder carefully. Limits reuse.
On the side seen above, bend the battery holder's flap. Will make battery placement a little tricky but won't solve the problem of contact during battery insertion/removal.
Use a really thick PCB. Those are really expensive. Not a serious solution.
Also, in the rare case you will use this as a development board, use female headers, not male as seen here.
A handful MCU pins are enough to implement a temperature logger; Two connect to the sensor via I2C and one more for the interrupt option, four for SPI to connect to the memory chip, two for UART to extract stored data, change settings, user firmware update etc, one for the reset pin for in-system programming (plus SPI), and one for a blinking LED. Add two for the real time crystal and all the power pins and on the 328PB this leaves 14 pins unused.
Before: 14 pins were left unused.
I could go for a lower-count MCU but the only AVR that fits all requirements is the Tiny417/817. This is a new chip and uses some different concepts, which would mean a steep learning curve. While this is an option for future models, I don't have time for it at the moment as I need to produce 50 and program them for deployment by next summer in my spare time.
This leaves me with 14 unused pins, so I opted for making those accessible. I had to redesign the layout to make way for all these lines but, at no cost difference, this temperature logger can now double as a coin-cell powered development board.
After: All MCU pins are used or accessible via 0.05" headers.