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? www.db-power.com. (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? www.db-power.com. (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? www.db-power.com. (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? www.db-power.com. (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? www.db-power.com. (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? www.db-power.com. (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? www.db-power.com. (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 www.db-power.com 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 > ec2-54-243-97-206.compute-1.amazonaws.com.32100: UDP, length 24
12:38:47.546216 IP OBSCURED.3203 > ec2-54-251-113-251.ap-southeast-1.compute.amazonaws.com.32100: UDP, length 24
12:38:47.546402 IP OBSCURED.3203 > ec2-54-246-107-165.eu-west-1.compute.amazonaws.com.32100: UDP, length 24
12:38:49.354353 IP OBSCURED.3208 > ec2-54-243-97-206.compute-1.amazonaws.com.32100: UDP, length 44
12:38:49.354574 IP OBSCURED.3208 > ec2-54-251-113-251.ap-southeast-1.compute.amazonaws.com.32100: UDP, length 44
12:38:49.354774 IP OBSCURED.3208 > ec2-54-246-107-165.eu-west-1.compute.amazonaws.com.32100: 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/ipcam.sh 
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"


Sunday, 15 November 2015

Dashcam/Reversing camera to Chrysler Grand Voyager - part 2

Briefly to complete my installation of the dashcam/reversing camera to my Chrysler Grand Voyager, I wanted to connect up the 12v 'sense' wires that are attached to the rear camera. These will then switch the screen on and set it to reverse mode (the reversing camera full screen), so I set about trying to connect these up.
The exterior light cluster on the GV comes out quite easily, two clips and the whole assembly pops out, and again the lights pop out from a clip, I can then see the wiring harness disappear into the chassis, typically further back than I'd hoped, so not within easy reach to any of the edges of the plastic boot covers.
So I set about taking the majority of the left-hand plastic covers off. This is additionally difficult as it has the boot opener/closer motor fitted to the chassis, so the plastic covers wouldn't come off completely as I'd need to disconnect the boot motor, which I didn't want to attempt.
So initially you have to take the boot tray/sill off, which is shown below. Just prise it up from one side as it has metal pop-clips on it, and comes off quite easily.

Then, unscrew the two retaining clips (These are what I assume support a boot cover if you have one too, they are crosshead screws inside), then start to prise off the side plastic panel:

These pop open from the back, and you have to slightly lift when doing that as they sit down onto retaining clips. This is quite tricky, as there are so many parts to this piece of plastic. It's a one-piece that goes from the base of the boot, up around the boot motor, round into the car and contains the rear window motor assembly and also the rear speakers, so quite a large piece of plastic with many shapes and fasteners.
I found that this was about as far as I could get, so could just move the plastic around and bend it slightly, just enough to get inside to route the wires and figure out whats going on.

I then discovered several odd things. The first was that a control box had been mounted inside the bodywork, and had a whole heap of wires coming out of it. Then, I noticed one of the wires from the main car wiring loom had been cut, extended and then joined into this black control box. The extension wire you can just see on the photo below, it's the red closest on the picture.

This had been black-taped at the joins, which always makes me think after-market fitting/work, basically because that's something I'd have done! After continuing with the job in hand, I started to test and trace for the cable connected to reverse lights, and found it's white with a light-green stripe. Sure enough, this is the wire that had been cut and extended as shown in the above photo, so now I know what this box was (probably), reversing sensors.

I'd always assumed the reversing sensors on my GV were factory fit, the sensors certainly looked it, and the module was sensibly fitted (It's a small black round circle with about 3 or 4 LEDs from green to red), but perhaps not! So anyway, this meant I could take another branch off this wire and use it for my reverse sense wire.

Wiring that in, the system worked great, when I select reverse the camera switches over and displays on the rear view mirror.

Saturday, 7 November 2015

Fitting and wiring a dashcam to my Chrysler Grand Voyager

A few tips and guides from when I fitted a dashcam to my Chrysler Grand Voyager. The dashcam I decided on was a cheap chinese import, It's a Buyee HD 1080p 4.3" Dual lens Mirror dashcam.
Below is the product information from ebay (It was around £30 which seemed a cheap enough price to play around with!)

The idea is you clip the unit over your existing rear view mirror. Normally (when it's screen is off, which is most of the time) the unit is reflective so it acts like a normal mirror. The mirror finish is good, and my only comment would be it's a little 'blue' in it's reflection, but this is pretty good, so as a rear view mirror, no problems.
The power to it is via a supplied 12v cigarette style power plug, which has a really nice long power cable on it so you can thread it around the car. It also comes with a small rear-view camera to put at the back of your car for additional recording, and it also acts as a reversing camera (and has a 12v sensing cable to connect to reverse lights so the screen switches on and flicks to view this when it reverse).
Fastening it around the Chrysler mirror was fine, the mirror was about the same size (and the Chrysler mirror is large) and the camera pops out the side quite nicely (The camera is to the left of the back of the mirror). The issue here is I think this was designed for left-hand-drive, and so the camera swivel on it's mount wasn't quite good enough, I viewed more of the left pavement than of the right of the road (it was fine, but just not covering the right of the road as much as I wanted).
So I therefore decided to install the mirror upside down! This means that all menus, etc, are upside down, and the images recorded were upside down, but it had a better field of vision. I might look to open the unit up and flip the camera at some point, but not yet!

So now onto fitting the cables. Luckily along the top of the front windscreen it is just soft foam padding to the roof so gently pushing the cable up and hiding it was easy. At the left door pillar, same again just gently prise the rubber and plastic fittings and there is plenty room to put the cables in (one for power, one for rear view camera). Once above the passenger left hand door I left the camera cable there, as I was going to take the rear camera cable along the top of the car.
The power, I then fed down the pillar, again just gently hiding it behind the plastic pillar cover, and down towards the glovebox. At the left just above the glovebox was a plastic cover, prising this open (It has those metal pop-clips, so fine to prise open gently) let me feed the cable in and behind the glovebox (Glovebox, open it, gently squeeze the limiters and it drops fully open revealing behind it)
This is the view when the glovebox is completely dropped open (down towards the bottom of the picture).
You can see to the left the black cable is the dashcam power cable I was threading through.

Pass the cable straight through, then onto the hard part, into the base of the centre console (where the old tape storage box was on these cars).
What I was going to do was put a cigarette socket inside this storage box at the base of the centre console, and wire that into the current cigarette lighter socket that was operated via the ignition. Therefore the dashcam would automatically switch on when ignition on, and then off again when off.
I took most of the centre console panels apart (Removing the 'wooden' fascia by taking the top two screws out and prising it out). Here is the cigarette lighter socket removed:

To remove it, you can just about see the small push in clips. So with a flat screwdriver head, gently push this into the top of the socket, between the black plastic and the grey dashboard surround. You should be able to prise it out and it'll drop out like you see here.

Pull it out and you see the connector at the back. Press the release button and the connector comes out. Then I found the problem, this cable is really tight and not much spare. Trying to trace the wire drew a blank, it's in a harness that goes round the right hand side of the radio and I suspect straight to the ignition wires (or at least that harness) so getting 'spare' wire doesn't look an option. I therefore decided to take the whole plastic connector apart and solder straight onto it. The connector comes apart easily, sliding the metal contacts out, I was then able to solder on my wires and a bit of electrical tape for good measure. It ended up looking like this:

However, if you do the same thing, make sure the solder and electrical tape is tight (not like mine!) as when you come to push the connectors back on, they'll struggle as they're too wide for the connector. After a struggle that went back on, and so did the cigarette lighter socket. Testing each time, and all the way to ensure polarity is correct, etc. All looked good. So I know had my extension sockets in the lower tape compartment powering on and off with the ignition.

The socket I chose was also from ebay and was around £3 which included two sockets and usb charging sockets on them too, you can never have too many charging sockets!
All I did then was plug in the dashcam cable to the socket and it was ready to go!

Wiring the rear camera was more of a challenge, mainly because of the wiring route I had to take. I'll need to update this with photos and more info when I can but it got dark so I gave up for the day.
In brief, I ran the cable over the top of the passenger door, round the pillar plastic cover and along the top of the rear sliding door. Again just gently prising it into the gap from the rubber seal as there is a generous amount of space behind these without compromising the seal. Round the very rear window, and up to the roof again, then to the boot. I screwed the camera into the grey plastic of the boot lid so it was sat at the top of the boot window. It was pretty small and not obvious which was ideal.

The next problem was to connect into the reverse lights. The camera cable branches off and gives you a red+black cable to run for this. I prised the plastic around the left rear speaker (just below the electric window housing). I found the hard way, this plastic does prise apart, but it should be removed by sliding outwards, towards the boot. I think, as this is an entire plastic component you are supposed to take the whole piece out together (including the plastic cover around the boot opener, etc), but I just forced it and ended up almost snapping (and bending) the plastic retaining clips. That way, I managed to feed the cable down towards the jack stowage locker.

(red and black wire on the photo above just hanging at the moment, this is the sense wire for the dashcam for when reverse is engaged)

That's as far as I've got, taking the rear light cluster out I found nothing more than a small cable and rubber fitting going into the body, no easy/big access hole to feed the cable to! So I suspect I am going to have to remove more of the whole plastic covers at the rear to get to this, so that's a job for another day.

But for now, I'm happy with the job, the unit powers on and starts recording when ignition goes on, and the view from front and rear cameras is ideal!

Get in touch if you'd like any specific details, etc, or to let me know if you've given it a go too!

Wednesday, 30 September 2015

Children and online safety

This is always a hot topic, and I'm probably wading into a hornets nest of trouble, but this has crept up on me as my two children are getting older (12 and 8) and starting to use electronic devices more and more for school, for entertainment, etc.
They've always had gadgets, probably my fault, but as they start to use them on their own and increasingly need to find things out on the big bad internet I'm thinking of further solutions to help keep them 'safe' or at least to help know when they're wandering away into something they shouldn't so we can talk about it.

This is the first issue, do you give unfiltered access to your children (or anyone in your house?) and then tell them off for going onto something they shouldn't, or should you filter the access then explain why something came up as blocked to them and explain? As an ISP network engineer this is a particularly thorny question as various ISPs now apply network-wide blocks on content, which I believe is totally WRONG. I do not agree with external 3rd parties determining what I can or cannot do or connect to. That is because I'm an adult and I know when I choose to view something that is questionable, that it is questionable. I don't need to be told that, nor do I need to be told off for it!
However, when it comes down to children then I believe it is the parents responsibility to help safeguard that child. You wouldn't let your child play on a main road, the internet is comparable (ish! creative/written license here) and so you would want to protect and guide them.
This is where I firmly believe the onus is on the parents. And as such I am taking that responsibility on and looking at how do achieve this in the best possible way. In my case I am lucky, I've worked around ISPs and the internet since before 2000 and so have a bit more knowledge than most on what you can and cannot do practically speaking.

Devices, my children have access to several devices around the house, so whatever protection I use needs to be consistent and also ensure that devices don't slip through the net. They use android tablets (The excellent Hudl2), iphone's (evil devices, but they are must-have's for children now apparently) and a desktop PC running Windows. I have two WIFI SSID's setup at home, one for the children and 'guest' access and another for myself and my wife with unfiltered, access to work, etc.
All the children's devices are connected to their WIFI SSID and using that router I have forced the DNS provided to use opendns (now part of Cisco). They provide very basic category filtering based on your public IP address as an identifier and you can then tick which categories you wish to permit. This is a very simple filter set and not very granular, it's also not 100% foolproof as anybody who works in IT knows, it bases it on the devices accepting the DNS entries given out by DHCP on your WIFI router and that the child doesn't tinker with these settings. It also doesn't fully work around proxies, so this I use as a 'simple' filter point but don't entirely trust it to work fully. An example of how this could FAIL would be, permit youtube access, so opendns will then let them get to youtube but that that point they could search and do anything on youtube, so it doesn't do anything further to protect them. That said, it does log access and will tell you on violations and also the general amount of internet traffic being used (again it's a rough estimation as it's based on DNS queries, not website hits, so it's a rough number). Accounts with opendns are FREE so this is good to get started with.

I'm going to digress here a little and talk about losing devices. Since we have portable devices (android tablets, iPhone) we have the potential of them being lost. For android devices the excellent Avast antivirus solves that so easily. Install the software onto the android device, set it with the right anti-theft and location features and attach it to your Avast account. You then have an amazing suite of tools that will help you locate the device, lock it, erase it, monitor it, etc. This is all FREE and is excellent, I've used it many times and it works perfectly. Even better you can connect multiple devices so I've also protected my own phone, wife's and families phones so should any phone be stolen it can be located, locked and erased remotely. Unfortunately the iphone is a different matter. There is the locate option from Apple, however this has never worked when I tried it and unfortunately Avast doesn't support the iPhone yet, so on these devices I've struggled. I've installed Lookout and Prey which have similar lock and erase features but they don't have a huge capability and I've not tested these in anger. They have a free version which is what I use.

So the next problem is protecting content of websites, youtube and sites that are visited. This is where things get a little grey. I don't want the children to be bothered by the filtering that's taking place, but I also expect them to know I'm doing it and that they should be responsible when it comes to using the internet (It's a privilege not a right. Keep saying that over and over. When I was young, the internet didn't exist!). So I started to look for an application that would primarily log and then do basic blocking. Two seemed to fit the bill, Qustodio http://www.qustodio.com/  and Kidlogger www.kidlogger.net . I went onto both and they both provide a free trial which you have to sign up for and get an email, etc. I signed up to both and as Qustodio's email came through first I put in my kids details (Which is good, it only took their name and year of birth, nothing else. So no compromise there in security). My details it just needed email, and a password so again no nasty data gathering.
They provide a windows client to install on the machine and then you use separate logins for each child on the PC which then attaches to their Qustodio profile. It was simple to use and easy to install. The client app seems to be a little resource hungry but I guess that's because of everything it logs (and the PC I'm running it on is ancient).
They give you a 3-day unlimited trial which lets you try everything out, and I'm quite impressed. It will log how long they've been logged in/active for, what applications they are using and for how long (word, excel, browser, etc), what searches and search terms they're using, and will log url's they hit and browse+visit in a timeline view which is pretty nice. It also has the ability to log facebook+social media activity separately but I haven't used this as the children are banned from these until they are age appropriate (I can't believe how many people let their children on these systems when it is clearly prohibited in their AUPs). Each website and application used can be individually logged or completely blocked by the application, or you can set it to ignore to ignore that application or websites activity, so it's good in that you can ignore known safe or sites you don't want to track or monitor. Logging is kept for 30 days, history-wise and you can have up to 5 children and 5 devices on the premium account. After the 3-day trial you revert to 1 child and 1 device and a limited history (unsure how long).
All in all, I'm impressed with Qustodio. It looks like it will help me teach the children about blocking, also I'm going to show them the logging it does and explain that almost everything they do on the internet is logged somewhere along the line, which I think is a good message to give to them and teach them.
If they feel that something they do is worrying if it's logged, then my thoughts are they shouldn't be doing it. That is the principle I believe is the one that works when it comes to internet security.

I welcome comments to this as I really do want to know what others think to my stance on this, be it right or wrong as I think everyone has a slightly different view. Feel free to comment below and I'll try and reply if relevant to all of you.