derbynet icon indicating copy to clipboard operation
derbynet copied to clipboard

Timer results not being recorded in derbynet hosted server using derby-timer.jar

Open koffeypot opened this issue 11 months ago • 2 comments

We ran a small derby over the weekend and failed to receive any heat results from our Champ timer. We ended up using the manual entry option for the finishes of each heat. The java timer software showed that the timer was connected, and the server was connected. In testing with the timer before the race I was not having this issue. I'm wondering if it could be an issue with the serial cable.. but it was detecting the timer properly. Only difference I can think of is we were on a different wifi network, but I would have expected the log file to be more helpful with communication errors with the server.

I'm hoping the log file and extract help figure out what the issue could be so I can be prepared for our next event.

Server: Derbynet hosted Server(thank you! this server has blazing speed!) Timer: Champ(eTekGadget Smartline Timer) Timer software: derby-timer.jar 10.0-1782-20241231 OS: Raspbian Gnu/Linux 10 (buster) on a Raspberry Pi model 3b

log file: timer-20250126-1423.log database extract: derbynet-20250127-160343.zip

koffeypot avatar Jan 27 '25 20:01 koffeypot

I just checked an old log from before the event where heat times were being recorded on the pi using derby-timer.jar:

timer-20250121-1704.log

koffeypot avatar Jan 27 '25 20:01 koffeypot

The timer log seems to show the gate being open initially, and remaining open until the +14:43:09.081S time mark (the timer responds with a "1" to each "rs" query). Thereafter, the timer reported the gate being closed ("0" response) continuously for the rest of the log.

That the timer was capturing times for you argues that it was successfully reading the start gate state. I don't have an explanation for why it wouldn't share that information accurately with the host computer. I've never seen this behavior before, to be honest.

The log from the 21st (with the same jar file version) looks entirely different, with the gate reporting open and closed as you'd expect.

If this behavior continues, a workaround would be to turn off the gate polling by setting the no-gate-watcher flag.

jeffpiazza avatar Jan 28 '25 00:01 jeffpiazza