Author
Topic: Tino, the tiny coin cell mote (Read 13130 times)

After all the coin cell and listen mode discussions here on the forum I finally have my first "Tino" ready. Very similar to Tom's TH Mote (https://lowpowerlab.com/forum/index.php/topic,1254.0.html it has a slightly different design objective: I wanted a board that could serve as thermometer/hygrometer just as Tom's - but I also want to use them for all kinds of other projects, similar to what I do with Moteino's today (Okay I admit these are all excuses for not delivering the sexy round shape and the wood finish ).

The focus of this 2.5cm x 2.5cm board is battery operation and particularly coin cell operation. I solder on an cr2540 for around 600 mAh - more than what a Moteino gets from a 9V battery but at a tight form factor. Soldering directly eliminates the bulky battery holder and allows use of a much larger battery than the cr2032 while keeping size down. On the side are a set of connectors which make the most important IO pins available for custom projects.

I pre-flash the 328p with my wireless bootloader so there is no ftdi header. As backup the ISP pins are available on the connector - but really you should just program this one wirelessly.

Looks very professional! Great that you built OTA programming into it.

At what Mhz are you running the ATMEGA?

During startup I boot at 1mhz to enable booting with weak battery. The I switch to 8mhz (internal).

The board uses my new listen mode based polling mechanism: unlike other battery sensors that periodically wake up to send updates to the server this one always sleeps in listen mode. It only ever wakes up if the gateway sends a burst to activate it and then replies with an update. This enables sleeping without watchdog which shaves off 4uA of the energy budget right away.

It's also ideal for interactive applications. Say you measure temp every 15 minutes but when the user opens the web front end you want an immediate update - done.

If you don't do many wireless installs the battery life should be measurable in decades with this scheme.

You could even take it a step further and use the gateway to deliberately space out the polling requests so as to minimize collisions between the sensors and also sidestep the Rx periods of the sensors, so that they aren't activated accidently when a message is intended for a different node.

Actually I assign broadcast id's to all nodes based on their required update frequency. Then the gateway periodically broadcasts bursts to those addresses to wake up all associated nodes. The burst contains a series of packets which each include the time since beginning of the burst. Each node has an assigned time offset after the end of the burst when it should send. Being woken up with one packet in the burst it can then deduce using the time stamp when it should send. Thus all nodes can quickly respond without collisions - essential since you really don't want to do acks with coin cells.

This scheme helps since due to the broadcast nature there is very little traffic on the burst channel that's not for a given node. So nodes can stay asleep and don't need to check if a burst is for them.

May I suggest you guys also check out the ULPNode by Charles (Charly86 in this forum). Maybe some good stuff there to consider.

Yeah I've looked at his stuff. One of his main assumptions is that you can drive a radio that can no longer be powered by a coin cell due to its high resistance by putting a step up regulator in front. Which of course means that the cell would have to provide even more current! I doubt that will work - if a coin cell can no longer provide the power needed by the radio it won't be able to do so at a lower voltage with increased current. Then the only approach would be to slowly charge a huge cap and use that for the short pulse. And we've already discussed that that's likely not helpful.

Instead one should focus on keeping the pulses as short as possible and the duty cycle as low as possible. It's average current that counts.

Having some external circuitry to get wakeups cheaper than with the WDT is a nice idea. But I think the radio with listen mode already provides something that's close enough. The price of 2-3uA for the interactivity of listen mode is very worthwhile in my view.

I don't quite grasp the benefit of broadcasting to multiple nodes at once. Is it just so the gateway is jamming the channel less often?

I'm not as far along as you, but I was planning to simply assign a unique ID to each sensor and then let the RFM69 hardware reject a packet if the address of a packet received during Rx of its Listen-Mode doesn't match that address. If it doesn't match, the ATMEGA isn't awoken and the RFM69x just goes back into the idle section of its Listen-Mode. If it does match, then no other node will be matched, and so then there's no chance of collision from another sensor while sending the requested info back to the gateway.

Listen mode is a two phase process: first the radio detects if RSSI is high enough to even go into receive. That only takes about 300uS in my setup. If it finds RSSI sufficient it will then attempt to receive a packet and see if the packet is addressed to itself (note you can't use hardware node address filtering here because of a bug in the radio - see the listening thread). Key to ultra low power consumption is to have the radio abort because of low RSSI as often as possible. So talk as little as you can and if you must talk talk to as many nodes as possible at once. Thus the broadcasts.

Having some external circuitry to get wakeups cheaper than with the WDT is a nice idea.

There was one more problem in Charles approach: if you regularly charge a reservoir cap to 3.3V and then let it discharge down to 2V you get the typical charging energy loss with a cap (see http://www.smpstech.com/charge.htm for example). You have to put in C * 3.3V (3.3V -2V) but you then have at the cap 1/2 C (3.3V^2 - 2V^2). That's a guaranteed 20% energy loss just for enjoying the benefits of the cap - which is likely to eat any improvement in powerDown efficiency due to lower operating voltage. Add the boost converter loss and the fact that when live he powers the ULPNode at an excessive 3.3V (drawing around 50% more current than at 2.7V due to 328p spec and even increasing that current at the coin cell by ~20% by boost converting up to 3.3V) and I think it's not unlikely that Tino will outlast ULPNode even with listen mode.

If one wanted to go really, really low just add a simple RC circuit which wakes the Tino up once every minute while using a large enough R and low enough C not to use more than a couple of nA. That would last forever - but you lose the interactivity of listen mode which I'm no longer willing to do.

Finally if you want to power something from a coin cell then likely because you want it small, not just for fun (ok fun is definitely A factor - so I don't really get what problem ULPNode solves if it worked unless it was much smaller.

I think it's not unlikely that Tino will outlast ULPNode even with listen mode.

You know what? I'll retract that statement. It might be true on the whole considering the boost converter issue during RX/TX, but the ULPNode is much more power efficient in powerDown because it doesn't use the on board WDT and doesn't need listen mode. That more than makes up for the non-ideal use of the cap and the booster loss.

I did a quick prototype yesterday to check how low I could go even with the current HW. Idea was to use listen mode as WDT without any interactivity benefits. Every 2 minutes I send a wakeup burst, all nodes send their replies, sequenced based on time stamp in the wakeup package. Then every node selects its listen idle period such that the next RX period overlaps with the next wakeup burst. After each wakeup I recalibrate the RC oscillator in the radio.

This works pretty well - but there is an obvious downside: if a node misses one wakeup burst for whatever reason you either need to send a 1 minute wakeup burst to collect it again, or you have to wait an hour or so until the RX period and the wakeup burst period overlap again. That said it's run all night without hickup here.

I put connectors on the side of the Tino to enable custom projects. Today I wanted to put together a water leakage alarm for the weekend home. Given that Tino sits on the coin cell with VCC exposed to the bottom I just soldered a 1mO resistor from int1 to Gnd and let the other end touch the ground. When water connects the coin cell bottom and the resistor leg an interrupt is triggered and I get an alarm. So simple ...

Kobuki, attached are the eagle files. I've got to say though I'm having a hard time producing them. The biggest issue is frequent shorts underneath the 328p. Bridges I have come to accept and fix after reflowing with some desoldering wick. But pretty often afterwards I still have shorts and they seem to be located underneath the chip. Sometimes I can fix them by inserting a bit of coper litz between the legs and heating with the soldering iron. It might have to do with the via's that are so close to the pads - I haven't really figured it out.

Today I first reflowed a board, then used a hot air gun to desolder the 328p and finally manually soldered the 328p three more times until it finally worked. Of course this might all be a symptom of my being a total HW noob. First PCB, first reflow project, first SMD soldering, first everything.

If anybody has ideas on what I could improve (board wise of in terms of technique) please let me know.