Hopefully this will save someone some money. All the dashboard lights (instrument cluster, radio buttons, heating control, etc) developed some weird intermittent fault, where sometimes their backlights would not work at all, preventing me from seeing important things like the speedometer, when driving in the dark. There was some strange interaction with the windscreen wipers and possibly the head lights. The Skoda garage wanted £80 or so just do go through their diagnosis process, so I decided to try to fix it myself.
The first thing I found was that the dash light dimming was not working at all. This lead me to suspect that the dimmer was at fault.
Get this switch panel out by pushing the headlight switch IN from the 'off' position, then turning clockwise slightly, before pulling the whole assembly out (I found this out in one of the many fact-filled threads at www.briskoda.net).
Getting the dimmer control PCB out was quite difficult:
The dimmer control came out by prizing the plastic where the dimmer 'module' goes into the front panel with a small flat screwdriver. I couldn't help but damage the plastic, but it's not visible in normal use. I had to put 2 screwdrivers in at once on one side, releasing that, then go on to the opposite side.
The dimmer module itself was also a pain to get apart. A similar technique to above, again using two very small screwdrivers, allowed the two halves of this to come apart (the top half comes off vertically in the image).
The module came in half, and looked like this. The PCB is held in place by small plastic hooks that can be bent out of the way slightly. Turn the board over to reveal...
An Infineon BTS730 high-side power switch with built-in PWM generator. I was able to probe this with a multimeter, and found that in the fault state, although the device was receiving ~12 volts across its power rails, it did not seem to be doing anything (I also made sure the control potentiometer wiper was varying as expected, to rule out a dirty potentiometer track). I replaced the part with another one from an (incompatible, see below) dimmer module I bought on eBay, and it had the same problem. I decided to simply bridge pins on the chip so that the supply voltage is always passed to the LEDs in the dash board. This meant connecting pins 7 and 8, but I decided to bridge all of pins 4-17:
Putting it all back together, the dashboard came back to life. The dimmer of course doesn't work, but ~6 months later everything is still working well. I never had the dimmer below maximum anyway.
I did try just getting a spare from eBay and the scrap yard. A Fabia light switch panel from eBay had slightly different version, which turned out to have a different connector (I stupidly bought this before taking my own one apart):
As well as different internals (although using the same IC for dimming):
I tried taking the IC from this one, but the problem remained, so presumably the Fabia I took it from had the same issue. I also got what looked to be the same thing from an Audi A4 Estate in the local scrap yard (a lot of parts like this have Skoda, Audi, SEAT, and VW stamps in the plastic moulding, as many parts are shared between these companies), but this turned out to have completely different circuitry, despite having a very similar connector:
Like I said, hopefully this fix saves someone some money at some point. If you're going to alter your car's electrics, make sure you have some idea of what you are doing. A short circuit could easily cause damage to some other system in the car. I have not described all the measurements I took to find this fault; you will need to make sure you are happy with what you are doing if you are going to try to make this repair yourself.
Stuff I've worked out
Title?
Since I use Google to find out pretty much everything, I thought I should have a page of things I had to work out for myself because 'the internet' didn't seem to know. Now it will.
Monday, 9 July 2012
Saturday, 7 July 2012
Marzocchi open bath oil seal removal
My 2000 Marzocchi Z1 CR open bath mountain bike forks spewed oil out of one of the legs. This apparently happens because damage to the stanchions damages the oil seals, which then leak oil during fork compression. The service manual available from Enduro Fork Seals is good, but the stage for removing the old oil seals proved to be pretty much impossible using the screwdriver method suggested:
Top: Screwdriver wrapped in tape. Middle: Tyre lever. Bottom: Spanner wrapped in tape
The screwdriver didn't move the seals at all (tape is important so as to not damage the upper edge of the fork, where the dust seal sits), and was actually bending. The tyre lever idea suggested somewhere on singletrackworld forums sounded good, making damaging the fork lower impossible, but the lever was going to fold in half before budging the seal (kind of predictable given that the screwdriver was bending I suppose). My spanner idea worked well. A bit of cardboard protected the floor, and a socket extension stopped the spanner falling over while prizing the seal out with my weight on the spanner. I used an 11/16" spanner, not wanting to risk damage to a useful metric spanner.
(It worked best with the spanner the way up shown in the first of these two photos).
Putting weight near the taped end of the spanner allowed the seal to be prized off pretty easily by carefully pulling back (left) on the fork lower, then rotating it ~120 degrees, and repeating, until the seal came gently out.
I did try heating the whole thing up with hot water, but this didn't seem to make it any easier.
I accept no responsibility if you snap your fork, poke yourself in the eye, burst into flames, or whatever, if using this method. The safest plan is to just take the fork to a shop to be serviced.
[edit] Check out the 3rd post in this thread... this is why I gave up on the screwdriver method! [/edit]
Top: Screwdriver wrapped in tape. Middle: Tyre lever. Bottom: Spanner wrapped in tape
The screwdriver didn't move the seals at all (tape is important so as to not damage the upper edge of the fork, where the dust seal sits), and was actually bending. The tyre lever idea suggested somewhere on singletrackworld forums sounded good, making damaging the fork lower impossible, but the lever was going to fold in half before budging the seal (kind of predictable given that the screwdriver was bending I suppose). My spanner idea worked well. A bit of cardboard protected the floor, and a socket extension stopped the spanner falling over while prizing the seal out with my weight on the spanner. I used an 11/16" spanner, not wanting to risk damage to a useful metric spanner.
(It worked best with the spanner the way up shown in the first of these two photos).
Putting weight near the taped end of the spanner allowed the seal to be prized off pretty easily by carefully pulling back (left) on the fork lower, then rotating it ~120 degrees, and repeating, until the seal came gently out.
I did try heating the whole thing up with hot water, but this didn't seem to make it any easier.
I accept no responsibility if you snap your fork, poke yourself in the eye, burst into flames, or whatever, if using this method. The safest plan is to just take the fork to a shop to be serviced.
[edit] Check out the 3rd post in this thread... this is why I gave up on the screwdriver method! [/edit]
Friday, 18 May 2012
Road wear
Well I posted this on slashdot. It seemed like I should put it somewhere more linkable, as I'm actually quite proud of it [edit] hmm.. [/edit].
Having heard that road wear is proportional to the fifth power of axle weight, I thought I would see what wear proportion that works out as for HGVs, given that there are presumably more cars than trucks, and the differing mileages of these types of vehicle. As I write this, I have not done the final calculation. I will use a couple of papers and some government statistics.
Looking at a couple of papers (The economic and environmental benefits of increasing maximum truck weight: the British experience, Alan C. McKinnon, 2005. The cost of relying on the wrong power—road wear and the importance of the fourth power rule (TP446), Richard Johnsson, 2004, Impacts of Increased Goods Vehicle Weight Limits - A European Case Study, Proceedings of Fourth International Symposium on Heavy Vehicle Weights and Dimensions, 1995, the exact proportion of axle weight to road wear varies depending on factors including road surface type, anywhere from 3rd or 4th power of axle weight, all the way up to the 9th power. I chose 4 as a lowish-average.
Taking a Heavy Goods Vehicle (HGV) weight of 15 tons and an average of 4 axles (HGV maximum weights: a brief guide gives a maximum for HGVs of 44 tons over 6 axles, and I don't have a good source, but the minimum to count as a HGV is 7.5 tons, presumably with 2 axles), this gives 3.75 tons/axle. For cars I assumed 1.5 tons and two axles; 0.75 tons per axle. The ratio of these figures is 5. 5^4 = 625 times as much road wear per axle.
Traffic statistics are in vehicle-kilometres, so to use these we need to multiply this back up by the number of axles per vehicle. 4 for trucks and 2 for cars gives 625*(4/2) = 1250 times as much road wear per vehicle per kilometre.
Keeping with the euro theme, I got transport statistics from the UK department for transport. 240 billion miles driven in the UK in 2011 by cars/taxis, heavy goods vehicles 16.4 billion. 240/16.4 = 14.63 times as many miles driven by cars, compared to heavy goods vehicles (I have deliberately left out 'vans', or other vehicles that carry smaller loads than the HGVs that my axle weights are for). So now we have 1250 times as much road wear per vehicle for HGVs, divided by 14.63 as the ratio of cars-HGVs, gives 85.4 times as much road wear by HGVs. Take the reciprocal and subtract from 1 to get that as a proportion, 0.988, or 98.9%.
My estimate for axle weight for HGVs I think is low if anything; I could easily have gone for 20 tons over 4 axles, which would have given 99.6%. I have also assumed that HGV weight is evenly spread over the axles; it strikes me that the rear axles will carry more weight, and so since the road wear varies with the 4th power of this, the real figure is probably higher.
Having heard that road wear is proportional to the fifth power of axle weight, I thought I would see what wear proportion that works out as for HGVs, given that there are presumably more cars than trucks, and the differing mileages of these types of vehicle. As I write this, I have not done the final calculation. I will use a couple of papers and some government statistics.
Looking at a couple of papers (The economic and environmental benefits of increasing maximum truck weight: the British experience, Alan C. McKinnon, 2005. The cost of relying on the wrong power—road wear and the importance of the fourth power rule (TP446), Richard Johnsson, 2004, Impacts of Increased Goods Vehicle Weight Limits - A European Case Study, Proceedings of Fourth International Symposium on Heavy Vehicle Weights and Dimensions, 1995, the exact proportion of axle weight to road wear varies depending on factors including road surface type, anywhere from 3rd or 4th power of axle weight, all the way up to the 9th power. I chose 4 as a lowish-average.
Taking a Heavy Goods Vehicle (HGV) weight of 15 tons and an average of 4 axles (HGV maximum weights: a brief guide gives a maximum for HGVs of 44 tons over 6 axles, and I don't have a good source, but the minimum to count as a HGV is 7.5 tons, presumably with 2 axles), this gives 3.75 tons/axle. For cars I assumed 1.5 tons and two axles; 0.75 tons per axle. The ratio of these figures is 5. 5^4 = 625 times as much road wear per axle.
Traffic statistics are in vehicle-kilometres, so to use these we need to multiply this back up by the number of axles per vehicle. 4 for trucks and 2 for cars gives 625*(4/2) = 1250 times as much road wear per vehicle per kilometre.
Keeping with the euro theme, I got transport statistics from the UK department for transport. 240 billion miles driven in the UK in 2011 by cars/taxis, heavy goods vehicles 16.4 billion. 240/16.4 = 14.63 times as many miles driven by cars, compared to heavy goods vehicles (I have deliberately left out 'vans', or other vehicles that carry smaller loads than the HGVs that my axle weights are for). So now we have 1250 times as much road wear per vehicle for HGVs, divided by 14.63 as the ratio of cars-HGVs, gives 85.4 times as much road wear by HGVs. Take the reciprocal and subtract from 1 to get that as a proportion, 0.988, or 98.9%.
My estimate for axle weight for HGVs I think is low if anything; I could easily have gone for 20 tons over 4 axles, which would have given 99.6%. I have also assumed that HGV weight is evenly spread over the axles; it strikes me that the rear axles will carry more weight, and so since the road wear varies with the 4th power of this, the real figure is probably higher.
Saturday, 10 March 2012
Can't boot from a CD?
Short version: Make sure the IDE controller that the CD drive is attached to is actually enabled.
The BIOS on my ASUS motherboard allowed me to choose 'ATAPI CD Drive' as a boot device, and on boot, no matter what CD (or CD drive) I tried, the drive would make a few noises, but the system would not boot from it. It turns out that the ATAPI device I had selected was actually some sort of dummy device; the system wasn't even trying to boot from the CD I had put in, because the Marvell IDE/PATA controller the CD drive was connected through was not actually enabled. With the controller enabled (somewhere in BIOS), there was a new, 'real' CD drive to select as a boot device, which of course worked straight away.
The BIOS on my ASUS motherboard allowed me to choose 'ATAPI CD Drive' as a boot device, and on boot, no matter what CD (or CD drive) I tried, the drive would make a few noises, but the system would not boot from it. It turns out that the ATAPI device I had selected was actually some sort of dummy device; the system wasn't even trying to boot from the CD I had put in, because the Marvell IDE/PATA controller the CD drive was connected through was not actually enabled. With the controller enabled (somewhere in BIOS), there was a new, 'real' CD drive to select as a boot device, which of course worked straight away.
Asus EZ Flash "ROM ID in the file is incompatible with with existing BIOS"
Short version: Burn the new rom to CD, or try a different USB key.
I found a lot of threads about this, but none had my eventual solution. I tried to update my BIOS with every version they had on the ASUS website using the EZ Flash utility in the BIOS tools menu, having transferred them all to a USB mass storage device. Every one of them gave a "ROM ID in the file is incompatible with existing BIOS" error. After probably two hours of dicking around trying to get different DOS boot CDs to work, in a vain effort to try to use the AFUDOS to perform the update, I eventually discovered that those same images, when burnt to a CD, could be used by EZ Flash without issue.
I found a lot of threads about this, but none had my eventual solution. I tried to update my BIOS with every version they had on the ASUS website using the EZ Flash utility in the BIOS tools menu, having transferred them all to a USB mass storage device. Every one of them gave a "ROM ID in the file is incompatible with existing BIOS" error. After probably two hours of dicking around trying to get different DOS boot CDs to work, in a vain effort to try to use the AFUDOS to perform the update, I eventually discovered that those same images, when burnt to a CD, could be used by EZ Flash without issue.
Thursday, 12 January 2012
Filtering based on any old byte(s) in Wireshark
Well this one is no doubt somewhere in Google, but knowing what to type in wasn't obvious for me at least. I wanted to filter some (well, over a million) captured packets in wireshark that had a protocol not in the list. I looked at... hmm nobody cares about this story do they. Short version is that you select the 'frame' protocol, which is actually a dummy protocol that gives you the whole frame. In the filter 'Expression' dialogue, choose 'frame' for protocol, but just select the top level item. Then select your operator, type the test bytes in the top right data-to-test-on box, then in the bottom right box labelled something like 'Range' enter the byte offset and number of bytes you are planning to filter on. in my case 209:1. More details at http://www.wireshark.org/docs/man-pages/wireshark-filter.html#the_slice_operator
Thursday, 13 October 2011
Xilinx ISE Global Signals (VHDL)
No, they don't work. You can add probes in the FPGA editor, or, to avoid having to edit loads of modules to bring signals up to the top level in the code, put 'records' in the port definitions instead of normal signals. These can easily be edited in a package file to add more signals (e.g. for debugging).
Subscribe to:
Posts (Atom)