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.

Objective

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.

Hardware

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
OpenWRT

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

Frankensockets

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

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

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.

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.

Friday, November 23, 2012

Building Arduino Sketches without the IDE

I really love the Arduino, because after all it was what started all this.

The one thing I don't like is the IDE that comes with it. It's not the IDE's fault, It's just that I'm a console guy and I don't really like IDEs in general (and yes, I've seen others and I think this one is not particularly good). Luckily there are ways around it, like Makefiles that automatically include all the needed libraries and even upload the sketch to the board. There are several of these out there, and I went with this one which is a slightly modified version of this one. The Makefile is pretty good as is, but I added a few minor changes:

  1. The Makefile can search for libraries in ~/sketchbook/libraries, but instead of the ~/sketchbook folder I use ~/src/arduino, so I just replaced that.
  2. It reads the boards.txt file in the Arduino installation directory but I have my own boards.txt in ~/src/arduino, where I added my own boards, so I changed that path, too.
  3. The setup howto suggests that you symlink the file to your sketch-directories, but if you do that, you'd still have to set the environment variable $BOARD to the right type, which I found a bit tedious. So instead of symlink it, I create a new Makefile in each sketch folder that contains only two lines: The first one sets $BOARD to the board type that sketch uses, and the other just includes the original Makefile.
The result is a very tidy build system with no redundancies whatsoever.

As usual everything can be downloaded in my github repository:


Sunday, November 11, 2012

Smartmeter III - blinking LEDs

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