(Almost) free DIY ADS interface

[Dannbodge]

I checked the environment variable and had written it in lowercase so changed it to uppercase and it seems to have worked.
I ran ADS setup during installation instead of OBD setup.

I also saw another of your posts David Mc about the Dell serial port driver. So I put that .DLL file in the folder suggested on another post to see if that will help too.

- - - Updated - - -

Tried running it again and still no luck.

Why can't this be easy. I've followed all the instructions and it's still not working.
All I want to do is code 1 module

[KevinMullins]

What is INPA doing or not doing? (errors?)
We need something more than just that it isn't working.

[Dannbodge]

Don't worry.
David Mc got it sorted via PM.

Was an issue with my ADS driver and ediabas configurations.

[vlakci]

I am tring to get the DIY ASD/OBD interface to work with DIS too. Up to now I did:
- from before and fully working on (DIY) ASD and (DIY) OBD interfaces, the Inpa V3 or Inpa V5 + Ediabas + NCS
- VMware virtual machine
- DIS V57 and DIS SSS
I did the DIS install as on PDF instructions:
- configure EDIABAS (set Ediabas.ini > RemoteHost = 192.168.68.1, port = 6801)
- set virtual network on VMware with set SUBNET and DHCP, DIS working
- set "BMW diagnostic head emulator V1.2",
- PING test in CMD
I start the system as per instruction:
- wired DIY OBD or ADS to RS232 COM1 and to a wall 12V power supply for first test (in INPA batt and ignition are marked, so it works)
- open and run diaghead.exe (emulator)
- star IHF-Service (C:\EDIABAS\BIN\Ifhsrv32.exe)
- start virtual machine with DIS V57
- in DIS I went under Administration -> Config -> Config\Diagnostic Head\Free diagnostic heads but it is empty

Is a problem of the instalation or of the ADS and OBD interfaces (simple made with some transistor, none procesor chips as on GT1)??

[David Mc]

I don't know where you guys are getting information that tells you to use a diaghead emulator, the problem you have is that DIS has not been configured correctly (Translator set to Fister and processes configured so that vm is set to off and NSW & DSM are set to run). Once configured correctly, you should not see any free diagnostic heads as your network will be hard wired to your interface.

[vlakci]

got it to work with easyDiS V44 and ASD, thanks to David Mc. Next thing is to check the OBD circuit (DIY)

- - - Updated - - -

where to get download the BMW DIS SSS program for coding?

[acheson850i]

Hi,

I am aware that I can purchase the ADS interface and 20 pin connector and obtain software for my 91 850i, an E31. If I want to "muck around with PCB's and soldering" which interface should I build. The very first one in this thread or one of the later "Hans" versions in later posts. I have seen Brian E (IcemanBHe on the 8 series forum)'s setup and would like to "reinvent the wheel"! Thanks!

Scott

[vlakci]

get the second Hand version. It works perfectly on ADS (=E31) with software V3 or V5 INPA/EDIABAS/NCS and even DIS. As for the laptop if no RS232 connector, use a PCMCIA to RS232 adapter and patch the I/Os with the adsport.exe also linked in this thread to the V3 INPA/EDIABAS installation.

[Bianco]

I don't know where you guys are getting information that tells you to use a diaghead emulator

That's the case with a K + DCAN cable if you prefer using DIS rather than Rheingold. Easy mistake.

[David Mc]

There is no need to use a diaghead emulator with DIS and a K+DCAN interface either, I run DIS v44 and DIS v57 with ADS, OBD and K+DCAN and have only ever used a diaghead emulator once in the early days when I was experimenting with software setups.

[KevinMullins]

There is no need to use a diaghead emulator with DIS and a K+DCAN interface either, I run DIS v44 and DIS v57 with ADS, OBD and K+DCAN and have only ever used a diaghead emulator once in the early days when I was experimenting with software setups.

+1
I have never had the need to use a diaghead emulator.

[Auzeras]

Trying to pull fault codes from my 1989 735 (E32) - INPA gets IGN and Battery but can't seem to communicate with anything else. Seems like there are a lot of files/setup to do with INPA to get it working, NCS Expert has the E32 chassis listed but when trying to load the profile it gave error "Chassis Corrupted" upon researching said error it seems that I need a lot of related E32 files for everything to work smoothly so I decided to use Carsoft instead since I really don't need anything fancy (yet) only to pull the codes and thus fix them. Carsoft won't communicate with any of the modules though. Throws an error along the lines of cable faulty, check cable.

I'm going to recheck my soldering and wiring to make sure it's good but other than that does anyone have:

A good working copy of Carsoft
Instructions for a muppet like myself in using said carsoft
OR
Copy of INPA with all the goodies to get it read the E32 chassis

Thanks!

[KevinMullins]

What version of INPA are you using?

[David Mc]

Carsoft will only work with a Carsoft interface. You may be better off trying to diagnose this car with DIS as I have never seen INPA files specifically written for the E32, which was marketed just as BMW were beginning to introduce external diagnostics to their model lineup.

[stef123]

I had no success with my Carsoft interface on by 1990 E34 M50B25, so i was making the first type of of the Interface and it still not working, got the same errors like "Lowclock" had ("Chassis# populates with 820W820W820W82" etc.), but i did not tried so far the "trick" referring to Post #30, joining RXD & TXD/TXD2 together, i will try that tomorrow. but i am curious about the technical behaviour at all. I have two LEDs attached to RXD (a rad one) and TXD (a green one). When INPA tries to access the DME, the red one will flash, trying to "wake up" the modules, but i get no response from the DME. When try to access other modules, the red LED does nothing, INPA says immediate something like "Identificaction error" and DIS "transmission diesturbed". DIS shows in fact the same errors as mentioned before ("820W820W820W82") and no response from any of the other modules, while the red LED shows no action and the green one flashes here and there in short pulses. Now my question is: Which -technical- sense does it make to join Pin 15&17/20 together? Do some modules need to be "wake up" through the TXD-Line in parralel to the RXD-Line? Do only some modules need to be wake up through the RXD-Line or -all- modules?

[David Mc]

Pins 17 & 20 are both K data lines (TXD) Pin 15 is an L data line (RXD) just physically connecting an L data line to a K data line will not result in you being able to communicate with modules on the L line as K line signals are bidirectional (TXD/RXD) whilst L data lines are unidirectional. You can read background information about how they function here http://www.vishay.com/docs/70573/70573.pdf

[stef123]

Ok. So it is normal that some diagnostic routines make usage of the l-line and some not? If i try to access the airbag module for examle, the L-Line stays alway at high level, same goes to several other modules. The only activity i was able to see on the L-Line was at the point, where i tried to access the DME.

[stef123]

David, is it possible that some PC-RS232 UARTS do not accept a Baud Rate of 10400 Bauds and some BMW-Interfaces proably accept the communiation with (for example) 9600 Baud and others do not? I've double-checked everything including the RXD-TXD-Lines from the Diagnostic connector to the modules and cannot find any fault. I start to believe that the RS232 always stays on a Baud Rate of 9600 Baud and some modules accept the communication at this Baud rate and others do not. It makes at least no sense that i am able to communicate for example with the Combi and the Central locking unit, but with no other module. I guess that D*S or any other Software simply tries to write a value into some specific registers of the UART, while it does not check if the UART itself accapted the commands for a 10.4K Baud rate. I know that ISO9141/KWP2000 rages from 1200 up to 10.4KBaud, but maybe BMW used back then fixed Baud rates in some modules and other modules accept variable baud rates?

[David Mc]

Stef, I have only ever used 9600 and can access all modules on every ADS compliant car I have tested - including E34, E38, E36 and E46's.

[stef123]

Stef, I have only ever used 9600 and can access all modules on every ADS compliant car I have tested - including E34, E38, E36 and E46's.

Ok...well, i am very bewildered - i dont know whats going on with my car or with the Interface / Software itself. I have currently the original (swapped) Airbag Module hooked up in my living room and i still cannot access the module with D*S, no matter, what i try. This Module was mostly used in E32s - Airbags were in the E34 back then an extra Option, so they seem to took this part from the E32. In the almost worst case this would mean that nearly all modules are destroyed in terms of their diagnostic link. My only solution would be then the removal of the entire Airbag System to pass the vehicle inspection.

[blarf]

David, is it possible that some PC-RS232 UARTS do not accept a Baud Rate of 10400 Bauds and some BMW-Interfaces proably accept the communiation with (for example) 9600 Baud and others do not? I've double-checked everything including the RXD-TXD-Lines from the Diagnostic connector to the modules and cannot find any fault. I start to believe that the RS232 always stays on a Baud Rate of 9600 Baud and some modules accept the communication at this Baud rate and others do not. It makes at least no sense that i am able to communicate for example with the Combi and the Central locking unit, but with no other module. I guess that D*S or any other Software simply tries to write a value into some specific registers of the UART, while it does not check if the UART itself accapted the commands for a 10.4K Baud rate. I know that ISO9141/KWP2000 rages from 1200 up to 10.4KBaud, but maybe BMW used back then fixed Baud rates in some modules and other modules accept variable baud rates?

The issue that you're seeing is that ADS modules may need one or two different TxD and RxD lines. RS-232 only has provision for one. I believe Carsoft initially used two serial ports to achieve communication, but eventually went with their own proprietary dongle. Another solution would be to repurpose one of the other RS-232 lines and twiddle that to emulate the second TxD/RxD line (L). This is what the BMW software does and when communication is attempted this way, it won't set off your Tx/Rx LEDs.

From openecu:

http://forums.openecu.org/viewtopic.php?t=115

Take a look at cboles' post. It sounds like the FTDI driver doesn't respond to setting the control lines properly (and instead you'd need to use their proprietary API) -- this may be one of the big reasons why INPA doesn't play nicely with USB adapters on ADS cars.

I'd be surprised if your dongle didn't do 10,400 baud. However, I'd also be surprised if BMW had any modules back then that utilized 10,400 baud. But... it sounds like there's a 5 baud init that needs to be done, and almost certainly none of the USB adapters will do this natively (and you'd need to fall back on one of the aforementioned methods of emulating it).

[stef123]

Yep, no success with the Carsoft Dongle, so i've build "Ver. 1" of the ADS-Interface in Post #1, running on a "real RS232 Port" (in fact the onboard in-Chipset-RS232 Implementation) and can access not more than the Carsoft dongle did, but i'd like to figure out why. So i thought that it could be proably a speed issue, since i cannot prove if the RS232 Port sets itself to the desired speed in which the adressed module likes to communicate, since there is in fact nothing else "active" between the RS232 Port and the module itself, only a bunch of Transistors and resistors. The only thing i can try first is to program the RS232 "Chip" directly to 10.4KBaud by adressing its registers directly and take a look if it accepts the Baud rate. I am also not sure if the carsoft dongle works correctly in this case. If the used AT89C2313 Microcontroller in there does nothing else than providing the "copy protection" and does not provide active communication work between the PC and the car and leaves baud rate settings also to the PC, this could be then also an issue.

[stef123]

Well, i had success. After playing around with my spare airbag module in the living room and the Carsoft Adapter it turned out that the voltage was (for me) the problem. I had no sucess to connect to the module with 12 or 13 Volt, but with 11 Volt, so i connected the Laboratory PSU with the Interface directly to the Airbag module in my car and had success to clear its fault memory. Why - no idea. A friend of mine said that it could be proably a fault of the design around the MAX232 used in the CS Interface, if they proably used "a cheap solution" to generate the negative voltage, which i have to check out later. Some more or less identical schematics show at least two capacitors on the MAX232 against V+. V-, going both to GND and no real positive/negative source. I doubt that this is correct. Additionally i have to say that i also tried it out by connecting a 12V/22 Amp PSU to the car, without having the Battery connected, in order to get a stable voltage condition, but that didn´t helped either.

[e36fiend]

I built HansV original 4053 based ADS interface which worked great in INPA, DIS, and NCS Expert for most things but I was never able to connect to ASC or KMB in INPA or NCS. I recently made the modification that benemorious pointed out in post #202 and now INPA can read/access ASC and Instrument Cluster, and NCS can read the modules and outputs the correct TRC files, but I am still unable to successfully code those 2 modules in NCS. I can read and code other modules in NCS Expert without error.

When I go to code the KMB in NCS Expert I get this error message after about 30 seconds:

COAPI-2021: data transmission to ECU disturbed
IFH-0010: DATATRANSMISSION TO CONTROLUNIT DISTURBED

I have a Dell laptop with a legitimate hardware serial port, I get battery and ignition lights in INPA, I've verified integrity on the three data lines that connect from the cluster to the diagnostic port under the hood, I've tried with and without a battery tender on the battery. I even tried a different cluster! I'm pulling my hair out here...

[e36fiend]

Can anyone verify being able to code the cluster in NCS Expert using Hans design? INPA can access the cluster, read errors, and do all the diagnostics just fine.