Hi Gents, I am about to create a small test project just for fun. My plan is to do the following: 1) A real lamp which will be turned off when the race lamps will turn off. 2) A 7 segment display which will show my gears... The plan is to create a plugin which will send the data via a serial port to an Arduino microcontroller. The controller will be coupled to the lamp and the display as well. (Later I have bigger plans... ) And here is my question: As I saw in the InternalsPlugin.hpp the game phases are only available via the ScoringInfoV01, which is only updated 5 times a second, which is more than a human reaction time -> too slow... What is the possible quickest way to get the information about the status of the start lamps ? In the trackmap plugin, there are 3 options (+ AUTO) 1) TELEMETRY 2) SYNCRO1 3) SYNCRO2 So What are these ? Is the "TELEMETRY" really from the TelemInfoV01 or its derivates ? (which means that I missed something ) Thanks & Regards, Mitya
I believe 'telemetry' uses the scoring updates (5Hz). At least one of the syncro ones used to get the status from memory I think, as it no longer works in new versions of rF2. As far as I know there's no better reference for the starting light status. Although.... I've have to check a log, does the current laptime only change when the lights go out/green? The old-school way of knowing when the race starts (from the cockpit) is to bring up the current laptime screen in the MFD, because it springs into life the moment the race starts. If I get a chance I'll check.
Hmm... just checking a log I'm not sure that'll work. However, I am seeing something weird with what I've called "Lap Start Elapsed Time", which I think is telem.mLapStartET. It appears to be set prior to the green light. I hope it's not a logging error on my part
doesn't having the race info lcd screen active acheive this? As soon as the track goes green, the time starts.(Hope I got the proper name)
we are talking about this I think: http://mitya.madein.hu/ss/snapshot-2018-02-06-22-37-11.png Unfortunately I could not find this value via the API yet
I understand you want to do a test project but I'm fairly sure Simhub can do all what you want. Maybe you could get Simhub to see how it gets the data.
Sure, I know this stuff, I like them. However now the focus is on that I would like to do it I would be very curious how did they solve this issue... If you know them, I would really appreciate if you could ask them...
I'm just an end user. As I said, I wasn't 100% sure if Simhub does what you want, I was just mentioning the program in case you didn't know of it.
Sorry, I don't think I communicated that well. mLapStartET is updated at the beginning of the light sequence, at least if my telemetry log is correct. It's set to the sessionET that the lights will go out/green. So if you take that value and compare mElapsedTime to it, you can get it correct to 1/100s. (they are both telemetry values, not scoring) Obviously it makes sense that game clients know in advance when the race will start, otherwise the start becomes a ping competition. So it appears that information is revealed in the lap start ET value.
Hi Lazza, Firstly, I really appreciate that you try to help me ! What is that sessionET exactly ? I just created a small video to show how it goes, please check it:
That would be nice to know... However, I think I just found the trick As I saw my video many times and I have just realized the following: 1) mLapStartET was set when the lights came up 2) I did not know what is that value (until now) 3) The lights became green about when mElapsedTime reached mLapStartET So that is the key I think.. The game will know the "future", so it knows when the light will be green.. This is proven by when I turned off the formation lap, then mLapStartET were set around 9 secs.. And the lights just became green about that time... The question now is that how mLapStartET gets set ? Who sets it and based on what ? What are your opinions ? Can it work ? Can we find a better solution ?
I think the above questions don't matter, because this is what my client knows, I will not have a green light earlier So knowing when we need to start and having a >100Hz tick to check whether I reached that point means that in theory I could turn off my light within at least in 10ms. Which is good... Also I can add an offset delay to finetune the timer because of my "slow" hardware as well... Correct me if I am wrong please...
Correct 'SessionET' I just meant the session elapsed time. The telemetry value you pointed out (mElapsedTime) is how many seconds have passed since the start of the session. The game (client or server) doesn't know how long the light sequence will take beforehand. It's obviously randomised a little so it's not completely consistent. But it decides how long it will take the moment it begins. So at that point it sets mLapStartET - literally the elapsed time (ET) the race will begin. A server would have to communicate this to clients so that everyone's game starts the race at the same time. If the server just announced "Go!" when it decided to start, someone with a ping of 20ms would have a big advantage over someone with 300ms, as they'd be shown the 'green' earlier. As far as counting the lights, I'm sure the scoring data at 5Hz will suffice, as that light sequence will always be followed by a longer (and randomised) delay before the race starts. So a little lag there won't hurt. (mind you, if the parameters regarding number of starting lights is correct, you could probably trace it back from the race start time and what I imagine is consistent light-light delay, and work out exactly when the lights will show) What's important is you can compare mElapsedTime to mLapStartET, as you've said. Depending on your own device timing you could certainly make it better than 10ms, since each telemetry update you have a quite precise indicator of ET, and you know exactly when the race will start. In practice I'd suggest 10ms is probably good enough
Great! Thanks for the confirmation Lazza, I really appreciate the help ! I'll show you guys the result (will take a few weeks/months or so )
