I have recently purchased a 3D printer, mostly because I was interested in learning about 3D printing, and of course, because I wanted one. Between buying a ready to print one and sourcing all parts individually, I went for a complete kit. I though getting a kit that needs assembly would allow me to learn more about it and I would enjoy assembling it. So, I went for a prusa i3 steel, because i wanted something capable of both ABS and PLA from the start and should have reasonable endurance.
Clearly, the thing is noisy, without any tuning it was constantly over 70dB, peaking at 75dB for some motions. Since I keep it next to my computer desk where I spent most of the time, I am troubled by it. So i made some changes to try and reduce the audible noise. For noise measurements I have used my smartphone with Audio Tool app and an IMM-6 calibrated microphone placed about 1m from the printer.
1. Support. Place the printer on something as rigid and heavy as possible. I found that tables are not that great, but a drawer set works better.
2. Decouple from the support, in order to minimize vibration transmission. Apart from a layer of foam, I used 4 furniture support feet placed under the Y carriage, which means that now the 3d printer touches the ground in less and smaller points than before. This helped a lot.
3. Play with printing speed. As a mechanical system, the whole printer is prone to have certain resonant frequencies and it turned out that the default 50mm/s speed was the loudest possible.
4. Change the motor drivers. The biggest change I have managed to make in terms of noise was to swap the original A4988 X and Y drivers with DRV8825. While these produce a high pitch wine, the mechanical noise is strongly reduced, i managed to get about 8-10dB.
5. Fix the power supply fan. The most annoying thing about it is that it cycles ON/OFF, not continuously variable according to the temperature. Of course this is acceptable for an industrial power supply, but not for home use. I could have replaced the control with a variable speed one, but there is not much to gain here either: the fan is small and placed in a closed space. The solution i settled for was to replace it with a 9cm fan, the largest I found in my parts collection. After cutting out the previous guard, I mounted the fan as far away from the case as my screws allowed and sealed the area around with duck tape. This is to allow the air to flow easier and keep the fan blades away from the big aluminum plate which would cause noise. Of course, no fan is complete without a red guard on top, with a bit of scaling. I left the original control in place, but I added a 50 ohm resistor as well, to keep the fan turning at lower speed. My goal is for the original thermostat that puts the fan at full power to never trigger. Some tests have shown that this performs as desired, even the outside of the power supply stays cooler then before. This is clearly beneficial and should increase the life span of what is not such a great quality power supply. Check below for the build pictures below.
What is inside the typical not so high quality, 360W, 12V LED power supply:
For thermal regulation, the power supply uses a simple mechanical thermostat placed inside the filter inductor, which switches the fan on at 45°C and switches it off at 33°C. Since the printer does not draw much power, the fan cycles ON and OFF, which is not that great for all the components, since they keep cycling between the 2 temperatures.
I have removed the original fan and cu the grill to improve airflow as much as possible. The fan is placed at about 1cm further away from the case to reduce noise.
Tape is used to seal the gap
I connected an extra wire to the positive supply of the fan to be brought outside in order to add a resistor to keep the fan at idle speed.
Ending with some experiments for idle speed
Of course, no fan installation is complete without a red grill
Note: The E3D fan is small and it’s quite noisy, if the printer does not print. Otherwise there is no difference in noise with or without it, so there is no need to replace this one with something larger.
Raspberry pi, routers, wireless nodes, NAS, some lights, all of mine have one thing in common: they need 5V power supply and could use one that is backed up. Now, I am not looking for hours of backup since i find the local electricity very reliable, I cannot remember when power was out for more than 10 minutes, but 1h should be ok for extreme cases. Since everything is already powered from a 5V supply with ample power reserve, i thought that a 5V in, 5V out version is best.
At first I tried using my 4×18650 batteries portable phone charger with both charger in and output on. It turns out that it will only work for some hours: as the step up converter is drawing power from the battery, even though it gets charged, the charger has a timeout. No matter what, the charger gives up and you are left consuming the battery and then it’s over. This takes more than a day if I start with a full battery, so it might fool you at the beginning. I tried looking for options to power the step up converter from the 5V input directly, but it turned out the compact PCB was making things worse.
I turned to my parts bin and searched for ingredients that would be needed to make one: A battery charger, a battery, and a step up converter. A 2.5Ah 18650 battery was just right, but i did not have a case for it so I 3d printed this one. The step up is an unknown DC/DC converter from ebay, it claims to be able to supply 5V at 1.2A, from a lithium battery, but that is about it. The charger is a 1A charger, which would charge the battery fast, while not overloading my 5V 2.4A supply.
Important: LiIon batteries can be very dangerous if mistreated, because of this I have used a protected cell: the battery contains over voltage, over current and over temperature protection circuits inside it, so in case something happens from the outside, it is safe. Please use a protected cell if you are replicating this design. I am not responsible for any consequences resulting from somebody using the information presented here, you are at your own risk!
Next up, let’s build the schematic:
I have not been able to find this design online, hence the article. It is pretty straightforward: a step up DC/DC converter gets its input either from the battery or from the original 5V supply. When 5V_IN is available, because the battery is a lower voltage than this, D2 conducts and provides power to the converter while D1 blocks the battery from discharging. There is about 0.3V dropped on the diode and some on the cable, in my tests the input of the converter dropped till 4.5V. If power fails, there is no 5V_IN available and D1 conducts and powers the converter.
Precisely for this voltage drop, I decided to use the step up converter after generating the uninterrupted supply at the common cathode of the diodes. I could have connected the schottky diode D2 between the output and input, and provide power to the output through it. This is seen in some other designs online. The drawback is that it requires the step up converter to be tuned to a voltage that is always lower than the supply reaching the UPS, otherwise the battery might supply the pi. With 4.5V from a nominal 5 reaching the UPS, I would have to tune the step up to about 4V which might not be enough for some attached peripherals, while running on backup battery.
I plugged everything on a prototype board and started doing a couple of tests. I loaded the circuit to about 1A mimicking a Pi and some things around it, with a 4.9Ω resistor(precise measured value). After a while it looks like the step up module reached a stable temperature of about 75°C maximum. This is rather high, so i recommend using it in a well ventilated enclosure, possibly with forced cooling. This is an extreme case, the Pi will be the greatest consumer at about 0.7A. On the right you can see the output voltage, on the left the battery voltage, in this case it is being charged.
The LEDs on the modules provide a good impression of the status: the one on the step up converter signals power is available to the PI and any of the ones on the charger(charging/full) signal AC power.
Time for Pi tests:
Efficiency results: Normally, the pi draws 2.8W from the mains while being idle, with a HDMI screen connected and Ethernet. While using the ups, after the battery is charged the total power draw is 3.2W, which means an efficiency of 87%. The actual lost power means 3.5KWh/year.
Idle power: Just the UPS alone draws 0.2W from the mains, after the battery is charged. All power numbers include the first 5V power supply, they are measured directly as power drawn from the mains with my sensitive power meter.
Backup time: as mentioned in the above test, the pi with only display and Ethernet is backed up for about 2 hours with a single 2.5Ah battery. The precise number of my 2 experiments is always between 2 and 2:15 hours, as I checked the status every 15 minutes.
Trust: I really don’t trust these eBay modules for a long time operation, the thing here is just for a proof of concept. As soon as I will get the chance I will purchase some “brand name” ICs to rebuild this with proper quality components.
Note: at some point i have used some step up modules that did not have a common ground between input and output. I suggest avoiding those.
Analog multimeters are measuring current, anything else needs to be converted to current. Digital ones measure voltage, any other measurement needs to be converted to voltage. Need to measure a resistance: inject a current into it and read the voltage across. Need to measure a current? Add a series shunt resistor and measure the voltage across it. And here lies the problem: the voltage dropped on that resistor is usually lost from your power supply and it can sometimes be a significant fraction. Things get complicated when you need to measure a current from a low voltage supply, as most multimeters will drop a significant amount on the current shunt, degrading your supply. You really cannot afford to lose a few hundred mV of your 2V supply. There is another case where things are complicated: a circuit that consumes power over a high dynamic range: mA while active, uA while on standby.
I am working on some sensor nodes that will be battery powered. While active and transmitting they may consume some 20-50mA, but while sleeping the current goes down to a few µA. Current measurement is a very important task to make sure the circuit is working properly, especially in the stand by sate. My main multimeter is a Brymen BM857a which provides a good 50.000 count on the current measurement range, even though it wins the contest for the worst back light you will ever see. If I use it on the mA scale which allows 1µA resolution, it has a shunt of 5Ω, dropping 250mV at peak current. Since everything is powered from 2x Ni-MH batteries of 2.4V supply, the drop can push the circuit to go outside the operating range whenever the batteries are not full. Switching to the µA scale is a total no go, since the shunt resistance here is 100Ω, dropping even more at peak current.
Micro current measurement
The typical way to solve this problem is to use a dedicated circuit with a smaller shunt and a precision amplifier connected to your multimeter. The precision amplifier will take care of amplifying the drop on a smaller resistor and feed that to a normal multimeter to be read. There are quite a few designs out there, but Dave’s µCurrent is very popular recently. I remember having some precision op-amps from the Led logger v3, but while those where not as good as the one used in the µCurrent design, they could do the job for me.
The uCurrent has more features that I could need, so I was looking into simplifying the design…. when it hit me. If my meter can count up to 50.000 then on a 50mA scale it could give me the perfect range: read both the peak and the sleep current on one scale. But how to get there? Now, on the 500mV scale my multimeter has a special 500.000 count mode, which could resolve 1uV, but the truth is that the added extra digit seems to change randomly so it is useless. Using just 50.000 counts and a 10Ω shunt brings me to a worse case scenario than the above mentioned mA scale. But then I found the perfect compromise: 500uA scale has a resolution of 0.01uA and a 100Ω shunt. Changing the shunt to 1Ω would yield 50mA with a 1uA resolution, exactly what i need for my tests. The maximum current of 50mA would drop just 50mV which is a lot more acceptable in the circuit.
The conversion is very simple and I did not need to change anything inside the multimeter: the shunt resistor can be added outside, in parallel with the internal one located between the COM and uA connectors, which is precisely the thing that I did. I have used a 1Ω 1% 0.6W resistor which is good enough for the application. I really don’t care about the 1% systematic error. No, I will not draw a schematic for this. 4 banana connectors and a piece of board later and the nice adapter is born. I really cannot remember when was the last time the connectors outnumbered the parts in the circuit.
Here is the multimeter with the extremely complicated circuit installed, before and after photos. No weight loss or muscle gain occurred.
Now, let’s run some tests. I used another, less precise multimeter, with a high burden voltage in series with the modified one, a 5V supply and a few resistors to check if everything is fine. First test at 5uA:
and finally 33mA. Everything looks fine.
I you are working with circuits spending time in active and standby and need to measure current in the 10s of mA and uA range, then this is the simpler method to use, provided you have a 50.000 count multimeter. With the external shunt my multimeter reads 50mA and 500mA on the uA scale, with enough resolution to count the uA going away in standby mode. With a 1Ω shunt I would say it is safe to measure up to about 100mA without worrying on the dropped voltage.
If you work with development boards you know that they usually connect through USB which provides power, can program and debug the micro and you also get some virtual serial port. Most external programmers not so much, they only do the programming and debugging thing. Except the pickit2, and even though I don’t use PICs anymore this is still by far the best programmer I have ever used. The reasons are simple: through its 6 pins interface it can program/debug, you can choose whether to supply power and at what voltage, you can reuse the pins as serial port or even a simple logic analyzer. Of course, the next version pickit3 is totally crap, but that is another story.
Towards the Xmega
Recently I have decided to give up on the AVR tiny and mega and use some sort of xmega for everything not requiring ARM, due to lack of time to switch between architectures. It does not make sense to lose time switching between devices while building only a single or small number of devices at hobby level. I would have jumped for the SAM D20 for everything, but its peripherals are inferior and it burns too much power while idle, even though the core is so much better. In most projects I don’t mind having at least 3 cables to the board: power, programming and serial port.
But I have recently started to develop some wireless nodes and needed to switch the programming cable and serial port and power between boards, which was making me lose a lot of time. At this stage of development I prefer to keep the debugger attached, not rely on the serial port debugging only, so a serial port based boot loader is useless. It gets quite a bit cluttered:
I realized that while using XMegas I could actually squeeze all 3 cables in the original 6 wire programming cable because 2 of the 6 wires on the ISP connector are not used in the PDI connector so they can be replaced by serial TX/RX. Power can be injected at the programmer side as well. A USB hub can provide one input and two ports, one for the programmer and one for the serial port adapter. So I started the build, first modifying the hub. Since I don’t have a short enough micro USB cable a long one was sacrificed, but rest assured, I will use the other half as well.
Then I built a module that can inject power and pass on the serial port instead of the MOSI and SCK ports. I have settled on using only a fixed 3.3V power supply, as I highly doubt anything else might be needed. I chose to include a separate regulator because the serial port adapter cannot provide enough current through its 3.3V output. This way about 200-300mA should be available for the development board, the rest being consumed by the hub, programmer and serial converter. A double pole switch allows the led to signal that power is being applied without being turned on by power applied from the board. Using a bi color LED i can signal the 2 situations: green means there is power on the board while yellow means there is power on the board and it is applied from the module. Here’s the schematic and the finished module:
I have put everything together and used tape to fix them to the Atmel ICE programmer, that way if I ever need to detach it and use separately, it will be a quick fix. The result is quite a monstrosity:
Now, the small xmega header board can be used with a single cable attached:
Of course, the board needs to have the serial TX and RX connected to the 2 available pins on the ISP connector, but this is a fix I will implement in future versions of the board
The finished device is rather large compared to the pickit2, but maybe someone from Atmel can take care of implementing these features in future versions of the atmel ICE, or AVR-ISP 3 or some other programmer/debugger.
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.
CONCLUSIONS – Final
As of June 2016 I have ended the experiment, once all the strips went over 10.000 hours. The previously drawn conclusions below are still valid (with updated graphs).
The third version of the Led logger has run without any major issues. Based on uptime logging there has never been any freeze or malfunction. As for the LEDs, I have identified a few types of strips based on the behaviour they manifested throughout the experiment. Careful about the axis scale of the graphs.
The terrible ones: strip 5 quickly dropped to very small brightness. It dropped to 7% of initial brightness after just 550 hours, talk about a waste of money. It even passed the threshold to be recognized as ON and the logger does not count the hours. Here is strip 5, a no name waterproof strip:
The fast droppers: Strip 1, 2 and 6 quickly (about 1000 hours) dropped to about 70% of initial brightness, but seem to be rather stable there, even after more than 10.000 hours. Here is strip 6, an initially bright PLCC LED strip from some Chinese on-line shop:
The good ones: Strip 3, 7 and 16 seem to slowly drop. They are the most expensive one: strip 3 is the Ikea ledberg, strip 7 is an Amazon bought strip for about 20 eur/5m and strip 16 is a WS2812 strip. Graph below shows strip 7, which has a very typical drop for a decent quality LED.
And below is the WS2812 strip, dropping to 76% of initial brightness after >10.000 hours. Pretty good result.
The excellent module strip number 4 is at 90% of brightness after more than 10.000 hours. Note that the graphic is missing parts from the previous versions of the LED loggers and has a wrong data point.
Some conclusions line up, but they should be taken with a grain of salt as the sample size is rather small. Obscure LED sources seem to have rather poor and unpredictable quality, so it is best to avoid them. The modules from reputable sources are more expensive, but seem to have better lifetime, while still being rather far from the desired 50.000 hours life time unless you count “there is light, it works” as acceptable. WS2812 LEDs are a pleasant surprise: even though they are cheap(for what they are and do) they seem to be holding their brightness pretty well (Yes, I know RGB LEDs have other ageing and failure modes).
Doing some sanity check, the power supply has been stable throughout the experiment, keeping within 5% of nominal:
The LEDs were kept at a good ambient temperature, which is not something you might expect in normal use
And of course, the uptime was measured. Very impressing, as at some point it has reached 4500 hours. Impressing for the power company, who never turned off the power for > 6 months.
This also proves that the ESP8266 module I used as a WiFi connection which is one of the first to hit the market, can function for a long time. I cannot say the same for later bought modules (~1 year), as 2 of them had died already.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
How it works
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.
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.
First tag, fully assembled, this time using all three buttons available on the PCB
The coffee machine will receive the first tag: no more mornings without coffee
First module connected to the “umbilical” cord while in development
One 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.
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.
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.
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:
The 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
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.
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.
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.
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.
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.
And here is the tag saying I still have enough coffee(green led not that visible due to flash):
Some terminals for debugging: top is the tag data, middle is data going through the gateway microcontroller and at the bottom is the router
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.
I found a place for the gateway in a socket I never need to use.
Let the software development commence: two serial ports for debugging:
Some of the electronic devices I build require some sort of display and buttons for user interaction. This usually leads to a lot of work to design and build a front panel which ends up having a tiny character of graphic display. While in some cases it would be mandatory to have the interface on the device itself, this is not always the case. The simplest alternative is to have the device controlled through the serial port via console and growing more advanced means designing some sort of GUI for your pc. The next step is to have your device be a web server as well and provide control through a web page which in todays world means access is opened to anything that can browse the internet, the PC, tablet, phone. So far, my chioce of HW interface was Ethernet through the ENC28J60. Lately I decided to give something else a chance: routers.
Simply because, depending on the goal, a router is able to provide with the following: a power supply with something left for the project, a case for the project, wireless and wired network connectivity, web server and interface, USB port, ample processing power and memory(vs a micro), huge list of bash commands, rather low power consumption etc. Many low cost models ca go below 20 euros and quite a lot of routers have been used for internet connectivity in projects. The down side is that they cannot replace the micro in the project due to limited amount of pins available and lack of ADC. It is worth noting that the price of a low cost version is comparable to purchasing Ethernet PHY, power supply and case, if the project can use those of the router. Alternatives of course exist, there are different tiny boards, my favorite would be the carambola 2 and there are new low power WiFi modules that could serve more power constrained devices like TI’s CC3300 but they are quite needy, requiring a lot around them.
My first experience was with an Asus 500gP which brought remote control to a few things around. Today I am looking at 4 other models. The TL-WR741N(D) is available as low as 15 Euro, though it will probably be replaced soon. I have successfully used it as IP to serial bridge to replace a “normal” IP-serial bridge. But for more compact designs I would prefer the WR710N European version which I will use in this test. It’s a more compact version of the very popular 703N which has a separate supply and takes a while to be delivered. Have a look at some great pictures of the 710 here. The third option is DIR505 which has a great advantage of splitting in two giving you a nice and compact wireless board and a few extra GPIOs used for the switch. Now if only router manufacturers would do something nice for the hackers out there and bring out some of the unused GPIOs on a header….
I decided to give it a try and found a candidate project: the heatsink tester. I am testing it with a TL-WR710N router, European version which comes with 32MB RAM and 8MB flash (3.5MB available after openwrt install). I took some shortcuts: I used a USB-serial adapter instead of the built in serial port to allow me to work with the console while developing the project, and try to modify the original heatsink tester as little as possible. This is not needed in a final design. Of course, the micro I used has USB port and could be loaded with usb-serial software, leaving the console free. If I am satisfied with the overall feeling I will buy a dedicated router for my heatsink tester and give it a proper „house”.
The web interface
The webpage has three parts: creating the widgets which includes all their designs, putting them on the page and the scripts for the data. The data flow is insured through two functions: one fetches the data from the router, the other sends data to it, both are called periodically.
Here’s a quick look.
The router stands between the microcontroller and the web browsers. The microcontroller sends all parameters required on the web interface through the serial port. A script on the router saves the last entry in a file in RAM. When the web page is opened it calls a cgi script which fetches the data in that file. Any interaction on a web page calls another script which sends some data to the serial port, to the microcontroller. The „middleware” on the router is meant to be universal, independent of the project. This will allow me to create a single image for all routers and use that one for an instant functioning router. For the moment the „history” is implemented on the webpage, not the router.
Response of the router seems to be very pleasant. The browsers show around 25ms response time, with both devices connected over WiFi. I tried opening the page from 3 devices and set the data refresh rate to 10/second and the router had no trouble handling it, there is plenty of power to spare. It is definitely faster than what you get from microcontroller based web servers, while the page is more complex.
While the design of the control panel and display may not be very artistic, it totally achieves the functionality I desired. I have displayed the important status parameters with gauges and text, which gives the user both precise and a fast display of status. A plot shows the evolution of parameters over time, providing a nice history.
Heatsink tester 2.0
My intention was to modify the original project as little as possible, jut to test the overhead of making such a web interface once the console is done.
I have changed the way data is send through the serial port to be comma separated, as this makes it very easy to parse. I have added some other status parameters, like if the heater is on, what is the maximum set power etc. I made minor improvements to the functionality as well: I added temperature limiting, if the temperature threshold is crossed, the available power will be limited. The loop is implemented in a simple way and is not very stable, but I don’t intend to spend time fixing it as it is meant only as a simple safety measure.
The second thing to add was a safety measure: periodically(every 5 seconds) the webpage pings the microcontroller. If no ping is received, after 12 seconds the microcontroller will stop the test and stop heating the heatsink. This means that the heater cannot remain on if there isn’t at least one web page open.
Here’s a quick measurement of a heatsink
For the moment the plot is made by every webpage, so a device connecting later does not have access to the history. I will expand the script on the router to achieve this.
As it seems that one single router can handle lots of things, for some projects it might make sense to use a router as a gateway for multiple projects. Data can be sent to the router with simple radio modules, like RFM12 or NRF24L01. This will make each project smaller and possibly battery operated.
Disclaimer and thoughts
This is not meant to be a complete project, just a test of feasibility. So there are no files available or detailed instructions how to achieve this. I will post all details with the first complete project that will have a web interface. I have had troubles getting stable results over the serial port. After many tries I decided to re-install openwrt after which everything worked fine. The webserver on the router comes by default with a very low number of maximum connections which causes frustration and failure to load pages, slow interface etc. So I increased it.
I have been unsuccessful at making it visible as network devices through network discovery, it would work out great if its properties could point to its webpage. Drop me a comment if you know how to.
The power supply should be able to provide the full current of a single USB port, 500mA but I suspect the total available to be more like 0.8A. My sensitive power meter shows the router draws about 1.2W from the mains while connected to the WiFI, while also powering the microcontroller and the CP2102 USB-serial adapter. The router itself needs only 1W of power.
WS2812 LEDs are one of my favourite toys. Apart from all the things that you can do with them in terms of lighting, displays or even light painting you can also use them for your projects as indicator lights.
The great advantage comes from the fact that you can use a single pin to drive so many of them and it takes just 3 wires ran across the whole box for practically any number. This in turn comes with the disadvantage of more complex control and problems driving them(5V devices) from a 3.3V microcontroller.
Although the data sheet states that you would need at least 3.5V for them to recognize as HIGH level(70% of 5V), many seem to have no problem being driven from a 3.3V micro. With the signal regeneration that each does, it is only a problem for the first one in the chain. But, as I found out, some LEDs simply don’t work as the first device, and to be safe it is best to use a level translator. Unless you completely forget about it and find yourself in need of driving a display with WS2812 which does not like 3.3V signals.
Luckily there is a simple solution with parts that you have available: just another WS2812 LED (or two) and a diode. The trick is to power the first LED in the chain from 5V via a diode dropping its supply to 4.3V*. At this level the 3.3V signal from the microcontroller is within specifications to be recognized as a high level. As each LED does signal regeneration the output of the first LED will be at a 4.3V level which is in specification for the next LED powered at 5V. If you need a longer cable between the microcontroler board and the LEDs, a second one may be included in on the board which will be supplied by 5V in turn regenerating the control levels to 5V.
Below you can see the original 3.3V signal and the 4.3V signal after the first LED. Also notice there is stronger ringing on the 3.3V control signal due to longer wire from the microcontroller.
And now the original 3.3V signal and the 5V signal after the second LED:
*Datasheet doesn’t specifically say what is the normal supply range for these LEDs, although many specs are provided for 4.5 to 5.5V supply. I found no problem with them at 4.3V in normal ambient conditions.
I decided to test the frequency of the PWM signal used in the LEDs as it seems to be unclear. The datasheet claims “scan frequency not less than 400Hz/s” but there was doubt whether or not this is the PWM frequency on some forums. With a resistor in series with the power supply I turned on only one color and tested the PWM frequency which was around 44oHz for a few of the LEDs that I looked at.