Over the recent bank holiday weekend we decided to plant a few vegetables in the garden. Nothing too radical, a few Onions, Peppers, Chilli and re-plant our little strawberry plant. We invested in one of those small polythene tunnels too, so help give them a bit of a boost start and see if we can get the plants happy despite the miserable cold weather we've been having. To this end I finally thought up a use for my Arduino I've had kicking around. So I started to think about a soil moisture and poly-tunnel temperature sensor type array that would feed back to the Arduino and tell us when it wanted watering, and also what the highs and lows are for temperature.

So I set about making a soil moisture sensor. My basic background in electronics helped and I knew the simplest method is to use a resistance type technique, so provide +DC to a probe, and them measure the resistance between that and a second probe. This should be easy for the Arudino as it has a few analogue inputs that I can use. The second input was temperature, so I used a temperature sensor I'd previously bought from oomlout.co.uk (TMP36) which has a nice range of -40oC up to 125oC so perfect for this. It's supplied in a standard semiconductor package so first I had to make it a little more weatherproof. Soldering up the 3 wires to a long length of cable (burglar alarm cable, which is my fave cable for general purpose as its 6-core and pretty reasonable in terms of weathering and loss of signal). I then coated each of the exposed wires with a bit of heatgun glue, followed by electricians tape round each leg, so each were electrically insulated and also hopefully sufficiently weather proofed. (Not sure how well that would survive totally exposed to the elements, but as this was going in the poly-tunnel I thought it would be fine).

Next was to build the soil moisture sensor. There are a few different ones on the net, so I went with one that seemed a common way of doing it. Set two probes (in my case 2 brass screws) in a piece of electrically non-conducting packing foam. So this lets the screws push down into the earth whilst keeping the rest of the screws insulated. At the top I then wire wrapped the alarm wire around the screws and added a few blobs of solder for good measure. A bit more electricians tape finished them off.

Here is the sensor that I came up with. You can see the TMP36 semiconductor sticking out the top, and the screw probes out the bottom.

After the probe was sorted, I ran it round outside into the poly-tunnel:

So the final part was the circuit into the Arduino, and also the code to make it function. The breadboard I had already connected to my Arduino had the LCD attached so I left that to give constant output on the Temperature and soil moisture, so all I had to add was the connections out to the remote probes. I found an interesting issue, at first the soil moisture values varied wildly, even when the probe wasn't in the soil, until I realised that this was because nothing was 'pulling' the input to ground, adding a quick resistor into the setup so that it pulled the input to 0 when it didn't have any other value sorted that out and I got values depending on the resistance being presented. At first I'd connected the soil moisture probe to +5ve and the other probe to my analogue input. One problem I'd found reported quite frequently online was about electrolysis of the metal probes (where electricity passing through them caused corrosion to take place). To counter this I moved the moisture probe to an output pin, and so I'll only switch on current to the probe when I wish to measure it, hopefully reducing the amount of electrolysis taking place.

A few iterations of code were required to get the reading showing anything sensible, and de-bouncing the inputs was essential. I found 4 iterations of the sensor read loop followed by an average calculation stopped a lot of the large fluctuations taking place and gave me what appear to be stable readings, and when compared with the temperature read-out from the car, the outdoor temperature looked around the right values. Soil moisture though is still a bit of an issue as I need to self-calibrate the sensor by checking the soil and deciding when it gets too dry to set that as the lower threshold.

I'll post the final code up here shortly as I'm still fine-tuning it, and also hopefully connecting my Arduino up so I can access the readings remotely and graph them using my rrd graphing system I use for other things around the house (heating, electricity, etc).

Here are a few images of the Arduino in its plastic (indoor) enclosure in operation. The Green LED lights up when the soil moisture drops below the triggered limit, and the Red LED lights when the readings are being taken. Debugging is also output via the serial port.

Aruino code + schematics to follow!

Update 10/May/2012 - Here is the current Arduino code I've been using, sorry about the messy code!

<pre>

// AndyB 7-may-2012 Outdoor temperature and soil moisture circuit

// ---------------------------------------------------------------

// include the library code:

#include <LiquidCrystal.h>

#include <EEPROM.h>

#include <Time.h>

#include <TimeAlarms.h>

// PINS

//   2 3 4 5 11 12 - LCD

//  9 = watering LED

// 10 = soil power pin

// 13 = Data collection LED

//  8 = LCD display light

//  6 = LCD display button light up

// initialize the library with the numbers of the interface pins

LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

int sensorPin = A0;       // Temperature sensor

int soilMoisturePin = A1; // soil moisture

int sensorValue1 = 0;

int addr = 0;

int SoilValue1 = 0;

float temperatureC = 0;

const int buttonPin = 7;     // the number of the pushbutton pin

int buttonState = 0;         // variable for reading the pushbutton status

const int ledPin =  13;      // the number of the LED pin

const int waterPin = 9;      // the LED for watering

const int soilPowerPin = 10;  // Pin to power up the soil moisture sensor

const int lcdPowerPin = 8;    // Pin to light up the LCD

const int lcdButtonPin = 6;  // Switch to light up the LCD for a few loops

int lcdlightloop=0;

int logloop = 0;

int debug = 0;  // Debug setting

void setup() {

  Serial.begin(9600);

  if (debug == 1) {Serial.println("Program initialised");};

  pinMode(ledPin, OUTPUT);  

  pinMode(buttonPin, INPUT);

  pinMode(waterPin, OUTPUT);

  pinMode(soilPowerPin, OUTPUT);

  pinMode(lcdPowerPin, OUTPUT);

  pinMode(lcdButtonPin, INPUT);

  // set up the LCD's number of columns and rows: 

  lcd.begin(16, 2);

  digitalWrite(lcdPowerPin, HIGH);

  // Print a message to the LCD.

  // lcd.print("       oC");

  // write a 0 to all 512 bytes of the EEPROM

//  for (int i = 0; i < 512; i++) {

//    EEPROM.write(i, 0);

//  };

  // do not reset the EEprom, find the last value and set the pointer, avoids power resets loosing old data

  if (debug == 1) {Serial.println("reading EEPROM");};

  for (int i = 0; i < 512; i++) {

    byte tmp_val = EEPROM.read(i);

    Serial.print("EEPROM ");

    Serial.print(i);

    Serial.print(": ");

    Serial.println(tmp_val, DEC);

    int tmp_val_int=tmp_val;

    if (tmp_val_int == 0) {

        addr=i;

        if (debug == 1) {Serial.print("EEPROM empty at ");};

        if (debug == 1) {Serial.println(i);};

        break;

    };

  };

  digitalWrite(soilPowerPin, LOW);

//  sensorValue1 = analogRead(sensorPin);

//  float voltage = sensorValue1 * 5.0;

//  voltage /= 1024.0;

//  temperatureC = (voltage - 0.5) * 100;

//  SoilValue1 = analogRead(soilMoisturePin);

//  Serial.println("Back from reading sensors");

//  logdatatoeeprom();

  if (debug == 1) {Serial.println("Setup completed");};

  // Alarm.timerRepeat(9000, logdatatoeeprom); // every 15 minutes

  // Alarm.timerRepeat(15, logdatatoeeprom);

  digitalWrite(lcdPowerPin, LOW);

}

void loop() {

  if (debug == 1) {Serial.println("Starting main loop");};

  // check the button status

  buttonState = digitalRead(buttonPin);

  if (buttonState == HIGH) {     

    // Button pressed - Reset all of the EEPROM values

    if (debug == 1) {Serial.println("Button pressed - resetting EEPROM");};

    digitalWrite(ledPin, HIGH);  

    // write a 0 to all 512 bytes of the EEPROM

    for (int i = 0; i < 512; i++) {

      EEPROM.write(i, 0);

    };

    Serial.println("EEPROM ERASED");

    addr=0;

    logdatatoeeprom();

    digitalWrite(ledPin, LOW);

  };

  // check for LCD display button

  if (digitalRead(lcdButtonPin) == HIGH) {

      // LCD button was pressed

      lcdlightloop=1;

  };

  if (lcdlightloop > 0) {

      lcdlightloop += 1;

      digitalWrite(lcdPowerPin, HIGH);

  };

  if (lcdlightloop > 20) {

    lcdlightloop=0;

    digitalWrite(lcdPowerPin, LOW);

  };

  if (debug == 1) {Serial.println("Button checks complete");};

  // set the cursor to column 0, line 1

  // (note: line 1 is the second row, since counting begins with 0):

  digitalWrite(ledPin, HIGH);

  if (debug == 1) {Serial.println("Read temp sensor");};

  // READ SENSORS HERE

  temperatureC = readinput_temp();

  SoilValue1 = readinput_soil();

  if (SoilValue1 < 40) {

    digitalWrite(waterPin, HIGH);

  } else {

    digitalWrite(waterPin, LOW);

  };

 if (debug == 1) {Serial.println("Display to LCD");};

 Serial.println("Temp: ");

 Serial.println(temperatureC);

 Serial.println("Moisture: ");

 Serial.println(SoilValue1);

  lcd.clear();

  lcd.setCursor(0,0);

  lcd.print("temp: ");

  lcd.print(temperatureC,1);

  lcd.print(" oC");

  lcd.setCursor(0,1);

  lcd.print("soil: ");

  lcd.print(SoilValue1);

if (debug == 1) {Serial.println("Done writing LCD");};

    // we write to the eeprom every 10 iterations

    logloop=logloop+1;

    if (debug == 1) {Serial.print("Testing for logloop ");};

    if (debug == 1) {Serial.println(logloop);};

      if (logloop > 9) {

        logdatatoeeprom();

        logloop = 0;

      };

  digitalWrite(ledPin, LOW);

  if (debug == 1) {Serial.println("LED off");};

  Alarm.delay(10000); // wait ten second between clock display

  if (debug == 1) {Serial.println("Delay set");};

}

void logdatatoeeprom(){

  digitalWrite(ledPin, HIGH);

  lcd.setCursor(15,1);

  lcd.print("E");

  if (debug == 1) {Serial.println("logdatatoeeprom started");};

  if (debug == 1) {Serial.print("writing to eeprom ");};

  if (debug == 1) {Serial.print(addr);};

  if (debug == 1) {Serial.print(" : ");};

  if (debug == 1) {Serial.println(temperatureC);};

  EEPROM.write(addr, temperatureC);

  if (debug == 1) {Serial.println("back from writing to eeprom");};

  digitalWrite(ledPin, LOW);

  digitalWrite(ledPin, HIGH);

  digitalWrite(ledPin, LOW);

  // advance to the next address.  there are 512 bytes in 

  // the EEPROM, so go back to 0 when we hit 512.

  addr = addr + 1;

  if (addr == 512) {

    addr = 0;

  };

  if (debug == 1) {Serial.println("end logdatatoeeprom");};

}

float readinput_temp() {

  // Read inputs and de-bounce, so read 3 times and take an average

  if (debug == 1) {Serial.println("Readinputs (Temperature) function started");};

  float temp1 = 0;

  float temp2 = 0;

  int soil1 = 0;

  int soil2 = 0;

  int lpcount=0;

  while (lpcount<6) {

    sensorValue1 = analogRead(sensorPin);

    float voltage = sensorValue1 * 5.0;

    voltage /= 1024.0;

    temp2 = (voltage - 0.5) * 100;

    temp1 += temp2;

    if (debug == 1) {Serial.print("Temp loop :");};

    if (debug == 1) {Serial.print(lpcount);};

    if (debug == 1) {Serial.print(" : ");};

    if (debug == 1) {Serial.println(temp2);};

    lpcount=lpcount+1;

  };

  temperatureC = temp1/6;

  if (debug == 1) {Serial.print("Temperature average: ");};

  if (debug == 1) {Serial.println(temperatureC);};

  if (debug == 1) {Serial.println("Exit Readinputs (Temperature)");};

return temperatureC;

};

int readinput_soil() {

  if (debug == 1) {Serial.println("Readinputs (Soil) function started");};

  // Switch power pin on for the soil sensor

  digitalWrite(soilPowerPin, HIGH);

  float temp1 = 0;

  float temp2 = 0;

  int soil1 = 0;

  int soil2 = 0;

  int lpcount=0;

  if (debug == 1) {Serial.println("Read soil moisture sensor");};

  lpcount=0;

  while (lpcount<4) {

    soil2 = analogRead(soilMoisturePin);

    soil2 = (soil2 / 2);

    soil1 += soil2;

    if (debug == 1) {Serial.print("Soil loop :");};

    if (debug == 1) {Serial.print(lpcount);};

    if (debug == 1) {Serial.print(" : ");};

    if (debug == 1) {Serial.println(soil2);};

    lpcount=lpcount+1;

  };

  SoilValue1 = soil1/4;

  if (debug == 1) {Serial.print("Soil average: ");};

  if (debug == 1) {Serial.println(SoilValue1);};

  digitalWrite(soilPowerPin, LOW);

  if (debug == 1) {Serial.println("Exit Readinputs (Soil)");};

return SoilValue1;

}

</pre>

 ----------------------------------------------------------------------------------

Update: Tuesday 15th May 2012

I'm now graphing the output as I've hooked the Arduino up to a laptop via USB, below are the graphs (updated every hour):

 I thought it was about time I wrote a bit more about what I've been up to with our TV setup at home. Firstly a bit of background, take a look at the previous posts on my XBMC setup, but that is now a bit out of date as I've found this isn't a set and forget sort of setup, so I can see why a lot of people won't bother with this day-to-day. But I'm persistant and wanted to get my setup as good as possible so we've got the best of several options.

Firstly FreeSat with the superior HD channels, then Freeview (via Aerial) as this still has some channels not on FreeSat, then PVR functionality for pause/rewind of live tv, finally playback from the network media drive. In addition I've also got a want to stream iPlayer, ITV, 4od and 5 via their online stream facilities.

So originally I had TVHeadend running (via their git repository) with a custom patch for adapter priorities. That patch allows me to 'weight' which adapter I want to be used, so the rule was, use the Freesat adapters, unless the channel wasn't available (or signal was too low). This worked great, but there are problems with the integration to XBMC (The frontend). The biggest problem was that the PVR functionality of pause/rewind didn't work, and the author of TVHeadend/XBMC PVR plug-in really doesn't have any interest in developing this as he has no need for it. That causes me a bit of a headache, as that component lets the system down quite a bit. There are also problems with TVHeadend in that it relies on XMLTV to grab TV listings, as the EIT grabber (Over the air/satellite) barely works at all, and again nobody can see to improve that at the moment. So these two items let it down quite a bit as it means we get dodgy entries in our TV Guide, so its not reliable, and we can't pause. Another huge bug, and I believe this is an XBMC problem, is that if a channel doesn't have an EPG entry, or the entry is deemed as 'invalid' by XBMC it actually hides the channel. Now this causes channels to disappear and re-appear due to bad EPG data, this is something I've asked numerous times on the forums on how to correct myself in the code and re-compile but nobody seemed to know the definitive answer, or didn't want to help. This also frustrated me!

So I thought, time to move to MythTV using XBMC as the front-end. Myth does have pause/rewind functions, has EIT working fully and a few other nice things so this seemed a good option to switch to. Installing Myth-backend is a pain as although they have debian/ubuntu packages, you have to guess which ones you need to run the backend (mythtv-backend, mythtv-web and a few others). Once installed onto my headless server that has my 2 FreeSat and 1 Freeview cards in it I needed to set it up. Here was the first problem, its a GUI that you run within an Xserver (a desktop). This is a headless server so I can't do that, so have to run it over an X forwarder to my laptop, so its a bit laggy but works. The mythtv-setup is HORRIBLE! It's clunky, and looks like its been designed to be used from a TV remote, but even that it would be horrible to use, so I didn't have a good experience there. The logic of channels, channel inputs, hardware adapters and channels is also a little confusing. So you first setup your capture card, thats pretty straight forward, the system finds my 3, you have to setup Diseqc and tell it just to use an LNB (even for the Freeview) which is weird as it seems to be a requirement rather than an option. Once they're all setup you have to create a video source. This is straight forward as I want to use EIT, so select that, and thats done. Now the bit that I've still not fully got my head around, Input Connections. You set these to match your channels, so on mine I've created 2, one for FreeSat and one for Freeview (I have no idea if this is right, as it doesn't seem 100% correct!), so I went in, scanned for FreeSat DVB-S first (this takes about 10 minutes), then for DVB-S2 (another 10 minutes). Then create another Input Connection for Freeview, and scan for channels on there (About 10 minutes again). Wow that takes a long time! Now you can go into channel listings. This is mostly pointless, as the interface is so unusable you have about 200 entries in a list and it expects you to click into them one-by-one and disable the ones you don't want, correct incorrect text, etc. I would be on forever with that, so opted to leave that as it is for now and just have a stupid number of channels visible. At this point you can save and exit.

Now you need to compile cmyth with XBMC. cmyth is a fork of XBMC as the developer has re-written some parts of XBMC to handle the Myth setup correctly. So I grabbed his sources and started compiling, hitting many incompatability problems along the way as debian packages were missing, I was running an old version of Ubuntu, so had to upgrade the distribution first. That took longer than I hoped, and if you do a custom compile, don't forget to put your ./configure command options in to make all your add-ons work. My line ended up as './configure --prefix=/usr --enable-vdpau --enable-static --disable-shared --enable-sdl --enable-rtmp' Doing this, a make and install got us up and running and I could see the EPG loading. Going in however I had about 10 BBC1's, 10 BBC2, etc. Basically what it had done is found each copy of the channel on the FreeSat devices, Freeview channels and just put each one into the listing, it didn't merge any! So that meant back to the MythTV listing setup (Also each time you go into myth-setup you have to shutdown the daemon, which disconnects all clients stopping TV from working again!). I tried again but found the channel editor impossible. Luckily I spotted the MythWeb add-on, went into that and found you can edit the channels through the web interface, so I went through removing channels I didnt want. But what to do about the duplicate BBC1? A bit more reading revealed that you should give these the same channel number. So find all the BBC1's in your listing and set them to a channel number (e.g. I used 101 to mirror the Sky numbering system). I've done that and sure enough it looks much better.

The main problems I have now (and not solved):

• EPG loading time in XBMC is very slow. It can be up to 5 minutes and its not a good idea so start watching TV till this is finished as if you do that it seems to corrupt a lot of EPG entries. This is a pain as we all have to sit watching a loading bar before we watch TV now!
• After selecting a channel, it takes almost a minute before the channel engages and starts streaming
• Pressing anything like EPG, pause, etc, also freezes the playback for a few seconds as the box 'thinks'
• Channels without proper EPG still don't appear in the EPG line-up, so again this is a big problem!

So after all of these, I'm unsure if I should revert back to TVHeadend, as there are a few too many bugs and problems that are frustrating, and I'm not sure if the gains (Pause TV) is enough to warrant it. I may re-do all of it over the weekend back to TVHeadend and see if I can correct the few bugs remaining there myself!

Firstly, what is FTTC, Fibre To The Cabinet is a service that BT is rolling out throughout the UK to provide stable, fast broadband to home users without requiring additional equipment to the customer premises (* ignoring BT VDSL modems). The service to the client premises is still delivered over the standard copper pairs used for PSTN provision, in the same way ADSL and ADSL2+ are, and it uses the same basic technology of frequency shift to 'shift' the data bits into a higher frequency range. The separation of this at customer premises takes place within the BT master socket, which is replaced during the installation of FTTC by a BT engineer. At the other end of your line things change quite dramatically.

In ADSL/ADSL2+ the BT copper pairs go from your master socket to a junction box in the street (the street cab), this then can pass through other street cabs/junction boxes (as mine did) and then eventually ends back in a BT exchange on a Main Distribution Frame (MDF). From here your line goes into an ADSL line card which is part of the DSLAM and provides the mo-dem part (modulation, de-modulation). This then turns into a 'regular' ethernet-like connection and will be fed back to BT Wholesale via their fibre connections to the exchange.

In FTTC the street cabinet is upgraded and takes a fibre connection from the exchange. The street cabinet then has the fibre-to-copper hardware inside it and this then uses the copper pairs to your premises to transmit the broadband. This reduces the distance the copper pairs are transmitting the data signal, and therefore provides much higher quality and therefore potential speeds. It is this key change that provides the improvements to the broadband provision, stabilises the connection and generally offers a higher quality service. The downside is that BT have to 'blow' fibre to the street cabinets, and upgrade the cabinets to support the active (i.e. powered) equipment to do the work (which was previously in the exchange).

The actual install to the end-user is pretty painless (your mileage may vary!). In my instance my current ADSL2+ service dropped around 20-30 minutes into the engineer visit window that had been scheduled (BT engineer had phoned confirming his attendance at the alloted time), and shortly afterwards he turned up to change the faceplate and do his work. The install was pretty quick. Removal of the existing BT master socket. Installation of the new socket. Connection of test equipment the BT engineer could then verify the signal quality and the potential speed of the circuit. Then installation of the BT supplied VDSL modem, and finally checking that I could authenticate over PPPOE.

The new installed BT master socket with integrated VDSL socket:

 Top socket is the VDSL socket, and the one parallel to the screws is for your PSTN phone (Which I don't use)

This is a snap of the tester the BT engineer uses, it shows the line sync and status on there and gives you your first indication of what your speeds should be like, etc.

This is the BT Openreach modem that the BT engineer supplies and for now is required to be installed. This isn't a router or anything smart, its a very simple modem, the LAN1 port presents a PPPOE connection for you to handle authentication, etc, to your ISP. All other ports are blocked off and not in use on the device.

Note this is the newer BT VDSL modem that is now being supplied in most installations. Earlier models were common to overheating, and had also had their firmware cracked open so the average user could log into them and view line stats, tinker about, etc. BT therefore started to replace their shipped/installed modem (generally cited as due to the overheating fault). Also note that most installs BT will attach this modem to a wall to help with cooling/circulation. You generally should NOT run it sitting on a carpet like you see in my pic! But as you can see its not powered on in the pic. The unit does get warm pretty quickly so beware of this!

An attempt at a close-up of the sockets:

My phone didn't do a very good job of this picture. Basically the ports are: DSL in, LAN1, LAN2 (blocked off), RESET, BBU (blocked off).

You would then plug your router in supplied by your ISP into the LAN1 port and wait for it to auth up.

Since I like to tinker, I went a little further and have removed the BT modem and installed my own, this allows me to view line stats, and generally have a closer view of what is going on over the VDSL connection. I'm using the vigor 2750n which I've found to be a very capable little router. Setup is a little more in-depth than defaults so here are the settings you'll need if you're doing the same.

Firstly, firmware update. I'm running 1.5.2_Beta so you need that or newer (Older ones don't always sync up correctly and will sit with their DSL light flashing constantly).

Then go through the Quick Start Wizard, this steps you through the usual stuff. When it comes to WAN, DO NOT CHOOSE DHCP (This is a little confusing), you want to choose PPPOE, as it will then give you the chance to put in your login and password provided from your ISP.

You then need to login to the web interface again, choose WAN and Multi-VLAN. In here you need to enable Multi-VLAN setup and in the WAN VLAN ID box put in 101. This is a BT wholesale FTTC setting, so I can only comment on this install. You might need something different if you are with a LLU or other provider.

Save it all up and you're good to go. By default the Vigor will do NAT, DHCP and all the other usual stuff. In my case I get a /30 allocated and run a server behind my connection so I want to remove NAT and do routing. This is pretty straight forward on this router too, just go into LAN and General Setup, and in the "For IP Routing" enable that and enter in your public IP address allocated by your ISP along with your subnet mask. Disable DHCP (not needed) and save that. This will then setup your router to route! One thing to bear in mind though, the router will still answer on 192.168.1.1 on the LAN and will still do NAT for this range, you can tweak this and lock this down further in the setup but most Vigor docs recommend against this for some reason.

I hope this has helped you setup FTTC or at least given a bit more info. If you've got any questions feel free to comment/drop me an email.

  As some of you may know, a long time ago I had a need to block persistant password attackers from various servers I managed (Working for a relatively large domain hosting company at the time), and because iptables didn't exist, ipchains wasn't everywhere I wondered what to do. I was learning Perl primarily through automating jobs at my job, and so I decided to write a little script that would 'watch' certain logfiles for attempts at gaining entry via repeated password or dictionary attacks. If the attack tried several attempts within a certain time-period, and from the same source IP, then flag it up, alert and then block using one of a few techniques. Not fool-proof, not perfect but it did the job.

Perl had a handy module called File::Tail that does exactly the same (sort of) as doing a tail -f /var/log/blah in the linux shell, so just run that in a script, watch for certain patterns and act accordingly. At the time the blocking action was either add an ipchains block rule, or add a route entry pushing the offender to the loopback interface. OK so this wasn't going to stop them DOS'ing us, etc, but it kinda did the job, and at the time internet connections weren't huge, if I remember rightly we had a 4Mb line or something like that, that was for a large domain hosting company, none of this 50Mb to the home, fibre or gigabit connections! So it did the job nicely.

Well, I started to install it on more and more servers that I looked after, or helped to look after, people asked about the script and slowly I started to pass it around, just by email at first. So I then decided to package it up and distribute it. My first bit of 'freeware'/GPL software was born! The software existed quite some time before it, but the official publication date was 5/5/2005 as that was when the package was created, however the release date that you'll see most other places was 27/7/2005 as that was the date that I released it on sourceforge.net

The original code is still up there, but don't look! It's horrible perl code, badly written, but it does the job!

Just looking on sourceforge.net at the site http://breakinguard.sourceforge.net/ you'll also see very poor HTML design (something I can still never shake off, my design eye is terrible!) The release up there now is dated 08/01/2008 version 0.11 and hasn't changed a great deal since the original to be honest, a few filters and a few nicer tweaks and thats about it! I belive it is still used in some places, but to be honest its had its day.

Now, a lot of people would use simple iptables, as you can do the same natively such as:

</p>
<p>iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set</p>
<p>iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP</p>
<p>

Which does the same thing really, so I think my software is dead or dying! If you do still use it, do pop a comment on or a mention as I'd appreciate it. Unfortunately I doubt I'll be doing any further updates to it, but will keep it live just for historic reasons rather than anything else!

 So recently I've been noticing that the heating in the house is on what seems like a lot of time, the radiators aren't always as hot as I'd expect and generally the house is a bit chilly. Now this is during the coldest time of year where I live in the UK, so temperatures outside are dropping to 1 or 2oC overnight and during the mornings not getting far beyond that. With everyone in the house out during the day I'm unsure what it goes to during this time, but on evenings/overnight is when we notice it. So I started to watch how the heating was setup and then started tinkering!

We use a gas-fired central boiler (not combi), that has timed on/off schedules for heating and hot water. The hot water/heating switch is done by changing the valve setting from the pump circulation (i.e. when hot water is set to on it will divert some/all of the heating hot water circulation into the hot water tank). So my first observation is that when heating and hot water are on at the same time then surely this will halve the efficiency of doing one or the other jobs quickly.

Radiators in each of the rooms, the majority have TRV (Thermostatic Radiator Valve)'s fitted on them, and have a 0-6 scale for setting the desired temperature. Most of these are set to maximum all the time. Only two radiators do not have TRV's, these are both in the living room/dining room (It's one large area, no partition walls, etc). This is also where the temperature room thermostat is located.

There is a single room thermostat in the dining room, this is a digital/electronic temperature sensor running off two AAA batteries (annoying when they run out), that switches the heating circulation on and off depending on the ambient temperature.

The other little niggle is that the house is quite open-plan. The downstairs is a large living room/dining room, open to the staircase, and obviously up to the upstairs landing. Therefore the majority of heat (in my limited knowledge) will escape straight upstairs to the top of the stairs! Not ideal.

So, my first steps were to change the heating programmer, to get different on/off times for the heating and hot water cycles, and to prioritise heating by only switching hot water on after I've giving the heating a chance to warm the place up. So I opted for 3 on/off sequences during the day. First one for when we get up on a morning, on 5am-8am heating only. Then for when we get home, 3am-9pm. Then one to keep the chill off at 10pm-11pm. I went for hot water going on once daily from 4pm-8pm. So that seems to keep the heating happily running and not letting the house get too cold, as I think that was an initial problem, the house dipping way too cold, so taking the heating too long to warm back up.

The room thermostat was then set to 20.5oC as that seemed a reasonable temperature that is warm but not boiling. This I think might not be helping things, as I think this might need to be higher, but more on that later.

I then attacked the radiators and the TRV's, as I know I had one of these fail in the kitchen and jam closed, so that TRV was removed, so that radiator is just on full all the time. A few of the radiators needed bleeding, so did that for a few days to make sure we didn't have any problems with air in the system. I then turned ALL TRV's down so they weren't sitting on maximum. This was because a few websites I had read stated that running a TRV at maximum is bad for the valve and heating system (can't find the quote to cite now, if you know please comment/post back!). Then went round each of the rooms and changed the TRV depending on if the room should be hot/warm/cold, the majority of bedrooms I set on 5 (one off maximum), bathrooms a little below that and thought I'd leave it at that.

Unfortunately the heating still wasn't really doing what I wanted, the children were complaining of a cold bedroom during the night/morning, our master bedroom got red-hot at night and early mornings, and the rest of the house was warm! So that didn't quite work it seems. My next discovery were the next generation of programmable TRV's. These you can set times/dates and temperatures and the unit will vary that individual radiator based on this. I thought this would be ideal for the master bedroom, as during the day/early evening it was pointlessly heating the room. So I purchased a programmable TRV from a heating/electronics firm in the UK (I'm not going to name them here, as I found their service SHOCKING, it took 2 devices and me piecing the working parts from the two together to get a single working TRV. Not impressed!).

I ordered "Radio energy-saver regulator" which is a german-manufactured device that simply plugs into your standard TRV fitting, so no draining the system, etc, just unscrew the old TRV top off and this on. You program it either via its LCD screen, or you can also use the USB computer programmer, which I chose. You then set what time-periods to use, temperatures and set it going. This has made a huge difference to the master bedroom, although some further tweaks to the schedule are needed as at the moment its like living in the antarctic! But that could also be due to the overall heating turning off too soon. Obviously the TRV will only heat the radiator up when three conditions are now met. The main heating timer is on, the downstairs thermostat is set to heat and the programmable TRV decides that its schedule and room temperature say it needs to heat. Unfortunately it has no control over the first two conditions, so therefore if the sequences aren't matched, then this fails, and I suspect this is where I'm going wrong at the moment. I'm setting the TRV schedule to warm the room before we retire to the bedroom, but at this time the rest of the house is warm enough, so the thermostat on the heating has cut out, so although our TRV wants to heat the room, it can't as the heating isn't firing. So more tweaking is needed here!

And thats about where I'm up to. I need to do some more tweaking with programs and temperatures to get things right, but I'm happy that I have much more control and I believe I can see where the problems are on the system now!

When I bought the Chrysler about 11 months ago, I shortly after bought a rear parking sensor kit with colour-matched sensors, thinking that I'd need it in such a big car. Well, its actually not a bad car to drive and park, but I'm still pretty bad at judging distances, so I had a good few hours spare this afternoon, the kids out, etc, so thought I'd give it a go and document what I did along with photos.

The first stage that I had to do was work out how everything would fit together, where it would position best and follow the instructions for positioning the sensors. The kit itself was straight forward, it had 4 sensors with removable connectors, then several lengths of labelled cable (labelled A, B, C, D), a control box and small display. This is the control box and display that came with mine:

So, the thing that I thought would be best, would be to get all of the sensors and somehow attach them to the bumper, see if my calculations looked correct before I drilled my precious bumper (That bit REALLY scared me, as if that went wrong, its time to buy a new bumper!). So I tried a few different ways of temporarily fastening them, all failing because the back of the sensor had the cable fitted directly to it, no flushed mount cables or anything like that,  so trying to attach it to a flat surface didn't really work. So, I then realised, the box that they came in had a plastic packaging tray, that if I cut up would work perfectly! Who said I didn't have good ideas sometimes ;-) So I fasioned that up and attached them with simple double-sided tape:

As you can see, the sensor dangling, and my make-shift mounting bracket. Looks classy!

So, I fitted them all on like that to see what positions, etc looked ok, and it didn't look too bad:

So after that quick test, I powered it up using an old 12v battery I had lying about (Old burglar alarm batteries are good for this, I used a battery I'd removed from an APC UPS recently. When you do this though, check the voltage with your multi-meter first as they don't label what voltage they run at. Make sure its 12v!).

So a quick power-on showed the sensors all working, and the distance was showing up with 0.5 which I assumed was correct as I was reversed up against my garage. One thing I did notice however is that the sensors slightly pointed downwards, which may be a problem, so something to watch for otherwise I'd guess it would generate erroneous results.

I then thought that the testing had worked fine, so time to go for broke, and work out how to remove the bumper. As this is a big American car, generally its put together pretty easily, and I'm glad to say the bumper was quite simple to remove. Firstly you open the boot, then inside the wheel-arch you'll find 3 screws, this poses a problem, the screws are around 2inches away from the rear tyre, so no screwdriver I had would fit. But improvisation, this is where a small screwdriver attachment (the ones you put on drills to electric drivers) and a spanner, grab the attachment in the jaws and you can manage to slowly remove the screws. Once all three are out, move round to the inside of the boot, and you'll see a single screw diagnoally down from the light cluster. Move to the opposite side and repeat this process. That's all the main screws undone, now for the REALLY tricky ones, underneath there are 4 push-clips. I took a picture of these as they are probably the most challenging part of the operation!

The way I managed to remove these, was firstly to use a flat-headed screwdriver to start to prise the clip out (push between the black clip and the silver bumper). Then as it starts to give, use the screwdriver to lever it, then finally finish by pulling it very hard with your hands. It's about the force you think you'd need to break/snap it! But it eventually pops out. The clip is just made of a load of ridges, so it just grabs all the time, I couldn't see a simpler way of removing them, and mine survived so hopefully thats all there is to it! Once those four were out, the bumper could be removed by returning to one of the wheel arches, and gently prising the bumper away from the bodywork (you'll notice the ridge), once that's removed go to the other side and remove that, then pick up the whole bumper and it will come away easily.

Here I've removed the bumper, and you can see the slightly odd site I found behind it, this is a polystyrene cover over the metal girder that is the main bumper, not what I'd expected but this looked like it might prove a problem. The problem was that the polystyrene would be right in the way of the sensors. Since I couldn't think of a solution I bashed on, and thought that I'd be able to solve this later.

I then used the drill-bit that was supplied to drill the holes where I'd measured. This worked fine, so I then fitted the sensors in, and they looked pretty neat!

So once this was all fitted, where to run the cables. I assumed that there must be a way of feeding the cables for a tow-bar into the inside cabin of the car, so looking around underneath I spotted a rubber plug right in the middle of the car. To find where this went, inside the car I took off the plastic cover that runs along the back (this has the load to this line note on it), this is held on with pop-clips again so just gentle prising let this come up easily. WORD OF CAUTION - Somehow when I did this originally there are two plastic clips at either side that fit the plastic cover onto the rest of the body panels, one of these were snapped/squashed when I removed the cover, I assume this was when I removed it, so be careful when you remove that cover, the sides need to be taken apart carefully!

Once off you could see the rubber bung under the carpet in the boot, so remove the bung and feed the cables in using a small hole to secure it all. It was easier to drop the spare tyre at this point so it was easier to work underneath the car. Feed the cables in, and I decided to hide the small control box inside the jack storage.

Next problem, wiring harness for the reverse lights (This unit is easier to wire straight into the reverse lights, so that it turns on when the car was in reverse), now myself and several others owners had talked about towing and where the tow-cables went, etc. It seems this is a bit of a mystery on these cars, as they all have slightly different wiring methods, where the wiring bundles are, etc. Now whilst taking panels apart, I took apart the plastic trim on the left hand side of the car and found the main wiring loom, and also a large plastic box with most of cables feeding into. Since I couldn't prise the plastic trim any further (I'd removed both screws and popped several clips, but I suspect because of the electric/motor power boot open/close that I wouldn't be able to fully remove the plastic panel without taking apart more mechanics of the car). I gave up trying to look into the electronics box, maybe something to do at a future date as I'm now curious what this is and what it does. So I went for plan B, basically testing which cables carried voltage when the reverse lights were on, and just splice into those. Easily done with the multi-meter, and wired in. Interestingly I also did a web search on wiring tow-bar wiring for these cars, and most of them do a similar job, they simply provide a connector socket and plug, you unplug the lights cluster from the rear lights, plug the cable into the tow-bar loom, and then plug back into the lights (so a man-in-the-middle type wiring). Power to the lights worked fine, and the unit came on no problem at all.

Re-attaching the bumper was simple, just hold the bumper back in place, clip around on the left and right inside the wheel-arch then re-attach the screws. Simple!

The whole job took around 3 hours with breaks, so not a particularly tricky one, and hopefully a few tips here will help out if you need to remove the bumper or do anything at the back of your Grand Voyager

 Well, as some of you have been following I've been puzzling and wondering how/why I've had 'hacks' from twitter, and whats going on over there as I suspect the hacks are a little deeper than just my account.

Over the weekend I noticed one of my friends had got hacked and a similar message to mine appeared in their timeline. Out of interest, their twitter name starts with D, so I'm still suspecting this 'hack' is working its way through the alphabet, will be intersting to watch that.

Anyway, this persons timeline showed on mine and my partners list as she had mentioned it to me originally, so I let the person know to change their password and check it out. After 15 minutes they managed to get online and check, and the post had gone, all by itself. It still showed on my cached timeline, but as soon as I refreshed it disappeared.

Now to me there is only one explanation why/how it could have appeared and disappeared by itself. That its twitter itself that has an exploit/vulnerability that somebody somewhere is exploiting, and twitter know about it, cannot patch/fix it (for whatever reason) and have a clean-up routine that goes around 'fixing' the problem by deleting the posts. Now this is ALL assumption and guess-work, but to me its the most plausible reason at present.

So I'm still watching my timelines, watching to see if that application gets automatically added to my approved application lists again and see what happens. If you get/see anything similar in your timeline, or anyone you follow please do get in touch with me, as I'd like to collate/compile the findings.

 As I continue to use the TVHeadend and XBMC setup I'm starting to find the odd little problem crop up. Most of these are pretty minor and can fix them as I go along (Pause live TV still a major missing element to this, and not one that looks like it'll be sorted soon unfortunately). One such minor issue I found was when setting up hardware adapters that can provide the same channels.

I have two DVB-S cards (Satellite, from my original quad-LNB) and one DVB-T (Terrestrial from the aerial installed in my loft). Now for whatever reason the DVB-S signal/channels show up as much better quality than the DVB-T (Not knowing the technologies, this may be expected due to available bandwidth on the MUXES, or whatever). So if I tune to BBC1 on my DVB-T its worse quality than on the DVB-S. The problem is that the DVB-T card seems to give out a signal quality of 100% all of the time, and the DVB-S can vary depending on weather conditions, etc. So TVHeadend was wanting to use the DVB-T card, and hence we got worse quality pictures.

I noticed in the TVHeadend issue tracker a request to be able to prioritise tuners, which sounds ideal. Basically in a nutshell somebody has modified the code so that you can force in a priority, to add "distance" (Using cisco/network terminology) to the adapter, and so make it less preferable for tuning. Martin Mrvka kindly produced the patch for his code modification so I could download and test it, and so far it looks good.

I've added a distance of 50 to my DVB-T card, and left everything else on defaults. So far it looks to have worked, however I've not fully tested it, so will do so over the next couple of days and see how it goes. Anyone else interested in this can get the patch from: https://www.lonelycoder.com/redmine/issues/343

Don't forget to post back and let him/me know how the patch works, see if it does the job for you too!

 So, I got another reply from Twitter in relation to my complaint that they're not really reading my replies, and I have actually got somebody who seems to understand what I'm after, but not quite in the context of "There is something wrong, please investigate". Here's the reply I've got:

"

@Kessel about 18 hours ago

Dear Twitter User:

If you are requesting your own Twitter account information, please fax us a signed request providing consent to disclosure for specific information (e.g., IP logs), including the username (e.g., @Safety and http://twitter.com/safety) and email address on the account, along with a scanned copy of your valid, government-issued photo ID to 1-415-222-9958.

We will send a request-for-consent email to the email address of record for the account, to which you will have to respond affirmatively. Receipt of an appropriate request and an affirmative response to the request-for-consent email will authorize us to release your information.

Regards, "