Software Scoring Machine

Discussion in 'Armory - Q&A' started by reawl, Aug 29, 2006.

  1. griffindm

    griffindm DE Bracket

    Joined:
    Sep 30, 2004
    Messages:
    595
    Likes Received:
    32
    Continuing to do a little basic research on the underlying causes of the problems here, I found a lot of discussion about the weaknesses of Windows and millisecond time control/reporting. It seems that standard Windows timing is done in ticks, which are about 55ms long under older Windows systems, and about 15ms under XP. There are some ways around this. I've included some links to relevant articles.

    High Performance Timing under Windows

    Obtaining Accurate Timestamps on Windows XP

    Inside Windows NT High Resolution Timers

    Dave G.
     
  2. brtech

    brtech Podium

    Joined:
    Nov 4, 2003
    Messages:
    2,424
    Likes Received:
    202
    Of course it may be best to just use a real time distribution of Linux to do this. You could make a self bootable, self loading CD that would load Linux and the app, perhaps not even needing a disk drive.

    It's hard to do millisecond accurate event determination with 15 ms ticks
     
  3. griffindm

    griffindm DE Bracket

    Joined:
    Sep 30, 2004
    Messages:
    595
    Likes Received:
    32
    I was thinking along the same lines. Burn a bootable CD, put the OS and the program on it. The only issue is with the differing configurations that may be encountered on individual laptops. Would they need a custom kernal to work? I haven't worked with linux in over three years, so I'm not current on what's possible.

    Will's current program is probably good enough for club use, but to get to a software config that can do FIE sabre/epee scoring, something running on a more realtime OS is probably required.
     
  4. jabalino

    jabalino Rookie

    Joined:
    Dec 7, 2006
    Messages:
    18
    Likes Received:
    1
    Accurate timing

    I ran into these timing issues when writing my software as well. Java implemented a call System.nanoTime() in Java 1.5. Perhaps C++ (if that is what you're using) has a similar, high-precision call as well. The bootable CD sounds like a pretty great idea as well, but this may save you some trouble. There are plenty of applications that need high-resolution timers and system calls, so there's bound to be a windows solution.

    BTW, one discussion we had at our club is the potential for systems like these to be connected to a central bout-committee. I had envisioned using those presenter-mice to do scoring and timing. Well, with a wireless connection, those results could be instantly relayed back to the bout committee. That could add up to significant savings over the course of the tournament.

    Anyway, I've found the link to the software that I wrote. This version is a little bit dated, but maybe some more ideas for you about incorporating the timers whatnot. I based the GUI off of one of the favero boxes. Probably you'll need the latest Java runtime (most computers will have it already) to make it work.

    http://www.mob.net/~jabalino/fencingbox/box.html
    or download the JAR directly (just like an EXE for Java)
    http://www.mob.net/~jabalino/fencingbox/FencingBox.jar

    G and Y are hits in epee, you can play with the keyboard to find the others.

    -Tom Pingel
     
  5. griffindm

    griffindm DE Bracket

    Joined:
    Sep 30, 2004
    Messages:
    595
    Likes Received:
    32
    Tom,

    I like what I see in your app. If you would like to start a separate thread to discuss development there I'd be glad to add to the mix. I am not sure it's best to take Will's thread OT without his agreement. Lots to like in the interface though.

    Dave G.
     
  6. reawl

    reawl Rookie

    Joined:
    Jan 30, 2003
    Messages:
    295
    Likes Received:
    19
    Feel free to keep your discussion here if you like (or move it, doesn't matter). My progress was because I was able to build on the parts others had created. I stake no claim to territory or anything along those lines.
     
  7. griffindm

    griffindm DE Bracket

    Joined:
    Sep 30, 2004
    Messages:
    595
    Likes Received:
    32
    Thanks Will. I think it would be more productive to keep the discussion on Tom's java app here, as it's ok with you. Both systems share common platforms (Tom's could be Mac compatible as well).

    In both systems (linux and Windows) remember that it's not the precision of the timer call (which can be down to nanoseconds) that is important. It's the minimum sampling interval that is crucial. I'm not sure how Java can get a more accurate sampling interval than the OS it is running on, unless it goes directly to the hardware timer, which I don't believe it does. Correct me if I'm wrong.

    I think it's important that a definitive answer on whether single or sub-millisecond interval precision is possible for either OS needs to be determined. Tom - do you have any examples of the "plenty of applications that need high-resolution timers and system calls" that you are talking about. I ask because it seems inconsistent with the limited research I have done.

    The NT call in my third URL may help in getting there, but I don't know if it's supported in Win32s for Windows 98.
     
  8. brtech

    brtech Podium

    Joined:
    Nov 4, 2003
    Messages:
    2,424
    Likes Received:
    202
    Let's keep in mind the REAL problem:

    The app is polling the parallel port registers looking for changes. When it sees the change, it tries to keep track of time between changes.

    The fundamental problem in non-real time operating systems is that you can't control when the poll occurs well enough, and specifically, the operating system may suspend the application doing the polling for long periods of time while it decides to do something else.

    In general, with Windows, you CAN'T get any real time control over the polling app. It's not designed to do that.

    The run-of-the-mill Linux kernel can't do it either, but there are real time kernels that let you control the scheduler to allow this kind of polling to be reliable.

    One of the reasons that this kind of application isn't done with parallel port hardware is this very reason: no real time control.

    The thing that will drive you nuts of course is that most of the time it will work. Every once in a while, it will screw up, and you won't be able to repeat the problem.
     
  9. griffindm

    griffindm DE Bracket

    Joined:
    Sep 30, 2004
    Messages:
    595
    Likes Received:
    32
    brtech,

    You are right that with either of those OS's you can't be absolutely sure that the system isn't preempted by another process, but the probability of that is somewhat controllable by the number of other processing running. I doubt someone is going to be running ten other apps as well as the scoring software.

    The real question is - is this going to be an FIE compliant system (app & OS) or just a club machine, i.e. close enough?

    If you want it to be FIE compliant, than a true real time OS is required. If so, can you find one that can boot an Intel/AMD system from either CD or floppy, and will it support the application development software?

    After the Xmas break I intend to run the system at my club with foil, as well as with epee again, maybe even sabre with the debounce settings HIGH (~ 15-30ms), just to see if that totally eliminates the false touches. If so, I think Will has a club scoring machine now, especially if he can simplify the hardware dongle with the suggestions you provided.

    The FIE version would still be an eventual goal I would think.
     
  10. jabalino

    jabalino Rookie

    Joined:
    Dec 7, 2006
    Messages:
    18
    Likes Received:
    1
    Timer resolutions

    Best explanation of the java timers I use is here: David Holmes' Weblog. The upshot is that the nanoTime function in Java has nanosecond precision and microsecond accuracy on most platforms, including Windows XP. Experimentally, I find that the results between events are pretty fine grained (at least 1 ms) when I use this timer. The old timer I used (which is what is used on the link I published earlier) used the old timer, and I did note that the values had much coarser resolution (~10ms). Or course I don't have another way of verifying those nanoTime comparisons for accuracy, but I consider it a good sign that I get an even distribution of integer values on very short durations (<40ms). Wish I could help translating this over to the C++, but I haven't done that in a long time. It may well be that whatever is monitoring those parallel signals is never going to have the resolution needed - that also is beyond my experience.

    brtech - is it possible to sketch and post just the foil configuration for the resistor setup that you suggested? Digital electronic design is not my forte, which I why I ended up following the keyboard path after getting pretty confused on my earliest serial port ideas.

    -Tom
     
  11. griffindm

    griffindm DE Bracket

    Joined:
    Sep 30, 2004
    Messages:
    595
    Likes Received:
    32
    Tom,

    Interesting. From reading the Holmes article, I assume you are using the call "Thread.sleep(Integer.MAX_VALUE)", which causes the VM to switch to a 1ms period for the duration of the sleep, even on WinNT based machines. Sweet. Will - I think that when this call is used on Windows NT/2K/XP it is using the NT call "NTSTATUS NtSetTimerResolution ()" that is referenced in my previous URL behind the scenes. Why not see if you can do the same thing?

    I like the interface on the Java app. Did you plan to allow the end user to adjust timings, as the FIE seems obsessed with fiddling with them? Ditto the light duration, and sound file source/volume, as was noted with Will's app.

    The other thing that is not really clear with your approach is the design of the adapter. I know you are using a USB keyboard work-around now. How would that translate into a working design that can interface with the standard reel setups? Would it be something that a professional would have to build, or could it be accessible to the homebrew novice?

    These are both great projects and I hope both move ahead to really nice finished products.

    Dave G.
     
  12. reawl

    reawl Rookie

    Joined:
    Jan 30, 2003
    Messages:
    295
    Likes Received:
    19
    Started Over

    I hated the code I had for my v.8 alpha release so I started over. I've separated the brains of the box from the display. The idea being that someone could write a different "face" that might be external lamps or who knows what. Everything is also now event driven, so it would be easy to write a client-server web app that would broadcast the lights. Another event is the "DebounceDone" event which sends a whole slew of data when someone's tip comes up (or in sabre, off the lame) so you can drop that in a database and answer all kinds of things like: How often do I hit off vs on-target? Am I usually locked out? Do I hit first? Is it usually a two light event?

    I've also created a "dongle simulator". Basically you press keys on your keyboard to simulate real fencing events (ie. F = Left hits valid, S = Left touches bell to lame, etc). When I use this software simulation of hardware, the main loop runs several thousand times per millisecond on my 1GHz Windows XP box with iTunes running. I think that is a reasonable amount of resolution despite not being real-time.

    The problem may be with Interrupt Request Times as griff pointed out. If they really are > 1ms then maybe there's a way to just open a pipe to the hardware and never close it so you don't have to interrupt each time you want to get/set signals? I have yet to hook up my hardware dongle and see what I can get that way, but it'll be the first thing I do once I've rewritten that chunk of code.

    I'm working to finish epee and sabre. When they're done I'll release the EXE and the source code (since I've also been doing a way better job of documenting my work as I go).

    No changes to the hardware... yet.

    Answering one question: It is not my intent to create anything the FIE would put their stamp on. There are too many ways to hack/cheat/whatever this type of system. This is intended to be a cheap alternative for clubs or even home use.

    PLEA: Anyone out there know how to make some USB hardware and a driver to go with it? I just need to send a byte and get a byte back, many, many times over.
     
  13. reawl

    reawl Rookie

    Joined:
    Jan 30, 2003
    Messages:
    295
    Likes Received:
    19
    Abandon Ship?

    So after reading up on hardware (some from the links posted here and a lot of research on my own), the conclusion that I've come to is this:
    • Peripherial Computer Hardware is not designed to send data back and forth continuously. It relies on the Interrupts that are several milliseconds apart
    • So to get the resolution desired, one would have to fill a buffer on the hardware peripherial, and then grab the results in chunks.
    • The result is a piece of hardware that is roughly as complicated and costly as a DIY stand-alone scoring machine
    So what I'm wondering is this: Is there anything that a PC version could really offer that a stand-alone box can't? All I can come up with is logging debounce times to a database, but the times aren't accurate to more than 15.25ms unless some fancy work is done.

    Unless someone can make a valid case for continuing this line of work, I'm planning to abandon the project and return my focus to the GPL Scoring Machine the folks at Eigertek released a while back.
     
  14. El Chucko

    El Chucko Rookie

    Joined:
    Feb 4, 2005
    Messages:
    425
    Likes Received:
    40
    Will, was this a problem before, when you weren't trying to go through the USB? I thought you had a program that worked fine, but the interface was just a bit "clumsy"?
     
  15. reawl

    reawl Rookie

    Joined:
    Jan 30, 2003
    Messages:
    295
    Likes Received:
    19
    http://en.wikipedia.org/wiki/Interrupt_request

    *sigh* there was a long post here, but the internet ate it.

    Basically every device, your hard drive, system clock, sound card, CD/DVD ROM, keyboard... they all have to put in an Interrupt Request (IRQ), to get time in the CPU. Once the CPU says, "Hey hard drive, you're up!" then the hard drive can dump data on the bus to the CPU for a window of time. Then the CPU picks someone new.

    The "speed" of a device is how fast it can transfer data from itself to the bus and back. USB is faster than parallel port, but both are subject to the IRQ process which as was shown can be 4+ms, which screws up fencing timing when you want to take samples several hundred times per millisecond.

    Devices get around this by having a local buffer. The devices are fast, the CPU is fast, the bus is the bottle neck. So the device does some work, sends it off every few milliseconds when the buffer fills up and continues on. To add a buffer to my hardware device would also mean adding a sense of timing, and at that point you've really got everything you need for a stand-alone box except for the lights and buzzer.
     
  16. jabalino

    jabalino Rookie

    Joined:
    Dec 7, 2006
    Messages:
    18
    Likes Received:
    1
    getting around the IRQ

    Well, does the hacked keyboard or other keyboard encoder get around this by having a buffer built in? I really don't have time to post much of a reply here now since I'm taking an exam, but the way I see it, the keyboard has a built in buffer and a matrix system that I used as input. If you take apart a keyboard, you have two (uh, right word here) "arrays" of input/output so that you form an array. Most matrices (combinations of the 2 arrays) are something like 9x12 (or whatever, plenty big). Let's suppose they are 2x4.

    1 2 3 4

    X

    Y

    So I wire the B line of one fencer to X and one B line to Y and the other 4 lines to 1,2,3 and 4. Then, when a connection is made (my epee depresses, and A and B connect), X touches 1 and I get a corresponding keystroke depending on my keyboard (they're all different). So now it apparently goes into the buffer (the crux: is it timestamped? It seems like it would be) and eventually my software can determine the right timings.

    Now, I ran into problems of keyboard masking with foil, since two connections are typically always on (the equivalent of holding down two keys on my keyboard permanently). As it turned out, when the blades were touching, no touch could be registered.

    I'd like to explain more, but I gotta go. Can you look into homebrew arcade controls/keyboard hacks and see if you think this looks like it avoids the IRQ, since the keyboard probably has a built in buffer? Or am I still going to get the 4ms delay?

    -Tom
     
  17. brtech

    brtech Podium

    Joined:
    Nov 4, 2003
    Messages:
    2,424
    Likes Received:
    202
    I suspect any attempt to do this kind of thing with software looking at wire state is doomed because of the non-real time nature of the OS. You need too much resolution than the system is designed to deliver.

    What you need to do is add some hardware, which may be part of a USB dongle you want to have. Perhaps something that has a running counter and a state change detector so you get ticks per state change, and some kind of 2 or 3 buffer arrangement. That's the kind of thing you do in a chip or the simplest possible microprocessor. Of course when you get to that, building the whole machine into the microprocessor is feasible.

    Let me see. I think you would want to use something like:
    http://www.cypress.com/portal/serve...D=209&PageID=259&fid=16&rpn=CY7C638xx&ref=pfm

    Digikey seems to normally not stock any of these, but has one variant that they have 1700 in stock at the moment for $2
    http://catalog.digikey.com/scripts/dksus.dll?Detail?name=CY7C63801-PXC-ND;keywords=CY7C63801-PXC

    This would get you everything you needed to have a USB interface. It has enough I/O pins, it has a USB interface. It has a microprocessor, with Flash memory, and the kind of counter you need to make the timing work right. It seems to need very few extra components, maybe only a capacitor or three. it comes in a DIP package, which is easy to deal with.

    Prototyping the actual interface wouldn't be hard. The problem would be that someone has to write code for it, and get that code into the Flash on the chip. Pretty simple coding problem, even in assembler. The normal development kit they have for these products is too expensive. Sometimes there is a code generator for the GNU C compiler for these kinds of parts, I haven't looked.

    You would also need a custom USB driver for Windows, probably not all that hard, but not something I've dealt with before.
     
  18. jabalino

    jabalino Rookie

    Joined:
    Dec 7, 2006
    Messages:
    18
    Likes Received:
    1
    Success with laptop software-based scoring machine

    So I've built a keyboard encoder-based software scoring box, and it seems to work very well in our trials so far. I'll post a link to the wiring diagram and software shortly, but here are the highlights.

    Java based software, so it is platform independent
    Easy to interface with various voice-control systems. We're having some very good results testing with the Jabra Jawbone device (cell phone hands free) which has some great auto-silencing and noise cancelling-features.
    Construction cost - about $35
    Utilizes a keyboard encoder to monitor connections (http://groovygamegear.com/webstore/...=76_80&zenid=976549b6f4b9a43fb460cd2bd426d425)
    testing in windows XP and pentium III laptop indicates timing is fine enough for foil debounce time
    actual testing indicates that the "feel" of the box is correct

    There are still a couple of small hurdles as I play with the hardware, but I'm fairly confident that these can be resolved. The conditions where strange things happen are relatively rare, so I'll be continuing to refine the software and hardware over time. I know there were a few people interested in this last year, so maybe people would be willing to give it a try.

    Right now the PS/2 version is working, but I want to buy a USB version of the keyboard encoder to see if the timing is good enough on it. USB seems to be a little slower according to the people who use these things to build arcade machines, but it may be good enough.

    Anyway, just a quick update. More to follow as I prepare some of the images and diagrams.

    -Tom
     
    the ancient one likes this.
  19. griffindm

    griffindm DE Bracket

    Joined:
    Sep 30, 2004
    Messages:
    595
    Likes Received:
    32
    Tom,

    Glad to see you haven't abandoned the project. The USB interface module looks real capable. I assume one could cobble together a small box to house the interface and hold the 2 3-pin floor cable jacks. Looks like an efficient low-cost solution, as long as the timing issues are resolved fully and the software allows easy modification to allow for future timing changes.

    Is the voice interface Bluetooth based? Do you use it to start/stop a timer for the bout? Cool stuff.

    Keep us posted on your progress.

    Dave G.
     
  20. griffindm

    griffindm DE Bracket

    Joined:
    Sep 30, 2004
    Messages:
    595
    Likes Received:
    32
    Tom,

    I just noticed that the specs on the USB modules give a speed of up to 125x per second. That gives only a 8ms response time. Any thoughts on that?

    Dave
     

Share This Page