Andy Blyth

Without running some calcs, I'd not recommend testing the rectifiers in circuit due to the size of the electrolytics. Even though capacitors should appear as open circuits when taking DC measurements (e.g. diode testing), they do pass a current as they are charging. With the small currents used in testing diodes, it could take a long time to charge the capacitors so they could be affecting your measurements. I'd recommend testing with your oscilloscope. Connect your ground lead to "CON 2 2" or any other ground point and start probing. You should see sine waves at the two inputs to the bridge rectifier. If it's working correctly, you should see a waveform similar to this (the black line) across the capacitor. Make sure you have a load connected when taking these measurements otherwise you won't be able to see failed diodes. If you have any findings, post up some captures and I can suggest further measurements to pinpoint failed components.

If you're able to crank, and can get the fuel pump running with the jumper between FP and B+ (I assume with the ignition in the on position) we can establish that the 120A alternator fuse 50A Main fuse 50A AM1 fuse 7.5A ST (starter) fuse 30A EFI1 fuse starter relay and EFI main relay are OK. There's very few other fuses and relays that are needed to run the engine. Ones to check are 30A EFI2 fuse EFI relay number 2 7.5A IGN fuse (driver's footwell) 30A AM2 fuse That's all of the relays and fuses you should need to start and run the engine. Failing that I would start to check (in this order) Igniter ECU Fuel pump ECU The fact that your fuel pump and starter are working suggest that any alarm or immobiliser is OK, but it's still something to check. Good luck!

I've had exactly the same symptoms. On mine it was due to a spring inside the catch itself corroding then snapping. Without this spring, the catch won't hold itself in the locked position when the bonnet it pressed into it. If one side is broken and the other is still working, the bonnet will appear to be locked, but the release handle stays about halfway out. You can inspect the spring quite easily by removing the nut and the two bolts holding the catch in place. The spring is even available separately from Toyota.

Exactly, right!

The value of the resistors are not as important as you might think - you're making a string of resistors between 5V and ground which will give you evenly spaced voltage values in between, regardless of the resistance. With the values in the pdf, it looks as if the lowest position will be 0.5V and the highest is 4.5V (the switch voltage output will be inbetween the "jumps" in the table). You can create an equivalent switch by getting 10 of the same value resistors (I'd start with something in the region of 220 Ohms each) and connecting the 1st position pin to the 2nd position pin with a resistor, again with the 2nd to the 3rd, 3rd to the 4th etc. After this, connect the 1st postition pin to ground with another resistor and the 9th position pin to 5V with the last resistor. Finally, connect the wiper pin to your ECU input. With this setup, you will have 0.5V across each resistor. With 220 Ohm resistors, the power dissipated in each resistor will be ((0.5V * 0.5V) / 220 Ohms = 0.001W. Half-Watt resistors would be overkill. 1/8th Watt resistors would be sufficient. Let me know if I'm not clear; I'm happy to draw a picture if it helps.

Thanks, I'll give it till the end of the weekend and if I've had no offers closer to home I'll get in touch.

As per title, I'm looking for the lock assembly for the bonnet on the right (drivers) side. Must be in good condition with tension springs also in good condition. Many Thanks Andy

I'm afraid not, Lee

You're welcome Chris. Looking back, two things would have made this very simple: 1> If the high word was guaranteed to be signed and the low word guaranteed to be unsigned, the combine channel would be as simple as: GPS LAT COMBINE = (('GPS LAT HW'*65536)+'GPS LAT LW')/10000000 2> If the GDA software had a function that performed rounding towards zero for both positive and negative numbers (like the trunc() function in the C programming language), the rest of the calculation would be a simple as: GPS LAT = (('GPS LAT COMBINE'-trunc('GPS LAT COMBINE'))/0.6)+trunc('GPS LAT COMBINE') Much simpler! Maybe it's worth putting a request into GEMS!

That's looking pretty good now! I'm pleasantly surprised that it's accurate enough to see the exact line you took on the track. I thought it would only be accurate enough to see how far around you were. Were you overtaking someone on the straight behind the pit lane?

Hmm maybe not then. The rates you have look good for the 5Hz receiver. You need to ensure that you're transmitting and sampling at a minimum of double the rate of the data. I think that the zig-zag pattern may be a side effect of the latidude and longitude being sent separately (I'm assuming that they are sent in separate frames; it's been a while since I watched the webinar with the low level details of the way MoTeC uses the CAN frames). It's as if the longitude of one sample is being mixed with the latidude of the previous sample. I can't think of an easy way of getting around this at the moment.

What update rate was your M800 sending the GPS CAN frames? Also, do you know what rate the logger was sampling the incoming frames? I may be able to explain the "zig-zig" pattern you're seeing if the rates are close to the IIRC 5Hz rate of your GPS receiver.

LOL! Don't worry, I enjoy little challenges like this! At least we're getting somewhere; it could be a lot worse! PM sent.

Could you send me the .kml files you're using, both for the i2 data and the GDA data please? I think I'm going to have to look more closely at the numbers to get to the bottom of the spikes and the quantisation you're seeing.

Interesting! For those spiky bits, I assume that it's the software drawing the lines between the track and the tip of the spike and you're not seeing GPS readings along the length of the spike? Do you have the ability to pick out the readings you were getting at the point immediately before a spike and at the end of a spike? It's interesting to me that it seems repeatable, happening several times in each of three parts of the track. The attached image makes it look as if the spikes are diagonal, but on the Google Earth image the spikes are either N/S or E/W, suggesting that for some cases the latitude is still valid but the longitude is incorrect and in others vice versa. I see in the attached image that your logger is seeing both the lat and lon high words as 0 and both the low words as -32768. Does the i2 log show the same? Those values would put you somewhere in the middle of the Atlantic Ocean, south of Ghana so clearly they are wrong! I'm starting to wonder if there's some errors in the data transmission at some point. It's maybe worth a question to MoTeC to see if they transmit those specific values if there's an error.

In your image in post #70 I can see some LW fields with negative numbers. The equations above need the LW to be unsigned (i.e. always positive numbers). You have a few different ways of fixing this: 1> Change the logger settings so that all of the LW fields are set to unsigned. 2> Change the "2-step" approach such that it doesn't matter if the number is signed or not: GPS LAT COMBINE = ((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW' GPS LON COMBINE = ((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW' GPS LAT = if(('GPS LAT COMBINE'>0.0),((('GPS LAT COMBINE'-floor('GPS LAT COMBINE'))/0.6)+(floor('GPS LAT COMBINE'))),((('GPS LAT COMBINE'-ceil('GPS LAT COMBINE'))/0.6)+(ceil('GPS LAT COMBINE')))) GPS LON = if(('GPS LON COMBINE'>0.0),((('GPS LON COMBINE'-floor('GPS LON COMBINE'))/0.6)+(floor('GPS LON COMBINE'))),((('GPS LON COMBINE'-ceil('GPS LON COMBINE'))/0.6)+(ceil('GPS LON COMBINE')))) 3> Do the same as the above, only with 1 step per axis: GPS LAT = if(((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'0.0),((((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW' GPS LON = if(((((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'0.0),((((((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'

Aha! We've regressed back to before the point where we added the ceil() function. You simply need to use ceil() when the number is negative rather than floor(). This will round the number to the first whole number reached when going towards zero. The formulae in post #64 will fix this; if you want to do it in one step rather than two, you could use: GPS LAT = if(((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)>0.0),((((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)-floor((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)))/0.6)+(floor((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)))),((((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)-ceil((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)))/0.6)+(ceil((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)))))

Have you got a few examples where the longitude is wrong? Ideally with the expected longitide, the high and low words and the longitude that you are getting.

What about the conversion in post #53 and #55? i.e. GPS LAT COMBINE = ((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000 GPS LON COMBINE = ((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+'GPS LON LW')/10000000 GPS LAT = if(('GPS LAT COMBINE'>0.0),((('GPS LAT COMBINE'-floor('GPS LAT COMBINE'))/0.6)+(floor('GPS LAT COMBINE'))),((('GPS LAT COMBINE'-ceil('GPS LAT COMBINE'))/0.6)+(ceil('GPS LAT COMBINE')))) GPS LON = if(('GPS LON COMBINE'>0.0),((('GPS LON COMBINE'-floor('GPS LON COMBINE'))/0.6)+(floor('GPS LON COMBINE'))),((('GPS LON COMBINE'-ceil('GPS LON COMBINE'))/0.6)+(ceil('GPS LON COMBINE'))))

The 12V supply to the coilpacks and the igniter come from pin 1 of the grey connector in the footwell. See if there's voltage on this pin with the ignition on. See here.

The throttle control ECU is the traction control ECU. The connector can be left disconnected on a manual.

The 4-pin connector is for the stock lambda sensor; the stock lamdba sensor should have a mating connector, not bullets. The 40 pin ECU connector and the traction control connector are very similar - possibly even the same. You can identify the ECU connector as the one with a black/orange wire going to pin 1. I've got a feeling the single pin connector mates with a connector on the steering rack. The mating half is on the end of a short wire rather than being fixed to the rack. I remember only being able to get to it from below.

Oops, good spot. You're still getting an answer that's slightly off. If you stick the following into a calculator: ((8015*65536)+51705)/10000000 You should get 52.5322745 but GPS LAT COMBINE is giving 52.5322762. I guess we're just hitting a precision limitation in the internal workings of GDA. The position difference seems to be only a few yards. Google maps says the difference in the two coordinates puts you on the opposite side of the road: I guess only you can decide if it's suitable for your application.

Getting very close now! The answer given for the COMBINE channel is slightly out (52.5322762 vs. 52.5322746). I think it's worth trying a slightly different method of generating it as I'm not 100% confident I know what's going on behind the scenes of the combine16() function. Try: GPS LAT COMBINE = ((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000

For some reason, the check to see if the COMBINE channel is positive is not working correctly. if(('GPS LAT COMBINE'>=0),... is being evaluated as false for a GPS LAT COMBINE value of 52.5322762, which is clearly incorrect. Could you try using just "greater than" rather than "greater than or equal to" in the GPS LAT channel? I.e. GPS LAT = if(('GPS LAT COMBINE'>0.0),((('GPS LAT COMBINE'-floor('GPS LAT COMBINE'))/0.6)+(floor('GPS LAT COMBINE'))),((('GPS LAT COMBINE'-ceil('GPS LAT COMBINE'))/0.6)+(ceil('GPS LAT COMBINE'))))