Jump to content
aaron_h

TD5 Speedo Mileage run up circuit

Recommended Posts

Nice. It's been a while since we did this - good to see it's proving useful!

 

Kev

Share this post


Link to post
Share on other sites

So as Kev previously found, the checksum byte will always be one of four values (0x50, 0x70, 0x90, 0xB0) minus the XOR sum of the high byte and low byte of the speedo calibration value.

The first value is a bit difficult to explain but so far it follows the procedure below :-

               for speedo rate settings (RATE) below 4096 :
                    CHECK WORD = ((int(RATE/16) % 4) * 2 + 5) * 16
                for values of 4096 or above
                    CHECK WORD = (11 - (2 * ((int(RATE/16)+2) % 4))) * 16

(% is the modulus operator)

This screams out for further simplification if anyone can be bothered, but it seems to work for all the values tested thus far (every value from 2000 to 5556).

It's easy to see the pattern once plotted on a graph...

5a1b5fab43954_Screenshotfrom2017-11-2700-40-52.thumb.png.178f10d7d6edc34245610897a954cce8.png

I think that completes the geekery, back to the oily bits instead :rolleyes:

Share this post


Link to post
Share on other sites

That's excellent work TSD, like you say it can probably be simplified further as well. 

Thanks for completing the puzzle for us all :)

 

It's interesting how the graph flips at 4096. How did you come up with the algorithm  once you established the pattern?

Share this post


Link to post
Share on other sites
3 hours ago, CwazyWabbit said:

How did you come up with the algorithm  once you established the pattern?

More or less by inspection TBH. I simply wrote a function that generates the required number...

Checkword changes every 16 values, so (n/16).

We know it is one of four values, so (n/16)%4 to generate the remainder, 0,1,2,3.

Write down the binary values of the check word, and you can see they are = 2x + 5 for x in 0..3

Then the * 16 simply moves it into the high nibble, so 0x05 becomes 0x50

I can see there is probably a 'bit twiddling' route  to simplification, but I can't immediately see what it is. The obvious clue being the 2's complement binary representation of -11 has the same bit pattern as +5.

 

Edited by TSD
  • Like 1

Share this post


Link to post
Share on other sites

I'm kind of trying to get my brain switched back on to this, but it's been a while :)

@TSD: I think you're basically right with the observation that -11 is the equivalent of +5.

The /16 (or shift 4 places) does seem to tie up with the "4096" thing, as the top bit may become the sign/carry flag for an 8 bit micro: i.e. 4096 <<4 = 256 or 0 with carry.

Kev

Edited by MrKev
  • Like 1

Share this post


Link to post
Share on other sites

Once I've finished messing about with this, I thought I'd write a small Python script that could be run on a Raspberry Pi by anyone who can temporarily solder small wires onto the speedo. So no real need to understand what goes on behind the curtain.

Share this post


Link to post
Share on other sites

This could get repetitive... added a further wrinkle

CHECK WORD = (11 - (2 * ((int((16383-RATE)/16)+2) % 4))) * 16 for values > 8192.

Expecting another one at 12288 much?

Share this post


Link to post
Share on other sites

Ok, i think its simpler to start with this: Take RATE, right shift 4 (/16), then logical AND with 0xFF, or 256 before wrapping the rest of the equation.

I haven't got a piece of paper handy, to work out the rest at the moment!

I think this will lead to a general rule for all rates, and satisfy the below 4096 case at the same time.

 

Kev

Share this post


Link to post
Share on other sites

I think I finally have a general solution...

                                tmpval = (RATE >> 4) & 0x0003
                                signbit = RATE & 0x1000
                                offset = RATE >> 12
                                
                                if signbit:
                                    checkword = ((((offset - tmpval) * 2) % 8) + 0x05) << 4
                                else:
                                    checkword = ((((offset + tmpval) * 2) % 8) + 0x05)  << 4

This could be a general solution in fixed width signed binary, but less obvious in a high level language.

The speedo works over the range RATE = 2000 to 19542, so very possibly out to 32767, buts that's as far as I've tested. It would take another week to check all the values further up and I'm getting bored of the sound of the power relay clicking :rolleyes:

I think I will try to write the R-Pi script and then call it done.

Share this post


Link to post
Share on other sites

As far as I'm aware, the limit for the Td5 speedo would be 65535, as the calibration word appears to be 16bit.

GPS  is technically not road legal in the UK as the primary speedo - at least it will not pass IVA testing. I did think about a device that continually recalibrates the speedo based on gps, but that would be too silly even for me :lol:

Share this post


Link to post
Share on other sites

OK, just to answer the final question, the maximum rate for the sender on the Td5 speedo is 60000.

The checksum routine as described appears to work for all values 2000 - 60000.

I have a simple programming script for a raspberry pi  available if anyone needs it - send me a PM. If you have a working raspberry pi setup (of any version) and you can solder 6 small wires, that's all you need. (You do need to crowbar the speedo open as described previously in this thread)

First customer gets the job of writing better instructions ! :D

Share this post


Link to post
Share on other sites

Thanks for this topic! I am now clocking 100.000 km extra to my "new" TD5 tacho which will replace my old analog tacho.

 

instead of the pic I use an arduino with this code and also the ULN2803. This gives me the highest speed (1km added every 1.5 seconds)

int ledPin = 6;

void setup() {
  // put your setup code here, to run once:
 pinMode(ledPin, OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:
  digitalWrite(ledPin, HIGH);   
  delayMicroseconds(400);       
  digitalWrite(ledPin, LOW);   
  delayMicroseconds(400); 
}

  • Like 1

Share this post


Link to post
Share on other sites

Hello.....just wondering if anyone is offering a mileage run-up service for my replacement TD5 speedometer?.....thank you!...Dan

Share this post


Link to post
Share on other sites
2 hours ago, Dan87GT said:

Hello.....just wondering if anyone is offering a mileage run-up service for my replacement TD5 speedometer?.....thank you!...Dan

Pop CwazyWabbit a PM (few posts above) he should be able to sort you out.

Share this post


Link to post
Share on other sites
Posted (edited)

soooooohhhhh.... I forgot to check the runup of kilometers on my odometer... 

now it shows 20.000km too much 🙂

So i ordered an usb-programmer and a suitable clamp from my uncle Ali in China.
When that arrives I hope to be able to set the distance back to the desired value.

Also made a little app to change the desired value to a hex-array:

td5odofix.jpg

Edited by doezel
  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)

Hi!

I now have a working programmer for the 93S46 chip.(an EZP2019 from my Chinese uncle Ali)

Only issue I have now is this:

I used the alghorithm written down by @MrKev. But for some reason it doen't work in kilometers.

For example:
ffff ffff ffff ffff ffff ffff ffff ffff shows 1.0KM, so that's good.
MrKevs example of 197672 (CFBC CFBC CFBC CFBC CFBD CFBD CFBD CFBD ) shows 271105KM.  (factor 1.3715 too much)
When I program 255000 (C1BD C1BD C1BD C1BD C1BE C1BE C1BE C1BE ) my meter shows 267233KM. (factor 1,0480 too much)
When I program 666666 (5D3C 5D3C 5D3C 5D3C 5D3C 5D3D 5D3D 5D3D ) my meter shows 801301KM. (factor 1,2020 too much)

So it's not a straight miles to kilometers conversion issue. Any idea what I'm missing here?

IMG_2032.jpeg

Edited by doezel
added image

Share this post


Link to post
Share on other sites

Hi,

Looking back through my emails I programmed up a KPH speedo for Ray in Australia with 

0xB29A 0xB29A 0xB29A 0xB29A 0xB29B 0xB29B 0xB29B 0xB29B

Which gave a reading of 317001, this follows MrKevs algorithm. I'm a little perplexed as to how you have had different results.

 

Is it possible you've accidentally changed some of the other values in the serial eeprom? Does the needle still work when it's receiving an input? 

 

EDIT: There should be a dump of the serial eeprom from a KPH speed earlier on in this thread that you could use for reference.

EDIT2: Here's the link to the post with a KPH eeprom dump, it's the second dump in the post 

 

Share this post


Link to post
Share on other sites

Can you post a link to your code?

Share this post


Link to post
Share on other sites

Good work takes time & there has been lots of research & effort by those involved Top job all.  :i-m_so_happy:

CW have you had any result with making the Td5 speedo red alarm light work in retrofitted vehicles ? 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

We use cookies to ensure you get the best experience. By using our website you agree to our Cookie Policy