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.
My observation....Quote:
Originally Posted by LilSick
The channel list shows actual data value updates and displays the last received value. The chart is always interpolating between points. This becomes very apparent when someone is logging way more stuff than they should be. An item in the channel list will might only updated once every second or 2 seconds or whatever, but the chart will show the data always moving-- it's just interpolating between the last and next data point.
I wish VCM scanner gave you a bit more insight into what "buckets" were being used and the expected polling rate or priority. But I also understand this gets really complicated because every ECU is a bit different and this probably gets very complicated from a GUI standpoint.
I'm most familiar with my Gen3 LS and thankfully its pretty simple but I've played with this extensively.
I know Gen3 LS has buckets that are 6 bytes and in a cycle you can poll 4 buckets at a time. Each cycle is around 10hz, so 24 bytes at 10hz.
What I did was set the request logging rate/priority to 10hz for 18 bytes and I set 12 additional bytes to 5hz.
Basically every cycle, the 3 buckets/18 bytes are polled every time and the 4th and 5th bucket alternate cycles, resulting in around 5hz for those.
It was tedious to set up and make it work, but it was important to me to get max possible speed on data that really matters when doing things like VE tuning, etc. That export to csv trick does help shed light on what's really going on too and getting the data rates you want.
Sorry long reply. Just sipping my morning coffee lol.
I just poked around a little in the VCM scanner, specifically in the channels list and the chart layout, I don't see where the difference is noted between broadcast and polling parameters. Can you point it out to me? Is it just the symbols on the left side of the channels list?Quote:
Originally Posted by aaronc7
The channels list is designed to be the source of truth. The values you see there are the nearest data point received.Quote:
Originally Posted by LilSick
The graphical displays often interpolate between data points to provide a more user friendly picture of what the channel or plot is doing.
Yeah exactly, there's also a filter button at the top to see broadcast only.
Not all cars will have any available. For example I also have a 2017 Audi S3 but the powertrain CAN is behind a gateway and isn't available at the OBD port. Only polling options.
Your assumptions are correct.Quote:
Originally Posted by aaronc7
VCM Scanner is significantly more powerful than the MPVIx interfaces, both in processing power but also the scanning engine. The newer MPVIx interfaces can support the more complex scanning engines but are still limited by the micro controller inside them.
how does one do this?Quote:
Originally Posted by aaronc7
do you export the .hpl file to .csv?
or the channel list itself?
Open hpl. Under the door drop down, export I think. You can export as a csv and have the option to enable or disable interpolation. Uncheck it
thx, yeah that is exactly how to export
now how to figure out the bucket part of it lol