Re: Measuring adapters on PC | Posts 16+

rabbit01 wrote:

Implementing the program and conducting runtime tests is, in my experience, quite challenging. It likely needs to be written in C++, and requires precise knowledge of how to interface with the COM port and, in particular, how to capture real-time signals. As I mentioned before, finding someone with this expertise could be difficult. The idea of testing this way and optimizing the adapter's quality is good!

Hi Florian

As someone who is quite new to computers, it seems difficult to imagine that such a simple task on the PC could be so challenging to accomplish. However, I respect the opinions of those who have more experience.

Displaying the runtime in real-time wouldn't be necessary, but it would certainly be optimal if you were working on a trimmer and could immediately see the changes on the monitor.

A measurement that can be started individually with "subsequent" result presentation would also fulfill this purpose.
Would this "waiver" make such a project easier?

A realistic simulation of the adapter seems unlikely. . . where would one reliably obtain data on the recovery time of semiconductors depending on saturation, which, according to my measurements, has a significant impact on the signal flank duration?

@rabbit01

The relevant characteristics of standard optocouplers are all similar. One isolates a higher voltage, while the other provides a higher output current. For our purpose, this is irrelevant. So, take the optocoupler that you find in the library.

[Translating...]

Hi,
So hundertpro hab ich zwar nicht verstanden was die Software genau können soll aber: Pc´s sind grundsätzlich nicht echtzeitfähig. Sowas funktioniert nur mit Haken und Ösen unter Dos, wobei möglichst wenig resistente Treiber wie Maus, Netzwerk, Festplattencache geladen sein dürfen.
Ein Programm das die Daten direkt graphisch ausgibt und nur nach Ablauf eines Meßzyklus auf Platte schreibt wär wohl noch am einfachsten.
Nach meinem Verständnis bzw. so wie ich das entsprechende Kapitel im Buch PC-Schnittstellen deute, hat die Com-Schnittstelle eine gewisse Eigenintelligenz, man gibt allgemeine Parameter wie die Bitrate ein und schickt oder Empfängt dann Datenworte an die / von der Schnittstelle. Das Bitweise Senden und Empfangen steuert der Schnittstellenbaustein selber. Diese Funktionen kann man mit üblichen Programmiersprachen aufrufen.
Es ist aber wohl nicht vorgesehen die Sende- und Empfangsleitung "frei" hin und her zu schalten oder abzufragen.
Mal abgesehen davon, daß VAG-Com unter Windows läuft, wo einem speziell bei Nt &Co die Hände gebunden sind, wird das wohl auch der Grund sein weshalb VAG-COM beim Initialisieren verschiedene erfolgversprechende Bit-Raten durchprobiert.
Vielleicht gibt es ja eine Steckkarte, die man für solche Zwecke mit einer externen Schaltung erweitern kann.

Bin im Übrigen mal gespannt ob ich mit 2.3 endlich meinem Audi100 beikomme.

Christian

[Translating...]

Hallo,

hier nur ein kleiner Verweis auf den anderen Thread, da habe ich gerade eine laengere Abhandlung zu der Software-Frage geschrieben...

Viele Gruesse,

Jan

[Translating...]

Ja,
ich brauch halt etwas länger fürs schreiben und als ich angfangen habe gabs den Thread noch nicht.
Christian

[Translating...]

Hi Christian,

sorry, war nicht als Kritik gemeint... nur als Verweis, weil ich den langen Text hier nicht nochmal reinkopieren wollte.

Viele Gruesse,

Jan

[Translating...]

christians wrote:

Bin im Übrigen mal gespannt ob ich mit 2.3 endlich meinem Audi100 beikomme.

Hi Christian,

wenn bisher mit einen Teil der STGe eine stablie Kommunikation möglich war, stehen die Chancen IMO recht gut.
Wenn aber bisher gar nix ging, dürfte das Problem eher woanders liegen . . .

[Translating...]

Hi Jan,
ist kein Thema.

Hi Uwe,
mit ABS gings, mit Motor und Klima nicht.
Den BC 547 hab ich eher zufällig schon als C drin. Der Händler vor Ort hatte eh nur eine Sorte.

Christian

Hi Christian,

Have you ever experimented with the start baud rate?

With me, the 'new' control units such as ABS, airbags, and instruments worked perfectly with the default configuration.
I can only get the motor control unit to work with a start baud rate of 9200, instead of 0. Okay, here's the translation:

Try it out.

Greetings
Florian

[Translating...]

Hi Florian,

nein, die kannte ich noch nicht. Uwe Ross hat in seinem Forum mal geschrieben, daß beim alten 2,5 L Motor 240 Bit/s einzugeben wären, das hat bei mir aber nicht geholfen. Wenn die niedrigen 240 richtig wären, hätten sich wohl auch die Timingprobleme durch Optokoppler etc. nicht so sehr bemerkbar gemacht.
Melde mich wenn ichs probiert habe.
Christian

[Translating...]

Hab gerade 9200 Bit/s mit Adapter 2.2 probiert.Ohne Erfolg.
9200 scheint bei VAG-Com 082 die Baudrate 03 zu sein, damit kann ich bei mir das ABS ansprechen. Hab ich das als Startwert, wird ABS mit Baudrate 00 erkannt, sonst mit 03.
Trotzdem Danke für jeden Hinweis.
Christian

Hi Andi and other adapter enthusiasts

Since our discussion about "accelerating" the 2.2 adapter has been ongoing here, I would like to share my results from using capacitors or trimmers.

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

My adapter 2.2 provided the following runtimes when connected to TXD with a 12V rectangle signal:
Increasing slope from TXD at K = 1 µsec
Falling flank of TXD after K = 16 µsec

With 100 nF in series with 120 Ohms as a current-limiting component, the entire assembly connected in parallel to R7 resulted in:
Increasing slope from TXD at K = 1 µsec
Falling flank of TXD after K = 10 µsec
so, eine remaining signal duration distortion of 9 µsec.

Without an acceleration capacitor, but with a trimmer in series with R3 (as specified in version 2.3), the best results were achieved:
Increasing slope from TXD to K = 3 µsec
Falling falling side from TXD to K = 3 µsec
So, ideally, there should be no more signal duration distortion.

Run times over OK 3 in the original version 2.2:
Rising edge from K to RXD = 2 µsec
Falling edge from K to RXD = 40 µsec

With 100 nF in parallel to R12, the following result was obtained:
Rising edge from K to RXD = 3 µsec
Falling edge from K to RXD = 38 µsec
so, a remaining signal duration distortion of 35 µsec.

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

If you (Andi) measured significantly different values on your 2.2, this could be due to, for example, manufacturing variations between our optocouplers – another indication of the usefulness of trimmers in the optocoupler circuits.

When increasing the resistance in series with R3, R5a initially shortens the "worse" falling-side runtime, after which the rising-side runtime increases.

The optimum I suspect lies where the times for rising and falling flanks are equal, and this can be determined according to my previous explanation. Measurements using the concept of adapter 2.3 are more successful than just using acceleration capacitors in 2.2.

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



I've also put together my own design for a minimal adapter without an optocoupler and trimmer, and I've measured its runtime:
Rise time of the rising edge of TXD after K = approximately 0.2 µsec
Fall time of the falling edge of TXD after K = 1.5 µsec

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

Therefore, its worst-case runtime is hardly better than that of an optimally tuned 2.3.
While this simple adapter with capacitors could likely reduce the response time to less than 2 µsec and potentially bring the signal distortion to near zero, I suspect that this would not offer any further advantages over a properly adjusted 2.3 adapter for normal VAGCOM usage.

Hello Ulf,

I didn't expect the impedance matching to have such a significant impact on the circuit symmetry. The problem with all the trimmers is that you can only adjust them without advanced measuring equipment by trial and error. I will redo it all, but I'm going on vacation first.

AndyO wrote:

The problem with many trimmers is that you can only adjust them roughly without advanced measuring devices.

Hi Andy

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

Wishing you a wonderful vacation

Hello Ulf,

was able to play with the switch for another hour. Here are the latest results:
a) The 100nF in parallel with R7 and R10 remain in place, as these stabilize the circuit against timing drift as a function of the input amplitude.
b) The 100pF in parallel to R12 remains outside (is not useful).
c) I have reduced the K-line feedback to pin 4 of the OK1+2 by connecting VR1 directly to + instead of through R19.
d) The flank steepness of OK3 can only be improved from the outgoing side by reducing R5. However, this results in a shift of the DC operating point. I now have 1 KOhm in it.
e) The LED3 should be bridged (switch S1 closed) during operation, as this increases the flank steepness.
f) My BC879 remains in place, as it can still switch due to the higher current gain at higher frequencies. I have increased R13 to 120 kOhms and decreased R12 to 100 kOhms for this purpose.

I now have a signal delay (Input R3 >K-Line> Output PIN4 OK3) of 14us increasing and 6us decreasing. The delays are in the range of 7V<Ue<12V and 100Hz<fe<50KHz, 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 ECUs is, but 9600 KBit/s is definitely sufficient.
Please let me know what cutoff frequency you are achieving (R3 to PIN4 OK3).

An Optocoupler (OK):

I built the 2.2 adapter with some simplifications, without doing precise calculations.
He works even though it's just luck.

Here are some thought starters:

- Problem OK3
In order for the PC to receive the K-Line, the DTR should be set to +U(rs232) and the RTS should be set to -U(rs232).
Depending on the RS232 interface, a voltage difference of 10 - 30V results with a load resistance of 1K5. This means that the OK signal must drive a current of 6 to 20 mA.
Due to a limited power transmission function, the OK output transistor now switches too slowly or does not switch completely through. It is possible to measure a voltage > 0.3V above the output transistor of the OK.
In extreme cases, the PC recognizes an incorrect input level.
Solution: Increase resistance in the DTR, reduce the pre-resistance for the OK LED.

A very large current transfer function, on the other hand, leads to a fully saturated output transistor, and thus to a possible delay in the OK signal.
Solution: Use a larger OK-LED. (This may result in a slower OK activation.) Or, use an OK with a separate base and solder a Schottky diode from the base of the OK transistor to the collector.
This prevents the oversteering of the OK transistors, regardless of the control current. (Principle of 74LSxx circuits)


Measurement values from some experiment:

OK = IL74 with base connection; Last 1k at 12V (12mA)

Tax Signal -> 0->12mA Delay Output 2uS
Steuersignal 12mA -> 0mA Delay Ausgang 16uS
Steuersignal 12mA -> 0mA Delay Ausgang 6uS mit
Schottky Diode Base / Collector

keep building!