Issue no. 8 - May 1994
Paper copies of the IOF High-Tech Group newsletter are circulated to all IOF member federations who will make copies available to members. Please contact your local federation for a paper copy. Note that this electronic version is still "hot from the press", and that the paper copy will reach your member federation about 15 June, depending on the various post offices.
A PostScript version of the newsletter (with figures) will be available via ftp from legba.ucd.ie shortly.
IOF High-Tech Group
Rolf Heinemann
Neundorfer Strasse 33
D-01257 Dresden
GERMANY
Tel. (+49) 351 223 8429
Fax. (+49) 351 498 1299
CompuServe: 100113,641
Finn Arildsen
1775 Milmont Dr. #E302
Milpitas CA 95035-3049
USA
Tel. (+1) 408 945 9140
Fax. (+1) 408 428 3622
Internet: finna@netcom.com
Hans Steinegger
Chriesimatt 23
CH-6340 Baar
SWITZERLAND
Tel. (+41) 42 31 93 53
Fax. (+41) 42 32 36 25
CompuServe: 100024.2730
Arthur Green
22 Swords St
Dublin 7
IRELAND
Tel. (+353) 1 386 093
Fax. (+353) 1 283 7077
Internet: arthur@cclana.ucd.ie
This issue's editorial has two main points: Result service at major IOF events, and the status of the newsletter.
Anyone who has attended a major orienteering event, such as a World Cup event or a World Championship, will readily accept that the organiser has an arduous task. Yet, on second thoughts, with so few competitors and only two or three different courses to plan, it could be considered as nothing more than the weekly training event for a local club.
However, there are some important requirements. To begin with, if IOF rules are to be followed, there is a list of "do's and don'ts", "musts and shalls", "cans and can'ts" etc. There are spectators to be con- sidered. The press of the world need to be supplied with up to the minute information, results, telephones, fax machines, and leaderboard times etc.
It takes a lot of time and effort to organise such an event. Fre- quently, organisers start from scratch, simply because the character of IOF events is so different to their usual events. Must "the wheel al- ways be reinvented"?
Is it possible for future organisers to use the same applications? To do some processes the same way, and save much repeated time and effort? Some important aspects such as maps and courses are unique to each and every event. Here, any idea of using similar methodology makes non- sense, but one might consider the benefits of common applications in other areas, such as the results service.
Many countries have realised the benefit of using a common results service for regional and national events. Even though these "solutions" are not usually applicable for IOF events because the requirements are different, the same arguments that lead to national solutions could be applied to find solutions for common applications at IOF events. Granted, different national conditions put a limit on the extent such common use is possible. Financial limitations also place a limit on the level of ambition that can be accommodated.
Nevertheless, the High-Tech Group is currently investigating the possi- bility of standardised solutions that could be provided for organisers of IOF events.
Such solutions could encompass standard software and/or "how to" knowledge about electronic results displays etc. Such an enterprise is not something that can be carried out by the High-Tech Group alone, but requires help from people in and around the orienteering World with useful experience. So, if you have ideas and/or experience, please come forward.
From time to time we receive letters from readers around the world asking
for back issues of the newsletter or asking for particular information.
We are very pleased to receive these letters, and we do our best to
provide the information asked for.
A recent letter from Alexander Kobzarev, chairman of the computer committee in the Russian Orienteering Federation, made us reflect a little bit about what we are doing.
The letter asked for permission to translate the newsletter into Russian for the benefit of native Russian speaking orienteers. So, we asked ourselves, how many readers does the newsletter have, and how broad is our reader group?
However, the manner in which the newsletter is being distributed does not directly allow us to trace how large a reader group the newsletter has, or how widely it is being distributed.
The publication of the newsletter is now in its fifth year, and it would be useful to reconsider its form and contents. Therefore, we would like to invite comments and suggestions from all readers, near and far. Let us know how you got your copy and/or what you think about the contents.
Should the newsletter continue in its current form, or is it time for a revision?
Last but not least, yet another newsletter with interesting articles written by orienteers with topical information has been collected. We are in the lucky position that the job of persuading authors to write in the newsletter is an easy one. Thank you for always being so forth- coming.
Hans Bengtsson, USA
Gunilla Wickenberg, SWE
At a World Championship - spectators, media representatives and participants - all expect the result service to be very quick and accurate. Everybody present, taking part in the event, want to be served with information about current position and chances for a competitor who passes a radio control in forest, or who approaches and passes the finish line. In planning for the WOC-93 in US the organisers were looking for existing programs to aid this task.
Figure 1: TUPP Overview
The Elite Support of the Swedish O-Ringen system contained promising
features in this respect, and members of IBM-Klubben in Stockholm ac-
cepted the job to make necessary changes and enhancements, a development
which has resulted in the current TUPP program package. (TUPP is an
acronym for the Swedish "Tdvlings UPPfvljningssystem" approximately
meaning: "the Meet Execution Program", in case you were wondering).
Key features of the TUPP package
TUPP was built to meet the requirements of accuracy and timeliness in results reporting at major orienteering events. See figure 1 for a logical overview of the system. Event data for a specific competitor is stored in one place - the TUPP "database" - located in a Local Area Network (LAN) server , and is immediately available to everybody at workstations connected to the network. The database is actually a collection of DataFlex* files, and a package of DataFlex programs gives the functions for data entry and retrieval. The programs are organised under a menu system so that the user can navigate his/her way to the required function. A couple of programs, written in the programming language "C", were added for support of the electronic timer, the Regnly RTR2 .
A central feature is the Announcer support. The announcer has an impor- tant role in serving the spectators with current information about the competitors finishing, for this task the electronic timer is necessary to eliminate delays in finish time access. Also, it is for the Announcer Support that split control passage information radioed from the forest is entered into the system as well as information sent from a checkpoint a few minutes before the finish.
The heart in the Announcer Support is the Current Results Program. The purpose of this is to display current event information in a way useful for the announcer. Figure 2 shows an example of an output screen - in this case the situation at finish at 10.13.34 during the Short Distance Final in WOC-93.
The upper part of the screen shows the currently best eleven results in the class, you can scroll forward to show subsequent results. The lower part shows a list of the runners reported to approach the finish. When a runner passes the reporting check point, the system calculates an expected result for him, assuming he makes the rest to finish as fast as the leader in the class, and shows how this relates to the leader's re- sult (the "Diff" column). The screen is updated every second. The "Rem" column continuously shows the time the runner still may spend to reach the projected result. When all is spent - he did not run as fast as the leader - the "Diff" time starts to count.
A close to zero or negative value in the "Diff" column indicates that the runner has a chance to take the lead, which is the case for No 626 in the example. Interesting information for the spectators!
When the runner passes the finish line and his result gets registered, the time info is replaced with values based on the actual finish time and freezes, two asterisks to the right show that the runner finished. (The line disappears after some seconds.) Also, his result will appear in the right place in the result list. In our case No 624 has finished with a result 3m52s after the current leader, which result did not place him on the first screen of the result list.
With help of function keys you may select what to show - current posi- tions at a split control or for another class, detailed current info for a specified runner, etc. A special feature is the +/- key F8. This initiates the +/- "tendency" column (to the right in figure 2) which displays gain/loss to the leader during the latest split. The feature has perhaps a more obvious value for one of a number of split controls.
Figure 2. Example of the "Current Results" screen. Data is from the Short Distance Final at WOC-93
Of course TUPP contains all the "normal" result services, which w.h.o. the RTR2 and the LAN are just somewhat faster and more automated than in less sophisticated setups. E.g. when the runner has finished, practically immediately result board data are put on a queue and printed (by a background program if running under OS/2). Corrections, entering DNFs/DSQs etc. are made on panels designed for the purpose, and can be made from more than one workstation (on the same time).
TUPP can be used as a standalone or "one room LAN" system, with or without the RTR2, to perform Secretary Services alone. The setup for WOC-93, though, illustrates how TUPP can be successfully utilised in- cluding support for the announcer and press/media representatives.
A configuration of 14 IBM PS/2's (on loan from IBM US) was used. The PS/2:s were connected through an IBM Token Ring LAN running at 4Mbps. Four of the PS/2:s were model P70, the rest M55SX (all these contain 386 processors). One of the P70:s was set up as Primary Server, a second as Reserve Server (normally working as requester but prepared so that a fast switch could be made in case the Primary failed). The servers, equipped with 12MB memory, worked under IBM OS/2 2.0 with IBM LAN Server ver. 3.0. The M55:s were running DOS 5.0, while OS/2 2.0 was installed on the remaining two P70 giving the possibility of multitasking for these. The IBM LAN Requester for DOS or OS/2 respectively was installed on all workstations.
The DataFlex runtime environment for OS/2 and DOS and the TUPP database and programs were installed on the servers only.
The PS/2's were set up in four locations, each one becoming a LAN hub with a MAU (MultiAccess Unit) which the local PS/2's plugged into. Three of the locations were placed in trailers, the fourth was in the large tent servicing the Press/Media people. Cable length between extreme work stations measured 600', plus some local cabling. The trailers were of the type used at construction sites and served us very well; eve- rything stayed high, dry and out of any wind. Also much of the cabling could stay unchanged while changing venues.
Secretariat Services use two of the trailers. The Servers were located in the first trailer together with two workstations for results verification and correction tasks. The main Regnly RTR2 (there were more than one for backup) was connected via a 1200 baud serial port to the Primary Server. At the Short Distance Finals a separate RTR2 was timing the runners in the second finish lane for the B/C finals. This one was connected to the Reserve Server, still the data was entered into the da- tabase in the Primary Server.
The Results crew received control card batches from the Finish, and verified a matching bib# between each card and the accompanying Regnly batch slip. This was done on the Batch Verification WS. In the meantime, the card punches got checked on light tables. The Corrections WS was set up to be used for entering Non Starters, DNFs, DSQs etc., but with the light work load at the Batch Verification station, any changes were done there.
The Reserve Server had a printer connected, allowing us to provide excel- lent results printout service to the radio crews reporting live to Scandinavia right outside our door. Final results also got printed here. The crew responsible for the Result Board used the second trailer, in which two workstations with printers were installed. Finish and Split results got instantly calculated and printed onto labels. The pre- prepared board was pulled and the result hand lettered onto the board. The label itself was stuck to the back of the board so the posters could easily see the posted results from the back side. The posting took less than two minutes. Since results were printed unverified, correction labels with special markings could appear, but usually so quickly that the original result could be stopped before being posted. These replacements were actually rare: six or less during the entire four days of competition.
The third trailer - placed well in advance of the Finish Line - was pri- marily intended for the Public Announcer team, but also housed the Split Time registrators, receiving radioed bib numbers and passages times. The Split Time registrators made use of three workstations, while the P/A made use of two; one by each of the two Announcer assistants.
In the Press tent two workstations were dedicated to show the Current Results Program display. One screen displayed splits and the other finish results, both in a rolling fashion, i.e. every 15 seconds the screen automatically switched over to the next result/class. A third station could service requests for particular results, including hard copies.
A unique setup was employed at the Sebago Lake site, where the Media telephones and faxes were located in a building some 500 meters away. The rolling finish results screen got transmitted every 3 seconds over telephone wires via a Short Haul Modem at a rate of 38400 baud to a display computer in the building, thus showing the same picture here as was shown at the connecting computer in the press tent.
For a system like TUPP there are always a number of requests appearing in the last minute, in this case to adapt to late setup decisions. A lot of changes like support of more than one clock and automatic scroll were added the week before the event. Nevertheless, TUPP functioned as well as any expectations with only one glitch, which locked up the Current Results display service for some 4-5 minutes out of a total running time of about 30 hours.
DataFlex programs are somewhat resource consuming, on the other hand the programs are easy to change and the same compiled program runs under the DataFlex RE in both OS/2 and DOS.
The Token Ring LAN proved to be totally reliable in spite of all kinds of
weather: sunny/hot/humid, monsoon rains, heavy frost (lower 20's). It
also took the abuse of rearranging work stations while active.
TUPP is licensed to the Swedish Orienteering Federation (SOFT) and is therefore not generally available, but permission to use it may be obtained upon inquiry - possibly license questions regarding DataFlex have to be solved. In Sweden TUPP is considered for use at e.g. Swedish Championships and further developments to adapt to new types of equipment will probably be done.
For more information about TUPP please contact Gunilla Wickenberg at:
Address: Barrstigen 30, S-18162 Lidingv, Sweden. Internet:
gunillaw@vnet.ibm.com
Stephan Krdmer, GER
In IOF High-Tech Group Newsletter Issue No. 7 - October 1993 was asked whether it might be possible to find computer software for O-events that fits to the needs of most O-clubs. Two alternatives were postulated as an answer: Either the organisers will change the programming, or the software will change the organising.
This article presents 3 software packages, which claim to be universally
usable.
The user interface of all packages is identical. The programs differ only by the specific needs of each event type. First of all I like to describe the functionality of the package OLEinzel. MTageOL and OLStaffel have specific differences, which will be discussed later. In the end I'll give you some information about the newest version, which is presently under development.
The software runs on every personal computer with MSDOS 3.1 and newer. A minimum of 384KB working space is needed. You can use any printer, Epson-compatibles are preferred. In the current version 5.2, the software is (only) in German language.
The limits are 9999 runners, 9999 clubs, and 9999 categories. With MTageOL you can manage 2 to 6 days. With OLStaffel you can define 2 up to 10 runners per team.
The software has been developed using Turbo Pascal 5.0 and higher, resp. Borland Pascal 7.0. The menu-driven, window based user interface is easy to use. By using key-indexed data storage methods, fast working and data integrity are granted, even with large competitions.
In the beginning, you have to define some basic topics. These are
You can key in the entries club by club, just as you receive them by mail. In this way, you are up to date at any time. Corrections and supplements can be entered at any time. Information can be retrieved in numerous manners. For example, you can account the starting fees, or print address labels.
You can define the controls and the courses. Each control may be keyed in only once. Depending on these information, you can print the control descriptions for each category and course. Currently only text de- scriptions are possible. With the new version, you will be able to use the IOF-symbols also. Numerous summaries give valuable support to the course setter. For example, you can get accounts on how much runners meet a specific control, or have the same course. This integration of entry and course information is one of the most significant benefits of organising O-events with the computer.
As usual, the start list for a single category is being determined by the
specification of the range of start numbers, the first starting time, and
the starting interval. To grant a fair competition, it is also important
to avoid starting two runners from different categories with the same
course at the same time.
The start organisation can be defined manually. you can also let
OLEinzel do the job for you automatically. The starting times and the
start numbers are determined by a random number generator. The draw can
be changed manually.
One of the most important principles I experienced in organising O-events (also important in other sports like Nordic skiing) is to separate time taking and result giving at different locations with different persons. With OLEinzel you can realise this principle, gaining a high level of flexibility. As usual, you have two choices: taking the finish times manually or automatically.
The incoming finish times and start numbers are notified manually. The finish protocols will be checked and then be keyed in manually in OLEinzel.
In this case, you have a separate computer system for time taking. It stores the finish times given by a finish time recorder or by the com- puter's own clock. Then you have to supplement the correct start num- bers. By pre-defined intervals you can transfer the data from the time taking system to the OLEinzel system off-line by using a software inter- face.
By this way, any time recording system can be used.
Depending upon your choice, you can print the result bills immediately, or print intermediate result listings at any time. Using the printer spooler delivered with the package, you don't have to wait for printout completion.
The results can be listed by numerous selections and sort orders. Short listings for press information can also be given. Using a software interface, the runners' data can be transferred for further use by an additional software. In Germany, for example, the interface is used to calculate the federal rank list. Another idea is printing diplomas by a DTP-software.
Compared with organising a single day event, there are a few differences concerning the layout of start and result listings. However, the most important difference is the manner of how to draw up the start list.
At a single day event, the start numbers will usually be distributed to the runners according to the start order in each category. This makes no sense at a multi day event, because you don't have the same start order on each stage. Thus it is better to distribute the start numbers club by club. In addition to the normal start time drawing by categories, it is possible to give the members of the same club start times within a pre- defined period.
When you have completed the result of the last but one stage (that is, exactly at the moment you have entered the finish time of the last incoming runner) you can print start listings for the chase start on the last day.
Organising relays is basically different to individual events. In organ- ising relays by means of the computer, you will get a great benefit even at relatively small events. Think about calculating the running times for the individual runners. A common source of mistakes is distributing the course combinations.
OLStaffel integrates entry management and course setting, thus avoiding doing wrong by well-designed checks.
In addition to event and category data, you have to define the number of runners for each category. 2 to 10 runners are possible, varying among the categories.
Entries will be keyed in club by club, as you receive them by mail. At this moment, you have to enter the category of each team only.
You can manage controls and courses. You can define branches based on the common methods Vdnnds, Farsta, and Motala. A single category can have several courses, which may be branched by different methods (as used at the Tiomila, or the Germany-Cup).
Having casted the start numbers, you can distribute the course combina- tions among the teams.
Each course can have 10 branches with 10 controls each as a maximum. The length of each complete course combination is calculated automatically.
You can define a start time for each category. The start numbers can be drawn manually as well as automatically.
At the near end of the competition, you can define a mass start for the waiting runners. The running times will also be calculated correctly in this case.
As I mentioned above, I am working hard on the new version 7.0 of all three packages at the moment. A lot of hints given by the users will be included there again.
As Windows would not add any benefits, the new version will also run un- der MSDOS.
Nevertheless, if the software is further accepted like in recent years, I'll also develop a Windows version.
Below you see a list of the most important new topics in version 7.0:
The current software is delivered on disk with tutorial datasets, and a manual on disk. The user license depends on the club, so you should tell me the club name on ordering. It is available only in German. The prices are: OLEinzel V.5.2. DM 220.- OLStaffel V.5.2. DM 220.- MTageOL V.5.2. DM 420.- plus tax and transport fee.
For further information contact: Stephan Krdmer, Brinkmannstr. 21, D- 95666 Mitterteich, Germany, Tel. (+49) 9633/4450, Fax (+49) 9633/4305. Compuserve: 100120,2657
(reduced by the editor)
Vladimir Mikan, TCH
Digital pocket-size clock for orienteering is produced in Czech Republic for three years. This clock Type 107 is also available in some orienteering shops in England, France, Germany and was also sold to other countries.
The clock is used not only for orienteering races and training, but also for ski orienteering, cross country skiing, mountain bikes events etc. It is small, easy to use and reliable. The price is very reasonable, lower than other similar products.
Operation is very easy. Before an important race install a new 9V bat- tery. After starting the clock seconds setting can be synchronised with real time. The sound signal every minute is now on, but the display will still show time "000". After the first start of runners with starting time "000" a "MIN" switch will activate the minute display.
Only a self-exitating piezoelectric warning indicators can be used for pre-start, not a common electrodynamic transducer. A piezoelectric warning indicator with 30 m line comes with the clock.
A pre-starting clock can be connected, current is max. 1A and voltage max. 30V. The manufacturer is currently developing a digital pre- starting clock.
Minutes set-up is performed by means of a micro switch button. Minutes setting can be reset. Minutes set-up does not affect the seconds setting.
START CLOCK TYPE 107 combines easy operation, small dimension, reliability, low price in one economic design.
These start clock have been used for three years in many orienteering countries. For further information contact: Ing. Vladimir Mikan Pratel- stvi 396 506 01 JICIN, Czech Republic, Fax: +42 433 32353
Hans Steinegger SUI
The map drawing program OCAD comes in a new version for Windows. New are the support of scanners, Bizier curves and programmable symbols.
OCAD has been transferred (or rather rewritten) to Windows. This elimi- nates a weak point of OCAD 4, the support of screen adapters and printers. All devices with a Windows driver are now supported.
As an alternative to digitizers, scanners may be used for entering the map. BMP files with any number of colours are accepted. The scanned im- age is displayed in the background of the screen. It is overwritten with a chessboard pattern of white dots in order to get a good distinction be- tween the background and the drawn objects. To compensate for inaccurate scanning the scanned image can be rotated. The scanned picture is zoomed together with the map which allows drawing in any magnification.
One of the advantages of working with a scanner is that the eyes can stay on the screen and do not have to change between the digitizer and the screen. Another is that you can easily see what objects have been drawn or not.
OCAD 5 does not provide automatic tracing.
Many mappers which are used to digitizers will continue using this method. Also here some improvements have been made. New is a smoothing level 0 for drawing in freehand mode. In this mode no points are moved. This was a request from users which have drawn very detailed maps. It is now possible to digitize in the 2X, 4X and 8X magnification. For the adjustment of the field work up to 12 adjustment points can be used.
Bezier curves are known from many illustration programs like Adobe Illu- strator. Instead of tracing a line with the mouse the direction on selected points on the line is dragged and the program then calculates a smooth curve between the points.
Drawing with Bezier curves requires some exercise to select the right points, but once the user has enough experience it's faster and gives better curves than the freehand mode. It is possible to use Bizier curves with the digitizer, but it is much easier to use them together with a scanner where you can see how well the curve matches the field work.
Fig. 1 The main screen of OCAD 5 for Windows
The main new part are the programmable symbols. All dimensions and colours of the symbols are now programmable.
Any point symbol can be created even consisting of different colours. All point symbols are rotatable. First the point symbol is drawn. Then all objects belonging to the symbol are selected and finally saved as a user defined point symbol.
23 different lines styles are available to define line symbols. These lines styles include all orienteering symbols (cliffs, fences, stonewalls etc.) and also include line styles for other maps like streets with a full line on one side and a dashed line on the other side. Dimensions and colours are programmable.
Styles for area symbols include dot and hatched patterns (including the
pattern for indistinct marshes). The angle of all patterns is programma-
ble like the dimensions and colours.
For texts all installed TrueType fonts may be used.
The programmable symbols are based on 32 colours. The appearance of these colours can be programmed independently for the screen and for the proof print.
Another feature are the colour separations. Up to 32 colour separations can be created. This allows the traditional 5-colour printing as well as 4-colour printing.
To reduce the printing costs often different maps are combined on the
same film. In OCAD 4 it was not possible to combine maps in different
orientation (e.g. portrait and landscape). This is now possible. In
addition maps with different symbols sizes or even completely different
symbols can be combined.
Another often missed feature in OCAD 4 was a possibility to make a
partial map out of a bigger map. Now a rectangular section of a map can
be extracted. All lines and areas are cut along the sides of the rec-
tangle.
The release of OCAD 5 is planned for end of March 1994. The price will be the same as for OCAD 4 Professional (480 Swiss Francs or about 340 US$). Special update prices apply for existing OCAD users. VISA and Mastercard are accepted. Demo disks will be available free of charge.
For more information contact: Hans Steinegger, Chriesimatt 23, CH-6340 Baar, Phone: +41 42 31 93 53, Fax: +41 42 32 36 25, Compuserve: 100024,2730
Fig. 2 Dialog to program the cliff symbol