In "Options - Main Screen" right at the top you can select the Units.
Klaus

Hello Blaustein / Klaus,

I am running GCC 4.10beta 1. Other than the abnormal termination functionality, I have not encountered any issues with the functionality I have used. Overall the software is excellent and I thank you for it's continued development.

I had an incident whilst cycling recently. The seperate GPS receiver remained on the bike however the Pocket PC detached from the bike and hit the ground quite severely. The impact caused the battery cover to come away and the battery itself to come out of the Pocket PC. Fortunately, there was no real damage done. After reasembling everything and restarting GCC, it asked if I wished to resume logging, I selected yes. Upon doing so, I then noticed the Distance increased immediately out of all proportion. The bike and GPS receiver had not moved significantly at all from the position where I had crashed, so this was unexpected.

I have confirmed this behavior is consistent by cycling a short distance, and then stopping stationary and pulling the battery on the Pocket PC. Even though remaining stationary throughout, the effect was the same. From memory, I think distance was 0.45 miles aproximately at the point of pulling the battery, immediately increasing to 0.78 miles approximately upon resuming despite having remained stationary.

Unless whatever causes this is equipment specific, it should be easy for you to replicate as above. It might be worth some attention before the next beta release.

Let me know if you need any further information or testing.

low.flying.pigs

Hello low.flying.pigs,
I am out for the weekend so be patient. Can you do another test: Do the same, but choose not to continue and switch gps on (if it is not on) and check that the position on map is stable and at the right place. Then choose continue from the menu page.
Check the track on the map (also for the first test) if there are some irregular points , which can produce this increase in distance.
Have a nice weekend
Klaus

Herzfrequenz mit Sportstracker?

---

Hi Blaustein/Klaus

is it possible to support the heartrate belt "Sports Tracker" in your program?
've since moved on Android and had long ceased in this forum. But now I have my "OLD" and my bike made ​​696 OLD Asus rolling again and I have a Bluetooth Sports Tracker chest gained the interesiert ....... but no one!

Now to my question:
Is it possible that this is supported by the GPS cycle computer and logged with the GPS log data in conjunction with the heart rate?
Maybe I can contribute to the realization and info since the beta test,


(sorry ich versuche es in Deutsch),

ich habe inzwischen auf Android gewechselt und war lange nicht mehr in diesem Forum. Aber jetzt habe ich mein "ALTES" Fahrrad und mein ALTEN Asus 696 wieder flott gemacht und habe mir einen Bluetooth Sportstracker Brustgurt zugelegt .......das interesiert aber wohl niemand!

Nun zu meiner Frage:
Ist es möglich, dass dieser vom GPS Cycle Computer unterstützt wird und Logdaten mit den GPS-Daten in Verbindung mit der Herzfrequenz loggt?
Eventuell kann ich da infos zur Realisierung und zum BetaTest beitragen,

MfG
Achim

Originally Posted by womisa

Hi Blaustein/Klaus
is it possible to support the heartrate belt "Sports Tracker" in your program?

Hello Achim,
I suppose you need Bluetooth V4.0 on your phone to support this belt. This also applies to the Polar H7 belt (Bluetooth smart).
Did you try the Sports Tracker application for Windows Phone? Maybe it doesn't work on your Windows Mobile phone at all.
On the support site of Sports Tracker there is the following FAQ:

Is the ST hrm (heart rate monitor) compatible with Windows Phone?

Last Updated: Mar 19, 2012 03:34PM EET

Not at the moment. Because of the closed interface of WP, the ST hrm doesn't work with the WP app. If Microsoft ads the necessary Bluetooth support to it's OS then we are able to add the support.

Unfortunately the same applies to the Polar Wearlink with Bluetooth belt.

So I guess it will be impossible or at least very hard to support this HR belt in GCC too.
Klaus

Originally Posted by Blaustein

Hello low.flying.pigs,
I am out for the weekend so be patient. Can you do another test: Do the same, but choose not to continue and switch gps on (if it is not on) and check that the position on map is stable and at the right place. Then choose continue from the menu page.
Check the track on the map (also for the first test) if there are some irregular points , which can produce this increase in distance.
Have a nice weekend
Klaus

Hello Blaustein / Klaus,

Thank you for your reply.

A cursory inspection of the maps reveals no obvious irregular points.

Choosing continue from the menu page also results in distance increasing abnormally.

On the main screen, nothing else seems to change apart from average speed and the odometer.

The effect on average speed seems to be because upon resuming by either method, the time since abnormal termination is added and included to the elapsed time within the 'stop time'. That I presume is by design, and for an abnormal termination event, is probably desireable. If resuming logging of a 'session' however in another circumstance as one would by selecting continue from the menu page, for example resuming ''yesterdays' log for 'todays' leg of a cycle tour, the overnight elapsed time seriously scews the readings. An option whether to include the elapsed time from the end of the log, to the current time when resuming would resolve the issue. Ordinarily I log rides individually. However, if doing a cycle tour or an extended length route / ride over a period of days as I hope to begin in the near furutre, I think I would prefer to record the route as a whole. I don't know however if there are any limitations on log sizes etc.

The odometer has reset, when it had been up to around 800 miles. From observation, it seems it might be becuase the file is written / updated when GCC is terminated, and when termination is abnormal, the odometer distance is lost. Unfortunately, I did not think to check the odometer file before restarting GCC after the first incident. I notice it records some information about the 'exit', usually being 'normalExit'.

There is no particular hurry to any of this from my point of view, I just thought it better to bring to your attention. Let me know if you need any further information or testing. GCC is an excellent peice of software in my opinion, it would be great to see development continue as and when circumstances allow.

low.flying.pigs

Hello low.flying.pigs;
there was a bug: when restartig GCC, load a track and continue, then immediately the shortest distance between start of track and current position was added to the distance. It should now be fixed but I haven't tested it in real - I think you will do it.

In Versions prior 4.9 tracks was limited to 18 hours but since 4.9 the limit is 68 years, which should be enough.

The odometer should never reset. GccState (with current odo) is written on all major actions (switch on, off GPS; start, stop, pause, continue of tracks; load files and exit GCC. One possibility is a problem with reading the file. Do you have a "LoadState" error in GpsCycleComputer.log? If GCC crashes you should only loose the km since last save of GccState, unless it crashes right in the moment of saving and the file is corrupt.

Attached is version 4.10 beta 2
Klaus

Originally Posted by Blaustein

Hello low.flying.pigs;
there was a bug: when restartig GCC, load a track and continue, then immediately the shortest distance between start of track and current position was added to the distance. It should now be fixed but I haven't tested it in real - I think you will do it.

In Versions prior 4.9 tracks was limited to 18 hours but since 4.9 the limit is 68 years, which should be enough.

The odometer should never reset. GccState (with current odo) is written on all major actions (switch on, off GPS; start, stop, pause, continue of tracks; load files and exit GCC. One possibility is a problem with reading the file. Do you have a "LoadState" error in GpsCycleComputer.log? If GCC crashes you should only loose the km since last save of GccState, unless it crashes right in the moment of saving and the file is corrupt.

Attached is version 4.10 beta 2
Klaus

Hello Blaustein / Klaus,

Thank you for the information regarding track limits.

I can confirm GCC 4.10beta 2 resolves the resumed session distance error issue, by whatever method the session is resumed. Excellent work.

What are your thoughts regarding an option to include / exclude the elapsed time since the end of the session being resumed within the 'stop time'? If resuming after a few moments due to an abnormal termination for example, it may be desireable. If resuming after an overnight stop for example, it may well not be.

Regarding the resetting odometer, there were a number of errors in my GpsCycleComputer.log file, including load state errors. I renamed the existing file so GCC would start afresh with a new log file and will carry out some further testing. As far as I can tell so far, something causes the gccstate.txt file to be unreadable / corrupted and it is then overwritten by GCC starting again from zero, there being no other storage of the previous odometer value to restore from. I will let you know any findings. If it just happening when an abnormal termination occurs, that is not to much of issue as that should be rare. If not, it may be more significant. Time will tell.

Something that is perhaps more of an issue are the 'pause', 'stop', 'gps off', and 'X close program' buttons. All work as intended and that is the problem, although no fault of GCC, more the practicalities of cycling and the equipment. I wasn't going to bother mentioning this but since it keeeps happening occasionally, this evening being the latest incident, I thought it better to bring it to your attention.

Occasionally, logging gets interupted unintentionally and goes unnoticed resulting in lost logging. It seems to me a 'press and hold' instead of just 'press' for these functions would largely eliminate the issue (perhaps with the exception 'X close program, it not being part of GCC), at least in most situations I suffer. It is probly more elegant than a popup 'do you really want to' type message.

Incidentally, the 'X close program' button for me if pressed whilst logging, shows a breif message 'GPS is logging do you want to exit stop logging' with a yes or no option. It then promply closes itself without waiting for an answer ending logging regardless.

Again there is no particular hurry to any of this from my point of view, have a good weekend.

Let me know if you need any further information or testing.

low.flying.pigs

Hello low.flying.pigs,

Thank you for testing.

>>option to include / exclude the elapsed time since the end of the session being resumed within the 'stop time'
There are no plans to do anything like this. I think it will be too difficult to manage and it is only useful for a (hopefully) very seldom malfunction or accident.

>> odometer
V4.10beta2 includes a slight change in reading GccState.txt file so that odo is read (and used) even if the file is corrupt afterwards (odo is the first line). This hopefully reduces the cases where odo is lost. You should never have GccState.txt opened in an editor while using GCC, as this could generate access failures.

>>'pause', 'stop', 'gps off' 'press and hold'
I will think about, but it was relatively complex to implement such a function on the left button. And next time the users complain that the button doesn't work reliably. I think I leave it as it is.

>> 'X close program' button ... promply closes itself without waiting for an answer
I cannot reproduce this issue. Which device and Windows version do you use? On my device and emulator it works as intended.
But I have discovered a bug when using Exit button from menu and then choose 'no' to cancel exiting (it exits anyway).

Klaus

Hello Blaustein / Klaus

My Pocket PC runs Windows Mobile 2003 SE and GCC 4.10 beta 2.

I can confirm as you noticed that if logging, when selecting exit from the menu, it will await a response, but it will close anyway even if 'no' is selected.

To add to my earlier report, pressing the 'X close program' button on the top right of the main main screen will promptly exit without waiting for an answer, but if you are quick, it will also exit even if 'no' is selected.

Both exit issues seem related, and it seems may therefore actually be the same and have the same solution.

Regarding the odometer, just to confirm I did not have any files open when running / testing GCC.
I will keep observing the odometer for any further problems.

Regarding an option to include as currently is the case, or exclude the elapsed time since the end of the session being resumed within the 'stop time', with respect I disagree about it being only useful for a seldom malfunction or accident. I had already provided examples where both options are preferable, dependent on circumstances. I think, and I may be wrong, that most users on extended rides or tours would want to record only time when 'out and about on the bike', and not 8 hours or whatever of sleep within thier stop time. In the absence of any other solution at the moment, I will just work around this by simply not using the resume functionality at all in this instance, instead logging each day individually, converting the resultant .gcc files to .gpx and then combining all the .gpx files together as a single .gpx for the total route. I will then try to import the combined .gpx into GCC and then save as a .gcc file.

Regarding the press and hold, it is just to stop accidental touches causing unwanted commands, that stop the logging. It could be made an option to choose a 'safety' or not so users have the choice and no reason to complain. Alternatively, a 'do you want to' confirmation request similar to that when exiting would achive the same, avoiding any difficulties implementing press and hold. In the absense of any other solution at the moment, I will either tolerate it or work around this also somehow.

I appreciate the difficulites with software development. If you are willing to provide the current beta sourcecode, I am willing to have an attempt at these matters myself and share any success.

low.flying.pigs