As usual I am preparing this fine publication with much less time than I would like, so I apologise in advance for all the typos you are likely to see. However the printing quality should have improved since last time at least! That is what happens if you ask Staples to do your photocopying - so now you know why they are so cheap.

I must make an apology here. I was given an article for CP completely out of the blue by a nice young man at the BCRA conference a few months ago. I was impressed at anyone writing stuff without being badgered. This man is an example to us all. I put it in my in-tray ready for the next issue of CP and then moved house. Needless to say I couldn't find my in-tray when the time came to do the next issue (CP5), as most of my stuff was still in cardboard boxes, as I am going to move again soon. Then I found it (packed in my laser printer box) -hooray. However, another couple of months on, a new CP deadline looming, and it has bloody disappeared again. I have just spent over an hour searching through acres of cardboard boxes, cupboards, the loft, my desk etc., but my in-tray and the article remain resolutely unfindable. So, you will all have to wait another 3 months before receiving this particular gem of wisdom, and I apologise unreservedly to the author for being so crap. (As I assume you are reading this it might be a good idea to send me another copy, just to make sure that it eventually makes it into print).

Also, for those of you have sent me floppies in the last three months, hoping for software, I haven't forgotten the small pile on my desk. Survex copies have been delayed pending the latest (v0.60) release, and copying Mac software always takes me a while 'cos I haven't got a Mac. Rest assured that you will get something eventually.

Coming soon:

More research on how your gear affects your compass

The UK's big surveying projects - Easegill, OFD, and now Ogof Draenen

GPS in cave surveying.

SNIPPETS

Refurbished Suuntos & cheap new ones

Wookey

I have found a company which will refurbish your old knackered instruments for very reasonable amounts of money (especially in comparison to their initial cost). We had 6 compasses & clinos turned into effectively brand new ones for about 25 quid each! The usual deal is that the sealed central binnacle is replaced for this cost, but when they saw the state of our bodies they threw them away and gave us some second-hand bodies which were in much better nick.

The company is a distributor of Suunto instruments and thus they sell at trade prices. This is about half what you pay at your local caving shop. They seem wary of dealing with the 'public', but if there is interest then I could set up a trade account with them under the auspices of either my company or the Cave Radio & Surveying Group.

Please contact me if you would be interested in getting this going.

Newtons for Cave Surveys

Chris Illis <chris_illes@qm.claris.com>

Although Apple's version of the Newton isn't suited for Cave surveying, a company called Digital Ocean makes one that just might be. It runs the Newton OS and hardware for the most part.

It also is ruggedized (can withstand a 6 foot drop onto a hard surface), waterproof (doesn't say how waterproof), backlit (a major missing feature of the Newton), beefed up battery and has a wireless LAN transceiver. You can also put a GPS system inside (instead of the wireless LAN I believe).

All in all a WonderNewton called the Tarpon. Not bad at all but about $3,000+ fully loaded.

Now for all you rich cavers out there ;-)

Compass Points Index

The CREG index has now been updated, and also includes the first 6 issues of Compass Points, so if you missed any of those and want to know whether they contain anything of interest to you, then a copy of the Index is a good way to find out.

HTO developments

Significant developments are afoot with the Hierarchical Tagged Object survey data transfer and recording format proposed by Doug Dotson in 1993, and detailed in CP issue 2. It took people about a year to notice its existence, but now there is significant interest in the project, and after much discussion on the Cavers Digest Email forum a separate 'Surveying Mailing List' was set up by Olly Betts (see CP6). Currently its primary purpose is discussion of HTO.

A committee has now been formed to formalise the process of deciding things about the detail of the format. The members of this erstwhile body are Doug Dotson (Chairman), Wookey (Secretary), Garry Petrie, Olly Betts, John Fogarty, and David McKenzie. All these people have wide experience of surveying, computing and survey software. It is hoped that this process will produce a standard that works, is useful to both software authors and users, and which people will thus want to use. Anyone who has an opinion is encouraged to make their views known to the committee. By far the best way to do this is to join the surveying mailing list, but for those that can't I will pass on your comments. Note that if you do wish to say anything it is important that you read the spec first to understand what is happening. We have already spent a disproportionate amount of time dealing with misinformation from people who hadn't bothered to read it.

I had hoped to put an article in this issue summarising some of the areas of debate, but it looks like there isn't room. If anyone is interested in this subject (you sad bastards!) and wishes to read a copy of the Draft Spec, then please send me a letter or floppy (depending on what medium you want a response on). The document is currently in version 1.4 and is about 30 pages long, and available in MS Word, WP5, Postscript and Text (without the pretty pictures) formats.

LETTERS

Reading Suuntos and 'Eye Rivalry'

Tom Moss

France Susteric says: In my experience the Suunto compasses introduced an up till now unknown source of systematic errors. When pointing at the target, the angle difference between the left eye line and the compass line is negligible. But when reading the scale, most people unconsciously adjust the angle to the compass focal distance and turn it to the left what may amount to even 5 degrees.

It's been well proven (see various references in "Compass and Tape", the NSS survey/cartography section newsletter) that considerable error results from reading the Suunto and similar compasses with two eyes open. A minority of people can do this accurately; most people suffer from a syndrome that Roger Bartholomew terms "eye rivalry". In teaching the FCP instrument class, I did informal tests on about 30 students -- less than five could read two-eyed with any accuracy. We're talking errors of 4-5 degrees in many cases. Don't just take my word for it, try doing the same shot -- fore and backsight -- with two eyes, then with one eye.

To read this type of compass, do the following:

Make sure nothing magnetic is near the compass.
Close the other eye and sight above or below the compass, depending upon whether the to-station is higher or lower. You can easily see the target and the scale; if you have problems, light the compass from above. Hold it close to your eye to get a rough reading, then move it out 4-5 inches to get a reading to the nearest 0.25 degree. This last is especially important for people over 40 like me, who don't have as much depth-of-field!
The Suunto is not very accurate for high-angle shots (> 20 degrees), even with a light bar. Use a Brunton, or shoot a vertical to minimise vertical angles.
Placement of stations is very important when surveying with a Suunto. Place stations that the compass reader can get behind. A point on the wall causes positional error.
The compass has to be levelled in three dimensions, before reading. This ensures that the compass card doesn't bind within the case, and that the compass is actually pointing at the target:
The compass is level front-to-back when the compass card appears in the centre of the round viewport, with an equal space above and below it.
The compass is level side-to-side when the hairline is parallel to the lines on the scale. Well, you've got to have a compass correctly balanced for your latitude for that.
The compass is pointed at the target when the hairline appears in the centre of the view window from right to left, and the hairline is lined up with the target.

This is a tedious description, but the compass can be sighted pretty quickly once you get used to it.

Not everyone can read this type of compass. But then, if you can't read compass accurately sketchers are always in demand...

The Future of Cave Surveying - What next?

Wookey

Reading through this and other issues of CP you will see a lot of talk about computers and algorithms and software, but not so much about the actual nitty-gritty of surveying. Every quarter at about this time, I have cause to ponder this issue - Why is it so?

It seems to me that whilst the tools for survey data analysis and survey production have come on in leaps an bounds over the last 10 years, very little has happened at the coal-face end of the operation. Almost everything in Bryan Ellis's 'Cave Surveying' book, published in 1974 is still current, for example. The instruments and techniques seem to be static. Is this really so? Has no-one thought of better ways of doing things in this time? Are the techniques now so apt that there is just no incentive for change?

Think about it for a moment, and ask yourself which aspects of surveying could do with a good overhaul. The objectives have always been to produce an accurate and realistic map of the cave passages, possibly including other data such as sediment types, floor covering, air speed, water temp. Can the needs of cavers, scientists & surveyors be met to everyone's satisfaction by scruffy blokes with beards, muddy sheets of paper, dinky little aluminium blocks, and calls of Tape, Compass, Clino? Probably yes, for the moment, but perhaps not that much longer.

I think the drive for change will actually come from the computers used at the survey production end of the process. Ever since people realised that computers could do all those tedious sums to convert survey data into co-ordinates, the software (and hardware) has been catching up with the existing techniques. First you could just type in a leg and get back the rectangular co-ordinates, then the computer could do the plotting too, then it could do loop closure and spin the cave before your eyes. Now it can draw the walls in too, and the whole drawing process need never involve a piece of paper until final plot time. Blunder detection is coming, and so is being able to scan your notes into the survey software to be turned almost instantly into a finished plot.

The computer is slowly spreading throughout the whole process. How long before it is possible to have something small, light end cheap enough to do away with those muddy bits of paper, and impossible to read Suuntos? The Ruggedised Newton mentioned in this issue is a meaningful step in this direction, but the cost will be prohibitive for some time yet - at least another 5 years will pass before this is a remotely sensible option for most surveyors.

But this spreading computerisation also provides a more immediate pressure for change. As the capabilities of the software improve and rendered 3D graphics become standard on people's desktops (viz. the 'Pipedreams' OpenGL screensaver that comes with Windows NT) the survey software starts to run up against the limitations of the original data-gathering process. You can't have beautifully rendered caves if the surveyors didn't record the passage dimensions, and even if they did, unless there are plentiful cross-sections, and a longitudinal profile (at least), then all the passages are likely to be square (or octagonal, of circular). The potential is there for almost perfect imaging of your cave, but this needs an extraordinary increase in the amount of data gathered. How can this be done in a meaningful way, and so that it still takes a reasonable period of time. We are all aware just how long surveying takes with current techniques. Recording more data simply makes it take longer. There comes a point (fairly quickly in most scenarios), where the effort becomes disproportionate to the gain.

The need for the surveyor's holy grail of a handheld laser widget that costs 200 quid and records every crinkle of your cave as you wave it about can only become greater. As this seems unlikely to happen very soon, what can we do to increase the effectiveness, accuracy and veracity of our surveying?

Texas Speleological Survey's Technical Workshop

Bill Elliott

The Texas Speleological Survey's Technical Workshop was held on Nov. 12, 1994, at St. Edward's University in Austin. About 35 or 40 cavers attended and the meeting was considered a success even though we didn't have enough time to do everything we had planned!

Most of the workshop focused on cave surveying software. We were able to use a new In-Focus video projector to display the programs on a slide screen, thanks to Martha Meacham, Instructional Computing Co-ordinator at St. Edward's. This wonderful device made it possible for a roomful of cavers to see full colour at 640 x 480 pixels. This still was not high-enough resolution for David McKenzie's Walls program, which he displayed on a 17inch monitor. More on this amazing program below.

Doug Dotson flew in from Maryland to demo his SMAPS 5.2 and SMAPS/GIS programs. I've been using SMAPS for years but was glad to see SMAPS/GIS for the first time. SMAPS is rich in features and quite powerful, despite its lack of mouse control or Windows interface. Doug showed us some displays of Hamilton's Cave along with examples of GIS displays-- coloured areas of the cave containing water within a certain distance of an entrance, etc. The topographic overlay was impressive too. I showed the Powell's Cave System on SMAPS, and a slide-show pseudoanimation of Powell's that I did in 1989, using 56 screens that were captured with EGASLIDE. I also demonstrated the BIGCAVE demo in SURVEX, and all were impressed with the speed at which one can rotate, pan, and zoom on the cave line plot.

Don Broussard did a demo of CAPS, which he had bought a few months ago. The program looks like a decent first effort, but suffers from a somewhat clumsy interface. For instance, you cannot view all your raw survey data in a table-- you're limited to one screen per vector. The line plot disappears off the screen sometimes and you have to go hunting for it. With more user experience one could make the program fly, no doubt.

John Fogarty demonstrated CaveView 5.1, a recent update to his program, which is respected among surveyors of Mexican caves. The longest cave in Mexico, Sistema Purificacion (82 km), is on CaveView. This DOS program has mouse control and many sophisticated features. It has no print drivers of its own; graphics are sent to an HPGL file, which can then be printed by Ventura or various other programs. John is working on his Windows program, called CORE, but was not ready to demo it yet. He has ambitious plans to make it a electronic drafting program for cavers. That is, after processing the data you could scan your notes, then treat them as a "rubber sheet" bitmap that can be stretched, bent, and shaped to fit over the line plot. The resultant map would then be vectorized. Details such as breakdown, water, and sand, could be painted in with a mouse from clip art. For example, a bumpy flowstone symbol could be inserted simply as an arc, then the program would draw the bumps for you. I imagine that such a program could result in maps that are laid out better, because you could rearrange and re-letter. With inked maps you are stuck if you didn't plan carefully.

John gave an interesting talk about the real possibility that in a few years we could have hardened pen computers for sketching and processing data in the cave. Already there are pen computers with 80486 processors, lots of RAM, and big hard disks, but they're expensive. It's hard to believe, but 10 years ago I wouldn't have dreamed of the notebook computers that we now have (I bought my latest one at an auction for US$520).

We interspersed the workshop with discussions of GPS (global positioning systems), cave radios, and data loggers. Mark Johnston, the original instigator of this workshop, has been collecting information on GPS units. We are interested in the more affordable hand-held units, but they cannot achieve the degree of accuracy that we would like for detailed karst area surveys. Accuracy is limited to about 30 m or so. There are several error sources, the major one being "SA", or selective availability. This is an encryption of part of the timing and positioning signals from the 24 U.S. military satellites that are used for GPS. Since the Persian Gulf War the U.S. military has switched this encryption on and off to prevent its use by potential enemies. Anyway, this can be partially overcome by doing "differential correction" of the data. This is accomplished with a base station placed at a known location (benchmark), and a roving unit that takes data at other locations. The logged data are then downloaded to a computer and "postprocessed" to remove much of the variance. This can narrow the accuracy down to a few meters or even to one centimetre.

Trimble Navigation makes a new handheld unit, the Scoutmaster, with an RS-232 serial port on it, so it can be used for differential correction. The cost is US$995, but you would have to have a base station or similar arrangement. Some companies are now offering base station services. That is, they pay an FM radio station to broadcast base station signals, which can be picked up on a proprietary receiver over a wide area. You can have real-time differential correction this way and you pay different rates for different levels of accuracy. Some are doing this over small pagers, which can be plugged into some GPSs. One company offers a GPS in a PCMCIA format, which can be plugged into some notebook computers for real-time navigation.

Cavers at the workshop remarked that you can do just as well or better than a hand-held GPS if you have a good topographic map and a few landmarks. That's true, but sometimes you don't know where you are within 100 m, such as in Mexico. These devices make it easier to relocate something too. But I have to say that GPS will have to become more accurate and cheaper before I will buy one. There is some talk that the military will turn off SA. Mark Johnston will follow up with further postings on what he has found. He's starting a GPS database.

We demonstrated Keith Heuss' cave radio, which has a rugged transmitter weighing about 3 Kg. It puts out 10 W at 3,500 Hz. This can transmit through at least 30 m of rock. The loop antenna and receiver are used to pick up the signal via headphones. This radio was used to position the drilling of a well into a cave stream, and it came within 15 cm of the cave radio location. We are using this radio to set "cave radio benchmarks" at various locations in Powell's Cave to the surface.

I discussed my experiences building a temperature-sensing data logger for my long-term cave ecology studies. I used some devices from the Blue Earth Co. in Minnesota, with help from Bob Buecher and Keith Heuss. My three data loggers each took 6 channels of data for up to 60 days, but I had a lot of problems with erratic signals, either from bad sensors or deteriorating wires-- I'm still not sure. Some of the sensors were "dry bulbs" and some were "wet bulbs", but I also used humidity sensors in entrance areas, which were within the sensors' range of 0-95% RH. Data were downloaded to a PC and graphed using Excel. More compact dataloggers may be available and may be easier to program too.

The finale of the workshop was David McKenzie's Walls program for Windows, which he demonstrated on a 486 66 MHz computer with 32 Mb of RAM. David has concentrated so far on the data management and error analysis "front end" of the program and only recently put in the graphics feature. David used his algorithms that he developed for his master's thesis on surveying in 1979. These first appeared in Net3 and Net4 (the latter is available with CaveView). His approach to "data screening" or "blunder detection" is way ahead of any other cave survey program I have read about.

Walls has a data management window with hierarchical files, very nice for larger cave systems. He has followed the lead of Doug Dotson in using a hierarchical scheme. Different surveys can be moved around in the tree by dragging and dropping with the mouse. Each node is marked by a little survey book, which is red until it is processed, then it turns blue. Branches can even be moved around within a tree or between different project trees. The whole tree or just parts of it can be processed. It crunches data very fast (17 seconds for the entire 82 km of Sistema Purificacion). David hasn't even optimised for speed yet, so it could go faster.

Other windows pop up to tell you where the blunders are. Of course, the more loops there are, the better the blunder detection. Using the UVE (unit variance estimate), you browse through tables of statistics looking for F statistics that are >1. Each independent loop system has both a horizontal and a vertical UVE. Each traverse has UVEs and an F statistic. They can be ranked with the worst system at the top and you can interactively jump to a line plot of the cave that shows the loop system in blue and the highest-error vector in red. Really bad F statistics range from 10 to several thousand. You can "detach" a vector, or give it zero weight in the least squares correction of the loop system, then reprocess to see what happens. The program gives you suggested corrections to the vector. Currently the tolerances are set at 5% for distances and 5 degrees for azimuths and inclinations. One can use this to actually go back into the cave and resurvey bad vectors (if you marked your stations). Some of the audience suggested that the names of the survey team members could flash like a neon sign when bad vectors are found!

I used NET4 once to analyse the Entrance Maze survey of Powell's Cave. It found 4 blunders and suggested what the correct vectors should be. When I resurveyed those 4 vectors the suggested corrections were remarkably good. This worked well because there were 48 interlocking loop junctions. Most blunders come from misnamed stations, but some are from other incorrect data.

The name "Walls" came from David's old mainframe program in which he actually attached cave walls to a survey using a graphics (digitising) tablet. This feature may be added to the new program later. The program could adjust the walls when the survey data is adjusted.

John Fogarty and Doug Dotson were very complimentary of David McKenzie's program. The three had discussions about collaborating on a set of Windows programs that could work together. Walls could be the front end, Fogarty's could be the drafting portion, and Dotson's SMAPS/GIS for Windows could work with the other two to provide GIS features. They were happily discussing the HTO spec that evening at dinner and agreed to collaborate on that too.

We are very sorry that we ran out of time and were not able to demo Compass, Karst256, CavePlot, and Vectors. My apologies to Garry Petrie and Dave Herron, who mailed me examples of their programs. Demo versions will be distributed to interested surveyors in this area to evaluate. We could have spent another DAY on survey programs. There was no Macintosh readily available in time to show CavePlot and Mel Park's Vectors, which Paul Fambro discussed. We also wanted to discuss Internet communications and how to get on the Cavers Digest, but that may be done in another workshop later.

The TSS plans to post the completed feature lists for all the cave surveying programs. These came from a questionnaire that I posted earlier, and most were filled out by the programmers themselves. Many thanks to all those who sent information or who participated in the workshop. Real good!

DIY Suunto lighting

Wookey

Daniel Gebauer and Bob Buecher have both suggested ways of adding your own electric lighting to Suunto Compasses & Clinos. Having been disappointed with the performance of the authentic Suunto-supplied lighted instruments under expo conditions I decided to try out a version of Daniel's suggestion as it seemed simple, and didn't involve drilling any holes in my recently-fettled instruments. New lights were needed because we had sent our compasses back for refurbishment (see above) and a couple that had previously had holes for the official Suunto lithium lights came back with older bodies which did not have this hole. The problem with the standard lithium lights is simply that they aren't completely waterproof so you get problems with the battery contact getting dodgy until no amount of twiddling and swearing will get you any light. Also the way the button is mounted on the side means that it tends to get turned on in your pocket as you cave, flattening the (very expensive) batteries. Finally, because they aren't fixed in place they tend to get twisted round so they aren't properly illuminating the scale.

I reckoned that something which was a cross between the surface mount LED mentioned by Bob, and the simple gunged-on battery & switch of Daniel's suggestion would be at least as good, and ought to be better. After looking through Farnell's catalogue for a bit I found some tiny surface mount LEDs (SOT-23 package) which looked much better than the usual sort - no metal worth mentioning to be magnetic, and an effective way of getting 'round the corner' to shine down onto the scale. These were available in yellow, green & red, all at the same efficiency (1mcd @ 10mA). I picked yellow as the most like normal light, hoping this would give the best readability.

There was a huge range of miniature and subminiature sealed momentary action push-button switches to choose from. all with at least IP65 rating, and several being designed to be flow-soldering or immersion cleaning -proof. There is also a fairly wide selection of lithium manganese (coin), and mercury & silver oxide (button) cells available. Most of these bits were very cheap so I bought a selection, and then experimented, eventually building 3 different light designs to go off to Austria for trials.

The basic design looks like this:

and the idea was that the whole would be covered by the rubber boot that can be bought as extra for these instruments. The LEDs were excellent, very cheap, very bright, and straightforward (if a little fiddly) to mount on a little cantilever arm of vero board. The main thing that decided which of the other components to use was size. There isn't much space on the end of a Suunto, and if you want to stretch a rubber boot over it nothing can stick up too far. The lithium cells tend to be thin but wide, whilst the others are small but deep. The lithium cells are 3V, whilst the others are about 1.5V so you need two to light the LED. Only the lithium cells are available with PCB mounting tags, and soldering direct to batteries is not good for them. (A couple of mine bubbled nicely during the construction although they still seem to work). Silver Oxide cells can be obtained for about a quarter of the price of lithium ones, so this makes your light twice as cheap to run.

For fitting the batteries I used a piece of bike inner tube to insulate them from the instrument body. Insulating tape would be thinner, but the rubber boot pushes very hard, and I felt that the soldered connections to the batteries or the vero could cut through it. The lithium cell with pcb mounting tabs was put on a bigger bit of vero, along with the LED, but this removed its height advantage over the silver oxide cells. Its diameter also meant that when the rubber boot is fitted, it tries quite hard to push the cell out towards the compass dial. I generally found that mounting one small silver oxide cell either side of the LED vero was the neatest construction.

When fitting the switches I initially hoped that the spring would be stiff enough to use the button through the boot so that they could be completely sealed away from harm underneath. This was not the case. Most would just be permanently on as soon as the boot was fitted, a couple would resist until clicked on, but would not go off again. The only answer was to have a small hole for the switch to stick through. This meant that only those designs where the whole front of the body did not move as part of the switch mechanism were any use. I had a couple of rather nice membrane switches but these were precluded from use because they were designed for panel mounting so their legs stuck out of the back and were too stiff to just bend out sideways usefully. The best switches proved to be the smallest - a surface mount one 4mm square, and a PCB mount version of the same thing (B3W series) (6mm square, and about 4mm high). These had legs that came out of the sides so they could be bent out horizontally and did not need insulating from the compass body. They had a small round button mounted in the square body, and cutting a hole just bigger than this in the boot meant that the thickness of the boot rubber protected the switch from accidental operation, and the body was still held securely.

Having 'weeded in' the most likely-looking components I constructed 4 lights of three designs. One with a lithium cell, two with a pair of silver oxides, one with a pair of mercury cells, and using 2 similar switches. The whole assembly was gunged into place with clear silicone sealant, then the rubber boot pulled over the whole, carefully ensuring that the LED and switch remain exactly positioned. This bulge means that the boot does not now seal around the binnacle so more silicone gunge is put in keep the caving crud out.

One difficult decision is whether to put gunge between the LED and the top of the binnacle (there is a small gap of maybe 2mm here). I decided not to as I felt that it would reduce the lighting level, and more importantly would make it hard to use an external light to illuminate the instrument in the case of built-in light failure (quite likely for caver-built version 0.1 stuff).

One aspect of this that I have barely touched on thus far is magnetism. The LED and switch are no problem at all, and obviously you can do what you like with clino's too. But batteries and compasses requires some care. I spent a long time waving cells around a compass lying on the table and found that all the cells affected it a bit if you got them close enough. However the effect was generally less than a degree, and you only had to move the cell about 5mm further away for the effect to reduce beyond detectabilty. I believe that any induced error will not be linear - it will depend on the relative orientation of the cell and the earth's field. However I could be wrong, and obviously if it does simply give an offset then this can be easily allowed for. Because of this, and because we already had two illuminated compasses - one brand new tritium & a fairly new Suunto lithium - I modified 4 clinos and left the compasses for later. However I reckon that if you mount a pair of button cells on the end of the instrument, either side of the viewing window, then any effect on your accuracy will be negligible. An alternative is mounting the cells somewhere on the lanyard, but this gives you a whole selection of difficult cave-proofing problems.

I skived off Austria this year, but reports from the users were generally favourable. All the lights survived the whole expo, although 2 of the four were significantly dimmer at the end. It is not clear whether this is though being operated accidentally, or battery damage through soldering, or if they have genuinely been used up. The latter is quite possible as the LEDs draw about 10mA, and the batteries are 20-40mAh so you only get a few hours of light. However that should last for an awful lot of surveying as the duty cycle should be quite low.

The biggest problem was the gap between the LED & the binnacle which (surprise surprise!) got filled up with crud from time to time. Next year I will seal this area with silicone and we'll see how that works.

So, you can get yourself a light which is brighter and more reliable than Suunto's for not much over a quid. A few p more for silicone, about 3 quid for the rubber cover (!), and an evening's construction and you are there.

Catalogue numbers:

LED (Farnell) 212-295 £2.20 for 10
Switch (Farnell) 177-807 £0.39
Batteries (CPC) BTGP-RM675 £1.00 for 4

Software Releases

New versions of surveying software continue to be released regularly. As well as a couple of new versions of Survex, and a new version of the CavePlot demo (v2.1) mentioned in CP6, this quarter has seen the release of preliminary Windows versions of two popular surveying packages from the US, KARST & COMPASS. These are both comprehensive & effective pieces of software, already easy to use. Moving to a GUI is a sensible thing for software of this nature, as it allows software writers to write code about surveying rather than supporting hundreds of different printers, or writing a whole user interface. The first releases look promising, and it will be interesting to see what the finished versions are like.

Survex version 0.60

Olly Betts

Survex v0.54 has been released since the last CP, and version 0.60 should be out by the time this hits your doorstep

Here's a quick summary of the non-trivial user-visible changes from 0.53 to 0.60 (a full list is in the release):

Enhancements:

in v0.54:

*solve directive added to allow easy adding of new data to an already drawn survey -- you can now read in data, close loops, then read in more data.
Survex prints percentage of matrix solved so you know how long you'll have to wait!
Improved error statistics. These give separate vertical & horizontal expected error ratios for loops. This allows a certain amount of blunder detection. You can often see that the excessive portion of the error is in, for example, the horizontal plane, suggesting a probable compass error. You can then break the loop in question to see the value of the error vector, and then look for a leg perpendicular to it. If you find one then that is likely to be the leg at fault. This stuff will eventually be done for you automatically.
Giving LEVEL or H instead of a clino reading for a level leg (e.g. along the surface of a canal) which shouldn't have the clino adjustment applied
SURVEX now gives E-W and N-S ranges and extreme stations
PRINTDM now has a definable end-of-line sequence, for non-standard printers.
DIFFPOS utility for comparing two .pos files included
Now set SURVEXLANG (case insensitive) to set language (default EngI)
Added US English messages (EngU)
Auto-resizing scale bar in CAVEROT
The RISCOS version now uses 3-bank animation giving a smoother display.
CAVEROT now uses "sliding point" arithmetic, which means that you can view larger caves without the rotation getting juddery (the judder is now just about detectable with a cave 200km across), and you can zoom in further before getting spurious lines appearing
Name of 3d file created displayed during SURVEX run
Printer drivers give dimensions for multipage printouts (e.g. 6 pages (3x2))

in v0.60:

French and German translations greatly improved and brought up to date.
Survey grades now supported. So you put a line '*include BCRA3' to include standard error values as defined by the BCRA grade 3 spec. You can also set up your own standard deviation values for the sort of surveying you usually do.
*calibrate, *data, and *units enhanced in a backwards compatible way. This lets you change the expected accuracy for one leg (or several), where you know that the clino was dodgy, for example.
The survey network is now split at articulation points. This increases speed and reduces memory requirements.
Omitted clino readings give a vertical SD of tape/sqrt(10). This basically means that clino-less data (e.g. collected with a theodolite, or by pacing), will stretch vertically, if attached to other data, allowing for the fact that the height change is very unlikely to be more than the length of the leg.
Filenames with spaces are now supported -- just put them in quotes ("").
CAVEROT's "sliding point" code improved to work even in really extreme cases. Added a "compass" to caverot.
DXF (AutoCAD) converter now included for moving cave plots into CAD or drawing packages in 3D.
CAVEROT memory usage improved, so it now copes with larger files.

Bugs fixed:

Printer drivers no longer size plot to include (0,0,0), so caves with 'real' co-ordinates will scale properly.
Fixed a couple of Printer Drivers problems
Fixed spurious '\' label which occasionally appeared in CAVEROT
Fixed CAVEROT bug which prevented it reading .3d files with no survey stations (e.g. those produced by CML)

And a host of more minor improvements and bug-fixes.

Finally there is now some better documentation (the start of the Survex Manual).

WinKarst Preliminary Release

Garry Petrie

WinKarst is the first porting of my software to the Windows environment. I've deliberately compiled the program for "enhanced mode" of Windows, which means you must have a 386 or better computer. The zipped file actually contains two files, WINKARST.EXE and BWCC.DLL. The dll file is Borland International's Windows runtime library. Windows users may already have this file if you have any Borland products or programs created with Borland software tools. Look for the file in your Windows/System directory.

So what is in WinKarst? WinKarst is the first caving survey software which will allow multiple views of multiple cave survey files.

[This is a somewhat debatable claim - X-Caverot (at least) has been able to do this for some time - Ed]

First, the program allows the user to open several cave surveys at the same time and use standard Window functions such as "tile" and "cascade" to view them. Then, for each cave survey, the program has two types of views and allows the user to open multiple windows of either type of view. The two view types are text/ASCII and graphical. Views are created through the "Windows|Add view" pull down menu. The views have all of the standard window functions like iconize, maximise and stretch.

The program uses the same files as KARST256. WinKarst will read files with the .KST extension after selecting it from the "file type" section of the standard open file windows dialog box. These type of files will initially start in the "Map View." File types read with the .SUR extension will start in the "Text View."

Map Views can be printed using your existing printer drivers through the standard Print dialog boxes. At this time, it is only possible to view the entire cave in both plan and profile views.

The Text View will reduce and close cave surveys. The shot data of the individual surveys and loops can only be viewed and not edited. As such, WinKarst must currently be viewed as a "read only" program.

This is only the first release of WinKarst. In the future, HPGL and DXF export functions, survey editing and data entry will be added. It is my commitment to add HTO as a supported file type. So stay tuned. For now, give it a try, kick the tires and let me know what you think. At this time the source code is not available, due to the daily changes to it. The coding was designed with a strong division between the graphical interface functions and the data processing. This was done with the hope that ports to "X" would be easy.

New WINDOWS version of COMPASS

Larry Fish

I have a new release of COMPASS for Windows. This version has more than 15 new features and improvements. Several people have complained that I don't give enough information in these announcements, so I'll try to give a brief description of the COMPASS for Windows features.

COMPASS for Windows is an extension of the DOS version of COMPASS. It has the same ease of use that is found in COMPASS for DOS, but it takes full advantage of the Windows environment. The program allows you to manipulate, view and plot cave survey data. The heart of the software is the viewer. The program begins by presenting you with an overview of the entire cave. Using a selection box, you can choose parts of the cave for detailed viewing. The selection box can be moved and resized using the mouse or the arrow keys.

When you have selected a part of the cave for detailed examination, you "enter" the box and the program displays the contents on the full screen. Once you have "entered" the box you can continue to zoom or pan, except that zooms and pans are carried out instantly. In effect, you pan and zoom through the cave. At any point, you can "exit" from the box and see an overview of the cave with the selection box showing the affect of the latest zooms and pans.

Here is a brief list of other features:

Plan and Profile Views.
Label stations.
Colour passage chromatically according to shot depth.
High speed Blit Refresh Mode - prevents redrawing of the whole cave every time the window gets resized or a change is made.
Optional status bar displays pan, zoom and scaling information.
Tool Bar Option - Visual tools perform many operations with a single mouse click.
Complete plotter and printer support through Window device drivers.
Floating Status Box Option - Allows you to move the status box anywhere on screen and gives a larger display area.
Floating Tool Box Option.
Independent Subwindows, allows simultaneous display of both overview and zoomed screens.
Complete Font Selection, including size and type face.
Complete colour control including, line, border, background, station labels, selections box and elevation.
Accelerators keys allow you to perform most operations with a single keystroke.
More than 25 pages of Windows style, hypertext online help.

HOW TO GET COPIES

All these releases are available from the usual places:

The UK cavers archive site: gserv1.dl.ac.uk

The US archive site: speleology.cs.yale.edu.

And all can be obtained from Wookey at the editorial address.

WinCompass:

WCOMPAS.EXE, a self extracting archive.

WinKARST:

WINKARST.ZIP (DOS ZIPfile), or karst.gz.tar (UNIX ZIPfile). you will also need KARST256.ZIP for data, and KARST.DOC might also be handy.

Survex:

SVX060.ZIP is the DOS version

SRC060.ZIP or SRC060.tar.gz are the source/UNIX releases

All three are free (Compass is normally shareware, but copies of this preliminary version are free).

Or you can contact the authors direct:

Larry Fish,123 E. Arkansas,Denver CO 80210, USA

<lfish@nyx.cs.du.edu>. Include $10 for costs.

Garry Petrie,
19880 NW Nestucca Drive
Portland
, Oregon 97229
USA.
<gp@scic.intel.com>

503-531-5071 days, 503-690-5465 evenings

Compass & WinCompass Review

Wookey

Compass (the Cave Oriented MaPping And Survey System) has been around for several years now, and is a popular package, having many testimonials from thoroughly satisfied users. It was started 10 years ago on an Apple II to help with the Groaning Cave (Colorado) mapping, and has since grown and moved to DOS, thus giving it a wider audience. Now it is moving to Windows.

I will start by looking at the DOS version to give you an idea of the software, and then take a look at the new Windows release, comparing it with WinKarst.

The most noticeable thing about Compass, compared to most of the other software available is the quality of the documentation, and a general attention to ease-of-use. To install you just run the self-extracting archive, then run INSTALL.EXE which leads you through the source directory, destination directory, which parts of the program you want installing (Minimum, docs, data, all etc.), and what printer you have. It will also add itself to your path and set an environment variable in your AUTOEXEC.BAT. (It got this slightly wrong for my rather complex AUTOEXEC, but then so does much commercial software so this is not a criticism). After a reboot, you just type CSHELL to start the 'Cavers Workbench' and you are off.

The workbench is a shell which provides access to all the important sub-programs which make up Compass. As a user you don't even need to know what they are called. The display shows a file and directory dialog, along with help on keys. At the bottom of the screen is an area summarising the data path from raw data (.DAT) through closed data (.CLP) to plot files (.PLT) via optional makefiles (.MAK) for very long caves.

You can get a long way with this software without reading the manual, but when you do it is a revelation. It is 400K of text, only slightly padded out by a number of screenshots. This may seem daunting but it is well set out and well written and generally lets you find out what you need to know. It also goes to a lot of trouble to explain terminology (both caving and computing) before using it. This, combined with the fact that at any time (except when displaying a cave) the screen shows you what keys you can use to do what, means that it is very easy to get results, even if you aren't a computer expert.

The facilities provided by the software are good. There is a data entry editor which works in units of surveys, i.e. you get given a list of the surveys in a cave and pick one to work on (or 'NEW' if you want to create a new one). For each survey you specify the name (up to 8 characters), the survey team, date and declination. You then also set the units (meters, feet & inches, decimal feet), data entry order, passage dimension order etc. The editor itself does it best to guess the station numbers for you, although it always assumes foresights so if you are entering leap-frogging data it is less helpful than if it did nothing at all. In general this feature is quite handy though. By default you get the 'WYSIWYG' entry editor which debuted in the last release of Compass (see CP5). My major gripe was that hitting return at the end of each line did not default to giving you a new shot; you have to press 'down cursor' and then answer 'Y' to 'Do you want to enter a new shot' every time. This sort of thing is the reason why I prefer to enter data straight into a text file. Compass is quite happy to let you do this, as the files produced are simple text files, except that each survey within a file is terminated by a form-feed (12h) character. The editor doesn't really provide any error checking, it is quite happy to take a negative tape reading or compass reading of -700. It does give you the opportunity to convert data wrongly entered in meters back to feet and vice versa.

Once you have some data you hit F2 to close loops (although this step is optional), and then F3 to process the data into a plot file. Both of these processes are very fast - about 1.5 seconds for the 273 station, 13 loop example cave provided. This speed is achieved by doing sequential loop closure rather than simultaneous loop closure. The author includes an appendix detailing the philosophy behind this approach. His reasoning is that whilst closing loops simultaneously is correct in terms of random error distribution around a network, it has problems with real-life cave data. A real survey is likely to have good loops and bad loops, and if the bad loops actually contain blunders, rather than random errors, then you do not want to 'contaminate' your good loops with the errors from the bad ones. Thus the software finds the loops first and then closes them in order of error (either by percentage error or by magnitude of error - users choice). Another advantage of the method is that it is very quick and uses very little memory, as no big reduction matrix is needed.

This method will work well where there are adjacent pairs of loops, one of which contains a blunder. It will work badly where there are no blunders, however errors should be quite small in this case. It is not the 'best' solution to the loop closure problem, but it is a reasonable one, which will be good enough for most people/caves in most cases, and is very efficient in terms of computing requirements. [The 'best' solution is probably blunder detection and exclusion, followed by simultaneous loop closure. I intend to examine the effects of different closure algorithms in a future article.]

Once you have a plot file you can either view it or plot it. The viewer uses the concept of a reference window from which you pick an area of the cave, a view angle and scale. Once this is done you can move the cave around the screen, zoom in & out, switch between plan & elevation views, toggle station labelling, colour legs by depth, colour by survey and find a survey by cursor position. All this worked well and seemed to be effective in use, although everything you did was reset by moving the cave view, so for example you could turn off an obscuring survey by setting its colour to black, but you couldn't then rotate the view for a better look, as the black survey would reappear. It was quite quick (although I was using a DX2/66 and the example cave is only about 2km long, so it ought to be). To deal with vary cave sizes and computer speeds you can set how many surveys the machine draws before checking the keyboard. Once set correctly for your machine, this allows continuous (if rather flickery) rotation. CGA, EGA & VGA are supported, and overall this is one of the more effective cave viewers, once you get used to its approach.

The plot program has much of the functionality of the viewer, allowing the same selection of the area, angle & scale of the plot. You can also specify a number of attributes for each survey: whether it is plotted at all, and what symbol is used to mark stations. There is a wide range of symbols, so you can distinguish between the different surveys on the plot. This is a very good idea.

The only noticable restriction of both the plotter and viewer is that of only being able to show plan & elevation views, as opposed to view looking up or down at an angle - very useful for caves in sloping beds.

Configuration files for the usual selection of common printers are provided - Epson, PCL laser printer/deskjet (75, 100, 150 & 300dpi), Proprinter, Panasonic and BMC. The configurable printer strings mean that almost anything should be usable. Facilities are provided to get accurate scaling, including a test plot of a perfectly square cave 10 feet on a side! Plotter drivers for HP and Apple plotters are also provided, as is a DXF exporter to deal with other export requirements.

Compass is designed to work on a very basic system. If you just have the basic files it takes up 188K, which means that it will run on single 360K floppy system, with plenty of room for cave data. In order to deal with the memory limitations of DOS it deals with big caves in chunks, where big means more than 4000 stations or about 20 miles/32km. This is enough for many caves, but not the ones that people really need computers for! Thus a method is provided to deal with big systems - the data is broken down into 4000 station chunks, each of which is processed in sequence. To do this it needs to know the connecting stations between the old data and the new. To save you typing this in every time you can create a makefile containing this data. As the whole of the first lot of data is processed before the next lot is read in then obviously the loop closure algorithm is compromised, but then something has to give when you only have 640K and a 100km cave. I don't know of any other survey software can manage unlimited cave size under DOS, although Survex can (potentially slowly) for 386s or better by using virtual memory.

Another side effect of the sequential-data-processing design is that it can only deal with a limited number of 'hanging' survey legs (500) before running out of space. This means that some care has to be taken to ensure that data is generally processed from a fixed point rather than in some other random order.

A number of other utility programs are provided. A couple to manipulate surveys so that they are in optimal processing order and to find and reduce links across survey blocks, one for displaying rose diagrams, and several for translating data from/to SMAPS & KARST formats. It also has GIS features, but I haven't the time or space to examine those here.

Compass is a very good example of a simple cave program taken a long way. There seems to be no way of fixing points, or dealing with radio locations, and not much concept of standard deviations or error values for data. Nevertheless, it has excellent documentation, a simple user interface and wide capabilities. It also achieves a lot with a small amount of computing. It is certainly worth a look and you may well consider it to be worth the asking price of $25.

So how does WinCompass compare? Well, it is currently just a viewer/plotter, so the processing must still be done in DOS, but it is very fast. Being able to change the font used for station labels to a really tidgy one is a godsend, and obviously the printer support immediately becomes complete. The complete control over colouring of items is nice too (it is red lines on a black background by default, but this feature let me change it to black on white for the screenshot on the cover). The floating toolbox & status window are also nice, as is the colour-by-depth. The preliminary nature of the release shows through rather in a number of non-working features such as rotation, & depth labelling. (I got an error of a missing library so it may be that there is a file missing from this version). I found the way the child windows remained linked to the main window rather unhelpful. When you open a view on a section of the cave it can optionally be put into its own box. When you use the movement controls both views move together. I think I would prefer to just move the view I am currently looking at - it is certainly open to debate - this feature is perhaps something that you have to get used to. It also seemed quite stable, as I only managed to crash it once

WinKarst is a different kettle of fish. It is a much more complete application allowing you to load up a cave and view both the plot and the original data files. It doesn't look as nice as WinCompass, and you can only have a complete plan & elevation (at the same time) view. The data editing facilities worked well, but any attempt to actually reduce data caused Floating Point errors and GP faults so I wasn't able to test them.

So, don't rush out and get either of these windows versions yet unless you just want a look, but give it a few months and they could be well worth having.