Skip to main content

I've just submitted to the iTunes App Store an app entitled 'UKCM' which was written specifically to automate and log all the calculations that we perform in the process of measuring a course. The programme’s algorithms are compliant with the standard measurement techniques using a ‘Jones’ counter.
The user can designate the length of the calibration course and configure various options as a definition for the course to be measured. Counter values are entered to calculate the calibration constants.
With this initial information race start, split and finish points are determined in both distance terms and counter readings. All data are dynamically recalculated as parameters change allowing instant results to be displayed. During the measurement run itself, counter values can be logged at each desired reference point with distance to the next pertinent points being presented. The complete list of logged reference points together with the automatically generated split points can be inspected and manipulated before being output to your favourite spreadsheet for further processing or presentation. 'Location aware' devices can store the approximate position of logged points which can be viewed on a map.
The app has been field-tested using iOS4.2, is compatible up to iOS5 and should run on an iPhone, iPod Touch or iPad.
Feedback would be particularly welcome to improve the usability of the app and to iron out any wrinkles. I can certainly incorporate any corrections or good suggestions that are generated here.
I hope that it proves a useful and reliable time saver.
Links are below for the app and the instructions...
Original Post

Replies sorted oldest to newest

The App is pretty inexpensive. The website that Dougie Roxburgh listed is selling the APP for £1.99 (roughly 3.19 USD.)

I have a spreadsheet that I have used in my Palm Pilot for several years, but I would be interested in trying out the UKCM App. Unfortunately, for me, I don't own an Apple iPhone, iPod Touch, or iPad. Maybe my kids will hand me down their Apple gadgets someday.

Here are a couple screenshots of the App.

Thank you. -- Justin
I'm a sucker for anything "there's an app for." Will look forward to testing it out.
An app I've found useful is "Elevation." Shows your current elevation in meters & feet. You have to remember to use it during your ride, though. It would be more useful if you could input locations by scroll and touch to get elevations remotely.
I have tried out Dougie's UKCM app using my son's iPad and found it worked well. I got the data out using my wife's mac and then transferred it to my PC. I am the only one in this family firmly wedded to non-Apple technology.

As Mark says, it will be handy if you have an iOS device to mount on your handle bars. My son is replacing his old iPhone with a new one in two weeks time and I am lined up to inherit the old one to install on my bike so I can use the app in the field.

Don't begrudge Dougie the odd $ or three. He has done great deal of work to make this app user friendly.
Dougie, this sounds like an awesome app. I think I might have especially appreciated it yesterday at about the 5th straight hour of measuring without a break, trying to pin down an elusive turn around on a non-symmetrical out-and-back course. My arithmetic skills can degrade when I get dehydrated But, I am an Android guy. Any plans to produce a version for the "Droid" users out here?
There are 2 (maybe more) spreadsheet apps available for the iPhone, iPod Touch and iPad. One is Apple's Numbers another is Sheet^2 by Byte Squared Ltd. The first (Numbers) is Apple's version of Excel. The second (Sheet^2) is Excel and works just like Excel. I use Sheet^2 and it saves a ton of time and allows me to calculate on the spot.
Thanks for the comments - I wasn't anticipating the price tag to be so controversial though! Just as background, registered Apple iOS development costs $99/year and there's nearly 5 months of hard programming and testing involved so I thought it might perhaps be worth the price of a coffee...
The premise behind the app is that it can be taken on the road and used in place of your calculator to automate the standard maths. It's the portability for 'field use' that's the main design feature. At the end of the day the log can be imported into a spreadsheet for all other post-measurement purposes which is what I also do; it won't replace your favourite spreadsheet in this respect but could perhaps generate the input for it. (I paste the CSV file into my spreadsheet and have the spreadsheet refer to these pasted cells.)
If location services are being used then the GoogleEarth KML export will show the spot elevations (though for a more comprehensive profile it would be better to trace the route in 'paths' then use the 'show elevation profile' option). I've used it on 2 live measurements and on neither had call to press a calculator button or do a single calculation. There is however a calculator function that will translate counts directly into metres or yards as required. Once the calibration is logged every other calculation is quite dynamic.
In response to Jim's query, it is possible to flip between metric and imperial splits by toggling the metric/imperial split button although they will not be displayed simultaneously.
I might have to disappoint Lyman here because I'm not at all experienced in Android development: iOS uses Objective-C for iOS whereas I think Android is Java for Linux so there would be a lot of work to port it across.
When run on an iPad it will be in the expanded iPhone format - it will require a bit of tweaking of the layout to make it native to the iPad screen; at the moment a few of the buttons get misplaced after compiling for the native iPad resolution.
I'm hoping for some good suggestions and observations as feedback for the first update: It works for my measurement methodology but there will be many techniques I'm blissfully unaware of...
Jim, It's probably one area that does unfortunately require a bit of familiarity with the programme methodology.
Start and finish counts are either marked counts or calculated counts. Split counts are always calculated from the displayed start count. The start count can be logged(marked) or calculated backwards from the finish point.
Basically when you specify a new course with the 'reset course' option from page two you will get a default start-to-finish layout with the start counter set to 00000. When you then specify the finish-to-start configuration (by pressing the S icon and seeing the reverse arrow from F to S) the start value will remain at the default 00000 and the finish value will remain as calculated (defaulted from the 'nominal' course length) UNTIL the actual finish count is marked whereupon it has the real value to back-calculate the actual required start count. The amber tags on page two should turn green when all the required information is present. Also on the full list on page four, selecting the finish point should show the status of the finish count - if it shows 'unmarked' then it is a calculated count rather than an actual count and it's awaiting entry of the real count.
If you are logging points as you do the measurement (ie from page three) then when you come to log the start point at the start of the ride (using the add button top right of page three) you will be presented with the option to log it as the 'nominal start' point whereupon an estimated finish point will be calculated along with the split point values you can expect. These will be updated at the ride's end when you get to enter and mark the real finish point. Again amber icons reveal assumed information that requires a final real input to complete the calculation.
I should add that this assumes that you are riding in the start to finish direction - hopefully I'll get the reverse direction ride algorithms for a future update as at the moment it will not count upwards from finish to start should you be doing a backwards ride. The presentation will always be listed with the start at the bottom and the finish at the top regardless - this is just having a convention of 'points ahead' being 'up' and 'points behind' being 'down'.
But would be easy to change if there is a demand!
Hope this helps.
By the way, if all else fails and the logging process gets into a complete tangle just press 'reset measurement' from the page two option, select the configuration again and enter the required counts into page four. Logged points are not deleted in this process - that only happens with the big red 'delete reference points' option.
Thanks Dougie that clears things up.
I think it would definitely be helpful to have the splits read in the direction you will encounter them on the ride, whether that means reversing the presentation order on screen 3 or simply changing the arrows so the splits flowed top to bottom rather than bottom to top, as they do now. At the least, going to the finish rather than the start when switching to screen 3 would be an asset. As it works now, you have to scroll from the start through all the splits to get to the finish, which can be quite tiresome for a full or half marathon.
I would guess the majority of the rides I do are Finish to Start, so this would be quite helpful. Hope it's an easy fix.
I have a 3-mile race I'm directing on Saturday and I plan to ride the course using the app tomorrow to check it in the field.
Thanks once again for creating it, and the feedback.
Last edited by jimgerweck
I can see that there will definitely be a demand for finish-to-start riding so I'll get to work on reversible algorithms! At the moment the option only gives you a fixed finish with variable start but ridden in start-to-finish direction which may not suit everyone.
I'm not sure if it completely addresses your scrolling query but page four is always available for previewing all the split points. Start and/or finish points can be marked there too.
Thanks, that is definitely necessary. As it stands now, I'm not sure what the point of having a fixed finish is if you can't ride from the finish backward to the start.
For the ride over my 3-mile course tomorrow, I'll just pretend the finish is the start and ride to where the indicated finish is, but this will only work for even distance non-metric courses.
Dougie, thanks for taking the time to program an app for measurers! While I don't use anything Apple, I know others will appreciate the replacement for our notesheets.

I have created an Excel spreadsheet that is the entire Road Course Application, which includes the measurement and calibration data. I further truncated the app to just have a set of sheets for calibration and measurement, which I use on my Android. Same principle as your app, but for the 'droid market. I use it with Documents To Go app, which allows for full functionality. If anyone is wed to their 'droid, as I am, it is available at the RaceMeasure Website.

Again, Dougie, way to go! Moving measuring into the 21st century.

Question to all, though - does the iPhone GPS feature give relatively accurate elevations? Do they give the same elevation for the same point every time, or is there variance?
Work progressing on the 'reverse measurement' update. Once I've given it a thorough test Apple takes about 5 or 6 days to process the update for the App Store.

Yes, the 21st century does call but I still jot counter values down on my route map just in case technology fails!

I'm a dedicated user of a spreadsheet (Numbers) for the report generation as the presentation is important. I'll follow the link to the above spreadsheet. The app in this respect is complimentary to that process in that it is an in-the-field tool, basically an intelligent pocket calculator that knows the calculations and can feed a spreadsheet when back at home. I'd be interested to hear of any spreadsheet functions that people feel could be incorporated.

If anyone was wondering, the design of page 3 is supposed to mimic a cycle computer with the current position in the middle with the next split ahead and the last split behind. If the counter is incremented in realtime it behaves just like one with a dynamic countdown to the next split being shown (my test app can simulate this). If anyone knows how to interface an iOS device to a jones counter this would be the result! Unfortunately iOS accessory development is a complicated process as I believe you have to get access to licensed chips.
In the meantime, hidden away on the calibration summary page is a little output calculating the size of your tyre circumference which can be used with most cycle computers - seems to be reasonably accurate for distance awareness aside from the inability of cycle computers to reverse backwards...

Not sure about the GPS elevation data as I test this on an unequipped iPod - GPS units have always been a bit notorious about displaying 3D elevations unless datums are corrected; off the top of my head, terminology such as WGS84 geoid elevation and Ordnance Survey Newlyn Datum (ie local mean sea level for here in the UK) have significant differences so you need to know which one you are using. Our Ordnance Survey website explains it all in horrendous detail: but that doesn't help with the accuracy of the GPS question! That said, relative elevations should be accurate and logged plan locations can be referenced to the ground in Google Earth to ascertain the real elevation if there is an error.
Tracing the course as a ground level 'path' in GoogleEarth then using 'show elevation profile' yields an elevation v distance diagram which is as good as is needed as seems to be within a metre or so of our 'official' OS mapping elevations.
Last edited by dougieroxburgh
One way to make this a very attractive app is to provide functions that people can't do with spreadsheets. One area I see that you might be able to do this is with GPS functionality. Of course you've already done GPS locations for mile/km marks, which is great, but another idea I thought of was to provide alerts when you get within 100 meters or so of mile or km marks. You could do a distance calculation based on the GPS info, or hopefully, that function is already available to you. You could have the rider press the "3-mile" button when they arrive at that mark so the distance calculation could be "re-zeroed" and made accurate again even if it goes bad for a while due to tall buildings, rider freezing the front wheel and moving his bike, etc. The audio cue is key to this. When I miss mile marks it's because I forget to check my counter or GPS, so something reminding me to check it would be helpful.

Elevations on my GPS are not very reliable, especially absolute elevations. But even for relative elevations I often see significant differences between GPS and Google Earth.
That's a pretty good idea, Mark. I've been pondering the solution for this and it might take a bit of lateral thought. The problem to the easy solution is that you wouldn't know in advance where the physical location of the split would be so in terms of GPS position you wouldn't know how close you were to it (unless you had a stab at predicting its location and pre-loading that information). However as you say, there is the chance of adding up the GPS track distance from the last fix (ie split) which would be able to trigger an alarm as it came up to a whole Km or mile. We know the controversy around GPS path measurements but for this application the required accuracy need not be that great. I'll have a look!

Nearly there on the reverse measurement solution - the algorithms have to run in the forward and reverse directions simultaneously and consistently as certain elements (splits etc) are directional as are the tiny elements that ensure positive rounding in the race direction.
I have a GPS unit that I mount to my bike and use whenever I measure, and I can see on it when I am getting close to a mile mark. I have even estimated the mile mark locations ahead of time with google earth and downloaded them to the unit before heading out to measure.
But one time out of ten I forget to look down to check it as I'm approaching a mile mark. If there was a audio cue 100m before I get to the mile mark, I'd never miss one again!
I used the program on 3 course measurements this weekend.
First was a half marathon measured S to F. Worked great although I'm not sure I was using the waypoint notation feature correctly.
Next was a 5 mile measured F to S. I could not get the program to calculate splits in reverse order (I must be doing something wrong - I input the actual counts at the Finish but the split and Start counts were indicated as if riding S to F (not just the order they were presented, but the actual counter readings). I simply set to to calculate & display as if it was a S to F ride and reversed the order on a piece of paper.
Finally, I rode part of a previously measured 10k to locate the 6 mi. point. Could not get it to indicate a reverse ride set of figures for the life of me, so wound up doing it on a calculator.
Can you tell me what I might be doing wrong? I'd love to use the app for F to S rides, which make up the majority of my measurements.
Also the longitude latitude function didn't work.
Hi Jim,
I'm just about to post the update which should address all your reverse measurement issues - as you know it is set up for forward measuring at the moment. The new version is working quite well on my iPod for F-S riding but I just need to make sure that there are no gremlins before I let it loose on iTunes. Hopefully I'll get that done within a day or so and once Apple verify the upload it should appear in about 5 days after that.
The waypoint lat/lon logging is off by default and is turned on from the calibration course page - this to save battery power if not intended to be on. After that, it does require a valid location update before the position is logged - the lat/lon will appear in small type under the current count on page 3 if this is so. That said, by selecting a waypoint on page 4 you should be able to manually type in a position if mapping is turned on. If that isn't the issue or something else is wrong please let me know.
Thanks for the feedback from your measurements - hopefully I'll get all the reverse features for you next week.
Jim - having had a closer look when you mentioned it, there may be occasions where the start and finish lat/lon points are not logged automatically from page three - this is a genuine bug which slipped through. The location is also [deliberately] automatically 'un-mapped' if you adjust the course by more than +/-100m so that the location info isn't misleading for a point which has moved (ie splits) - if you think that this is too draconian let me know! I've also taken the opportunity to change the mechanism of page 3 which hopefully will make it much more user friendly. For the reverse measurement scenario I'm just putting the finishing touches to the ability to use fixed or variable start/finish points as with the forward case (hence more useful for post-processing if you are attempting to adjust a course after measurement.) I don't own a GPS capable iPhone so would be interested to see how the location functions affect battery life. There are various economy measures that can be used to leave the feature dormant until actually requested but these slow down the speed of acquisition or affect precision just when you are in the act of logging a point.
Originally posted by Dougie Roxburgh:

The waypoint lat/lon logging is off by default and is turned on from the calibration course page - this to save battery power if not intended to be on. After that, it does require a valid location update before the position is logged - the lat/lon will appear in small type under the current count on page 3 if this is so. That said, by selecting a waypoint on page 4 you should be able to manually type in a position if mapping is turned on. If that isn't the issue or something else is wrong please let me know.

I have just got my son's old iPhone version 4.2.1, complete with cracked screen which I am not sure can be used when it is raining! I have no SIM card, but have synced with iTunes and downloaded the UKCM app.

The app works as it did when I tested with my son's iPad, but I dont seem to be able to record GPS. The phone has GPS according to my son, and when using wifi I can download a map and my position is correctly located. Of course as soon as I move away from my house, I lose the wifi and it tells me I dont have the cell phone service - the map position does not update.

The phone's location services are switched on for UKCM.

I am not able to find anything on the calibration course page of the app which turns on lat/lon logging for the way points.
Hi Mike - just got your message, we've had a power cut for the last 6 hours as you may have done... I'm not sure how your phone is set up but in principle you should be able to record the GPS lat/lon directly without a phone signal (as you won't have) but the map will not load without an internet connection. Thus you will have to wait until back in wifi coverage to see the map. In wifi coverage the map will be displayed when the waypoint is selected from page 4. To test this theory out check on page 3 to see if the lat/lon is being reported in the current position box - it will only be logged if it is also being displayed. Once a valid lat/lon is recorded then internet becomes available the map should be visible. I've only got wifi to test with on the iPod but the programme development simulator simulates GPS input which hasn't thrown up any anomalies.
Thanks. I am getting Lat/Long recording now. Not sure what I have done.

The main problem now is that I am very confused about how to work my way through all of the procedures. Partly this is because I have never used a touch screen device before and I am used to a PC with a mouse and a menu at the top of the screen to get me out of trouble when I am lost.

I shall sit down this evening and have another serious go. It will be really great once I have mastered it.

One point about lat and long though - I tend to think locations in the British Grid Ref - of course I can convert on a spreadsheet, but for measurement report summaries in the South of England I specified that the start should be given using Grid Ref not Lat/long. Was that a bad choice?
Mike, I'm with you on the grid / lat/lon question. It is much easier to plot positions on 50000 scale maps in grid than in lat/lot. It's purely a programming matter that the positions are displayed as such as I can't get a direct readout of grid and would thus have to implement transformation algorithms which are a lot more complicated that I bargained for! There would have to be a UTM grid function too. Of course proper [Garmin etc] GPS units do myriads of conversions but I haven't quite got there! I don't expect that the average mapped location will be hugely accurate - I only included it as an indicator of the general area as the phone is capable of doing it. Another plan is to allow a picture to be tagged to the point...
Dougie, perhaps I'm just dense, but I can't seem to get the app to calculate a Finish to Start measurement. I downloaded the upgrade, but still having the same problem.

On the Course screen I input course length and push the "S" button, and the arrow points from F ("marked") to S ("calc").

When I go to Measure screen I swipe to the top of the screen to F, tap the arrow and the Marked Finish Line screen comes up, w/ map. I input the counter reading, hit Done, and when I'm returned to the Measure screen the S, 1, 2, 3 mile splits are all there - but calculated from Start forward.

What am I doing wrong? I love this app but thus far have found it unusable for F to S measurements of metric courses marked in miles.
Dougie, never mind! I saw on page 2 that by pressing the arrow next to Measure the option for Forward or Reverse Measurement Reset appears. The calculations work swimmingly from there.

I can't wait to test it - measuring a course tomorrow although it's a straight Imperial course, so the benefit will be less pronounced.

I'm also set to measure some odd-distance courses for a long-running (50 years) summer race series - anxious to see how it compares to my original measurements 10+ years ago.
Hi Jim,
(sorry for delay - was away on my day-job for several days...)

There is a general quest to make things as intuitive as possible so if you have any ideas about how the interface can work better let me know!
The setting up for a reverse measurement is slightly quirky at the moment as you need to reset the distance, erase the old waypoints and then select the reverse reset option - all of which is straight forward but not necessarily a slick process. (The calibration resets to the 'pre' calibration constant which may go unnoticed too...).
It is technically possible to flip-flop between forward and reverse measurements AFTER the measurement has taken place (ie multiple forward/reverse resets) with the reference point counter values being recalculated to their equivalent 'virtual' inverse readings. The data points are retained (properly positioned) but beware that if the finish point is then moved the reference points will drift off - the reversing process assumes a fixed datum point but if that datum is moved between reversals then the subsequent reversal may not yield the original distances for the reference points. This would be a convoluted thing to do but I only mention it to emphasise the nature and implication of the 'reset'.

Let me know how you get on with it - I've only tested this on paper with an artificial set of data from a mirror-image of a forward measurement.

There is also a glaring omission in that multiple runs can't be saved - no big technical issue but the next update will have a scheme for archiving past measurements so that, for example, several measurements of a course can be stored.

I've just seen a release note that iOS6 is available for developers so another problem as my iPod won't be compatible (must be time for a new one...) Also the maps function is changing away from GoogleMaps to [I believe] TomTom which may be seamless or may not be. I'm still formulating a plan for the proximity alarm to operate on the location functions.

Feedback welcome as always!

Add Reply

Link copied to your clipboard.