THSCC Forums

In the most recent version of AXWare, they started encrypting the data at rest. This prevents anyone accessing the data in any meaningful way without AXWare's blessing, such as third party tools like my Instant Results web app and others. Although it seems their encryption scheme is quite weak, the legality of circumventing it is unclear. From discussions with AXWare, we've discovered that they hold the view that the timing data our club generates belongs to them. I think that is a completely absurd and customer-hostile position, the likes of which could only be held by a company that thinks it has its market cornered.

With that in mind, I've been giving strong consideration to building my own timing and scoring software from scratch, with the goal of being able to take AXWare completely out of the autocross equation. This would be no small task, and in all likelihood would take me well over a year of sustained on-the-side, after-hours development. I've never built desktop software before, so I have some studying and experimentation with desktop development tools/frameworks/etc before I can actually break ground on this.

I'll be developing this as an open source project right from the start, and I plan to use a free software license. I'm still shopping around for the desktop framework, but I'm going to give a strong preference for one that makes cross-platform development easy, so this program could run on Linux and Mac in addition to Windows. I'm not planning to go commercial with it, but I'll probably put a donation link on the source repository.

I'd like to collect some feedback from anyone who has used AXWare to run an autocross event. What do you like about it? What don't you like? What could be improved?

_________________
2017 THSCC Autocross Chief of Timing and Scoring

03 Nissan Altima
02 Honda S2000

Let me state that I haven't used AXWare, so I can't comment on that part of the equation.

That said, I did write a T&S solution way back when for a school project for RC racing. And I know a thing or two about "open source." And I'd DEARLY love an open source T&S solution that knew how to score closed circuit racing as well as open circuit (autox being open). You'll get a LOT more eyeballs and a LOT more development help on this if it can do both, and the differences are pretty minor if you architect from the beginning with both in mind. I think it's also VERY important to keep the theory of providing "segment times" via intermediate beacons in mind at the architecture level, because leaving that out to begin with is fine, but if you had no consideration of it to start with then adding it can be a nightmare.

You might also consider a path that not only lets it run on a laptop, but let's it run on a tablet. And in an ideal world, a multi-tablet system so that open circuits can be manually timed in multiple locations (ie. a tablet at the start tower signals a "go" for a competitor and another tablet at the remote end of the course signals a "stop" for that same competitor). This opens your system up to time things like skiing, bicycle downhill, hill climbs, etc. Yes, it requires a reliable network, but let the end user worry about that part.

On the closed loop side, I have gokart track I'd want to use something on. I currently have an AMB loop and decoder, but all my transponders appear to have died and I don't REALLY want to replace them. Would love to come up with a cheaper hardware alternative to that, and am good on the hardware side, and only mediocre on the software side. I'm actually contemplating building my own helmet-based lap timer now that would have a beacon receiver on your helmet and a tiny display in the bottom of your eye port. I have two display options identified, with one on the way to me now and will likely order the other soon. I think I can prototype it for under $75 in parts using an Arduino and an OTS AiM beacon.

Anyway, I have a lot of thoughts. Happy to discuss here, via email at djb@donniebarnes.com, or in person if you're really serious. I know a thing or two about the online maintenance of an open source project if you need or want any help with that, too. And I'm happy to contribute in other ways.


--Donnie

_________________
My Blog

Oddly enough I was trying to think of ideas for some of the various new micro controllers out there in the "maker" universe and I was wondering about a significant number of devices scattered throughout an autocross course that maybe used a mesh network for communication and maybe even something easier to maintain than laser triggers (but likely still optical based) to generate a large number of segment timing data and then have an app that would let you view your runs against others. Where you are loosing and gaining, etc.

To your original point, I think open source T&S software is an interesting idea. Also imagine open API for publishing of live T&S data during the event so that anyone can suck the data into their own device and process as needed. Any subscriber (including timing display near finish or elsewhere) would use that public feed.

Richard

_________________
Richard Casto
1972 Porsche 914
2013 Honda Fit Sport
2015 Honda Fit EX
http://motorsport.zyyz.com
Money can't buy happiness, but somehow it's more comfortable to cry in a Porsche than a Kia.

This used to be a possibility when AXWare's data was stored in the clear at rest. If you point a cloud storage provider at the folder where it's storing its files, the possibilities are pretty much endless.



These are excellent points and I'll take this into consideration as I start to plan and architect the project. I probably wouldn't provide full support for this at first just as a matter of prioritization, but I really like the idea of having a general purpose race timer application.



I don't think it'll be necessary to have one program that runs on both a desktop and one or more tablets to achieve this. The desktop app could open a network port and listen for timing data from timer client apps, which are designed around the sole purpose of being remote time input stations. This approach could lend itself to Richard's idea as well.

I don't really like the idea of running the main timing and scoring duties using a tablet. Makes my shoulders and arms sore just thinking about it.

Thanks for the feedback!

_________________
2017 THSCC Autocross Chief of Timing and Scoring

03 Nissan Altima
02 Honda S2000

I get the aversion to T&S running directly on a tablet, but I would say consider your "market", too. When it comes to timing a LOT of other sports, tablets are a) what people have and b) MUCH easier to "ruggedize" than a laptop. You're thinking primarily of a world where you have a bus or a building, but a lot of timing applications could end up having neither.

Another idea I had was *integrated* photo finish capability as well as video logging capability. On the former, think of the ability to have a tablet or iPod or Android device on a tripod that was automatically triggered by the T&S system (if beacon based) to snap a pic (or series) that were properly labeled and/or put in the database to help with conflict resolution.

Another idea is to just let the thing shoot continuous video (using a custom app) that could also sync to the race timing so that events in the video could be located easily. Again, conflict resolution. I'm thinking distributed network of timing devices here with the ability to have video or pics or both triggered on any or all of the devices. I see it useful at the finish for photo type finish scenarios, but what about at corner stations using video into the system so that passes under caution and the like could be penalized properly.

Richard, your idea could be pulled off easily with XBee devices. They're about $20 per device and all you'd have to add is the optical trigger (there is digital I/O available) and you get the mesh "for free." Range is WAY more than enough for a typical autox course, power consumption is miniscule. They are wonderful little devices.

Carlton, FWIW, there are already several closed source tablet based T&S solutions for things like bicycle racing and such. They work pretty well, too. And for a subscription model that seems to make money, check out Gamechanger. It's a baseball scoring "app" and you can use it just to keep your baseball game stats, but you can also "livetrack" with it by streaming your game to their servers and Grandma/Grandpa can keep up with the game just like ESPN's "Gametracker" type stuff for pro sports. Those folks are making serious dough.

I know that's not really what you're *after* here, but an open source solution is nice for the DIY folks, but for everyone else they just want to pay a reasonable amount for shit that works. The cloud part of this would be worth money to clubs to be able to livestream event results, anyway. *shrug*

Just a lot more random thoughts. Obviously this has been on my brain in a LOT of different avenues for quite some time.


--Donnie

_________________
My Blog

Everything about axware is customer hostile. I don't understand how they have customers.

In my experience, talking to the timing hardware is the most complicated part. Given what we run, a tablet just isn't going to cut it. However, I'd like a tablet interface for check-in and grid. Actually, I want a no-human-involved barcode system for grid -- for rallyx, the line rarely stays in order, the staged car isn't always communicated to the bus, and without fail, cars grid that haven't checked in. (and I do have industrial barcode readers. I wouldn't use them in the rain, but they can stand up to dust.)

The world is going to a networked model where *everything* ends up a network device. Getting timing hardware to become a network device is going to become easier than having a PC that can interface to it all the time. That's the part I'm *least* concerned with, honestly.

And cameras on smartphones and tablets are barcode readers now, FWIW. And they can be made waterproof quite easily *and* still read barcodes.


--Donnie

_________________
My Blog

And they make such perfect track telemetry devices. (No, they don't. I did that once, and bought an Aim Solo DL) The club has no such fancy timing hardware. (well, the track program does, but that's what's required to use the built-in timing loop) I can only code support for things I have to play with.

Carlton - You might want to post on http://www.roadraceautox.com/ since this forum currently seems to be used by a large portion of the autocross world as well as road racers. There have been timing equipment threads and some Axware discussions.

_________________
Dick Rasmussen

FS 50 2018 Mustang GT

Thank for putting me onto Xbee. I will read up on what they can do.


To expand upon the idea of the mesh network of devices and publishing a stream of data. There is no reason you can't have two streams running. A raw event based stream (straight off the devices) and potentially another stream from T&S that would potentially more data and corrections? Or you define a spec for a single stream that includes corrections as needed (such as corrections from the T&S team for things like false triggers, etc.) And there is also no reason that additional devices couldn't consume the raw stream (such as watching the stream for a specific event such as car crossing finish line) and it would then trigger it's own action (taking a photo or video). This might be exactly what Donnie was talking about anyhow. And of course you can always get creative when taking photos or videos. Such as continuous photos/video, but it saves the last few seconds once the event happens. So you could have a trigger at the end of a segment (maybe it is just easier to place the sensor near the end) and it could capture entry and exit.

The possibilities are endless. I think what would be needed is the definition of an open ecosystem and then "add ons" could be built over time. I also understand the reluctance regarding tablets, but I can see no reason that both classic desktop and tablets clients could be created. And also, there is no reason to say a single devices has to be used for all scenarios. Phone that can scan barcodes in grid, device of some type at start that could even scan barcodes on cars, multiple devices in the bus if needed (tablet, or laptop) or a single device in the bus. Devices could take on one or more roles in the entire T&S process. You fragment as needed and the software handles it. If you are small, or don't have the funds, you could start with single device in the bus, with legacy timing hardware likely connected to one or more specialized interface devices and then grow from there. If you have the money, and the need, break it out by function if you define a T&S process that works better with multiple devices in the bus.

There is also the entire subject of AMB transponders and I also think some type of open transponder system that could break the AMB monopoly has legs as well. However I think I read somewhere that the real "lock" AMB has is on T&S integration at tracks.

If anyone is serious about taking this on, let me know as I potentially would like to help.

Richard

_________________
Richard Casto
1972 Porsche 914
2013 Honda Fit Sport
2015 Honda Fit EX
http://motorsport.zyyz.com
Money can't buy happiness, but somehow it's more comfortable to cry in a Porsche than a Kia.

Wanted to post this before I forgot the idea...

Drivers can buy an RFID based proximity card. It would be bound to a driver and as you register for an event you then are attached to a car/class. At start you could wave card at reader to register you with T&S for a given run. Those that have not bought a card would maybe have something printed on a barcode (attached to wrist?) that they would wave at the same reader. proximity card would be more convenient than bar code, so that would be the incentive to buy one. RFID card could also have barcode printed on it in case proximity reader fails.

Richard

_________________
Richard Casto
1972 Porsche 914
2013 Honda Fit Sport
2015 Honda Fit EX
http://motorsport.zyyz.com
Money can't buy happiness, but somehow it's more comfortable to cry in a Porsche than a Kia.

Where buy? How much? Other uses? How avoid two driver car drivers using the other guy's card accidentally?

SCCA for national events and apparently some other clubs use helmet barcodes BUT that won't work at events needing loaner helmets.

_________________
Dick Rasmussen

FS 50 2018 Mustang GT

So clearly more thought needs to be put into this, but a quick google search shows RFID cards can be bought for less than a dollar a card. I can't see other uses other than intra-club. If you wanted, they could become club ID cards with name and photo attached!

Regarding mix up, I would think that with the use of a lanyard, etc. that it should be rare (I don't give any of my IDs or RFID cards to others to use) but mixups can always happen including with any system in use today. And the same goes for explicit attempts to subvert.

Richard

_________________
Richard Casto
1972 Porsche 914
2013 Honda Fit Sport
2015 Honda Fit EX
http://motorsport.zyyz.com
Money can't buy happiness, but somehow it's more comfortable to cry in a Porsche than a Kia.

I think for Tarheel it's largely a solution looking for a problem. If we're going all networked system let the starter just punch the car number and class into some low cost Android device.

There's no reason that couldn't be an alternative to a myriad of options, including barcode reading, RFID scanning, etc. It's just another way to do the same thing.

But remember, even TH has problems where the driver forgets to put the "1" on since he/she is the second driver, etc. If you were scanning the driver's ID card, that wouldn't happen. And there's no reason why the same device couldn't also let you key it in for the case where the ID card is currently missing, too. *shrug*

The big reason to add things or at least architect with the ability to add things that Tar Heel might never use is simply so that you get more eyeballs and more help from the people that *do* want/need those features.

As for Richard's post, yes, that kind of thing is *exactly* what I was thinking. A distributed system where you don't really care what OS the client apps are running, they just speak the language. And they can listen to the stream and do things based on it. Those things could add to the stream or be kept to themselves depending on the situation.


--Donnie

_________________
My Blog