Thursday 12 March 2015

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.

Wednesday 4 March 2015

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

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:
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!)