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.

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.

I finally got posting approval, so you guys can interact with me directly now.

I'll comment on the latest post by Cliff to start things off.

Quote:

Originally Posted by Cliff96

Keith,
* 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.)

I agree. Custom MSR columns can be added to the MJTiming registration. It's a little clunky (editing the CSV file manually for the first time), but not impossible or difficult.

Quote:

* 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

Already possible. Look under the config tab for something that reads reverseDisplayDigits. Other clubs have run into this, and it was fixed long ago.

Quote:

* 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.

I could add this as a config item, but it sounds to me like this isn't necessary.

Quote:

* 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.)

My software allows you to reset or trigger both start and stop beams. If you do a trigger operation, the times will automatically show 999.999 and mark as a rerun, since the software does no timing internally - it all has to come from the timing hardware.

Quote:

* 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.

This is where life starts to get "interesting". Live results from MJTiming are only to a local router and WiFi hotpoint, not the internet. If you want full internet posting, then I can't help you. I am fully willing to give you the source code for my live results app. It's written in C#, using SharpDevelop.

Quote:

* 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.

Again, life is interesting. I do have HTML conversion scripts (source available if you want), but there is a huge reason that my software produces text-based scores. It really is realtime, with the updated scores available immediately after a car crosses the finish line. I value the ability of the timing software to run on incredibly low powered netbooks, so HTML formatting just wasn't in my list of important things. Oh, and I am completely useless when it comes to HTML and web apps as well

Quote:

* 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.

OK, I am confused here. I show a percentage score for every driver, for PAX, RAW, and class results. I don't understand where this doesn't match your desires. Those percentage scores are what I use to calculate and generate the season total scores.

I am certanly willing to accept requests for enhancements, but being that this is a free app, I am also willing to ignore them if it would require some major re-write. The software *is* supported, and I can give you contacts at multiple clubs if you want third party reviews of the software as well as my support.

Presently, there are about a dozen clubs (that I know of) using the software. The last 4 western Canadian Nationals have been run using the software, so I think it is reasonably capable And, to brag a bit, it has never lost any data for any club, with one exception (the club's laptop hard drive completely crashed on them). And even then, they could have configured the software to make realtime backups on a USB dongle.

You also have my word that, if I decide to quit supporting the software, I will release the code as open source. The reason I don't do this now, is that supporting software becomes impossibly difficult when other people start modifying it.

Anyway, all questions welcome. You can safely "install" (unzip to a folder) the software on your home computer and play around, even if you don't have timing hardware to enjoy the full experience.

Welcome Murray! And thanks for this software. I'm sure we are not the only one having problems with Axtime/Axware and looking for a way out.

Quote:

Originally Posted by MurrayPeterson

I finally got posting approval, so you guys can interact with me directly now.

I am certanly willing to accept requests for enhancements, but being that this is a free app, I am also willing to ignore them if it would require some major re-write. The software *is* supported, and I can give you contacts at multiple clubs if you want third party reviews of the software as well as my support.

Presently, there are about a dozen clubs (that I know of) using the software. The last 4 western Canadian Nationals have been run using the software, so I think it is reasonably capable And, to brag a bit, it has never lost any data for any club, with one exception (the club's laptop hard drive completely crashed on them). And even then, they could have configured the software to make realtime backups on a USB dongle.

You also have my word that, if I decide to quit supporting the software, I will release the code as open source. The reason I don't do this now, is that supporting software becomes impossibly difficult when other people start modifying it.

Anyway, all questions welcome. You can safely "install" (unzip to a folder) the software on your home computer and play around, even if you don't have timing hardware to enjoy the full experience.

Report for MSR export: Cliff also says this is one of the last things I should worry about, so I haven't thought about it much.

Digit backwards: I caught on to that setting after re-reading the files. I can say I'm all good and this "issue" is behind us now.

Manual beam triggers: I have yet to see the 999.999, or maybe I missed it, in my tests. No big deal, I can always key in "RRN" myself. Point is, this feature allows us to undo a false trigger, if caught in time.

Sensor ID reassignment: Agreed, we don't have an immediate need for this change.

Live Results: We supply live results via local wifi as well, not internet, so no problem there. It's just that we're used to seeing Axtime live results. However, if the community agrees to change out the live results part as well, then all the better.

Rank by PAX percentage: I read the VCMC results page you linked to and it is indeed done the same way as ours. Is there a setting that triggers these calculations or is it part of the conversion scripts?

Continuation plans: Github and git should help. Still need someone to manage them though.

All said, we're talking about replacing a key component of the series' operations. We probably need to have a region-level discussion, before actually adopting MJTiming for next year. In the meantime I can find out if additional work is still needed, and if needed is it something that I can do or you have to do.

Live Results: We supply live results via local wifi as well, not internet, so no problem there. It's just that we're used to seeing Axtime live results. However, if the community agrees to change out the live results part as well, then all the better.

I just use a router that is running dd-wrt firmware, with DNSmasq configured to route any requests to a specific IP address. The laptop is listening on that IP address, and is running one of my apps (MJannounce) that services these web page requests. The format is simple and dull -- just a simple HTML wrapper around the text results.

Quote:

Rank by PAX percentage: I read the VCMC results page you linked to and it is indeed done the same way as ours. Is there a setting that triggers these calculations or is it part of the conversion scripts?

Neither -- it is intrinsic to any of the scoring options with the exception of rally scoring, which uses a point system. The rally scoring is currently broken, BTW. If you look at the Edmonton club's results (unconverted text, not split into separate files), you will see that the percentage score is still there for PAX, RAW, and class scores.

Quote:

All said, we're talking about replacing a key component of the series' operations. We probably need to have a region-level discussion, before actually adopting MJTiming for next year. In the meantime I can find out if additional work is still needed, and if needed is it something that I can do or you have to do.

There is one thing you probably haven't noticed yet. The software insists on unique "numbers" for all drivers, not just within a class. This was (and is) done for operator simplicity and speed. However, the car "number" is actually any text identifier, so some clubs just concatenate number and class together into a single identifier (e.g. "52CS"). One small club just uses member's initials instead of numbers. Most clubs (ours included) just go with the unique number for every driver.

And if you decide to not use the software, no problem. It's not exactly a money loss on my part

I just use a router that is running dd-wrt firmware, with DNSmasq configured to route any requests to a specific IP address. The laptop is listening on that IP address, and is running one of my apps (MJannounce) that services these web page requests. The format is simple and dull -- just a simple HTML wrapper around the text results.

Essentially we do the same thing, except with tomato instead of dd-wrt. We actually run/ran two sets of results; first using windows iis (with the axware html results) as the websever, and secondly (which I think is the only one we advertise now is the live results package from axtime (which parses the axware log file, and builds/serves/pushes the live results in it's own package). I haven't looked, but if the source is available for it, someone with some node.js skills should be able to adapt it to read the mj timing format. I just don't have the time right now to learn node and make the changes with all the other stuff on my to do list.

Quote:

Originally Posted by MurrayPeterson

There is one thing you probably haven't noticed yet. The software insists on unique "numbers" for all drivers, not just within a class. This was (and is) done for operator simplicity and speed. However, the car "number" is actually any text identifier, so some clubs just concatenate number and class together into a single identifier (e.g. "52CS"). One small club just uses member's initials instead of numbers. Most clubs (ours included) just go with the unique number for every driver.

Not a problem, we run unique numbers across an event. A couple years ago we tried relaxing it, but it added confusion as people were used to calling only the car number without the class on a penalty, not fun when things got busy behind the screen with intermittent radio's at a big venue - so we stopped allowing it.

Quote:

Originally Posted by buurin

All said, we're talking about replacing a key component of the series' operations. We probably need to have a region-level discussion, before actually adopting MJTiming for next year. In the meantime I can find out if additional work is still needed, and if needed is it something that I can do or you have to do.

I don't know about the big discussion, when I was doing it we had flexibility - but things needed to work. I remember, setting things up in the basement to test, and then once I was reasonably confident that it would work, piloting the new system back in the day at the school to make sure it would work for an event, and we did the same when going wireless, set it up in parallel at a club event before using it for a regional. I would suggest the same again.

Essentially we do the same thing, except with tomato instead of dd-wrt. We actually run/ran two sets of results; first using windows iis (with the axware html results) as the websever, and secondly (which I think is the only one we advertise now is the live results package from axtime (which parses the axware log file, and builds/serves/pushes the live results in it's own package). I haven't looked, but if the source is available for it, someone with some node.js skills should be able to adapt it to read the mj timing format. I just don't have the time right now to learn node and make the changes with all the other stuff on my to do list.

That makes thing easy in one way; you can just use my existing live scoring app (MJannounce) with your existing router/laptop setup.

Quote:

Not a problem, we run unique numbers across an event. A couple years ago we tried relaxing it, but it added confusion as people were used to calling only the car number without the class on a penalty, not fun when things got busy behind the screen with intermittent radio's at a big venue - so we stopped allowing it.

BTW, you might want to talk with the Winnipeg club (http://forums.wscc.mb.ca/) about your Axtime issues. They decided to use Axtime instead of MJTiming, and I believe that they are happy with it so far.

Further updates. We recently ran an event with 107 drivers, and managed 10 runs each. MJTiming was showing an issue with live scoring at the end of the day, and this is a tweak or two to make it more responsive.

Essentially we do the same thing, except with tomato instead of dd-wrt. We actually run/ran two sets of results; first using windows iis (with the axware html results) as the websever, and secondly (which I think is the only one we advertise now is the live results package from axtime (which parses the axware log file, and builds/serves/pushes the live results in it's own package). I haven't looked, but if the source is available for it, someone with some node.js skills should be able to adapt it to read the mj timing format.

I have successfully modified Live Results to read from mjtiming. Woot!

Took the results from regional event 3 (the one with lightning and incident) and crosschecked the converted timing data between mjtiming, LR and axware. For correctness the port also honors the last name and cones-get-paxed settings from mjtiming, but we'll always keep both enabled.

ps. Say hi to LEDE when that Unifi returns "gloriously" next year! Still looking for a way to hang it 8ft in the air away from the tent. Something like a collapsible lamppost or stand.

I have successfully modified Live Results to read from mjtiming. Woot!

Took the results from regional event 3 (the one with lightning and incident) and crosschecked the converted timing data between mjtiming, LR and axware. For correctness the port also honors the last name and cones-get-paxed settings from mjtiming, but we'll always keep both enabled.

ps. Say hi to LEDE when that Unifi returns "gloriously" next year! Still looking for a way to hang it 8ft in the air away from the tent. Something like a collapsible lamppost or stand.