Friday, 22 July 2016

Fencing and outdoor stuff

Well over the past few weeks myself and my dad have been working on the fence at the back of the house. It's been a while in coming, over 2 years ago we bought this house from the developers and there wasn't a dividing fence between us and one of our neighbours (Just a few posts and rails to show the marker) and so this summer I decided it really was about time to get a bit of privacy and security to the house.
I'd kind of planned on how much it was going to cost us, pricing up timber, screws, etc, and it wasn't a cheap amount, the area was quite large to cover and especially as I wanted to 'cover' more of the other areas.

It's probably easier to show a before photo to explain what I was doing:

Along the left was the original fence post and rails put in do divide between us and the neighbours. Then along the back was this half wall half fence (Those neighbours path was at the brick height, so when walking along they were clearly visible) which the gaps inbetween the panels.
This was another thing I wanted to tackle, I wanted to block out the gaps, so decided to 'back' panel these fences and completely cover using my own fencing material the gaps.
So the job involved putting new posts in along the left (Quite easy, long fence posts, some postcrete that you just pour in dry into the hole and fill with water) and then create and attach the rails. Getting the height and position of the rails took a little work, then each of the wooden panels needed cutting and fitting to the right height.
The rear 'back' panel covers weren't too bad, just cut to the right height and then pushing them so they sit snugly.

Here's an in-progress shot:
As you can see the back panels are all in and covering nicely with my own fencing. The left posts and initial rails were in place (the two supports were just whilst the postcrete set fully).

We've now put in most of the panels on the left fence and just have the final parts of the posts and rails to continue down the side of the house.
After all of that, we then need to paint them as we want a slightly darker wood stain colouring on them, so plenty of tubs and paint brushes will be needed soon!

All in all, a lot of work, but I'm pleased with the effort and again much more satisfied doing the job ourselves than getting somebody else in to do it. It is true, DIY becomes a bit of a hobby and something I look forward to doing now.

Friday, 3 June 2016

maildrop and postfix

This is quite a short entry, it's mainly to help out anybody that needs to debug the same as me, as it took me a while to find the right information online.
If you're using postfix, and use maildrop you probably also use mailfilter rules to move your mail into the relevant folders on IMAP for you. Well if things don't go where you expect, or don't seem to drop into the folders you need to debug. Telling maildrop to debug and what to look for isn't exactly intuitive.
I'm using postfix, maildrop and ispconfig, so your config may be a little different, but the debugging should be the same. In your postfix you should have your maildrop line, something like:
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d vmail ${extension} ${recipient} ${user} ${nexthop} ${sender}
Which puts it into delivery mode with user vmail. So in your /home/vmail (or whatever user folder it's set to) will be your .mailfilter generic file. It's in here you can setup the logging location:
logfile "/tmp/maildrop.log"
Seemed to work nicely for me, it was only a temporary log I wanted to look at. No need to restart postfix as it's called on the fly. Reading that file you'll see something like:
Date: Fri Jun  3 20:10:51 2016
From: Homebase <>
Subj: Be BBQ ready
File: /home/mydomain/myuser/.                                (154696)
Which in this case shows the email was dropped into the default inbox folder. If it was filtered into an alternative folder you'd see:
Date: Fri Jun  3 20:10:51 2016
From: Homebase <>
Subj: Be BBQ ready
File: /home/mydomain/myuser/./SOMEFOLDER/                                (154696)
Or similar to that. Easy!
Also if you want to log bits in the filter itself, open up the .mailfilter for your user account, and add in lines like:
log "== some log words =="
And that will literally log that to the file. Good to check your if conditions are working or to dump out some temporary fields.

That's it really!

Wednesday, 1 June 2016

Home improvement - painting and such like

I'm opening up a blog post for a slightly unusual topic. Decorating. We're planning on finally getting round to decorating our house (It was a new build 2yrs ago, so everywhere is builders magnolia that's as thin as skimmed milk) and so the choices of what to do, where and how are all starting to bubble up between me and my wife. (We've not even asked the kids yet, as who knows how many more options and choices that will open up!)
So, the main choices we're trying to come up with are:

  • Where to start - What room should we try first!
  • What to do - painting, a bit of wall art, wallpaper
  • How to do it - Tips and tricks on making it easy (!) and the right way to do things.
So I'm also after comments too, so feel free to let me know tips or tricks or any suggestions you have on how we should do this to give a good result.
My thinking so far:
Where to start - Probably our master bedroom, it's at the top of the house with adjoining en-suite and has low ceilings and strange angles/corners (It's built into the roofspace of the house). Initial thinking is just to paint, but for a bedroom what colours to go for. Light colours would make sense, it's not got a huge window so increasing the room light by paint would be better (No dark oaky types), our furniture is also light wood colours so keeping it light. Light grey colours with a feature wall with extra colour seem to be an idea that keeps coming into my head, because of the strange shapes of the ceiling though not sure how you would approach this. Other colours such as light pastel colours would maybe be an option?
What to do - I think wallpaper is discounted, as I hate the stuff, hate putting it up and removing it, so I reckon this one isn't going to be an option. Wall art, possibly, we did this in the children rooms and it looks really good, but not sure it would fit with what we want for our bedroom.
How to do it - This is the thing. I've never been a great painter or decorator, so I just do what I think is right. Go and buy a load of masking tape, and mask along the skirting board, and along the ceiling, around light fittings and electrical sockets. Then get a roller, slop some paint in the tray and roller away, trying to keep it even. Do you keep the strokes up and down or side to side? How thick do you apply the paint? And when I get to the fiddly bits and get a paint brush, how do you make it look the same, brush strokes always look different and it looks like you've 'highlighted' the socket you've painted around since the brush strokes stick out more! This is the bit that I always struggle with! So this is the part that needs the most input from those that know better, so I'm hoping somebody hears my struggle and tells me the right thing to do!

I look forward to comments or suggestions :-)

Tuesday, 3 May 2016

Another follow up to Marmitek/Haibrain SC9000 PSU (PS90U) failure

Here we go again, I've had another SC9000 power supply failure. For those that have been following my blog before you'll know I use an SC9000 X10 alarm system, and last year the power supply PS90U failed on it.
The power supply fails in an odd way, it still provides power to the alarm system, so everything appears fine, however when it fails it stops sending or receiving X10 commands, which is critical as the X10 commands trigger the siren/sounders and show the alarm as triggered.
I noticed that the timed lights weren't coming on and off when they are supposed to. These are controlled by the timer light functions on the SC9000, and so this made me suspect it yet again.

Sure enough, checking the PSU out, I found it wasn't sending/receiving the X10 commands through it. So time to check what's wrong.
Firstly. This is the 2nd unit I've had to purchase. The first failed in the same way, and now this one, less than one year since I bought it (Purchased 04/06/2016, failed 17/04/2016). So these units really aren't reliable. Originally I thought this was due to heat and so put heat vents in this PSU last year, however it looks like this hasn't helped.

Opening the unit up, again it has the stench of burnt electronics. They are comprised of a large transformer, some mains filter circuitry (and DC step-down) and then the X10 circuitry.

The first photo shows the transformer and the mains side of the circuit. You can see to the lower part of the board the discolouration of the circuit board, which is where the transformer sits, so the transformer obviously runs hot.

After stripping away some plastic covers/heatshrink, I revealed a glass fuse (I was expecting a resistor that was being 'used' as a resistor). Other components on there such as the capacitors, etc, looked OK, they weren't bulging and putting the meter on them showed the 'correct' resistance rising up to infinity, so they appeared OK.
The larger yellow component (visible in the photo) MPX275-X2 is a surge AC capacitor, small blue circle (to the right of the first photo) 
Various transistors are there 2SC667 which is an NPN transistor used for switching high current from a low current source (So most likely output from the chips on board)

Anyway, after various tests, none of the components appeared to have failed, which was odd. So I then started probing parts of the board for continuity, thinking heat may have fractured a trace. I wasn't getting much continuity from the mains leads (red and black in the photo) to anywhere, and then I tested the fuse. It was open circuit, so it had blown. It's a small 250mA 250v fuse, so a very small value.
Following the wiring of it, I realised that the mains wires (red and black) come in, directly connect to the two brown wires (to power the transformer) but then go through a fuse, choke, etc, and into the circuitry. So the transformer IS NOT protected by the fuse, but the small electronics ARE! How strange. So what was happening was the transformer was still working and stepping down/providing the low voltage to power the SC9000 alarm, but the fuse had blown and so the X10 circuitry in the PSU weren't getting any power. Hence the failure mode of these units, when they fail I suspect that is always the weak point, but rather than stop the whole thing working (A much better failure mode to me, in that you'll know it's failed. Rather than waiting until you need the alarm, and it not sounding!).

I did a small test, I bridged the fuse with a replacement, and hey presto, it started working. Now why the fuse failed I'm unsure, it was a very small current (250mA) which makes me think even a small electrical surge would cause it (The fuse was directly on the mains input, not after the smoothing capacitors, etc) so that's what I'm thinking. Especially as I've found that this does seem vulnerable to electrical surges.

So a quick replacement fuse and it's working again. But for how long?!

PIR Motion sensor circuit for kitchen lighting

A quick and simple little circuit but hopefully will help others out who want to achieve this. This is a little circuit I've knocked together for a friend.
The idea, he has LED downlight strips that are powered from a 5-12v DC supply. To add a clever touch to it, he'd like it when somebody walks into the kitchen the downlighters will come on and stay on whilst there is still movement (and after a delay) switch themselves off again.
* PIR sensor, from ebay which is around £3
* RELAY, from ebay again around £3-5
* BC547B NPN transistor (NOT gate), ebay around £1
* 10k resistor
* 1k resistor
* wires, casing and connectors

The circuit is very simple and will work like this. The PIR is supplied with power from the power supply constantly. When it senses movement it triggers it's middle pin and drives it LOW. (No movement and it drives it to 5v). So we connect the NPN base through the 10k resistor to the PIR signal output. Connect the collector via a 1k resistor to the +ve rail, and the emitter to ground.

The basic circuit diagram looks like this:
(The PIR is indicated by the switch to the left, and the output is connected to the relay)

And the actual components I've used look like this:

This is the small PIR with it's output going to the 10k resistor.
Above is the small relay board (It's a dual relay board, but I'm just using one). These boards are designed for Arduino and others as they are low-voltage signalling, so don't need a high current to switch the relay (They're opto-isolated). So you supply the board with +ve, ground and then the signal wire. When the signal is driven high it'll switch the relay on, and low switches it back off. The red LED indicates when the relay is energised.
At the top of the photo are the relay contacts, so centre takes the +ve feed, and the right (of the three terminals) takes the connection out to the LED downlights (normally open).

The image above shows the BC547B transistor with the 1k resistor to +ve and the connection to the relay board.
That's about all there is to it. I've contained it in a small plastic food container, and added fly leads with a DC jack socket and plug so you can simply plug it inline to the LED downlighters.

Monday, 11 April 2016

Project: Heating timer/thermostat replacement with Arduino

This is something I've been planning on and off for many years now and finally managed to make a start on the planning and design of this.
(Sorry for the long wordy blog entry!)

The project goal is to have a system that runs alongside the original programmer (And can be removed without damaging/affecting the existing system) and will supplement it's operation with a more dynamic control system. By dynamic I mean, by taking temperature readings from the majority of rooms in the house, taking outdoor temperatures and by allowing remote devices (Smartphones) the ability to interact with it, we should have a smarter heating system, and in theory save money by only having heating and hot water on when we actually need it and not warm an empty house, or over-heat the house.

The downside to traditional heating systems: This is an easy one, most existing systems have one temperature sensor/thermostat, a timer and a boiler (We'll ignore the pump, valves, etc, as those are all semi-automated from the boiler itself). Since there is only one temperature sensor/thermostat then we 'assume' this is a good judge of the house temperature. If that room is warm or cold then it will influence the heat through the entire house. It also doesn't take into account the outside temperature, or whether the house is occupied or not. In addition to that the hot water is a 'set and guess' method. You set what times you think you'll need hot water (or more accurately 30 minutes before you want it) and then heat up the hot water tank and hope it holds heat long enough until you need it, otherwise the heat is wasted.

The improvement plan: To add a controller alongside the existing one. This one will take temperature readings from all over the house and outside and make a calculation based on the average temperature in the house and also the outside temperature. For example, if the outside temperature is 5oC and inside we're only on 18oC then we know it'll take the house longer to warm up, so bring the heating on at an earlier time that morning (Also checking if people are in the house, if not then don't bother).

The equipment: To do this I'm going to use several Arduino programmable I/O boards. These are cheap, easily programmed and flexible to do what I need. There will be one installed beside the existing timer/controller which is beside the boiler. This will be the master and will have two relays connected up, to control the two functions on the boiler (Heating and Hot Water). These relays will be switching the 240v mains boiler, the current programmer is rated at 3Amp switching so my relays need to be at least the same. I'll wire them into the same outputs as the current programmer with a common LIVE to switch. These relays will need to be opto-isolated from their inputs to protect my Arduino against the high voltage that would kill it. I would also like a mains voltage 'sense' coming back into the Arduino, the idea being I can sense these two functions and see if the existing programmer has the heating or hot water already on. (Not sure how to 'sense' this voltage safely yet. Possibly solid-state mains powered relays?) This Arduino will also have a plain 16x2 LCD display to show current status, and will talk to my network using an ESP8266 wifi module. I'll also put two buttons on there, one for BOOST (1hr) for heating and the same for hot water, so you can also manually force the system ON (A function lacking on my existing controller).

Testing: So far I've only done a few concept tests. Firstly removing the existing controller and checking what connections are there. On mine there are 8. First two are LIVE and NEUTRAL (supply), the next two are NC contacts (one for HTG and HTW) which are unused, then there are the NO HTG and NO HTW which are the contacts closed to LIVE when the heating or hot water are requested by the programmer. The remaining two wires are for the temperature thermistor in the hallway (The only temperature sensor the manufacturer fits/supports).
Then I tested the LCD module and ESP8266 wifi module. I've had a lot of trouble with the ESP8266 modules in the past, I'm sure I've burnt out two now. First thing to remember, they are 3v units, and the Arduino drives at 5v so trying to talk serial to them over the digital I/O will over-volt the ESP8266, so this time I'm using a 4-channel Bi-Directional Logic Level Shifter, which allows 3.3v to 5v and vice versa conversion. I'm also using a 5v to 3.3v step down supply to power the ESP8266 based on the AMS1117-3.3 chip. That should keep the ESP8266 running happily, though I'll power it from my separate 5v supply rather than the 5v pins on the Arduino as these aren't particularly high current and the ESP8266 suffers when fed with low current supplies.
Also to remember, when testing the ESP8266 I used a USB serial adapter FTDI232 that runs at 3v3 or 5v for testing. That lets me connect straight into my laptop and to the ESP8266 to send AT commands and make sure it's working, etc. One other thing to remember, minicom on linux doesn't send CR+LF at end of line. You have to force it by pressing Ctrl-M then J (Annoying!)
So, that meant I had a working LCD and ESP8266 ready for the next parts.

I was also running out of digital I/O, luckily I'm not using analogue here so can use those as digital I/O too.
So the pins I've allocated so far are:

 * A0  = D14 BUTTON - heating boost (Boost for 1hr)
 * A1  = D15 BUTTON - water boost (Boost for 1hr)
 * A2  = DHW sense
 * A3  = HTG sense
 * A4  =
 * A5  =
 * D0  = n/a (serial comms)
 * D1  = n/a (serial comms)
 * D2  = lcd(14)
 * D3  = lcd(13)
 * D4  = lcd(12)
 * D5  = lcd(11)
 * D6  = RELAY (DHW) Hot Water
 * D7  = RELAY (HTG) Heating
 * D8  = ESP8211 RX
 * D9  = ESP8211 TX
 * D10 =
 * D11 = lcd(6)
 * D12 = lcd(4)
 * D13 = heartbeat LED light

As you can see, I'm now a little low on pins, so cannot add much more to this unit, good job this should cover almost everything here!

The next stage is the code which will involve quite a bit of tweaking, as there are several conditions I need to handle:
Heating on/off from temperatures (average) around the house
Heating on/off from remote control (app/webpage)
Hot water on/off from remote control (app/webpage)
Boost button for heating
Boost button for hot water
When people are home (Detect they're home by checking for either bluetooth mac address ping, wifi association, or house alarm isn't turned on) then switch heating on if temperatures are needed, or turn on hot water if within certain times.

There are also several safeguards to build in:
If heating is on constantly for more than 2hrs, perhaps we should switch it off as maybe something got stuck (Perhaps Arduino should stop making change and wait for manual intervention?)
Don't switch on and off heating quickly within an hour
Don't switch on and off hot water quickly within an hour

So the Arduino code will need to take the above into account. My basic code plan is to run in loop and keep polling my home linux server for the current state request.

That's where I'm up to for now, I'll continue to add more as I write the code and build the hardware. The next part is to find suitable hardware to enclose it in, this needs to be able to sit alongside the existing heating controller and not look out of place, but contain all the required Arduino, space for the LCD front screen, Heating on, Hot water on and two buttons for manual boost.
I'll also need to figure out how to sense mains voltage safely.

Hopefully more updates soon!

Sunday, 13 March 2016

Ford Fiesta Style 2007 remote boot release

Just a quick post for anybody with a similar problem. We have a Ford Fiesta Style 2007, similar to the photo below:
Recently the remote wouldn't pop the boot open, neither would the button on the car dashboard. For anyone that doesn't know, the car boot has a pop release on it, so it won't pop fully open but will unlock and release the catch so you can then lift the boot easily, or let somebody else do so (This is because there is no manual release button on the boot, the only alternative way to open the boot is to use the keylock which also releases the boot).
The electric boot release stopped working recently, and although you can hear the motor whirr nothing happens, so we decided to take a look and find out how it fits together and what was wrong.

Opening the boot you can see the locking mechanism, held in by two substantial hex bolts.

Here you can see the locking mechanism and I've removed the hex bolts (Two either side of the lock mechanism). DO NOT DO THIS! You don't need to for this repair/fix, that unit doesn't have anything interesting in. It contains the mechanical movement, an electric switch (for the alarm and boot lights) which you can see in the top right of the lock mechanism with the red tab (That is a push/pull connector) and two steel cables. These two steel cables are the release mechanism.
To get to these and the motor you need to remove the boot inner cover. This is the plastic cover with the handle to pull the boot shut. It has 3 cross-head screws and then it is pop-clipped shut, so take the screws out and just gently pull around the edges and the whole panel will come off.

Once you've removed the cover you'll see the rear wiper motor, electrical wiring and another black cover (in the middle of the photo, and photo below) which contains the locking mechanism and motor. This comes off with another couple of hex screws and then pops open.

Once you've removed the cover, you will see the motor and locking mechanism:

The two steel cables are then split, one comes into the servo motor shown above for the electrical release. The other feeds to the mechanical switch just up off to the right (out of shot) from the photo above.
As you can see it's a simple mechanism and uses a standard door lock servo to pull on the cable via a metal pivot. The springs them return the servo back to it's extended position.
The servo itself doesn't have many markings on it, the only ones I had are shown above on the photo. These will probably be standard, and I'd hope they match the servo's used in the door locks too to make it all standard and simple.
I found the servo was working, but it wasn't strong enough, so I think the servo is on it's last legs as it didn't have enough fore to exert against the spring. So as a quick/simple fix I decided to reduce the strength of the spring by cable-tying some of the coils together. This isn't exactly a fix, just a bodge job for now!
That's after I put the cable ties on and reduces the strength of the spring and for now opens the boot again using the electrical release. It'll fail again fairly soon but now I know I'll need a replacement servo motor to repair it properly.

Hope that helps somebody else wondering why their boot won't pop open, it should be an easy fix once you can identify the spare part to order and will only take about 30 minutes to change.

Friday, 11 March 2016

Tesco Hudl2 battery problems and teardown - Part2

Following on from my previous post (Tesco Hudl2 battery problems and teardown) I ordered a replacement Li-Ion battery (from eBay) to compare and test if this was the problem.
The battery was identical to the original one I had (Apart from the screenprinting wasn't quite a clear, so I'm not sure if it was genuine or a chinese copy. Doesn't really matter!), and so the first thing I did was tested the voltages I was getting on the pins.
Again on the black and red wires I was getting around 3.9v which looked good. I then tested the yellow and green wires. As you may remember these were the two I was most interested in as I think they were 'sense' wires to the Hudl2 to perhaps control if it should power on, check for 'safe' state of the battery, etc.
These did the same as the original battery, same low voltage output and same floating values, however after a bit of thought I tried the test but against the red (positive) wires, and lo and behold I got values! I got the same 3.9v on both of these wires. Comparing to the old battery, that did the same, so now I know, both batteries are giving the same output.
Therefore I wasn't very hopeful at this making the Hudl2 work.
Connecting it up, and sure enough the Hudl2 wouldn't power on. Connecting the charger up it again didn't light the charge light. No luck.

I then took the main board out of the Hudl2 to look for any other signs of problems, couldn't find anything, many many probe pins are on the board underneath marked power, signal, etc, and probing almost all of these showed voltage and signal so the board was getting power, etc, and all looked OK, so it appears to be something a lot more fundamentally wrong with the board now.

My suspicion is that when the fault PSU/wire started shorting out the usb input, there wasn't enough protection on the board and it damaged some key components (Not just in the charge circuit/components) and effectively bricked the unit.

Friday, 4 March 2016

Tesco Hudl2 battery problems and teardown

The Hudl2 is an excellently priced android-based tablet sold by Tesco in the UK for a while. Unfortunately they have now discontinued the range and so no more will be produced. Their price-point of under £100 and has an 8.1" screen, full HD, stereo speakers, quad-core 1.8Ghz processor, 2Gb RAM, 16Gb storage built-in and a 5 megapixel rear camera and 1.2 megapixel front-facing camera. So a pretty decent spec for the money.
My youngest had one and it's done well, lasted around 2 years of abuse, mainly around the charge socket as usual it's micro-usb and this is the weak point, the cables were abused quite badly and over time gave up, so swapping cables quite often solved it. That was until the last time, when the cable seemed to have shorted, so the tablet was left for a few weeks totally flat.
Plugging it in to charge wouldn't give the red charging light, which worried me as normally charge lights are hard-wired to the voltage input, so it not coming on was a bad sign, was the usb port damaged or worse.

What makes it more complicated is the hudl2 comes with a USB charger, but with non-standard specs, it's the usual 5v output but it's 2.0A which is a lot higher than normal (usb port is 0.5A), so that would suggest the hudl2 uses fast/high-powered charge. I therefore wasn't sure what the cable needed to be (We'd thrown out the damaged cable, a stupid move in hindsight!). Luckily the charger itself was OK and charging other USB devices fine.

So I suspected the hardware, popping the cover off is easy, just a flat screwdriver gently prising around the outside of the case at the seam will take the back cover off, just pop it open and it comes into two neat halves (no wires to worry about popping out, etc, the rear cover is purely a cover).

There in the middle you can see the 'battery pack'. This consists of two 3.8v li-ion batteries in parallel which I assume is to provide longer life/capacity. The connector is curious, it's 10 wires, 4 red, 4 black, one yellow and one green. All the red wires are tied together (so I suspect just to carry higher current on small wires) as are all the black wires. The yellow and green are interesting.
Upon initial opening, the red and black wires were giving 0v output. This made me think the 'battery pack' had li-ion protection circuit in there and had gone into full discharge protection (i.e. shutting the batteries down). So the first trick was to get them to charge. Plugging the USB power lead in initially didn't show any voltage on these wires either, which really confused me, as I'd assume the tablet would provide power to try and charge the batteries and rely on the charge circuitry to protect it.
In hindsight, I suspect this isn't the case, and the tablet does have sense on it (through the yellow and green wires I think) and so didn't start charging.

I then pulled apart the battery pack (very carefully. Li-ion are very unstable batteries, any damage could cause a cascade accident so please read up on them and do this with caution, know what you're playing with!) and found the control circuit. This was also when I found that the 'battery pack' was two li-ion packs joined together at the top with the control circuitry.
Testing the cell themselves (the metal tabs at the top of the cells) I got a low voltage (around 3.0v) which I'd guess was too low for the circuit to allow output/charge, so it was 'dead'. Reading around, there are ways to revive this circuit, unfortunately I didn't really document how I recovered the battery but it was a combination of keeping the charge on it and probing the sense circuits (My suspicion is my meter combined with voltage applied caused the charge circuit to 'see' a voltage which kicked things back off). I then saw 3.7v on the red and black wires from the Hudl2 cables, which was a good start. Watching it over a minute or so I saw the voltage slowly going up, by 0.01v every few seconds, so it got to 3.9v and hovered for a while. This looked hopeful.
Meanwhile I took it off charge a few times to test the Hudl2 power supply, the adapter gave out 5v as expected, and it had the middle two data pins shorted out, which is a common way of signalling to devices that it was a 'fast/high capacity' charger, so that's why other chargers didn't work right, they did slow/low charging rates.
Over about 30 minutes the voltage went up and up to around 4.0v which looked a good charge voltage for the cells, and it stayed around there, the charger got quite warm (I couldn't check current unfortunately) but I guessed this meant it was charging at a decent rate.
Over a few hours the voltage stayed around 4/4.1v and when removing the charger, I saw the voltage drop to the correct 3.8v supplied on the black and red wires to the Hudl2. However, the charge light would still not come on and the tablet wouldn't power on.
I was using the 'recovery' way of turning it on, that is holding the volume up and power in for 15 seconds, then just power for 15 seconds. This is supposed to recover it should it stop charging. However this wouldn't work. I've tried many combination of power and volume buttons without success now. None will show either the charge light or the power coming on to the tablet (Normally even when low on battery plugging the charge cable in would light the screen up and show a charging battery animation, this didn't trigger either).
So I'm back to suspecting the 'sense' circuitry either in the battery (unlikely as the batteries seemed happy now) or in the Hudl2 itself (most likely now I think). So I turned my attention to the strange additional two wires. The Yellow and Green that came from the battery into the Hudl2 motherboard.
When testing these wires, the yellow shows a constant 0.5v (when tested to black/ground) and the green showed a jumping voltage, my meter only showed around 0.5v for about a second, then 0 then back up again, approx every second changing. This is confusing, I'm unsure what both of these values should be, so cannot determine if these are giving the right output to the Hudl2 to tell it 'all is well'.

This is where I'm up to, the tablet won't power on or show it's charging, I think it's to do with these two sense cables, but not knowing their purpose or correct values cannot 'trick' it into booting or charging, which I suspect will kick a chain reaction and get it back to life.
I've ordered a replacement Li-Ion battery pack for it (Around £10 from eBay) as my suspicion is that if the pack is still damaged/faulty, then these sense wires may be causing the problem. When the new pack arrives the first thing I'll be doing is testing these two leads and see what voltage they give out and what sequence they do, as that may unlock the key to why the unit won't power back up.

As always, I'd appreciate your feedback and comments, if you've had similar problems and solved them please do post back to me, or if you know what the mystery Yellow and Green wires are for let me know in the comments!

Thursday, 11 February 2016

Cheap Chinese IP cameras (Wanscam) and their network activity

Here's a curious item, I've had quite a few of these over the years, not just IP Cameras but home automation relays, thermostats, etc. They all generally have IP connectivity and I duly just connect them into my LAN and start to use them.
However, I've been looking at why my internet connection keeps spiking and trying to cut down on anything not required to chatter to the internet, as my home connection is a very poor ADSL that cannot sustain much traffic, so cutting any junk out will help lots!

So running packet traces on my public connection (All devices on the LAN default gateway to my home server (A linux server) and then this does NAT to the public IPs I have), and started to notice a pattern of requests constantly going out over the public interface.

The first one is shown below:

12:33:47.668240 IP OBSCURED.2614 > OBSCURED.domain: 6038+ A? (34)
12:33:47.686932 IP OBSCURED.domain > OBSCURED.2614: 6038 NXDomain* 0/0/0 (34)
12:33:47.690643 IP OBSCURED.2614 > OBSCURED.domain: 6039+ A? (34)
12:33:47.709829 IP OBSCURED.domain > OBSCURED.2614: 6039 NXDomain* 0/0/0 (34)
12:33:47.723202 IP OBSCURED.2614 > OBSCURED.domain: 6042+ A? (34)
12:33:47.742344 IP OBSCURED.domain > OBSCURED.2614: 6042 NXDomain* 0/0/0 (34)
12:33:47.746075 IP OBSCURED.2614 > OBSCURED.domain: 6043+ A? (34)
12:33:47.764766 IP OBSCURED.domain > OBSCURED.2614: 6043 NXDomain* 0/0/0 (34)
12:33:47.777307 IP OBSCURED.2614 > OBSCURED.domain: 6046+ A? (34)
12:33:47.796293 IP OBSCURED.domain > OBSCURED.2614: 6046 NXDomain* 0/0/0 (34)
12:33:47.801283 IP OBSCURED.2614 > OBSCURED.domain: 6047+ A? (34)
12:33:47.819959 IP OBSCURED.domain > OBSCURED.2614: 6047 NXDomain* 0/0/0 (34)
12:33:47.832231 IP OBSCURED.2614 > OBSCURED.domain: 6050+ A? (34)
12:33:47.850810 IP OBSCURED.domain > OBSCURED.2614: 6050 NXDomain* 0/0/0 (34)

(I've OBSCURED my IP/hostname and my upstream DNS providers resolver here)
So what was happening is something was asking for the dns entry for and constantly being told this doesn't exist. So this capture was done on my external interface, switching to my internal interface (for my LAN on the NAT server) I then tracked this down to an IP Camera was making this constant request. Logging into the web interface of the camera I couldn't find anything referring to this, but clearly it has some process where it tries to 'phone home' so that was the first one tracked down. I simply put a block in my local caching DNS to stop this external request, so that stopped it from asking externally and wasting bandwidth (It was doing this every 60 seconds).

The next one I then spotted was this:

12:38:47.545925 IP OBSCURED.3203 > UDP, length 24
12:38:47.546216 IP OBSCURED.3203 > UDP, length 24
12:38:47.546402 IP OBSCURED.3203 > UDP, length 24
12:38:49.354353 IP OBSCURED.3208 > UDP, length 44
12:38:49.354574 IP OBSCURED.3208 > UDP, length 44
12:38:49.354774 IP OBSCURED.3208 > UDP, length 44
Again OBSCURED was my cameras IP address. So this was more interesting. The camera was constantly (every minute again) trying to contact something in the Amazon AWS cloud. This indicates somebody has a server on Amazon's cloud that these units are contacting. I have two IP cameras both different manufacturers and different interfaces but they were both doing this, so there must be a common firmware package being used that was making this communication.
Interestingly the machine at the other end was refusing the UDP connection, but still, why was it there?
First thing, I blocked this from making it out of my firewall, then set about looking to see what it's doing. The payload is UDP therefore it's stateless, so most likely it's just squirting a bit of info about itself (perhaps firmware, version, date/time) back to it's manufacturer. Possibly it was also used as a 'cloud' solution for viewing or managing your camera as I have seen this principle, but again this was all disabled on my unit, but this suggests even when disabled it still makes the initial phone-home even if nothing else was passed. As you can also see it's trying to talk to a few IP addresses in Amazon. I'm unsure if these are hard-coded in or if it's a DNS request the device makes, so next step was to sniff it's traffic and see what DNS requests it was making. In this case it didn't appear to be making any DNS requests, which suggests these hosts are hardcoded into it.
Viewing the actual payload didn't help much either:

13:17:00.226305 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 52)
    OBSCURED.3203 > [udp sum ok] UDP, length 24
 0x0000:  4500 0034 0000 4000 4011 a06c c0a8 3709  E..4..@.@..l..7.
 0x0010:  36f6 6ba5 0c83 7d64 0020 f89b f191 0014  6.k...}d........
 0x0020:  4a57 4556 0000 0000 0003 95fe 4545 4343  JWEV........EECC
 0x0030:  4300 0000                                C...
13:17:01.942156 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
    OBSCURED.3208 > [udp sum ok] UDP, length 44
 0x0000:  4500 0048 0000 4000 4011 aa32 c0a8 3709  E..H..@.@..2..7.
 0x0010:  36f3 61ce 0c88 7d64 0034 bf8e f110 0028  6.a...}d.4.....(
 0x0020:  4a57 4556 0000 0000 0003 95fe 4545 4343  JWEV........EECC
 0x0030:  4300 0000 0200 0721 0002 880c 0937 a8c0  C......!.....7..
 0x0040:  0000 0000 0000 0000                      ........
13:17:01.942371 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
    OBSCURED.3208 > [udp sum ok] UDP, length 44
 0x0000:  4500 0048 0000 4000 4011 99fd c0a8 3709  E..H..@.@.....7.
 0x0010:  36fb 71fb 0c88 7d64 0034 af59 f110 0028  6.q...}d.4.Y...(
 0x0020:  4a57 4556 0000 0000 0003 95fe 4545 4343  JWEV........EECC
 0x0030:  4300 0000 0200 0721 0002 880c 0937 a8c0  C......!.....7..
 0x0040:  0000 0000 0000 0000
Which I couldn't work out what this was containing. It was always the same length and contained similar information, only one or two characters changed, but I couldn't see any correlation between what the camera was doing and this value, so I don't think I'll spot what it is.

One final thing, was I port scanned the camera, which showed 23 (telnet), 99 (metagram), 8600 (asterisk). Now the first telnet port was correct as I could telnet and get a login prompt. Port 99 was the web port (I'd changed it to that) and 8600 seemed to answer telnet then immediately close it again. So I thought I'd try telnet:

Escape character is '^]'.

(none) login: root

BusyBox v1.12.1 (2012-11-20 15:16:24 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# ps
    1 root      1528 S    init       
    2 root         0 SWN  [ksoftirqd/0]
    3 root         0 SW<  [events/0]
    4 root         0 SW<  [khelper]
    5 root         0 SW<  [kthread]
    6 root         0 SW<  [kblockd/0]
    7 root         0 SW<  [khubd]
    8 root         0 SW<  [kswapd0]
    9 root         0 SW   [pdflush]
   10 root         0 SW   [pdflush]
   11 root         0 SW<  [aio/0]
   12 root         0 SW<  [scsi_tgtd/0]
   13 root         0 SW   [mtdblockd]
   14 root         0 SW<  [kmmcd]
   20 root      1092 S    nvram_daemon 
   23 root         0 SWN  [jffs2_gcd_mtd6]
   25 root         0 SWN  [jffs2_gcd_mtd7]
   28 root      1528 R    telnetd 
   29 root      1696 S    /system/system/bin/daemon.v5.12 
   30 root      1480 S    /system/system/bin/cmd_thread 
   31 root      1480 S    /system/system/bin/gmail_thread 
   32 root      1532 S    /bin/sh 
   33 root      1696 S    /system/system/bin/daemon.v5.12 
   36 root      1480 S    /system/system/bin/cmd_thread 
   39 root      1480 S    /system/system/bin/gmail_thread 
   40 root      1696 S    /system/system/bin/daemon.v5.12 
   41 root      1696 S    /system/system/bin/daemon.v5.12 
   43 root      1480 S    /system/system/bin/cmd_thread 
   44 root      1480 S    /system/system/bin/gmail_thread 
   50 root         0 SW   [RtmpCmdQTask]
   51 root         0 SW   [RtmpWscTask]
   89 root      1696 S    /system/system/bin/daemon.v5.12 
  135 root      1524 S    /sbin/udhcpc -i eth2 -n 
  140 root      1696 S    /system/system/bin/daemon.v5.12 
  141 root      1696 S    /system/system/bin/daemon.v5.12 
  142 root      1696 S    /system/system/bin/daemon.v5.12 
  145 root      1696 S    /system/system/bin/daemon.v5.12 
  146 root      1696 S    /system/system/bin/daemon.v5.12 
  147 root      1696 S    /system/system/bin/daemon.v5.12 
  151 root     11528 S    /system/system/bin/encoder 
  158 root     11528 S    /system/system/bin/encoder 
  159 root     11528 S    /system/system/bin/encoder 
  160 root     11528 S    /system/system/bin/encoder 
  161 root     11528 S    /system/system/bin/encoder 
  164 root     11528 S    /system/system/bin/encoder 
  165 root     11528 S    /system/system/bin/encoder 
  167 root     11528 S    /system/system/bin/encoder 
  168 root     11528 S    /system/system/bin/encoder 
  169 root     11528 S    /system/system/bin/encoder 
  170 root     11528 S    /system/system/bin/encoder 
  171 root     11528 S    /system/system/bin/encoder 
  172 root     11528 S    /system/system/bin/encoder 
  173 root     11528 S    /system/system/bin/encoder 
  178 root     11528 S    /system/system/bin/encoder 
  179 root     11528 S    /system/system/bin/encoder 
  180 root     11528 S    /system/system/bin/encoder 
  181 root     11528 S    /system/system/bin/encoder 
  182 root     11528 S    /system/system/bin/encoder 
  183 root     11528 S    /system/system/bin/encoder 
  184 root     11528 S    /system/system/bin/encoder 
  185 root     11528 S    /system/system/bin/encoder 
  186 root     11528 S    /system/system/bin/encoder 
  187 root     11528 S    /system/system/bin/encoder 
  188 root     11528 S    /system/system/bin/encoder 
  189 root     11528 S    /system/system/bin/encoder 
  190 root     11528 S    /system/system/bin/encoder 
  191 root     11528 S    /system/system/bin/encoder 
  192 root     11528 S    /system/system/bin/encoder 
  193 root     11528 S    /system/system/bin/encoder 
  194 root     11528 S    /system/system/bin/encoder 
  195 root     11528 S    /system/system/bin/encoder 
  196 root     11528 S    /system/system/bin/encoder 
  197 root     11528 S    /system/system/bin/encoder 
  198 root     11528 S    /system/system/bin/encoder 
  199 root     11528 S    /system/system/bin/encoder 
  200 root     11528 S    /system/system/bin/encoder 
  201 root     11528 S    /system/system/bin/encoder 
  202 root     11528 S    /system/system/bin/encoder 
  203 root     11528 S    /system/system/bin/encoder 
  204 root     11528 S    /system/system/bin/encoder 
  205 root     11528 S    /system/system/bin/encoder 
  206 root     11528 S    /system/system/bin/encoder 
  207 root     11528 S    /system/system/bin/encoder 
  208 root     11528 S    /system/system/bin/encoder 
  209 root     11528 S    /system/system/bin/encoder 
  210 root     11528 S    /system/system/bin/encoder 
  211 root     11528 S    /system/system/bin/encoder 
  213 root     11528 S    /system/system/bin/encoder 
  214 root     11528 S    /system/system/bin/encoder 
  215 root     11528 S    /system/system/bin/encoder 
  216 root     11528 S    /system/system/bin/encoder 
  217 root     11528 S    /system/system/bin/encoder 
  218 root     11528 S    /system/system/bin/encoder 
  221 root     11528 S    /system/system/bin/encoder 
  222 root     11528 S    /system/system/bin/encoder 
  223 root     11528 S    /system/system/bin/encoder 
  224 root     11528 S    /system/system/bin/encoder 
  225 root     11528 S    /system/system/bin/encoder 
  226 root     11528 S    /system/system/bin/encoder 
  227 root     11528 S    /system/system/bin/encoder 
  228 root     11528 S    /system/system/bin/encoder 
  229 root     11528 S    /system/system/bin/encoder 
  230 root     11528 S    /system/system/bin/encoder 
  231 root     11528 S    /system/system/bin/encoder 
  236 root     11528 S    /system/system/bin/encoder 
  237 root     11528 S    /system/system/bin/encoder 
  238 root     11528 S    /system/system/bin/encoder 
  239 root     11528 S    /system/system/bin/encoder 
  240 root     11528 S    /system/system/bin/encoder 
  252 root     11528 S    /system/system/bin/encoder 
  253 root     11528 S    /system/system/bin/encoder 
 1891 root     11528 S    /system/system/bin/encoder 
 1892 root     11528 S    /system/system/bin/encoder 
 3553 root     11528 S    /system/system/bin/encoder 
 3554 root     11528 S    /system/system/bin/encoder 
 3821 root      1532 S    -sh 
 3824 root      1528 R    ps 

As you can see, I logged in! I tried using the username and password I'd set using the web interface, but this failed. So I tried the default it shipped with, 'root' and password '123456' and it let me in! So it seems these all have this as a default, and once in it runs a basic busybox linux system. I've not had much time to look any further, but if you're interested here is the filesystem and what looks like the init script that is ran at system bootup to start the daemons
# df
Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                    3008      3008         0 100% /
/dev/root                 3008      3008         0 100% /
/dev/mtdblock6            3072      1892      1180  62% /system
/dev/mtdblock7             512       208       304  41% /param
# ls /system
system    daemon    Wireless  init      www
# cat /system/init/ 
export LD_LIBRARY_PATH=/system/system/lib:$LD_LIBRARY_PATH
export PATH=/system/system/bin:$PATH
/system/system/bin/daemon.v5.12 &
/system/system/bin/cmd_thread &
/system/system/bin/gmail_thread &
So there looks to be 3 daemons that I'd like to have a look inside, so may do at some point in the future.

Monday, 11 January 2016

Review/Experience Vax Air Pet Upright Vacuum Cleaner

Slightly swaying away from techie things, I felt I'd like to write a review on this product "Vax Air Pet Upright Vacuum Cleaner", it's something we decided to buy for our house around 1 year ago. Previously I'd owned a Dyson animal DC14, which was a great unit, it managed to clean up the cat air (two long-haired cats) and usual family mess for around 5 years, which I was happy with.

However, it's brush cleaners and plastic casing finally got cracked badly and the decision was made to purchase a new one. Unfortunately the newer Dyson units are very expensive, and I dislike the 'ball' idea they've had for these, so looked around, and found the Vax Air Pet Upright:
Which looked similar, it uses cyclone bagless technology, was designed for people with pets so generally has good suction and ability to grab the hair up.
They're also not cheap, but slightly less than the Dyson. Around £200 was the going price I think.

Initial thoughts, it looked ok, seemed to have the functions and did a decent first start at hoovering up, so was ok.
However, several limitations appeared almost immediately.
It has a very short flexi-hose. As you can see on the picture above, the flexi hose is moulded at the top of it, and clips into the front brushes, so for your flexi hose you unclip there. And you only have the length to the first plastic ring as hose that's any use. Realistically thats one arm length at full stretch. Not very long at all, try to clean the back of a sofa with the unit on the floor, it's almost impossible without dragging the whole unit up.
Suction, it's not that great, whilst it feels powerful, when you actually try to suck up pet hair from a carpet/sofa, etc, with an attachment on the hose the pressure release valve goes off and it stops suction, so you have to only half use the suction otherwise the pressure relief stops the thing from sucking.
Weight, it's not too bad on this, you can carry it with one hand reasonably, but I'm not going to hoist it up and above my head in a hurry.
Power cable length feels a bit shorter than the Dyson too, but that's not a major pain.
Waste/Dust container isn't huge, but sufficient, just remember to empty it often on a large house run.

Now onto the REALLY big problem, the front rotating brushes. These are ran by a separate motor (good idea) and belt driven (good idea), however they are really poor at getting clogged up. And not by something like a childs toy, wire or string. It gets heavily clogged up by HAIR, cat and human! So after quite a short vacuum run you have to then unplug it, upturn it and grab a pair of scissors and start to cut the tangled hair out of it. This is a continued pain I find. On the old Dyson I could leave that and do it maybe once a year (I probably should have done it more often!) but it certainly didn't impede it's work. On the Vax this slows down the rotor, causes it to smell badly (I think hair gets into the bearings or spindles and at the speed it spins causes it to burn slightly and give the bad smell of burning hair).
I spent quite some time over the weekend taking this part apart on the unit, to find out how it works and fits together. I found several parts that I wasn't impressed with. Firstly the bar:

It isn't very clear on this picture, but on the left hand side you have a toothed gear that attaches to the belt, it's pretty sturdy and good teeth on it so this is a good build. On the right however is where it worried me. This piece simply pushes into the base of the device and is held against the right hand side of the base by friction. So it's not actually supported on both sides, only the side with the belt and motor. This is probably what caused it to dislodge at some point with us and cause the whole unit to vibrate terribly.
Secondly, inside the ends of these there are small bearings for the rotation. These bearings are very small, but also aren't sealed, they appear to be open and able to get things jammed into them, like hair, dust, particles, etc. So again not very impressive considering this will be a part constantly in the path of dirt and particles that can get into bearings and not give them a good time.

So all in all, Vax, I think this is a very poor offering, it doesn't hold up to the tough PET name, giving you the impression it can deal with tough pet hair, etc. And so unfortunately I think this may not last very long and get replaced sooner.

A few months after purchase I wanted to solve the short hose problem and get some better attachments as the one that comes with it was very poor indeed (single tube type). So I went via the official vax shop, compatibility checker and chose an accessory pack called "Vax Pro Cleaning Kit" which was £39.99 and had lots of handy adapters in there, which would help with stairs, etc. I also ordered a "Vax Stretch Hose" which is listed as a replacement but also an extension, which I thought would be ideal, add that on and better adapters and all would be well. However after they turned up several problems again were spotted. Several of the adapters didn't actually FIT the hose! Some were way too small and by forcing them on it would work, but this felt like a wrong design. Others went on fine and worked. The extra hose, this doesn't act as an extension but a replacement (same short size) of the original so this also was useless and couldn't even be modified to fit (I tried all sorts to modify the hose and fittings, plastic shaving, resizing, etc, nothing would make it fit right and work) so I gave up with that also.

All in all, not an impressive offering.

Thursday, 7 January 2016

12v LED indicator bulbs for Chrysler grand voyager

A short post this one, but I noticed the orange colour was fading from my rear indicators on my Chrysler Grand Voyager.

This is a common problem on many cars now, as they use clear lenses and an orange bulb to make the indicator orange. This 'solution' to me is flawed and since its the bulbs with an orange paint on them, over time the pain burns off/fades which is what happened with mine and the indicator now looks white rather than orange (This is an MOT fail here in the UK, and as my MOT is due I needed to sort it)

So I found these LEDs on an ebay listing

They are ORANGE 581 BAU15s PY21 replacement LED bulbs in the same package, etc.
One warning that I saw on the Chrysler Grand Voyager forums is that the voyagers electrical wiring is non-standard and actually has positive on the surround and negative on the central pin. On normal bulbs this isn't a problem as they don't care about polarity, but LED's require + and - polarity so this could have been an issue.
I did a test with my multimeter on the pins and verified that this was NOT the case though, the central pin was positive like on all other vehicles as standard, so first issue out of the way.

The bulbs fit into the holders fine, and then into the external bulb/reflectors fine too, so these are the right size and shape.
Testing them with the hazard indicators on, all looks good, swapped them and they were blinking away and brightness looked ok (I did expect a little brighter to be honest, but they were comparable to the existing ones).

So all was well.
Until the next day when I actually drove to work, and realised that when I put the indicators on I got the dreaded 'fast flash' or hyperflash as some people call it. This is where the indicator bulbs flash very quickly. Most cars were designed to have a load from the bulbs and this allowed them to flash at a normal pace. When a short or an open circuit (bulb failure) was detected, the current consumed dropped and this causes the flasher unit to flash faster, the idea being that it was then easy to tell when a bulb had failed and needed replacing.
Unfortunately the LEDs consume a lot less current than the original bulbs and so this was causing the circuit to think the bulb was missing, when in fact all the bulbs and LEDs were lighting up correctly.

Doing a bit of maths I can calculate the difference.
These are 24LED units, and assuming an LED voltage of 2v for orange and estimating at 25mA per LED, adding that up we get 0.05 watts at 2v per LED. Multiple by 24 and we get 1.2 watts in total.
The usual bulb consumes 21 watts, so there is a difference of 19.8 watts, which is quite significant and obviously what the car is detecting and causing the fast flash.

There is a solution, this is to use a load resistor. This is effectively a resistor across the terminals (shunting the voltage/power through the resistor as well as the LED) which causes a higher current to flow and the indicator circuit to think it has a valid bulb installed.
This has several problems for me, firstly it's a waste. We would be wasting current shunting it through a resistor effectively wasting this current through heating the resistor up. Secondly you have to cut into the wiring loom and install this load resistor which is untidy and messy. I'm also not sure if this will stop the bulb sensing for the other bulbs in the indicator circuit (I only swapped the rear to LED, front are still standard). So this to me isn't a good solution.
I still did the maths to calculate what resistor I'd need.
So for 19watts at 12v this is 1.58 amps.
So using Ohms law (V = ir) I could calculate the resistor size. So 12 = 1.58R, and calculating that it comes out at 8.2 Ω (Ohms)
So if I were to install a load resistor it would need to be an 8.2 Ohm 19 (or 20) watt resistor. (Which are the larger ceramic style rectangular units as they are dissipating so much wattage)

Therefore I'm thinking of swapping and going back to the regular bulbs rather than LEDs as don't think this solution is quite right. I'm open to comments though, please let me know your thoughts.

Monday, 16 November 2015

New Video: Inside a cheap chinese LED E15 lightbulb

I've posted a new video to +YouTube "Inside a cheap chinese LED E15 lightbulb"