Building a wireless sensor hub (part iii)

I rebuilt my little circuit board, and all now seems OK. Now I just need to test it. So I reattached it to the router, and wanted to check that I could communicate with it via the (second) serial port that it is connected to, called /dev/tts/1

To check the serial line configuration, I needed stty, which is not installed in the BusyBox implementation supplied with OpenWRT, so I needed to install the standalone version. It’s in the coreutils package, which has lots of things in it that I don’t need, and is frankly huge. The solution to this is to extract just the stty program from the package, and install that manually. This is done as follows:

  1. Download coreutils from the repository manually (e.g. wget http://downloads.openwrt.org/kamikaze/8.09.2/brcm-2.4/packages/coreutils_6.9-1_mipsel.ipk for the WRT54GL). Make sure you are using the right architecture/platform.
  2. Rename the file so that it ends in .tar.gz
  3. Uncompress the file using tar/gzip
  4. This will reveal a data.tar.gz (and other files). Uncompress this file, unpacking the usr directory.
  5. Copy usr/bin/stty to /usr/bin on the WRT54GL.

Building a wireless sensor hub (part ii)

After well over a year sat on my ToDo list, I’ve finally got around to progressing my plan to turn a spare WRT54GL router into a wireless sensor hub. I decided that I didn’t want to stack interfaces, adding RS232 interfaces, then adding RS232 to 1-Wire converters to them, so after a quick check on my likely needs, I decided to instead simply add a single 1-wire interface directly to the router.

That will allow me to put the router out in the garage, where it can attach itself to the main house wireless network, and extended that to it’s wired ethernet ports, to which I can easily attach other devices in the future. In addition, I can add sensors and actuators to the routers newly added 1-wire network. Small programs on the router can read those sensors, and publish their readings to the MQTT server running on my home server back in the house, making them generally available. Similarly, messages published to that MQTT server can be read by programs on the router, and turned into commands to the 1-wire actuators, allowing the automated control of external equipment.

The Linksys WRT54GL has a pair of 3.3v TTL UARTS on the motherboard, which are not externalised. One of these is used by the router during start up, and can only be used after that startup has completed, but the other is completely unused. Both are exposed as pinouts on an unimplemented header (JP1) on the router PCB, as follows:

Pin 1:  3.3V         Pin 2:  3.3V
Pin 3:  Tx (ttyS1)   Pin 4:  Tx (ttyS0)
Pin 5:  Rx (ttyS1)   Pin 6:  Rx (ttyS0)
Pin 7:  NC           Pin 8:  NC
Pin 9:  GND          Pin 10: GND

Note that neither of the serial ports support hardware flow control (it’s not pinned out on JP1 on the Linksys PCB), so you need to use software flow control when connecting to these ports.

By attaching a DS2480B (Serial to 1-Wire Line Driver) the unused serial port can be used to control the 1-wire network. However, the DS2480B expects 5v TTL levels, not the 3.3v produced by the router, so some level conversion is required. I also wished to protect the router in the event of a lightning strike to the (potentially) long 1-wire cable. Together these requirements (and wanting to keep the router looking as normal as possible) meant that I needed to create some electronics – something I’ve not done in a while.

In the end I created a simple circuit to convert the levels between the 3.3v running in the router, and the 5v required by the 1-wire network. I powered the circuit from a combination of the 12v supply to the router, and the routers internal 3.3v power rail. The circuit I came up with takes inputs on the left of (top to bottom) 12v, 3.3v (Pin1 JP1), UART Rx (Pin5 JP1), UART Tx (Pin3 JP1) and GND (Pin9 JP1). The outputs on the right (top to bottom) are 12v, 5v, 1-wire, and GND, and will be externalised via a socket mounted on the case.

I then tried to lay it out on stripboard, using first VeeCAD and then Eagle (electronic design/layout systems) but in the end, for something this simple, it was proving more difficult to configure the tools than to just do the job manually. So I ended up with a traditional series of graph paper designs, finally settling on the following approximate layout:

After quite a lot of (very careful) soldering, this resulted in the following circuit, seen waiting to be attached to the router, and to some 1-wire devices. Note the use of a breakout board to convert the DS2480B from SOIC8 to something more compatible with breadboard & stripboard. The UK 50pence piece provides scale:

Sadly however, I wasn’t careful enough with my soldering. I managed to put the voltage regulator in back to front, swapping the input and output terminals. Worse, I didn’t notice when I checked the board. So when I connected it up, the resulting unexpected voltages let loose through the circuit have comprehensively let the magic smoke out of the DS2480B, which has in turn (I suspect) comprehensively cooked capacitor C3, and resistor R1. The good news is that the level converter MOSFETs that I installed to convert between 3.3v and 5v were man enough to cope with the 15v rampaging around my circuit, and saved the routers electronics from any problems.

So now I need to replace the DS2480B, the voltage regulator, C3 and R1. I’ll swap out the zener at the same time, “just in case”. What a pain.

Upgraded study music system

Like a lot of people, I sometimes work from home. In general it’s a day or two a week, and I’m lucky enough to have a small (2m x 2m) study dedicated to that. And since it’s the one room in the house that is genuinely “mine” and no-one else’s, it’s something of a refuge as well as a place of work.

My need for music while I work has meant that over the years I’ve moved from a pair of earphones plugged into the laptop, to a Joggler acting as a DIY Squeezebox Touch. This fed a pair of powered computer speakers from its headphone socket, which produced some basic noise, but wasn’t exactly high fidelity.

For some time now I’ve been watching the discussions around Gainclone and T-class amplifiers on the internet with interest, and this month I decided to spend some of my “toy fund” on improving my study music system. In the end, I was somewhat limited by the Joggler (which I wanted to keep) in my choice of improvements, as the only analogue audio output available is a low-quality headphone output. Which meant I needed to move into the digital domain, and flow my music over the USB output into an offboard DAC and amplifier.

I looked at various options (mostly involving second-hand DACs) but then I discovered this review of the Topping TP30, which is a combination T-class amplifier and USB DAC in a conveniently small package. Further investigation led me to this further (and more detailed) review.

At this point I was pretty much convinced, especially as I was able to get one delivered from a UK Ebay supplier for only £63. My only concern was that as the output is only 10watts RMS per channel into 8 ohm loads, the speakers need to be reasonably efficient, even in as small a room as mine.


Fortunately I had an old pair of speakers from a Sony micro hifi, which looked like they might be good candidates – and were helpfully only 6 ohm loads too.

So, what does it sound like?

Surprisingly good. It’s no match for my old Audiolab 8000A and KEF reference speakers in the lounge, but it’s a massive step up from the old set of 2.1 powered speakers that I was using. It produces a very pleasant sound, tending towards the lean and analytical – which is the sound I prefer anyway. With a good recording, it can be quite revealing, and with the right track it happily grabs the beat and rocks along nicely. Volume levels are (as Rolls Royce would say) “adequate”; half volume is as much as I would ever want in this size room. My only criticism would be that it doesn’t have the reserves of power to provide sudden big slams of bass; but then I wasn’t expecting that it would.

What’s interesting to me from having done this is the minimal cost of creating a very impressive sounding system; the TP30 was £63 delivered. Speakers like mine are about £25 on Ebay. Jogglers are £50 on Ebay. Admittedly I already had the NAS with the Squeezeserver software & music store … but many people have a spare computer these days, or you could equally well feed the amplifier and speakers directly from a laptop. Hard to imagine a better value-for-money set up for a student. It’s even relatively portable.

Yellow light of death

My PS3 is one of the original 60GB launch systems; as such it’s getting a bit long in the tooth. But it still gets used every day for either streaming my movies, or playing the kids games. Or both.

Until Tuesday evening, when it suddenly beeped three times, and turned itself off, with the power light flashing red. Trying to turn it back on again didn’t work, and neither did power cycling it. At which point I did some research, and discovered that this is known as the “Yellow Light Of Death”, or YLOD for short. It’s the way the PS3 indicates a catch-all hardware problem, and basically means the console is dead, and needs to be sent back to Sony for repair

Which would be OK, but since mine is well out of warranty we’re talking a significant bill to repair it, and in all likelihood I wouldn’t get back my rather rare launch system, with all the additional hardware that helps with backwards compatibility for PS2 titles. Not good.

It transpires that early PS3 systems like mine used 90nm Cell B/E processors, which were very power-hungry hot-running processors, and Sony didn’t do a very good job mounting the heatsinks in the early systems. This resulted in the systems running hot, and eventually causing dry solder joints to form between the CPU & GPU and the motherboard, resulting in these YLOD hardware failures. These problems are much less common on the newer PS3 Slims, which user newer 45nm Cell B/E processors that generate much less heat (200w total system consumption, compared to nearly 400w in mine).

Fortunately some enterprising people have managed to find a way of fixing this by making their own hot-air reflow solder station out of a standard hot air paint stripper, and have been able to re-flow-solder all the surface-mounted components around the CPU/GPU, fixing the dry solder joints and restoring their PS3s to life. And better yet they’ve posted videos of how to do it, so others can repeat their success.

So I did.

Going slowly it took me about 3 hours to strip the PS3 down to it’s bare motherboard, heat up the components so their soldered connections re-flowed and remade themselves, and then to rebuild it afterwards. I must admit that I wasn’t expecting it to work – but then again I had nothing to lose beyond a spare evening and £5 of thermal compound to remount the heatsinks with.

But the result is that the PS3 is now working again, and in practice, probably better than it has for a long time; by resolving the poorly mounted heatsinks and using a better quality of thermal compound the fan can now run much more slowly, and still provide better cooling. So it’s much quieter while streaming movies. Which is perfect.

Except I rather fancy getting a second generation Apple TV and hacking XBMC onto it to produce a really smart media hub, and fixing the PS3 has just made justifying the expenditure on that a lot harder!

Server drive failure

In other news, I received a barrage of emails from my home server the other day, each complaining about a degraded raid array. A swift check through the emails indicates that every array on the machine had been degraded, and a little more investigation leads to the simple conclusion that one of the hard drives has completely failed.

So far I’ve not had time to check if this is a failure of the drive, the controller, or perhaps even just a cable coming loose, but it’s nice to see the server continuing to function completely normally despite this failure. Lots of kudos for the software raid functionality in Linux.

My job for tomorrow morning is to find out what has actually failed, replace it, and then reinstate the degraded raid arrays. One thing I’ll look into is getting SMART monitoring of the hard drives enabled. Currently it isn’t, and it would have been nice to have had some advance warning of this so I could have had the new drive ordered and waiting.

Still, hopefully the whole thing is not more than a couple of hours work.

Update: Initially it seemed like a cabling problem; simply replugging all the drives seemed to resolve the problem. However, putting it all back together again caused it to stop working again. After quite a lot of swapping of cables, and then finally wiggling of cables, it became clear that the problem was the drive after all. Ultimately it looks like the circuit-board attached to the drive has failed. Flexing the cables causes a little bit of movement of the circuit-board, which I suspect over time has caused it to fail.

A new drive seems to have completely resolved the problem. Having got that installed, it took about 5 minutes to partition it up, another 5 minutes to add the partitions to the raid sets, and about 4 hours for the linux software raid system to rebuild the raid sets.

And all is now working perfectly again.

Joggler Squeezeboxes (part iv)

Since finally getting the BBC iPlayer listen again streams to work by switching over to the AAC streams rather than the WMA streams, it appears that the BBC have broken the AAC streams at their end. I’ve (temporarily) switched back over the to WMA versions, which work, but that I (still!) cannot seek within.

Sometimes it really does feel like life is a constant case of 2 steps forward and 1 step back…

Bitten by a Viper

In this case, the viper in question is an old industrial control computer, based on an Intel PXA255 processor, in PC104 form factor, running a minimal linux. It was originally manufactured by Arcom Ltd, who have in the intervening years been taken over by Eurotech S.p.A. and comes with a nice complement of default communications options.

Mine is a standard “full-fat” Viper board, with no additional expansion cards, but mounted in an industrial enclosure with an integral UPS battery-backup. Sadly it’s been lying around gathering dust in my study for about the last 5 years, and as part of a recent attempt to tidy up some of my clutter I decided I either needed to make use of it, or get rid of it.

A little searching unearthed the power supply, and then, according to the little red LED on the back panel, we had life.

The first problem was how to talk to it. This is a true industrial device – no screen or keyboard. The options are either to telnet or ssh in over the network connection, or use an ASCII terminal over a serial connection. And therein lay the first problem; it didn’t connect to my network as I was expecting, leaving only the serial option open to me. But as I’m almost exclusively laptop-based these days, finding a machine with a serial port, and then a serial cable to link it to the Viper, took quite some effort.

But having done so, and set up minicom with the correct serial port parameters (helpfully documented in the Viper manuals) I was able to login to the Viper, at which point a little debugging of the network stack revealed the issue – at some point I’d defined the Viper with a static IP address, on a different subnet to my current home network.

A few quick edits to return it to DHCP operation, and a little configuration work on my home servers dnsmasq configuration returned the Viper to my home network, at a readily accessible IP address, allowing me to ssh in again.

At this point, having proved that the system is working again, I now need to decide what to do with it; and in this case, I’m going to use it as part of my plan to implement a set of DIY ambient orbs, as I mentioned back in this post. The Viper happens to consume only 9w while network connected, and has a built-in I2C interface, which can connect to BlinkM LED’s which I can mount in my B&Q Cubo housings. This will allow me to control the colour of the orbs from a program running on the Viper.

Better than that though, I can then install an MQTT client on the Viper, allowing my Viper program to subscribe to a topic on my home servers MQTT micro-broker. This will allow me to have the Viper change the colours of the orbs in response to messages published to the broker on my home server. At that point I can trivially integrate any sort of external input to the orbs just by administering my home server, & without needing to make further updates to the Viper.

So all I need to do now is to get the AEL development kit (cross-compiler etc) set up so I can write some code for the Viper, and then buy some BlinkM LEDs. Which sounds simple, but unfortunately the AEL development kit hasn’t been updated for some 4 years now, and isn’t keen on installing on my latest and greatest Ubuntu 10.10 development machine. I’ve put some calls out to colleagues who have also had experience with these Arcom Vipers, but so far no joy. Next step will be to see if Eurotech can provide a little help – after all, I suspect the original Arcom engineers will mostly still be working there. I guess the worst case will be to set up a *really* old Linux system in a virtual machine, and install the AEL development kit on that instead.

Wacom Bamboo Pen tablet under Ubuntu 10.10

I bought one of these USB graphics tablets for my daughter for Christmas. It turns out that it’s not quite plug and play on her Ubuntu-powered netbook – well, not until a few extra commands have been entered in a terminal:

sudo add-apt-repository ppa:doctormo/wacom-plus
sudo apt-get update
sudo apt-get install wacom-dkms

After this the tablet is hot-pluggable, and acts (at least initially) as another mouse-like device. I’ve yet to try it with tablet-aware applications like Inkscape or The Gimp, both of which will need a little additional configuration to recognise and make use of the advanced features of the tablet (pressure sensitivity etc) but it’s looking good so far.

A little playing with the configuration of The Gimp has proved that the tablet works perfectly; we now have detection of pressure working, allowing the rendering of variable stroke-width depending on the pressure applied to the pen. All in all I’m very impressed – having had the opportunity to experiment a little, I’m now wondering if I could use one to create free-hand drawings in presentations, which I suspect could be very effective.

When is a USB charger *not* a USB charger?

Answer: When you want to charge an original PS3 SixAxis controller.

I’ve had an original first-release PS3 since 2007, and it’s a fine piece of kit. Given that it was designed many years ago, it’s lasting extremely well. In my case I mostly use it for streaming my video collection from my (DNLA-enabled) home server, where I store my digitised DVD collection, to the main TV, which is attached to the PS3 by HDMI.

My only problem with this arrangement is that I’ll often find that when I want to use the PS3, the rechargeable wireless controller is flat, thanks to extended movie-watching by my kids. The only way to recharge the controller is to plug it into the USB port of the running PS3, which charges it up again reasonably quickly.

So I decided it would be worth spending the £5 or so to get a mains-powered USB-charger, so the controller can be left permanently on charge when not in use, so it’s always fully charged when needed. A fine idea.

Except in practice my PS3 controller fails to charge when plugged into the mains charger. It charges when connected to the PS3. Or my laptop. But it also fails to charge on my old mains-powered Blackberry USB charger. Something is definitely odd.

There are now extensive specifications for how you must go about powering (and especially charging) devices via USB, but back when the PS3 was designed (2003-2005) this was something of a new and grey area, so it’s not at all clear that Sony would be following the current specifications. And so it transpires.

Unlike almost every other device out there, which either just draws current from the USB port without asking, or follows the specifications and passively checks for fixed voltages on the USB data lines, my PS3 controller will only start charging after it has been both connected to, and enumerated by, a host USB port.

What this means in practice is that my PS3 controller can only charge from a real USB port on a computer that is capable of intelligently communicating with it. Modern mains-powered USB chargers which describe their capabilities according to the USB specifications using voltages and simple resistances between the data lines will never persuade it to start charging. Which is very annoying.

So, the question is, will newer PS3 controllers follow the new USB specifications, or will they also require enumeration before they can be charged? I have a suspicion that the newer controllers will follow the new USB charging specifications; this would account for the number of very mixed reviews of “mains powered PS3 controller docking stations” on places like Amazon. Anyone with an old original controller like mine, and a new docking station designed to the USB standard will find it doesn’t work. Whereas people with newer controllers will see it work perfectly, and not understand the poor reviews from the owners of original controllers.

I’ll find out soon enough, as I’ve ordered myself a Dualshock controller for Christmas to allow my kids and I to play some games head to head.

If that follows the recent USB specifications then I think my low-tech solution will be to leave the original controller connected to the PS3 USB port, and predominantly use the new controller. The original will charge whenever we use the PS3, and the new one can be plugged into the mains-powered USB charger and charge when the PS3 is switched off, and so also always be ready for use.

If the new controllers do not follow the new USB specifications then there is a solution to the problem – build a charging circuit that is capable of supplying power from the mains that can follow enough of the USB specifications to properly enumerate the controller. Fortunately, someone has already done all the hard work for a single controller, and published the information. I’ll need to modify it to support (at least) two controllers, which will need some simple circuit changes to add more USB ports, and some more extensive changes to the microcode to provide support for them.

Since I’ve not played with micro-controllers yet, I’m going to hold off from attempting this until I definitely know I need it!

My new DualShock3 controller arrived today. It also refuses to charge on a standards-compliant USB charger. Options are to build something to resolve it, as detailed earlier, or pay the outrageous markup that Sony demand for their charger, which can enumerate the controller. I suspect I won’t be able to build a charger for less than the cost of Sonys commercial charger, so I may as well just go and buy it. But I do feel cheated by this. Sony ought to have fixed their controllers by now.

Joggler Squeezeboxes (part iii)

After quite a lot more experimentation, I’ve completely failed to get seeking within iPlayers WMA-based “listen again” streams to work. Although I’ve yet to prove it definitively, it seems that the Squeezebox Server code doesn’t support seeking within such a stream – flagging my transcoding command line as being capable of seeking, and then using the GUI to attempt to actually seek in the stream doesn’t result in the Squeezebox Server passing the seek location to my transcoding command.

More research into WMA streaming seems to indicate that passing the seek command from a client to the server is not trivial on non-Windows platforms, and appears to be based on a collection of proprietary and less-than-well-documented dataflows.

So my (completely unsubstantiated) suspicion is that Squeezebox Server running on a non-Windows platform (like mine) doesn’t support seeking within WMA streams.

However, there is always another way. And in this case, it transpires that not only do the BBC stream their iPlayer radio streams as WMA, but also as AAC, which is a codec that is significantly better documented and supported on Linux. So by simply changing the preferences within the iPlayer plug-in it’s possible to switch to using the AAC streams, which are supported by both my Jogglers and my Classic player. Better yet, it’s possible to also seek within the “listen-again” versions of those streams. In short, it all now “just works”.

Although I’m now using AAC streams for iPlayer access, the work that I put into getting WMA streaming to work with the Jogglers hasn’t been wasted, as there are other Internet Radio stations out there that do only broadcast in WMA, and this transcoding solution allows me to access them too.

And finally, unlike the Jogglers build-in Internet Radio application, the Squeezeplay application buffers enough content (irrespective of codec) to completely avoid skipping and audio drop-outs. Perfect!