Open eplossl opened 2 years ago
I don't think I've encountered one of these timers before, but I expect support could be added with a little experimentation.
Are you able to get the existing software working at all with the timer?
To be honest, I haven't tried yet. Unfortunately, the timer with the track ate itself today, and we'll have to replace the solenoid switch that starts the races, but I hadn't considered trying to connect to it from DerbyNet.
For what it's worth, it makes use of a magnetic sensor to detect the start dropping and a piezoelectric flag to detect race completion.
That's interesting, but how the sensors actually work doesn't really affect the interface. What we'd need to figure out is what bytes get sent over the serial interface when a car crosses the finish or the heat ends.
There's some basic information about connection parameters (9600-8-N-1) and the commands to reset the timer for different numbers of lanes, in the spreadsheet at https://grandprix-software-central.com/index.php/software/downloads/download/7-custom-timers/180-supertimer-setup. We'd just need to have someone connect a terminal to the timer and observe what it sends when a race is run.
When I can get the track repaired, I can get the data, but it'll be a few weeks, at least.
Hello, has there been any updates for this timer? Our pack has this same timer, however I'm very interested in using derbynet with our track. Let me know if there is anything I could perhaps provide.
If you have one of these timers at your disposal, it'd be super useful to be able to observe what data it sends back when racers cross the finish line. Also to see if the timer sends any other data (e.g., an identification string or an acknowledgment of lane masking operations). Working out a timer profile usually doesn't take very long if we can do some rapid experiment iterations.
Thanks Jeff. Do you just need a readout from hyperterm? I can get to the timer later this week and set it up.
On Mon, Jan 23, 2023 at 4:04 AM Jeff Piazza @.***> wrote:
If you have one of these timers at your disposal, it'd be super useful to be able to observe what data it sends back when racers cross the finish line. Also to see if the timer sends any other data (e.g., an identification string or an acknowledgment of lane masking operations). Working out a timer profile usually doesn't take very long if we can do some rapid experiment iterations.
— Reply to this email directly, view it on GitHub https://github.com/jeffpiazza/derbynet/issues/206#issuecomment-1400232241, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5NDDMQ55RNUYOHH7NL4XHDWTZXTTANCNFSM5RXT76IQ . You are receiving this because you commented.Message ID: @.***>
-- Eric
Hyperterm to start, but we'd probably need some back and forth communication, and maybe have you try some early prototypes.
Please email me directly (address is at https://github.com/jeffpiazza) when you can, and we can discuss in more detail.
So my pack has decided not to repair our system and are looking to replace with a known supported timer system. Unfortunately, that means I won't be able to gather data to solve this issue.
My pack has been using an old SuperTimer II track and timing system (http://www.supertimer.com/). Due to some technical knowledge deficit, I'm looking to possibly upgrade/replace the software from them with DerbyNet. However, you don't list as supporting that timer. Is it possible to get the SuperTimer II timing mechanism supported?
We may be looking at replacing the track and timer entirely for next year, but I'm curious as to how hard it might be to add that capability to the software, if possible.