I'm not even sure those modifications are even needed, as the Passat cluster does look to have an LED already on the board. What I really need is a sport diesel tach face with the glow plug symbol on it as right now I just have a non-diesel gauge face. Then I can test to see if the existing LED will light up when it's supposed to.
There's a bit you have to set in the cluster EEPROM to enable the glow plug LED. You should be able to use DashDumpEdit to turn on that bit in the dump.
Yeah - that's pretty much the conclusion I'd come to as well. I have to (different generation) VAG TACHO cables and they both have the same PID, VID and "serial number" of 00000004. ¯\_(ツ)_/¯
I confirm:
Thanks for confirming. There does seem to be a bit that I thought was an option depending on market (NAR/RoW) but it is enabled on yours and every NAR vehicle I've seen but no other RoW cars (from my limited list of cars anyway). I guess that will stay a mystery what it is for then. Some things I can confirm for you is that you DO have the factory alarm but not the DWA configuration with the battery backup alarm siren. Also, your CCM does have interior monitoring enabled but the adaption channel bit that allows you to adapt/monitor if the system is on is disabled though. Are you sure you do not have the sensors somewhere? Due to the adaption channel bit disabled, I am almost sure this answer will be no.
FTDI USB-Serial cable arrived today; plugged it into the KKL cable that works on the old DOS machine with VDS-PRO, so I think I have the hardware all sorted out.
Mikes-MacBook-Air:Downloads Mike$ ./kw1281test AG0JGRR4 10400 17 ReadIdent
Unhandled exception. System.DllNotFoundException: Unable to load shared library 'libSystem.Native' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(liblibSystem.Native, 1): image not found
at Interop.Sys.Dup(SafeFileHandle oldfd)
at System.ConsolePal.<>c.<OpenStandardOutput>b__9_0()
at Microsoft.Win32.SafeHandles.SafeFileHandleHelper.Open(Func`1 fdFunc)
at System.ConsolePal.OpenStandardOutput()
at System.Console.OpenStandardOutput()
at System.Console.<get_Out>g__EnsureInitialized|25_0()
at System.Console.get_Out()
at System.Console.WriteLine(String value)
at BitFab.KW1281Test.Logger.WriteLine(String message)
at BitFab.KW1281Test.Program.Main(String[] args)
Abort trap: 6
Mikes-MacBook-Air:Downloads Mike$Mikes-MacBook-Air:Samples Mike$ make
for n in BitMode EEPROM/erase EEPROM/read EEPROM/write EEPROM/user/read EEPROM/user/size EEPROM/user/write Events LargeRead loopback MultiThread SetVIDPID Simple static Timeouts W32/escapeseq W32/events W32/simple W32/timeouts write ; do "/Library/Developer/CommandLineTools/usr/bin/make" -C $n || exit 1; done
cc main.c -o bitmode-static ../../build/libftd2xx.a -Wall -Wextra -lpthread -lobjc -framework IOKit -framework CoreFoundation
clang: error: no such file or directory: '../../build/libftd2xx.a'
make[1]: *** [bitmode-static] Error 1
make: *** [subdirs] Error 1
Mikes-MacBook-Air:Samples Mike$
Unfortunately, it looks like that model doesn't behave the same as the 2 Bosch cluster that I have (both 1J5920926C) so you're probably out of luck.Hi, I'm really grateful for this, I'm really happy that I can use my Chinese kkl cable for these kinds of stuff. I was able to enable remote windows control, but I'm having difficulties with reading the cluster's EEPROM, if I'm right it's a Bosch one, but with DumpRB8Eeprom command it can't even talk to it.
Before that I tried DumpEeprom command too, which thrown a weird exception.
I might be missing something here, but could you help me please?
That just how the FTDI D2xx drivers work on Linux. I guess they need extra permissions to talk to the port.
Unhandled exception. System.DllNotFoundException: Unable to load shared library 'libSystem.Native' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(liblibSystem.Native.......Just out of curiosity - have you tried by running sudo first (someone correct me if I'm wrong, but I always assumed it stood for super user, do once)?One by one, copied the lines above into Terminal, everything worked...until ./kw1281test
(Edit: ...on my old MacBook Air (High Sierra); just now gave the same thing a try on the MacBook Pro (Big Sur) - it worked!!
Thanks for your patience and help, @gmenounos - very much appreciated!
MacBook Air gives me this same error.
Code:Unhandled exception. System.DllNotFoundException: Unable to load shared library 'libSystem.Native' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(liblibSystem.Native.......
sudo actually stands for switch user; do once. Running sudo just assumes root permissions if you do not pass the -u "username" option which is why it seems to stand for super user. The su command is the same deal.
I was close - I honestly never bothered to look it up, and having been traditionally a Solaris guy, we never had sudo, but rather, su.
I used to use Linux a lot more years ago with building home servers using old hardware but I bought a Synology NAS years ago and that sorta went away. Now I use Win/Mac most of the time so I forgot a lot of the commands I used to use. I never ran Solaris but I have used BeOS and the new Haiku recreation of it. Now I am just lazy since my day job is to deal with a windows domain issues and the usual things users end up breaking.
Yes, last night, I'd tried it with sudo, without sudo, in the active folder, not...
High Sierra did have less security than Big Sur. Also, do keep in mind that since Catalina, MacOS only supports 64bit everything so if your FDTI driver is 32 bit, it may not run at all. If I remember correctly, kw1281test is 64 bit but is the FDTI driver 64 bit?
to @gmenounos!
"chmod +x kw1281test" changes the file attributes to make it executable. I created the zip file on a Windows machine, which doesn't have an executable attribute. I'll experiment some time and see if I can eliminate the need for the chmod step.
dotnet.microsoft.com
chmod +x would just set kw1281test to be executable. Like our CCMs, it's all binary. So I think chmod 777 for instance would set the read, write and execute bit for root, group and user. I'm guessing +x would just set the execute bit on, though I can't imagine any reason the write bit would need to be set on or off.
I sent Lawson( @VeeDubTDI ) a message asking him to sticky this a while ago.
I think if you set it as an executable, this (and other permissions) theoretically should be preserved if you gzip it or put it in a tar.
That's super cool. Big segue, but my friend @alphaseinor used to be a BeOS developer once upon a time, before becoming a TDI mechanic/vendor (and now back to a programmer and doing TDI stuff on the side). I totally get forgetting commands you don't use all the time!
Well, as is often the case with me...PEBKAC.
You deduced perfectly! I managed to download the chassis number info for Etka. In fact, my friend's Golf 4 1.9 GTI TDI has the alarm with internal volumetric sensor (PR WE3 - Technical Pack with volumetric sensor + PR 9V7 Electronic immobilizer, with anti- theft
Looks like the standard B5 Passats do already have a functioning glow plug LED on the board. I managed to find a 1J5920826C binary to flash into an 01 Passat 1.8T cluster, swapped over a diesel tach, and installed it in my 04 BEW car. Glow plug light works great now and no check engine light either. Not bad to have about $40 invested in an MFA cluster.
I don't know you well enough to assume that, but given you're helping others running Linux and Mac OS X, I wouldn't have assumed that at all.
There is a way actually, and that's to use VMWare. Without going into details, if you google it, you can run OS X under VMware. I think it depends on the version, and if you use Linux seamlessly with Windows 10, I think that has to get disabled to allow VMware to run in 64 bit mode. I want to say that I'm running Sierra as well, based on the backgrounds @Nuje showed.
It turns out that OS/2 article is online here: https://www.linuxjournal.com/article/2734