Status of COMPMNGR's Judge's Handheld Marking Device System
This report contains four sections:
Summary
Description of test system
Observations
Where to go from here
You might also want to read the report on the second test, conducted at the Texas
Challenge, the report on the third test, conducted at the
Dance Houston competition, and the system user's manual.
COMPMNGR's handheld judge's marking system was used for the fourth time at the 2006 Sapphire DanceSport competition. I'd like to thank Antony and Connie Paley for allowing me to test the system.
Up until this competition I was of the opinion that the use of judge's hand held making devices, while "way cool" to watch, provides very little real benefit to the competition organizer. Two things are causing me to rethink that opinion. First, the system was much more reliable than in previous tests; apparently the main problem noted earlier was solved by a program modification made prior to this test. Second, in an informal poll I made of the judges after the competition there was a consensus that they preferred using the system to marking on paper since it made their job easier. Here is a list of advantages and disadvantages as I see them.
Their advantages are:
●They prevent judges from making some common
errors, such as marking an entrant twice or failing to recall the correct number
of entrants from a semi-final round.
●They may speed things up slightly under some
circumstances since runners are not required and the scrutineer doesn't have to
manually enter the marks into COMPMNGR.
●It makes the judge's job easier and
gives them more time to watch the dancers.
Their disadvantages are:
●The judges, scrutineers, and master
of ceremonies require some training. At least at this point in time, some
judges do not like computers, are inexperienced with them, and require extra
training. The marking devices are small and can be difficult to use for
judges with
poor eyesight or shaky hands.
●They may make it more difficult to handle last minute changes such as
scratches, write-ins, and judge substitutions.
●Even a marking system based on the
least expensive PDAs (personal digital assistants) having wireless networking
capabilities is expensive. (The PDAs used in the test system cost about $300
apiece.)
●Systems based on the least expensive
PDAs and networking systems are not currently 100% reliable so, for the
foreseeable future, will require the presence of a technician to monitor them.
I expect the disadvantages will diminish as judges, scrutineers, and masters of ceremony become more familiar with such systems and as the hardware becomes less expensive and more reliable.
As far as COMPMNGR's support for handheld judge's marking system, I have taken it about as far as I care to, although I will continue to support the software by making modifications as necessary. I will provide the software (a program which runs on Windows based personal digital assistants and a COMPMNGR interface to communicate with them) as an option to COMPMNGR users. I never intended to sell or rent the hardware for such systems, and certainly do not want to travel to competitions in order to provide setup or support services. It is my hope that some young, energetic, and highly computer literate scrutineers will be interested in doing that. So if you know of such persons please steer them to me; I'll be happy to work with them as long as I can do so while sitting in my office smoking a cigar. The following material is intended primarily for such interested parties.
The hardware
The test system hardware consisted of:
●An Averatec 3300 notebook computer running COMPMNGR under Windows XP
●A D-Link WBR-1310 wireless router, connected by wire to the computer, and
a Hawking Technology HSB2 signal booster set to provide a 500mW signal (about 10
time the usual signal strength)
●Nine HP iPAQ rx3115 PDAs running the handheld marker program under Microsoft® Windows
Mobile™ 2003 Second Edition software for Pocket PC
The software
As explained in the earlier test review articles, some years ago I provided COMPMNGR with an interface for a handheld marker system to be developed by another party. That marker system was never completed. The interface is very simple in concept. COMPMNGR writes a text file describing an upcoming heat (competitors, judges, dances, etc.) with the judge's marks set to 0 as place markers; these are called 'OUT' files since that is their file name extension. The separate marker system running concurrently with COMPMNGR on the scrutineer's computer has two tasks: (1) it reads OUT files and sends the information to the handheld markers, and (2) it receives marks from the handheld markers, inserts them into the OUT file, and when all marks are inserted renames the file with the same root name and the extension 'INP'. COMPMNGR imports the INP files into scoresheet records, tabulates placements, and posts the placements in its on-screen program.
The program running on the PDAs is called HandheldMarker (a .exe file) and was written using Microsoft's Embedded VC++. Along with HandheldMarker I wrote a program called MarkerServer to run concurrently with COMPMNGR on the scrutineer's computer to handle the OUT and INP files. When initial tests indicated that HandheldMarker and MarkerServer were working correctly, I integrated MarkerServer into COMPMNGR as a separate thread of execution (actually as a modeless dialog box).
Both MarkerServer and HandheldMarker use the WinSock API (the Windows implementation of the Unix sockets TCP/IP technology) to communicate over the network. In fact, I wrote a single program module, a C++ file incorporating a couple of C++ classes, to handle both the server task in MarkerServer and the client task in HandheldMarker.
For diagnostic purposes, in the previous test at Dance Houston and in this test, we attempted to keep all nine PDAs "connected" to the scrutineer's computer at all times, even when only a smaller number were actually being used for judging. To be precise, the MarkerServer module acting as server on the scrutineer's computer was in communication with the HandheldMarker program running as client on the PDAs. In the following, a "loss of connection" means the loss of communication between a PDA's HandheldMarker program and the scrutineer's MarkerServer module. In all cases of loss of connection, it was necessary to reboot the PDA before a connection could be reestablished.
Probably the most important observation in the previous test at Dance Houston was that, in many of the cases of lost connections, all or a majority of the nine PDAs lost their connection at about the same time. Further, the PDAs losing connection were ones that were not at the time being used for judging and so were inactive. It appeared that the inactive PDAs lost their connection about six to eight minutes after the connection was made. Following the previous test, a series of experiments confirmed that the PDAs almost always lost connection after about five minutes. I guess it is supposed to be a power saving feature, but there was nothing in the PDA documentation about it and there appears to be no way to disable it. So I modified COMPMNGR to periodically exchange an "Are you there?" signal with the PDA's. That seemed to work to keep them on-line, as was confirmed at the Sapphire DanceSport.
Although the system was much more reliable in the Sapphire DanceSport test than in previous tests, it was by no means 100% reliable. I believe that in most cases problems were caused by human error, for example, by a judge pressing the off button (turning the PDA off) or the record (voice recorder) button. In other cases it appeared that a judge tapped the wrong on-screen button and exited the program. In one case the wireless router was accidentally unplugged. In two cases COMPMNGR crashed for unknown reasons. It is clear that, for the foreseeable future, the presence of a technician will be required to support such systems.
I don't plan to make any major modifications in the HandheldMarker program or the MarkerServer module in COMPMNGR unless future testing indicates they are necessary.
I would prefer not to spend any more entire weekends testing the system at dance competitions. However at this point I plan to keep the nine PDA system for any further testing that might be required.
As I said in the summary, I don't intend to provide marking system hardware or support services. I am hoping others will do that. There are two ways a person interested in developing the hardware portion of a COMPMNGR compatible marking system could proceed. The first is to use the HandheldMarker program and the MarkerServer module I have developed. The second is to write his/her own programs to perform the functions handled by the HandheldMarker program and the MarkerServer module, namely handling the 'OUT' and 'INP' files required by the COMPMNGR interface. Obviously in either approach it will be necessary to acquire the hardware components. I would suggest starting small, say with only one PDA just in order to get the software working with the hardware. I will be happy to work with anyone developing a COMPMNGR compatible marking system, even to the point of providing relevant sections of my source code. Also, interested persons are welcome to work with me at any competition which allows me to use my test system.