Software Scoring Machine

[reawl]

*scratches chin* I like the use of the voice commands (though I wonder how it would work if you had two boxes being used or if the environment was noisy, maybe a bluetooth headset could solve those problems, but then we're talking more high end than my goals?)

I also found it interesting that you used an existing piece of hardware to solve this problem. I'm pretty certain that in order to make a three weapon "box" you have to provide some form of switch, be it a physical switch (by moving the floor cords, or by flipping a switch), or an electronically controlled switch to provide the resistance on the correct line.

I guess it's time for me to finish up my V1 and release it so I can get on to a V2.

[shlepzig]

Originally Posted by reawl

brtech, any chance you'd be willing to draw me a diagram? I'm willing to give it a shot, but I'm not quite wrapping my head around it. If you'd rather email it to me just shoot me a PM and I'll give you my address.

Multiplexer - Wikipedia, the free encyclopedia

This should give you a good introduction.

Shlep

[Angwilwileth]

Well I'm glad to know that you're continuing with this idea. If it works well enough, we could make electric fencing much more accessible.

[reawl]

http://softwarescoringmachine.rivercityfencing.net

I've got a Wiki up. At the moment there is a parts list, but no instructions or wiring diagram for the adapter. Should be up later tonight. Software is there for downloading. I'm looking for feedback.

EDIT: The wiring diagram and assembly instructions are up.

[griffindm]

Will,

I think this is a great project, one that could definitely help the fencing community.

I downloaded the executable and associated files today. Is there a reason why the app shows random scoring when the adapter is not hooked up? I just wanted to see the interface before I construct the adapter. This does not happen for the Foil setting, only Epee and Sabre. It may be my bios setting for my parallel port. I'll check it shortly.

Thanks,

Dave Griffin

[griffindm]

Yep. It turned out to be my bios setting for LP1. Had to change from ECP back to normal. I'll be constructing your dongle adapter in the coming week and I'll let you know how it goes.

Dave G.

[griffindm]

I plan to use an existing old parallel printer cable rather than construct one. I think a lot of us have such a beast in our collection of "things that work, but I'll never use again".

I'm still getting intermittent false signals on the sabre and epee settings. I just have the app running without inputs. Not sure why, but it may prove distressing in actual use.

Some suggestions on the interface:

Store the last setting for the port selected. Otherwise you have to keep going in to tell it your LP number each time it runs.

Make the interval duration for the display of lights and sound adjustable. Keep this setting saved as well. Volume of sound as well.

(for future versions) Adding a countdown clock in the middle of the screen, controllable by an [Enter] key selection for Start/Stop. Wireless presentation controllers are ubiquitous these days. No need to program in how to get the signal, just take an Enter from however it gets there.

I've simulated the dongle using a paper clip on the parallel port, and the basic responses seem good. I'm looking forward to building the interface as a Christmas break project with my 14 year old fencing son.

Thanks,

Dave G.

[reawl]

Thanks for taking an interest in this project (I was beginning to fear that the thread was going unnoticed). I too had the errant lights in Epee and Sabre while having nothing connected or even just the dongle, but the problem seemed to go away when weapons were connected. This makes me suspect that the random lights are caused by noise on the open port, and if it isn't that it is a much more complex issue with the timings of the program (not easy to debug). Let me know what you experience.

I should be able to get it to store the port setting without too much trouble (I thought I had it doing that already). I'll have a new release by Friday that includes that. I'll add the other features to my TODO list.

Any reason you want a vairiable buzzer/light timing? Rule book says 2 seconds so that's what I defaulted to. I have no problem adding it to the timings config page, just curious how people are going to use it is all.

Thanks,
Will

[oiuyt]

Originally Posted by reawl

Any reason you want a vairiable buzzer/light timing? Rule book says 2 seconds so that's what I defaulted to. I have no problem adding it to the timings config page, just curious how people are going to use it is all.

Presumably for the same reason(s) that one of the fencing machine manufacturers (Favero?) includes that functionality on their production machines -- because in club settings it can be useful to have it set to other amounts (almost immediately resetting can be very useful for a rapid multi-hit drill/lesson, etc.).

-B

[SJCFU#2]

And also it sometimes helps if the lights don't go out before the referee has completed their analysis (a common problem with beginners who are just starting to referee).

FWIW the two second maximum mentioned Appendix B applies to the audio signal only. The FIE requires a "superintendent of the apparatus" stand by the machine to monitor its operation and to reset the machine manually after the referee has given his decision (o.7).

[griffindm]

I think I may have located a more reasonably priced rotary switch that could do the job.
105-SR2921F-34S

Priced $4.08 for singles, $3.40 ea for 10. Has an extra position (4), but handles the 6 poles via two layers with 3 poles each.

I have not found a local distributer yet, but mouser.com says you can order direct.

Maybe an option if you decide to mass-produce the dongle.

Dave G.

[griffindm]

Originally Posted by oiuyt

Presumably for the same reason(s) that one of the fencing machine manufacturers (Favero?) includes that functionality on their production machines -- because in club settings it can be useful to have it set to other amounts (almost immediately resetting can be very useful for a rapid multi-hit drill/lesson, etc.).

-B

The LP club box has always had the variable reset timer. I've used them forever and just gotten used to the option. It was more the duration of the lights than the audio that I was looking for.

Dave

[jabalino]

Hey all. I'm going to test the parallel system that you've designed here soon, but here's an expansion on the keyboard scheme I was talking about. Many keyboards are hacked to form homebuilt arcade and flight simulator systems in the following way: Keyboard Emulator. As an alternative, you can buy adapters that are somewhat easier to wire (Ultimarc, the Ultimate in Arcade Controls.* and Hagstrom Electronics - Products - Keyboard Encoder Modules as examples). These are often pretty cheap and have the advantage of being USB (in some cases) which means they can be used on newer macs and pcs that don't come with parallel ports. One of the advantages I see to systems like these is that they can be used in home with cheap bungee-cord reel systems. My system was intended to be used for clubs as well, but frankly, I'm looking forward to just using it myself in a room with high ceilings. As far as selling it or whatever... I think a reasonable number of people would buy it, and some people would just make it, and you can just put up a paypal account for donations on the software or something (make it sharewhere so they are officially required to do it, even though you know they all won't).

I have been using a freeware version of GameCommander software (Tucows Downloads - Game Commander 2.0 Freeware Software or gamecommander.com) but it looks like the newer versions cost money. (As well they should, I guess, it's pretty good software.) It was a pretty cool way to emulate keyboard (and now mouse) commands for free, so since I had wired everything in to use keystrokes anyway (since I use a hacked up keyboard as well) it worked very well. This may not work so easily with the parallel port system, but it wouldn't be hard at all to include it in the software.

Again, I should have time soon to post my version of the software. I'm certainly not trying to compete with this system, but I've been working independently on this problem for a year (in spurts with a lot of downtime). I stopped when I couldn't think of a way to get foil to work without some glitches, but this new switched-based system could solve that problem. The software I wrote is in Java, so it's got the nice benefit of being easily translated to a Mac (though the C based stuff isn't that hard to convert either, I suppose).

-Tom

[griffindm]

Will,

I have cobbled together a version of your adapter, and have done some limited testing. I have also installed the software on a second laptop, and have some inconsistent results.

Foil seems to work well with both laptops (A Dell and an IBM, both running XP SP2) in simulated testing.

My testing with the adapter with epee (my primary weapon) so far has been frustrating. On my Dell Inspiron 8100 I am still getting frequent spurious valid touches scored when nothing is happening with the blades. As the epee circuit, like sabre, is normally open, this is consistent with what I am also getting when the adapter is not installed, where these touches appear in both sabre and epee.

On the IBM laptop, while foil looks okay so far, epee and sabre do not work at all, and show a consistent double valid touch for each side.

Both of the computers are set to a normal uni-directional parallel port. Is this what the software expects? The other options are for bi-directional or ECP.

When I lengthen the epee debounce time the false valid signal diminish and eventually disappear, around 5-7ms. This may be due to noise in the circuit.

In testing epee, the block out time seemed a little quick to my experience. I suspect that most commercial vendors use a blockout of 45ms, which is the middle of the allowable range. Also, the grounding light was always appearing on the right (green) side, even if it was the left side that was grounded.

I would suggest a mechanism in the software, for testing at least, to record detected conditions to a text file with an indicator of the detected condition and a time stamp. That way running the software unattended for testing in a null condition (normal closed circuit for foil, open for epee and sabre) would record a history of activity that might assist in debugging.

I'll keep messing with it during the week. I may do a foil demo at my club with it tomorrow night to give it some more realistic testing.

Regards,

Dave G.

[griffindm]

It looks like both of my "spurious valid touch" problems (epee and sabre) the Dell, and the constant valid touch problems (epee and sabre) on the IBM are both related to the debounce timings. When I increase these to 11ms, the problems all but disappear. The timings Will is using are on the bottom of the allowable ranges. I would suggest to change these to maximum debounce timings instead. The "noise" problems seem to vary by machine, and may make the parallel port an inferior choice for a competition grade machine, but it is plenty adequate for club scoring.

It may be worth looking at a USB option eventually to make the competition grade system, but I wouldn't let that problem deter you from completing development of the parallel port system for now, especially if the application could be configured to take alternate inputs in the future.

Jabalino - Could you offer any advice on handling the USB inputs, and whether they would be superior in the arena of noise on millisecond timings?

Regards,

Dave G.

[brtech]

I suspect your noise problems are because you don't have a reference for the signal.

The parallel port, like most digital ports, wants values between 0 and 2.4V, and something has to define the values at all times. What you have with an epee is an open circuit. Actually, you have the same problem with a depressed foil tip.

What you want to do is have a defined value at all times. The easiest way to do that is make one side of the switch ground, which is pins 18-25.

Then what you want to do is have something "pull" the input pins to a higher voltage when the switch is open (depressed in foil, at rest in epee), and do the same with the lame.

The easiest way to do that is to go to Radio Shack and by a 10 pack of 10K ohm resistors. Connect a resistor between one side of the switch and something that is always "high", that is 2.4V or greater. There isn't a 5V or 3.3V source on the parallel port, but you can use some of the unused data pins as long as you write ones to them in software. 10K is not a magic number, but it should be easy to find.

Now, when the switch is open (depressed foil, at rest epee), the input bits (you appear to be using Ack, Busy, Paper Out and Select) will read 1 and when the switch is closed (at rest foil, depressed epee), the input bits will read 0. This works because ground is solid zero (can't be budged), but the 10K ohm "pull up" resistor limits the current it can supply. When the logic 1 through the resistor meets the ground, the ground wins. With the switch open, the resistor pulls the voltage up.

You want to use separate 10K ohm resistors for each bit, because you don't want to have a closed switch on one weapon to affect the state of the other signals. In theory, if the output circuit supplied enough current, you could use one data bit to drive all the "high" levels (that would mean one side of all the resistors would be connected together and they would all connect to one data bit). I think it will be easier to wire using separate data bits. Just make sure every time you write the data bits that the ones you use for the "high" signal are written with a 1.

         
                   --------
  Output Bit  -----| 10 K |-----+----  Input Bit
   set to 1        --------     |
                                |
                                o /
                                 /   Switch
                                o
                                |
                               -----
                               \ \ \  Ground

With a voltmeter, you should be able to see the input pins (10, 11, 12, 13) swing between at least 2.4 V and 0 volts when you depress the switch.

Now that I'm looking at the wiring diagram, I think you can make this simpler, and use only one set of sockets.

On a foil, the tip is the B line. Connect that to ground on both sides.

Connect the C line on left to one of the input pins (Paper Out, S5, pin 12) and C Right to another (Busy, S7, Pin 11). Also use the resistor trick, connect a 10K resistor to D0 (pin 1), and connect the other side of the resistor to C Left. Do the same with another resistor on D1 (pin 2), and connect the other side of the second resistor to C right.

Okay, now set the data pins (D0-D7) to logic 1, high. They should be above 2.4 V. Connect a foil on left, depress the tip and verify that the S5, pin 12 is high. Let go of the tip and see that S5, pin 12 drops to 0 V. Check it with your code. You should see a 0 with the tip at rest, and a 1 with it depressed. Do the same with right, S7 should go from 0 to 1.

Now, wire up the A pins the same way. Use Error, S3 (pin 15) for left A with D2, pin 3 for the resistor, and Select, S4 (pin 13) for right A with D3, pin 4 for the resistor. You should be able to see Select (S4) high with everything at rest. If you touch left's tip to right's Lame, you should see it change from 2.4V to 0 (logic 1 to logic 0). S3, Error may be inverted. The voltage should be >2.4V with everything at rest, and 0V when Left tip touches Right's Lame, but you might see a logic 0 at rest and a logic 1 when the tip touches the lame.

Now plug in epees to the same socket. Look at S3 and S4. You should see them with >2.4V and you should read a logic 1 on S4 (S3 may be inverted). When you depress the tip, you should see the voltage go to zero and the logic state change. Also, if you look at S5 and S7, you will see the bell guard state, and again, it should be >2.4V at rest, and zero if the tip touches the bell when depressed.

Now plug in sabers. S4 should show the connection from Left blade to right Lame, and S3 should show the connection from Right blade to Left Lame.

Only one set of sockets required. No muxes required. This works because the tip is B on foil, so we can use one input for the blade and another for the lame. In epee, B is one side of the switch, and we can use the same pin we use for the lame in foil to read the tip state in epee and use the other side for the bell guard. In sabre, B and C are tied together (you will notice that S5 and S7 are always low with saber), and we use the A line for the lames as with foil.

Now, we have a problem with this set up, which you can verify in foil by noticing that you can get a valid hit on your own lame. The same would be true in saber. The reason is that both B lines are grounded, any anything that grounds the input will change its state. We can't tell the difference between left's tip and right's tip. This probably doesn't matter a whole lot in foil. Won't matter in epee either. I think it's more of a problem in saber (reach up and touch your own mask, point). Sweat through might also be a problem.

Fixing it would take more work. The hint is to use another pair of output bits instead of the actual ground on the B lines without resistors. If you drive these output bits to zero, they should be able to pull the input bits down. Then you can wave them up and down with software to determine which tip is connecting to whom. Probably best to use pins 16 and 17 for them (Initialize and Select Printer, C2/C3). Drive one low and the other high, read the status bits, then reverse and read them again, and you will be able to tell the state of all the connections. Remember, low wins. When in doubt, high is weak, low is strong. The logic outputs can "sink" more current than they can "source", and low sinks, high sources for this kind of logic.

[griffindm]

brtech,

It sounds like you are well versed in parallel port programming. I know just enough to be dangerous. I had been wondering if the system needed a powered reference to handle the open circuit. Especially in light of the tight debounce requirement for sabre (<= 1ms).

Will - I'm free to continue testing on any design/program changes you want to do. As I used an existing printer cable for my connections, and left the wires you do not use still attached, I can easily mod it to any changes in pin assignments you might need to do. From the length of brtech's post, I'm sure you could wrangle a proposed wiring diagram out of him using the resistors and a single pair of banana jacks.

I'm excited that the project is this far along. If Will can make this work it would be a great addition to the fencing community, at whatever reasonable price he would put on it. While the requirement to have a laptop/computer may seem to push the price into the realm of the current low-end machines, how many people do not have access to a Windows laptop for casual (read non-dedicated) use? And the ability to use low-end laptops, coupled with the potential to use the platform for other features (i.e. timing, score indicators, Fencing Time linking) in the future weigh in the product's favor.

Regards,

Dave G.

[brtech]

Software debounce

Yeah, since the source code is not posted, I don't know what he is doing about that.

Every mechanical switch "bounces". That means there is not a simple on/off. When it changes state, it often goes off/on/off for a while until the mechanics move far enough. Computers are fast, humans and mechanics are slow.

When you use software to look at mechanical switches, you "debounce" the switch. The usual way to do that is to ignore fast changes and average them out. You do that by "sampling" switch state at a fairly high rate, and integrate the results some. This also helps with noise.

I don't know what the effective sample rate (how often you look for switch state change) is. Ideally, it would be tens of microseconds, or as much as 200 microseconds max. You then ignore short "bursts" of state. say, on for 200 us, off for 400 us, on for 200 us, off for a while. That's noise. If, after, say 1 ms its really truly "on", then you decide it really is a state change, and go back to the first real "on" you found and make that the beginning of the event. If it never really goes "on", then ignore the noise.

Windows is not a real time OS, and you may not be able to sample this fast.

You have to do some amount of software debounce though.