NefMoto

Hi I have tried to adapt a VDO 1J5 920 926 C cluster to a Bosch 1J0 920 926 C which I was assured should be compatible.
However when I went to transfer the softcoding 01414, it refused it. I read soemwhere where sometimes it won't accept the last digit and to try a 0. So I changed it to 01410 and it worked. But I see this affects the speedometer calibration so obviously it needs to be the right number.
So I wondered if anyone might shed some light on why that last digit of the soft coding can't be set to 4 on this cluster, or if there's any way around it.
Thanks.

Update: I managed to hard code the last digit in before doing the adaptation. It seems to have taken and now the speedo is much closer to the correct speed, but is reading slightly too fast compared to my Tom Tom. e.g.It reads 30 mph for 27 mph on the Tom Tom. Seems about 10% out though I've not tested it at higher speeds.
Should that even happen if the last digit matches what it was on the old cluster?
Thanks.

You are under the assumption that the factory calibration is accurate. That is false.

Is it 10 percent? Or is it a fixed delta?

Thanks for the response.
Well this is my first run in with speedos but I was certainly under the assumption speedos should read the correct speed.
But other threads say they can be a bit over - someone mentioned 5%. Still 27 mph fo 30 mph seems high.
I'm not sure what "a fixed delta" means. But I wonder if you're asking if it's reading high by a set amount or by or a relative amount?
If that's what you're asking then that is a good question and in all honesty it was tricky to ascertain that on the test run. I think I'd need to get it up to higher speeds to answer this. There were too many cars around last night and it made it difficult to get through a good range. May take it out later when the roads are(hopefully clearer).

OK it proved very difficult to do a test on the motorway - busy, people driving dangerously badly, Tom Tom just refusing to work. But I managed to work it through the lower ranges again anyway, and again afterwards. It's hard to know what to say about this. It seems to work through a range of 0 -3 mph from 0 to 60 but while it's ~1 difference at 10, maybe 2 at 20, then it seems to remain at about a 3 mph differnce from 30 to 60. Which doesn't make a fat lot of sense to me. Someone suggested an output test so will try that.
I'm also wondering from some of the other errors I've been getting if my ECU may need rebuilding. The root cause of all this was an immobiliser activated message that started right after I had a coolant leak and the mechanic fixed it. I don't know how but I think somehow, the ECU or leads going to may have got wet. I did a check of the leads going in a couple of times and looked tip top. Couldnt get the ECU out of its housing, then did and couldnt get it open without forcing it cos I didn't know if that could do damge or break an important seal or something. Guess it's time to force it though. But before I came across these error messages, elimination and googling had led me to believe it was bad soldering in the cluster, hence the replacement.

A 3mph discrepancy really isn't that bad tbf.  Assuming you still have stock wheels, stock tyre sizes and operating at the correct pressure, a discrepancy will always exist.

I've also heard (although probably bullshit), that the factory speedos should always read higher than actual speed - so that you think you're doing 30, when infact you're going a little slower.

You can vary the speedo calibration:
http://nefariousmotorsports.com/forum/index.php?topic=7964.15

"Very important thing if you want to have accurate speed and distance readings is to properly set K value. If your cluster is set to use gearbox sender as speed source (as there are clusters which use ABS as speed source by default and you can change most clusters to use it) you can calculate proper K value using your wheel diameter. You need to calculate how many rotations your wheel needs for 1000m and then multiply it by 7 (as gearbox sensor sends 7 impulses per wheel rotation). The tricky thing about using your custom K value is that after recoding using same coding as before (to recalculate checksum and remove DEF error) you are loosing your custom K value. For VMK501 clusters there is easy solution - you just need to set your dump to have 0 as last digit of cluster coding. For VMK503 clusters there should be a solution but if you set the dump to have 0 as last digit of coding the DEF error will not be cleared. Do not forget that speedometer scale/stepper motor settings are also covered by checksum protection."

Thanks for the reply Adam.
Yes, I've read a few comments about how speedos are made to deliberately read a little higher than the actual speed. I posted on another forum and they said 3mph higher could just be the way it normally works. Just doesn't si right with me. Seems a significant different. Like it's almost dangerous(I know that makes no sense though).
I had trouble setting the k value to what it was meant to be. Would only accept a 0 which gave a wildly incorrect speedo reading. Then I repeated the adaptation, fisrt coding the hex values into the cluster's eeprom code and writing back. And that led to this latest situation. So maybe this is just normal. Maybe my old cluster did this too and I never noticed. Would probably explain all those irate people when Im doing 30 in aa 30 zone or 40 in a 40 zone!

If you can pull the EEPROM from the clocks, you can edit all of the values manually, no need for adaptations.

The K value is stored at - 0x150 [0x192] - K value stored as LoHi 16 bit number.  The two addresses are for different clocks.

Wouldn't be too hard to calculate, but it's never bothered me that much.  Just add a few mph to your current speed to adjust. ;)

I don't think they're irate because you're going too slowly; it's just a thing in the UK where it's compulsory to speed everywhere.

I've been overtaken a few times by doing the speed limit (30 in a 30).  Furthermore, it seems the done thing to do 40 in a 30, and then continue to do 40 in a 60.  Idiots.

Ha ha ha that last bit made me laugh. Yes I have noticed these things too. Whenever I want to go at the speed  limit everyone demands that I go much faster, and if I'm in a rush, suddenly it's sunday driving everywhere. It's like The Truman Show or something.
Now what you wrote there is interesting. Maybe I have confused this K value with the distance impulse miltiplier in the cluster's softcoding, which by comparison I found to be at 00001C, 00001D, 00011C, 00011D, 00021C, 00021D. So that's the part I had to change manually.
So the K value is a separate deal to that? Sorry, learning as I go here.
So should I do anything with this K value or leave it alone?
I didn't quite understand the part about the 0 at the end of the softcoding. When mine was set to 0 it was way out(showing 20mph for 40mph), so maybe it was the other type of cluster they mentioned in that quote. I'm a bit lost with this I'm afraid.

I swear you're right, it's exactly the same in Glasgow!  That, and motorway etiquette is generally appalling.  Sitting in the right hand lane for no reason, when both two lanes are totally clear.  I find myself having to cut across three lanes to then over come all the way back across.  People are just clueless and it really annoys me.

Yes, I think you're right.  I've not changed mine because when I'm doing 30, people are sat up my chuff.  Do 60 and people fly past.  I know that I'm doing roughly the speed limit and I've not really thought about it.

I'm sure there's a method on how to calculate it, I'll have a Google when I get home for you.  Otherwise, you could load the EEPROM (pulled with vag commander 2.5 or similar) and edit the value.  Either increase 5% and see the effect, decrease 5% and see the effect.  Edit until you get it close; that's all I'd say! :)

Exactly. That was always a bug bear motorway driving. When people stop driving by the rules of the motorway, the motorway doesn't function any more. I heard they were going to fine people for middle lane hogging and tail gaiting anyway. Long overdue. either they need to enforce motorway driving rules better or scrap it and introduce freeway driving rules. I prefer motorway rules though cos I dont think we have enough lanes for freeway driving to work.

Thanks a lot for the advice on the K value. That is a new one on me. I'll bear that in mind if I decide this 0-3 mph over is not liveable with. In the quoted text, it sounded like there's a complication when you rewrite it though and I couldn't quite follow that part. I'm a bit thick like that! But I'll cross that when I come to it I guess.
Thanks again Adam. Much appreciated.

I am experiencing the same issue in my 2006 VW Jetta TDI. At about 60mph (GPS measured), the speedometer would indicate 65mph, so it is about 8% error. I have seen some talks about it and VW claims it is normal as they don't want to responsible for speeding tickets in case it showed less. This has been bothering me and I would like to know what to change in the instrument cluster for the gauge to show the correct speed. Are we talking about modifying the content of serial EEPROM 24C32 or something else?

Not sure if I got from this thread how to do this...

Just to add to my previous message...I have tested

2004 Acura TL - 70mph GPS - 70mph Speedo
2012 Chevy Cruze - 70mph GPS - 70mph Speedo

My both VWs 2003 Jetta and 2006 Jetta are showing the incorrect speed, or slightly higher speed. I would like them also to be exact.

How about a lo-tech solution? I noticed the same "error" in my car. It isn't so much to do with how many mph or kph the the actual speed varies from the speed displayed. If You look at the speedometer, i bet You 9 times out of 10 the same difference is the distance the speedometer needle should be further. Sorry for the awdward way to explain this, english isn't my native language.

Anyway, if You look at Your speedo when doing 50 verified with GPS and look how far off the needle is from the actual speed, then raise the speed to 80 and look if the needle is still as far off You get what I'm talking about. Way I fixed it, was to take the front cover and speedo needle off, then take the car to 100kph (GPS) an plug the needle so that it points to the correct speed. Takes 10 minutes and now I have the speedo working right where it matters the most, I don't much care if there is now some error at 200kph.

Hey Hytron,
I agree, I would prefer an accurate reading but a lot of people on forums(fora!?) claim that this higher reading is a deliberate safety measure in a lot of modern cars. And it may be that is just a European standard. I think I read that the rule allows for speedos to read higher up to (10% of your speed + 4kph) but they must always read higher. So my 2-3 mph at 30/40mph doesn't seem that high after all! I'm not the best at wading through lots of threads but I guess I read a fair amount on this one and it seems to me the general consensus is you either fiddle the Distance Impulse Multiplier to reflect the right speed, but then adverseley affect the odometer; or you just live with it reading high. But I'm not 100% about the Distance Impulse Multiplier affecting odometer - there was some debate about that and I'm just erring on the side of caution by assuming it does in my case.

I imagine you already know this but for anyone else who doesn't, the Distance Impulse Multiplier is set via the last(5th) digit of the Instruments softcoding(5 digit field that appears under "17 - Instruments" in VAG COM/VCDS). I can't tell you the precise technical definition but it's to do with how many times the tyres rotate over a given distance so obviously tyre size affects it. If you get tyres with a larger circumference, you're going to want to lower that number or your speedo.

The setting on my last cluster was 01414 where the 5th digit, 4, is the Distance Impulse Multiplier.

Setting the Distance Impulse Multiplier in VAG COM(VCDS) by changing the last digit of "17 Instruments" softcoding, you will have a set number of options available and I believe that varies for different models, but for my car there are be 4 values to choose from:

1 = 4345 impulses/km
2 = 3528 impulses/km
3 = 4134 impulses/km
4 = 3648 impulses/km

VCDS also says there's a 0 option which covers all eventualities by getting the impulses through the CAN. However I couldn't code my car to this value using VCDS. I tried hard coding it via other means but the speedo was way off.

These are the results I got from changing these values then testing the speed at 30-40 mph:
0 = get impulses through CAN - speedo reading 14-16 mph under actual speed
1 = 4345 impulses/km - speedo reading 3-4 mph under actual speed
2 = 3528 impulses/km - speedo reading 3-4 mph over actual speed
3 = 4134 impulses/km - speedo reading 1-2 mph under actual speed
4 = 3648 impulses/km - speedo reading 2-3mph over actual speed

It's a bad idea to have it reading under, so I went with 4 as it was the closest higher reading.

These options appear as a tooltip when you go into VCDS and click "17 Insturments > 07 Recode" (or "07 Coding" on more recent versions) and click into the softcoding field.

1) To change it via VCDS:
SELECT > 17 Instruments > 07 Recode
overwrite existing value with new value and save it. This should take effect without any kind of cluster reset. I think I just turned the ignition off then on again and it took effect.

2) to change it with an EEPROM editor, you'll need to know beyond any doubt which addesses correspond to your softcoding and change them all 100% accurately before writing the EEPROM back. I believe that if you make any errors there's a risk of bricking the cluster, though fortunately this didn't happen in my case. But you definitely want to make a backup of your cluster's EEPROM before attempting anything like this so, hopefully, you can restore it if it goes wrong.

So in mine I figured out by changing it in VCDS and comparing files, working out what the numbers were, that it was stored in 3 locations:
i) 00001c, 00001d
ii) 00011c, 00011d
iii) 00021c, 00021d

(remember that the above addresses will vary depending on what cluster you have so DO NOT go blindly trying to change them or you will wreck your cluster if it's the wrong locations)

The reason there's 2 addresses for each is there's 2 x 2 digit hexadecimal numbers making up the code. For some reason they are stored in reverse order so you take them, switch them round, then run them through a Hexadecimal > Decimal converter to work out the actual code or vice versa. Here's an example.
So each of those 3 locations above currently stores "86 05" in my case. So if I want to know the digital value that corresponds to, I swithc the numbers first, giving me "05 86", then I put them through the Hex> Dec converter (like this: http://www.rapidtables.com/convert/number/hex-to-decimal.htm) and it tells me "1414" which matches my cluster's softcoding.

To do this work on mine I used VAG EEPROM Programmer but there's other software that can do this like VAG K Commander. You also need a K-line OBD2 cable and a laptop to run VAG EEPROM Programmer from. Not unusual to need multiple attempts to read/write. The only thing I'd warn you is that sometimes, when I attempted to hard code the 0 value in or cod it back to 1,2 3,4 from the 0 value, it didn't always take and I had to do a new cluster adaptation to get it back to the other value range. SAo my advice to you would be to perhaps stiuck to VAG Com/VCDS and only enter what it allows you to in there.

3) I have read something about actually hard coding the impulse value in to make the speedo reflect the speed. But I was afraid this would throw the odometer out so I didn't go down that route. Plus the Hex addresses provided don't seem to hold that info in my case.

If there's any inaccuracies in the above info, I'm seriously just a begninner at this stuff so don't be too harsh!

Hey Hopsis,
So if you're saying take the needle off the clouster and reset it to make up for the difference., I did consider this. If it were 3mp across the board, I think I would attempt that, but since it seems to vary on some kind of curve, I'm reluctant to, because if I corrrected it for 40mph then it would be under reading at 20 mph etc etc etc.
So I decided to just live with it.
Good suggestion though, bit of lateral thinking :)

canigetawitness,

Thank you for this great writeup!! There is quite a bit of useful information in there! I have used VCDS and tried changing the last value of the cluster coding, and has no effect. The original coding was: 0023203 and I changed it to 0023207 per service bulettin and no luck. I have not noticed any difference in speed indication on the speedo.
I have tried using the E2PROM programmer but doesn't seem to be talking to the usb-hex adapter. Is there any other software that needs to be installed? Are you using VAG e2prom programmer 1.19?

I know there is a way to read the content of the serial eeprom using hardware programmer such as Elnec beeprog ( I have another dash from 2006 Jetta that I am using for testing and have read the eeprom), but I am pretty sure it is easier to connect obd2 connector than pulling a cluster and opening it up. That is always a last resort option in case the change messes up the cluster and you can no longer access it.

Hopsis,

The error is in % not in fixed amount. So for example when you go 20mph, your speedometer might show 21-22mph...going 60mpg (GPS), your speedometer might show 65-66, so it is the percentage error. Pulling the needle and setting it at lets say 60mph will give you acurate speed at 60mph, but when you drive 20, your speedometer will read only about 15mph. That can set you up for a good ticket if you are not thinking about it.

What car do you have Hytron?
If it's a Golf/Bora Mk IV then AFAIK the cluster softcoding is always 5 digits long so I'm going to guess those first 2 0's are unintentional?
If so then would I also be right in assuming you have built-in Satnav equipment cos otherwise those first 2 digits seem on the high side. If needs be, I'll hunt down the thread that shows all the different pemutations for those first 2 digits.

When you say you tried changing the last value and it had no effect, do you mean it just didn't change and reverted back to the original number? Did you try any other values? Did a list of options appear in a tooltip when you clicked in the softcoding field? If so, was 7 one of those options?

It's version 1.19g. Are you sure your COM port is set right? i.e. does the COM port VAG EEPROM programmer is using(look under "options" to see which is ticked) correspond to the one the cable's using(look in control panel > device manager > COM ports and see what's in the brackets alongside the only entry down there)?
I'm afraid I'm no cable expert so I'm not going to be able to advise there. All I know is I use it on a OBD 2 cable and it doesnt work on the CAN cable I bought.

I'm afraid I've not looked into the bench options like Elnec beeprog. I didn't want to go that route so stuck with the cables. If I could advise on it I would, I'm just not knowledgable about them sadly.

The car is 2006 Jetta TDI. It is a mkV version. It does have SAT radio but NO navigation.

The coding should be 5 digit long, but the leading zeros were present from VCDS software, so I just did cut&paste. Only the last 5 digits matter from what I can see (VCDS info).

Elnec programmer (http://www.elnec.com) is an universal EEPROM programmer and from what I heard they are very good. I have their BeeProg+ programmer and it supports over 88000 devices/chips. What I did was used the ISP (In circuit programming) option and connected the wires to the 8-pin clip that hovered and clipped on the top of the eeprom chip so that I don't have to desolder it. I was able to read the content of the serial eeprom using that method. The eeprom used in these models is nothing else than serial 24C32 eeprom manufactured by ST. Datasheets can be downloaded here:  http://pdf.datasheetcatalog.com/datasheet/atmel/doc0336.pdf

The cluster took the new value "7" but I don't notice any difference as far as the speedometer goes. It is still off.

Yes the version of VAG programmer is 1.19g and the only options are COM1, COM2 or USB. I have chosen USB since my RossTech USB-HEX cable is connected via USB. But no luck.

I can see the USB-HEX adapter under the device manager and it is under the USB section.

Ah see I have a MkIV so it looks like these codes are different. Damn if I'd known that I wouldn't have wrtten all of that about MkIVs and softcoding. D'oh, guess I should've asked that first!
Well I'm afraid I've no idea about Mk Vs and VCDS. Never had a Mk V nor seen one in use with VCDS. Maybe someone else here can help though.

The EEP{ROM bench stuff sounds impressive but I don't have experience of that tiehr I'm afraid.

And when you enter the new softcoding does a tooltip(looks like a speech bubble) appear explaining how the softcoding works, with a list of available values for that last digit? Cos it should do.
Is 7 one of those?

Maybe that's where you're going wrong then cos I have to have it set to COM1 or COM2, whichever matches what the cable has as a COM port(control panel > device manager > COM ports).
So try that.

Hmmm OK so maybe this just works differently to my cable. I'm afraid my cable is the only one I've had so I'm stumped. Maybe someone else can shed some light.
Were you given any instructions on installing drivers for the cable when you first got it, or was it just pulg n play?

My experience is kind of confined to what I've done with my car in the last couple of months, so there's a lot I don't know about all this.

You need the VCP drivers if you want the ross-tech cable to show up as a com port.

From your writing, MkIV coding seems to be very similar to MkV. Most of the information you wrote is the same!

I removed VCDS, all Ross-Tech inf files which point to their drivers. When I plug the HEX-USB adapter, it says "Found Ross-Tech HEX-USB hardware" and when I point to the drivers that I extracted from VCP but it says that it cannot find a maching driver. Hmmm What now? I cant seem to make this driver working with the HEX-USB.

You'll likely have to uninstall all the existing RossTech drivers first. Just removing inf files is not sufficient. If you aren't proficient with windows driver stuff, you're kind of on your own. You know, Windows being so user friendly and all :)

Also, which VCP drivers are you using? You MUST use the ones supplied by RossTech, not the FTDI VCP drivers... they won't work.

Also, please bug RossTech to update their VCP drivers. They are very old.

So it didnt come with a disc with drivers on, or a link to somewhere with drivers?
May be worth entering the name of the cable and "drivers" into google.

Oh Im glad the infor is still relevant then.

RossTech has their own VCP drivers. The FTDI ones will not work.

http://www.ross-tech.com/vag-com/usb/virtual-com-port.html

Ok I see this was my problem I think. I was using the FTDI VCP drivers and added manually into the inf file the VID and PID information.

Well if you delete a device and delete inf file from c:\windows\inf, windows cannot find a driver that maches the description so it asks you to provide drivers or basically windows is looking for an inf file to load drivers. INF contains all the information on the drivers and which files to copy (SYS, DLL etc...)

Just remember, removing a device and the entire VCDS will not remove the inf file and as soon as you plug it in it will try to load that driver again. I had to do:
c:\windows\inf   
findstr /C:"FA24" *.inf or findstr /C:"RT-USB.SYS" *.inf

There was a file called "oem22.inf" which contained the string searched and had to be deleted.
Just posting this for someone else who might experience the same problem

Here is the update.

So I installed the correct drivers and VCP; the USB-HEX adapter shows on COM2 (I set it to be at that port as it was available), but vag eeprom programmer 1.19g will not read anything from my vehicle. No dash no engine cpu. Nefmoto software also will not work but that is for a different forum. So what does that mean? Do these programs not support MkV vehicles?

Seems likely at this point, unfortunately. I don't have a MkV to try them out on.

Oh no that's aggravating after all of that. So did you check that the COM port in device manager matches the COM port that VAG EEPROM Programmer is using?(under options).
I suppose you know that the ignition has to be turned onto position 2(so as far as you can without actually starting the car). What else ... whenever I used VAG EEPROM Programmer or VCDS I always temporarily deactivated my anti-virus software(making sure I wasn't connected to the internet obviously!), and made sure I always ran the software by right clicking on the .exe and choosing "run as administrator". Failure to do these caused problems for me.
So maybe try those too Hytron.
It's also worth mentioning that with my set up, it could often take a few attempts to get a read or do a write. I think that's the cable as I've heard a lot of reports like that. I don't understand it.
So maybe be persistent. Sometimes if it carried on like that, I'd switch off the ignition and unplug the USB, then switch back on and re-connect. But make sure the software's closed down first or it hangs.

That's about all I can think of. I'd not heard that it only worked on MkIVs but it's entirely possible I guess.

I set the VCP to use COM2, as COM1 is being used by my serial card in the laptop. BUt still no luck. I think this software was not meant for this vehicle, maybe for an older like MkIV. I am using XP, and running as administrator.

Damn, I'm sorry to hear about that Hytron. I hope there's some equivalent software that works with a Mk V. Only other ones I've heard of are VAG K Commander and VAG Dashcom.

Yeah my only option that I know that works is to clip the eeprom. But that would be very time consuming if you are changing a parameter that you don't know...try it out...and then change again...try it out...etc... Maybe I can "assemble" a mini vehicle in my lab and see how that goes.

You could try some sort of socket ...

Seems nuts to me. I can't believe no-one has written software that can do this on later models. I mean it's inevitable. Someone must know what it's called?

My 2013 Jetta TDI is the same way, drives me nuts.

My solution? A custom CANbus LED display that pulls speed from the convenience bus, along with RPM (just for kicks), fuel level (because I don't care for the crappy bar graph gauge), and water temp (because they don't have one!)

I find it weird that they couldn't get the "analog" gauge to read correctly, but yet the information is correct on the CANbus that feeds it.

I'm reluctant to mess with my eeprom, as immo work on these cars is next to impossible for me, and I've heard that even just reading the damn thing will brick it. ::)

Maybe that happens with certain cables/software but didn't happen to me and I did a *lot* or reads and writes. Having read similar horror stories I was expecting the worst and was surprised this never happened. No DEF no brick, despite my unorthodox equipment(!) and intermittent hangs in cables/software. I was taking backups of backups before doing any changes! So either those DEFs/bricks happen with other setups or the rumours are exaggerated. OR of course, people could just be entering garbage into their clusters, which is on them cos that's to be expected when manually editing code like that.
I agree - I'd prefer an accurate speedo, but it's just the current rule(certainly in Europe anyway) that they have to read a little high. Looking how many people round here insist on doing a minimum of 40mph in a 30 zone(unless I'm late of course, then it's 15), I can see the logic in it, but then again when it's like that, what difference is 1-2 mph gonna make anyway? They should have the stones to properly enforce the rules or not at all. That gadget sounds pretty handy. Never heard of one of those.

It's completely custom, uses a teensy 3.1 microcontroller and some 8 digit SPI LED displays.
(http://i3.photobucket.com/albums/y59/seishuku/IMG_20150827_121435.jpg)

Microcontroller stuff like that is my hobby.

Very neat.
And the "passenger airbag off" must be the modern day equivalent of James Bond's ejector seat in his DB5?!  ;D

first I am VERY surprised they did not a temperature gauge on the new TDIs! That is so dumb from them! It is useful to know the temp of your engine, especially during the winter months where you don't want to rev it up higher when the engine can be still cold. I have read somewhere that you should not rev the TDIs more than 2500rpm unless the coolant temp is at least 120F (49C). I didn't think they would chip out on stuff like that!

As far as the speed, If I recall correctly when you use VCDS and I think group 1 in the ABS controller, the speed of the vehicle is correct as read by the ABS sensors, but I think they purposely tuned the gauge (EEPROM mappings) so that it reads little faster. I still DO NOT FIND THIS ACCEPTABLE.

So you tapped at the CAN L and CAN H wires?

Do you know if the program can be made using Atmel 324 microcontroller? I am not that great at writing software, more of a hardware person. I see that controller has a built in CAN bus from the specs:
https://www.pjrc.com/teensy/teensy31.html

If not, can you share more info about it?

Thanks!

That was the main reasoning behind the Teensy, built-in CAN controller, all you need to add is a CANbus transceiver ($3 Waveshare board from eBay).

I'm not real familiar with AVR chips, just STM32F4 and K20.

I tapped at the radio, but the BCM is also the CAN gateway on this car, so you can get all 3 busses there (drivetrain, convenience, and infotainment).

I've been keeping a "log" of CAN message here:
http://www.canhack.de/viewtopic.php?t=2128

Edit:
I also have some code here:
https://github.com/seishuku/teensybare_canbus

It's not up to date, I've made some changes recently, but it should give you an idea on how I'm doing it.

Thank you for this great posting!

I was just looking one of the suppliers and appears that ATmel makes a microcontroller with CAN controller built in as well.
Check out this site, I have purchased from them before and they seem to be ok:
http://www.futurlec.com/Atmel/AT90CAN128-16AU.shtml

From the wiring diagram I see that the instrument cluster on mkV only means of communication are using the CAN (brown and yellow wires).

I will check for the CAN transceiver, it might be just the programming part that would be a bit difficult. If I can see some sample code that would help alot.

For some reason the second link does not work...

Edit: Ok it appears the github is back up. Probably was down for maintenance last night.

seishuku,

I was wondering if you could have used a graphical display instead of just the 8-digit numerical display. You could glue it permanently and even display the words: "RPM, Coolant Temp, etc...." on it looks neat. Just an idea.

I purchased the teensy 3.1, as it appears to be a pretty powerful controller, so I will see what I can do...but I have quite bit of programming to learn! lol

Oh, definitely... The LED displays were just something I already had... I also wanted high visibility.

You could just as easily use an SPI/I2C LCD or OLED display, I even have a text library in one of my other github repos if you're interested.

Along with the teensy 3.1, I have also purchased this:
http://www.pjrc.com/store/display_ili9341.html

It seemed to be cheap, not sure if it would be difficult to display the same data that you have (RPMs, Speed, Fuel and Temperature) on it or I should be looking for some other kind of display?

Edit: Or even something like this might not be a bad idea: http://www.ebay.com/itm/Blue-Serial-IIC-I2C-TWI-2004-204-20X4-Character-LCD-Module-Display-For-Arduino-/181299099752?hash=item2a3644b868

That 320x240 LCD is what my STM32 discovery board uses, pretty nice display for the price... I've never used it by SPI though, only using the on-chip display controller (STM32F429 has a direct LCD hardware controller).
From what I've seen, it's still a pretty easy display to work with.

seishuku,

I saw some of your posts on that German site and was thinking about something. You are using the CAN transceiver that works on 3.3V, and I think the vehicle bus still works on 5V. Dominant CAN state would be 2.5V+1V which is 3.5V, and exceeds the supply voltage so the transceiver can never send anything more than 3.3V (probably 3.0V or so, it is always less than the supply voltage). Maybe you need to use the 5V versions such as PCA82C250 or TLE6250G. Just a tought.

It shouldn't matter, the transceiver has to conform to standards... It probably wouldnt receive any messages if that were the case anyway.

Also canbus is differential voltage, so as long as it has correct difference, it shouldn't matter if the overall voltage spec is a tad low.

This is starting to get a tad off-topic now, but here's something I've been working on:
https://youtu.be/vT89iyXch2Q

It's on my STM32 discovery, but the code is fairly portable, should "port" over to the Teensy with little effort... I really need to pick up an extra SPI LCD, maybe something bigger than the ILI9341 though.

Wow great job! Yeah you should use that with a display for your VW and frame it would look nice! What software do you use to program teensy 3.1? Arduino or something else?

As far as the instrument cluster, I picked up ABS control module and an instrument cluster from a junkyard because I really want to get down to this speedometer error without messing with my TDI back and forth, but being able to reproduce similar scenario on my work bench. I connected the two modules to a spare OBD2 connector I had, and all the required wiring. The ABS control module is being fed by the circuit I made out of NE555 (timer) and a few opto-couplers (you can find them in any computer power supply). VW uses Magneto-resistive ABS sensors and that is the reason for opto-couplers to be used. The NE555 timing circuit is feeding the same signal as the vehicle ABS sensors would so the ABS control module feeds that data using the CAN bus over to the instrument cluster. Using potentiometer I can change the indicated speed to anywhere from 10mph to 120mph (don't care for more)  ;D
I know they are not on the same bus in the vehicle (they are routed through CAN gateway), but this will serve the purpose. I am still waiting for my CAN transceiver chip to arrive to start the test. I am hoping to do enough testing and to figure out (with the help from this site) how to change and correctly change the parameters so the speedometer is correct. Probably one of the first things will be sniffing the information on the CAN bus.

Do you happen to know the CAN message code to turn on the instrument illumination at night?
 

So here is an update. Received the Microchip MC2551 CAN transceiver and started capturing on my bench.

The file in the next post has ONLY ABS controller connected and continuous at 0mph from begining. At second 30, powered up the circuit to send pulses and indicate 30mph on the cluster (cluster is not connected but I know the frequency from previous setup). At second 60 the speed was slowly increased to 70mph (I would say at second 75 the speed was for sure 70mph).

Seems like the CAN messages have different identifiers for different year and model of VW? Can you tell which message tells the speed? I am thinking it is 0x5A0 or 0x4A8

This is for 2006 Jetta TDI

CAN Bus log

MK6 VW's have it at 0x359 bytes 1 and 2, though MK5 will probably be the older 0x351 (same bytes).

But you're dealing with just the cluster, right? So you'd be on the drivetrain bus...

Its been awhile since I logged the drivetrain bus... But I do recall that 0x5A0 is speed, it does seem to match up with a divisor of 322 (which is what I used for 0x359 on my MK6)

As far I have discovered, the ABS control module sends speed information on the powertrain bus. The instrument control module is on that same bus and picks up those CAN messages and displays the correct, well "correct" speed on the speedometer. But I didnt see any of the messages with the ID of 0x351..hmmm...check the file I attached.

Yes I had only ABS and Cluster connected with CAN high and low and at the same time the MCP2551 tranceiver feeding the info to Teensy 3.1. The bus was properly terminated with 120 ohm resistor right by the MCP2551. Remember I am simulating a vehicle on the bench so other modules are out of question, well, at the same time their data is not on the bus and is easier to capture and see the difference.  ;D

Yeah, you won't find 0x351 there, that's only on info/convenience bus.

0x5A0 is the speedo message:
https://hackaday.io/project/6288/instructions

Old topic, but I've found additional information that could be usefull.

For my VWK503MH clusters the fashion described by canigetawitness did not work. I've found it at 0x192 and 0x193 as "56 10" -> byteflip hex2dec = 4182
above that you can find the last digit of the SW coding. in this case it was option 5, so 0x182 and 0x183 said "55 05"

For my cluster to be fitted in a Golf I changed 0x192 and 0x193 to "C8 0D" -> byteflip hex2dec = 3528
In VCDS, option 2 as last digit was still available for this cluster so I changed 0x182 and 0x183 to "22 02"

When you flash the dump to the cluster it will give "def" in de right bottom screen. with VCDS, go to [17] Instruments -> [10] Adapation -> channel 00 -> read -> save. This will recalculate the checksums.

All of this means one does not have to hybridize ROMs to fit them in Golf 4.

For VBX00MH clusters these pulses are found at 0x150 - 0x151 and the SW-coding digit above it, at 0x140 - 0x141
For VWK501MH clusters i have not found it yet. Will update when i do.