Thursday 12 December 2013

Arduino controlled outdoor motion sensing xmas lights

*Edited 20-12-2013 to update Arduino code and de
 I finally managed to get on with my next Arduino project, and as its Christmas, why not do something with Christmas lights, an arduino, some PIR sensors and relay board. My idea was to use some little xmas trees I bought a few years earlier and do something a little smarter with them. Out of the box they are a chain of 7 1-foot high trees with various lightbulbs on them all powered from an AC power supply (low voltage). Nothing amazing, they didn't even flash originally, so the plan was to do this:
* Disconnect each tree, so that they could be controlled independantly
* Attach a PIR (Passive Infra-Red [motion sensor]) to each tree
* When the tree senses movement, light it up
* Run in a sequence to flash all the trees

So, first job, was to cut the tree cables down so that I had a single common wire running to each, I could then wire a cable to each one to run as the 'trigger' cable. The small trees look like this:

So I cut each of the cables and remade them with new cable runs, tested them and I could light up each tree individually.
Next job was to start with the PIR sensors. These are ones I picked up from eBay and were only around 1-2 uk pounds each, so pretty cheap really.

As you can see there are 3 pins for connection, +ve (5 volts), ground and trigger. When powered and operating they will send high the trigger to +ve to indicate the unit has sensed motion. The sensors also had two pot's on them to control the TX time and the distance control. I didn't get a lot of difference playing with either to be honest but that didn't matter, the defaults seemed to do the trick. I powered them up as a test and found that movement in front of them triggered the output for around a second then when motion stopped it removed the trigger. All looked good, but I had to waterproof them. First attempt and the cheap solution was to wrap them in freezer bags, not sure what this did to the PIR sensitivity I covered on and re-tested, no real difference to the triggering so this was ideal. I wrapped each one in the bags and tied them shut with freezer ties and wound the bag around so they were pretty snug in there.

There you can see the bagged up PIR, and also it nestling inside the tree, I opted to put them low down and try to bury them inside the tree a little, this hid them as much as I could from view and let me put the other tree branches up over them so the general view wasn't the rather unsightly bag and PIR sensor itself.
Next up, to control them I needed a relay board. This is because I was going to be controlling AC and an unknown current (Yes, I could have tested, but to be honest I knew it would be within the ratings of the relays, but way too high for an Arduino output, and I wanted isolation). So again I turned to eBay and found relay boards that you could get for around 5 ukp, and these were optically isolated too, so even better keeping the Arduino isolated and safe so it wasn't going to stress the outputs. Below is an image of the relay board as I was starting to wire it up.

The pins along the left of the board were labelled as ground, 1-8 and +ve. The relays are triggered by 0/LOW from the Arduino, initially I wired the relays up to be powered by the Arduino +5v rails and used the digital outputs as a test. This all appeared to work correctly, setting the digital pins to OUTPUT and when driven LOW the relay clicked and engaged. The relays are single-pole changeover so the outputs can be triggered on either throw of the relay. I wanted to use mine when the relay was engaged/energised the output to the tree would be on. The only thing that started to appear was as I did some test Arduino sketches that sometimes everything would hang and just stop dead, the arduino wouldn't continue its loop and the relays would be left on whatever sequence they were in. After some playing around I made an assumption. The 5v draw from the relays was proving too much, or too electrically noisy to be driven from the Arduino itself, so I separated it. I got another 5v supply, connected its ground to the GROUND on the relay board, and the +5v to the +ve on the relay board. I had to also tie the +ve to the Arduino 5v pin to keep it common but that worked great, the Arduino now only gave signals to the relay board and the other 5v supply powered the relay board itself.

Next was to start wiring the Arduino Uno up. I have the digital pins 0-13 available, so since I need 7 outputs I chose pins 6-12. Setting them in the code to OUTPUT pins and setting them to HIGH initally (Remember the relay board uses LOW to trigger!)
As you can see, I used a small breadboard to use as breakouts for a few of the connections, this was just to make the links to the tree lights themselves and common 5v rails easier to wire up.
For input I used the 5 analogue input ports but used them in a digital way, as all I was detecting was +ve or not that was simple. Referring to them in the code as pins 14-18 as they were being used as digital input pins.
Also you'll probably notice a tri-colour LED on the breadboard, another initial idea (since I already had 5 of them) was to put these on top of each tree and let it cycle through colours, in the end I gave up on that idea as I needed more output pins, and more importantly a lot more wires and the wire I was using already looked a little untidy/unsightly, so I gave up on that idea.
The code for the Arduino too quite a few attempts to get it right, mainly because I needed a few different sequences and logic to make it work right. The completed code is shown below, but it's not very neat, any modifications to it would be welcome! But the general program works as expected, so it will sit in a sequence flashing each tree lights in a sequence until one of the PIRs sense movement. When they do, they will turn off all trees except the ones sensing movement, so you can 'walk' up past the trees and they will light sequencially, you can also jump to particular trees and they will light in any order too!
The biggest bug/drawback that I've found is the PIR sensing component. since the PIRs aren't very precise sometimes they detect movement when none happens (I'm guessing this is because they're outside and picking up all sorts of stray IR activity or heat signatures), but also their field of vision is difficult to control, so knowing where they will detect movement is a bit of trial and error. But they generally work!

   

Merry Christmas everyone!
Arduino code below:
 (Moved code to pastebin) : pastebin.com/FJ2qP74m

Problems: 20-12-2013
I hit a few problems after setting it all up and letting it run a while. The biggest problem I'm having is the Arduino locking up and just stopping where it is in the code. The result are the lights getting stuck at whatever point they were at. I've tried to work around this in various ways. Firstly I thought it was the PSU I was using for the Arduino as it was a USB phone charger and I was feeding the Arduino over the USB port. I've swapped this to use a 9v PSU into the barrel jack so its got a 'proper' power supply and this made no immediate difference. I suspect this is due to EMI (Electro-magnetic-interference) from the relays and switching the low-voltage AC for the lights, so trying to re-route cables and move the relays away from the Arduino has helped but not enough. Finally I've put in a watchdog timer/code into my software so that at least if the Arduino locks up, it'll reboot itself and reset the sequence. I've not managed to figure this out much further other than it being an utter annoyance as its when I want to show the system off to somebody! I still suspect its due to EMI and need to try and protect things a little better, perhaps I've not isolated enough of the relay board from the Arduino output pins, but open to suggestions please folks!

Tuesday 27 August 2013

Regional DAB switch-off and digital radio in the UK

"@RadioToday Digital Radio News: Regional DAB turned off in West Midlands"

Well, is this a good thing or a bad thing? I was puzzling over this whole setup for quite a while, as I'm very disillusioned already over the state of DAB and digital radio in the UK. Firstly I suppose a little bit of background to it. We all know that in certain areas the use of FM frequencies is tight, there are far too many for the old analogue spectrum to handle and since each station has to keep a 'gap' between the other (to avoid interference overlap, etc) then you start to run out of frequencies available for everyone to use. As an example, take a drive around London, and just seek through the radio frequencies, you'll find the radio stops every .3 or .4 steps and finds a new station. That's the problem. So in very lucrative areas there are no further frequencies available. The big radio firms in the UK are also wanting to expand their empire and go national, as the BBC has been able to do easily for many years, and so the advent of DAB/digital radio offered such an option.

Regional multiplexes of DAB transmitters could be linked and provide the option for a radio station to exist nationally quite easily, and with the ability to fit many stations within a single mux it also allowed a much larger number of channels to become available.

It sounded like the perfect answer to the UK radio industry. Except that the operation of those DAB transmitters/mux's would be auctioned off to the highest bidder, which therefore meant that only the biggest of big boys in the radio industry could get to operate the MUX's. So that did happen, and the big groups such as MXR (A combination of Chrysalis, GMG, Capital and Choice. There were a large number of commercial big boys all going for DAB and getting the infrastructure in and operational.

A good explanation of DAB and what the regional turn-off of DAB means is written here " @RadioToday: Digital Radio News: Regional DAB turned off in West Midlands radiotoday.co/14X9Lz5 "

However I'm still not convinced the current model of DAB and digital radio in the UK is a good thing.

I have to say, I have a vested interest, I'm with the 'little guys'. The smaller independant radio companies (Very very few) and the even more minority group, community radio. To be honest, my vested interest is with the community stations I work with, and on many occasions I'm asked "When can we go to digital/DAB". And unfortunately my answer is always the same. Only when we can make a huge profit and do some serious cap-ex.

I have questioned this time and time again, and the answer is always the same. You speak to the regulator (Ofcom) and advise on the DAB/Digital licensing, which in itself isn't a huge expense (And isn't huge for Community stations on FM/AM either). However you then have to arrange to actually transmit on a digital MUX (Multiplex). And that you do by contacting the local regional mux operator (Generally Arquiva, Capital, Chrysalis, etc), and that is where the problem comes in. They're a commercial company, working to a profit and making profit. So you get quoted between 4 and 5 figure sums and then you have to go into rental charges and more. Terrible when its for a community station that barely can pay for the building it runs from, never mind paying staff, expenses, kit, etc. To give it contrast, if you setup a community station to broadcast on FM you can use your own transmitter, your own transmitter site and equipment, making yourself totally self-contained and purchasing the transmission kit yourself. It could be as low as a 3 figure sum if you use the basic kit to get up and running. That plus the relevant fees to regulatory bodies, etc, and you're running in a few 1,000's which is generally within reach.

So my view on DAB and digital radio in the UK is still a very pessimistic one. To get full scale take-up of it by the public, it will need you to be able to get EVERYTHING you do now on analogue radio. At the moment this just isn't possible, and doesn't even look remotely feasible in the medium term. So something has to happen.

I'd love to hear what you think about this, whether you're in the radio industry, part of the licensing or just generally a radio listener, please leave comments and thoughts!

 

Sunday 7 July 2013

Community Radio

 Well,

It's about time I wrote this one up as it's been in use for a good few months now and I've not mentioned it. As some of you may be aware I like to get involved with Community Radio Stations in the UK. These not-for-profit stations are run purely by volunteers who have a passion in radio, broadcasting or just want to be involved in something a little different. I've been interested in radio since I was very young and always wanted to be involved somehow, so around 6 years ago I started to get involved with local community radio in the area. I've never looked back, helping a few more and more community stations get up and running, or just offering a bit of assistance now and again. My proudest achievement was being a part of setting up and starting a community station in Hartlepool, the station is still running, going strong and have had their license extended beyond the initial 5-year period so I'm thrilled I've been part of something as exciting as that.

So onto another challenge, I was approached to help with a Community station in Redcar, and as usual I couldn't refuse, so started to help with the planning, FM application, documentation and everything that goes with it. Needless to say I get into a lot of trouble for using up so much of my free time on projects like this but I absolutely love doing it! And so, we're now up and running online and just hoping and waiting to hear if Ofcom will grant us an FM license. This would be really exciting if it is granted as its then a mad rush to get a studio fitted out, FM transmitter, audio processing, etc, all in place. It feels like its taken forever to get to this stage, but in reality the station at Redcar has come together in a very short time period. Just around about a year from the original planning and ideas to having the station running 24x7 online streaming and having presenters on-air live from 10am to around 6pm each weekday is so rewarding. Fingers crossed the FM license comes through soon and it can go full-time on FM!

 

I should also talk a little about what I'm interested in with radio. It's not primarily as a presenter, as unfortunately I'm not the worlds best radio presenter, I mean, don't get my wrong I believe I can do a reasonably job of it, done quite a few interviews over the years and played music, chatted a bit and quite happy in front of the microphone, but alas, I'm not the most thrilling in the world and have the voice to match so this will never be my strong point! So where I aim for is the technical side of radio. The playout systems, broadcast chain (thats the audio processing, FM transmitter, RDS encoder, etc) is where my interest lies firmly. I've been lucky enough to be a part of two start-up stations now, both with their own slightly different needs and so the playout system and equipment behind the scenes needs to be a little different too. At the first station I'm pleased to say we could do things in quite a structured manner. There are two studios, one main playout and a second for pre-recording and voice work. Both use the central database of the playout machine in the primary studio. Audio output from the broadcast desk is then fed over low-oxygen high-grade audio cables up to the 'rack room' where it goes through two levels of audio processing before it hits the FM transmitter, via the RDS encoder and out at 25watts to the end-fed dipole antenna. The coverage is pretty good, even from a congested central town location with lots of noise polluters nearby (noise in terms of r/f interference such as mobile phone transmitters, taxi radios, etc).

This is such a brief insight into what I've put in and done so far, but hopefully I'll get more time in the coming weeks to talk a bit more in depth about each of the elements of broadcast chain and producing a 'decent' output for listeners. If you're interested in community radio too, I'd love to hear from you so please get in touch or pop by on twitter: twitter.com/andyb2000/

 

Friday 21 June 2013

Power ON PC from usb/remotely using Arduino

 Right folks, It's been a while so thought I should start to write up a few things I've been working on. Unfortunately I don't get the free time I used to because of other projects now (See another post shortly, hopefully!) but this one has been a constant pain since I moved the household TV over to XBMC+TVHEADEND.

Turning the home TV system on is done from an all-in-one remote, the Harmony from Logitech. It has a smart switch-on function that sends the various power and channel change events to the devices (TV, Sound System, channel switcher) but one thing it can't do is power the XBMC PC on. This is a Dell PC with a usb-ir receiver that is powered off most of the time unless tv watching is going on. It cannot go into standby as standby and USB infra-red devices are still problematic under linux and results in no remote control ability after wake-up.

So how to turn it on using the IR remote then? The USB ports are powered off when the system is off (All it leaves powered on is the ethernet adapter for wake-on-lan functionality). So I'm thinking that to power the system on I need to use an external device and 'press' the power button/trigger the ATX power supply to wake up. An Arduino seems the obvious choice for this, mainly because they are good little boards, low powered and can do simple tasks with input+output pins and also because I have a couple of them lying around at the moment as I've not done any projects with them for a while.

So to get the arduino to turn the PC on, I need to trace the power switch inside the PC and the control lines it uses on the ATX power supply connector. So as some of you may know, ATX is a standard an so colours and pin numbers are standard. Pick out the right ones, pull it to ground and it should power the ATX supply on. WRONG when it comes to DELL machines. They decided a while back that using a standard like ATX was silly and so invented their own ATX standard.... Hmm, so this meant the pins and wires didn't translate, and so trying to probe them or work them out might cause a blown PSU. Looking at this particular PSU it is one of Dell's finest custom units and I didn't want to replace it in a hurry so decided this option was out. Next option was to trigger the power button that we press on the front. Again in theory this is just closing a contact so should be straight forward. Well it would be if you could get to it! The power button is sat on a PCB installed at the front of the chassis. From this PCB there is a ribbon cable with around 20 connections on it! This handles the Dell diagnostic LEDs on the front of the machine also, along with some USB, firewire and other functions. So if I removed the board could probably trace them and figure it but this seemed a lot of hassle too, and again if I broke it, it was game over.

I needed a solution that wasn't doing ANYTHING custom to the Dell PC. So my only option really was to look at the Wake On Lan option. This could power the machine up 'remotely' and without modifying it.

To actually trigger the Wake On LAN, I needed to receive IR remote presses. Since the all-in-one remote handles power on for various devices I could just sniff for any of these power on signals and use them to trigger my power on function. Hooking the Arduino up to the IR module and then sniffing codes was straight forward, there are various nice IR libraries to do this. I have the 'Keyes IR Receiver module' which is the one on a small PCB with a metal can-like surrounding. Hook up the pins to the arduino (central pin is + , S is marked and the remainder is -) to one of the digital PWM pins and with the library you can start to decode IR.

Now IR itself is a bit complicated. Because you have lots of different 'standards' and methods of doing things. I finally settled on a very simple bit of code that included the IR library, and then sent the HEX code to the serial port. This worked fine and I found a unique-enough code used when power-on was sent from the IR remote. This let the Arduino do its job. How the hard part, how to get this into a Wake On LAN signal. Unfortunately I don't have an ethernet shield otherwise this would have been simple! So my next option was to use the serial/usb cable to send this HEX code to another device that could send the WOL signal. My trusty FTTC router looked ideal, its a Vigor that has an entire busybox system on it, so ssh, telnet, and most of the normal shell commands there ready, plus two USB ports. Plugging the arduino in, I happily could see the /dev/ttyACM0 appear and dmesg confirmed that it recognised the ftdi interface.

So I could now communicate with the arduino, if I cat /dev/ttyACM0 I could see codes working, so all looked good. I then got back to my dreaded problem from some time ago with the outside temperature sensors. The biggest issue with the setup, everytime you opened the serial port, the Arduino rebooted (for its code upload routine), and also it generally didn't hold the serial port open well enough to actually receive data consistently. This was and still is my biggest hurdle that I've not overcome yet. At the moment I'm trying with a bash script like this:

#!/bin/sh

while [ /bin/true ]; do
        grab=$(grep -m 1 valid /dev/ttyACM0)
        
        wget -O - http://192.168.1.1/wake_xbmc2.php >/dev/null 2>&1
        sleep 5 

done

However, this suffers from several problems. (You'll also note, I'm watching for the word valid to appear, I amended my Arduino code to only put out valid when the relevant IR code was received, this cut down noise on the serial port to try and help things along. Firstly the serial port doesn't always seem to want to send data. So sometimes this will just sit there ignoring any IR input. I'm guessing the Arduino is seeing the IR (The LEDs on the arduino show this) but the serial port just isn't seeing the reply.

Secondly if the serial port is disrupted, the wake on lan gets triggered regardless. This is just a bash scripting tweak but I've not got round to fixing this yet.

So I'm still stuck with reading from the Arduino serial port reliably in this manner, and so I'm hoping for inspiration! Arduino people, feel free to comment and assist!

 

Sunday 20 January 2013

Linksys WRT54GL bricked

For years I've used the Linksys WRT54 range of wifi routers, I like these units as they have a decent form-factor, generally just keep on running for years without any attention and two wifi antennas that have screw-terminals on them so can easily add or change the aerial. I've always flashed these routers with different firmware, generally I use DDWRT as this has a new GUI, easy setup and quite a few advanced functions to switch WIFI on and off at certain times, captive portals, firewall rules, etc.

Recently I was going to upgrade my firmware, so did the usual, downloaded from DDWRT and uploaded it, then waited for the reboot, wifi didn't come back. Let it do its longer reboot, still nothing and it just wouldn't come back. I checked on the unit and the power light was constantly flashing, this is a bad sign, this generally means the FLASH/firmware isn't working correctly and its stuck in a boot loop. The recovery options on the Linksys/Broadcom hardware are to try their failsafe IP, this is 192.168.1.1 and initialise during their CFE bootloader. The trick here is to see if you can get a ping from 192.168.1.1 during power on. Unfortunately, this also didn't work for me, so it looked increasingly likely that I'd lost the unit completely, so it would be down to using a JTAG re-flash of the system to recover. This isn't easy! So popped the cover off and located the JTAG port. JTAG is a 12-pin (6x6 pins) port that you can access the Broadcom chipset directly to re-flash and debug it. In my case I was trying to use my FTDI cable FT232RL. I now realise this was STUPID of me! This is simply a low-voltage (3v) TTL to serial/usb converter cable, not a JTAG. So I started to give up hope. Until I realised, on the Linksys board was a SERIAL pin header. I soldered up some pins and connected up at 115200-8-N-1 and powered on. Sure enough I saw the bootloader!

This was a relief, it showed me that the bootloader wasn't damaged, but it just hun as it tried to load the O/S (As expected). It also confirmed that it should have been listening on 192.168.1.1 but the time it waited was tiny, almost 1-2 seconds! But it gave me hope as I reckon I could try to recover it from this point. Here is the screen output I had:

 

CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: Tue Jun 20 16:22:41 CST 2006 (root@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.
 
Initializing Arena
Initializing Devices.
 
No DPN
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.37.0
CPU type 0x29008: 200MHz
Total memory: 16384 KBytes
 
Total memory used by CFE:  0x80300000 - 0x803A39C0 (670144)
Initialized Data:          0x803398D0 - 0x8033BFE0 (10000)
BSS Area:                  0x8033BFE0 - 0x8033D9C0 (6624)
Local Heap:                0x8033D9C0 - 0x803A19C0 (409600)
Stack Area:                0x803A19C0 - 0x803A39C0 (8192)
Text (code) segment:       0x80300000 - 0x803398D0 (235728)
Boot area (physical):      0x003A4000 - 0x003E4000
Relocation Factor:         I:00000000 - D:00000000
 
Boot version: v3.7
The boot is CFE
 
mac_init(): Find mac [00:1C:10:36:41:9E] in location 0
Nothing...
 
eou_key_init(): Find key pair in location 0
The eou device id is same
The eou public key is same
The eou private key is same
Device eth0:  hwaddr 00-1C-10-36-41-9E, ipaddr 192.168.1.1, mask 255.255.255.0
        gateway not set, nameserver not set
Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
Loading: .. 3916 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000
 
You can see it was giving me its IP and trying to boot. So now to try and interrupt it and get a ping reply. It also occurred to me at this point, previously trying to connect/talk to it I had plugged the cable directly from the router into my laptop. This was problematic as linux was trying to auto-negotiate and DHCP to the interface, which seemed to also introduce a delay, the delays were small but when I'd see the bootloader via serial I realised how time-sensitive the whole approach was. So using a mini-hub I connected the two together and started the ping again. Again I rebooted and found it didn't reply to pings.
The CFE bootloader can be interrupted by a CTRL-C to go interactive (like grub, lilo, etc) so the next trick was to try and interrupt it. Again this was time-sensitive and I found I had to keep hammering away at CTRL-C whilst plugging power into the router. A very tricky thing to do, but keep trying. Probably 10-20 attempts. Finally I got in and it responded:
 
mac_init(): Find mac [00:1C:10:36:41:9E] in location 0
Nothing...

eou_key_init(): Find key pair in location 0
The eou device id is same
The eou public key is same
The eou private key is same
Device eth0:  hwaddr 00-1C-10-36-41-9E, ipaddr 192.168.1.1, mask 255.255.255.0
        gateway not set, nameserver not set
Automatic startup canceled via Ctrl-C
CFE> ^C
CFE> ^C
CFE> help
Available commands:

rndis               Broadcom USB RNDIS utility.
et                  Broadcom Ethernet utility.
modify              Modify flash data.
nvram               NVRAM utility.
reboot              Reboot.
flash               Update a flash memory device
memtest             Test memory.
f                   Fill contents of memory.
e                   Modify contents of memory.
d                   Dump memory.
u                   Disassemble instructions.
autoboot            Automatic system bootstrap.
batch               Load a batch file into memory and execute it
go                  Verify and boot OS image.
boot                Load an executable file into memory and execute it
load                Load an executable file into memory without executing it
save                Save a region of memory to a remote file via TFTP
ping                Ping a remote IP host.
arp                 Display or modify the ARP Table
ifconfig            Configure the Ethernet interface
show devices        Display information about the installed devices.
unsetenv            Delete an environment variable.
printenv            Display the environment variables
setenv              Set an environment variable.
 
As you can see, we can now get to the bootloader commands, whilst this appeared my pings to 192.168.1.1 worked, so I now had a chance to get into it! I immediately tried sending a new firmware via TFTP to the Linksys. Trying to send the firmware over tftp was failing, so I was a little confused, until I read about CFE and how it works, and realised, by interrupting its boot process, it stopped its ability to receive firmware. So I now started to read about the commands, as I wanted to do it all in one go now, no more reboots as who knows if I'd get back into this mode again! Checking the commands I saw the erase and flash options. Checking again at DDWRT it showed that I could erase the existing/faulty flash 'nvram erase' which confirmed back with a 0 (for ok). I then found parameters to the flash command, and this accepted flashing from a TFTP source, so by doing:
flash -ctheader : flash1.trx
I could start the flash, at the same time sending the file via tftp it started to upload:
 
CFE> nvram erase
*** command status = 0
CFE> flash -ctheader : flash1.trx
Reading :: CODE Pattern is CORRECT!
upgrade_ver[v4.20.6] upgrade_ver[42006] 4712_ver[15000]
Done. 3032064 bytes read
fname=flash1.trx 
CODE Pattern is correct! (W54G)
Programming...done. 3032032 bytes written
*** command status = 0
 
At that point I typed 'go' which told it to boot, and sure enough after a few seconds DDWRT kernel boot messages appeared and eventually got the DDWRT root prompt, so I'm back in.
 
Hopefully the above will be handy to anyone in the same situation and thinking their router is toast. Persistance and keep on reading for solutions, good luck!