VCX nano intermittent comms loss

TJBaker57

Lifetime VIP Donor
Member
Aug 16, 2015
3,316
Colorado
First, I see that the recording begins with Mode $2A traffic without any Mode $2C (setup) commands having been seen. That seems suspicious


I suspect that the engine speed control page is similar to other such device control pages I have recorded. I have seen that a block of DPIDs are configured when one opens the page where the control can be enabled/adjusted. The DPID block seems to be the same block that is displayed when simply viewing live data.

assuming the timestamps are trustworthy,


A word about timestamps. Since we know these cannot be the actual time of each message, the time required to send each message simply doesn't allow for the timestamping we are seeing, I believe the serial terminal app is buffering data when it is not able to write to the file due to other tasks operating on the host device. When the terminal app is again able to write to the file all the buffered messages get the current timestamp. Make sense?

Also, I see a lot of level 0 (highest priority) functionally addressed traffic too, typically using Primary ID $FF ("Network Control").

There are 412 priority 0 (highest priority) messages, all of these are the normal 'heartbeat' messages required to be sent from every node on the network. Each node will send one each 2 seconds. If they don't that causes those "lost communications with 'xyz' " DTC codes we sometimes encounter.

I too will continue to peruse this log file, but maybe I should not be doing this at 75 mph on the Interstate !!
 

AmpOverload

Member
Jul 10, 2023
161
USA
The analytical portion of the program has extended beyond my working knowledge. If there are specific experiments or testing sequences that might be useful in shedding new light please let me know.
I understand. This stuff can get ugly pretty quickly!

I appreciate your having made that log available. Like TJ, I will often search through some old log files to see how things behave (or misbehave!).

I suspect that the engine speed control page is similar to other such device control pages I have recorded.
Your suspicion is completely correct. I too have seen many of these Tech2Win/Tech2 "control" pages where the Mode $2C setup is essentially exactly the same as the "data" page. Frankly, I wish they didn't do it that way because there's usually way more data than I want/need on a "control" page and it just makes for a "bogged down" traffic load!

Having said that, if the recording started on the page where the menu option is selected, then I would still expect to see all the Mode $2C "setup" commands and I see none. Looked at from a different angle, if that traffic was from a setup on a previous page (maybe even on the same "Engine Speed Control" page), it should have been shut down when the page was exited. But maybe @azswiss exited the page, started recording, then re-entered it and the periodic Mode $2A traffic was still buffered by the Android serial terminal app. That would be the only thing that makes sense to me, frankly. It's more of a curiosity than a problem, though.

A word about timestamps.
Yes, the timestamps are obviously aggregated. But they still serve as a decent "relative" indicator. Although, as I said earlier, they sometimes just get in the way.

I'd like to design and build a (USB, not wireless!) scantool that can do proper time-stamping and recording of traffic, with an actual real-time clock chip to allow time synchronization with an external source (like a camera recording something). That would make investigations of this sort far more decisive and convenient.

There are 412 priority 0 (highest priority) messages, all of these are the normal 'heartbeat' messages required to be sent from every node on the network.
I knew that there was network "heartbeat" traffic, but I was surprised to see so many of the messages at that priority level and, to a lesser extent, to see the volume of them. That's one of the things I tend to forget about when I use my simulator because that stuff never appears (for better or worse!). :wink:

I too will continue to peruse this log file, but maybe I should not be doing this at 75 mph on the Interstate !!
😲 Stay safe -- we need all the OBD2 gurus we can find!

I think my next step will be to experiment on a real vehicle to see if I can replicate the issue.
 

AmpOverload

Member
Jul 10, 2023
161
USA
I unexpectedly had access to a GM vehicle (2004 Century) today, so I took the opportunity to do some engine speed control testing under Tech2Win with the VCX Nano, logging the traffic with an "ATMA" command on a Y-cabled USB scantool, specifically model "ElmScan5 Compact USB" made by 'ScanTool.net'. (Curiously, the Tech2Win screen is called "RPM Control" on this vehicle and not "Engine Speed Control" as it's called for the 2003 trucks.)

The bad news is that I could not duplicate the problem. I never once saw the "No Communications with Vehicle" screen and I spent a long time testing on that screen and several others, including both "control" pages and "data" pages. I even had Tech2Win's "Automatic Screenshots" option enabled during much of my testing, in part to "load" the VCX Nano / Tech2Win laptop (same one mentioned earlier in this thread) a bit, trying to trigger the issue. I also ran the "Cylinder Power Balance" test on each cylinder and there were simply no comm dropouts at all.

Here's the "RPM Control" screen:

RPM-Control-on-2004-Buick.png

Examining the log from the "RPM Control" page's testing, I see Mode $3F commands coming much more steadily than I saw in the log from @azswiss. In my log, I never saw a time difference between successive Mode $3F commands of even as much as 3 seconds. Most were just a bit over the 2-second mark. I wonder if that's essentially the problem, even though I have no real explanation for the discrepancy.

Another thing that struck me in my log is the complete absence of priority-level-0 (highest priority) functionally addressed traffic from the nodes. Literally 99.6% (1110 out of 1114) of those "heartbeat" messages on this vehicle (from 6 nodes) are at the lowest priority level (7), which is why I was so surprised to see so many messages at the highest priority level on @azswiss' log.

I don't know if this gets us any closer to an answer, but thought I'd report it, FWIW.
 

azswiss

Original poster
Member
May 23, 2021
1,007
Tempe, AZ
FWIW, one more dataset: network traffic logged while revving the engine several times without the VCX Nano attached. As with the prior dataset, lots of priority-level-0 messages (81 out 343 lines).
 

Attachments

  • TAC_7-21-24.txt
    6.8 KB · Views: 2

AmpOverload

Member
Jul 10, 2023
161
USA
After lots of testing, I'm close to declaring defeat. ☹️

Short of effectively killing all communication from the vehicle to Tech2Win, I simply cannot duplicate this problem on my end. Basically, I've been trying to "trigger" Tech2Win into displaying the "No Communications with Vehicle" screen when running it on the "Engine Speed Control" screen with your vehicle settings.

Using my so-called "HVS" ("Hardware Vehicle Simulator"), I've tried slowing the transmission of the vehicle's Mode $2A periodic replies (the ones triggered by Mode $2C "setup PIDs" commands and Mode $2A "activation" commands). That actually begins to trigger the "No Comm{...}" screen when the periodic transmission rate drops to a period of about 650 msec when you're on a page (e.g. "Engine Data 1") without other periodic VPW traffic. But since the "Engine Speed Control" page (on your vehicle) also sends Mode $22 commands to query the RPM and VSS (Vehicle Speed Sensor) PIDs, Tech2Win (unsurprisingly) seems to happily see replies to those commands as vehicle "communication" and does not trigger the "No Comm{...}" screen. I even slowed the Mode $2A reply rate to well below what I think is the slowest supported rate, all the way down to a 3-second period, and still could not trigger the "No Comm{...}" screen.

Based on your original 'ATMA' log, I also modified my sim to mimic your exact vehicle by sending repeated maximum-priority (level zero) "Node Alive" functionally addressed messages (Primary ID $FE/$FF, Secondary ID $03), from these 10 specific nodes (whose bus address is the 3rd byte on each line):
Code:
08 FF 1A 03 9A
08 FF 29 03 8F
08 FF 40 03 06
08 FF 58 03 E8
08 FF 60 03 73
08 FF 80 03 25
08 FF 98 03 CB
08 FF A0 03 50
08 FF A1 03 1C
08 FF A7 03 A9
Sending simulated traffic from those 10 nodes did not make Tech2Win unhappy enough to trigger even a single "No Comm{...}" screen, even when used in conjunction with the aforementioned slowdown of Mode $2A replies.

Ideally, we'd have more than 1 vehicle where this problem occurs.

Frankly, we should consider that the Tech2 itself may not be immune to this issue. So, although it's understandable, it's somewhat unfortunate that the title of this thread (and the sub-forum in which it was created) sort of implies that this is a VCX Nano issue. I have no real evidence of that so far. It might help if a few other folks using Tech2Win or owning a Tech2 could try the "Engine Speed Control" page (or, "RPM Control" page, as it's called with some vehicles) to see if that "No Communications with Vehicle" screen ever appears, however briefly and/or infrequently.

It would also be nice to run Tech2Win with an SAE J2534 device other than the VCX Nano.

At this point, I can only suggest something that you've already done to some extent -- try to pull fuses to remove other nodes' traffic from the VPW bus to see if it helps enough to avoid the "No Comm{...}" screens.

Lastly, on the chance that it could be an issue with the VXDIAG VCX Nano's software/firmware, it might be useful to compare our versions. My VCX Nano reports "Firmware" version 1.9.4.2, dated 2023-03-31 and "Driver" version 1.8.9.0, dated 2022-06-01. What does yours report (in "VX Manager")?
 

azswiss

Original poster
Member
May 23, 2021
1,007
Tempe, AZ
Lastly, on the chance that it could be an issue with the VXDIAG VCX Nano's software/firmware, it might be useful to compare our versions. My VCX Nano reports "Firmware" version 1.9.4.2, dated 2023-03-31 and "Driver" version 1.8.9.0, dated 2022-06-01. What does yours report (in "VX Manager")?
Firmware: Version 1.9.5.0 dated 2024-05-21
Driver: Version 1.8.9.0 dated 2022-06-01

Pending any further revelations I think this topic has been worked as far as it can be taken absent detailed knowledge of the overall Tech2Win system and the VxDiag hack of Tech2Win.

Many, many thanks to @AmpOverload and @TJBaker57 for their insights and analytical support.

That said, time to put a fork in this thread!
 

Forum Statistics

Threads
23,721
Posts
642,586
Members
19,251
Latest member
Sheik480

Staff Online

Members Online