View Single Post
  #4  
Old 08-25-2017, 11:59 AM
Cliff96 Cliff96 is offline
Registered User
 
Join Date: Jul 2003
Location: North York, ON
Posts: 301
Re: A possible way out of Axware? First thoughts on MJtiming

Quote:
Originally Posted by buurin View Post
Thanks to a tip from Dina:
I tried MJtiming with our timing gear and my laptop and here are my first (second) thoughts. It seems to work, but needs (supplementary work) before we would be able to use it to run our series.

- We'll need the 4 clubs that host the regionals to adopt its MSR report format to export registrations - add an MJtiming style report. On the plus side, we would seem to have an easier time adding drivers on the spot. The exact format we'll need from Murray should we decide to go this route.
- It doesn't work out of the box with our display. The digits are shown backwards. (It needs a setting to reverse the digits to match.)
- It works out of the box with our beams, but only knows unit "A" as start beam and unit "B" as end beam. If someone runs over or otherwise knock "B" out of commission during an event, we won't be able to put our unit "C" in its place and carry on. Do we have those reconfigure jumper the manual mentioned?
- It can't interface directly with our (Axtime) LiveResults. However I can write a script that watches MJtiming's timing data (it's CSV) and run a script that converts it to Axware format on the fly for LiveResults to consume. (It has its own live results, but I think we should stick with Axtime because it's still serving us well.)
- Its public-facing output are text files. More conversion scripts would be needed to generate results in our typical format.
- (I would need to build a brand new class data file for our superclass structure.)
- Its points system is the typical points-by-ranking. Ours is proportional by PAX time, with 100pts for winner. We can address this when we run scripts to produce results from MJtiming raw data.
- It allows us to void the most recent start and end beam triggers with two keypresses.
- We seem to have more screen real estate with it than Axware. Timing, drivers and logs are on separate tabs.
- It autosaves timing data, so we can restart it (or even reboot the laptop) and pick up where we left off.
Keith,

I'll offer a couple of comments base off of running things for a couple of years, feel free to reach out - I'm sure there's more, but this quick post is already getting a little long

* Building/changing MSR custom reports is easy; I wouldn't worry about this part (in theory we used to, and likely should all use the same account - that way we can make sure the class validations are setup and done correctly on the form.)
* Display showing backwards; means it's pretty close (the format and protocol are working correctly), there just needs to be a new display type spec'ed in the SW to print the numbers in the inverse order
* Timing beams; the sensor/emitters can be placed anywhere and aren't specific to start/stop. The wifi-links are specific (and should be well back of the course as they are more $$), but in the event you need them, there should be dongles in either the laptop or bins. They look like ~6" single ended ethernet cables. You turn the unit off, insert the appropriate dongle, and then turn it on - the unit will now act as whatever cable you inserted until you turn it off. If it's power cycled it reverts back to the standard setting written on the case.
* Axware allows us to void and suspend start/stop beams. The trick is the operator needs to catch these in time - and know which ones to hit at the right time, if you miss them there is no fixing it later without reruns. (There is a flaw where you can't reset the sector timer itself.)
* On the live results side, if I'm remembering right, axtime includes the source - I'd think it would be more reliable if it could be modified to read the mjtiming output natively, rather then converting it to axware format, and then having axtime convert that to it's own. But I'd put this low on the list, if mjtiming has their own way to push live results.
* Text results are fine, and would likely play better with the results module on the website, but still takes way more work then it should to publish them there.
* The big piece is generating the class and overall results correctly, on the percentage basis - we'd want these available on the live results, and after every run.
__________________
--
99 328i
Reply With Quote