Data Logging Polling Rates

[mejohn50]

I came across this post in the how to section from 2021 and it has some details on polling rates. Does that information still apply, and if so does it apply to the US market cars as well? 

  

On 2/8/2021 at 5:10 PM, Roland@pcmtec said:

I'll put the reply here as well regarding poll rates.

The way the datalogger works is you get 15 rapid packet polls, these update at roughly 50ms. Then every thing else after this is polled as fast as it can, eg if you have 16 items you are logging, the 16th item will still log very fast. If you have 60 items, the 45 items after the first 15 will log quite slowly, roughly once a second.

We get a few 'freebies' that are broadcast data and always log fast irrespective of whether they are set to high priority. These are engine rpm, oil temp and a few others. This is something only we do, other companies don't take advantage of these.

If you are very curious about how it works you can right click on the name column, select column chooser, scroll down to 'rate' and add this column. This will show a number which is number of updates per second. For a fast dyno pull you need at least 250ms updates for rpm, boost, load, knock for it to be useful, otherwise the values will not line up and you will miss spikes of knock etc.

In future versions we will be setting high priority by default on knock, rpm, cam angle etc. Currently it has to be done manually if you have selected over 15 items.

 

[grim5.0]

Id assume the core functionality is unchanged. post a log and let's see. id contribute but my strategy is not able to be data logged/edited yet

[Roland@pcmtec]

On 8/9/2023 at 11:49 AM, grim5.0 said:

Id assume the core functionality is unchanged. post a log and let's see. id contribute but my strategy is not able to be data logged/edited yet

Yes it does work very similarly. However the Mustang has DIDs (typically a much smaller data structure) and you can pack more into a single request. If they were all bytes (this would be unlikely but it is the best case scenario) you get 7x16 = 112 rapid packet high speed items you can log, this is as you get 7 bytes per slot and 16 slots, most DIDs are 1 or 2 bytes, some are 4, almost all DMRs are 4 bytes (higher resolution). We are adding the generic DIDs to the Datalogging soon. These are a small generic subset and there will be approximately 300 of them. You can mix these DIDs with normal DMRs. So things like RPM/ECT/EOT etc you can use the DID version to speed up datalogging of other items. Our default layout will be updated to optimise this.

We also looked at dynamic datalogging rates for the single rate polling. Eg if something doesn't change very fast (ECT etc) then you don't need to poll it very often. As such we could make buckets of slow/medium/fast where if you had 9 DMRs, 3 fast, 3 medium and 3 slow they would be polled in the following order (an approximation of how it would work).

 

slow1

medium1

medium2

fast1

fast2

fast3

slow2

medium2

medium3

fast3

fast1

fast2

slow3

We would then dynamically adjust certain values like EOT/ECT to be slow as they do not change often (based on some magic algorithm), or set good defaults so that you get an optimal logging experience.

In the mean time we recommend you create several logging layouts, one for each task and only log the minimum number of items required to ensure fast logging rates. We have multiple default layout files, most of these can be trimmed substantially to increase poll rates depending on what you are doing

If you create good layout files and want to share them I'm sure this would be greatly appreciated by others. We could even include them in the editor by default.

[mejohn50]

Thanks for that very informative response. 

I have been working with the logger and like you suggested I have found it best to work with the least amount of channels possible to get the information needed.