Monday 26 September 2016

433Mhz transmitters deciphering and teardown

I've been doing yet more digging around with these little 433Mhz transmitters. These are the ones found in a lot of home automation hardware now, as well as wireless alarm system, remote garage door and shutter controllers and a lot more.
I've got a few different ones here at home, so I thought I'd go through each one and work out how they work and what different functions they leverage for their operation. The main goal behind this was to determine reliability (Which I'll get onto later).

Here are the 5 different models I have:




X11 alarm remote

X11 light control

Garage door/Shutter remote

Alarm door sensor

Alarm remote control

All five of these have remote control capabilities and operate in a similar way, so the first thing was to take a look at how they all operated.

The first was the X11 alarm remote:


That's both sides of the small board inside. Difficult to see, but on the top photo is the battery source (2x3v) and to the right of it is the 433Mhz transmitter 'can' with 433 printed onto it, so I know it's a 433mhz transmission type. Looking on the back was interesting though, it didn't have one of the 'standard' chips used for 433Mhz transmission, and actually had a custom 14-pin chip in it with no markings at all on it. My guess is this is a custom mini microcontroller with custom firmare burnt onto it. There were very few other components, a diode, resistors and an LED. So not much to go on. I started my 433Mhz sniffer application (Using an arduino with a 433Mhz receiver chip connected) and got no signal at all on any mode. This makes me think they are doing custom modulation with the 433Mhz signal and no much chance of decoding it.

The second one I tried was another X11 remote, this time just used for lighting control:
On this one there was the transmitter can in the middle (With the red insulating foam around it) but no mention of 433Mhz. I assumed it would be. I then looked into the chip in the middle, which was a EM78P153AN. Looking this up, I found it to be an 8-bit microcontroller with OTP ROM, so again a chip with custom firmware burnt onto it. Again not many other components on either side of the board, a few resistors, diodes and that was about it. Running my 433Mhz sniffer I didn't get anything I could decode, so again assuming this is using similar coding to the previous X11 remote and can't get into what it was sending.

The above two isn't entirely surprising, X11 protocols for their remotes are 'encrypted' or at least made to not be easy to hack or replicate using standard duplication techniques. Whether they use rolling codes or not I'm unsure, but they certainly have the ability to do this since they have the custom microcontroller on board which could run all sorts of interesting code.

I then turned my attention to the more 'basic' 433Mhz transmitters. Firstly the one for the garage door/shutters:

This one was for a commercial shutter. Any to my surprise when opened up, the 'can' said it all! 13,560Mhz! Now this was supplied by a shutter company for use here in the UK, I'm not 100% sure but I don't believe these are legal to use in the UK due to licensing.
Looking at the rest of the board, there is a 430G2332 chip which is a mixed signal microcontroller, and beside it the 7110FE which is either a second microcontroller or a voltage regulator chip. Either way this remote wasn't much use since it wasn't 433Mhz so I didn't investigate any further.


This then takes me onto the alarm sensor unit:


On the front of the board (Bottom photo) you can see the multicolour LED top left (Red and Green), then the top right is the can for the 433Mhz crystal. To the left is the reed switch (for the door) a capacitor and then to the bottom (above the battery slot) are 4 dip switches. These vary the code transmitted (well, the first two, the 3rd and 4th don't seem to make a difference).
On the back of the board we can see the main chip (towards the bottom of the board). It's covered in resin gunk but I could still make out the chip which was EV1527 OTP encoder which is on most of the 433Mhz boards. The 8-pin schematic shows:
And can take a voltage range from 3v to 12v. And by setting K0-3 to either 1 or 0 it will change the data output (D0-3). In this units case it only appears to have two of these linked to the dip switches but I'd assume you could connect the rest up if you wished. Looking at a close-up of the circuit I can see where the traces are missing:

So the common row of 4 pins along the top of the DIP switches go to a connection pad (see below, this is the reed switch connection). Then only one line is brought down from the chip (pin5 K0) so this is the only one that will be affected by changing the DIP switches. So effectively this version allows two values to be chosen.
However, this is almost unrequired, as the chip itself has a burnt-in at factory value as part of the output code:
So the C0~C19 is burnt into the chip and forms part of the initial code, followed by the user-defined 4 character selection. This should therefore mean that no two chips are identical (assuming we don't hit the same code from the choice of 1 million!) in their transmitted codes, so should be safe from colliding with another unit.
The reed switch lower solder joint goes to the top row of pins on the DIP switches (and so ultimately to pin 5 K0). The other side of the reed switch goes to capacitor C1 (tiny smd) and to J3Y which is a switching transistor, which will be to handle the switching voltage for the chip.
Pin 6 is pulled to ground constantly (as it the ground pin for the chip).
The positive pin (2) for the chip is only energised when the transmitter needs to be powered up, and so is therefore controlled by the rest of the circuits switching transistors and trigger with a timed value. This therefore allows the circuit to detect when the reed switch is broken it will trigger a timed burst of voltage to the chip and transmit it's signal. This only works because this is a one-way circuit, it only transmits, so has no method of testing battery voltage and letting the alarm know, nor does it know the state of the alarm or any other state. It simply gets woken up by voltage being sent to the chip which immediately starts transmitting it's value and then gets power removed.
This method is good for low power consumption as when not transmitting it'll use very little idle power (Just a transistor switch, remember we want to trigger the signal when the circuit is broken, so it's known as a NC normally closed circuit).

However this also highlights the weakness in this system. Firstly the system only has one go at sending data, if that fails then there are no retries. In practice I've tested this with my 433Mhz receiver and I do only see a single transmitted value from the unit when the reed switch is removed. So the alarm receiver has to get the signal the first time, otherwise it would be missed. This is where an improvement should be made and setup so the signal repeats several times.

Another unknown for now is the multi-colour LED. It has both red and green in the package, and will trigger both colours. When the reed switch is triggered the red LED will come on then flicker red and green (and off) until completely off. This seems to be a capacitor discharge timer/reduction of power, so I think the circuit must charge the capacitor (47uF 16v on the front of the board?) and then use the capacitor discharge to supply power to the transmitter circuit. I'm therefore unsure what the different colours indicate. There is also the push button on the front of the board. This forces the transmission of the code. I'd expected this to simply bridge the reed switch, but upon learning about the circuit (and realising it's NC) then this couldn't be possible. Therefore it seems to force a power 'jolt' to the circuitry and forcibly power up the chip. This keeps repeating the code so it is powered direct from the battery I think. This causes the LED to flicker red and green constantly until I release the button, at which point the LED stays lit up GREEN! It won't go off until I remove the battery, so is almost like a power indicator showing that power is being supplied by the battery (but not supplied to the chip).

UPDATE: I did a bit more testing and worked out the LED colour conditions! They indicate battery state. The battery I was testing with was an older one (These are 23A/MN21 12v batteries) and actually on testing with the meter showed only a 6v output without load. Therefore this shows that I believe the green/orange light indicates low battery/poor output state. I think it was keeping the green LED on to show that voltage was low and needed replacing! (Would be better the other way round, red instead of green!) Putting a full battery in (showing 12v) when moving the reed switch away the LED lit bright RED and transmitted it's code twice before the LED flickered and went off. (No green shown on the LED at all) So this appears to be a basic indicator for battery state, when low it will show yellow/orange/green to tell you to replace!

The transmitted code can be read by my 433Mhz receiver and I can see it's a simple code being sent at 24-bit, an example of a code would be 3528277. This I can see repeated at each trigger, so they aren't rolling codes or anything sophisticated.
I can therefore transmit this code and 'emulate' the sensor if for whatever reason I needed to.


The alarm remote control was the last unit I took a look at.

It contains four buttons for 'SET', 'UNSET', 'HOME-SET' and 'PANIC'. These four seem to send different codes, so I suspect they simply set the different K0-3 pins on the same chip.
Here is the circuit itself, you can see the BXR433A can to the top middle, the 12v battery sits in the middle.
At the bottom middle you can see the SCT2260 (Also known as the PT2260) chip which does the RF encoding. This uses a similar technique to the other 433Mhz transmitter chips and the pin-out along with an example 4-button transmitter is on the datasheet:

So that looks like how this unit is being used.


Finally, I wanted to find out a constant bug that was appearing on my setup. On the remote transmitters, these seemed to sometimes fail and not set or unset the units. This is strange as the LED on the transmitter always lit up and it always appeared to send a code. Sniffing the codes I can see a code transmitted at every press of the buttons. HOWEVER the code sometimes changed (and not just once. When it happened the transmitter would send 3 or 4 of this incorrect code, not changing). Initially I dismissed this as just because of poor antenna or receivers or similar, so this is something to investigate further.
That's for the next part of debugging I think!


Monday 12 September 2016

5ive U80 android-compatible smart watch

This is my thoughts on the 5ive U80 android-compatible smart watch.


I've had the watch for a couple of weeks now and so I've got used to how it works, what's good and what's bad about it, so here's my review on it.
Firstly, setup and use. Initially it doesn't power on with a single touch, you have to hold it's main button in for a bit longer than you'd normally like to for most gadgets, but bear with it, it'll light up and say "Welcome" when it starts to power on. Boot time is around 5 seconds which is pretty quick and indicates it runs a ROM-based basic operating system rather than Android or any other full operating systems. (So beware, whilst it says Android on most of the promotion material, it means it's compatible with Android phones and doesn't run Android itself, so you can't install apps from the play store/market or APKs onto it)
After boot up it shows the main screen giving you time and date, along with some status icons along the top. These show bluetooth connectivity, received notifications and text message notifications along with battery state.
The rubber strap is really comfortable to wear, I'm not a keen watch wearer but found this one sat on my wrist (Which is very skinny, so it fit great, on the second or third hole, so it's no problem for kids or skinny wristed adults like me!) comfortably. The screen is large but not too large to look ridiculous on my arm and the main button is unobtrusive and needs a proper click to engage so you won't be turning the screen on constantly by mistake. There isn't a motion/movement detector switch-on function on this watch.

To connect the watch to your phone you need to use bluetooth, just pair it like any other accessory, which is pretty straight forward. It will display a random 4 digit pairing code on the screen, key this into your phone and accept it, it'll then pair up and connect (It will show you onscreen that it's connected and paired). That's the basic connectivity working. It will act as a handsfree speakerphone, display active call information and missed/last calls. It will also let you use the built in functions such as stepcounter, timer, activity monitor, etc. These are all pretty basic and simple to use.
If you want to view text messages, get notifications for other events on your phone, etc, you need to install a specific application onto your phone that will push the notifications to your watch.
I found the app which worked best was BTNOTIFICATION. Install it from the android market and then configure the "Notification app" section which lets you choose what applications on your phone can send notifications to your watch. It's basically allowing you to choose what notifications you normally see along the top bar of your phone on the watch, so choose which ones you want (along with system notifications too) and allow it to connect. I had to switch off and on bluetooth on the phone a couple of times for the watch to pair correctly and show all these functions. When it pairs correctly it will connect and show "connected" twice on the phone, kind of showing the basic connection, then the push notifications. On the phone you'll see the bt notification icon in the notification area along the top showing it's seen the watch and sending notifications.
This then allows you on the watch to click menu (left button along the base of the watch) and choose either your messages for txt inbox, or the notifications menu to see other notifications (emails, etc, as per the applications you setup on your phone).
The touchscreen on the watch is pretty responsive and swipes and multitouch seem to work accurately. I was impressed at such a low-price watch how clear the screen was and that it never seemed to lag or slow down in functions.

Now onto a few of the downsides of the watch. The first is that it will default to be your bluetooth handsfree/headset app for the phone. So each call you answer will automatically go to the watch and be answered on speakerphone! Not ideal, especially in an office or other environment, the first bit of your call isn't private until you switch back to the phone handset, etc. (On my HTC One m8 it pops up immediately and asks what device I want to use, so I just quickly select the handset)
The watch will show the call status throughout your phonecall and also show a hangup button to cancel the call, mute your microphone, etc. When somebody rings it will also show who is calling you and give you the option to answer or reject the call.
I tried to disable the headset function of the device, by going into bluetooth settings on my phone, settings for the U80 bluetooth association and untick phone audio. The problem here is that with that unticked the notification app and sync between the two isn't established, so full notifications don't get sent to the watch. So effectively if you do this, it becomes useless, so you can't disable it!
The three touch-screen fixed buttons on the homescreen aren't configurable, so you're stuck with the shortcuts of: Bluetooth settings, step counter and calorie tracker.
The battery life, initially appeared good, almost 2 days on my first try, but it seems to have dropped quite quickly. I'm now able to get 1 day out of it (fairly light use), but you must charge it overnight to have this, if you leave it powered off and not on charge it doesn't seem to retain charge and will drop out early. The battery indicator doesn't give you a clue either, it's either full, almost empty or empty and when it warns you the battery is low you probably have 10-15 minutes before power off completely.

Charging it, I used my USB voltage and current monitor to see how much it pulls when charging (I used a 2amp capable charger) and it was very low, only 0.19 amps were pulled initially and after about 30 minutes this dropped quite quickly to only 0.02 amps, so a tiny trickle charge, so my suspicion is it's either got a very low capacity ni-mh battery in it, or it's charge circuitry isn't that smart.
On the usb indicator, red is voltage and blue is current (in amps)

Overall, it's a nice enough watch, as a watch it works fine! As a smart watch it does the basics OK, and will act as a speakerphone. Don't expect much more from it, and unless there is an update the fact it acts as speakerphone to all calls makes it my biggest negative for everyday use.

Specifications:
Screen Size: 1.44-inch
Screen Resolution: 128 x 128 px
Touch Module: Yes
Battery Type: Lithium-ion Polymer battery
Battery Capacity: 3.7V/230mAh
Processor type: MTK6260-ARM7 Speed 360MHz
SRAM: MTK6260(Built-in)-32mb NOR
Flash: MTK6260(Built-in)-32mb
Camera: No
Speaker: 8/0.7W speaker x 1
Microphone: Yes
G-sensor : Yes
GPS: No
Bluetooth: Yes, Bluetooth 4.0
3G/2G: No
Memory card socket: No
USB interface: Micro USB
Headphone jack: No
Operation System: MTK
Phonebook entries: Max. 1000
Phone calls: Yes (Loudspeaker)
SMS: Yes (thru Application)
MMS: Push (need application)
Time Sync: Yes
Call History: Yes
Music Player: Yes
Set Time/Date: User-defined
Alarm clock: Yes
Stopwatch: Yes
Pedometer: Yes
Rest Alarm: Yes; Reminds you to stand up or start physical activity
Drink Alarm: Yes; Reminds you to drink more water
Sleep monitoring: Yes
Anti-theft Alarm: Yes
Power saving mode: Yes
Languages: English, French, Spanish, German, Portuguese, Italian, Dutch, Russian, Turkish

Hacking-wise, connecting the USB up to my linux laptop (Don't use the supplied usb cable as it doesn't have data lines connected!) I could see the device. Watch needs to be powered off and it becomes visible as:
Bus 002 Device 009: ID 0e8d:0002 MediaTek Inc.
[27755.648566] usb 2-1.2.2: new full-speed USB device number 8 using ehci-pci[27755.961281] usb 2-1.2.2: New USB device found, idVendor=0e8d, idProduct=0003[27755.961290] usb 2-1.2.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0[27755.962847] cdc_acm 2-1.2.2:1.1: ttyACM0: USB ACM device[27756.119144] usbcore: registered new interface driver usbserial[27756.119168] usbcore: registered new interface driver usbserial_generic[27756.119188] usbserial: USB Serial support registered for generic[27756.177096] usbcore: registered new interface driver option[27756.177138] usbserial: USB Serial support registered for GSM modem (1-port)[27758.507798] usb 2-1.2.2: USB disconnect, device number 8[27761.800152] usb 2-1.2.2: new full-speed USB device number 9 using ehci-pci[27761.913019] usb 2-1.2.2: New USB device found, idVendor=0e8d, idProduct=0002[27761.913028] usb 2-1.2.2: New USB device strings: Mfr=2, Product=3, SerialNumber=4[27761.913034] usb 2-1.2.2: Product: U8 [27761.913038] usb 2-1.2.2: Manufacturer: U8[27761.913043] usb 2-1.2.2: SerialNumber: fffffffffffffff[27761.914079] usb-storage 2-1.2.2:1.0: USB Mass Storage device detected[27761.917187] scsi host5: usb-storage 2-1.2.2:1.0[27762.916956] scsi 5:0:0:0: Direct-Access     MEDIATEK  FLASH DISK           PQ: 0 ANSI: 0 CCS[27762.917522] sd 5:0:0:0: Attached scsi generic sg2 type 0[27762.926813] sd 5:0:0:0: [sdb] Attached SCSI removable disk
So you can see it registers as a usb serial device and also as a storage device. It initially registers as usb serial, disconnects and comes back as a storage device. I suspect this is the usb_modeswitch drivers for linux getting in the way so after disabling it still did the same. It appears as a serial device for a few seconds before the screen comes on with "Welcome" and it then switches to a storage device. The /dev/sdb cannot be accessed though and has no partition structure. I'm going to try and dump /dev/sdb to see if it contains the firmware or similar.
When powering the watch up it prompts for "serial usb" on screen. Pressing this and it stays as a usb serial device that I can then access.
Connecting to it using 9600,8,N,1 and I can get a prompt. I can send it an AT and it responds OK so it has some sort of AT command set registered with it. I couldn't get it to give me anything interesting, but there must be something in there!
AT
OK
AT+I
ERROR
ATI0
ERROR
ATI1
ERROR
AT+CREG
ERROR
AT+WS46=?
ERROR
ATX4
ERROR
ATA
NO CARRIER
ATDT01642216204
NO CARRIER
AT&V0
ERROR


So if you have any ideas or further information, please leave a comment and I'll do a bit more investigation.

5ive U80 on amazon.co.uk £29.99
Please note that I received in exchange for an honest and unbiased review for a discounted value.

Thursday 8 September 2016

Follow up: Wireless home alarm system from ebay 433Mhz

I've finally installed and setup the alarm I bought from eBay a few weeks ago (See post: http://www.thebmwz3.co.uk/2016/08/wireless-home-alarm-system-from-ebay.html ) and found a few extra little notes to add to anyone using it or looking to buy.
Firstly, the setup is actually straight forward, as per my previous blog post on it, configuring it and getting it working was simple enough.



I ordered a sim card (It needs to be an older 2G version) from o2, put some credit on and installed it, works great it sent me a text when power failed, power returned and when the alarm had triggered and the reason for the trigger. Pretty neat. I found that it was better to power off before inserting the sim as sometimes if you inserted it with power on it didn't recognise it and start to use it. A few interesting features I found, firstly if you ring the alarm from another phone it'll answer (give it quite a few rings) and it'll ask for your pin code (just the standard pin/alarm code) and give you the options: 1 to arm, 2 to disarm, 3 to monitor (listen) or 4 for intercom. There are also a couple of hidden options, press 5 and it triggers SOS/panic and goes to alarm straight away. I also found the * option played back what sounded like a technician setting the system up (In a language I didn't recognise so can't tell what he was saying!), I'm assuming that was a pre-recording loaded onto the sound chip by mistake and they probably didn't intend anyone to find it!
Unfortunately it didn't tell you the current state of the alarm which was one thing I was after.

Installing the wireless sensors was easy enough, they came with fixing brackets and also double-sided sticky pads, and it was easy to fit and test.
These are very basic 433Mhz devices, found in a lot of hobby electronics (and arduino kits), and in this alarm they seem to be only 1-way units, i.e. the sensor sends it's alarm state to the control panel, no return path from the alarm to tell it when it's armed (to save battery life), whether it's been tampered, if it's still alive (dead battery), if it's signal is OK (doesn't detect jamming/malicious signals), etc. So this is the true weakness of the system.

Here are the insides of one of the door sensors.



You can see the typical 433Mhz can at the top right (R433A), along with the spring antenna it uses. On the left is the reed switch and top left is the tri-colour LED. On the back are the electronics and it's all controlled by the chip you can see middle right of the photo. The chip is the typical EV1527 OTP encoder with configurable code setting.

I did like that they left in the jumpers for helping to set a 'random' coded sequence on them, the theory being you set these to random positions so they're unique to your alarm and individual sensor setup. I changed mine just because I could and in theory thought anyone near me (There is probably only one house close to me!) wouldn't bother/know this. They also need to be unique otherwise two sensors will share the same code and trigger the same input.

Note that they came with the 23A 12v battery installed, and I've had at least two die since installation, so I'd say go out and buy a pack of them and replace them as soon as you purchase.
This has also exposed another weakness, knowing when the batteries run down. Most of the time you notice the little red flicker when you open the doors, but that means you wait until they're dead before replacing. There is also an odd flicker pattern. When you open the door it goes bright red then flickers 3 or 4 times getting dimmer each time. (Capacitor discharge timer?) If you press the button and hold it the red light flickers then goes orange and green. I've got no idea what the different colours of the lights mean, so when I've replaced the batteries with new ones I'll add extra info here on them, my hope is they are green for good battery and drop to red/orange when low battery (Too much to ask?).

Next was wiring up an external bellbox. Although one came with the unit, I also had a traditional bellbox that I could use. As normal this had various feeds into it, labelled:
holdoff - and + = These are the power supply (12v) to the unit that charged the battery and also acted as the power feed.
STB - = Strobe negative switched trigger
TRG = Siren negative switched trigger
LOOP = negative feed from alarm (This acts as a tamper circuit)

The problem here is that the alarm uses positive switching for it's alarm trigger output (On the back of the alarm it's BZ+ and BZ-, BZ- is common to ground so not switched), so therefore I had to be a little creative. A cheap 12v optocoupled relay looked like the best option (http://r.ebay.com/EvgMbn)

Which you feed with 12v constant and then when the IN terminal goes high it'll activate the relay (If you set the switchable trigger to HIGH). This way it protects the alarm from any noise/spikes from the relay itself and triggers on high. You can then connect the holdoff - (supply) to COM on the relay and then feed NO to the TRG and STB terminals, so when the relay is triggered it'll set the alarm off. It also has the advantage that the battery built into your bellbox can be enabled so if wires are cut, etc, then it will trigger the sounder on it's own.

The next part to tackle was a magnetic door switch (non wireless), this was for the garage doors. So I had the relevant magnetic reed switch, just needed to feed two wires back to the alarm from it, and wire them into the Z1 contact. This is wired in between common/ground and the zone input (with a resistor in series too). The manual wasn't very good at explaining how to wire it, so it was a bit trial and error!



So if you have normally closed contacts (Like most magnetic door switches are) then you put the resistor inline (10k ohm supplied in the box) and connect back to ground.
For a normally open contact you put the resistor in parallel to your sensor and wire it into ground and the zone you need.
(Ignore the Pusitive (!) and power supply lines, I have no idea why they included them on this diagram unless to show electrical isolation)

Setting up the wired zones didn't seem to go right to start with, but I finally figured it out.
Each zone you can setup with one of the following modes:
0) Sensor will not trigger in any status (disabled zones)
1) Sensor will trigger the alarm when in out or home alarm state
2) Sensor will trigger the alarm when set to out state only (for PIRs, etc)
3) Sensor will trigger the alarm in any status (for smoke alarm, panic alarm, etc)

So to set the wired alarm into state 1 you are supposed to use key function
47811 (47 is the menu code, 81 is the wired zone code range [81-88])
However when I did this the alarm didn't confirm the setting, just returned to the menu, like it was an invalid setting. I then tried each one in turn and it seems 81 didn't accept it, but 82-88 did. I have my sensor still in zone1 and it works in mode 1, so not sure if that is a constant setting for that or something similar, but it seems to work.

All in all, I'm quite impressed. It installed without too much challenge and is working great with the remotes.
A few negative points:

  • Remote-only 'home' alarm mode. There is no way of setting the home mode from the panel itself, so you need a remote to set that mode.
  • Positive triggers (for sounders) as noted above, so needed a relay to solve this
  • No indication (that I've found) that it'll alert me to batteries going low on the sensors
  • No remote way of determining if alarm is armed or not
  • Timer is always active on zones, so no matter which zone is triggering the alarm, the timer starts counting before the alarm sounds
I'm also thinking of changing the resistor on the speaker as now it's in 'production' use it's actually a little bit too quiet, so might change this in the near future.

Next up I'm also going to start to sniff the protocol and traffic going through the 433Mhz system and see if I can also 'read' the sensor states and anything else the units chatter about during normal operations, this may prove interesting as may help determine how 'secure' or at least tamper resistant the system will be. Again this is in theory, because as usual an intruder would need to know this was the system in use, and sniff/understand the frequencies involved to try to use them to their advantage. I suspect brute-force attempts to jam it won't work very well from outside the house, otherwise they would need to learn/replay the remote control codes to help de-activate it, as all other signals would trigger the alarm. (All just conjecture at this point in time)

UPDATE 12/sept:
I've done a little sniffing using my Arduino 433Mhz receivers, and sure enough I can see some of the communications. Generally I can see the PIRs sending their current movement state, so when movement is detected they send a stream of their code. I've not seen any values from the door sensors as yet or other sensors but this may be the mode I've been testing using my Arduino. I've also seen some limited codes from the remotes, they don't appear to be rolling code units but I do see several codes sent on each keypress that I'm going to investigate further.
My conclusion is that it's not got a very secure wireless component to it, it uses hobby electronic frequencies which increase the chance of interference and also jamming/hacking into it. I've not yet tried to replay codes and see if the system accepts or rejects them at this point in time.

Friday 2 September 2016

Top suspension mount replacement - Chrysler Grand Voyager

This is a set of steps and some photos of replacing the top suspension mount in a Chrysler Grand Voyager 2.8CRD 2005 edition. This process should be the same all the way up to the 2007 edition (As far as I'm aware) as these models all share similar front suspension components.

Symptoms, I suspected these were faulty for a while as I had a clunk when steering. About every 1/4 revolution of the steering wheel I'd hear a thuuuunnnggg, a thump that reverberated through the spring (I was guessing) so my assumption was either the bearings had seized up and were slipping at times, or there was something else wrong. Well whilst away on holiday recently one of the top suspension mounts completely collapsed! It made a real rattle and thumping noise whilst moving, especially on uneven roads. Taking the wheel off didn't reveal anything, but looking from the top you could see the damage easily. (You have to take the whole windscreen wiper assembly off to see the top of the struts/suspension mounts)
Here is the damaged top view:

The strut is sticking right up through the mount. To compare, here is the other side:

So, to replace them, order the parts (Eurocarparts did the job for me, decent price and all were in stock too).
Then the process of taking it out, you will need a set (or two) of spring compressors for this job. This isn't an easy job, so one you'll need to plan and have time to do, especially if you hit the problems I did, as you'll see.

Jack the side of the car up, and secure it with axle stands. There is NO excuse not to have these for doing these jobs, they are cheap from Halfords or most car places and will save you. Please buy some as they are key to your safety!
Firstly, take the wheel off and loosen (don't remove) the two main bolts holding the suspension to the wheel hub.

Here you can see where I've taken both nuts off the bolts. These were VERY difficult on both sides on mine, we had to use large breaker bars and a lot of heat. In the end two needed CUT off as they were so well fastened on. So this would be a good idea to have replacements ready. We got ours from a bolt/ironmongers so they weren't Chrysler/Mopar original parts but were very close (and high tensile, ensure you match as close as possible to factory). Once these were off/loose we could move onto the rest of the job. The anti-roll bar joint needed removing, this is on a nut, and around the back there is a slight groove cut into the metal so you can grip it with a molerench or similar.
That's it removed and free floating. You might need to lever it up/down so the pressure is released from it first.

Now move onto the top, so first you need to remove the wipers (small plastic cover hides the larger nut that holds the wiper on), when you pull the wipers off you might need to gently prise them, mine needed quite a considerable force to come off the wiper motor splines. Once off you take the top plastic wiper cover off using a star screwdriver, disconnect the water feed pipe (to the left of the engine, just a push fit connector) and then lift the whole piece out of the way.
Then disconnect the wiper motor power cable (to the right, just above the battery) and start to remove the main wiper tray assembly.
This is held on by two sets of fasteners, the first is at the top of this picture, where the upside down U shape metal brackets meet the bottom of the windscreen there are small nuts, undo all of these.


Then there are four large bolts fastening the whole piece into the bodywork. Here is the hole for one of them this is the far left side just behind where the wiper arm would sit on top of the splines (just visible top of photo)

Once out, lift out the entire motor assembly.
Now the tricky bit! You need to loosen the nut/spindle pair at the top of the suspension mount. This will make it easier later when you have to remove it and it's out of the car.
For this you need a bit of luck when it comes to what tools you have. In our case we used a spark plug socket, and then a smaller hexagonal tool. There may be a 'proper' item to do this, but see what you have available to you. This is what it looked like in place:


And a close-up of the tools we used, hopefully you can match what you need also



We just need to loosen this slightly, don't undo it completely!
Once you've done that, you can loosen the three main nuts that hold the suspension mount in place (you can see two of them in the above picture).
Then return to the wheel arch, remove the two main bolts and get one person ready to 'catch' the suspension, the other undo the 3 nuts from the top. You should then be able to freely drop the suspension out of the arch and take it out.

The next step is to compress the spring. You'll need some decent spring compressors, these springs are relatively short and dumpy, so getting a good purchase on with the spring compressors is vital.

Here is what it looks like with our spring compressors on and tensioned. We compressed more than you can see in this photo:
The way we 'tested' to see if we had enough compression was to grab the top suspension mount and tried to spin/move it. At first it wouldn't move, slowly as we compressed it, it started to free and spin. Once it could spin freely we then removed the top nut that was holding the suspension mount in place. Do this carefully. If there is tension it will fly off, so make sure it doesn't have pressure on it.

Once removed the underside of the suspension mount looks like this. The inner (lighter colour) part is the compression bearing and is removable which leaves the suspension mount, and the faulty part in my case. It wasn't really obvious, but underneath the compression bearing is a piece of metal (like a large washer welded into place, but one piece of metal no welds!) This is the weak point, and in my case although it looked in-tact, one tap with a hammer and it dropped out! So it was clearly weak, one side had given way on me, the other was near to falling out too! So take note. I'm on 113,000 miles. Maybe yours needs done too!
After that, it's a re-assembly. Put the new together (you'll see below, the new compression bearing sat in the right place ready)

Place on top of the suspension spring (make sure you line up the spring and rubber parts so they all sit in their correct markings), and if you've compressed the spring enough, you'll be able to drop the nut on the top and tighten it slightly. If you can't, then compress the spring more until you can. Once that's in and secure (tighten the nut down as far as you can so it is tight/holding tension) then you can start to release the spring compressors.

The re-insertion is just the reverse of the above, push it into the wheel arch into position and fasten with the three nuts at the top. Fasten the suspension to the wheel hub and reverse the process to put it all back together.

In my case, this totally removed the thump when steering, so clearly this was causing the issue.
What this does NOT fix is creaking when you go over bumps or uneven ground. Creaking noises I suspect are anti-rollbar joints/bearings/bushes that are worn and will be my next challenge.

I hope this helps, please do provide feedback or comments on it and I hope this will help you.