Test software for VAGCOM adapters?

Hello everyone.

My recent experiences with VAGCOM have shown that the quality of an adapter is related to factors such as the signal delay within the adapter (i.e., its response time).
Therefore, an adapter should be optimized for the shortest possible processing times during its development and adjustment.
Something like that can be achieved using a rectangular wave generator and an oscilloscope, but this is probably not available to every VAGCOM user or adapter DIY enthusiast.

An alternative would be to use the existing PC as a measurement instrument.
"Every signal that the PC sends to the K-line is received back at pin RXD as an echo." The measurement of this delay could be used directly as a quality criterion for the adapter and its interaction with the computer, and in the case of adjustable adapters, it could be used as a setting aid.
In addition, this could also be used to test the quality of commercially available ready-made adapters.

The adapter test in the VAGCOM menu apparently checks the adapter function so loosely that even very slow adapters are recognized as OK, which can still fail in actual operation.

For a more precise analysis, appropriate software would need to be available, which should be able to perform the following tasks.
Default state: RTS = low, DTR = high (the other pins of the COM port do not matter).
Measurement operation: The TXD line is switched from low to high and back approximately every 0.5 seconds. The time intervals between each transmit pulse on the TXD line and the next corresponding signal edge on the RXD line are measured and displayed in real-time on the monitor.

Since the rise and fall times of a signal can be different, both times must be output simultaneously.
The measurement range should be approximately 1 to 100 microseconds, and the resolution should be around 1 microsecond.

Where can I find such software, or who could write something like that and potentially make it available for download on Rainer's website?

Following a brief email exchange with Ulf, and now with this statement posted on the forum, I'd like to add my thoughts on the matter, as the topic falls squarely within my area of expertise.

Such a program as a calibration aid would undoubtedly be useful, but I believe it is not feasible, and that is for a number of reasons.

Timer Resolution: To achieve accurate measurements, you need a timer that is at least as good, and most PCs don't offer that. It's generally not possible to achieve accuracy much better than 10 microseconds, even though various system interfaces might suggest otherwise. The only possibility would be to use the CPU's performance counters (starting with the Pentium 1, CPUs internally count their clock cycles), which would provide very accurate results, but at the cost of a high dependency on specific CPUs and motherboards. The next two problems will not be solved with this.

Interrupts: When working at a "high level," an operating system sits between the program and the hardware, with various interrupt handlers that can unexpectedly interfere with the program's execution. These can range from the operating system's timer service to internal cleanup processes, and even to other devices to which data is being sent, such as a hard drive or CD-ROM. Such influences can lead to unpredictable delays that make planned measurements impossible. It's difficult to completely disable these interrupts, even when using a primitive DOS as the operating system. A possible solution would be to use a very small and predictable real-time kernel (e.g., RTLinux, QNX, or Lynx), but this would again lead to a specialized solution that would involve a significant amount of effort. And... by solving that, we move on to the next problem.

PC Hardware: PC hardware is unpredictable. For example, PCI devices like graphics cards (and AGP, which is essentially a specialized form of PCI) can block the PCI bus for UNPREDICTABLY long periods, ultimately leading to a situation where we can't receive data from the serial ports with a known delay, because these are often connected to the PCI bus via a PCI/ISA bridge. This doesn't necessarily impair the functionality, but it does compromise predictability. This problem is very serious. Companies that run real-time systems on PC hardware must carefully select all components and meticulously evaluate this behavior, because this information is not typically included in the specifications. Therefore, we would have to do the same thing, but that's not possible for many reasons, because our computers are all very different.

These three arguments highlight one of the most important aspects of real-time systems: they don't necessarily need to be FAST (which is a common misconception), but rather PREDICTABLE (which also includes predictable and sufficient performance).

Therefore, I believe that such a measurement program is unfortunately not feasible without additional hardware.

With additional hardware, it's relatively straightforward to, for example, use large FIFOs to read data streams and simultaneously store timestamps from a quartz oscillator, and then make this data accessible via ISA or PCI. It decouples the entire process in terms of timing, but it's also not justified by the amount of effort required.

Overall, it's possible that reasons mentioned above might be responsible for why VAGCOM simply doesn't work on some PCs.

And... there's one more (optional) obstacle: Modern COM interfaces have FIFOs (First-In, First-Out buffers) through which they buffer data. So, the CPU doesn't actually know exactly when something arrives; it only becomes aware when the FIFO has exceeded a certain fill level. We would also have to disable that, which in turn would significantly slow down the COM operations, making high measurement resolutions illusory.

Best regards,

Jan.

Hi Jan,

If I understand the basic premise correctly, when faced with such "simple" tasks, PCs can be compared to a mathematics professor who, due to their vast knowledge, can no longer add 2 + 2.

Too bad, then.
There are still some products that allow you to use a PC as a (memory?) oscilloscope, but then you probably lose the option to generate square waves... also, I don't know how much something like that costs.

However, VAGCOM seems to have the fundamental ability to "control" the COM port in real-time.
Otherwise, a dialogue with the STGen (presumably a group of people) in the carriage would not be possible, as it is essential to adhere to certain (short) timeframes.

Perhaps VAGCOM could be analyzed in a way that allows one to access the COM port directly, and then build an adapter testing program around that.
But I probably think too simply and too "analog" again in this case as well.

Well, what can't be done, can't be done. That would have been too good to be true.

Thank you again for all the informative contributions on the topic.

Hi,
I don't think VAG-Com can do that.
The serial controller component of the PC is responsible for ensuring compliance with time windows and other timing constraints.

The Ross website also features statements indicating that VAG-COM only uses standard Windows functions, so that separate routines are not needed for each Windows version. To improve query speed, we are considering or planning to build an adapter with its own intelligence.

Christian

Hello,

The main function of the adapter is to provide potential separation and to adapt the signals to the control unit. The circuit should achieve this with the lowest possible propagation delays, phase shifts, and pulse distortions. If we assume a data rate of 9,600 bits per second, the signal delays should be at least five times lower. This means that for a data rate of 10,000 bits per second, the maximum allowable signal delay would be 1/10,000 seconds, or 100 microseconds. With a factor of 5, this becomes 20 microseconds. This corresponds to a test frequency of a 50 kHz square wave. It's quite obvious that it's difficult to replicate a 50 kHz generator and oscilloscope over a serial interface.
Without my accelerating measures, using 100nF capacitors across R7 and R10, and 100pF capacitors across R12, the circuit was operating at that limit. Now, I'm getting approximately 6us. That should be enough.

Hello,

Regarding the real-time capability of COM control, I agree with my predecessors – the controller handles this automatically. The data generated is placed in a FIFO (First-In, First-Out buffer), and when the FIFO reaches a certain fill level, an interrupt is triggered. If the CPU can process the data before the FIFO becomes completely full, the port continues to operate at its maximum speed (the CPU essentially empties the FIFO and then moves on to other tasks). However, if the CPU cannot keep up, the data flow will be interrupted. So, the trick is to trigger an IRQ approximately every 10-12 bytes (FIFOs usually have 16 bytes), and at 115 kbit/s = 15 KB/s, this translates to roughly 1500 IRQs per second, which can be easily handled under normal circumstances.

Regarding VAGCOM: It only needs to be fast enough to quickly receive data from the drivers (which read the FIFOs) and pass it on; it doesn't need to do anything more complex. Specifically, it doesn't directly access the individual bits; instead, the controller's hardware assembles them into bytes according to the protocol.

Regarding PC-based oscilloscopes: If I'm not mistaken, you can find something like that at Conrad. However, they use specialized hardware: a plug-in card implements the time-critical components, and the PC then serves as a display and control interface for that card. It's essentially the luxury version of the FIFO game.

At our university, someone once built an ISA card for parallel, real-time measurements (i.e., 32 inputs, each with 1 bit in parallel, from different sources). The basic principle involves a large FIFO buffer and a counter, the latter being incremented by an 8 MHz crystal oscillator. In each cycle, this counter and the mask of the 32 bits are pushed into the very large FIFO (probably around 16 KB), and the CPU reads this data later for analysis. So, here again, the real-time requirement is being shifted to extra hardware. With this device, such measurements should be possible, but the effort involved is also considerable.

Best regards,

Jan.

The only point I see for troubleshooting this circuit is the signal propagation time. It is assumed that the application runs flawlessly at the higher protocol layers. The adapter cannot do more than ensure that the signal passes through without any delay.

Okay, I'm going to out myself as a microprocessor god at the hardware level (see also profile) .

Admittedly, I've never really examined the adapter in detail, regardless of the model. Given the maximum data rates of 10.4 kbaud and the components used, the signal propagation time shouldn't have a significant impact. Something would have to be seriously wrong for that to be the case. Also, unlike many others, I haven't experienced any problems with the original Jeff's PCB, neither with different vehicles nor with the two Toshiba laptops I've used.

'In that case, I think the issue of real-time performance in the operating system is more likely. The only solution seems to be to kill processes aggressively. But how can a 266 MHz P-II with 64MB of RAM running Windows 98SE manage that, especially when it has many programs running in the background?'

okok, I'll take a look at the whole thing next year ( ) and tinker with it. If necessary, there will be a circuit with a DC/DC converter to boost the PC side a bit... but it might take some time, as traditionally, customers go crazy around the beginning of the year ( ).

CU Gremlin.