VCX nano intermittent comms loss

[azswiss]

Ran a can of ACDelco GM Original Equipment 10-3007 Top Engine Cleaner thru the throttle body. Some smoke but definitely less than the first time (April last year).

Per the instructions, I set the engine at 900RPM using Tech2Win and a VCX Nano. Somewhat annoyingly, an error message indicating "Loss of Communication" with the vehicle popped up repeatedly during the process.

This happened last time so before I tried again this time I made sure to disable all non-essential services & processes on my laptop (an old Dell Intel i5 Win7 Pro 32 machine dedicated for just this use) with the intent of reducing/eliminating competition for resources (CPU, memory, bus bandwidth, etc ). The frequency & duration of the communication losses was reduced as compared to last time so a modest improvement but still problematic.

Wondering if anyone else has seen this problem or has any thoughts.

 

[Mooseman]

Maybe start a thread in the scan tools section. Maybe someone else has had the same issue.

 

[TJBaker57]

I would be tempted to use an OBD2 splitter and record all serial data traffic during the procedure with an ELM type device in bus monitoring mode.

For those who aren't familiar, an ELM type OBD2 device has the ability to be a silent listener on the vehicle network, simply decoding all the traffic without ever transmitting anything on the network. No part of the vehicle will even be aware of its' being there. With the right serial terminal app you can record all the traffic for examination.

No guarantee you would find anything definitive but it is likely some evidence of what was going on would be seen.

 

[Mooseman]

Moved to its own thread .

 

[azswiss]

@TJBaker57, have you attempted any Mode $08 stuff via ELM327 using a terminal app? Do you have any sample traffic?

 

[TJBaker57]

@TJBaker57, have you attempted any Mode $08 stuff via ELM327 using a terminal app? Do you have any sample traffic?

I have not. Since the Tech 2 uses mode $AE for device control I have only experimented with that mode and it does not appear to be similar across or even within platforms.

What would you be looking at doing with mode $08? Do we even know if mode $08 is supported?

 

[TJBaker57]

I will admit I have never looked at this, until now. I have a 2005 P10 at the ready in a drawer here in the house. I read a little in J1979 and fiddled around a bit and got a positive response to a mode $08, TID $01 request.

I included a mode $09 02 request to get the VIN of this test PCM.

Is this related to the thread title in some way?

 

[azswiss]

Assumed Mode $08 (request control of on-board system, test, or component) would be involved in attempting to command a specific PCM-controlled parameter like RPM. Was not aware of Mode $AE (request device control).

I want to try out your suggestion on monitoring the traffic with an OBD2 splitter while using Tech2Win via a VCX Nano to hold the engine at a specific RPM (Tech2 Path – Powertrain > Special Functions > Special Functions (PCM) > TAC System > RPM Control). I was interested in understanding what the traffic looks like when a Tech2 (or Tech2Win) is performing this type of operation, or any other type of bi-directional control.

Ultimately, my objective is to understand the root cause of the intermittent loss of connection between Tech2Win and the vehicle. Is it an app problem (Tech2Win, VXDiag Manager), a PC problem, or an interface hardware problem (VCXNano).

 

[Mooseman]

Maybe @mrrsm could chime in but I do remember a procedure to monitor network traffic using either a DMM or a Pico scope. This should tell if it's a problem with the VCX/software or an actual problem with the network.

 

[TJBaker57]

While a scope has certainly its' place this is not it. Unless there is some signal interference going on. That seems unlikely given the nature of the issue here.

A scope will show the waveforms of the pulses and so on but it cannot decode these pulses into messages. Recording the traffic on an OBD2 adapter yields the actual messages being sent by all modules on the network.

The tricky part is learning how to read these messages and understand what they mean. Somewhere on this site I have a thread on serial data traffic that dives into this. It can be a little overwhelming.

That's where community members like @AmpOverload and myself are handy. I have spent an insane amount of time studying (playing) with this stuff.

@azswiss did at least once record some serial data before and made it available to me when we were investigating key fob/door unlock messaging.

The thing needed here is the OBD2 splitter. I first purchased some cable splitters but I now use a cable exension and a 'block' splitter at the remote end. I find these more convenient.

 

[TJBaker57]

A small thread drift footnote;

The only mode $08 test I see listed is for an Evap leak test. And the text in J1979 seems to say that this can request that the PCM enable conditions for the evaporative system leak test but does not actually run the test.

Curious. I may try this on my TrailBlazer to see if it activates the purge and/or vent solenoids.

 

[AmpOverload]

Per the instructions, I set the engine at 900RPM using Tech2Win and a VCX Nano. Somewhat annoyingly, an error message indicating "Loss of Communication" with the vehicle popped up repeatedly during the process.

This happened last time so before I tried again this time I made sure to disable all non-essential services & processes on my laptop (an old Dell Intel i5 Win7 Pro 32 machine dedicated for just this use) with the intent of reducing/eliminating competition for resources (CPU, memory, bus bandwidth, etc ). The frequency & duration of the communication losses was reduced as compared to last time so a modest improvement but still problematic.

Wondering if anyone else has seen this problem or has any thoughts.

TL;DR: I've seen (many times!) the problem referred to by this thread title. But I suspect that it will be hard to isolate and characterize.

I have a VXDIAG VCX Nano and have run Tech2Win extensively with it.

I'm assuming that @azswiss is seeing this screen:



If so, I've seen that before many times and also wondered why.

I've been using Tech2Win with my "hardware vehicle simulators" (a.k.a. "HVS"), for both VPW and CAN protocols. In fact, I have far more hours with Tech2Win and my HVS hardware than I do with Tech2Win and actual GM vehicles, simply because I can learn more that way! But I've seen the issue with both simulated and real GM vehicles.

Based on that experience, I've been unable to find a clear pattern as to when these "No Communications with Vehicle" screens appear or why. Admittedly, I have not spent extensive time investigating that, specifically.

There are (potentially) several things which, IMHO, could trigger those messages:

• improper communication from the vehicle (whether from traffic collisions on the VPW bus, malformed VPW signals, or even just badly coded ECUs)
• scantool problems (hardware and/or firmware)
• cabling problems
• vehicle and/or scantool voltage issues (strength, quality, etc)
• host computer (running Tech2Win) issues (e.g. interruptions, speed, etc)
• VCX Nano hardware/firmware quality issues
• Tech2Win software quality issues

The problem is that the Tech2Win message gives you no real insight into why they're appearing.

When I'm running with one of my HVSes, I can rule out traffic collisions from other nodes (ECUs) on the VPW bus because I completely control the replies on the bus, from all nodes. And, of course, I don't generate any traffic on the bus except to reply to a command from the scantool+software (VCX Nano + Tech2Win in this case). And yet I still see the "No Communications with Vehicle" screen from time to time. I've been slightly suspicious that maybe my simulator's firmware isn't consistently generating a perfect VPW waveform, because, IIRC, it doesn't follow the standard 100%. But I have not had time to investigate that possibility. In reality, I doubt that that is the issue, though.

When I'm running on the actual vehicle, I cannot rule out traffic from other nodes causing the "No Communications with Vehicle" screen. I will assume (bad idea, as we all know) that Tech2Win is sending periodic Mode $3F ("Test Device Present") commands when/where needed but I wonder (and can test this, just haven't) if it's sending a Mode $28 command ("Disable Normal Message Transmission") that would (in theory) tend to prevent excess bus traffic and collisions.

There's also the issue that I seem to see these messages frequently (only?) when Mode $2A is in use by Tech2Win. Mode $2A, for those unaware, is how Tech2/Tech2Win gets the vehicle to continuously send replies to various "PID query" "collections". Since that's used frequently even on Tech2Win screens where some form of bi-directional control is used, I suspect that it's why @azswiss sees it on the engine-speed-control screen too.

Having said all that, I still think that attempting to characterize the reason for these Tech2Win "No Communications with Vehicle" screens is a worthy effort and I volunteer to do any testing that might assist.

Many months ago, shortly after trying my new VCX Nano and Tech2Win on an actual vehicle for the 1st time, I was floored by how it worked well initially but then seemed to be repeatedly giving me the "No Communications with Vehicle" screens. At one point, I even tried enabling the "Tool Options", "Set Communication By-Pass Mode" option but it didn't help at all. Here's what the GM Tech2 User's Manual says about that option:

F6: Set Communication By-Pass Mode

When you select F6: Set Communication By-Pass Mode, the upcoming screen (Figure VIIA-10) offers Disable and Enable options. By enabling the by-pass mode, the Tech 2 bypasses error handling and allows the user to view data display information without being connected to a vehicle. Highlight the desired setting using the up or down arrow keys, then press [ENTER] to change the current mode. The Tech 2 will default to the Disable mode after it has been powered off.

I thought that it might reduce or even eliminate those Tech2Win "No Communications with Vehicle" screens, but it seemed to have no effect at all. IIRC, that option is effective when you have no vehicle connected, but it's been a long time since I tried it and my memory may be faulty.

I agree with @TJBaker57's suggestion to try capturing traffic. It's certainly possible that it won't be conclusive and may not even help at all, but capturing data that way is a useful skill to master for anyone and having a log of the traffic can be incredibly useful, now or even much later, especially when presented to the right set of eyeballs.

I also agree with him about an oscilloscope probably not being too useful in this case. It's possible that the VPW signals are somehow malformed or out-of-spec when this problem occurs, but that's only a (slim?) possibility and debugging that would really be "opening a can of worms".

As for Mode $08, I've done tests with it in the past. IMHO, it's only mildly useful. For one thing, the only "TID" (Test ID) that it defined during the era of vehicles we're discussing is TID $01 ("Evaporative system leak test"). But don't be fooled by that name -- invoking Mode $08, TID $01 doesn't actually run the EVAP test -- it just "enables the conditions required to conduct an evaporative system leak test, but does not actually run the test". In my experience, it can close the vent valve, but it's way less useful than the aforementioned Mode $AE. In fact, I wrote a little Android app a few months ago to do Mode $AE commands to control the EVAP valves:



It shows the status (between the 2 purple lines) and allows you to directly control both EVAP valves.

I found that infinitely more useful than the pathetic Mode $08, FWIW. But we're getting OT for the thread title....

Anyway, hope some of that lengthy tome is useful or insightful. Don't hesitate to ask about anything unclear, anything that I may have forgotten to address, or if there's any test I could do here to assist.

I may try some more tests on my own initiative, but it probably won't be for a day or two at best.

 

[AmpOverload]

The only mode $08 test I see listed is for an Evap leak test. [...]

Curious. I may try this on my TrailBlazer to see if it activates the purge and/or vent solenoids.

I'm no master of Mode $08, but my experience was that it could close the vent valve and nothing obviously more. I could be wrong, though. My notes from back then show that I actually had issues gettting the vent valve to open again. An ignition key cycle, which of course re-booted the PCM, seemed to be one way to get the valve to open up again. Even a Mode $20 command ("Return to Normal Operation") had no effect on opening the vent valve, which surprised me.

My notes show that I also noticed that the Mode $08, TID $01 command consistently failed when the engine was running:

>08 01 00 00 00 00 00
NO DATA

and succeeded when the engine was off:

>08 01 00 00 00 00 00
48 6B 10 48 01 00 00 00 00 00 C3

This led me to wonder if it was designed purely to allow an engine-off "smoke test". But, truthfully, I've always wanted to do more testing, just no time for it all.

Will be interested to hear your experience if you decide to test it....

 

[azswiss]

I'm assuming that @azswiss is seeing this screen:

That's the screen. One minor data point regarding cabling; I have observed this problem when connecting to the VCX Nano with both the USB cable and with WiFi.

 

[AmpOverload]

One minor data point regarding cabling; I have observed this problem when connecting to the VCX Nano with both the USB cable and with WiFi.

Good to know. I forgot that the VCX Nano offered that dual WiFi+USB version! I guess I should've included "WiFi problems" in that "bullet" list in my 1st post. My VCX Nano is USB-only.

 

[mrrsm]

Re: @Mooseman 's invite in Post #9... Sorry for coming late to this Thread... Busy with domestic plumbing repairs all this week and last...and STILL at it...

The problem with any VCX-NANO Serial Drop Outs might be something as simple as having an Errant Battery not holding a charge... or the Serial Port Device being used is either unreliable... or functioning on the Wrong BAUD Rate Setting.

The use of WIFI versus a Direct Link to the DLC Port can raise its ugly head as well If the local environment is being Bathed in RF via a Bench Top FILLED With Chargers and Transformers ...or if there is an abundance of Fluorescent Lighting, then getting A/C Radiant Energy Interference in between the PCM and the Test Gear from the "Jacob's Ladder" -like Ballast behavior can have a Bad Outcome if reading or writing Calibrations through the TECH2 and the VX-NANO Gear.

Keeping the DLC Cable as Short as Possible and NOT using the 10' or 16' Lengths is also an important consideration. There could even be a situation of an unusual issue that Stresses the Internal PCM Circuitry in ways that might prove interesting and perhaps useful to this discussion ... as per THIS Link:

SOLVED! - Loss of Communication when trying to read DTC's

The Tech 2 just flashes "loss of communication" and beeps repeatedly when I try to get it to read codes. Also, it will request info from the ECU for the SPS just fine but after I load the updates from the PC and hook it up to the obd port, it cycles through everything and then says failure...

gmtnation.com

PS FREE PICO-Scope Software is capable of Data-Logging across their entire Hardware Line-Up ...too:

picoscope data traffic at DuckDuckGo

DuckDuckGo. Privacy, Simplified.

duckduckgo.com

PicoScope oscilloscope software and PicoLog data logging software

Download PicoScope, PicoVNA, PicoSource, and PicoLog software for free! Including support for macOS Catalina, Windows XP and Vista.

www.picotech.com

Think..."Electrical Power Interference Cut Outs...?" First... Via "Occam's Razor"

 

[azswiss]

In post #28 from SOLVED! Loss of Communication when trying to read DTC's the OP indicates that by removing the aftermarket radio harness adapter he was able to solve his loss of comms problems. I remember reading a post from @TJBaker57 regarding issues with programming if/when the radio or related devices are live. Makes me wonder if this could be a time-out issue for Tech2Win not seeing an expected network response within a specified time window due to traffic from other modules.

I will pull the radio & amp fuses to see if this buys any margin. Not sure what other modules (e.g. passenger door module which handles comm with the key fob) I can take offline but this is a start.

Note, the incremental improvement I observed by eliminating non-key processes & services on my laptop should have benefited timing margins at the PC side of things. BTW, the MAF was disconnected (had to remove the air cleaner & inlet) when I ran Top Engine Cleaner thru the throttle body; wondering if that triggered any error messages, etc. on the bus.

 

[azswiss]

I ran a series of trials and got the following observations:
- MAF: No difference when connected or disconnected
- Radio & Amp Fuses: No difference when connected or disconnected
- PC WiFi Connectivity: Better when the laptop's WiFi is OFF (but still not perfect)

CPU Loading: Fired up Task Manager & found a process called "emulator.exe" that looks to be tied to Tech2Win. When running as the top process (2%-3%) comms remain connected. Whenever comm was lost the RPM's drop back to idle *AND* emulator.exe drops way down in CPU loading (down to 0%) while several other PC-related processes become the top CPU users (1%-2% each). Once comms are re-established, without any intervention on my part, emulator.exe becomes the top CPU process once more. Note: I cannot say whether comms are lost due to loss of CPU priority for emulator.exe or if emulator.exe priority drops due to lost comms. A chicken or egg situation.

Next step will be to see if I can permanently assign emulator.exe as the top priority process (via registry edits).

 

[mrrsm]

With an observant assistant on hand... It would be interesting to see the behavior of the Battery Voltage using a Sensitive AMP Current Clamp to capture any B+ fluctuations when the Drop-Out Phenomena occurs.

This one was recently On Sale at a substantial price reduction and would be sensitive enough to pick up the changes... NOT as Good as an Oscilloscope for being able to see the slightest alteration mind you... but still useful in catching any such coincidence. The same procedure would work on the "Red Charging Wire" coming from the Alternator's Rectifier Output to determine whether or not it too might be "The Culprit"

 

[AmpOverload]

Makes me wonder if this could be a time-out issue for Tech2Win not seeing an expected network response within a specified time window due to traffic from other modules.

It certainly could be that. But, from where I sit, even if other modules' VPW bus traffic was conclusively found to be a reason for the "No Communications with Vehicle" screens, it probably cannot be the only reason, based on my sim testing, where I have the luxury of strictly controlling the traffic and still see those screens even with no extraneous bus traffic.

I wish I had more time because I'd like to play around with intentionally delaying the vehicle's PCM replies used to satisfy the Mode $2A command and see just how much of a delay Tech2Win (or a Tech2 for that matter!) could tolerate before showing that screen.

Whenever comm was lost the RPM's drop back to idle

Glad you mentioned that. (I meant to ask and forgot.) But the next question is: When you get comm loss and RPM drops to idle, then (IIUC) Tech2Win recovers on its own without your intervention, does the RPM go back to the commanded value (900)?

 

[azswiss]

When you get comm loss and RPM drops to idle, then (IIUC) Tech2Win recovers on its own without your intervention, does the RPM go back to the commanded value (900)?

Yes.

 

[azswiss]

Ran another couple of trials focusing on CPU priorities; alas, no joy. Went into Task Manager & set the priority for emulator.exe to High; no difference. Set several unrelated processes to Low; no difference.

Unfortunately, I do not have any additional data that would provide any insight as to whether comms are lost due to loss of CPU priority for emulator.exe or if emulator.exe priority drops due to lost comms.

That said, based on @AmpOverload's comments in Post #20 that comms loss was observed "even with no extraneous bus traffic" it would appear that a substantial portion of the problem lies on the PC side of things. Specifically, how emulator.exe, and all of its various components & affiliates, is running.

At a standstill at this point as the next likely area of investigation on this path would be to try this on a more powerful PC (# CPU cores, clock speed, RAM, etc.) than I currently possess.

Still planning to look into @TJBaker57's suggestion about monitoring the traffic with an OBD2 splitter (once I get one!).

 

[AmpOverload]

At a standstill at this point as the next likely area of investigation on this path would be to try this on a more powerful PC (# CPU cores, clock speed, RAM, etc.) than I currently possess.

Sorry for not mentioning this earlier, but there is a "Speed Indicator" in the lower left corner of the Tech2Win window:



For me, when Tech2Win is first starting, it changes frequently, going through all 3 colors (green, yellow, and red triangles) and with numbers as low as "2" and as high as "25", quickly settling down to show a green triangle and "5". I also see "5" when Tech2Win is not doing any vehicle comm at all and when it's showing a page like "Engine Data 1" (with 43 PIDs total). So I don't know if it's really that useful. I've never really paid much attention to it, but it may give an additional clue if you see that number or color change when the comm dropouts occur (e.g. during RPM control).

There's also that "Vehicle Communication Status" indicator, which seems rather crude and maybe not very helpful, but maybe it would give some insight during a comm dropout???

For the record, the laptop on which I run Tech2Win has an Intel Core 2 Duo T5500 (2 64-bit CPUs each running at 1.66 GHz). I run it under a clean (no other stuff installed), 32-bit version of Windows 7 Pro, with 1.5 GB of RAM. Just curious, what does the Windows 7 "Control Panel", "System" page show for your CPU speed and RAM? How many CPU cores?

I don't think the "comm loss" messages I see are due to this PC, but I could be wrong. One of the things on my "to do" list is to try to get Tech2Win running under a Virtual Machine (VM) hosted on a PC that's running Linux as the host OS, which will provide the additional benefit of running on a "beefier" PC, with a reliable scheduler.

 

[azswiss]

I see the same Speed Indicator behavior as you do; peaking during startup and then holding steady at 5. No deviation from 5 on the Speed Indicator with or without comms; no variation as emulator.exe CPU load varies from 5% down thru 0%. The Vehicle Communication status arrows do show some change, slowing down/stopping when comm is lost.

My laptop is a Dell Latitude E6410 running a Core I5 M540 CPU (2 physical cores, 4 logical cores) running at 2.53GHz with 4GB RAM. OS is Windows 7 Pro 32.

While I still believe the problem is on the PC side (a driver marginality maybe?) the point is pretty much moot at this point. That said, next step is to get the splitter and see what, if anything, shows in the serial bus traffic.

 

[AmpOverload]

FWIW, I've noticed that when I start seeing these "No Communications with Vehicle" screens, it seems that Tech2Win will "recover" from the situation as long as it doesn't go on for too long. Typically, I'll control this by "backing out" (e.g. with the 'Backspace' key) of whatever Tech2Win screen I'm on that's causing the issue.

But I've seen many times where I let the "No Communications with Vehicle" screen persist and Tech2Win will not recover (i.e. begin showing the expected data). When this happens (like it did just recently), it's not enough to shut Tech2Win down and restart it -- it will just continue to report "No Communications with Vehicle", even on the simplest of screens (a VIN query). I seemingly always wind up having to remove power from the VCX Nano, both at the OBD2 DLC connector side and the USB side (by pulling the USB cable from either end to fully de-power the Nano). Fortunately, this doesn't happen too often, and even less so if I'm on top of the situation and "back out" as described.

The whole thing (VCX Nano + Tech2Win) just always strikes me as incredibly "fragile", and that's not even considering the whole "license timeout/update" issue!

BTW, I know you said it's "pretty much moot" but, in case it's useful and/or for anyone in the future reading this thread, here are some more points:

1. This laptop has no Internet access whatsoever, so there's no possible "interference" from that perspective. Of course, this means (for better or for worse) that no updates have been applied to Win7Pro32.
2. I have anti-virus, automatic updates (etc) turned off. Since it has no Internet access, this is ideal.
3. This laptop has a physical switch to disable WiFi and (especially when using Tech2Win) that switch is off, so there should be little chance that a WiFi driver is causing any issues.

In trying to replicate your situation, I've selected the 2003 model year, but which of the three 5.3L V8 engine types (L59, LM4, or LM7) in Tech2Win do you select? And which options do you select after that (they vary by engine selection, etc)? I'd like to get to the same "Engine Speed Control" page that you're using, with all the same selections you used, if possible.

 

[azswiss]

In trying to replicate your situation, I've selected the 2003 model year, but which of the three 5.3L V8 engine types (L59, LM4, or LM7) in Tech2Win do you select? And which options do you select after that (they vary by engine selection, etc)? I'd like to get to the same "Engine Speed Control" page that you're using, with all the same selections you used, if possible.

Tech2 S/W Rev 33.004 w/ following options selected:
North American (*not* Chevrolet)
GM - MDI, D-PDU API by Bosch
22124708 - USB
F0: Diagnostics
2003
LD Trk, MPV, Incomplete
F0: Powertrain
(Z) 5.3L V8 L59
4 Speed Automatic
2 Speed Active
F2: Special Functions
F3: TAC System
F0: Engine Speed Control

 

[azswiss]

Found a coupe of interesting threads when searching for Tech 2 loss of communication (vs. Tech2Win). A lot of stuff on the Saab forums, primarily dealing with managing/reworking Chinese knockoffs in both H/W & S/W. Did find this thread on the C5 Corvette forum dealing with cabling/connector issues (see post #5):
Tech 2 - No Communications with Vehicle error

Visual inspection of the connector on the VCX (pins 2, 4, 5, & 16) reveals clear evidence of contact with the OBD socket, no obvious junk or discolorations that would indicate connection issues. Ditto on the truck's connector. In the interest of trying to eliminate this variable I will give them a good clean and will retry.

 

[mrrsm]

Perhaps some more 'On Topic' Videos can be seen here, too...

Additional Tech 2 & VXDIAG Nano Resources

EDIT: On November 11th, 2019, :I created a TOC (Table of Contents) of the Video Files shown consecutively in the following Threads that should help to speed the identification of Specific On Topic Videos vs. having to Read and Watch each one in sequence to locate what the Viewers need. The...

gmtnation.com

 

[AmpOverload]

(Z) 5.3L V8 L59
4 Speed Automatic
2 Speed Active

Thanks for the detailed Tech2Win settings -- very helpful! (The part I quoted was what I was most unsure about.)

I ran Tech2Win with those settings, simulating that vehicle with my HVS (sim). I configured one of the potentiometers on my sim to control the reported engine speed (RPM).

I was able to see the "Engine Speed Control" page once my simulated RPM was raised from 0 to about 500:



I grabbed the VPW traffic coming from Tech2Win and emanating from my sim. If needed, that should serve as a nice baseline once you grab the traffic on your truck with the splitter cable.

I have the gory details should anyone want to see them, but I'll just summarize what I see for now....

Basically, it's the usual Tech2/Tech2Win scheme of doing setups using Mode $2C commands for several DPIDs, which results in 47 "Engine Data 1" PIDs being shown on the "Engine Speed Control" screen.

Tech2Win is also continuously using Mode $22 requests to query the engine speed (PID $000C) and vehicle speed (PID $000D). This is very odd (in more ways than one), but I'll leave that discussion for a later post so as not to distract from the main point of this post.

So there's actually more VPW bus traffic than I typically would see from a Tech2Win page, FWIW.

I tested for quite a while without ever seeing the dreaded "No Communications with Vehicle" screen. I even stressed the "vehicle"-to-Nano comm link by occasionally enabling continuous console output in my sim, which can often be a reason for starting to see that screen. But not once did the "vehicle" comm drop out!

I later exited and re-entered the "Engine Speed Control" page and it ran fine once again. But when I tried it again, I suddenly saw the "No Communications with Vehicle" screen and nothing short of removing both sources of the VCX Nano's power (OBD2 DLC connector and USB cable) would make it work again. Killing and re-starting Tech2Win didn't help. Rebooting my sim didn't help. It's like the VCX Nano gets itself into a state where it must be rebooted.

So it's odd to me that, compared to my testing, your testing:

• has so many "comm loss" events
• recovers from the event(s) and continues to control the vehicle's engine speed

I'll have to ponder this a bit more. Unfortunately, I don't think my testing has made anything distinctly clearer, not that I really expected it to.

Nevertheless, it will be interesting to see what sort of data you capture on the real vehicle.

 

[azswiss]

Monitored the network traffic while Tech2Win/VCX Nano engaged in multiple attempts to control engine speed (the new OBD splitter from Amazon worked perfectly!). I have started in on parsing the data but rather than bias the analysis I am attaching the raw data text file so any interested party (@TJBaker57, @AmpOverload) can pass it thru their own parsing process.
Notes:
- Multiple loss of communications events occurred during the logging session (~2 minutes), but cannot pinpoint them at specific time stamp locations
- Multiple data lines appear to have had 0's inserted in both the timestamp & data fields. Assuming this is a serial terminal logging problem (e.g. time stamp 012:51:007.97). Please validate (or refute).
- Time stamp 12:51:19.404 shows a very interesting response back to the Test Device:
12:51:19.404 08 10 F1 20 64 <DATA ERROR
(Edit: time stamp 12:51:58.339 shows a similar response)
My parsed Excel file is available upon request.

 

[AmpOverload]

Monitored the network traffic while Tech2Win/VCX Nano engaged in multiple attempts to control engine speed [...]

I've taken a preliminary pass through the raw data. One technique I like to use to cut down on the analysis time involves stripping off the timestamp, sorting the remaining lines, then running them through a "unique" filter, so that only 1 version of multiple cases of the same line remains.

When I do this on your data, I don't see anything too odd. There are the 2 cases of "<DATA ERROR", of course, but that's not unheard of. I would expect Tech2Win to be tolerant of that, but who knows if it really is?

There are also, as you've identified, cases that appear to be an issue with the ATMA data logging (broken timestamps, etc). If we're right that that is purely a logging issue, then it would not explain Tech2Win's "No Communications with Vehicle" screen appearing.

There are some functionally addressed messages in that set, but since Tech2Win doesn't appear to ever issue a Mode $28 ("Disable Normal Message Transmission") command, I would expect Tech2Win to be tolerant of such bus traffic.

To be clear, at what point did you start the recording? Were you already on the "Engine Speed Control" page itself or were you on one of the earlier pages (e.g. the one where it tells you to start and idle the engine)?

BTW, before I forget, out of curiosity, what scantool (and interface -- WiFi, Bluetooth, or USB) did you use to collect the ATMA log? And what serial terminal app? It may not matter, but it could.

I'm going to pore over the data some more and run some more tests on my end, but that might take a day or two.

Frankly, I think it will be hard to pin this down, given all the "variables", most of which we have no control over.

I may try to duplicate your issue on a real-world GM vehicle, then write a little Android app (similar to the "EVAP" app I mentioned earlier) that would control the RPM, but using software under my control and a scantool of my choice, instead of using the elusive, mysterious, temperamental Tech2Win + VCX Nano. Then I might get a better idea where the problem really is.

P.S. It probably wouldn't have made any difference in this recording you made, but when I'm collecting data with "ATMA", I like to send the "ATAL" command beforehand, to "Allow Long messages".

P.P.S. Do you ever see the "No Communications with Vehicle" screen at other times (i.e. other than on the "Engine Speed Control" screen) when using Tech2Win with your truck?

 

[AmpOverload]

Tech2Win is also continuously using Mode $22 requests to query the engine speed (PID $000C) and vehicle speed (PID $000D). This is very odd (in more ways than one), but I'll leave that discussion for a later post so as not to distract from the main point of this post.

I just remembered that I never really addressed this, but now that I've seen your data, it's time....

I see the same thing in your data that I saw in mine. The "engine speed (RPM)" PID ($000C) is set up with a Mode $2C message and continuously transmitted with Mode $2A, so why does Tech2Win waste time also requesting the same PID ($000C) with repeated Mode $22 commands?!? It makes no sense to me.

Tech2Win does the same thing for the "Vehicle Speed Sensor" PID (0x000D). Again, it makes no sense -- all it does in increase the VPW bus traffic, for no apparent gain!

 

[TJBaker57]

Visual inspection of the connector on the VCX (pins 2, 4, 5, & 16) reveals clear evidence of contact with the OBD socket, no obvious junk or discolorations that would indicate connection issues

Does the VCX use a similar arrangement as the Tech 2 where there is an adapter to go from the round connector to the OBD2 connector? I found that junction on my clone to be very poor. I ended up disassembling the connector and removing the spring from the thing. This helped a good deal.

 

[AmpOverload]

Does the VCX use a similar arrangement as the Tech 2 where there is an adapter to go from the round connector to the OBD2 connector?

No, it's got the standard 16-pin OBD2 DLC on one end and a USB plug jack on the other.

 

[azswiss]

To be clear, at what point did you start the recording? Were you already on the "Engine Speed Control" page itself or were you on one of the earlier pages (e.g. the one where it tells you to start and idle the engine)?

Got to the page where you can showing F0: Engine Speed Control but did not select it. Started logging and then selected F0: Engine Speed Control

P.P.S. Do you ever see the "No Communications with Vehicle" screen at other times (i.e. other than on the "Engine Speed Control" screen) when using Tech2Win with your truck?

Yes, but only once or twice. I believe it was in Powertrain Diagnostics when I was checking for DTC's. I was connecting via WiFi so I assumed that the connectivity was suspect and have used the USB cable since then.

No, it's got the standard 16-pin OBD2 DLC on one end and a USB plug jack on the other.

There are two versions: USB only & USB+WiFi

 

[AmpOverload]

There are two versions: USB only & USB+WiFi

True but, other than the color of the plastic case (mine [USB-only] being light gray and yours [USB+WiFi] light blue), the 2 versions appear to be identical on the exterior.

BTW, before I forget, out of curiosity, what scantool (and interface -- WiFi, Bluetooth, or USB) did you use to collect the ATMA log? And what serial terminal app? It may not matter, but it could.

Any input on this? Also, can you turn off the timestamps when logging? In the right circumstances, they could certainly be useful, but in this case, they seem to be more of a distraction.

Another thought on this comm dropout and your collected data... I can easily inject a "<DATA ERROR" by simulating a vehicle reply with a bad checksum -- I've done it before when testing how various scantools handle it. Doing that at various frequencies would show me how tolerant Tech2Win (or it could be the VCX Nano, actually) is when faced with such vehicle replies.

One problem I have is that there's no way to separate potential VCX Nano issues from potential Tech2Win issues. I wish I had another SAE J2534 VCI ("Vehicle Communication Interface") that could be used with Tech2Win, to help differentiate a bit.

Frankly, I don't completely trust either the VCX Nano or Tech2Win! They both seem rather "temperamental". Or maybe that's just me -- "90% temper, 10% mental", as the old joke goes!

 

[azswiss]

I am using this serial terminal app: Serial WiFi Terminal

The app is installed on a Verizon Ellipsis 10 running Android 5.1.

The physical interface is a garden variety ELM327 with WiFi. Picture below:

 

[TJBaker57]

I see a potential thing here in your log file. At least it 'looks' like a possible issue.

Seems like there is a instance where the mode $2A stream times out? No mode $3F message is seen from the VCX nor is there the usual mode $20 message from the VCX.






I reviewed maybe a dozen Tech 2 data logs from my library and did not see an instance like this where the Tech 2 allowed the $2A data stream to time out. There was always a mode $20 message sent terminateing the $2A data stream when the page/screen was exited.

 

[AmpOverload]

I see a potential thing here in your log file.

I noticed this too, but I didn't see your post until after I composed mine. Forgive the impression that I'm being a "copy cat".

I've been perusing the ATMA recording some more and a few new thoughts come to mind.

First, I see that the recording begins with Mode $2A traffic without any Mode $2C (setup) commands having been seen. That seems suspicious, given that you started recording on the page showing "F0: Engine Speed Control". It makes me think that something happened to the log where the initial traffic either didn't get recorded or got cut off somehow.

Unfortunately, WiFi recordings, while still useful, don't inspire high confidence levels. For example, here's a spot where the recording dropped out for about 2.7 seconds:

12:52:25.971 6C 12:52:28.619 F1 10 6A F1 FC 14 00 00 00 00 A8

Second, I see the requisite periodic Mode $3F ("Test Device Present") commands, but they're not always as timely as I'd expect. In fact, assuming the timestamps are trustworthy, some of the Mode $3F commands exceed the spec:

12:51:45.409 6C FE F1 3F 8B
12:51:49.106 6C FE F1 3F 8B
12:51:53.604 6C FE F1 3F 8B
12:52:01.995 6C FE F1 3F 8B <--- this one is late!
12:52:06.396 6C FE F1 3F 8B
12:52:10.627 6C FE F1 3F 8B
12:52:15.298 6C FE F1 3F 8B
12:52:28.927 6C FE F1 3F 8B <--- this one is really late!

That 1st marked one is so late that the periodic Mode $2A traffic ceases for a long time! That is almost certainly a cause for seeing the "No Communications with Vehicle" screen.

Periodic Mode $2A traffic does not resume until Tech2Win "restarts" it, about 20 seconds later:

12:52:20.931 6C 10 F1 2A 14 F6 F7 F9 FA DA
12:52:20.931 6C 10 F1 2A 24 FB FC FD FE 63
12:52:20.931 6C F1 10 7F 2A 24 FB FC FD FE 23 AF
12:52:20.931 6C F1 10 6A F6 00 00 22 88 03 3B 4E
12:52:20.931 6C F1 10 6A F7 00 00 01 89 01 81 4A
12:52:20.931 6C F1 10 6A F9 04 60 3F 40 02 80 60

And then almost immediately shuts it off again: EDIT: Ignore that. That's a late reply to an earlier command.

12:52:20.931 6C F1 10 6A A0

Only to re-start it about 4.3 seconds later:

12:52:25.246 6C 10 F1 2A 14 F6 F7 F9 FA DA
12:52:25.249 6C 10 F1 2A 24 FB FC FD FE 63
12:52:25.252 6C F1 10 7F 2A 14 F6 F7 F9 FA 23 36
12:52:25.259 6C F1 10 7F 2A 24 FB FC FD FE 23 AF
12:52:25.259 6C F1 10 6A F6 00 00 09 88 03 2C BC
12:52:25.259 6C F1 10 6A F7 00 00 00 F1 00 E5 3F
12:52:25.259 6C F1 10 6A F9 04 60 3F 40 02 80 60

But the problem is that it's hard to know if the slow Mode $3F commands are the problem or just a symptom of a different problem. "Chicken and egg", if you will.

Also, I see a lot of level 0 (highest priority) functionally addressed traffic too, typically using Primary ID $FF ("Network Control"). In fact, there are 412 of those bus messages in a 1m21s recording. Maybe that's normal (I have no reason to suspect otherwise), but I wonder if that could be disrupting the traffic flow enough to cause issues. I would expect Tech2Win to be able to deal with that, but who knows?

I continue to think that getting to the bottom of this might be very difficult, but I still have some ideas. I just don't know when I'll have time to test them.

 

[azswiss]

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.