Friday, October 10, 2014

RCExplorer Tricopter v2.5 Build

Over the last year or so I've picked up flying RC multicopters. I started out with micro and nano sized toy quads like the Hubsan X4, which are great for learning the basics about flying such a thing, but eventually I wanted something more "Hobby grade". Something I will have to build myself. Something "real". Also something intimidatingly large, as it turned out.

I used the original arm length of 48cm and the thing is humongous! Those are 11" props on there (not screwed on of course, just for scale). And please excuse the unit confusion. We have the metric system where I live, but some things like screen sizes or propeller diameters are commonly measured in inches.
 So I decided to build a Tricopter design conceived by RCExplorer's David WindestÃ¥l, v2.5.

My take on David's "Coffin Body"

Frame and Landing Gear

 David's original design features an arrow shaped frame, but there is also an alternative version which he called the coffin body, for obvious reasons. That was the frame I wanted to use, but I didn't know where to buy and/or cut carbon fiber or fiberglass. Except for PCB fab houses, of course, so I went and designed a board in Eagle. While I was at it, I played around a bit and added a power distribution system and a bit of "coffin art in copper, tin and solder mask". And yes, I know, this would have probably looked a lot cooler with black solder mask, but the boards were expensive enough as is, and I didn't want to spend another 16 or so Euros for black soldermask before I even know if my concept worked.

The landing gears are also just PCBs designed in eagle. They have footprints for 1206 LEDs and 0805 resistors on them. Oh, and little skulls, of course!

Power distribution

Originally I had planned to put the wiring on the inside of the sandwich, but that didn't work out due to too short battery leads on the ESCs. And I had a hard time unsoldering the original leads. As a matter of fact, I eventually gave up on it after repeatedly failing to remove the leads even with the whole solder joint liquefied. It felt like they were spot welded or glued on there somehow. Anyway, I was afraid to completely destroy the ESC boards, so the original leads stayed on, end of story. Also, I soldered the battery connector directly to the board because I didn't have any beefy cable handy at the time, but I'm not sure it's a good Idea. it looks like it's just waiting to break off in a crash.

Those solder joints don't look too good. I should probably redo them before something bad happens.
Also the screws are way too long and I didn't have lock nuts, but I hope that the generous amount of thread lock I applied after taking the picture will hold everything in place.

Just a cheap Arduino clone. Please move along.
I used a Frsky D8-Something RX with PPM output and a Chinese Arduino pro micro knock off running MultiWii with a MPU6050 sensor board, for now. I'm planning on replacing it with a Chinese CC3D knock off later.

From left to right: Servo/ESC interface board, FrSky RX, MPU6050. And yes, I know the wiring looks like shit.

I used a bit of protoboard to interface the Arduino with the ESCs. This might go into a later version of the frame, along with an I2C Bus, to ease playing around with different kinds of sensors. Oh, and a voltage divider wouldn't hurt either, I guess.

Setup/Test flight

I've begun setting up MultiWii, but so far the copter wont behave itself. I suspect the PID values are way off, but I just don't have the experience to tell exactly what is going on. I've even got it off the ground for a few seconds once, but I don't consider that a successful flight, even though it stayed in one piece, because I couldn't really control it.

The beast folded up. The original frame design leaves a bit more space for zip-ties closer to 

After the crash...

There's no point in pretending that I won't involuntarily destroy this thing rather sooner than later, so I already have a few things planned to do after the first fatal crash:
  • Try again to desolder the original power leads from the ESCs and put custom length leads on them. Don't chicken out prematurely this time
  • Mount the ESCs as close as possible to the motors
  • Put the power distribution side of the board on the inside of the sandwich.
  • Buy the right length screws and lock nuts for the frame
  • Build the Battery/Camera mount from David's design
  • Try shorter and maybe thicker arms
  • Put the LEDs and resistors on the landing gears before mounting them to the copter
  • Redesign the frame board to use the original arrow shape and put signal distribution, a voltage divider and an I2C bus on it. Hell, maybe even a few LED drivers if I feel like it! After all there is one completely unused layer of copper on there (unless you count the skull doodle)
  • Something I don't know yet. Perhaps something dangerously stupid.

Toellner Lab Bench PSU Repair

For quite some time I wanted a "real" bench power supply. The problem is, the good ones are expensive and the cheap Chinese ones are usually crap. So I bought an old Toellner TOE8433 on Ebay.

According to the seller the left instrument was broken and always on full tilt, the cause being "probably just being a bad solder joint". That wasn't it.

The PSU has three outputs: A 3-6V output and two identical 0-30V 0-1A outputs, one of which was broken and put out about 44V, no matter what. The instrument itself, on the other hand, was completely fine. There just wasn't any scale left.

A first try to repair it without schematics didn't work out so good. I found a few broken components but I didn't find the cause of the fault. So I went hunting for schematics on the net, without success. There was one guy selling the schematic I needed but he wanted 10 € for the PDF. That couldn't be any more than a last resort. So I tried contacting Toellner themselves. I knew that was a long shot, but since I was reluctant to give somebody 10 € for a PDF, I had to give it a try.

I wrote a mail explaining that I bought an out of production PSU on the net, that I was on a tight budget and asking nicely for the schematics. I didn't really expect an answer at all, but two hours later I had a mail in my inbox, reading something along the lines of "Dear Sir, enclosed you'll find the files from the years 1984 and 1992. Please recommend us. Best regards...". Attached were complete schematics, BOM and a description of how the circuit worked (which I didn't entirely understand, even after reading it ten times - more than three transistors interacting with each other still make my brain hurt).

With the schematic, repairing the thing was a piece of cake. I soon found out that an internal supply voltage was missing and found the fault in the generation of that voltage, so after fixing that, everything worked perfectly again.

The only question remaining is, how did the previous owners manage to break the thing in the first place? These devices are widely in use in educational workshops, so they can take quite a bit of abuse. Shorted outputs and even hooking up voltages shouldn't be able to damage them. Hooking up mains could do the trick, though, I suppose.

So I want to thank Toellner for supplying me with the schematics, and no, I won't share them. They have been nice to me and I don't want to piss them off by publishing their stuff on the net. I value open source a lot, but these files aren't open source or public domain, and I have to respect that. If you want them, go and ask for yourself.

Tuesday, March 4, 2014

TP-Link based DLNA Music Player

Everybody is building some kind of multimedia stuff with a Raspberry Pi these days. I'm no exception as I also have one connected to my (really shitty Philips) TV, running RaspBMC. But that's not what this post is about, and it's also pretty lame, since there isn't really that much to it.


I also wanted something to connect to my stereo to play music, but I didn't want to use a Pi for that for these reasons:

  • It's rather wasteful. The Pi including a power supply and an SD-Card costs about 50,-€ and I wouldn't even use most of the hardware it comes with.
  • The SD-Card will break eventually. Depending on how much logging I would forget/neglect to disable, rather sooner than later.
  • It doesn't have wifi and I have no ethernet in the dining room where the stereo sits.
  • The audio output of the Pi sucks. Plain and simple. It's about as far from HiFi as Fox News is from being a news network. So I'd have to use an external DAC to get decent audio output from it.
  • It's about as lame as using a Pi for video playback. Perhaps even more so.
Now that we have established that a Raspberry Pi just isn't the right tool for the job, what is? A cheap chinese wifi router seems to be a perfect fit, provided it has enough power to decode MP3s, OGGs, and FLACs (and it has). The only thing missing is the audio output, but that can be added as a USB device, the same way it would have to be done with a RasPi. Also, it obviously has wifi and it's a lot cheaper than a RasPi.


I went for a TP-Link WR841N V7.2 because that's what I had lying around. I also had a Behringer USB DAC collecting dust. If anyone wants to replicate this project, I'd recommend getting another kind of router, since the WR841N doesn't have a USB port. The processor does, however, but I had to solder the D+ and D- wires to some tiny ass resistors on the board and generate the +5V from the routers 9V supply voltage myself. Any version more recent than 7.2 of the router doesn't even have traces for the data pins and the processor comes in a QFN package, so you'd have to cut away part of the processor package and solder the data lines directly to the processor pins. Some people have done that, but I'm just not that sick. I might be a cheap bastard, but putting a Dremel to a QFN package is where I draw the line.

Somewhere left of the processor are R601 and R602 where D+ and D- surface
Other than adding those data lines the hardware side of this build isn't too interesting, so I will spare you the details.

Botched up a 7805 voltage regulator and a few caps on a piece of perfboard

Since these cheap routers only have a few megs of flash, they can only run special embedded Linux distributions like OpenWRT, which is what I am using. But even with that, there was no way of fitting all the needed packages in there, so I added a flashdrive to deal with that. Since the processor only has one USB port a USB hub was also needed. That was actually the only thing I had to buy for this project.

The OpenWRT project provides lots of documentation about building minimal images and putting its root filesystem on an external storage, so I've done just that. With plenty of storage to install the needed packages, it's for the hard part: Building the software.

GStreamer and gmrender-resurrect

There are quite a lot of projects out there that achieve a similar goal, but it seems that all of them use mpd for streaming. Frankly, I don't like mpd very much, mainly because all clients I've seen so far lack in usability. Also, it seems to me that while it even supports gapless playback, it's unlikely to be adopted by manufacturers (if it were, there would be a few commercially available players by now). DLNA on the other hand looks like it's quickly becoming a de-facto industry standard as it already has been adopted by some very reputable HiFi manufacturers like Linn, Marantz, Denon and others.

For DLNA-Support there is a project based on the gstreamer framework, called gmrender-resurrect, and also an OpenWRT port of it. OpenWRT packages can be built using either the OpenWRT SDK or the OpenWRT buildroot. If you can live with the hopelessly outdated gstreamer packages provided by OpenWRT, it's just a matter of building the gmrender-resurrect package and you're done. I couldn't, however, so I built packages for the current version of gstreamer, too, which took me forever.

I'd like to point out that no real coding or porting work was done on my part. I just updated and fixed a few Makefiles to make it build. All the real work was done by other people.

The finished thing: Router, USB-Hub, Flashdrive, USB-DAC
All patches needed to compile gmrender-resurrect and gstreamer (including plugins) are available on my github.

What it can do

These little routers are really amazing. With this I am now able to play music from any DLNA source (fileserver, phone, tablet, laptop, you name it...) to the stereo in my dining room. I'm using BubbleUPNP on Android as control point and it really works great! Also, it still acts as a WDS-router.

Where to go from here

There's a lot more that can be done, given that all the LEDs and buttons in the router are actually GPIOs. So adding a LCD and putting it in a nice enclosure (like an old CD-Player) with Play/Pause/Skip-buttons should be pretty easy.

Sunday, July 14, 2013


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.


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
SMPS cons:
  • size
  • price
Cap Dropper pros:
  • size
  • price
Cap Dropper cons:
  • not isolated from mains
  • inefficiency
Looking at the pros and cons it's obvious why most commercial products have cap droppers. They are dirt cheap to produce and the producer or vendor really doesn't give a crap about their efficiency. After all it's your power that's wasted, not theirs. Mains isolation is irrelevant, since the whole circuit is safely tucked away inside the enclosure.

To me as a hobbyist priorities are a little different. Efficiency totally outweighs initial cost. What good is a power supply that takes only 50 cents to build if it eats up 10 € in electricity a year. Not to mention mains isolation. I've known myself for quite some time now and I know that (probably like everyone else) with growing routine and confidence I tend to get sloppy. And that's when I get hurt or accidentally blow up my gear. So no cap dropper for me.

An SMPS on the other hand would have to be reasonably cheap and, even more importantly, small. Given the simplicity of my overall design and the overwhelming choice in available SMPS, choosing a suitable one proved to be the most challenging part of this project.
These are really nice. But also very expensive

There are SMPS-Modules that would be ideal for this project, but unfortunately those cost about 30 € a piece, which is about three times of what I intended to be the cost of a completed socket, so those are out.

Then there are those really slim iPhone chargers, but those also cost about 20 € (used to be 30 a few months ago) and my religion forbids the purchase of apple products anyway, so those are out, too. But then there are those fake Apple lookalikes, which cost only 2-4 €. Couldn't I just use those? I decided to give it a try and ordered a bunch from Ebay or Amazon or so. Of the six I got one blew up right away, so I sent them all back the same day.

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

After ordering a few more similar, but slightly more expensive types, cutting them open and discussing the pictures on the net I finally found this one:

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.


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 boardsI 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.


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.


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.

Thursday, July 11, 2013

Coming up...

There wasn't a lot of time in the last few months to write new posts, so there aren't any.

But there was time to finish some long overdue projects, move some other ones up the queue,  and think up some new ones. So here is the list:

Finished Projects:
  • RC mains sockets and power strips (RFM12B+AVR controlled, of course)
  • RC Doorbuzzer (RFM12B+AVR controlled, too)
  • Repair of an old, built like a tank, lab bench power supply
  • Rewrite of my wireless sensor and home automation network code

Almost finished:
  • ESR-Meter (without RFM12B, but still with an Atmega)
  • Solar powered sensor node hacked from a cheap garden light

Still need some work:
  • Wall switches to go with the mains sockets
  • Hack annoying toddler toys so I can mute them remotely and build some new ones
  • Long range garage door remote
  • Build a "Lab-Node" with voltage dividers and optocouplers for long term measurements
  • Build/Buy an isolation transformer
  • Play around with non isolated mains power supplies
  • Build a dummy load
  • Repair and and complete re-cap of an old NAD 3020 amp
  • Build a little robot to creep into an old sewage pipe to check it's condition
  • Build a bathroom if the condition of said pipe turns out to be OK (I'm a bit scared of this one)
  • Rewrite of the powermeter code
  • ???
  • Profit

Friday, December 14, 2012

RUWIDO Merlin IR-USB-HID Receiver

There are these very neat IR Keyboards for sale at a German surplus retailer. At only one Euro they are a steal, but the reason they are this cheap is that they come without a receiver. So to the average person seeking a nice keyboard for their living room media center PC they are useless.

I bought one a few months back when they were still 2,95 € and tried to get it to work with LIRC, but had little luck. It kind of worked in raw mode but the key repeat rate was insane and also this wasn't what I was after: I didn't want to use it as a remote control with LIRC, but as a regular HID keyboard instead.

These keyboards were discussed on quite a few (mostly German) forums on the web, and someone even came up with a decoder for the IR protocol, but so far nobody seems to have written something that would act as a USB HID keyboard. So I had to do it myself.

I did it by simply combining the IR decoder with the V-USB project, which implements a USB HID driver on any old AVR device (not those expensive "U" types, which come with hardware USB).

It should run on any ATMega44/48/168/328 and even on the ATMega8. Which is quite nice because there is a type of USB ISP programmer called USBASP, which is also based on V-USB (I think), and those are available on Ebay for about 3,- €.

So all that's left to do is to get one of those and solder a IR-receiver to it, so I can get it off the breadboard.
The schematic is really simple. And the best thing is, the USBASP already contains everything everything except the TSOP1756 !
As usual, the code can be found in my Github-repository.

Saturday, November 24, 2012

Debugging the garage door remote

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.