LED Logger V3

Intro

I’ve previously wanted to know how much do cheap led strips last: turned out they don’t even pay for themselves over incandescent bulbs.

Here is the third incarnation of the experiment, after the second one failed and sat in a box for a couple of years. My motivation for fixing this was very low, as it already showed what I was interested in. As I received a few requests to resume the experiments from interested people and began to be interested in newer types of LED like  the WS2812, here it is.

The logger has got some new updates to measure everything possible and benefits from a Wi-Fi connection.

 LED logger V 3

In short:  16 LED channels are measured, one is kept for control of the sensor. For each LED the power supply and current are measured. The temperature of the aluminium plate is measured as well. In total there are 16 light channels, 15 current channels***, 4 voltage channels and one temperature channel.

Power supply: The strips I am using are 12V operated, but there are some WS2812B LEDs powered from a 5V DC/DC converter, along with the electronics. The power supply is loaded to about 30%. Both supplies are monitored, and 2 more channels are available for the future.

Current: The current of each LED channel is measured along with the light intensity. The current measuring sensor along with the switching transistors are made to have a very low burden voltage, in the order of mV, using a 10mW shunt and a 40mΩ RdsON transistor. The voltage across the shunt is amplified with a MCP6V31 low offset amplifier.

Temperature: there is now a one wire temperature sensor. Even though there are a few more LED strips added and power dissipation is 2-3 larger, the temperature rise is only about 10C over ambient.

Sensor degradation: in order to verify that the sensor is still reporting correctly I have installed a strip that will only be lit for a short time at each measurement to check that the sensor has not changed. By measuring a strip identical to the first I have found that the sensor produces identical results, so there appear to be no degradation over the experiment.

***I designed the circuit to switch off the negative supply. It turns out that this is a bad idea for the WS2812 LEDs, as the first one breaks very soon after. So the current for the WS LEDs is not measured.

Current Data:

The current data is available here (or click the picture below), check under for description of each strip. I have decided not to plot the variation over time for now (it’s stored) and only show the running time and intensity of each led, reported as percentage of initial intensity as well. The temperature and supplies are monitored along with the current for each LED. As with the previous experiment there are fluctuations in the readings, but they seem to average out nicely over time.

led_dashboard

Meet the candidates

The control strip is identical to the strip used in the first experiment, except that is has not been used. It turns out that it produces the exact same readout as the first strip, meaning that the sensor has not been degraded over the 1400 hours of initial test. The control strip and the original strip are the best aligned to the sensor.

Strip 1 is the strip used in the first and the second led logger. It starts with about 5500 hour usage.

Strip 2 is made by Optoflash, it’s similar to the others except that the light is cold white. It’s a bit more expensive, comes from TME and there are no details about lifetime in the datasheet, but at least there is some sort of datasheet. It starts with 4500 hour usage.

Strip 3 is an Ikea ledberg strip. It’s rated at 20.000 hours, but without any info as to how this time is measured. It starts with 4500 hour usage.

Strip 4 is actually a waterproof module from a local shop that I paid about 1 EUR for. I don’t know anything more.  It starts with 4500 hour usage.

Strip 5 is another waterproof strip.  It starts with 0 hour usage.

Strip 6 is a much brighter PLC LED chip strip.  It starts with 0 hour usage.

Strip 7 is similar with Strip 6, but encased in gel. It is also the most expensive one, bought from a more reputable online shop. Added on 28.03.2015.

Strip 16 is three WS2812B LEDs, which used to be 4 until I realized there is no easy way to measure the current on the WS2812 without breaking it. It starts with 0 hour usage.

Strips 7 to 14 will be determined and added later.

DSC_3816

The logger

There is now a brand new, factory made PCB, schematic and layout available of course. Quite a lot of changes have happened: I switched the micro to a bigger XMEGA, added more channels, more voltage channels and current monitoring. Plus, now it is wirelessly connecting to the internet with the help of an ESP8266.

I have switched from the public data loggers and installed emoncms, the open source energy monitoring software on my website’s server. This has quite a few extra features and I have a sort of guarantee that once I get it working there will be no disruption due to domain changes, API changes etc. Plus, I own my data.

DSC_3809

The software of the logger is quite a big mess, it is put together from many places which makes it far from optimal, but it does the job. Available on github.

Schematic is below. It’s grown a bit now, but there is nothing special about it.

led_logger_schematic_v3

Everything is built around the same box used in the previous projects, except that now the wire mess has grown significantly due to more channels and extra features. I move the controller on the inside to avoid disrupting the wires and stupid questions from visitors.

DSC_3813

The ESP module sits on the outside, although it worked from the inside in the brief tests that I have performed. Still, I don’t want to risk any issues so outside it stays.

The temperature sensor is placed on the outside of the aluminium plate, in the centre where I expect the temperature rise to be maximum. It is placed in thermal contact with the plate and then some isolating foam and a few layers of tape disconnect it from ambient influences.

DSC_3795 DSC_3804

PCBs?

Interested in replicating the experiment and sharing your results? I will be happy to offer some PCBs for free (you pay the postage), but I will not have time to offer support. PCBs will be limited to 1 per person, I only have a few available.  Still all information to replicate the experiment is here. 

ESP8266 tests

IntroDSC_3532_r

If you remember the time when radio modules like the nrf24l01 dropped under $5 you are going to like this. Now there are WiFi modules at that price point and there are going to be massive changes in the IoT.

The ESP8266 is a low power WiFi module built around the ESP chip of course and some flash memory. It’s made some waves around the Internet recently and everyone is excited about it, i would say even more than when TI launched its cc3000 WiFi which promised a low price point for WiFi. There are plenty of other WiFi modules out there, but nothing except router based modules made any significant excitement.

Like the cc3000, these modules contain WiFi PHY and a processor to leverage the task of a small micro around it. This is done to shorten the time to market and ease the RF qualifications of the final design. But for hobby level, it means that the module does most of the heavy stuff for you, without worrying what is inside. You can probably make your Internet connected temp sensor with a 1k microcontroller but you can even skip it by playing with the newly released SDK.

WiFi, the universal connection

Why does the WiFi matter? Well, it is the most universal thing to connect your stuff to the internet. With other radios you normally have to result to a gateway or something similar that does the link between your simple radio and the internet. That would have not been a problem if anyone defined some standard that everyone agreed to, instead of having every manufacturer trying to promote their own. And no, there was no way out of this.

Bigger batteries

It’s no surprise that the new devices consume more power compared to other radio modules like the NRF24L01, as it can operate at higher data rates and higher power. While this might be an advantage with larger coverage and higher throughput, it’s not the best if your application is a low power sensor. Still, a pair of AA(A) batteries might be able to feed your internet powered temperature sensor for a year, about what you can get from a coin cell with lower power RF modules. It’s actually not the RX/TX power per se that causes battery drain, but the longer response time required to establish a connection and upload a small amount of data to a server half way around the world, which can reach to 100ms or more. Compared to that, in a dedicated system,  a sensor with a dedicated gateway will get a response as fast as 1ms and is required to upload less data. One solution can be to use the battery powered WiFi modules with a local server to minimize response time.

Quick testDSC_3504

My ego box is a quick candidate to become wireless, but as I wanted to keep the original intact, I made a new temporary one. My greatest concern was to establish if the HW, with default firmware(less important), is capable of running stable for a long time. The build puts together an Xmega header board with an IL9341 2.2” QVGA LCD and, of course, the ESP8266 module.

As there is no great deal of official documentation for the chip, I could not establish a correct way to check whether the chip is still connected to the WiFi correctly or not. After a lot of experimenting I found that checking the IP is the only way. This is also the best way to test if the connection to the WiFi was successful, as the module replies with “OK” even if trying to connect to an nonexistent network.

The software loop is quite simple (sorry, no code yet): every 30 seconds, if the IP is available, get the visits counter of my website, otherwise attempt to connect to the WiFi. The time since power up is measured in h:m:s, along with successful readouts of the counter. Further, the number of WiFi reconnects (how many times it lost connection) and the number of connection attempts (except the first) is counted to provide an outlook on the stability. A dedicated TP LINK 841ND router is used to provide WiFi access, because I wanted to test things without altering my normal internet connection.

 Results

First results show good stability of the module and code. In multiple experiments the module is capable of reconnecting to the WiFi in case of connection loss caused by router shutdown. Saturating the WiFi with file transfer between two devices does not seem to bother the ESP module.

Now, the endurance test is started, stay tuned for more results.

Update 1: 1 week in the device went without any re-connection. Note that the router was set to manual IP for the ESP.

Update 2: Somewhere in the 9th day there was a re connection to the WiFi, which took 2 attempts.DSC_3561

Update 3: Another re-connection some time during the second week. It also looks like I am converting the number as signed, hence the negative number of successful attempts to get the website counter after 32767. I should also have used a 32bit counter, but that is for the second revision.

Update 4: the device worked for 859 hours before being shut down for the holidays. It is safe to assume the ESP can be trusted to need infrequent resets, should it be used for a permanently operated device. 

859_h

 Build pictures

DSC_3509DSC_3516DSC_3518DSC_3526

Stockie – item centric shopping list

This project is my entry to the Hackaday prize. If you like it, please vote for me by clicking the “Give a skull” button! (quick registration required)

 

Intro

What if every time you run out of a product, the smart tag on it would instantly add it to your shopping list, at the touch of a button?

The system is very simple and everyone in your house can use it, from kids to the elderly, even visitors. The shopping list is updated dynamically in real time and the system can even be configured to automatically order things online. Scattered throughout the house there are small tags or panels called stokies. You can attach the tags to individual products or things that need them, while panels provide multiple buttons and are designed for places where multiple things are stored, like the pantry.

Modern world has advanced with the help of technology, but somehow a shopping list stayed the same. Paper based, on your smartphone or on the cloud, shopping lists are centralised and require you to reach them in order to add things. Cooking a steak and running out of your favourite spice? For the modern person it’s a bit difficult to get your smartphone, unlock it, find the app, search for the item and check it while your hands are still dirty. Etching a board and your ferric chloride could use a replacement – luckily there is a smart stockie label on it.

My goal is to create simple, small, low cost tags, that you can attach to a product or place nearby which together with the system will provide an automatic shopping list and delivery. These tags would enable a one button press add to the shopping list. Adding something is a simple and instant operation, this is why the tags need to be product centric or use centric, instead of a centralised list or an app on your phone. Such a system should be suitable for the elderly, kids or anyone else for that matter, including somebody visiting you. The list is always available for consultation and in the future, integration with online shop will allow items to be automatically delivered.

VIDEO

How it works

System diagram

Throughout the house there are tags (1) and panels (2) that allow you to mark one item as running low with a simple push of a button. Tags are generally dedicated to one item while panels contain multiple buttons for objects clustered in specific places. When a button is pressed the tags and panels communicate through the gateway(3) which provides acces to the internet, reaching the server(4). This is where it all happens: a database keeps track of each tag of the users and applications provide extra functionality. Users(5) can consult the list(6) while shopping at the supermarket or even at home. Online stores(7) connected to the server can provide automatic delivery(8) of specific items.

Applications are not limited to your home, the system can be used in offices, hospitals, warehouses and even supermarkets, basically everywhere you need to keep a sure supply of something. The tags can be placed corresponding to items on shelves so that you can alert about missing items and have them supplied immediately.

sotckie_system

History and inspiration

The inspiration arrived one early morning when I realized I was out of coffee, even though I had the intention to add it to my shopping list. I started pondering about ways to measure the available quantity of things around the house so that I could be alerted when something was running low. I instantly realized that this would be a fairly difficult task requiring different kinds of sensors which would prove complicated, costly and unreliable. But the real goal was actually easier to achieve: since almost everything is used by a person he/she can alert the system about things running low without the need of a high tech sensor.

I wanted the system to be tied to each individual product or right where it is used, such that the user can instantly notify of a low supply, without stopping the activity or having to remember to later add it to the list. Adding a tag for each product might be appear to be an expensive goal at first, but a quick check shows that I could build a one button tag for about 3 euro, even while buying parts in low quantity. The tag is even significantly lower in cost than the annual supply of most things. Still, tags with multiple buttons can be transformed into panels which I can place in cabinets or drawers where multiple things need to be monitored, further reducing the cost per item.

Hence,  the first prototype is ready to be attached to the coffee machine. It will make sure I never forget to buy coffee, tea or milk.

The built is currently ongoing. Check the gallery for pictures of the progress.

As prototypes I will build 2 kinds of tags and the gateway. I have started with the small version, the coffee machine tag, which is intended for single items, but can contain up to three buttons. The larger version is intended for places where multiple items are stored, like the pantry, and will have a larger number of buttons.

Assembled one button stockie, without case. This PCB supports 1, 2 or three buttons.DSC_2762DSC_2741

First tag, fully assembled, this time using all three buttons available on the PCB

DSC_2640DSC_2639

The coffee machine will receive the first tag: no more mornings without coffee

DSC_2654

First module connected to the “umbilical” cord while in development

DSC_2661DSC_2662One of the first steps of the built is to achieve communication between the stockie tags and the main node which will be the gateway to the server. The tags are based around an attiny88 microcontroller and a NRF24l01+ radio module. The gateway will use a router coupled with an XMEGA micro controller along with a NRF24L01+ high power module and external antenna (here shown with a regular one). In this combination the communication range is sufficient throughout the house, including passing through two floors.

DSC_2619

Low power design

The stockie tags need to operate from a coin cell for as long as possible. I have considered designing the tags with touch sensors instead of physical buttons but the sensors need to wake up periodically and consume power do do the readout. Supposed I would have designed a tag with 4 buttons and settled on a 250 ms response time(that is slow actually), then the circuit burns 28uA which means that the coin cell battery would last less than a year. By using buttons, the microcontroller sleep current goes down to 0.2uA which is far less than the self discharge rate of the battery. CR2032 batteries are rated at 1-2%/year self discharge, which combined with the microcontroller consumption should have a life or around 50(yes fifty) years, but I highly doubt that will happen in real life.

When a button is pressed the tag communicates with the gateway which communicates with the server and then returns a response which will be a red or green LED blink. Assuming a worse case scenario of 0.5s of wait time for answer from server and 0.5 seconds of total on time for the LED, I get an average current of 18.8mA for 1 seconds. This  translates to about 40.000 operations from one battery.

With the extreme standby time and high number of operations I think the tags will have a practical life of more than 5 years on a battery.

Schematics

The design of the tags and panels is rather similar, they differ just in the number of buttons. The tags have up to 3 buttons while the first panels have up to 10. The parts list is kept to the minimum, I have even omitted the LED current limiting resistors because the reduced drive strength of the micro controller at 3V will keep the current within levels. Schematics available in PDF: Tag and Panel and the gerbers are avilable here: Tag and Panel.

stockie3_schematic

stockie10_schematic

Build Log

Update 19-20.08.2014

I have finally achieved simple functionality on the website. The whole project is hosted on my personal website, since I still have resources like databases available. The data is stored in a MySQL database which supports multiple users. There are a lot of features that I would like to have, but so far there are just a few things available: some diagnostics, user selection, simple error handling and most importantly a shopping list display. Apart from the user pages, there are a couple of others that will be accessed by the tags in order to change the status of the item or configure the tag.  Here is how my list looks now, I have added just some random things:

website_listThe other functionality is to show the status of all the tags for a certain user. For now the information contained is the HW ID of the tag, status, battery status and when it was last changed by the tag or website

website_configure

Update 18.08.2014

First panels are completed and can go online. Here are the first two assembled PCBs, one for development and one for actual usage in the kitchen.

DSC_2818DSC_2823

As you can see, there is a lot of empty space in the box, but I will design the whole thing again for the next version, the panel should not be much thicker than a battery and PCB. 
DSC_2828

The buttons are designed to come out of the box surface just enough so that they can be pressed through the front plastic panel that comes over them.

DSC_2830

 

And the first completed panel from the front which will take place in one of my cabinets in the kitchen. I have chosen the labels quite randomly, I almost never need flour, since I don’t cook. DSC_2832

 

Update 18.08.2014

To make the prototypes easier to fit in the box I have used a trick: I have placed a proper sized hole into the PCB under the buttons and the LEDs. That way I can install the PCB in the box and use it as a template to drill the holes. It takes less than 2 minutes for the whole 11 holes required for the 10 button panel, but I bet I could do it faster with enough practice.DSC_2625_2

Update 17.08.2014

Success! The first stockie tag(attached to serial port for debug) can now connect to the database and check the status of my coffee. This means that basic functionality in the tag software, gateway software and server side software is done, time to start building up on it. Here is the tag saying I am out of coffee(red led). It takes a lot of things to work together in order for this to happen, I had to develop software for the tag, the gateway(micro and router) and server while using C, bash, javascript, html, php and mysql and of course, everything has to work together.

DSC_2817

 

And here is the tag saying I still have enough coffee(green led not that visible due to flash):

DSC_2816

 

Some terminals for debugging: top is the tag data, middle is data going through the gateway microcontroller and at the bottom is the router

first_debug_all3_1708

Update 16.08.2014

I have assembled the hardware of the gateway. The gateway is made from a TL-WR710N(EU) router and a Xmega header board I have previously designed. The XMEGA32A4U  microcontroller serves as interface between the radio and the router since there is no hardware SPI available on the router. Currently the data transfer between the microcontroller and router is done with a USB-serial adapter because I need the original router serial port for debugging. Once the development is finished, I will switch to the router serial port. There is an additional serial connection between the microcontroller and PC to monitor the data transfers and debug.

The two antennas, router and NRF, are perpendicular to minimize coupling, as the router connects to my Wi-Fi to get online. Alternatively, I could use an Ethernet connection, but that requires an extra cable and limits the place where I can put the gateway.DSC_2788DSC_2791DSC_2794DSC_2801

 

I found a place for the gateway in a socket I never need to use.
DSC_2807

Let the software development commence: two serial ports for debugging:

DSC_2810