PC Adapter Measurement: How to Test & Diagnose | Posts 16+

rabbit01 wrote:

Writing the program for runtime testing is quite difficult, in my experience. It probably needs to be done in C++, and you need to have precise knowledge of how to interface with the COM port, or how to capture the signals in real-time.

As I said, it might be difficult to find someone to do that. However, the idea of testing in this way and optimizing the quality of the adapter is a good one!}


Hi Florian,

As someone who's not very tech-savvy, it seems hard to imagine that such a seemingly simple task on a computer could be so difficult to accomplish... but of course, I respect the opinions of those who have more expertise in the area.

While displaying the runtime in real-time wouldn't be essential, it would certainly be ideal if you could adjust a setting on the trimmer and immediately see the corresponding changes on the monitor.

However, performing individual measurements one at a time, with the results displayed afterward, would also achieve the desired outcome.
Would this "waiver" make such a project easier?

A realistic simulation of the adapter seems hardly feasible... Where would one reliably obtain data for the recovery time of semiconductors, depending on the saturation level, which, according to my measurements, has a huge impact on the rise time of signal edges?

@rabbit01

The key specifications of standard optocouplers are all quite similar. One might isolate a higher voltage, while another might provide a higher output current. For our purpose, this is not a significant factor. So, just choose the optocoupler that you find in the library.

Hi,
While I'm not entirely sure what the software is supposed to do, I can say that PCs are fundamentally not capable of real-time operation. That kind of thing only works with specific configurations under DOS, where as few as possible essential drivers, such as those for the mouse, network, and hard drive cache, should be loaded.
A program that directly displays the data graphically and only writes to disk after a measurement cycle would probably be the simplest solution.
According to my understanding, or as I interpret the relevant chapter in the book "PC Interfaces," the COM interface possesses a certain degree of intelligence. You specify general parameters such as the bitrate and then send or receive data words to/from the interface. The interface chip itself controls the bitwise sending and receiving. These functions can be accessed using common programming languages.
It is likely not intended to freely switch or query the transmit and receive lines.
Aside from the fact that VAG-Com runs under Windows, which limits options, especially with companies like Nt & Co, this is likely also the reason why VAG-COM tries out various promising baud rates during the initialization process.
Perhaps there's an expansion card that can be used for such purposes and can be extended with an external circuit.

I'm also curious to see if I'll finally get my Audi 100 with a 2.3 engine.

Christian.

Hello,

Here's just a quick reference to the other thread, as I just wrote a longer discussion about the software issue there...

Best regards,

Jan.

Yes.
I just need a bit more time to write, and when I started, the thread didn't exist yet.
Christian.

Hi Christian,

Sorry, it wasn't meant as criticism... just a reference, because I didn't want to copy and paste the long text again.

Best regards,

Jan.

christians wrote:

I'm also curious to see if I'll finally get my Audi 100 with a 2.3 engine.

Hi Christian,

If it has been possible to maintain stable communication with a portion of the STGe (presumably a system or group), then, in my opinion, the chances are quite good.
If, however, nothing has worked so far, the problem is likely located elsewhere.

Hi Jan,
No problem.

Hi Uwe,
It came with ABS, but not with the engine or air conditioning.
I actually already have the BC 547 as a "C" version, more or less by chance. The local dealer only had one type available.

Christian.

Hi Christian,

Have you ever experimented with the start baud rate?

For me, the 'new' control units, such as ABS, airbags, and instruments, worked without any problems using the default configuration.
I can only connect to the engine control unit with a start baud rate of 9200, instead of 0. Try that.

Regards,
Florian.

Hi Florian,

"No, I wasn't familiar with that. Uwe Ross once wrote in his forum that for the older 2.5L engine, a value of 240 bits/s should be entered, but that didn't help me. If the lower value of 240 was correct, the timing problems caused by optocouplers, etc., probably wouldn't have been so noticeable."
Let me know when I've tried it.
Christian.

I just tried 9200 bits per second with adapter 2.2, but it didn't work.
"9200 seems to be the baud rate 03 for VAG-Com 082, which allows me to access the ABS system. If I set it as the starting value, the ABS is recognized with baud rate 00, otherwise with 03."
Thank you for any advice you may have.
Christian.

Hi Andi and other people interested in adapters,

Since our discussion about "speeding up" the Adapter 2.2 has been ongoing here, I'm now sharing my measurement results regarding the use of capacitors and trimmers.

I only measured the important signal path: TXD -> K-Line -> RXD.

My Adapter 2.2 provided the following response times for a square wave signal at 12 volts on the TXD line:
Rising edge of TXD to K = 1 µsec.
Falling flank of TXD signal: 16 µsec.

With 100 nF in series with 120 ohms for current limiting, all connected in parallel with R7, the result was:
Rising edge of TXD to K = 1 µsec.
Falling flank of TXD signal: 10 µsec.
So, there remains a signal duration distortion of 9 µsec.

Without an acceleration capacitor, but with a trimmer resistor in series with R3 (as intended in version 2.3), the best result achievable was:
Rising edge of TXD to K = 3 µsec.
Falling edge transition time from TXD to K = 3 µsec.
Ideally, there should be no more signal duration distortion.

Runtime information for OK 3, version 2.2:
Rising edge of signal K to RXD = 2 µsec.
Falling edge of signal K to RXD = 40 µsec.

With a 100 nF capacitor connected in parallel with R12, the result was:
Rising edge of signal K to RXD = 3 µsec.
Falling edge of signal K to RXD = 38 µsec.
So, there remains a signal duration distortion of 35 µsec.

Without an acceleration capacitor, but with a trimmer resistor in series with R5a (essentially as intended in version 2.3), the best result achievable was:
Rising edge of signal K to RXD = 5 µsec.
Falling edge of signal K to RXD = 5 µsec.
Ideally, there should be no more signal duration distortion.

If you (Andi) measured significantly different values with your 2.2, it could be due to manufacturing variations between our optocouplers – an additional indication of the usefulness of trimmers in the circuits of the optocouplers.

When increasing the resistance in series with R3 or R5a, the "worse" rise time of the falling edge is initially shortened, but beyond a certain point, the rise time of the rising edge starts to increase.

The optimum point, as I suspect, is where the rise and fall times are equal. Based on my measurements mentioned above, this can be achieved much better with the adapter concept 2.3 compared to using only acceleration capacitors in the 2.2 configuration.

Furthermore, the effort required to upgrade from version 2.2 to 2.3 is not much greater than that of soldering in acceleration capacitors.



I then put together a draft of a minimal adapter without optocouplers or potentiometers and measured its operating times:
Rise time of the TXD signal to level K: approximately 0.2 µsec.
Fall time of the TXD signal's falling edge: 1.5 µsec.

Rise time of the rising edge from K to RXD = 3 µsec.
Fall time of the falling edge from K to RXD = 3.5 µsec.

Its worst-case performance is therefore hardly better than that of a perfectly optimized 2.3 version.
While this simple adapter could likely be accelerated to less than 2 µsec using capacitors, and potentially even minimize signal distortion to near zero, I suspect that this would no longer offer any significant advantages for normal VAGCOM usage compared to a properly calibrated adapter 2.3.

Hello Ulf,

I didn't realize that impedance matching would have such a significant impact on the symmetry of the circuit. The problem with having so many trimmers is that you can only adjust them blindly without specialized measuring equipment. I'll try reproducing the results again, but I'm going on vacation now!

AndyO wrote:

The problem with many trimmers is that you can only adjust them randomly without using specialized measuring equipment.

Hi Andy,

Yes, unfortunately .
I hope that the setup instructions in the description of version 2.3 will at least help users somewhat.

I wish you a wonderful vacation .

Hello Ulf,

I was able to spend another hour experimenting with the circuit. Here are the latest results:
a) The 100nF capacitors, which are connected in parallel with R7 and R10, should remain in the circuit, as they help to stabilize the circuit and prevent variations in timing based on the input amplitude.
b) The 100pF capacitor connected in parallel with R12 should be removed (it doesn't provide any benefit).
c) I reduced the feedback from the K-line to pin 4 of the OK1+2 by connecting VR1 directly to the positive (+) terminal, bypassing R19.
d) The steepness of the flanks of component OK3 can only be improved by reducing the value of resistor R5. However, this will shift the DC operating point. I have now installed a 1 kOhm resistor.
e) LED3 should be enabled during operation (switch S1 closed), as this increases the steepness of the rising and falling edges.
f) I'm keeping the BC879 in the circuit because, due to its higher current gain, it can still switch at higher frequencies. To achieve this, I've increased the value of R13 to 120 kOhms and decreased the value of R12 to 100 kOhms.

I now have a signal delay (Input R3 > K-Line > Output PIN4 OK3) of 14 microseconds rising and 6 microseconds falling. These delays are within the range of 7V < Ue < 12V and 100Hz < fe < 50kHz and are independent of the input amplitude and frequency. The cutoff frequency is approximately 80 kHz (50% amplitude).
I don't know what the maximum baud rate of the control units is, but the circuit easily handles 9600 kbit/s.
Please tell me what maximum frequency you can achieve (R3 connected to PIN4, OK3).

A contribution on the topic of optocouplers (OK).

I built the adapter 2.2 with some simplifications, without doing precise calculations.
It actually works, even though it's probably just a coincidence.

Here are some thought-provoking ideas:

- Problem OK3
In order for the PC to receive data from the K-line, it is likely that DTR needs to be set to +U (positive voltage) and RTS to -U (negative voltage) with respect to the RS232 standard.
Depending on the RS232 interface, a voltage difference of 10-30V results. With a load resistor of 1.5KΩ, the OK signal must drive a current of 6 to 20mA.
If the current transfer function is too low, the output transistor of the OK circuit will switch too slowly or not completely. A voltage greater than 0.3V should be measured across the output transistor of the OK circuit.
In extreme cases, the PC may detect an incorrect input level.
Solution: Increase the resistance at the DTR pin, and decrease the pre-existing resistor for the OK-LED.

A very large power transfer capability, on the other hand, can lead to a fully saturated switching output transistor, which can result in a possible delay in the OK (okay) signal being turned off.
Solution: Increase the value of the current-limiting resistor for the OK-LED. (This may result in a slower 'OK' signal). Alternatively, use the 'OK' signal with the base terminal exposed, and solder a Schottky diode from the base of the 'OK' transistor to the collector.
This prevents the OK transistors from going into saturation, regardless of the control current. (This is the principle behind 74LSxx circuits).


Measurements from some experiment:

OK = IL74 with basic connection; Load 1k at 12V (12mA).

Tax signal: 0 -> 12mA. Output delay: 2 microseconds.
Tax signal: 12mA -> 0mA. Output delay: 16 microseconds.
Tax signal: 12mA -> 0mA. Output delay: 6 microseconds.
Schottky Diode, Base / Collector.

Keep crafting!