PDT Timer does not reset after heat

[kurtnordstrom]

When I use Derbynet with the PDT Arduino timer (this is with the Java timer), the timer does not reset after the heat, and I have to manually hit the "timer reset" button on the physical unit.

Looking at the Profile, I notice that the timer sends the "R" code (reset) when on setup, but when it received the "overdue" event, it only sends the command to force it to send data.

Should the timer send the reset code when it is overdue?

[kurtnordstrom]

Just an update, changing the setting on the PDT sketch to reset on gate closed seems to have mitigated the issue for me.

I still feel like the timer should be able to send the reset command, but it's not as pressing now.

[Chipper2]

Yes, you have to have the sketch read the gate switch.

[jbrown123]

I agree that this is should be logged as a bug. When you click the "START" button in the DerbyNet interface, it should reset the timer as necessary to get it ready to run the next race.

This is how the PDT3 testing software works.

[jbrown123]

Just an update, changing the setting on the PDT sketch to reset on gate closed seems to have mitigated the issue for me.

@kurtnordstrom Thanks for noting this! I was trying to fix this exact problem and I greatly appreciated having this simple solution available.

[jeffpiazza]

https://derbynet.org/download/jars/pdt-372.jar sends a reset ("R") after the lane mask when preparing for a new heat. I'd appreciate if someone could try it out and confirm or refute that this change would address the concern here.

[jbrown123]

https://derbynet.org/download/jars/pdt-372.jar sends a reset ("R") after the lane mask when preparing for a new heat. I'd appreciate if someone could try it out and confirm or refute that this change would address the concern here.

Better, but not fixed in all cases. The pdt-372.jar works correctly under normal circumstances where the current derby-timer.jar does not.

Assuming that you close the start gate before the PREPARE_HEAT_RECEIVED message, it works fine. This is true whether the race finished normally or was aborted do to time limit exceeded.

Abbreviated log of working events

--> G
<-- .
--> G
<-- .
<-- B
INT SET >--RACE_STARTED--> RUNNING
<-- 1 - 3.51814
<-- 2 - 3.53337
<-- 3 - 3.53803
INT RUNNING >--RACE_FINISHED--> IDLE
--> G
<-- O
--> G
<-- O
--> G
<-- .
--> G
<-- .
INT IDLE >--PREPARE_HEAT_RECEIVED--> MARK
--> U
<-- .
--> R                                  <<<<< R command after Prepare Heat <<<<<<
<-- K                                  <<<<< Timer reset
--> G
<-- .
--> G
<-- .
--> G
<-- .
--> G
<-- .
INT MARK >--GATE_CLOSED--> SET
--> G
<-- .

Abbreviated log of timeout with gate closed before next heat

--> G
<-- .
<-- B
INT SET >--RACE_STARTED--> RUNNING
--> F
<-- .
<-- 1 - 99.99990
<-- 2 - 99.99990
<-- 3 - 99.99990
INT RUNNING >--RACE_FINISHED--> IDLE
--> G
<-- O
--> G
<-- O
--> G
<-- O
--> G
<-- O
--> G
<-- O
--> G
<-- O
INT Unexpected transition: IDLE >--GIVING_UP--> IDLE
--> G
<-- O
--> G
<-- O
--> G
<-- .
--> G
<-- .
INT IDLE >--PREPARE_HEAT_RECEIVED--> MARK
--> U
<-- .
--> R                                  <<<<< R command after Prepare Heat <<<<<<
<-- K                                  <<<<< Timer reset
--> G
<-- .
--> G
<-- .
--> G
<-- .
--> G
<-- .
--> G
<-- .
INT MARK >--GATE_CLOSED--> SET
--> G
<-- .

Failure case (gate not closed before next heat)

However, if you don't close the gate prior to the "R" command being issued, the timer will never reset. Now you are in a circumstance where DerbyNet thinks you are in "staging" mode, but the timer hardware thinks it is still in "racing" mode (has yet to be reset). This behavior is the same whether the race finished normally or the race ended because of a timeout

Here's an abbreviated log of a failed run

--> G
<-- .
<-- B
INT SET >--RACE_STARTED--> RUNNING
<-- 1 - 2.82814
<-- 2 - 2.84413
<-- 3 - 2.84898
INT RUNNING >--RACE_FINISHED--> IDLE
--> G
<-- O
--> G
<-- O
--> G
[ time elapses ]
<-- O
--> G
<-- O
INT IDLE >--PREPARE_HEAT_RECEIVED--> MARK
--> U
<-- .
--> R                                  <<<<< R command after Prepare Heat <<<<<<
<-- O                                  <<<<< O response, not K as expected <<<<<<
--> G
<-- O
--> G
<-- .
--> G
<-- .
--> G
<-- .
--> G
<-- .
--> G
<-- .
INT MARK >--GATE_CLOSED--> SET
--> G
<-- .
--> G
<-- .
--> G
<-- .

Note the response in this case. Not a 'K' as expected but an 'O' indicating that the gate is still open.

Closing the gate at this point does not reset the timer to the ready state. Now the DerbyNet software is in 'staging' mode but the timer hardware is still waiting for a reset.

I suggest sending an 'R' if DerbyNet is in 'staging' mode and the gate is closed (e.g. when INT MARK >--GATE_CLOSED--> SET occurs).

Let me know if this is sufficient or if you want additional details, logs, etc.

[jbrown123]

@jeffpiazza as you are, I'm sure, aware -- this bug exists, even worse, in the browser window version (vs. the JAR file).

+22.113S --> G
+22.119S <-- .
+22.227S <-- B
+22.228* INT SET >--RACE_STARTED--> RUNNING
+25.321S <-- 1 - 3.02354
+25.321S <-- 2 - 3.05662
+25.330S <-- 3 - 3.06583
+25.331* INT RACE_FINISHED: {"action":"timer-message","message":"FINISHED","lane1":"3.02354","lane2":"3.05662","lane3":"3.06583"}
+25.331* INT RUNNING >--RACE_FINISHED--> IDLE
+25.381S --> G
+25.387S <-- O
+25.555H <-- Prepare heat -100,16,7,3,1,Timer Test
+25.557* INT IDLE >--PREPARE_HEAT_RECEIVED--> MARK
+25.632S --> G
+25.638S <-- O
+25.884S --> G
+25.890S <-- O
+26.135S --> G

Note here that the PREPARE_HEAT_RECEIVED occurs almost immediately after the race (0.2 seconds after end fo race). The gate is almost never closed at that point and thus, the hardware isn't reset. Not to mention, of course, that the web version isn't sending the 'R' command anyway.

[jeffpiazza]

Thanks for this great feedback!

I have a new version of the jar up, same URL that (re-)sends a reset when the gate closes.

(java -jar pdt-372.jar -v will report 20250404 as the date.)

Once I can confirm that the behavior is correct, I'll update the in-browser version to match.

[jbrown123]

Confirmed - Works!

This fixes all issues I'm aware of. @kurtnordstrom should jump in with any other cases to test.

Does the right thing under the following test criteria:

• Race finishes normally, gate closed before next heat
• Race finishes normally, gate left open after next heat
• Race timeout, gate closed before next heat
• Race timeout, gate left open after next heat

Gate closed after next heat

--> G
<-- O
--> G
<-- O
INT IDLE >--PREPARE_HEAT_RECEIVED--> MARK
--> U
<-- .
--> R                             <<<< reset
<-- O                             <<<< fail (gate still open)
--> G
<-- O
--> G
<-- O
--> G
<-- .
--> G
<-- .
--> G
<-- .
--> G
<-- .
--> G
<-- .
INT MARK >--GATE_CLOSED--> SET
--> R                             <<<<< reset
<-- K                             <<<<< ack
--> G
<-- .
--> G
<-- .
--> G
<-- .

Gate closed before next heat

--> G
<-- .
--> G
<-- .
--> G
<-- .
INT IDLE >--PREPARE_HEAT_RECEIVED--> MARK
--> U
<-- .
--> R                                      <<<<< reset
<-- K                                      <<<<< ack
--> G
<-- .
--> G
<-- .
--> G
<-- .
--> G
<-- .
--> G
<-- .
INT MARK >--GATE_CLOSED--> SET
--> R                                   <<<<< reset (unnecessary, but doesn't hurt)
<-- K                                    <<<<< ack
--> G
<-- .

[jbrown123]

@jeffpiazza let me know when you've implemented this in the JS (internal) timer and I'll test those cases again using the internal one.

[mashcraft]

Late comment -- Fixed this a long time ago by setting the PDT sketch to reset the timer after gate is closed for 10s. This also makes it easy for the participants to race each other in an unstructured manner before/after the actual event.