Arduino shed/outdoor monitor, batteries and solar panels

A brief update, I put in place my shed/outdoor monitoring system last weekend, installed the solar panel and monitors, and have so far had to change the batteries already, so at the moment it looks like they are only lasting 3-4 days maximum.

Upon investigating my 9v solar panel is giving out 2-3 volts, which is pretty useless. I'm trying to charge my 4 AA batteries (6 volts).

So my next plan of action is to take the solar panel back down and work out why it's only producing this very low voltage, I'm now wondering if the connections on the rear split the panel into two and I'm only connecting to one half (even so doubling 3 volts isn't near the 9v I was expecting), so a bit more investigation is needed.

(Yes I removed the plastic film cover! But it is inside a plastic box for protection, but even so I'd not expect the voltage drop to be that dramatic)

Graphs were being produced before the power failure though as you can see below:

(note the flat line towards the end is where the batteries died and I'd not written a failsafe into my graphing to 0/ignore results)

Arduino ESP8266 1-wire Dallas temperature, soil, rain, moisture, solar power unit

Arduino Uno outdoor sensors project. Here is the first posting for my Arduino UNO outdoor monitoring unit. The idea for this is to act as a small weather station, and also to feedback on the condition of the garden. So this is my second version of my earlier garden controller (several years ago).
I bought a bunch of sensors recently, which included:

• 1-wire Dallas temperature sensor DS18B20
• Rain sensor module with LM393
• Light dependant resistor LDR5528 (+10k resistor)
• Soil moisture sensor with LM393
• ESP8266 wifi module
• 9v Solar panel + 1N4007 diode
• Water float sensors (x2)

The goal is to setup a stand-alone Arduino that will connect to my wifi (signal may be an interesting problem, we'll come to that) and then feed back a lot of environmental information to my server, that I can then graph/log and alert depending on the inputs.

ESP8266:

First job was to get the ESP8266 wifi module working. This was a new item to me, but it's principle was simple, it was a stand-alone wifi module that you could communicate using 2-wires serial (TX and RX), so you could open a serial session, connect to your wifi AP using WPA2, WEP, etc, and then set it to send data in an HTTP GET session. The simple commands made this an excellent add-on for me to include in my project, and the price is excellent (Around £3).

Connecting it up, you need power (3.3v), also you need to pull CH_PD to positive, which I did through a 10k resistor. So my wiring diagram worked out as:

(Credit to enio in arduino forums for image)

I connect VCC, GND, CH_PD for power. then TX and RX to the Arduino. To test the connectivity I used my Arduino UNO, loaded a blank sketch and connect RX to data_rx and TX to data-tx (pins 0 and 1 digital), that let me type into the serial console and it was passed straight to the ESP8266. Various AT command sets are available all over the internet, so a few tests I did:

AT

AT+CWLAP

(Full list on wikipedia http://wiki.iteadstudio.com/ESP8266_Serial_WIFI_Module#AT_Commands)

After receiving valid replies I knew the unit was operating correctly, and making a quick sketch to connect to my WIFI using softserial started working (using softserial allowed me to use alternative digital pins for talking to the ESP8266 whilst still having my serial console to monitor and upload sketches).

After some trial and error, I found this wifi module dropped out or didn't respond to commands. Upon checking various forums and information, I found this was probably due to the current this was pulling. Originally I was powering it via the 3.3v output on the Arduino, however this couldn't provide enough power, especially when I added all my other sensors, etc and I started to get issues with no reply to the AT commands. Therefore I decided I needed to power this separately. The solution (since I would be powering this from a bank of AA batteries) was to use a LM2596 DC-DC step-down power supply (also known as a buck converter).

I set this up on my multimeter and set it to produce 3.3v so this would supply the ESP8266 directly. (I'll have to see over time how inefficient this method would be, as I know it'll be wasting energy from the battery packs)

1-wire temperature sensor DS18B20

I've used these temperature sensors many times before, I have one in each of the Raspberry PI's around the house and have created a basic temperature 'network' within the house to monitor room temperatures in previous blog posts. I'm using the same sensor again, so as before simply connecting the 3 pins up and including the "OneWire.h and DallasTemperature.h" libraries into my sketch and it was up and running. PIN connections for the DS18B20 are as follows:

  

So in my setup (You can't quite see this in the picture unfortunately as it's wrapped in black tape) I have connected GND to ground, VDD to +5v, DQ to a digital pin, and then via a 4k7 resistor DQ is also connected to 5v.

Soil moisture sensor with LM393

The soil moisture sensor is a regular two pin/probe style that you stick in the ground, and then measure the resistance between pins. The unit I bought came with a basic LM393 control circuit shown below:

 

The pin connections are simple, on the left you connect the soil measuring probe, the right are 4 connections, top and bottom are +VE (3.3v) and GND, then you have an analogue out or digital out. The digital out (high or low) is controlled using the variable resistor on the board, so you can set the threshold. I opted for analogue so connecting to the analogue inputs and then read the values shown. Read this as a typical integer from the digital input.

Rain sensor with LM393

This is the same as the soil moisture sensor and came with the LM393 sensor as above.

9v solar panel

To power my arduino I decided to go with a battery pack and use a solar panel to top the batteries up. I purchased a battery pack, the model I chose had 6xAA batteries so produced approx 9v. This created several problems. Firstly the cheap solar panel I bought only produced 220ma 2 watts at 9v, so even at full sunlight it was producing the same voltage as the batteries, therefore this would not charge them (generally you need a higher voltage to charge) and at low current.

Therefore I decided to modify my battery pack to exclude 2 AA batteries, taking the voltage down to 6v which would be more suitable for the solar panel to charge them, and also will reduce the amount of power lost through the heat dissipation on the Arduino Uno.

(NOTE, I'm not an expert on batteries and power, so please do correct me if I make some glaring errors here!)

These are the solar panels I'm using (A chinese import) and currently with their protective plastic film over them. I'm planning on fitting these into a plastic container, to keep them protected from the elements. Although this will reduce their output slightly it will protect them over time.

I should also mention that I have connected in a 1N4007 1A 400v rectifier diode to ensure no power from the batteries are lost back into the solar panels during darkness, etc.

Below is the power pack that I've put in my two dummy batteries to reduce the voltage/number of cells:

Testing the Arduino Uno and the LM2596 powering all the devices the pack was providing enough power. I'll monitor this for amount of current consumed, etc, later in the testing/implementation.

Light Dependant Resistor LDR5528

This was a simple off the shelf LDR that I connected up to the Arduino analogue input ports with a 10k resistor in parallel (to the 5v feed). I then read this during the normal sampling periods.

CODE

The code I've used is a combination of various of my older projects put together with some libraries to control the various input sensors. The libraries I've used are as follows:

#include <LowPower.h> - This is to be used to help reduce idling power consumption

#include <stdlib.h> - for dtoi and related functions

#include <SoftwareSerial.h> - for communication to the ESP8266

#include <OneWire.h> - for the 1-wire temperature communication protocol

#include <DallasTemperature.h> - 1-wire temperature

I set a few definitions near the top of the code (for SSID, WPA2 password and the url to GET when sending data).

Setup involves setting the various input and output pins to their relevant values and initialise the softwareserial.

The main code loop is fairly straight forward, I read each of the sensors in turn, display the output to the serial monitor and then use the ESP8266 to send the data to my webserver.

The code is available in full on my github page, so feel free to take a look, and if you can spot any improvements please commit them as I'd like to get some feedback and improvements on my code:

https://github.com/andyb2000/outdoor_sensors

(NOTE: There are a few extras I've missed off here, I'll post further blog entries with tweaks and changes as I make them and when I implement the final system)

Follow up to Marmitek/Haibrain SC9000 PSU failure

This is a bit of a follow up to my previous post on the Haibrain SC9000 X10 alarm unit that I use at home. I decided to bite the bullet and purchase a replacement power supply (£15 so not cheap, but then again not too pricey) and it arrived a few days later. I've finally got round to fitting it and as I did made a few observations and notes for the future.

I took quite a few photos which are all in this post, so apologies for it being graphically heavy.

Firstly, the new unit arrived, and unboxing showed it to be identical to the original, no change to voltage, current, etc. So first thing I did was connected it up as a test and checked, yep the alarm would now sound and all the X10 commands started to flow, so it appears this IS a faulty power supply that causes the alarm sounder not to trigger and the X10 commands to fail. At least I'd now determined the root cause of the fault, it wasn't the overall alarm unit.
Next, I wanted to try and see WHY the original failed and if possible make the new one last longer. One thing I'd always noted was that it ran hot, as most step-down transformers give off heat this isn't unusual, but they generally have vents or at least some way of expelling the heat. This one doesn't, the power supply is a sealed black brick, no vents or anything and when I say it ran hot, you wouldn't want to hold it in the palm of your hand long, it's that sort of heat. So my thinking is I give it some vents before I put the new one into service to help loose the heat, my thinking is most electronics prefer to run cool than hot and it might stop the failure occurring again.
This meant my favourite (ha ha) thing of all time, take something brand new that I've just paid for, take it apart and modify it! But luckily these PSUs have 4 clear screws and a simple case, so taking it apart isn't a challenge. Once opened up, split the two halves of the case carefully as one circuit board stays in one side, the other in the base as you can see from this photo with the case carefully separated:

The right is the "base" which has the main transformer and a circuit board that covers the base, along with at the top right the 2-pin mains in socket.

The left "top" holds a much smaller IC-containing board and the output wire that feeds to the alarm (4-wire). The small circuit board has a single screw in it (just visible on photo, bottom left) so take that out and the top casing comes completely clear. This was ideal, my thinking was to make air vents right along where that bulky transformer sat as that's where the heat was generated, and it was VERY snug alongside other electronics, so a good bet.

I set about the case with my dremel, and here I show my failure as a practical/mechanical/precision person, the air holes are horrible, not neat, but I sanded them down so no rough edges and I think they'll do the job.

 

As you can see they aren't neat, but should allow a bit of heat to escape. Putting it all back together and it looks like the vents are in the right place, right over the transformer.

Now since I fitted the front of the SC9000 to a wall, and then fitted the cable into the gap between the plaster and wall (inside the wall), the next problem was re-feeding the wire to the right place. So I decided not to, and to simply cut the cables and join them back up using a connector block. That way I didn't have to re-trace the cabling in the wall and make life a lot easier!

As you can see, I was feeling quite neat today and even used a connector block (instead of twisting the wires together and taping them together). I then wrapped the block in tape so it was secure and no potential for shorts or anything getting in there.

Putting it all back together, power on and it all worked fine!
(Note for later, when the batteries are low, the green battery light stays on! I thought the power supply had blown somewhere in the process as the green light stayed on. Seems the green light not only shows it's running on batteries, but also that the batteries are low!)

Next, I decided to properly pull apart the old supply, as I'd like to find what failed and possibly fix it, so in future I have a way of repairing these things with just a few parts.
Below are a load of photos of the teardown, I've not yet had time to investigate all the parts but will do very shortly and probably try a trial and error of replacing parts until I discover the failed unit. However as you'll see there are quite a few scorch marks on components, so I'll be starting work there, which is also where I believe the mains part of the circuit resides, hence this bit will be more susceptible to mains spikes, etc, (which is what Marmitek/Haibrain state as the issue when the PSU fails, it's a mains spike)

The main split board from above

The smaller IC board

The top corner of the main board, no obvious damage here.

 After removing the transformer, some scorching of the main board was clear, I'm now suspecting this is where the issue is.

 Underneath shows more heat damage.

 Closer view of the high voltage components that sit almost exactly underneath the transformer.

After inspection I suspect looking at these components closely, however they are only a couple of resistors, so I'm not hopeful that it would be something as simple as these failing!

Marmitek/Haibrain SC9000 X10 alarm system

* Updated 02/06/2015 (See end of post)

When we moved into our new house a year ago, I decided to go for an alarm system that I'd be able to integrate with, and use with my home automation that I keep trying to build upon and improve. I already had various X10 home modules (lights and appliances) and whilst some of these modules are poor quality and fail quickly, it is a good system that has worked for me. I have the CM11a conneted via serial to my server in the house so it can monitor all X10 codes and also send them for turning outside lights on, living room lights, etc.

So I looked into it and went with the SC9000 home alarm system from Marmitek (Who are now called Haibrain) as it was a fully integrated X10 alarm system, it could send and receive X10 signals over the home powerline and also used wireless door and motion sensors in the house for triggers.

The above is a stock image, but it's similar to what I got, I added more sensors and an external bell box. I fitted the unit into the hallway in the house, cut a hole in the wall and fed it to be supplied by a mains socket. This was the first challenge. The PSU looks like this:

Which is kinda tricky to install for an alarm system! You want things like that hidden (So burglar doesn't unplug the alarm!) and that huge power brick and hard-wired plug was a pain. I also did a bit more reading and found that power brick isn't just a step-down transformer. Since it has to send and receive X10 signals it actually has a lot of the X10 circuitry built into it.
So my plan was, install the front facing alarm unit somewhere public, then run cables away somewhere hidden. The house lent itself to this so I got it fitted and sorted. The alarm had backup batteries internally, so it was protected even if the power was cut.
Registering the wireless motion sensors and door sensors was easy and the remotes to arm and disarm the unit, etc.
The unit wasn't as flexible as I'd hoped, you couldn't specify which zones you wanted for "home set" and "away set". I.e. when "home set" it will only activate the door sensors, no motion sensors. And "away set" activates all sensors, no option to exclude. This was a bit annoying, but the unit didn't have much flexibility in it's programming.

Anyway, I lived with all of that, and now almost a year later the unit has stopped working in quite a critical way. It won't alarm! It sets, it will do the exit timer chimes, and notify when people open doors, but critically if it's triggered it would sound the main alarm sounder. It is also not sending or receiving the X10 signals.

Again, reading up, it appears the PSU on these units is particularly sensitive and will 'blow' in a partial way quite easily. My PSU has always run pretty hot, this seems common with X10 stuff, and it looks like after around a year it's given up. It still supplies the correct voltage, etc, so the alarm is on but critically it won't send or receive the X10 commands (So can't send the 'ALARM ARMED', 'disarmed', etc) and it also won't trigger it's main alarm siren.

I've contacted Marmitek in the hope of finding a solution, as I am also not 100% sure this is a faulty PSU, or some other fault that has been developed. Either way I want an answer as surely it has a longer life than a year on it. If it does indeed turn out to be the problem, I think an alternative is needed as I'm not going to keep replacing these every year for an alarm system, seems excessive that, as electronics should be more capable than that.

* Update 02/06/2015

I've had a reply back from a UK reseller of the Marmitek equipment regarding this issue, and they do indeed state that it was likely a brownout or power spike caused the PSU X10 electronics to fail causing the situation I've got. They've recommended their replacement power supply at £13. I've contacted them back asking if anything can be done to protect the supply, as my understanding is I could buy a new one, plug it in and if I get another surge next week that one will blow. And putting it behind a surge protection multiway I suspect would stop the X10 signals. I'll post back if/when I get a reply, but in the meantime it doesn't look a very good solution to me.

w1-gpio w1-therm In openelec

Well, I'm really pleased to announce, something I wanted has been implemented into the Openelec build tree and will be in future releases.
A while ago I wanted to do 1-wire temperature sensing using my raspberry pi's around the house running openelec. Seemed a good use of hardware that was low power, small and generally always on.

In my quest for this I found what was needed (addition of modules to the kernel build) and set about testing and using it myself. And it works great, for a while now I've been logging temperature around my house and slowly building my own thermostatic control system for the house heating. Truly intelligent heating control!

And now the kind developers at Openelec have seen my feature request :

https://github.com/OpenELEC/OpenELEC.tv/issues/3975

And given it the green light, it's now implemented in change:

https://github.com/OpenELEC/OpenELEC.tv/commit/413817a9d765c49014baed1d9224c86022ce7b12

Sad as it is, this gives me a huge self confidence boost and a big pride boost! (told you it was sad!) I love open source, and dedicate a lot of my spare time to developing projects using open source, and returning things to the community (breakinguard, kodi scripts and plugins, and my contributions in the past to Tvheadend) and when something I wanted implemented has been done and will be available to all future users gives me something to smile about!

To all those that contacted me via my blog about using this, compiling themselves, etc, here you go, problem solved!

-- Update 10/08/2015

Thanks to Jo (https://www.blogger.com/profile/09579014828121678108) he confirms the action to get the module loaded on the PI as follows:

mount -o remount,rw /flash (To get the flash filesystem into rw mode)

echo "dtoverlay=w1-gpio" >> /flash/config.txt

Then reboot and you should be good to go!

asterisk and the RTP timeout

This was an interesting one after a new install of Asterisk (using freepbx) and one I wanted to document and log for future.
We had users on a new phonesystem (Part of an existing one, but using a new call server, running latest Freepbx 6.12.65-26 and asterisk 11.16.0) and finding that putting people on hold, the calls would get cutoff at times.

Doing some investigations, I could see:

[2015-05-21 10:18:44] NOTICE[3336] chan_sip.c: Disconnecting call 'SIP/5011-00000e0e' for lack of RTP activity in 301 seconds

[2015-05-21 10:57:34] NOTICE[3336] chan_sip.c: Disconnecting call 'SIP/5049-00000e33' for lack of RTP activity in 301 seconds

Appearing in the logs. Doing some reading, what was happening was the user placed a call on hold and dealt with the issue, during this time no rtp data passed to the handset (the onhold was passed back to the voip server to play nice music to caller), and after a while asterisk thought the phone handset had given up (i.e. rtp stream timeout) and so disconnected the call.

The apparent fix here is to  add in an RTP keep alive, which is in "Settings > Asterisk SIP settings > Chan SIP" and in the "rtpkeepalive" value I've added in 10 initially to test.
This bit of gui-ification adds in:

rtptimeout=190

rtpholdtimeout=600

rtpkeepalive=10

To the sip_general_additional.conf file (and so forms part of the global [sip] configuration for asterisk)

Will keep monitoring this, but suspect this was the issue.

UPSs tinkering

Doing a bit of tinkering with UPSs (Uninterruptible Power Supplies) for the FM station I help out at, and been discovering some interesting fact and details that I'm making note of, again more for my benefit that others probably!

Firstly, the problem. Several old UPS units well past their prime have been in use to smooth the power out and keep the equipment going for all those little blips in power, this is to provide power to an FM transmitter, audio processor and RDS encoder. All together they don't draw a huge amount of power (approx 130 watts), but I need them protected against surges and other nasties, also the power in our particular location isn't very good, drops out often and suffers from surges, brownouts and all sorts, so protecting this sensitive and expensive equipment is a must.

I've used a variety of APC, Belkin and no-name UPSs for this job, mainly ones I've salvaged and either got working enough by cycle charging them or pure luck, and they hold up for at least a few minutes in a power failure which smoothes out most of the dips we get. Now I had a chance to properly replace a couple, the first was my old ALC Smart-UPS sc420 which is a reasonably new model (4 years approx), and I didn't use as it was alarming about battery failure. So looking to purchase a new battery, hit the APC website and they wanted me to trade the whole UPS in for a replacement. This seems excessive, it only needs a new battery. So, all of these units are able to be replaced, taking the battery out, it's a regular sealed lead-acid (or gel, I'm not sure) battery. Looking it up, APC call it the RBC2 which is a single unit 12v battery. You can get replacements relatively cheap, in this case around the £25 mark including delivery, so that was a no-brainer, order that, swap the battery and off we go. Went well, and now using it's monitoring on my linux server (apcupsd) it's currently showing it's at 55% load capacity, battery at 100% and approx 16 minutes of run-time available. Excellent, so that solves the immediate problem.

I therefore now have a 'spare' UPS to tinker with, and this one has a bit more power behind it. This one is the APC smart-ups 1500, and after looking it up this can deal with 980 watts at max, so this is a pretty decent size unit (It's also quite heavy!), so again pulling it apart to see what batteries it has, and this one has two joined together. The pic below shows what configuration it has:

These are considerable larger batteries than the RBC2 units, and you can see there are two joined together. On the right terminals (the blue block) is a large fuse joining the terminals together, and on the left you see the cables that are connected into the UPS itself (the yellow marks are the adhesive that had covers over all the exciting bits). Taking it all apart, I'm expecting two 12v batteries again, so joining them in series like this would give a 24v pack. Each battery was registering around 2v on their own, and so seem pretty dead to me (This ups is probably more like 10 years old, and in my use it died probably 2yrs ago and has been left unplugged ever since, so I suspect sulphurisation has occurred and completely ruined them), so onto the next thing, identifying so I can replace. This isn't easy.

APC batteries are completely generic, no markings, or anything. I suspect they either burn, scrub or simply cover all markings showing voltage, current, etc, which makes it harder. Luckily most websites have direct lookups for these batteries, just put in the ups product and it'll tell you what size, etc. So that looks like the next plan, to order a couple, wire them up and get this UPS back on the road!

Chrysler Grand Voyager - Sound System quandry

So, I'm back trying to add in my Parrot bluetooth phone kit into my Chrysler Grand Voyager (2004). This has hit upon several big obstacles, the first of which, nobody online (Manufacturers, suppliers, etc) can decide on what the correct kit is needed for this car, some say SOT-046 some say SOT-086 and others say SOT-948. So I checked, and in the past I'd bought the SOT-046 (For my last Chrysler Grand Voyager 2004) so bought another one the same.
However this time it didn't work out, connecting it in, all went well, however the unit when trying to play audio through the speakers simply slightly muted the audio and no phone/Parrot audio at all.

I did a lot of digging, checking wiring diagrams, cabling, etc, and came to the conclusion it must be the wrong cable, so went and tried others, but all gave the same problem, that it didn't fully mute the radio and no audio at all went through.

Next step, I cut the cables on one of the SOT-046 cables and started to do my own testing, firstly by trying a manual connection from the radio to the car audio harness. This is when I started to find something strange. Disconnecting all the audio output cables (Verifying the wiring diagram online and on the Parrot wiring diagrams, so at least these added up) from the radio, and trying by connecting just one (Driver side right) pair. This didn't result in any audio output at all. Strange! I then tried each of the other pairs, checking polarity (Front left, Rear left, Rear Right) and none of them worked. I was now really confused. So connected them all back up again and they all started working. So it wasn't a fault, but almost by design. This makes me think (I already suspected this) that there is an amplifier somewhere in the car to drive all the speakers (8 speakers in total!) which is sometimes referred to as the Infinity sound system. I then tried connecting all speaker pairs up again and then disconnected a single one whilst the system was still on, and strangely that speaker didn't totally go quiet, it lost a little volume but not totally. Swapping which wires were connected or not seemed to produce similar results, but again disconnecting a single pair didn't stop a speaker from working. This confirmed what I suspected, these aren't true line-level outputs to an amp, they are more a digital output per channel.
This is my assumption anyway, and if this is truly the case then I'm going to struggle to feed in the analogue audio from the Parrot phone system.

Therefore a bit more investigation is needed I suspect, but that's my findings so far!

Removing dashboard/console/speedo from Chrysler Grand Voyager

This is a break from my normal blog posts, but I'm going to be adding a few car information posts, since I've not bought another of my favourite cars of all time, the Chrysler Grand Voyager. This huge people carrier (7 seats) is a nice comfy big bulk of a car but has loads of gadgets and is just a really nice car to drive!

So onto the tutorial, I found that the speedometer, rev counter, etc, weren't illuminated at night, so looks like the bulbs were out, so to remove it here are the few simple steps. It didn't take long and is nice and straight forward.
First, there is a plastic cover at the base which exposes two of the first screws, this simply pops up so just apply a little force to the centre of this panel:

As you can see, I've popped that up on mine already. Be careful, the UK edition has that LED embedded which is the engine immobiliser light. The leads on it aren't very long, so don't pull the cover off too quickly.
Looking underneath you'll see the LED is on a small connector, so you can take each leg/lead off. Make sure you mark/make a note which colour lead onto which leg as LEDs are sensitive to polarity (+ and -) so make sure you put them back on the right way round!

LED on mine has yellow and grey leads, so I simply removed the grey lead and wrapped that leg on the LED in white electrician tape.

Remove that cover now and put it out of the way. You've then exposed all 4 screws (the top two screws are obvious)

All four are cross-head (otherwise know as Phillips) screws, so nice and easy. Once out you can remove the plastic facia. This is a little tricky due to it's size and the steering wheel getting in the way, it is slightly flexible so let it flex and eventually it'll come out.

There are then 4 screws at each corner of the panel, each of these are cross-head. Careful when you remove them, try not to let them drop. I did with one of mine and luckily it rattled it's way down and out the bottom into the footwell, but I think I was lucky!

After you've removed all four you can then gently start to move the whole panel towards you. The cable/connector for the panel is along the top near the middle, so pull it towards you slightly so you can see it. It uses the standard Chrysler GV connectors where you slide the red tab before you can press the release on it and tease it out. Try to get the connector out in one swift action. I didn't on my first attempt and the car started to light up a lot of panel lights randomly (Ignition off and key out, obviously) so be careful as I'd not want to do that too often in case it confused it!
Once disconnected you can remove the whole panel. Here is the back of the panel for reference and you can see the main connector just offset from the middle slightly.

(As an aside, you can see why my panel illumination doesn't work. There are no bulbs or even fittings where they should be! These are PC74 lights+fittings for reference)

Fitting it all back together is pretty much the reverse. It's not a complex/tricky job, but hope this helps.

Broadband at home in the UK

As some of you may know, my professional life is working for an isp as network engineer, and in that role I end up dealing with larger internet connections (mainly business who get fixed line circuits or fibre circuits).
But at home, I unfortunately struggle with a less than perfect speed and connection and unfortunately there is very little you can do.
Thousands of homes through the UK suffer a similar problem, the old BT (or gpo!) infrastructure just simply isn't in place in many locations, especially those in rural Britain or in places where the infrastructure hasn't been touched in decades.
For telephony this isn't a problem, the old twisted pair copper does the job for voice just fine as our ears aren't great at picking up on very high or very low harmonics, so a slightly iffy copper line doesn't make a difference.
Now try to feed superfast broadband over this and you start to have problems. Most superfast broadband uses high frequency to 'overlay' the digital signal on top of the same copper pair used for the voice calls and  excuse of that we don't hear or know it's there.
And there is the problem. It had to use the existing copper, so where a line is poor, the infrastructure old, degrading or with few subscribers it's neglected and the costs involved in upgrading, very high.

Now after saying all of that, here's my situation. I live in the North-east of England, in a relatively built up area, served by a relatively modern telephone exchange, and in a house built in 2014. Yes that's right, it's a new house, in a new housing estate in an exchange area covered by an upgraded fttc exchange. But yet all houses in this new part of the estate can barely reach download speeds on ADSL of 3Mb. Why is this?
Well, I've written to everyone I can, I've spoken to BT wholesale, BT retail, the local council, the builders, local government, bduk and they all come back pointing the finger at each other and say tough luck, no plans or funding to sort this out.
So who says what? Bt wholesale state that the builders are responsible for 'selecting' the cabinet/infrastructure that wholesale then install. This seems odd to me, yes it's a pure cost thing as the builders I believe have to assist in payment to wholesale for the street cabinet, but surely a survey by wholesale would show around 200 homes to be served by this cabinet and think there was a market there? (how many homes does the average Street cabinet serve? I'm not sure)
So the builders to be honest, don't care. They'll sell the house regardless and its the homeowners problem on internet connectivity, they do the minimum required (plumb gas, electricity and copper pairs for phone) and the rest is up to the home owner.
Local council state that as the roads aren't adopted by the council yet (building is still going on in parts) that it is nothing to do with them and they wouldn't get involved and don't have on record any plans or queries on the street cabinet install or planning.
Bduk who are charged with helping areas achieve better high speed broadband also cannot help as they can see the problem, identify the cabinet and confirm the issue but then state it's not in their upgrade plans or budget as it wasn't in place in time for their forecasts  so it's been missed.

And so, that appears to be it. No option but for each of the 200+ homes to go with slow adsl broadband and wait in the value hope when the roads are adopted by the council that we have somebody to complain to and see if they can assist.

I'm not hopeful.

Raspberry PI, Openelec and 1-wire temperature sensing

I've finally got back to writing up some blogs, so there are a few things I'm currently trying to achieve, and as always the solution to a problem involves Arduino, Raspberry PI and electronics!

This particular problem is my home heating system. After being in the new house for a year we're still struggling to have the heating system actually heat the house to a comfortable amount when it needs it. The built-in heating system uses a temperature sensor (Looks like a DS18B20) in the hallway (beside front door and a radiator), and most other rooms have radiator thermostats. The problem is that the hallway never really matches the temperature in the rest of the house, bedrooms are often cold and other rooms roasting hot. Therefore I had a plan to have temperature sensors around the house and provide an 'overview' on/off to the heating system, in theory when rooms are still too cold, forcing the heating to stay on should let these rooms warm up and rooms that are already up to temperature will remain there because of the radiator thermostat. So to do this I need a way of sensing temperatures.

I already have Raspberry PI's in a few of the rooms, sat behind TV's to provide TV/media playback, so I looked into using the 1-wire temperature sensor DS18B20 on the PI. Now luckily there is a nice 1-wire kernel module available so it's pretty easy, modprobe the 1-wire module, modprobe the 1-wire temperature module and you can then pull sensor values using a script. Pretty easy, and yep testing this it works great.
The commands used were simply:

modprobe w1-gpio

modprobe w1-therm

Which then allowed me to grab sensor values by prodding about in the '/sys/bus/w1/devices'

However, I use Openelec, not a standard Raspbian release. Now Openelec is great, it's a cut-down system that just works, it boots quickly and runs the hardware nicely. But because it is cut-down for speed a lot of modules, etc, have been removed, and in this case the 1-wire modules have been removed.
So I needed to get a solution to provide the modules in Openelec. To do this I needed to recompile it, which I didn't find the solution to very easily, so I've documented it here not just for myself but in case anyone else wants to try this. First you need the Openelec build environment, so clone their github repo:

git clone https://github.com/OpenELEC/OpenELEC.tv.git

You then do the initial build by running:

PROJECT=RPi ARCH=arm make release

And leave it (This took my server about 5 hours to complete). That gets you the same release that you're probably running now from the downloaded Openelec/official release. Now to custom the kernel, so you do:

PROJECT=RPi ARCH=arm ./scripts/unpack linux

Which then allows you to edit the kernel parameters like normal, so then running:

cd build.OpenELEC-RPi.arm-devel/linux-3.19.0

Followed by:

make menuconfig

Gets you to change kernel parameters. The changes I made were fairly simple, just:

CONFIG_W1=m
CONFIG_W1_MASTER_DS2490=m
CONFIG_W1_MASTER_DS2482=m
CONFIG_W1_MASTER_DS1WM=m
CONFIG_W1_MASTER_GPIO=m
CONFIG_W1_SLAVE_THERM=m

Adding those you can then recompile the kernel again like this:
make menuconfig
cp .config ../../projects/RPi/linux/linux.arm.confPROJECT=RPi ARCH=arm make release

And you're done. Copy the produced KERNEL and SYSTEM files (in the target folder) over to your PI in the /flash partition and boot up, should be all working at that point.

You can then connect the 1-wire sensors up and start to pull values. I'll add that to the next blog entry on how to connect the hardware and then start to retrieve the values.

(Edited: 22/05/2015 thanks to Chris Van Marle pointing out some stupid errors of mine!)

Xmas lights 2014

Well it's that time again when we all try to out do each other with flashy outdoor xmas lights. This being the first xmas in our new home I had to rethink how to put them up, and of course the wiring.
I'm still looking out for the best wire to use, I keep hoping to find thin green twin core wire, but alas I never find it to buy (appears all xmas light manufacturers know where to buy it!) so for now I'll stick to good old cat5 as it's not bad for the job, just the light grey colour isn't ideal as it's not noticeable.
The lights are my little xmas trees with lights in them, and a mini pir at their base. The idea being, feed power to the pir, take its output back to my Arduino and then control power to the lights on each tree.
The basic code is from my previous blog posts, and appears to work however I think somewhere between the rain last year, the house move and the pir being very cheap Chinese imports have decided to fair, or at least 3 out of 5 are now returning 2v on their signal line constantly instead of pulsing the 5v when motion is detected.
Tomorrow's task is to check them for short circuit, test their boards and try to fix them.
For now they're running my Arduino sequence.

Next jobs, use my multiplexer to provide more outputs from the Arduino and control even more mini trees and also maybe the other hanging lights strung around the windows and door

Problems with DHT11 Moisture sensor

I've recently been playing around with the DHT11 1-wire temperature and moisture sensor for my Arduino, and you may have seen my posts on www.hackaday.com and my old blog.

Now as an update, the DHT11 has burnt out! I was starting to get fewer and fewer readings, getting a checksum and then timeout error from the arduino code I was using. Eventually I never got any returned values, so decided to take a look. After checking all the cable runs, etc, I then added the pull-up resistor that was recommended in some locations. But unfortunately still nothing. So I decided to prise open the little blue plastic package, and the problem was quite clear:

If you look, in the lower left corner of the small coil (?) you can see the burnt parts which seemed to have made contact with the lower circuit board (where the spare leg was) and caused this burnt look. I'm not sure how or why this happened though.
My best guess is a large amount of moisture gathered, condensed and the water droplet caused the short to take place and kill the sensor.

So I've now got a replacement DHT11 and trying to work out how to safeguard the next one against damage and how to better sense the moisture in the dryer without destroying the sensor too!

Arduino Leonardo with ENC28J60

This is a very quick post, it's mainly to act as reference for me in the future!
When connecting an Arduino Leonardo up to the ENC28J60 cheapo ethernet adapter things are a little more complicated than with the other Arduino's

I've used them before with the Uno and it's straight forward. PIN conections are:

// PIN Connections (Using Arduino UNO):
//   VCC -   3.3V
//   GND -    GND
//   SCK - Pin 13
//   SO  - Pin 12
//   SI  - Pin 11
//   CS  - Pin  8

However, when you get to the Leonardo things are a little different, as the Leondardo has the ICSP header which you need to use for this connection.
The ICSP connections are:
//   MISO  VDD (+5v)
//   SCK   MOSI
//   RST   GND

So the connections are:

Pin Connections (Using Arduino Leonardo):
//   VCC -   3.3V
//   GND -    GND
//   SCK - SCK
//   SO  - MISO
//   SI  - MOSI
//   CS  - Pin  10

Then to init the library pass it the pin 10 like this:
ether.begin(sizeof Ethernet::buffer, mymac,10)

And it works! Hopefully this will help you out if you're trying to do the same, otherwise it's just handy for my ageing memory ;-)

New Blog

Hello and welcome to my new blog. I'm moving from my old geeklog blogging to this, mainly because others use it and I like the format and ease of not having to maintain it. One such feed is http://revk.www.me.uk/ who is always entertaining and good to read up on the challenges of running a DSL/ISP these days and hits upon many issues and frustrations I do too through $job

I'll hopefully import all my older blogs into this soon, but bear with me.