Ticket

back to ticket overview

Project RCM Ultimate
Summary Use RTC time of external start button
Sequence 2751
Classification Change Request
Priority Medium
Status Done
Kickoff date Sep 11, 2019
Maturity date Sep 11, 2019
Responsible
Version 2.4.5
Expense 0
Description I has now used RCm for 2 races parallell with the old bbK. Mostly it has worked fine, but I has found a strange behavior that I dont know wether it is a wrong setup or a bug. We use milling start, so the rules are set to groupstart. But as you can see in the attached example, two guys has a laptime of 0,000 sek for lap 0. We visually saw that they did false starts, and bbK also took it as false tarts, meaning they got 1 lap more in RCM than in bbK! We use a startclock that is connected to both decoders, so the startsignal is exactly the same in both setups. My guess is that a passing just before the startsignal is accepted as a start, instead of a warmup lap.

Comments

Timestamp Who Comment
Sep 11, 2019 7:18:08 AM Felix Romer What is a "milling start"? Is it kind of formula 1 start?

Do I understand this correctly, that the start of the heas is done over a start clock. Means RCM is receiving the start signal from the decoder and triggers the start based on this. Is that correct?

If they would have passed the loop before the start trigger has been received, then the passing would have been not counted (as it has been collected before the start). Therefore I would say, that those 2 pilots have passed the loop after the start has been triggered. Otherwise the laps would not have been collected. Therefore I assume that those two pilots have more or less passed the loop at the same time the timekeeper has triggered the start. Could that be the case?

There is an option within the rule where you can set a locktime (see attachment). If a passing is collected during this locktime, then RCM will simply ignore it. Maybe this setting would solve this problem.
Sep 11, 2019 7:18:20 AM Felix Romer Milling start could also be called running start. The boats lanches before start and run around the track. the startclock counts down to zero and at that point sends a signal to the decoder(s), wich in turn trigger the software. we use one loop that via a coax splitter/t-harness connects to both decoders. The startclock is also connected to both decoders, so it triggers them at exactly the same time. It is theoretically possible that a boat passes te loop exactly at startsignal, but it is practically impossible that several boats should do so and get 0,000 laptime for lap 0 in one competition. (there are more cases in this competition than the example I gave you). I also ran RCM parallell with bbK, and when bbK recorded a start (lap0) for these boats, RCM gave them there first lap. We also saw visually that they had passed the line by several meters at start signal.
It feels like the software has an "allowance" for passings a few 10th of a second before start. Could it be tha the decoder still sences the transponde it has passed?
Sep 11, 2019 7:19:07 AM Felix Romer Hi John

I did have now a closer look at the event and especially the logs (needed to decode manually a part of the decoder logfile). Here is what I have done and what is the important part of it. RCM has received those messages in the order which they are listened below. There is a timestamp in front of each datagram, which shows the exact time when the data has been received (with a accuracy of milliseconds)

-> external start: TX: 9992 -> 1567274177368
31.08.2019 17:31:10.934 [<] 8E022B009D29000001000104271100000304082700000408C08DAF9B746D9105000802000081045F0D04008F

-> time request from RCM
31.08.2019 17:31:11.009 [>] 8E0000004ACC000024000100050004008F

-> answer on "time request" -> 1567274177463
31.08.2019 17:31:11.031 [<] 8E021F009C9800002400010882069D746D9105000402000081045F0D04008F

-> passing: TX 7681697 -> 1567274177261
31.08.2019 17:31:11.031 [<] 8E0233003824000001000104281100000304A13675000408C8ED99746D9105000502A40006020F000802000081045F0D04008F

-> passing: TX 4671791 -> 1567274177379
31.08.2019 17:31:11.179 [<] 8E023300A93C0000010001042911000003042F4947000408B8BA9B746D91050005028C0006020B000802000081045F0D04008F


In the group start mode, RCM needs the timeoffset of the decoder in order to be able to calculate the proper time of the first passing. Therefore RCM send a "time request" message to the decoder when the start is executed (see above). In your case, this "time request" would actually not really be necessary, as the start has been triggered by the external clock. Therefore RCM could actually use the passed time of this external start instead of requesting it "again" - what has been done in your case.

As I already mentioned, RCM has requsted the decoder time again after the external clock has done the "remote" start. When I calculate now the laptimes based on the offset RCM has received by the "time request", then I end up in this values:

> 1567274177463
> TX 7681697: 1567274177261 -> -202
> TX 4671791: 1567274177379 -> -84

As you can see, both times have a negativ value, what should not be the case. This ends up in a laptime of "0.000" within RCM, as a type of the time is "unsigned" (negativ values are not possible).

If I do the same calculation based on the time of the external start, then I get this values:

> 1567274177368
> TX 7681697: 1567274177261 -> -107
> TX 4671791: 1567274177379 -> 11

The first received passing of the TX 7681697 is still negativ (but not the second one). As you can see in the decoder log above, this first passing has been received 97ms after the external start has been received. Therefore my assumption would be, that the car has passed the loop after the start, otherwise I would expect, that the passing datagram would be sent by the decoder before the external trigger. But it looks like as this is not given.

I will do the following:
First I will do a change on RCM in order that RCM will use the time of the external trigger as "time offset" for the group start mode. This will end up that RCM will not send the "time request" to the decoder again. If this is done, then RCM would have at least a valid laptime for the second received passing. Regarding the first passing which would still be negativ - I will contact MyLaps and ask them about this.

Change history

Timestamp Who Modification
Sep 11, 2019 7:17:39 AM Ticket created
Sep 11, 2019 7:17:46 AM Felix Romer Field: Status
Old value: Opened
New value : Running
Sep 11, 2019 8:03:08 AM Felix Romer Field: Status
Old value: Running
New value : Done