[REL] DAMPlugin for rF2

:mad:

@DreamsKnight Grab the manual install archive, it's down the bottom of the first post. Looks like Mediafire is only blocking the installer, not all my files, so that one still works.
 
Lazza said:
:mad:

@DreamsKnight Grab the manual install archive, it's down the bottom of the first post. Looks like Mediafire is only blocking the installer, not all my files, so that one still works.
Click to expand...

i forgot links at the bottom. and i used them no more than 2 weeks ago

facepalm.jpg


sorry, thank you.
 
Lots of webinars at the Motec site.
Also, a lot of tutorials out there. Mostly, just a lot of reading, absorbing data, most importantly...understanding what is being read.

Application of the data is dependent on the end user.
There's no one size fits all answer, imo.
 
11/03/18 23:29:06 Error creating file:
11/03/18 23:29:06 .\\LOG\2018-11-03 - 23-29-06 - Botniaring Long w/chicane - P1.ldtemp

Cannot enable recording on Botniaring, tried reinstall of plugin.
Problem only occours on the chicane variant of track. Character problem due to the "/" in the track name?
 
Update 0.79 (attached to first post, manual install archives also linked to):
  • Fixed track name correction so slashes etc don't break it (@Launger ). I actually did this for both car and track names ages ago but forgot to use the corrected track name...
  • Added an option to log to a track name subfolder (@d0nd33 ). This can be combined with the vehicle class subfolder option, or either one, or none. Off by default.
  • Added an option to only record log files when the car has moved, or left the pits, or a lap was started or completed. Default is car needs to move to create a log.
  • Cleaned up the fresh .ini file, config output, and fixed some of the changed channel groups not being referenced properly, so all the current .ini options are present.
To see any new .ini options you need to delete/rename the existing DAMPlugin.ini so the plugin creates a new one. No automation on that, sorry.

Note: The 'Capture partial log' option isn't fully tested, especially for driverswap situations. I suspect it will work as advertised but you may want to stick to the default value (1, car moved) to make sure. Confirmation of other settings would be great though.

Let me know of any issues.
 
patchedupdemon said:
@Lazza
thanks for taking the time to look at this for me
Click to expand...

Better late than never :D

The temps look fine to me, can see the FL temps spiking on right-hand corners, and FR spiking on left handers. It's definitely clearer when you set up Maths channels to average the Outer, Centre, and Inner temperatures for each tyre (would show basically what you see in the game HUD), but the individual temperatures also follow the same pattern. Your rear temps aren't moving around much, I'd say you have understeer :P

Be aware if you have the individual OCI temperatures showing, on the same graph there will be lines everywhere and it's easy to get confused, while if they're on different graphs they can get scaled differently and look different to what they really are (in comparison). It's also easy for the 'map' in motec to end up being a bit wrong; if you look at a log early on it draws the track based on your best lap in the log and sticks with that version, later you might have improved your lines in various corners and they won't line up correctly when you look at where your dot is on the map. If you go back to Tools -> Track Editor -> Generate Track when that happens, it will fix it up based on the fastest lap you currently have loaded.

Option D is you did break your i2 project and it's showing stuff wrong, but it seems unlikely for 1 car.
 
Lazza said:
Better late than never :D

The temps look fine to me, can see the FL temps spiking on right-hand corners, and FR spiking on left handers. It's definitely clearer when you set up Maths channels to average the Outer, Centre, and Inner temperatures for each tyre (would show basically what you see in the game HUD), but the individual temperatures also follow the same pattern. Your rear temps aren't moving around much, I'd say you have understeer :p

Be aware if you have the individual OCI temperatures showing, on the same graph there will be lines everywhere and it's easy to get confused, while if they're on different graphs they can get scaled differently and look different to what they really are (in comparison). It's also easy for the 'map' in motec to end up being a bit wrong; if you look at a log early on it draws the track based on your best lap in the log and sticks with that version, later you might have improved your lines in various corners and they won't line up correctly when you look at where your dot is on the map. If you go back to Tools -> Track Editor -> Generate Track when that happens, it will fix it up based on the fastest lap you currently have loaded.

Option D is you did break your i2 project and it's showing stuff wrong, but it seems unlikely for 1 car.
Click to expand...

Thanks for looking into it for me, I guess I’m just reading it wrong lol, and yeah I had an understeer setup for that track, my skills don’t really lend themselves to an oversteering setup and I’m still learning how to balance a setup

Thanks again
 
Lazza said:
Added an option to only record log files when the car has moved, or left the pits, or a lap was started or completed. Default is car needs to move to create a log.
Click to expand...

This is so great. I really wanted to suggest this feature but allways forgot to do so.
 
@Lazza I know you said you don't plan on sharing the code because of the ld format not actually being open, but I would still have a question. Did you reverse engineer the format yourself? If not, any chance you have any links to resources that could help me implement it myself?

Thanks in advance

PS. If you don't want to discuss it here feel free to send me an email to me@polakjan.com
 
@Jan Polak No resources, just the example log file that used to come with i2Pro. I knew the DAQ plugin of the time (rF1) had issues with recent i2Pro versions so I didn't want to use its logs at all.
 
@Lazza Thank you for the updates. I have another question: is there a way to have the time elapsed from lap start to current position? In other words, I know there is "Corr Dist" for distance, I'd like to have "Corr Time".
 
Last edited:
@d0nd33 I haven't tried to produce a value for that before, it might be possible to use a function to subtract the "Lap Start Elapsed Time" (in the Scoring_1 group) from the current time? Can I ask why you want that value? It's really not something I've looked into before. (usually if there's a derived value that people find useful, there's a way to get it through i2Pro)

The backup option is to provide that value as a custom channel, which shouldn't be too difficult for me to do, so if we can't work something out I can do it that way.
 
@Lazza I was trying to replicate something like this: Time Variance Gain/Loss rainbow track map
I did not remember "Lap Start Elapsed Time", I'm going to try it.
Result: "Session Elapsed Time" isn't useful because it is not continuous but moves in steps of 1s, even though its sample rate is set at 50Hz and Data Rate = 5.
 
Last edited:
@d0nd33 Ah, I see. Good (bad) to see iRacers also go to Motec for support for their unlicensed plugin. :rolleyes:

It looks like a "Running Laptime" channel would do the job, as said there. Unfortunately as you've noticed, the game-provided lap start value is being logged at a higher frequency, which means you can better see where it actually changes from one lap to the next, but this takes away the opportunity to use "Up sampling" in the channel properties to interpolate. (of course, if I lowered the frequency you could do it, but then you're trading accuracy for precision. So that's no good either)

Let me just check over the available data and work out the best way to achieve this with the fewest number of extra channels.
 
@Lazza This can be a temporary fix if 'Ground Speed' is logged with a sample rate of 100Hz. The difference from actual lap time is 0.01s, from the 100Hz sample rate, plus what comes from calculations with 'Ground Speed' and its precision. The latter can be lowered with higher 'Ground Speed' precision, I'd say at least 3 decimal places but more is better.

I integrated 1/speed by distance to get time:
Code: 
Session Current Time:
integrate_dist(1/'Ground Speed' [m/s])
Sample rate: 100Hz
I don't know how the difference in distance, used for numeric integration, is calculated. 'Corr Dist' has a sample rate of 10Hz(*). If that is used, accuracy would be lower because of the 10Hz sample rate, with a difference from actual lap time of 0.1s more.

'Current Lap Time' can be calculated from 'Session Current Time', by "resetting" the time counting at lap start:
Code: 
Current Lap Time:
'Session Current Time' [s] - stat_min('Session Current Time' [s],1==1,range_change("Outings:Laps"))
Sample rate: 100Hz
Obviously this does not work if 'Corr Speed' is ever equal to 0 because of division by 0 in 'Session Current Time'. MoTeC shows a gap when it happens: time counting halts and resumes when the car starts moving again. It's better to filter out those laps:
Code: 
Current Lap Time Filtered:
choose(stat_min('Corr Speed' [km/h] != 0,1==1,range_change("Outings:Laps")),'Current Lap Time' [s],invalid())
Sample rate: 100Hz
When speed reaches 0 it means that something like a crash or spin happened, so those lap time are not useful for best times comparison.

(*): 'Corr Dist' stands for "corrected distance", the way it gets calculated can be changed in Tools -> Corrected Speed and Distance. I suggest to select 'Ground Speed' to generate it. There's even a check box to create the 'Corr Lap Dist' channel on the spot.
Click to expand...

Problem solved in #520
 
Last edited:
I had to try and remind myself why the elapsed time channels are integers. I'm actually not sure. (maybe I couldn't see a use for them, and saved disk space...)

Would having the session elapsed time, and the lap start elapsed time, updated to 3 decimal places at their frequencies be sufficient? Or would you need something more?
 
@Lazza Yes, a precise and accurate session elapsed time would be sufficient, since current lap time can be extrapolated from it with:
Code: 
'Session Elapsed Time' [s] - stat_min('Session Elapsed Time' [s],1==1,range_change("Outings:Laps"))
I think that, in this case, precision and sample rate must match because we're logging time in relation to itself. So 2 decimal places for 100Hz or 3 decimal places for 1000Hz.

There may be a way to avoid to store such an "useless" value, if we could have 0 at lap start and lap time at lap end, and interpolate with a straight line what's in between. In this way only accurate lap end and precise lap time are required, since lap end and lap start are the same point.
Click to expand...

@Lazza Nevermind: I realized that there is 'Calc Lap Time' in Tools -> Corrected Speed and Distance... that does exactly what I requested :oops: It adds a channel with current lap time, 1000Hz.
I'd bump up 'Ground Speed' sample rate, so it can be used to calculate 'Corr Dist' with more accuracy.
 
Last edited:
You must log in or register to reply here.
Back
Top