Tinysensors Redux

 

Raspberry Pi Zero-W with Tinysensor Hat

It is often instructive to revisit an old project: you never know what you might see with fresh eyes. Such is the case with Tinysensors, which has featured here several times over the years. Since it lives in Github I use that platform's Issues feature to collect ideas which pop into my head when I am otherwise occupied. This provides a nice context from which to start revisiting.

Among the issues addressed since the last time we featured this project are:

• Switching to the ATTinyCore. From my point of view, the most important feature of this great project is its support for Optiboot. This decreased the testing time for changes to the Tinysensor sketch by an order of magnitude. No more external programmers!
• Removing the RF24Network library. This supports a very versatile model of organising nRF24L01+ radios into a fully-connected 5-way tree. However it necessarily limits the number of leaf sensors to 5, requiring bridges to interconnect different levels. A star topology removes this limitation, and also reduces the code footprint enough to support debugging via SoftwareSerial.
• Reducing power-drain. With the above improvements in testability, it didn't take long before a gotcha in power consumption was spotted: a voltage divider made with a built-in pullup resistor consumes current even during SLEEP_MODE_PWR_DOWN!
• Moving the hub to Raspberry Pi Zero W. This has more memory and more processor for smaller footprint; in addition to built-in WiFi and Bluetooth. Once that was complete, a proper Hat was designed to hold the nRF24L01+ radio and status LEDs... and a power button, just 'cos.
• Outsourcing the RF24 library to nRF24. These guys have put a lot of work into improving the performance of Maniacbug's excellent original library, which means I don't have to!

Future work? A nice next step might be to redesign the sensor PCB for a coin-cell and surface-mount components. However I'm pleased enough with these changes to park it for another couple of years!

TinySensor Server

Well after almost a year I decided it was time to update this project with improvements to both its hardware and software.

On the hardware side, the server is still the original Raspberry Pi model B, but I've mounted the nRF24L01+ radio on a neat little Slice of Pi board. (These boards also have traces for mounting XBees with their unusual pin spacing. And they're cheap!)

The Slice of Pi board (left) with radio and status LEDs

While I had the soldering iron out, I added a couple of status LEDs (see picture). The green one indicates recent activity on the radio, while the red one indicates a timeout but also flashes every time a packet is received. Both of them are driven by a single GPIO line on the Pi. (This was motivated by the radio cutting out on the Pi, probably due to the original Heath-Robinson jumper cable arrangement, and since its transplant it's behaved perfectly.)

On the software side, there are now quite a few little daemons, each doing one thing well:

• A wireless hub, running RF24-rpi, sends packets received on a TCP socket,
• A wired hub, running remotely, polls a legacy 1-wire sensor network and sends its readings on another TCP socket,
• A multiplexor, connected to the two data sources above, sends their streams to its connected clients, described next,
• A MySQL client writes readings to a database,
• A status client manages the LEDs described above,
• An RRD client maintains a round-robin database,
• An lcdproc client updates a wireless LCD display.

All of these are, as usual, on GitHub.

Future software components planned for this system include a simple weather service to inject local weather data into the stream, and a client for one of the various IoT services now becoming widespread. (Here is a fairly recent overview of some of these.)

Power Consumption

Initial news on the power consumption of a TinySensor just in! A sensor was configured to transmit every 5 seconds until its battery ran down; it managed 1205331 transmissions in just under 70 days on a Duracell AAA Plus. Therefore, if configured to transmit once per minute, it would have lasted for 2 years and 4 months.

This handy page informs us that a long-life AAA Alkaline battery contains about 5kJ of energy, therefore each transmission takes about 4mJ, which equals an average power consumption of 0.8mW. At an average voltage of 3v this requires a current of about 0.26mA. Ignoring consumption by the sensors and boost converter, and estimating current drawn by the radio and processor combined at 25mA, gives a duty-cycle of 1:100, meaning it's awake for 50ms.

Voltage over time looks like this, which seems typical for Alkaline batteries; it jumps around quite a bit at the end, and the interval between transmission times increases considerably.

During normal operation there is a bit of variation between successive readings, I'm not sure whether this is just due to thermal fluctuations or an artifact of the ATtiny's ADC.

The starting battery voltage was logged at an unsurprising 1.51v but the last reading received was an astonishing 0.28v! This shows the amazing ability of the step-up voltage converter to suck every last drop of juice out of a battery. Here we have zoomed in on the end of its life:

Each transmission carries a message-ID which should be monotone increasing, within the limits of its range. The next plot shows that the TinySensor worked perfectly (or at least didn't reboot) for most of its run (and also that the message-ID is 16-bits unsigned):

However, towards the end of the battery's life, this is certainly not the case:

Here we zoom in still further on the system's behaviour at the end of the battery's life:

It is clear that the system halts for increasingly long periods of time while the battery recovers, then it manages a few hundred transmissions before collapsing again. We can look at the time interval between messages on the same time axis as the plot above:

Noticing the change in the slope of the message ID line above, let's zoom in on the corresponding part of the inter-arrival time graph:

Note that this is the time at which the message was written to the database on the Raspberry Pi, so some variation must arise from the behaviour of the Linux kernel on that box, however it's not clear what to make of the rising trend in the graph from about 03:37 onwards. (The processor used its Watchdog timer to sleep; this is clocked using its own 128kHz RC-oscillator so perhaps the falling supply voltage is causing time to dilate!)

Update:

A little experiment with an ATtiny, a blinking LED and an almost-exhausted battery disproves the hypothesis that the watchdog timer is losing time: the blink-rate remained constant until the battery died. Furthermore a voltmeter attached to the battery confirmed that it fluctuated up and down by about 10mV during the sketch's blink cycle.

Update 2:

An important lesson from this kind of experimentation is to keep as many sources of time as possible. We've seen the inter-arrival time above, but what about the transmission time as seen by the sensor? Below is a plot of the inter-transmission time, as recorded by the millisecond timer on the ATtiny:

What is really interesting about this is that all of the noise in the inter-arrival times has vanished! As far as the ATtiny is concerned, there are only 4 distinct intervals between packets: 5s (as intended), 10.45s, 15.9s and 21.4s. My best guess for this is that the radio has only succeeded in transmitting one out of every two, three and four packets respectively. Lastly, the steadily rising inter-arrival time is most likely due to radio-level retransmissions, required due to diminishing transmission signal power.

The Next Level

The PCB and TinySensor assembled!

A mere three weeks after submitting the order, Seeed Studio returned my PCBs! The picture above shows one before assembly and the other after. The assembled one is mounted on half of a sick-of-beige case, also from Seeed Studio. This was needed because the PCB chosen was 0.8mm thick and flexes easily. (Perhaps a thicker PCB wouldn't have this problem.)

Assembling a PCB is much easier than stripboard mainly because of the smaller number of holes on offer for each part. Printing the component names helps too but not having them wouldn't have mattered so much, for this project anyway. The main thing to remember is to add the parts in increasing order of height.

The board worked first time! No embarrassing green wires needed! I attribute this to the fantastic job done by Eagle's autorouter. The only change I would make in retrospect is to ensure the capacitors were the right physical size: the parts chosen from Eagle's library had a smaller footprint than the ones eventually used. The Eagle files are here.

Quick-and-dirty graphs of humidity and light from the bathroom over the past 8 hours. (Note the spike at 9am when I was showering!)

Here's the bill-of-materials. Say €20 including headers, nuts-and-bolts, AAA battery, etc.

Part	Qty	€
ATtiny84	1	3.00
14-pin DIL	1	0.15
PCB	1	4.50
Sick-of-Beige Case	0.5	1.00
DHT22	1	3.50
NRF24L01+	1	1.00
NCP1402 3v3	1	5.00
100nF	3	0.05
10k	2	0.05
4k7	1	0.02
Total		18.27

Taking it to the Next Level

TinySensor Board Layout

Up till now we've just used Eagle to draw schematics and, in all honesty, it's not the world's greatest drawing tool. It only really comes into its own when used as it was intended, to assist the complete design process.

What follows is a summary of my experience using Eagle to lay out the TinySensor circuit, described previously, on a sub-credit-card-sized board and generate the files required to fabricate the board. (It's based on a reading of these two useful posts.)

So, once a circuit has been designed and prototyped on breadboard/stripboard, its schematic drawn and checked for errors (using the ERC tool in Eagle), board layout can begin. Unsurprisingly this involves Eagle's "Switch to Board" menu item. A new window appears with a jumble of interconnected footprints corresponding to the components chosen in the schematic view.

The board view is connected to the schematic so that any changes to the latter are reflected in the former. The first changes might be to replace some components by equivalents with different footprints, for instance (and Eagle provides a tool for just this purpose).

However the main action of this view is layout, routing and manufacture. Layout must be done manually, by dragging individual components out of the jumble and into the white rectangle, representing the board itself. At this stage, I chose the board above (it's from Dangerous Prototypes) and deleted the white rectangle. A good rule of thumb is to place the largest parts first, although you'll probably have a good idea of the desired relative positions of the parts, having prototyped it already on stripboard.

It's good practise to try manually routing the circuit, if only to be even more amazed at what a good job the autorouter does. The undo command is your friend here: I found it useful to try autorouting slightly different placements, undoing autorouting before moving components around.

Once satisfied with the placement, print the layout on paper! This provides an essential sanity check of component footprints: use a pin for the drill holes and attempt to fit your chosen parts. Better to discover they don't fit at this stage than when the boards come back from the fabricator!

The next step is to run a Design Rules' Check. This often requires a rules' file tailored to the fabrication process itself, in this case Seeed Studio's Fusion PCB Service. Download the rules' file, load it from the DRC dialog and run the check. This thread contains descriptions of some errors found at this point.

Finally, run the CAM Processor to generate the design files for manufacturing. (For Seeed Studio, this requires its own Gerber Generator, downloadable from the second step of the Fusion PCB workflow.)
At the CAM Processor dialog, load this file from File > Open > Job... and then hit Process Job. This will generate a bunch of files, of which Seeed requires 8:

% zip seeed.zip sensors.{GTL,GBL,GTS,GBS,GTO,GBO,TXT,GML}

A sanity-check widely recommended at this stage is to load up the layer-files above using a separate tool (e.g., gerbv) to see if there is a discrepancy between it and Eagle and correct it. Once this is done, upload the zip file, pay your money and wait!

TinySensor (part 1)

TinySensor circuit diagram

Remote sensing using microcontrollers is nothing new --- it is practically a rite of passage. My spin on it, TinySensor, can be seen above. It's a wireless, battery-powered device which periodically transmits readings of light, temperature, humidity and its own battery voltage, to a base station comprising a Raspberry Pi and a MySQL database. Unusual features of this sensor are:

• It uses my 'port' to ATtiny of Maniacbug's excellent RF24 and RF24Network libraries for the NRF24L01 radio.
• It runs for over a year on only a single AAA battery with an NCP1402 3.3v step-up converter.
• It is field-programmable using the TinySafeBoot bootloader and the Arduino IDE, as described previously.
• It costs about €15 per node when prototyped on padboard with breakout boards for the radio and voltage converter.

Resources:

• RF24 and RF24Network tweaked for ATtiny and Raspberry Pi.
• Modified Arduino SPI library providing SPI emulation on ATtiny.
• A DHT22 library (forked from here) and also tweaked for ATtiny, by removing floating-point.
• Sketches to test the board and set the network address (in EEPROM) and run the hardware in the field.
• A Raspberry Pi program to receive the data and dump it into the database.