Alexander Tuxen

I hate tinkering with AC mains. But if you want to get “real” things done around the house there is no way around it. So before this goes any further, here is the disclaimer:

AC mains power is dangerous. It can kill you and/or burn your house down if you are not careful. Unless you know exactly what you are doing, DON’T TRY THIS AT HOME!

That being said, AC mains is no rocket surgery either and probably no one in their right mind would call a union electrician to hook up a lamp.

So, what is there to switching mains? Not much, actually, it’s just a sufficiently rated relay to switch the hot or neutral wire (it doesn’t matter which, either will break the circuit and prevent current from flowing).

There is a variety of readily made hardware available that will accomplish this but from my point of view all these products are flawed: The ones that work reliably are expensive and the cheap ones are unreliable.

Hardware:

I had a few very cheap and extremely unreliable ones around, so the obvious solution was to gut them and use the enclosures for my own design.

I got these about 20 years back, as you can tell by the grime.. The set of four was about 30 DM, back in the day.

All those certifications… Must be good stuff inside…

The enclosure looks quite nicely engineered. But what is it with that crappy and kind of burned looking circuit board?

Yuck! This isn’t even a cap dropper, this is basically just a resistor on a mains wire, and it looks fried up pretty good. How did they get all those safety stickers with this?

The design itself is simple: Just hook up a relay to an Atmega with an RFM12B. If there wasn’t the issue of a power supply. Looking at commercially available solutions there seem to be mainly two options: Go with a full blown switch mode power supply or implement some sort of ultra cheap non isolated cap dropper type power supply. Both have a list of pros and cons:

SMPS pros:

• isolated from mains
• efficiency

These are really nice. But also very expensive

 

 

The switching transistor bent over to the secondary side was the reason this one was rejected

Almost as tiny as the “Apple” chargers

It’s cheap, small and at first sight not too dangerous. At least there were no reviews about these things blowing up all the time.

This looks more like it. A nice big slot between primary and secondary side and no parts hanging over from the dangerous side.

With this out of the way I was finally set to go. To make the PSU fit the enclosure I hat to cut it along the slot that was already there.

Nice fit. The mains side of the PSU is on the left

Space was an issue with this project. I could have easily thrown those old sockets out and gotten new ones with bigger enclosures, but where would be the fun in that?

So, after I pulled out that deathtrap load of crap PCB I found inside, I went through the usual process of measuring the enclosure and designing a new board in Eagle.

Boring.

 

Also quite boring. This is hand routed, and I needed six jumpers. Lame.

To accommodate the PSU, the relay and my controller board I had to make two PCBs: One for the controller and RFM12B, the “cold board”, and one for the relay and the PSU, the “hot board”.

The “hot board”. This will only contain the relay and mains connections for the PSU. This isn’t its final form. The leftover copper at the lower edge of the board was of course removed. At the left lower edge I hat already removed a bit too much.

To connect the PSU to my adapter board, I just bent two regular pin headers and soldered the PSU’s mains contacts to them.

 

The “cold board”: This will contain the RFM12B and the Atmega

 

The push button and the LED are still missing.

 

Note the absence of parts on the right hand side of the board. That will be on top of the mains side of the power supply.

The controller board would be on top of the PSU. To eliminate the risks of accidentally shorting anything to the mains side of the PSU I arranged all
parts on the controller board so they would be a safe distance from all the scary mains stuff.

The hard part is done. Those heavy duty mains wires weren’t too much fun to work with.

 

Almost completed. Now only the wires from the PSU and to the relay need to be connected.

The prototype worked perfectly, so I was ready to go into production…

Three more controller boards. I was smart enough to put three boards on a panel, but not to think about routing the outlines of the boards. m(

 

…and the PSU/relay boards.

There was some time between building the first prototype and finishing the rest of the bunch, so it slipped my mind, that I used a m168p on the prototype and m328ps on the other three, but it wouldn’t have changed anything, because I hat no 168s left. Well, now I have to have a type A and a type B in my Makefile. Never mind.

The semi finished sockets on the “assembly line”.

They work beautifully and the power supplies are quite efficient. With the relay idle they draw about 0.2W and with the relay active it’s about 0.6W. I vaguely remember, that the original circuit drew about 2.5W, no matter what. I could maybe reduce the active power consumption another bit by driving the relays with PWM, since they need a lot less power maintaining an active state than switching to it, but that’s for another day.

I finally got around to adding the LEDs. The buttons are still missing, though.

Software:

On the code side there are a few things to mention:

The sockets tie into my sensor and home automation infrastructure, I have yet to write a post about. Basically every type of device uses a separate rf12 node id, which is shared among all devices of that type, which in turn all have their own individual mcu ids, which are stored in eeprom and can be set dynamically.

When a virgin socket is powered up for the first time its mcu id will be 0xFF, because that’s the default value of untouched eeprom. If the id is 0xFF, the controller will go into a loop where it sends a packet every second announcing that its id is unset. In this mode the only command it accepts is one that assigns it an mcu id, which is then written to eeprom.

With the mcu id set, the controller will enter its normal mode in which it will listen for packets with matching node- and mcu id and do what it’s told. In this mode the relay can be turned on and off or queried for status.

Conclusion:

This was a fun project, but I wouldn’t go about it this way again. The power supply alone is way too much hassle. In the meantime I’ve learned about a nice sounding switching regulator for transformer less power supplies (and ordered a bunch), so I’d sacrifice mains isolation for simplicity, but I won’t play around with them without an isolation transformer. That would probably be really painful.

I’ll probably stick to buying some cheap sockets and gutting them, because that’s the easiest and cheapest way to to get my hands on suitable enclosures, but I’d choose something nice and big, and maybe even a cheap brand name, to improve the odds that the same model will be around for a few years. After all, I don’t want to have to change my “Frankensocket” design around all the time.

I’ll also make some with screw terminals or just wires sticking out, instead of sockets, that can be hooked up to ceiling fixtures. Those would easily fit in a small project box or maybe even a piece of heat shrink tube.

I must add that I’m not the first one to do this. There is another, very similar project here.

As usual the code and all PCB design files are available at github.

A while ago I built a little remote to open my garage door (well, not actually my garage door but the one of the house I live in, but who cares). But the greedy kid I am, I wasn’t satisfied with just opening the garage door with it. After all it has four buttons, and so I planned on also using it as a remote for my yet to be built home automation system (a few parts of it already exist, but there is a lot of work to be done before I can really call it that).

The problem was that it had a nasty bug which was really hard to track down: It would work as intended for some time (sometimes hours, sometimes even days), but then, all of a sudden it would hang. And not only did it seize to work, it also stayed in some state where it consumed lots of power and ate up the battery in no time. This was far from usable in real life.

I had heard of a little thing called watchdog timer, which could reset the MCU if it hung. So the first thing I did was to add this watchdog timer to my code. Sure enough that didn’t fix my problem, so I tried everything I could think of from incrementing counters in EEPROM after every “real” instruction in the code to hooking up oscilloscopes and logic analyzers. But the only thing I found out was that it somehow, sometimes would get stuck in some weird kind of a reset loop.

When I ran out of ideas of what else to try I started badgering people on various internet forums. And after trying all sorts of changes to the code that people suggested, someone came up with the idea of deliberately causing a reset (among a few other things). I implemented that idea in my code and what happened was, that now every time I caused the reset, the MCU would hang. That may not sound like a good thing at first, but at least now I could reproduce the bug!

After that all it took was a bit of searching the web until I found out about a register called MCUSR, the MCU status register. Turns out that if the watchdog wants to reset the MCU, it writes some value to this register that would cause the MCU to perform the reset. But for some reason it doesn’t get cleared after the reset is done, causing the MCU to keep resetting itself until the battery is dead or the world ends, whichever comes first.

So in the end all I had to do was to set the MCUSB to zero right at the beginning of the setup() routine and all of a sudden the reset would be performed as intended and the MCU would work again. For now. I’ll have to give it a few weeks to really call this case closed, but I’m pretty confident that this was it.

All that’s left to do is to say a big THANK YOU to all the people who tried to help me solve this mystery, and especially JohnO on the Jeelabs forum, who came up with the idea of causing that reset on purpose (although he might have had something completely different in mind than crashing the MCU every time the reset fired).

The updated code can be downloaded here.

This is a short one. At least compared to the usual walls of text I post.

Due to the nature of my water heater (a continuous-flow-type), it’s power consumption is highly dependent on the water pressure and flow-speed. The more and faster the water flows, the more power it consumes. Apparently this happens in three stages. The first two turn on immediately as you turn on warm water. But the third will only com on if needed, i.e. if the water consumption continues to increase. Also these three stages are connected to three different mains lines, which means, they get counted separately.

Saving energy, resources and money is fine, but sacrificing creature comforts for it? No way!
When I take a shower I want it hot. And I don’t want it trickling down on me, either.

That’s not a problem with my new water (and thus electricity) saving shower head. What is a problem, though, is that the water flow has to be adjusted just right to keep the third (and greediest) stage of the water heater from turning on.

So to be able to see what the water heater is up to, while in the shower, I built this little thingy:

It’s just a Jeenode with a few LEDs

The yellow, green and white LEDs blink if there’s a pulse received for one of the three mains lines, and the red one will blink if a packed got lost. Right now it’s powered with a single AA battery, but that lasts only a couple of days, so I’ll have to add a little power supply, probably from an old phone, since I have plenty of those.

The code to drive it is here:

https://github.com/alibenpeng/powerblinker.git

Einstein once said that only two things were infinite: The universe and human stupidity. The former even he wasn’t sure about, and the latter I found out the hard way. But I’ll start from the top:

I’ve had my smartmeter running for a while now and since the readings looked plausible I assumed they were accurate. Well, they weren’t.

The meters I use generate 2000 pulses of 90ms length for every consumed kWh, and the way I counted them was to collect them for five seconds and then transmit a summary. After a while I found out two things about my power consumption:

1. The water heater (a continuous-flow-type) consumes an insane amount of power, and
2. The computer running the metering software also was a bit too greedy for my taste.

I couldn’t do anything about the water heater because it’s installed permanently and after all it’s not even mine, but I could try and tame it’s power consumption by reducing the water pressure and/or the flow speed by using a water saving shower head. As a side effect I’d also reduce my water consumption. Two birds with one stone! And the PC running the metering software also had to go.

To get rid of the PC I had to rewrite the metering software from scratch, because the software from the volkszaehler.org project I was using is based on a full-fledged LAMP-stack (Linux, Apache, MySQL, PHP). The main problem was the MySQL-database, as this keeps every reading I ever took and has to access them all at once every time I’d wanted to view my consumption graph (remember, I took readings every five seconds, so there were a LOT of values in there).

I opted to use something called RRDTool instead. This is a nifty little tool, well known to sysadmins around the world to keep stats about routers and switches, system loads and whatnot. Since there are usually a lot of data sources too keep track of, the databases have to be kept small. The way it achieves this is to use fixed size databases of different resolutions and aggregation functions to consolidate older data.

While I was at it, I also changed the way I collected the pulses from the meters from the five-second-summary-method to transmitting every pulse as it came in. This is where things started to go South…

Before…

But the really stupid thing I did was changing something that drastically influenced my power consumption (the shower head) and the way I collected and processed the consumption data at the same time.

The result was that I grossly overestimated the savings from changing the shower head and thought I’d cut my consumption by about 50%, since that was what my new readings suggested. I never even bothered to check the “official” meter from the power company, which finally bit me in the ass when the next power bill came in.

…after…

Only then did I find out that my readings were way off! They may have looked plausible, but weren’t anywhere near my true consumption.

After this wake up call I started to investigate the error. At first it looked like the new way of counting pulses was to blame, so I changed that back to the old way. That gave me way higher readings but by then I had grown suspicious if those were correct. They also weren’t.

So the new method was obviously loosing pulses while the old way was counting pulses that weren’t there. The one thing both had in common was the way they went into the controller:

When idle the controller was in sleep mode and an incoming pulse would cause an interrupt to wake up the controller and send out a packet or increment a counter, respectively. Since the driver for the RFM12 transceiver is also heavily based on interrupts I figured that might have been the problem. I also had some code to blink an LED using the Arduino delay() function, which is a really bad idea when using interrupts at the same time, but I threw that out first and it didn’t fix the problem.

So I changed the code to poll the inputs instead of sleeping and waiting for interrupts and that seemed to help with the lost pulses.

But things only got weirder: Now some pulses were counted twice. So I started counting milliseconds between pulses and it turned out there was some kind of bouncing about 75ms after some pulses, while others looked OK.

I knew that mechanical buttons tend to bounce, but this bouncing would occur in the first ten ms after the button was pressed, not 75ms later! 75ms is close to eternity, even for a tiny and slow 8 bit microcontroller. A real computer could go fetch a coffe and have a smoke in 75ms! Also there weren’t any mechanical switches anywhere near the circuit I’ve built. The pulses are generated digitally by the counters, go to an optocoupler and straight to the controller.

But I didn’t want to rip the whole thing out of my breaker box and dissect it with an oscilloscope, so I just wrote a little routine that ignores every state change that occurs less than 90ms after the input went low. Think of it as a really slow debouncing routine.

and the real thing (hopefully)

So far my readings look OK, there still is some 0.03kWh error per day, give or take, but that’s nowhere near what my old code produced.

As usual, the code can be found in my github account:

• https://github.com/alibenpeng/smartmeter-frontend
• https://github.com/alibenpeng/powermeter
• https://github.com/alibenpeng/wl500g

This one started with a power bill. One exceptionally high power bill, that is.

I had been reading and thinking about smart metering and smart grids for some time already, and when the bill hit me I decided it was time to act. But where to start? Those kill-a-watt-kind-of-things weren’t an option because I needed to measure the power right at the point where the lines enter my apartment, because I didn’t want to miss anything like the stove or the water heater, which don’t plug into sockets, but are connected directly.

The guts of my Breakerbox: In the lower row you can see the main breaker on the left and the breakers for the stove and the water heater.

But I also didn’t really want to mess with my breakerbox if there was any way I could avoid it. So the first things I had a look at were inductive sensors. Only two problems with that:

First, the coil or the ferrite core of the sensor has to go around the conductor you want to measure. So either the coil, the core or the conductor has to be split open to mount it. There are sensors made especially for this purpose, like these: https://www.flukso.net/content/50amp-current-clamp, so this issue could be addressed by simply throwing money at it, because those specialized sensors anren’t too cheap. Actually there are even some DIY projects for these sensors out there.

The second problem is, that these sensors only measure current. We want to measure power consumption and power is the product of current and voltage. So we’d need to measure the voltage, too, if we want accurate measurements. Now this definitely isn’t achievable without a physical connection to the conductor.

So there you have it: No accurate measurement without physical contact to hot wires. Just no way around it. Shit.

This meant, I couldn’t do his by myself. Luckily that’s not that much of a problem, because a friend of mine, who is a certified electrician, had offered to help me out.

This is why some folks in Germany started the volkszaehler.org (which roughly translates to “peoples power meter”) project. This project is a really great starting point for everything about DIY smart metering. They’ve got open source software to track the consumption (among other things like temperatures) and several controller designs to connect your meters to the internet (or LAN).

 

This is the volkszaehler.org frontend.

This was the first design. It was based on a RN171-Wifi-module and an ATTiny2313, and didn’t work. Notice how crammed the area above and on the right of the RN171 is. That’s not only capacitors and resistors, there’s a good deal of vias in there, too. The bottom side of the beast.

I spent literally months of debugging before I finally decided to can it and start from scratch.

This is what I came up with:

 

Not much to it. The crucial parts are an ATMega, the RFM12, and the headers to connect to the other board.

Actually this design is derived from the JeeNode, which is (kind of) an Arduino clone with a RFM12B 868MHz FSK transceiver.

Since I was eager to keep things simple this time, and also because this was my first attempt to design a pcb in eagle (or any pcb-layout-software, for that matter), I went with a single sided board. For this all SMT-parts have to be mirrored and placed on the back. But after that epic failure with the first board I also decided to use as few SMT-parts as possible. Luckily the RFM12B is the only one and that’s also comfortably big.

The layout in eagle. Notice the RFM12B on the back of the board

Before you can feed the layout to the router, you have to convert the eagle file to gcode, and while you’re at it, you could just widen the traces a bit, so that you’d have a bit less milling. If you don’t know what I’m talking about, the next few pictures are pretty self-explanatory.

This is what the layout looks like before being “blown up”

This is what the layout looks like after the traces have been “blown up”. The colors are added by the software to ease identifying traces and nets.

The milled and drilled board. I only remembered to take a picture after I already had started soldering stuff to it. Note that it’s no problem to route traces between IC-pins. Also note that some holes (e.g. the ones for the pin headers) are wider than others.

This was done with pcb2gcode which is available at http://sourceforge.net/apps/mediawiki/pcb2gcode/index.php?title=Main_Page.

The receiver:

– Tell me, Captain Obvious, what good is a single RFM12B radio transceiver if it has no one to talk to?
– Well, not too much, obviously!

Anything with a RFM12B module (and probably others) can act as a receiver for the power meter.
I went and built a receiver into my Asus WL500gP Wifi-router, but you don’t have to:

There are (Arduino compatible) kits and assembled USB-dongles that contain a RFM12B and an ATMega328 available at http://jeelabs.com/, so you could just get a JeeLink or a JeeNode USB and use that.

 

My breakerbox with my smartmeter in it: Upper row: The controller, middle row on the right: The three meters.

 

 

 

 

Resources:

 

The code as well as eagle files are available at github:

• https://github.com/alibenpeng/powermeter
• https://github.com/alibenpeng/wl500g
• https://github.com/alib
  enpeng/ahans

I’ve only just started learning C, so the code is probably shit.

Credits:

All PCB milling was done at the Attraktor hackerspace in Hamburg (website in German).

(featuring my first real factory made PCB)

It’s been a while since I built the garage-door-proof-of-concept-remote. As stated in the according post, the “industrial design” part of the PoC managed to be flimsy and clunky at the same time. So there was some room for improvement.

Back when I still thought the original remote was using 434 MHz, I bought two little “cloning remotes” or at least so I thought. I was eager to save a few Euros, so I got mine from some shady Chinese eBay-shop, and sure enough the ones I bought were far from capable of cloning anything. Instead they just sent out fixed codes, no matter what I tried. Well, at least they did something.

The enclosure.

But even if I had gotten the “real” ones, it wouldn’t have helped a bit, because those still would only work with 434 MHz and I needed 868 MHz.

So there I was with my homemade (but working) remote and my two Chinese knockoffs. Even though those were useless, I still liked the enclosure and started wondering if I could just use that and design my own PCB to put inside. I could even harvest a few parts of the original PCBs, like the buttons and the blue LED.

The disassembled remote and the original PCB. They use a 12V battery for the 434 MHz transmitter.

The first thing I did was to take measurements of the original PCB and transfer that to a simple Eagle layout. After quintuple checking the positions of every hole, notch, button and the LED I locked their positions so that I wouldn’t accidentally move them out of place later in the process.

The back of the board on a scanner.

And the front. At first I tried to take measurements from the scan, but I soon realized I would have to get a caliper.

The problem with my layout was that it would not work with the kind of PCBs I could make on the CNC router at the Attraktor because the board would have to be double sided and I’ve tried to make a double sided board before and failed miserably. So I had to have the board for this project manufactured in a real fab house. The problem with that is that it’s really expensive for low volumes. If I had the board made on my own in Germany it would have cost me about $50. So that wasn’t an option.

By chance a friend told me about the dorkbot PCB-service (now called OSHPark). This is an extremely cool service run by a guy who started out collecting PCB layouts for his local hackerspace and put them all together on a big panel to reduce manufacturing cost. To fill up the panels quicker he opened his service to the public, so that is where I went.

My Idea of a garage door remote in Eagle. Except for the antenna on the right I was really lazy and let Eagle autoroute most of the traces, which wasn’t too brilliant.

Having the boards made and shipping them across half the globe takes about 4-6 weeks, so after a long wait I finally had these in the mail:

I had round edges and a little notch on the “Dimension” layer. The notch is there but the round edges aren’t. I’ll have to remember to sort that out before I order the next batch.

And when I finally held them in my hands, it wasn’t long until I discovered the first fundamental design fault: There are a bunch of vias (gold plated, even!) right where the negative terminal of the battery would go. These I would have to insulate somehow.

Later that night one of the boards looked like this:

The ATMega is facing the wrong way. Ignore that.

I soldered the TQFP part using the solder wick technique shown at about 6:25 in this video (and probably many others).

I left out the LED and the accompanying resistor on this board. Also note that I left out the notches on the sides of the board. I figured that it would be easier to just cut the enclosure to fit instead. Which worked.

I insulated the vias under the battery clip with this stuff and I also put a lot of solder on the sqaure pad in the middle to raise its level above that of the vias.

The ISP connector is done with the pads on the left. Now I had to find a connector to fit. A PCI connector should fit, or maybe an old floppy drive connector. Too bad I didn’t have any of those around. All I could find was an old connector for a C64 datasette port, if anyone still remembers those.

My barely working ISP Plug.

The pitch was totally off but it was the only thing I could find, so I used it. It was a royal pain in the ass but at least sometimes it worked.

Not that night, though… The programmer wouldn’t even find a controller to talk to. After checking all of the connections were good, I finally found it: The ATMega was facing the wrong way. Nice work.

De-soldering a TQFP part is no fun but it can be done. You have to add lots of solder, so that all pins are covered, and heat all four sides in a swift procession. The trick is to have the fourth side heated while the first is still hot. You’ll have to go around the chip for a few times but eventually it’ll come loose and you can just wipe it off the board. The major rule is: Patience > Violence.

After having this fixed I could flash the controller but the damn thing still wouldn’t work. I had to get out the logic analyzer. Luckily the connection between the ATMega and the RFM12B is an SPI connection, which is basically the same as the ISP connection for the programmer, and it also uses the same pins (mostly). So I could connect all but one of the analyzer probes to the programming connector. With help of the analyzer I could see that the controller was talking to the RFM12B on the MOSI line but wasn’t getting an answer on the MISO line. This meant that the RFM12B wasn’t working properly for whatever reason, most probably a short circuit somewhere on the board.

After poking around with the multimeter for another while I found it. Or, more precisely, I found out which nets were shorted out, but I had no idea where.

By now I had a little practice in de-soldering larger SMD parts, but even after removing the ATMega and the RFM12B (the de-soldering trick described for the ATMega works with that, too), the short was still there. It was between the SEL signal of the RFM12B and VCC, i.e. the positive terminal of the battery. But since these two nets virtually never cross paths or even come close to one another it had to be somewhere else. And here it was:

The SEL trace of the RFM12B crossing the drawing of the battery clip on the “Dimension” layer. Looks perfectly innocent in Eagle.

This is what it looks like in real life:

Not so much in real life. The metal of the battery clip cut through the soldermask somehow and shorted out VCC with SEL.

After gently bending the battery clip everything worked like a charm. Well, at least the hardware did.

The software:
The PoC didn’t have a real program logic at all. As soon as you connected the power, it would transmit away. For this project I wanted something slightly more elegant. In addition to just sending the garage opening signal, the buttons should send something I could use around the house, like a unique ID, that I could process in projects to come. Also I had to do something about the current consumption. Both, the ATMega328p and the RFM12B have ultra low power sleep modes and I needed to utilize those to make the coin cell last more than a few hours. Again I had lots of help from the internets, particularly here and here somewhere near the bottom. After some tweaking I had the standby power consumption down to under 1 µA.

At this point I’d like to praise the Internet. I couldn’t do shit without it.
The only problem with the code was that it wasn’t very stable, and I couldn’t really fix that.

(The PCB design actually reflects how little trust I had in my own coding skills: I put in a little solder jumper to be able to use one of the keys as a reset button for the AVR. But that was planned as a last resort in case I really couldn’t get the code to run properly.)

Luckily, for cases just like this, the ATMega (and probably other microcontrollers as well) has a watchdog timer, that will reset the whole controller if you don’t reset the timer before it runs out. After implementing that, everything is running smoothly for several days now.

Conclusion:
I’ve learned quite a few things about PCB design doing this project:

• Don’t trust the autorouter of your PCB design software. Better yet, on a project as simple as this, don’t even use it.
• Think 3D! It’s hard to imagine a
  real life PCB just from an Eagle layout. There are 3D rendering plugins for Eagle and other software with this functionality built in, but I found it the easiest to just print out the PCB layout on a piece of paper and place the parts on it.
• Only use parts in your design that are actually available to you. I have  yet to find a correctly pitched edge connector for the ISP connection.

Total cost of the project:

• PCB: 3.30 €
• ATMega328p: 1.80 €
• RFM12B: 4.00 €
• Chinese fake-cloning-remote: 2.50 €

Makes a total of 11.60 € or US $ 14.35 at the time of writing. All prices include tax and shipping and all items were purchased in low volumes.

Files:
All design files as well as the source code for the controller are available at my github repository:

• https://github.com/alibenpeng/keyfob
• https://github.com/alibenpeng/keyfob_hardware

Update:
As it turned out, the watchdog timer (or rather the way I implemented it) didn’t really help, actually it made matters worse! After a long and tedious debugging process I finally think I’ve got it right. Read about it here.