New HEX-V2 cable with VCDS, clarifications

Hello to all fellow members. I recently bought a HEX-V2 device and when connect with my car (Audi A4 B9 2.0 TDI Quattro '2018) I had the next message at my screen:
Must register in 12 uses!
and when trying long code helper in module 46:
VCDS is about to send experimental coding to LCode. This information is uverified, untested and you will be using it AT YOUR OWN RISK!

Can somebody explain what these messages mean?
Thanks in advance.
Regards from Greece,
John

Bold message no. 1)

You have to finish the registration process of your HEX-V2 using the VCIConfig tool with comes with VCDS and can be accessed through the Options screen

Bold message no. 2)

HEX-V2 and HEX-NET offer so called "experimental labels" which are non-editorial labels that come directly with ASAM data for that unit.
This means something like "The unit manufactor describes this bit as follows but Ross-Tech did not test if this is true"
Can be helpful at some point!

jpaudioa4 said:

Hello to all fellow members. I recently bought a HEX-V2 device and when connect with my car (Audi A4 B9 2.0 TDI Quattro '2018) I had the next message at my screen:
Must register in 12 uses!

Click to expand...

-Uwe-

jpaudioa4 said:

Hello to all fellow members. I recently bought a HEX-V2 device and when connect with my car (Audi A4 B9 2.0 TDI Quattro '2018) I had the next message at my screen:
...................
and when trying long code helper in module 46:
VCDS is about to send experimental coding to LCode. This information is uverified, untested and you will be using it AT YOUR OWN RISK!

Can somebody explain what these messages mean?
Thanks in advance.
Regards from Greece,
John

hadez16 said:

HEX-V2 and HEX-NET offer so called "experimental labels" which are non-editorial labels that come directly with ASAM data for that unit.
This means something like "The unit manufactor describes this bit as follows but Ross-Tech did not test if this is true"
Can be helpful at some point!

Click to expand...

Click to expand...

I happen to share John's apprehension about the risk-warning message that VCDS reports when accessing the very-useful "yellow" long coding helper screens. The information in these screens largely aligns with the data that's available for long coding from non VCDS devices: this Bit/Byte information from the module's ASAM data is invariably the only data that's available to users from these non-VCDS devices.

Without wishing to be too critical of what is otherwise an excellent addition to the conventional long-coding helper screen facility, IMHO - I believe that the warning message for the "yellow" screens is overly dramatic and somewhat misleading (no offense intended to the facility designers)

Whilst I suspect that many experienced VCDS users on this forum fully understand the context for the warning message, I imagine that the average, or newby user is probably inappropriately deterred from using the "yellow" screens by this melodramatic text. Yes, the data may not be tested by RT staff, but the information comes directly from the module's manufacturer.

To my mind, the status of the long coding information in the "yellow" screens is exactly the same as the status of the information contained in each adaptation channel descriptor within the same module's ASAM database. I'm fairly certain (and I assume) that RT has not individually verified each and every adaptation channel descriptor which comes from the manufacturer -nor is there a need for RT to do this. Nevertheless, a similar warning message about "experimental coding" and "use at your own risk" doesn't appear whenever a VCDS user accesses the adaptation channel database.

Again, I stress that my critique is not meant to under-mine what is an excellent facility. In fact, my suggestion for a change to the text message has quite the opposite objective: to accurately reflect the true status of the information so that greater use of the facility is promoted (because the "yellow" screens can be very useful IMO).

Don

Don,

I love your posts, every time. What about keeping them shorter and concise? My coffee is cold now.

I think mainly the reason why non-VCDS tools offer these coding labels from ASAM data without any clue is.....they don't have conscience.

For example. Unit 46 of MLBevo platform. There are bits that have fancy labels but I'm pretty sure the function behind was discarded during development for some of them. These typical "My car has that, why isn't it ticked" bits.
RT wants to prevent the telephone going nuts because people might rely on labels that are strange or "don't work". Any self-protection phrase is needed

Another reason might be the historical fact that everything was from editorial origin. Poor employees in the basement without daylight, just coding tables and text editor. And a car too. To test them.

I am very happy that the yellow-alert labels are there now because this gave VCDS a giant push (imho).

DV52 said:

To my mind, the status of the long coding information in the "yellow" screens is exactly the same as the status of the information contained in each adaptation channel descriptor within the same module's ASAM database. I'm fairly certain (and I assume) that RT has not individually verified each and every adaptation channel descriptor which comes from the manufacturer.

Click to expand...

That's correct. But the Coding information in those original databases seems to be of much lower quality than the Adaptation Channel info. I think that's because the factory software actively uses the Adaptation Channel data in there, but not the coding info. Thus the Adaptation data is well maintained buy guys in white lab coats, while the coding info is somewhat vestigial. In fact, the original data for many modules has no coding info at all.

-Uwe-

^^^ hmm........ clearly I will submit to your greater knowledge of these things and if the dynamic for the BCM on MQB platform vehicles is an indication, yes there does seem to be shift away from code-string switches. I don't know why this shift has happened. I've not ever contemplated that the reason for the move is because of the apparent "quality" of the code-string descriptors in the ASAM database across every module in the VAG stable. My assumption has always been that such a basic shift in software architecture is too fundamental for it to be driven by a perceived historic problem in code part of the ASAM data. Rather, my amateur guess was that the ever increasing Byte count in newer modules was the impetus for this shift (perhaps?). But mine is very much an "observational guess" based on nothing more than the uninformed machinations of a troubled mind

As I have said, on devices that don't have Ross Tech's excellent traditional long code helper screens - the same information that VCDS calls "experimental" and warns to "use at own risk" is the sole data for long coding changes. And, whilst I would never rate non VCDS devices on a par with RT's products, some of these devices are mature industry tools. I use some of these non-VCDS devices and AFAIK there has never been a systemic problem with the ASAM code string descriptors (albeit I can agree that perhaps a small number of these descriptors may be in error - just as I know that the same applies for a small number of the descriptors in the VCDS traditional long coding helper screen).

In any event, thanks for the response - I will consider the matter further when next I contemplate the meaning of life and everthing

Don