<disclaimer> This article is an emotional rant and may contain some strong language.</disclaimer>
Studying the available open source solutions for my 1000.1000 project, I found quite a few interesting frameworks for DIY sensors. One of the most complete and fast growing is the My Sensors project. The Framework, like many others, is based on Arduino, with both the traditional and more exotic hardware.
I did quite some embedded software development and other programming throughout my life, as some projects on my site show, but only from a classical approach. I have used multiple Arduino boards for low price and convenience and I have ported a few Arduino libraries to a regular environment, but my experience with the pure Arduino way of software was very limited. I was aware of the limitations, but not quite so…
Playing with examples
Getting the MySensors to work was fast, I setup a gateway, a dimmer node and a button node. Grabbed openHAB controller and made a rule to toggle the LED at the press of the button. Added a motion sensor and another rule in openHAB to turn the light on for some time when there is motion. Sweet. Great work mysensors.org!
Ok this looks really easy and well off, let’s dig into how this works. Oh….s**t! Can’t navigate through the code using the Arduino Ide, well, ok, fine, I knew it was basic.
Let’s just open the source files of the MySensors library used in the example and look at them. S**t! The fu***ng Arduino IDE cannot even open the very .cpp and .h source files used in the libraries without some inconvenient hacks.
OK, there are other IDEs out there, surely Atmel studio has been bragging to me for a while that it supports Arduino. Fire it up, open the project, and voila! Can jump to function definitions….but wait! All the files used in the project are not easily visible and it is terribly difficult to figure it out the whole mysensors library. Better, but not good enough.
Let’s convert the project to a regular Atmel Studio project.
all most of the source files required are pulled from the Arduino folders into a nice, complete project where one can see all the things happening in the background of the Arduino. And yeah, Arduino does a lot of things behind you back and uses some hardware blocks inside the microcontroller, but that is another story.
But it won’t compile. See, for the sake of simplifying things, Arduino code breaks some rules that normal C/C++ expects. While the Arduino processes the files in the background to make sure they become compatible with gcc, this does not happen here anymore since this project is now a normal C++ project. Untangling things would take a significant effort for such a complex library.
As far as I know, there is no easy way to get both things – the nice complete project with all sources and advanced IDE features and Arduino to compile it, but please correct me if this exists. This is valid for other IDE alternatives, like Eclipse and it is caused by the Arduino way of life.
How does it feel?
Arduino is supposed to be like some aid to swiming. Only that it turns the waters muddy so you cannot see what’s below and you cannot actually swim, you are forced to walk through water. It sorts of works if the water isn’t too deep and your purpose is to get across the river, not learn how to swim.
Don’t get me wrong, it has a very useful place in this world. The community around it had built one of the largest collections of open source embedded code and the far east manufacturers can sure get a board in your hands for cheap. Who cares if it uses a counterfeit or out of spec chip or both, you can get a lot of stuff done.
The alternative is difficult
Actually it isn’t. Let’s look at an example: try reading an analog voltage.
This is how the Arduino sketch looks like, independend to what Arduino hardware you use. Let’s try the newer Arduino Zero.
There is some setup, but nothing to do, it happens in the background, and then you just loop through reading the value. Looking at the ADC it feels like there is more to it, but changing settings will get you digging around the internet a lot.
Now let’s take a similar example using a the SAMD21 ARM that is found on the newer Arduino Zero but in Atmel Studio, which is at the moment one of my favourite microcontrollers. The datasheet shows that indeed, ADC does have few more tricks up its sleeve:
Atmel studio has built in example project to read the ADC using the Atmel Software Framework (ASF). This is the program it produces (removed comments):
Here’s what you immediately learn by looking at the code: there’s a main() function where everything happens, which Arduino normally hides. system_init() takes care of some basic initialisation of the chip. Then you need to initialize the ADC. To get a value you need to tell it to start converting and wait for a result while the ADC is busy, because this takes time. A little bit more complex in appearance, but no different than what actually happens if you use an Arduino, remember the hardware is the same.
But here there is nothing hidden, nothing happens out of your sight or control, you have now discovered more is needed to make a microcontroller work. You can explore the whole code with the ease of a powerful IDE.
And here is where something magic happens, have a look at what is inside the ASF provided function that sets the default way to use the ADC adc_get_config_defaults(&config_adc):
It immediately becomes obvious what are the different settings one can play with. Even for a total beginner, jumping back and forward between this configuration and the ADC diagram above maked it pretty obvious how things can be changed to do a lot more if the user wants to. You don’t need to understand everything at once, a lot of things will be intuitive and some will need the datasheet. This is the way embedded programming normally works, you control the hardware, not use in whatever hidden and obscure way the Arduino wants you to. Atmel provides this nice hardware abstraction layer through ASF, but one can, of course, also use the most efficient way of editing the actual configuration registers following the datasheet.
The complexity is always there, but in Arduino it is hidden. This might be good, but it is also inaccessible and that is why it remains a mystery for a lot of users who never grow beyond it. It’s exactly the wall you hit when you want to dig in and see what really happens under the hood that stops you.
My advice: use Arduino for simple fast things, profit from the community written libraries and buy the cheap hardware, but do learn about the whole world beyond it.
I am not complaining about the loss of performance due to poor code implementation, and in the end not even about the bad IDE. It’s the hide things under the rug to make it look simpler and cleaner approach that upsets me.
So where does this leave me with my home automation project? Tough dilemma, I like my ARM with great IDE and partially written code, but a readymade platform covering 80% of my needs based on cheap hardware and terrible Arduino is also tempting.
Note: there are no links to Arduino sites because they split up some time ago and I don’t find either of them more relevant than the other or worth including both.
[Under construction. Check out The intro in the meantime]
[Under construction. Check out The intro in the meantime]
A picture says 1000 words!*
*inner voice dependent
When I began this project, I was long given up on the ATMega and ATTtiny micro, with some exceptions, as they are not really justified in a hobby environment. Therefore, I have initially intended to make my nodes using an ATXMEGA32E5, which I believe is an ideal device for sensor nodes, due to the various and low power peripherals. However, it soon turned out that for some devices I would need more flash, but the family stops at 32K and a package change is required for more. So I dropped it in favour of the new SAMD21, ARM cortex M0, which comes with more flexible package and flash options. This device burns a little bit more in sleep, but still tolerable. And a 128K flash and 16K RAM version costs slightly more than the lousy old atmega328 with tons of extra features (way better ADC, DAC, more PWM, more timers, more I/O, more flash, more RAM, faster core, lower uA/MHz, RTC, more SPI, mor UART, more I2C….i’ll stop here).
Therefore, welcome the “core 1” SAMD21 node and IOT board.
The top and bottom headers contain all the pins of the microcontroller, including power. The left side has an easy breakable micro USB and room for the antenna. On the right there is the “basics” header which contains power plus 7 other carefully chosen pins. For most nodes, the right header will cover all the connection needs. An antiparallel red-green led can use 2 pins and no series resistor, while being able to display 3 colors. As mentioned in the lessons learned, there is a linear regulator, for the projects that need a regulated 3.3V supply.
And the back featuring the RFM69 radio:
The best way to see the power of this little beast is to look at one of the earlier test modules i built. At the same time, I was using : I2C, light sensor, ADC channel, battery monitor, motion sensor, contact, button and driving WS2812 and 3 PWM channels, red-green status LED and, of course, the radio. It’s not that a lower end microcontroller could not do it, but the flexibility and free memory I still have while doing this is of very high value. And, although I am not proud of it, I took the non elegant solution of driving the WS2812 LEDs by bit banging, because I totally can with a 48MHz clock.
The radio used to transmit the data between nodes is one of the crucial parts of the system. As mentioned in the Lessons learned, the NRF was a good candidate, but eventually failed to meet the needs, so I chose the RFM69. Truth be told, I believe the perfect radio is a combination between the two and some bonuses.
Here’s what I would like to have:
1. Integrated PCB antenna is generally better than an external one when designing a compact sensor node.
2. Decent power, 100mW or more, with the possibility to scale it down to 1mW.
3. High range of bit rates: the RFM69 can do 250:1 (300kbps to 1.2kbps) while the RFM75 is only 8:1. Lowering the bit rate allows for higher range when more power is not an option.
4. Automatic packet handling with automatic ACK and re transmission is gorgeous.
5. Automatic bit rate detection from the preamble: this would allow a gateway or any node to receive any packet without prior knowledge of what bit rate to expect.
6. Cost should be somewhere between the RFM75 and RFM69 (1 to 3 EUR/USD each).
7. Sub GHz band has quite some advantages, but for compactness 2.4GHz works too. Same module with integrated PCB antenna working at 433MHz or 868MHz or 2.4GHz would be gorgeous.
8. Encryption with nounce.
This page covers things I have learned and why I did what I did in my 1000.1000 project. Some experience, random calculations, opinions and thoughts.
So what is the battery philosophy? Should I make everything last as long as possible and change batteries each time some device is dead? What if I have 100 devices at home? Should I use the smallest battery that lasts 1 year and change all of them every year? The expected lifetime for motion sensors will be close to 1 year of life while devices like temp sensors could go for up to 10 years on AA batteries, with others falling in between.
I am staying out of energy harvesting, be it simple solar or more complicated as this is not a universal solution. Long operating times are a must, randomly needing to replace the batteries of many devices every few months becomes quite a big hassle, even for a small home.
My battery philosophy is simple: change the batteries only once a year for the required devices. So, everything should last for a year, guaranteed, worst case scenario. For very long life devices, the ‘low battery’ warning should allow 1 year of operation. So, a yearly battery change should be comfortable enough.
On top of that, no weird shapes, just CR2032, AAA and AA.
Inside the devices, the brains will be a microcontroller, while radio will take care of communication, we’ll call this ‘the core’. Finding the optimal pair is not an easy task. There will be a huge diversity of devices and tasks and one size fits all might not be the best way to go. At the opposite side of the spectrum, the optimum size for each function will blow up in an unmanageable diversity. I know how little it takes to get a button and an LED on the internet, a few times more than that to measure a bunch of LEDs and quite a lot more to get a nice user interface. I am aiming for 2 flavours of the core: devices that need to be very power efficient and devices that can feast from an all you can drink buffet of electrons. If possible for the 2 aromas to merge into one and get power efficiency and performance, even better.
Universal – particular
Going full universal and making a node board suited for all the required tasks is complicated. Let’s just look at the power supply: some devices can work from most range of 2x AA batteries, some need at least 3V, some will need more. Combine with USB power when connected while sipping every last bit from batteries and it gets complicated to manage already.
Using a pair of boards suited for a specific task serves as the best compromise for the majority of things. First, a ‘Core’ contains the microcontroller and radio, along with programming options and maybe regulator. Attached to this is an application specific board. This split allows for faster design times, as a new application board contains only the minimum, specific parts.
In my experience, using small scale assembly, getting 40 simpler boards (20 & 20) designed and assembled is simpler than designing a more universal one and then assembling it with missing components and different configurations.
Drop by the Hardware page to check the solutions.
But how complicated?
I counted about 100 simple devices that I want to measure, control or interact with in my home for now. A simple device is a switch, a light, a motion sensor, temperature sensor, button, led, small display, power meter, switch, plant humidity etc. The combinations of these will result in functionality of the system, like a motion activated light. In order to minimize the amount of hardware, I have grouped them by functionality and location. Keeping the universal – particular balance, I grouped the devices in “common denominators”. The surprise here was that each core needs to handle just 2 devices on average.
This points out to the complexity required for each ‘core’. Drop by the Hardware page to check the solutions.
Software and hardware modularity go hand in hand. While OOP is not my favourite on microcontrollers, it’s the best way here. Fundamentally, most devices will fall in just a few classes (GPIO, analog I/O, read/write at a specific I2C address, PWM, counter etc). Allow these types of classes to operate on any hardware resource and the platform becomes highly modular.
Step up or step down
A step up regulator used for this application like the TLV61225 does not squeeze every last bit of battery when using a power hungry radio. The radio I will use needs 45mA while transmitting. Supplying this current from a step up regulator providing 3.3V from a pair of discharged AA batteries at 2V proved problematic, as this requires close to 100mA of current, taking into account the efficiency. Because of the high internal resistance, the voltage drops too much shutting down the node with significant charge left in the batteries.
The other alternative, of using an LDO from 3 AA(A) batteries provides a longer battery life as it discharges them at half the current (taking into account the different number of batteries). Efficiency is not that bad either, as with 3.3V out and a fresh set of batteries (4.5V) it starts at 73%. As the batteries discharge, the efficiency increases (funny, ha).
How much does it cost to keep an ESP8266 running per year?
Assuming always on, 70mA from a standard 5V supply through linear regulator, 0.35W consumed. Adding inefficiency and self consumption of DC/DC converter getting to 0.6W from mains(I measured). This is 5KWh per year, or about 1.1 euro at average EU price. If the price does not tell you anything, think of the effort for a human to produce this: your not so sporty, but decently conditioned person would spend 50 hours on a bike.
A pair of AA batteries will set me 0.4€ (in some quantity) and have the potential to keep a low power radio running a few years. So a low power radio battery powered temperature sensor will cost more in the long run compared to a cheap, mains powered ESP8266 temperature sensor.
NRF24L01 goes a long way….or does it?
I have used a hell lot of NRFs in my project, Stockie and encountered no major issues. They are super cheap and easy to get…but the very low transmission power limits the range. Not so fast! By combining the low power modules on the Stockies with a high power modules and antenna on the gateway I could get a lot of range (+/- 1 floors and anywhere inside the apartment). With a caveat, that did not matter for the application: allowing a lot of retries, just to play it safe.
I started working on this project with a RFM75 in mind, which is a clone of the NRF as well. It comes from a distributor, because of my ‘no cheap china‘ rule. The first lesson: automatic ACK does not work between cloned NRF modules and RFM75 modules. Rumor has it that Nordic hid some things in the datasheet and some bits are actually flipped in the packet, with the NRF clones following the datasheet while the RFM following the over the air transmission. Hence, automatic packet ACK and retry does not work between the sensor nodes (RFM75) and a NRF24L01 PA LNA (=NRF clone) gateway.
Implementing ACK in software (I used the Radiohead library) showed a higher on air time for the modules, hence more power. This really shows the advantages of the auto ACK the module does in HW.
Moreover, modules located far from the gateway required a significant amount of retries before getting a packet through, quite frequently. This leads to higher battery consumption and unpleasant delays, which could end up being a second even, which pretty much killed this module. I have tried the system with a single node, so only the nearby WiFis as pollution, though quite a lot of them.
So I moved on to my next favourite, the RFM69, which is superior due to operating in sub GHz band, more power and lower data rate. Check out the hardware section for more thoughts on this and my wishes for the perfect radio.
[Ths project is work in progress in an incipient state. Check out the related pages:
Lessons learned and why I did what I did
I have enjoyed building small home automation devices for many years, simple things that make life better or just cater for the lazy animal. The world has been dreaming about the internet of things where everything is connected for a while now. While the big guys are focusing on intelligent AI assistants, the market for simple devices is still not mature enough, being full of overpriced products that don’t want to talk to each other.
This leaves plenty room for diy projects, which at this point in time can be put together easily thanks to the dropping cost of electronics coupled with multiple open source software packages.
A bit of history
I started to automate things using the traditional computer parallel port and a literal bucket full of relays which drove my thirst to more complicated things that could operate independently. I jumped on to microcontroller projects and a few years later I made a small RS485 network. Moving taught me the important lesson of breaking free of the wires: some devices simply need to be wireless, while the plethora of others could go either way, saving the user from the ugly and complicated cabling experience. This is not an easy job, though.
Is my new ambitious project: do a lot of home automation while spending 1000 euro and 1000 hours working on it. Well, hopefully not that long time, but a budget and time limit give a good motivation to get things going. Plus, both constraints avoid the hobby trap of infinitely fiddling with details.
Some ground rules.
The budget limit is for final parts kept in the system. Failures don’t count, but are great way to learn.
No cheap china: parts used should come from good sources and be of consistent quality, as much as possible.
Distributed intelligence and context aware devices.
Cut corners, where possible.
Attention to security.
Modular hardware: easier to design and debug.
Modular software: easily build a new thing based on old ones.
Separate by function, easy to reconfigure.
Anything that runs on batteries should last at least 1 year in worst case.
Allow room for growth.
More to come….
Time to get moving. Make sure to check the related pages .
In Lessons learned and Why I did what I did, I explain the failures, experiences and calculations that lead to the current designs.
The hardware section contains hardware related things.
Software touches the devices’ firmware and control software.
A while ago I felt I needed to upgrade my work mouse to a higher resolution one, since I am mousing all around doing designs across 3 screens. In a purchase of impulse, I ended up getting a wireless one for a good price, the 4000dpi Mpow Dragon Slayer gaming mouse. I was happy with it for the first 2 months: 2-3 weeks of life at max resolution using rechargeable batteries without lights and an excellent match for my hand. Then the scroll started working improperly, it would change direction every few steps.
I thought the problem was not mechanical – bad contact, but since I did not have a spare scroll switch anyway nor time to invest in looking for a replacement…i thought i could try an electronic fix: de-bouncing the switch, which I saw no trace of being implemented on the PCB in a brief search. Cheaper de-bouncing is normally done in firmware, without passives, however if insufficient, I can compensate in hardware.
Here is the guilty switch, the one with the red part
The solution: add 2 1nF capacitors across the switches. I figured this would give a good de-bounce time with what looks like internal pull up resistors (~10…100KΩ) from the microcontroller.
And the terrible soldering job
Then I put it back together
Of course, opening it meant removing the feet, which don’t stick back properly
All done, the rodent is happily and properly working. Time will tell if this will last long enough, I will update if it breaks again. I hope the engineers at Mpow can see this and fix this really great mouse. Also a more “business” model would be great. The fact that the problem shows up so soon and for so many people tells me it is a software problem – not enough debouching. It only works while the switch is perfect. I have used plenty of mice so far and never found this to be an issue ever, even for much cheaper products.
[This article is alive and being updated with things that I use].
This is a summary about my experience with cheap electronic modules from China. I have used quite a few throughout the years, so there will not be any long video explanation, but more of a summary. The article is a living creature, with new updates as I test more stuff.
Why buy this stuff?
It makes sense for large distributors to sell you parts at exponentially higher markup when bought in smaller quantities, since it takes comparable effort to collect, package and send you 1 or 100. But the home user is interested in small quantity and most of the time using things in a typical diy recipe. This makes a ready made module carrying, for example, a real time clock chip along with its passives and backup battery a lot more attractive than just a bare chip. Since these modules are made of components quite close to the factories, in Asia, and sold avoiding a lot of the middle-men, it makes sense they would be cheaper than a 1-off component from a distributor. However, the ingredients used are not really top notch.
Some general observation first
These modules are cheap, generally everything is under 20ish EUR, which is the mark for paying VAT in the EU, varying slightly by country. This tax usually attracts another fixed import processing fee which raises the price significantly. Unless you are into high quantity, it makes more sense to buy items over this threshold locally.
The most important thing to understand is that these things are mostly provided ‘as is’ with no guarantees, no matter what ebay/other website will try to convince you, because…
“It works” does not mean what you think it means. I have learned this while discussing LEDs with a distributor: it works means there is light coming out of the LED, that is it. Big companies will count LED lifetime until it drops to about 70% of initial brightness. Generally speaking, “it works” means the thing is doing something somewhat related to what it should do, with no guarantee of any performance or operating parameters.
In general, you should assume that the parts on the modules might be fab rejects, clones or even something totally different pretending to be the real thing. Words like “genuine” or “original” are thrown in the tile to tell you they mean business.
With such a low value of the items, there’s no surprise that even though the seller would accept a return, paying for the return shipping is a no go. And they know that.
When you buy a lot of X quantity of parts, there are some that are crappy and even dead on arrival. It happened to me buying the NRF24L01+ modules, DC/DC converters, PIR sensors, even headers. I suppose they might do some testing on the 1 PCS sales, not on the lots.
Quality and functionality of some module will decrease over time and is not consistent among suppliers, as they find more ways to cut cost or make a clone of a clone of a clone, see the NRF24L01 below. This is the reason why I am not linking to places of purchase, you will not get the same thing anyway.
However, things are not all bad and these modules are worth it for some application. Think for example the NRF24L01, you probably don’t care that it is not compatible with genuine ones, and I don’t care that 1-2 of the 10 are not working, since I can buy 20 for the price I pay for 1 at a distributor. And hopefully, we will both never find out they break any radio compliance. But, I would not use them if I were to build something and sell it.
These types of devices are great for hobby and learning, especially the troubleshooting part. Or sometimes just exploring and getting to know the feeling of a device. So, if you proceed with the right expectations, good things can happen and great projects can come to life.
Here are the devices I have experimented with, but don’t take this information for granted. There are numerous suppliers and very high variability with all modules, not to mention some room for user error.
ESP8266. This is an absolutely great device and without access to a real good supply of these modules it is hard to say if the quality problem is with ESP8266 IC itself or the modules are just using bad parts. The 1 of the 2 modules i got first from electrodragon is still working fine in the LED logger. But, overall 2 others have died, both coming from ebay. Another thing I have noticed is that the devices, even though specified up to 1.8V and with good supply and decoupling capacitors, seem to operate only down to about 2.6V.
NRF24L01 – 2 black ones DOA got while working on the Stockie project. 2 more died during experimenting from a batch of 10, without being stressed in some way. Another batch of 10 had 1 DOA. They are partially incompatible with genuine chips or “real” copies like the RFM75. But things get really bad after a while as they are trying to make them even cheaper than they are. A green version exists with an incompatible pinout which I did not test because of this. The high power version used as a central node coupled with low power versions on other nodes can give you quite some range.
Step up/down DC/DC converter, lot of 5, look at the great soldering job. The IC is far off the PCB, with only a bit of solder at the end of the metal tab. They are nowhere near capable of what they promise, de-rate 2-3X for continuous operation because of bad soldering, under performing IC, no heatsink and high ESR caps.
3mm LEDS: quite a bunch of them. Very inconsistent in brightness at the same current. Quite a few of them dead, maybe 3-5%, so I would not throw this in a project without giving it a try. A couple of them they died without any stress in some more long term assemblies. Stay away from them if you want to use them in anything more permanent, I know I do.
Bad led strips, bright and nice warm light, but getting dim fast as tested with the LED logger. I use these in a wardrobe, so no problem with lifetime there, as they run only minutes per day.
Ribbon cable that is so stinking of plastic smell even after letting it “out to dry in the sun” for a month. No picture, i threw the thing away.
These breadboards are so terrible i threw them away. They are crooked and rusty. Nowhere near the quality of a regular breadboard.
These breadboards are OK, but quite small.
Ramps 1.4. Thought getting everything for a driver is cheaper separately but this thing came with such bad soldering I had to give up on it. There is not much on the board that could not function, just that all the connectors on the back were poorly soldered at an angle.
Component tester. The original one is an absolutely great device and was on my to build list for a long time, however not of relevant priority. The version i got is much nicer, as it comes with a graphic LCD that is more intuitive to use. Precision is not that great, judging from comparison with the multimeter, but that is not what I am looking for. It is good to know some simple things, like if those cheap 3mm LEDs are DOA or not or making sure you don’t have a old and dried capacitor. SMD component testing is rather impossible by placing the part on the board. Recommend it only as an aid to a good multimeter.
1.44” or 2.2” IL9341 LCDs use a controller chip for which you can find a driver on many platforms. Pretty bad in terms of colours and one of them fell apart, even though it is still working. The headers are compatible across sizes and the big ones support an awkwardly placed SD card slot on them, but I never used it. They are the best thing to get if you need a cheap colour LCD.
WS2812 LEDs are a pleasant surprise, as my LED logger is showing, they are good for long term lighting. However, they do come with some limits, as the strip copper is highly inadequate for carrying all the current with LEDs at max. The data input pint is also very sensitive, I have managed to break quire a few. I am using them on the kitchen counter along with a motion sensor and that is pretty much the only light i normally use. Being RGB LEDs, they increase the “saturation of vegetables”.
WS2812 ring I got for an indicator, which was fine. However I tried to use one for lighting and they are nowhere near capable of dissipating the heat of all LEDs at max brightness constantly.
RFM69 – at the moment it costs about as much as it does at distributors, if I purchase 25 minimum. There is clear difference in components and the ebay one appears to be soldered manually and poorly. I suspect they are factory rejects manually fixed. My sensors website folks seem to use them without issues and the one I got works so far. However, I will continue to purchase them through regular distributors.
Voltmeters – the ones with 3 wires are great, you can even hack the micro on them. Don’t know about long term life or stability. 2 wire ones I have not tested, but I suspect they are more limiting.
Buzzers – waaaaaaaaaaaaaay quieter than the same thing from a distributor. [If CAPS says I am SHOUTING, what do I use to talk quieter?]
Terminal blocks – at quantities of 10s to 100 similar to distributor price, but the ebay ones stink.
Headers and connectors – cheaper than distributors, specially in small quantities. Some stink, some don’t. The gold coating is almost missing and they are more prone to oxidation. Avoid in things that you would care to work over long time, I suspect they will rust.
Jumper wires. I have talked about this one before.
FT232 adapters. I guess you know how these work out. Cannot say why, but I prefer the CP2102 modules below.
CP2012 USB-serial adapters. Clones, all with same serial number – a pain to manage multiple in various USB ports. Occasionally lose connection, but SW like YAT reconnect automatically. Edit: apparently the serial number can be changed, but I have not tried it.
Touch sensor – not low power, but ok. Seems to work, no long term testing. Given the application, there should be a jumper to disconnect the LED, as it is burning more power than the chip. Thought it can work as sit sensor, while experimenting for Sit.Up, but the auto calibration means it does not detect a touch after a few seconds.
Micro USB breakout – no issues, but they could have used thicker lines for power. A version with integrated ESD on the data lines would be a lot better.
Step UP DC/DC converter Noisy and pretty incapable of operating at the specified power. Use 2-3X derating.
USB battery charger – no issues so far.
QFN/TQFP to DIP adapter – smart because it lets you add a capacitor or pull down resistor to every pin. Not great, since the pads are too wide and solder bridges are hard to avoid. Don’t forget to connect the ground plane to the ground separately.
PIR sensors – have quite a few large ones operate for a few years. As with other packs, from a pack of 10, 1 was DOA, one very insensitive. Small ones seem to do fine as well, but are less sensitive and you cannot adjust the sensitivity or time.
CSR8645 bluetooth module. Overheating from start, despite proper supply. Died in less than 1h.
Bluetooth device for my blue panda. Died after some 10s of hours of usage over the course of a couple of years.
HC-SR04 – ultrasonic sensor. Works as described, but only briefly tested on the Sit.Up project.
US-100 sonar, smarter than the HC-SR04 and can operate at lower voltage. No long term testing, just brief playing with Sit.UP!
Nokia LCD – refurbished parts from old phones, mine have bad contrast requiring adjustment, but great LCD for some LOW power displays. More flexible than the typical 16×2 LCDs.
Vibrator motor – used in Sit.Up. One of 5 DOA and pretty weak compared to what is found in modern smartphones.
25 EURO oscilloscope. Just amazing what you can get in terms of oscilloscope for such a low price. I got it out of curiosity, it is pretty impractical, but it is a lot better than no oscilloscope for a beginner.
A project out of frustration. A hardware solution to bad software…
[Project complete……but check in a few months for performance reporting]
Also available at hackaday.io
AutoResetRRR is a kind electronic frustration reducing device: it cuts the power periodically to devices that can go nuts (routers, net cams, servers), but it does give a heads up. If all is well, they can shut down safely and start back up. If not, the power cycle can fix a thing or two.
I have a raspberry pi time-lapse rig that sometimes hangs. And a few simple IP cameras also used for time lapse, all a bit inaccessible. And my modem/router that comes from the ISP gets the “slow internet syndrome” every now and then.
They should have good software, but they don’t. I cannot change the software in most devices to tell it to restart periodically, unlike my openwrt stuff. So I have fix this in HW by cutting the power with the AutoResetRRR.
Oh, and it allows devices like the RasPi to have a soft shut-down button like you expect from any PC.
What it is
A small devices that you place between the power adapter and your device. I works with most supplies from 5V to 35V, and can switch over 3A, so practically any device you might find in your home. From time to time, say once a day, it cuts the power to that device for a few seconds, forcing it to reboot. For devices that can use this, such as a raspberry pi, a separate pin can warn a little ahead of the coming restart and allow for safe shutdown.
As or the bells and whistles, especially for the raspberry pi, there is a possibility to shut down the power permanently by pulling a pin low.
Why it is not? Or the things I thought about before
A 555: because it’s difficult and requires bulky components for such low duty cycle, plus it is hard to get long durations or a pre warning.
A programmable of the shelf timer: it’s not possible to get a pre shutdown warning with it. Plus, I need quite a few of them, which makes my solution more cost effective.
ESP8266 based: mostly, too much current. A lot of the devices I have don’t have the margins to support the peak 250mA from their power supplies. Plus, so far quite a few of my ESPs have died after just months of operation.
Just a way to press the reset switch: it’s too much effort to get inside most devices.
A super complicated device with touch screen, configurations and bells and whistles: I want something simple that can have a high reliability and needs little time to design.
This is the first device I made on a bread board, but the PCBs are already mostly designed. So far the software is incomplete, but the reset time-out is working. The blue LED is the one that will blink, while the green one simulates the device.
Schematic and PCB
I finished the board and sent it to the fab. Schematic and PCB rendering below. Files are available at GitHub along with the firmware and raspberry pi software. The usual 5V regulator with fool proof diode ensures a good 5V supply for the ATTiny13 micro, up to 35V input. There are no worries for powering the device from 5V directly, at the low current consumption it will get about 4V, enough for proper operation. But of course, you can totally skip the regulator in case of a 5V supply. A IRLL2705 logic level NMOS takes care of switching the load. And the brain is a small 1k of flash micro, the ATTiny13.
Your typical LED insures a nice blinky to tell you everything is working. The same output is going to intelligent loads like the Raspberry Pi: 2 minutes before the reset the LED will stay constantly on, to tell it to shut down. The same pin is used bidirectionally: if the load will pull it to ground, that is a sign that it should be powered off soon, so the AutoResetRRR will cut the power after a delay.
I made the PCBs at Elecrow, and due to the small size they sent quite a few extras. Time to get soldering
First one assembled
The first device skips the 5V regulator, as I am testing it with a raspberry pi. Everything is red, even the LED. I began to test it for the raspberrry pi as this needs the additional python software required to shut-down the pi safely. I am thinking to implement the functionality of a power button as well, will be a simple one, since the Pi does not have such functionality.
To contact the side ISP connector I use a home made PCB with a simple 90 degrees connector with pins slightly bent
And brief tests with the Pi, shutdown during the warning time works smoothly.
Parts are here and…
It appears I have accidentally ordered the wide version of the SO8 package for the tiny13. It has been
5 years 0 days since the last wrong part purchase. The pitch is the same, so I will probably get around this by bending them.
Mini assembly run
I have assembled 6 more devices, for a total of 8. Collecting the parts, assembling them and programming the 6 took slightly less than 1 hour, that is 10 minutes for each device. Not bad.
Notice the 2 ways to connect the power, supported by the PCB: using terminal blocks or DC jack. Of course, any combination of the 2 is possible. I prefer terminal blocks for all the devices that are out of warranty and I can cut the cord to as this allows for a more optimal placement, such as at the middle of the cable.
And finally, some tests with the most relevant type of device: the router. Disclaimer: this is not the router it will be used for, fortunately this can run OpenWrt.
Camera installation coming soon… and possibly a 3d printed case, although i have some project cases that fit the device nicely and that is a faster way to get things done.
Project is now complete: will report in a few months with the performance of the device!
1,527 views since Nov 2016
Update exactly 7 months after initial post: I have used this on my night stand, for a little bit of instant light during the night. The thing is still working, but visibly dimmer, the batteries are just under 1V each, so mostly discharged. 7 months is a pretty good life time.
This does not deserve so much attention, but here it is. I got one of the Ikea Molgan motion sensor lights and thought it is too bright for the application. The light has 5 LEDs inside and the tipical BISS0001 pir IC.
They were bright enough to use a current limiting resistor for each LED(the right way to do it), so there are 2 solutions: increase the resistor for each LED, or just leave a single one ON. I took the lazy way out and cut the trace after the first resistor.
In case you are wondering, the original lamp burns almost 70µA while on standby and almost 100mA while the LEDs are on. This gives you about 1.6 years of standby and 10 hours of light or however you manage to combine it(about 6 months at 5 triggers of 30 seconds per day). With this change the light time is increased to 5X, so about 50 hours.
Too bad they used AAA batteries, AA would have been slightly larger, but with 2.5 times the life.