Hello,
I am trying to tune a 2013 caprice PPV L77 with E38 controller, no matter what I do the data transfer rate is extremely slow. In the attached image and log, engine speed is not polled and is at 5 hz and works great. The other three channels (Mass airflow, MAP, O2 voltage) are polled and I have them also set to 5hz but they update maybe once a second.
Any advice?Attachment 156381Attachment 156382
Speed them up and see if it meets your satisfaction. How clean is the hard drive of the laptop you are using? Does it run other programs well?
He has already removed the polling interval
They are polling at whatever rate they poll at
How does one remove a polling interval?Quote:
Originally Posted by LilSick
He mentioned he has them polling at the preset interval of .2 seconds.
You can easily remove the intervals in notepad
Would you be willing to do a little show and tell? As I know at this point I can't easily remove the polling intervals with notepad and I don't see an option to remove the polling intervals, only change the time between polls. If the software is not capturing the data but every 1 second (for example) how is notepad going to change that?
Like so
double click will remove the interval
How does that translate back to viewing the data that was not polled (I call it lost data) during a log?
lost data, or trying to log a parameter that isnt avail on yer os?
Removing the suggested polling intervals from the channels config will make it even worse.
From the older help files:
Scanner Performance and Polling Interval
In most cases, the more parameters you add to the Channels display, the slower they will be returned to you from the vehicle.
Broadcast parameters do not suffer from this drawback. These are parameters that the vehicle is always sending and require no overhead in collecting. Given the choice between a Polling and a Broadcast parameter, you should chose the Broadcast one.
External sourced parameters (MPVI, Serial Port, etc...) do not affect the rate at which parameters are gathered from the vehicle.
To improve performance, lower the interval on polling parameters that do not require great resolution. For example, setting Engine Coolant Temperature to 10 seconds might be more appropriate than .1 seconds. By doing so, you free up bandwidth space for a parameter that might require tighter resolution, like Spark Advance.
Naw...Quote:
Originally Posted by Keith@HPTuners
Keith is just used to those slow Chevy PCM's ; )
My mopar GPEC2A loves em sped up on scanner
I don't have an answer for you, but one "trick" I've found to help figure out exactly what is going on is exporting to csv and uncheck the interpolation box.
Now you can see exactly what channel is updated when, how often, etc.
Engine speed (broadcast) is being logged very fast close to 100hz
The other 3 params will log quickly for about 0.2 seconds, then stop, then repeat every 1 second or so. Normally when setting something to a very slow logging speed, it will just get one request/response at the selected interval... 1 second, or whatever. I speculate if you logged the bus traffic you'd see this same behavior. Is it sending a request and just getting no response, or just only requesting data quickly multiple times over this ~0.2 second windows?
I can't really explain the behavior, but something does seem amiss for sure.
I believe the OP is asking about an issue with a GM PCM issue, not Mopar?
So the little notepad trick is to remove the PID from being polled?
I was using the language provided by HPT, I assume that the misunderstanding is on my end as I took the OP question to mean he wanted to see all the data available on the PID's selected. If the polling interval's were set to 10 sec. for example, the log would not show the data but once every 10 sec.? This is what I mean by missing data or lost data.
Now HPT steps in and says it's bad to remove the polling intervals from the list, are you saying they don't know how their system works or are you being sarcastic?
I also have a new question: How do I tell the difference between a polling parameter and a broadcast one? I admit I haven't looked, but is it evident somewhere in the
vcm scanner and if so where?
Circling back around to the OP's question, he has his polling intervals set at .2, with 4 PID's selected, why do you guys think his data is updating at his suggested, at best every one second?
I have noticed similar issues when viewing a log vs viewing the gauges in the VCM scanner. For example: my IAT is set to update (poll) every .2 sec. During a boosted WOT pull, the IAT would show little to no change for 5 seconds or more until I let off the throttle, then the log would update. If I watch the VCM scanner gauge it will update every second or less and in the middle of the pull the gauge and log stream do not match. In my case there may be 30 degrees different in the two readings.
I think more often than not I see people who just have way more things logging than they should, resulting in super slow update rates. Of course, depends greatly on ECU and generation etc etc.
Some ECUs are limited to basic service 22 logging, which is single PID request/response and generally limited to around 100 PID/s update rate. Others support service 2C or similar which allow multiple parameters to be requested/received in one message, so its a lot more efficient, but still there are going to be limitations.
Broadcast is powertrain CAN messages that are just broadcast across the CAN... say engine RPM that, that could be picked up by the ECU/PCM, and the TCM, and the brake module, all at once. Polling is what I described above, the control module sends a request and gets a response and there is some throughout limit. In the screen where you select things to log, it says if its broadcast or polling, and if it's a PID or direct memory logging.
I'm most familiar with old Gen3 as an example, but it has a max rate of around 24 bytes at 10hz. If you select any more than that it starts going down quick. So you really need to think hard about what you want to log in that particular session and always a good idea to use VCM scanner polling rates so the software can determine what to log at max rate and what doesn't need to be (coolant temp maybe).
Are you using the standalone logging?
I had graphs that looked like, until I plugged in a computer.
Now that is a cool trick and thank you for sharing. Being able to diagnose the issue is out of my scope of "I want to figure this out" for the time being, but there are some days I wonder if I should dedicate a year or two and attempt to gain more understanding to things like this or code/how to code or even winols. Then I think, I just wanna go play with my hot rod!Quote:
Originally Posted by aaronc7
If you were going to attempt to solve the problem, would you turn it over to the software engineers at HPT and ask for their help or what would be the plan of attack?
Most PCM's support multiple methods of scanning at the same time. Internally, we talk about these as buckets. Each bucket has its own reporting rate as well.Quote:
Originally Posted by LilSick
What the configured polling intervals do is help the scanner engine make sure that the parameters that you want the quickest go into the fastest flowing buckets. If you've marked some parameters as very slow, but their is still room in the fast buckets, those parameters end up going in the fast buckets anyway.
When you mark every parameter the same interval you basically take away the scanner engines ability to prioritize parameters for you. When every parameter has the same priority, no parameter has priority.
checks out
when the channel list and the chart are not exactly the same which is correct?
thx Keith
Plan of attack is always the same-- gather as much info as possible and try to fix it myself, but if I cannot, then create a ticket or whatever. In this case I think it probably needs to get looked at by HPT, as it's something beyond what I can fix or control.Quote:
Originally Posted by abc
The comment above about standalone logging is a great one though I think. In my mind that could maybe explain what's going on.... the broadcast parameter could be overwhelming what the processor in the MPVI can handle so as a result the polled parameters suffer. I'm assuming that when using VCM scanner, the dongle is pretty much just a passthru and the PC is doing all the processing-- so that would be a good test. And/or reduce the polling rate of the broadcast parameters, if that's possible.