Sorry for my late responses. Here is my comments regarding to your comments:
- Pace 1K remove;
- 2 configurable selection of LAP setting;
- Cumulative distance improvement;
Since our resources are almost occupied on new project development, I will ask them to arrange the schedule;
Is there a change in the smoothing of speed and ascending speed as well as cumulation of ascending distance?
Up to now, i had always 20-50% to high results for cumulated ascending distances when running. So the results are quite worthless up to now - at least for me.
Since others pointed out that the readings are better for steep and long ascends, at least two modes ("nearly flat" and "mountainious") with different algorythm would be a cheap solution i think.
It seems a good idea to have calculation into two modes; due to the GPS accuracy limiton, we take the medium value to smoothing the bumpy road, so that the result will not be same as real case.
Did you fix the issue that after about 650 km/h the speed starts with 0 km/h again? (This only happens in the airplane of course, but the watch is a nice gimick when travelling and correct readings should be no problem, since recorded data in memory is correct already...)
I will check with engineer, because it will impact the data structure.
For the memory full issue, i would suggest to combine the suggestions of rookie and zingo: when there are more then one training data in the memory: delete the oldest training data (perhaps with an alert in advance, lets say when there is only 1% of memory left). If there is only one training recorded (the present one) give the same alert and stop recording when memory is full except of the last bytes to collect the last position and time when the timer is finally stopped by the user.
Do you means the last point will be recored until timer be stop? I will check that.
I would also appreciate the suggestion of Albert when following a track: "...it would be helpful if the next trackpoint shows the altitude as well and the actual altitude"
This would be a great feature!
It could be implement, but the distance to next point is only according to 2D coordination.
Furthermore - but it seems I am nearly the only one in this forum in need for that - I still hope to see a chance for UTM data point entry some time, since this is essential for serious outdoor use with most of the available paper maps...
We know it is wonderful feature, but the idea still be hold for GH-625 according to memory size and CPU resource. For GH-505, it is done.