Translate

Donnerstag, 13. April 2017

Meine aktuellen Sportcomputer (Part 1: Bike Computer)

Da die Frage immer mal wieder aufkommt, hier eine kleine Übersicht meiner sich derzeit in Gebrauch befindlichen Sportcomputer.

Vorab: dies ist kein Review und ich bin, was Markentreue betrifft, mittlerweile auch sehr schmerzfrei. Daher führe ich hier wirklich nur jene Geräte auf, die ich nutze - bzw. die innerhalb meiner Familie derzeit genutzt werden - (sonst würde diese Aufzählung zu lang werden). Im Allgemeinen sind das auch jene Geräte, die eine gewisse Beständigkeit aufweisen, was für die Qualität dieser Produkte sprechen dürfte.

Was die hier nicht genannten Marken betrifft: vielleicht böte es sich an, eine Historie der im gesamten Radfahrerleben genutzten Bike-Computer zu verfassen, aber ehrlich, wer wollte das überhaupt lesen?
(falls es interessiert, mein erster elektronischer Fahrradtacho dürfte ein Sigma gewesen sein und mein erster Pulsmesser ein Polar Gerät, irgendwann sehr viel später bin ich dann beim Ciclosport Hac4 gelandet und noch etliche andere Marken sind durch meine Hände gegangen -> womit ich sicherlich einen ähnlichen Werdegang zu verzeichnen habe, wie etliche meiner Radsportkollegen auch :-) )

Derzeit genutzte Bike-Computer:

  • Garmin Edge 800
  • Lezyne Enhanced MicroC GPS (10 year edition)
    (aufgrund der Aktualität des Gerätes eine etwas ausführlichere Beschreibung)
  • Polar CS600

Garmin Edge 800

Auch wenn der alte Edge 800 seine besten Jahre sicherlich hinter sich haben dürfte - man könnte auch sagen, technisch nicht mehr auf dem aktuellsten Stand ist -, so ist das immer noch mein Bikecomputer der Wahl. Ich sehe einfach noch keinen Grund, ihn in Rente zu schicken.

Der Akku weist noch keine echten Verschleißerscheinungen auf (zumindest keine, die mich einschränken würden): sprich selbst die längeren Ausfahrten am Wochenende meistert er noch ohne Probleme, wobei aber irgendwo zwischen der 9-10h Marke Schluss sein dürfte. Einen Ötztaler müsste man dann schon entsprechend schnell angehen, wenn dem Edge 800 unterwegs nicht die Puste ausgehen soll :)

Von der fehlenden Konnektivität abgesehen - die ich aber nicht wirklich vermisse - bringt er fast alle Funktionen mit, die ich so brauche. 

Fast, weil bei Nutzung eines Leistungsmessers auf einige der später eingeführten Metriken verzichtet werden muss. Ob man diese benötigt oder nicht, das muss man freilich mit sich selbst ausmachen: left/right torque effect, left/right pedal smoothness und solche Sachen kennt er nicht und diese Parameter werden in der *.fit Activity auch nicht gespeichert und können daher später auch nicht ausgewertet werden.

Die letzten Anpassungen hinsichtlich der erweiterten Power-Metriken dürften mit Version 2.40 Einzug gehalten haben. Die darauf folgenden Firmware Versionen wiesen eher kleinere Korrekturen auf.

Der Vollständigkeit halber:


Als großes Plus erachte ich die vollwertige Routingfähigkeit des Gerätes, die immer noch gegeben ist. Die Nachfolger (Edge820, Edge1000, etc.) sind diesbezüglich sicherlich noch etwas verbessert worden (schnellere Prozessoren, etc.), aber das Grundhandling ist mehr oder weniger gleich geblieben.


Da man zum Teil kostenfreie routingfähige OSM Karten aufspielen kann, ist man bzgl. des Kartenmaterials relativ gut versorgt. Bisher war es mir mit dem Edge 800 immer möglich, mich im Falle des Falles korrekt navigieren zu lassen. Selbst im Ausland. Wobei ich anmerken will, dass ich die Routingfunktionen aber eher selten nutze. Wenn ich sie gebraucht habe, dann waren sie aber immer zielführend.

Ich will das Thema an der Stelle daher auch nicht weiter vertiefen, hinsichtlich der Routingfähigkeiten der aktuellen Bike-Computer habe ich mich in meinem Blog ja schon mal ausgelassen: Navigationsfähige GPS Radcomputer (von der Theorie zur Praxis)

Die letzten Versionsstände waren/sind dann auch sehr stabil. Kenner der Szene wissen sicherlich, dass diese Geräte mitunter einen gewissen Reifeprozess durchlaufen (was ich hier aber nicht weiter vertiefen will, aber es muss nicht unbedingt ein Fehler sein, die Pulle guten Weines etwas reifen zu lassen :) ) 

Kurzum, zu einem 'Neukauf' eines (gebrauchten) Edge 800 würde ich nicht mehr raten, da man bei gebrauchten Geräten nicht hineinsehen kann. Je nach Pflege wird die Akkuleistung des Gerätes irgendwann doch mal nachlassen!

Bei einem Neukauf sollte man daher doch die aktuellen Edge Geräte vorziehen, wenn man denn bei Garmin bleiben will. Allen Unkenrufen zum Trotz, bin ich, was die meisten Garmin Sportcomputer betrifft, mit dieser Marke immer relativ gut gefahren. 

Sollte bei mir aber wieder mal ein Neukauf anstehen, dann werde ich mir auch die aktuellen Wahoo Bike Computer (Wahoo Elemnt und Bolt) genauer ansehen, denn von den Spezifikationen her, können diese mit den Edge Geräten sicherlich mithalten und die Wahoos verfolgen ein paar interessante Ansätze, die Garmin bisher definitiv vernachlässigt hat (Smartphone-Anbindung, etc.)

Reviews 
(bessere als Rays Reviews wird man im Netz sicherlich schwerlich finden): 


Lezyne Enhanced Micro C GPS (10 Year edition):

Seit relativ kurzer Zeit nutze ich auch einen Lezyne Enhanced Micro C GPS Computer. Das Gerät ist wirklich sehr klein ausgefallen und bietet sich daher auch gut für Alltagsaufgaben an.

Der Lezyne Micro C ist ein vollwertiger Bike-Computer, aber dann doch nicht mit dem Edge und vergleichbaren Bike-Computern, die mehr Wert auf Datenfülle legen, vergleichbar.
Das Gerät ist hinsichtlich der Datenfelder nämlich eingeschränkt bzw. (wohl) bewusst auf das Wesentliche limitiert. Dazu weiter unten gleich mehr.

Achtung: Wer mit Altersweitsichtigkeit zu kämpfen hat - bei mir fängt das gerade erst an und ich kann die Texte auf dem kleinen Display gerade noch so einigermaßen gut lesen -, wird mit dem Micro nicht warm werden. Lezyne hat für diese Fälle aber auch größere Varianten im Portfolio.

Größenvergleich Lezyne Micro C GPS <-> Garmin Edge 800













Apropos Datenfülle: die Color-Variante des Micro kann nur max. drei (3) Datenfelder pro Seite (maximal fünf Seiten) anzeigen, was für Trainingsfahrten unter Umständen zu wenig ist.
Die anderen Lezyne Geräte dieser Serie (inkl. des Micro in der monochromen Ausführung) können anstatt der drei Datenfelder vier (4) gleichzeitig pro Datenseite anzeigen.
Beim Kauf der Micro-Serie sollte man das ggfs. beachten. Möglicherweise wird Lezyne die Farbvariante des Micro ja noch mal umgestalten, aber bisher ist das der Stand der Dinge -> mein Micro C kann jedenfalls definitiv nur max. 3 Felder pro Seite darstellen und - für die chronischen Zweifler dieser Worte - seitens Lezyne wurde mir das auch so bestätigt!.

Wenn man ein Intervalltraining bestreitet oder einen längeren Anstieg hochfährt, dann will man oftmals doch mehr Parameter einsehen können, ohne ständig durch die Displayseiten blättern zu müssen.

Wie auch immer, für mein Einsatzprofil reicht der Lezyne völlig aus (zur Not kann ich ja immer noch auf den Edge 800 ausweichen, was es für mich natürlich etwas einfacher macht, da ich das Teil einfach mal als Zweitcomputer deklariere :) ). 

Der Lezyne gehört zur neuesten Generation routingfähiger Bike-Computer, die quasi die (Routing-)Intelligenz komplett auslagern -> auf die erweiterten Routing-Eigenschaften kann nur zugegriffen werden, wenn die Geräte per Bluetooth mit einem Smartphone gekoppelt werden.

Auch hier möchte ich nochmal auf meinen Blog Post verweisen: Navigationsfähige GPS Radcomputer (von der Theorie zur Praxis)

Statische Navigation:


Turn-By-Turn Anweisung:

Mit dem ATB bin ich jetzt schon des öfteren statischen Routen nachgefahren, die ich zuvor mit dem TrainingLab Pro Routeneditor zusammen geklickt hatte.

Und das hat mit der aktuellen Firmware wirklich sehr gut funktioniert. Bei Wendepunkten poppt eine Hinweismeldung auf, die Turn-By-Turn Anweisungen werden so sehr präzise umgesetzt. Ich hatte schon ähnliche Geräte im Einsatz, bei denen das nicht so gut funktioniert hat. Vorallem wird der Abbiegehinweis früh genug eingeblendet, sodass man genug Zeit hat, zu agieren (anderenfalls kann man nämlich nur noch reagieren).

Statische Routen können über andere Webportale oder mit geeigneten PC- Programmen erstellt und dann auf den Lezyne Webservice in Form von TCX- oder GPX-Dateien hochgeladen werden oder direkt - allerdings in eingeschränkter Form - im Lezyne Routeneditor (in deren Webservice integriert) angelegt werden.

Werden (Routen)-Daten auf den Lezyne Webservice hochgeladen (und von diesem für die Geräte konvertiert) gilt es zu beachten:

  • importierte GPX Dateien können auf dem Gerät nur in Form einer Krümelspur angezeigt werden
  • wohingegen TCX-Dateien, sofern sie entsprechende Turn-Anweisungen enthalten(!), vom Lezyne Webservice dermaßen konvertiert werden, dass auch die Turn-Anweisungen auf dem Gerät genutzt werden können.

Also GPX-Routen nur als Krümelspur, TCX-Dateien, sofern sie entsprechende Turn-Anweisungen beinhalten, können auch als Turn-By-Turn-Navigation verwendet werden.

Werbung in eigener Sache: Mit dem in der TrainingLab Pro enthaltenen Routeneditor können z.B. solche Turn-By-Turn fähigen TCX Dateien erstellt werden:

Route zusammen klicken...



...und als TCX-Datei exportieren


Krümelspur:

Wenn alle Stricke reißen kann man auch der Krümelspur nachfahren. Allerdings muss man dann auf die Anzeige der 'Tachofelder' verzichten.

Es gibt immer mal wieder Szenarien, unter denen man wahrscheinlich auf die Krümelspuransicht wechseln wird: z.B. auf engen verwinkelten Wald- und Feldwegen oder immer dann, wenn die Turn-By-Turn Navigation nicht funktioniert.

Hier gibt es leider drei kleinere Handicaps, die ich nicht unerwähnt lassen will:

1.) die Krümelspur zeigt die aktuelle Position nur in Form eines sehr kleinen Fadenkreuzes an, sodass man nicht erkennen kann, auf oder in welche Richtung man sich gerade zu bewegt. Man muss also den Verlauf des Fadenkreuz einige Zeit beoachten, um zu sehen, in welche Richtung man sich bewegt. Richtig praxisfreundlich ist das nicht.

2.) Auch wird die Karte leider nicht in Fahrtrichtung ausgerichtet, sondern sie ist immer genordet. M.E. geht dadurch einiges an Überblick verloren.

3.) Und schließlich bietet das Gerät in der Krümelspuransicht bisher keinerlei Zoom-Funktionen, was mitunter die visuelle Wahrnehmung sehr erschwert.

Wie man es besser machen kann - trotz des zugegeben sehr kleinen Displays - zeigt TomTom mit der aktuellen Spark & Runner 3 Serie. Es wäre schön, wenn Lezyne hier noch mal Hand anlegen würde.

Zum Vergleich, so sieht das auf einem TomTom Spark 3Gerät aus. Dank der rotierenden Ansicht und vorallem des kleinen Richtungspfeils (anstatt eines Fadenkreuzes) kann man der Kartenskizze entnehmen, in welche Richtung man sich bewegt. Zusätzlich kann in die Kartenansicht auch in sehr einfacher Form hinein- und hinausgezoomt werden.

Das sind zwar nur drei kleine Details, die in der Praxis aber sehr viel ausmachen. Das Nachfahren der Krümelspur gestaltet sich auf der TomTom wesentlich leichter und angenehmer, dafür kann diese (Lauf)-Uhr nicht mit Turn-By-Turn Anweisungen aufwarten. Wie immer gilt auch hier, irgendeinen Tod stirbt man leider immer :-)

Nachtrag, was die zwingende Kopplung mit dem Smartphone beim Navigieren betrifft: 
wie weiter oben erwähnt, sollte der Lezyne mit dem Smartphone gekoppelt sein. 
Bei statischen Routen muss diese Kopplung streng genommen nur beim Aufspielen der Route gewährleistet sein (also immer beim Start der Route und zwar jedesmal, d.h. nach jedem Neustart des Gerätes -> die Routen liegen im flüchtigen Speicher des Gerätes). 
Dazu ist es nötig, dass das Smartphone mit dem Lezyne gekoppelt ist und auch Zugriff auf das Internet hat (WLAN oder mobile Daten), da die Routen auf dem Lezyne Webserver Server liegen. Sobald die Route auf das Gerät hochgeladen wurde, kann die Kopplung mit dem Smartphone theoretisch beendet werden, da die statische Route ja nur 'abgefahren' wird.

Bei der Echtzeit-Navigation (siehe folgende Erläuterung) verhält es sich ähnlich, nur sollte/muss auch während der Navigation eine Kopplung samt Internetzugriff dauerhaft bestehen, da der Lezyne nur über diese Kopplung eine Neuberechnung der Route anstoßen kann, wenn man sich zuweit von der zuvor berechneten Route entfernt hat (wie gesagt, die eigentliche Navigations-Intelligenz ist in der App implementiert und nicht im Bike-Computer)


Echtzeit Navigation:


Zusätzlich kann sich man über das Smartphone auch zu unbekannten Zielen navigieren lassen -> auch das klappte bisher wunderbar. Zumindest hier in der näheren Umgebung habe ich kein Problem, mich komplett auf dieses semistatische Routing zu verlassen. Die App benötigt dazu aber Zugriff aufs Internet!

Navigation via Smartphone-App:
Im Ausland wäre mir aber wahrscheinlich ein echtes routingfähiges Gerät mit einer realen Kartenansicht dann doch lieber.

Und für den Notfall sollte im Rucksack natürlich auch noch eine Papierkarte mitgeführt werden.














Konnektivität:


Ganz ohne geht es halt in der heutigen Zeit doch nicht. Da der Lezyne mit dem Smartphone gekoppelt werden kann - und das auch sollte, wenn man das Optimale aus dem Gerät herausholen will! -, bieten sich natürlich diverse Konnektivitäts-Features an. 

Mittels der Lezyne App kann ein Echtzeit-Tracking aktiviert werden, was es Dritten ermöglicht, die Trainingsrunde live mitzuverfolgen. Über den Sinn und Unsinn will ich mich an dieser Stelle nicht auslassen, aber dieses Feature funktioniert soweit. 

Man kann diversen Personen - auch über die App - einen entsprechenden Link auf das Lezyne Webportal zumailen lassen. Sobald man eine Aufzeichnung startet, erhalten jene Personen dann eine EMail und können auf dem Lezyne Webportal die aktuelle Route live mitverfolgen. 

Als Alltags-Gadget wird diese Funktionalität m.E. ziemlich überbewertet, aber im Urlaub oder bei gewissen Anlässen kann das wohl einen Sinn machen (und jetzt habe ich mich doch bzgl. der Sinnhaftigkeit ausgelassen).

Zu guter Letzt dürfen natürlich Strava Segmente nicht fehlen, aber um ehrlich zu sein, diese Funktion habe ich bisher noch nie genutzt (mir fehlt da wohl etwas der Ehrgeiz) und kann daher nicht sagen, ob Leyzne das alltagstauglich umgesetzt hat. 


Reviews:
DC Rainmaker: Hands-on with the Lezyne Super GPS Bike Computer


Polar CS600:

Der Vollständigkeit halber möchte ich an dieser Stelle noch meinen Polar CS600 aufführen, den ich immer noch am Zweitrenner fahre (wenngleich mittlerweile eher selten).

Viel zu schreiben gibt es an dieser Stelle nicht. Der CS600 stammt aus einer Zeit, als GPS Funktionen im Bikecomputer Bereich noch eher die Ausnahme waren, bzw. Garmin in diesem neuen Segment mehr oder weniger echte Alleinstellungsmerkmale für sich proklamieren konnte. Siehe: TIMELINE 2016: GARMIN, POLAR, SUUNTO, TOMTOM

Nichtsdestotrotz hatte der Polar CS600 mit seinem Erscheinen bei mir einen bleibenden Eindruck hinterlassen, da er relativ einfach zu bedienen war und eine Menüführung aufwies, die mittels kurzer Texterläuterungen der Anwender durch die vielen Funktionen leiten konnte (was damals noch eher die Ausnahme war). Ganz ohne Handbuchstudium ging es aber doch nicht.

Das Gerät war für mich - von dem in der Tat sehr gewöhnungsbedürftigen Design mal abgesehen - der perfekte Bike-Computer und wenn ich gefragt wurde dann lautete meine Antwort: "So - und nicht anders - muss ein Bike-Computer funktionieren!" (was in meinem beruflichen Umfeld mitunter die ein oder oder andere seltsame Reaktion auslöste :-) ).
Ich war so überzeugt von dem Gerät, dass ich der TrainingLab sofort das Direkteinlesen beigebracht hatte, was insofern relativ einfach war, als dass ich viel Code aus meinem alten HRMProfil Projekt übernehmen konnte :-)

Leider war Polar damals schon relativ verschlossen, was Industriestandards betraf, was ich beim CS600 aber noch verschmerzen konnte.
Dennoch es war zu diesem Zeitpunkt schon ersichtlich, dass Dynastream/Garmin mit dem recht neuen ANT+ Standard ein herstellerübergreifendes Protokoll realisiert hatte, dem ich als Anwender auf Dauer nicht wirklich entsagen konnte oder wollte.

Sei's drum, ich nutze den CS600 gelegentlich noch, aber aufgrund des proprietären Sendeprotokolls kann der CS600 z.B. nicht mit meinen sich in Verwendung befindlichen Sendern gekoppelt werden. Beim Pulsgurt ist das nicht so tragisch, aber meine SPD/CAD Sender und meinen Leistungsmesser kann ich mit dem CS600 nicht koppeln, sodass die Nutzung mittlerweile für mich doch recht eingeschränkt ist. Generell nutze ich fast nur noch ANT+ basierte Sender, was den großen Vorteil hat, dass meine ANT+ fähigen Bike-Computer mit allen Rädern mehr oder weniger kompatibel sind.

Falls der CS600 heutzutage günstig im Rahmen eines Gebrauchtkaufs angeboten wird und auf die ANT+ Kompatibilität verzichtet werden kann (leider auch nicht Bluetooth Smart fähig!) könnte man eventuell zuschlagen.

Reviews:
POLAR CS600 with Power Review


In Teil 2 werde ich mich meiner Laufcomputer annehmen und Teil 3 wird dann Fitness-Tracker beleuchten, die sich bei uns im Einsatz befinden.

To be continued...

Donnerstag, 23. März 2017

Why it's all in german (or wouldn't it be better to offer an english based webpage)?

This article is written in english and primarily addressed to english speaking people.

Sometimes I get some enquiries asking why my website is german only.
Some not german speaking people want to use the TrainingLab Pro PC software and want to support this project, but have concerns that there isn't any english based support.

Here is the answer (in a few words):

TrainingLab Pro application:

The TrainingLab Pro software supports an english and german based GUI -> so TrainingLab Pro isn't a german only PC program, but can be switched to an english interface (indeed I'm developing the TrainingLab Pro in english and do the (german) translation stuff afterwards).

The support 'thing':

Developing and offering a computer application is one thing, but you must support users, if they have any problems.

And here the problems begin:

I'm not a native english speaker, but of course I'm able to speak and write english (although not perfect, as you can possibly see while reading this blog article, but who is already perfect :) ?).

Sometimes I must ask madame Google (Google translator) for some help, so writing in english and doing english based support is more time-consuming for me.

In other words, I'm able to answer questions in english, but not at fast as I'm able to do this in german.

Status Quo:

So, regarding the TrainingLab Pro project this means:

  • the main TrainingLab Pro application supports - besides german - an english interface too
  • my TrainingLab Pro website doesn't, but is german only (at the moment)
    (this includes the author FAQ, some written instructions and the official TrainingLab Pro PDF manual, that is german only at the moment -> one must or should use Google translation service)
  • yes, english based email support exists, but due to fact that this is a more time-consuming task for me, in general, it could last some more days.  

That's the reason, why the TrainingLab Pro project website is german only and therefore limited respective to english. There are many not german speaking TrainingLab Pro users and till now, it wasn't a big deal to support them if they had needed help.
It would be worse to fake a perfect world szenario regarding this kind of (support) stuff, if I couldn't handle all this in a perfect manner. I'm a developer and not a faker!

Maybe this can improve in the future, so that a better international support will be the result, but as long as I handle this by myself, things are going on like they are going on at this time.

Conclusion:

Now you should know what's going on and why things are like they are... I prefer the honest way, therefore I won't build up a perfect world scenario that I cannot handle for the moment. Not a fake world, but a grey world (with respect to one of my former favourite HC bands called Attitude Adjustment *) :) Get the point!

Thanks for reading...

Dienstag, 24. Januar 2017

Navigationsfähige GPS Radcomputer (von der Theorie zur Praxis)

Hin und wieder werde ich gefragt, welchen Sportcomputer oder welches GPS-Gerät ich empfehlen würde.

Mal davon abgesehen, dass ich tunlichst versuche, dieser Frage samt einer Antwort aus dem Weg zu gehen, weil das eine sehr subjektive Sache ist - und mir mitunter die Nähe bzw. neuerdings auch Distanz zu diversen Firmen unterstellt wird -, kommt das immer auf das konkrete Anforderungsprofil an.

Wer während des Trainings nur Pulswerte ablesen will, um z.B. die Trainingsintensität etwas steuern zu können, dem wird ein profaner Pulsmesser reichen (die es heute schon recht preiswert zu kaufen gibt).

Wer seine Trainingseinheiten protokollieren will, der wird natürlich tiefer in die Tasche greifen müssen.

Und wer einen navigationsfähigen Bikecomputer nutzen will, der muss wissen, inwieweit ihm die Navigationsfähigkeiten wichtig sind.

Daher will ich an dieser Stelle das Thema navigationsfähige Bike-Computer aufgreifen und deren Arbeitsweisen etwas skizzieren.

Vereinfacht gesagt, gibt es zwei bzw. mittlerweile drei Varianten navigationsfähiger Bike-Computer:

  • Geräte, die eine Echtzeitnavigation bieten (das bedingt routingfähige Karten auf dem Gerät)
  • Geräte, die eine rudimentäre Navigation anhand statischer Routen, die zuvor mittels eines geeigneten Programmes oder Webservices erstellt werden müssen, bieten. Im Grunde genommen ist das eine Art Pseudo-Navigation, die funktionieren kann, aber nicht immer funktionieren muss (siehe Ausführungen weiter unten). 
  • Neue Gerätetypen, die beide Welten mittels Smartphone-Anbindung mehr oder weniger miteinander verknüpfen.


Echtzeitnavigation:

(Geräte mit echter Kartendarstellung)

Wenn Navigationseigenschaften wirklich im Vordergrund stehen, dann empfehle ich durch die Bank jene Geräte, die eine Echtzeitnavigation inklusive einer echten Kartenansicht bieten. Mit diesen Geräten kann man wirklich überall navigieren -> natürlich muss die installierte Karte das entsprechende Einsatzgebiet abdecken!

Die meisten dieser Geräte weisen ein mehr oder weniger großes Farbdisplay auf, was etwas an der Akkulaufzeit nagt. Aktuelle Geräte meistern die 10 Stunden Hürde normalerweise aber schon, sodass auch längere Tagestouren damit machbar sind. Bei noch längeren Touren (Radmarathons, Langstreckenfahrten) muss aber ggfs. eine externe Powerbank als zusätzliche Stromquelle Verwendung finden.

Oftmals wird man beim Marktführer landen, denn so groß ist der Markt nicht. Es gibt mittlerweile aber auch andere Hersteller, die sich diesem speziellen Marktsegement annehmen.

Wer jetzt allerdings eine stressfreie Navigation, wie sie in KFZ-Navigationsgeräten realisiert ist, erwartet, der wird vermutlich enttäuscht sein. Meistens handelt es sich bei den Geräten primär um Sportcomputer, die eine Navigation als Nice-To-Have mitbringen. Im Gegensatz zur Auto-Navigation ist das radtaugliche Strassennetz nicht so gut erfasst, wie das KFZ-geprägte Strassennetz, sodass die on-the-fly Navigation auch schon mal zu einer etwas kruden Streckenberechnung führen kann.
Auch die Bedienung ist aufgrund der eher kleineren Bauweise nicht mit der eines KFZ-Navis vergleichbar, da die Hersteller beim User-Interface Kompromisse machen müssen. Zwar hat sich diesbezüglich die letzten Jahre sehr viel getan, ohne Handbuchstudium wird es aber in den seltensten Fällen gehen (das fängt schon damit an, dass man sich die Unterschiede zwischen einer Route und eines Tracks erschließen sollte, was hier aber bewusst nicht das Thema ist).

Man kann eine reine Kartensicht aufrufen und dann einer bereits fertig erstellten Route bzw. Track auf der Karte nachfahren, was aber dazu führt, dass man die normalen sportbasierten Ansichten des Bikecomputers nicht mehr vor Augen hat, oder, und das ist das Tolle an diesen Geräten, die Sportseiten weiterhin aktiv geöffnet haben: sobald eine Abzweigung kommt, blendet das Navi einen Abiegepfeil ein, sodass man früh genug reagieren kann. Das klappt in der Regel recht gut.

Bei bereits fertig erstellten Routen/Tracks, die auf das Gerät aufgespielt wurden, sind die Geräte meistens so schlau, beim Verlassen der aktiven Route, eine Neuberechnung anzustoßen, um wieder auf die eigentliche Routenvorgabe zu gelangen.
Alternativ kann man von unterwegs einen Zielpunkt vorgeben -> das Navi berechnet dann on-the-fly eine Route, der man einfach nachfährt. Je nach installiertem Kartenmaterial kann auch eine Adresssuche angestoßen werden, ansonsten kann man auf der Karte einen Zielpunkt markieren und sich dorthin navigieren lassen.
Das geht natürlich nur, wenn das Gerät eine Kartenansicht bietet und eine Karte der betreffenden Region installiert ist.

Bisher war es mir immer möglich, auch von unterwegs eine Zielnavigation einzuleiten, wenn ich mich denn mal verfahren hatte. Bei der rein statischen Navigation - ohne echte Kartenansicht - ist das nicht möglich! Hier kann maximal eine Luftliniennavigation aufgerufen werden, sofern das Ziel als Wegpunkt auf dem Gerät gespeichert ist -> das heißt, man wird eine gerade Linie sehen, die auf das Ziel hinweist, was bei verwinkelten Strassen-/Wegführungen natürlich alles andere als zielführend ist. Hier ist die Kartensicht also mehr oder weniger unabdingbar.


Rudimentäre Navigation:

(Geräte ohne eigenes Kartenmaterial)

Bis vor kurzem war ich noch der Meinung, dass diese Art der Navigation - da rein statisch! - nicht wirklich taugt. Z.B. kommt es immer mal wieder vor, dass die zuvor erstellte Route nicht 100% nachgefahren werden kann, weil Umleitungen (im Wald gerne auch mal gesperrte Wege), etc. ein 100% genaues nachfahren nicht ermöglichen. Je nach Straßen- und Wegnetz kann es dann sehr schwer sein, wieder auf die im Display angezeigte Krümelspur zu gelangen. 
Mittlerweile gibt es aber Geräte, die mit einem Smartphone gekoppelt werden können, sodass diese Geräte nicht mehr rein statisch operieren, sondern mit Hilfe des Smartphones, das die (Navigations)Intelligenz mittels einer App dem Bike-Computer zur Verfügung stellt, dynamisch navigieren können (darauf werde ich weiter unten eingehen).

Die Vorgehensweise ist dabei immer die Gleiche. Man muss eine bereits erstellte Route auf das Gerät übertragen, der man dann mehr oder weniger - eher mehr! - akribisch nachfahren muss. Bei der Krümelspurnavigation kann man oftmals fertig designte GPS-Routen oder Tracks verwenden, wie man sie im Internet zuhauf findet.


Manche Geräte, die eine sogenannte 'Turn-by-Turn'-Navigation bieten, verlangen hingegen oft besonders designte GPX-Dateien, die online mit bestimmten Webportal Editoren oder mit PC-Programmen erstellt werden müssen. Eines dieser Tools wäre z.B. der in der TrainingLab Pro integrierte Routeneditor (den ich aber aus diversen Gründen zu diesem Zweck nicht empfehle!).

Diese speziellen GPX-Dateien werden um statische Pfeil-Attribute ergänzt. Und hier liegt dann auch das große Problem, da die Pfeilvorgaben eben für jeden Wegpunkt statisch sind -> sobald man einen Wegpunkt verpasst hat, kann das dazu führen, dass diese ganze statische Routenvorgabe nicht mehr funktioniert, weil das Gerät nicht weiß, wo es sich auf der nichtvorhandenen Karte befindet.

Oftmals sind die Routenwegpunkte in der Anzahl auch noch begrenzt (50-100 Routenpunkte), was zufolge hat, dass man Touren ab einer bestimmten Länge bzw. Komplexität nicht mehr gescheit abbilden kann. Letztlich muss nämlich an jeder Kreuzung, die eine Richtungsänderung bedingt, ein Routenwegpunkt gesetzt werden.

Vorab noch ein kleiner Exkurs bzgl. dieser Turn-by-Turn Navigation und deren statischen Charakters:

Bei den mir bekannten Geräten müssen die Turn-by-Turn Vorgaben wirklich statisch in eine GPX-Datei geschrieben werden (meistens verwenden diese Geräte dafür spezielle XML-Tags, die nicht standardisiert sind, sondern jeder Hersteller kocht hier sein eigenes Süppchen).

Das heißt, der Routeneditor muss beim Designen der Route die Ausrichtung der Abbiegepfeile - ausgehend von der jeweils aktuellen Position/Fahrtrichtung, die das GPS-Gerät an den Routenwegpunkten aufweisen wird! - berechnen und entsprechend pro Routenwegpunkt einbetten.

Hier ein Screenshot, der das hoffentlich etwas verdeutlicht.

Sobald man nun die Kette der vorgegebenen Routenwegpunkte durchbrochen hat und sich aufgrund einer anderen Position dem kommenden Routenwegpunkt in einem anderen Winkel nähert, kann das Gerät das nicht mehr abbilden.
Manche Geräte sind immerhin so schlau, beim gegensätzlichen Abfahren der Routen (als Startpunkt fungiert also der Endpunkt), die Pfeile entsprechend umzudrehen (sofern das Gerät erkennt, dass die Route in der anderen Richtung abgefahren wird, aber das war es dann auch schon mit der Automatik).

Es gibt Geräte (z..B. die alten Garmin Outdoor Handhelds und sicherlich auch noch Andere), die auf die zuzufahrenden Wegpunkte mit einem dynamischen Pfeil zeigen (als Luftlinie). Das hat Vor-, aber auch Nachteile:

  • Wenn man z.B. bei einer arg verwinkelten Strassenführung nicht auf der Luftlinie zum anvisierten Wegpunkt zufahren kann (bei diesem Screenshot beträfe das die leicht abweichende Startposition, die ich unten rechts vom eigentlichen Startpunkt markiert habe). 
  • Oder die Trägheit des Pfeiles dazu führt, dass man bei höheren Geschwindigkeiten beim Einleiten der Kurve nicht schnell genug agieren kann.

Sofern man aber vom Startpunkt aus immer diesen dynamischen Pfeilen folgen kann, würde das Einen sicher zum Ziel führen (die ersten erschwinglichen Garmin Outdoor Handhelds waren daher auch bei Wanderern sehr beliebt).

Wie auch immer, die mir bekannten Geräte, die als Turn-by-Turn fähig beworben wurden, haben alle statisch operiert; anders könnte man wohl die Abbiege-Hinweismeldungen, die ca. 20-100 Meter vor dem kommenden Abbiegevorgang eingeblendet werden, auch nicht realisieren.

Ggfs. müsst ihr Euch halt schlau machen, wie das jeweilige Gerät in dieser Hinsicht funktioniert. Ich kann mir gut vorstellen, dass dieses statische Routing-Verfahren mit der Kopplung an Smartphones in naher Zukunft durchaus noch optimiert werden kann (erste Ansätze gibt es ja bereits, die aber m.E. noch nicht alles Machbare ausreizen). Siehe Ausführungen weiter unten.

Die erste Generation dieser technischen Navigationswunderwerke wies eine reine Pfeilnavigation (Turn-by-Turn) auf. Das Gerät navigierte also entlang einer festen Route. Mittels einer statischen Pfeilvorgabe musste man sich von Wegpunkt zu Wegpunkt entlang hangeln. Wenn man einen Wegpunkt nicht genau gekreuzt hat, konnte das dazu führen, dass die gesamte Navigation aus dem Tritt kam. 
Bessere Geräte konnten dann zumindest wieder zum nicht gekreuzten (= übersprungenen) Wegpunkt zurück navigieren, aber das konnte dazu führen, dass man immer wieder im Kreis navigiert wurde.

Ich kann diese Geräte jedenfalls nicht empfehlen, bzw. ich selbst bin mit diesen Geräten nie richtig warm geworden. 
So richtig funktioniert diese Navigationsart im Grunde genommen nur auf einem freien Feld oder in Gewässern, weil man unter diesen Bedingungen immer wieder auf den anvisierten Wegpunkt (in Form einer virtuellen Luftlinie) direkt zufahren kann. Im normalen Bike-Einsatz ist das eher schwer machbar.

Diese Geräte haben aber durchaus ihre Daseinsberechtigung, z.B. im Geocache-Bereich. Die Kartenbasierten Navis sind da fast schon wieder zuviel des Guten bzw. wird die Geocache-Sucherei dann zu einfach. 
Auch in der Schiffahrt findet diese rein Wegpunkt basierte Navigation Anwendung, um seichte Stellen und Untiefen zu umschiffen. Und in der Luftfahrt wird/wurde diese Navigationsart auch genutzt.


Die zweite Generation zeichnet sich dadurch aus, dass neben der Pfeilvorgabe auch eine Krümelspuransicht eingeblendet werden kann. Auf diese Weise kann man immerhin dem auf dem Display angezeigten Track nachfahren. Allerdings muss hierfür immer die Kartenansicht aktiv sein, sonst kann man der Krümelspur logischerweise nicht folgen.

Mitunter bieten diese Geräte auch eine Einblendung von Abbiegepfeilen (Turn-by-Turn) an, sodass man während der Fahrt die sportspezifischen Seiten weiterhin aktiviert haben kann und das Navi kurz vor den Abzweigungen einen Abbiegepfeil einblendet.
Das klingt in der Theorie gut, aufgrund der Tatsache, dass die Pfeilvorgaben hier aber auch statisch in der GPX-Datei eingebunden sind, trifft das bereits zuvor Gesagte zu. Sobald man die ursprüngliche Routenvorgabe verlässt, wird es mitunter holprig.

Da die Pfeile wirklich statisch in der GPX-Datei eingebunden sind (also z.B. als LEFT, RIGHT, etc. deklariert), funktioniert diese Turn-by-Turn Anzeige nicht, wenn man sich dem Routenwegpunkt in einem anderen Winkel als den ursprünglich geplanten annähert. Das kann durchaus vorkommen, wenn man einen Routenwegpunkt umfahren hat. Mit anderen Worten, sobald die Kette der Routenwegpunkte unterbrochen wurde - das Navi arbeitet diese Kette einfach nur sequentiell ab -, kann es Probleme mit dieser Turn-by-Turn Navigation geben.

Es gibt Geräte, die das etwas egalisieren können, aber das sind meistens Navis, die keine statischen Abbiegepfeile einblenden, sondern den Pfeil zum nächsten Routenpunkt immer direkt auf diesen ausrichten. Das ist im engeren Sinne keine Turn-by-Turn Navigation, weil das einem Luftlinienrouting mit Hilfe eines Kurszeigers entspricht (mit den weiter oben beschrieben Problemen).

Das ist auch der Hauptgrund, weshalb ich meinen Routeneditor - der mir lediglich als eine Art private Machbarkeitsstudie diente - für derlei Aufgaben nicht empfehle.

Ich habe die Erfahrung gemacht, dass diese Art der Navigation funktionieren kann, aber nicht muss. Bei großen Rennrad-Rundtouren hatte ich einige positive Ergebnisse, sobald ich aber auf arg verwinkelte Straßenführungen gestoßen bin, war dieses statische Navigieren eher schwierig bis nicht mehr praktikabel.

Ich will/muss aber anmerken, dass es auch viele User gibt, die mit dieser Art der statischen Navigation gut zurechtkommen. Hier sind jene Geräte klar im Vorteil, die den User auf eine Abweichung entsprechend hinweisen (was aber nicht alle Geräte wirklich gut machen!).


GPS Bike Computer mit Smartphone Anbindung:

(Geräte mit Zugriff auf routingfähige Karten mit Hilfe einer Smartphone-Anbindung)

Die dritte Generation - wie ich sie jetzt nenne - hat jene Navigationsart, die auf einer im Gerät hinterlegten routingfähigen Karte verzichtet, nun wieder aufgegriffen, stark verbessert und dank der Anbindung an ein Smartphone, um ein dynamisches Routing ergänzt (da über das Smartphone nun doch auf eine routingfähige Karte zugegriffen werden kann bzw. die dynamische Routenberechnung direkt von einer Smartphone App an den Bikecomputer durchgereicht wird).

Vertreter dieser neuen Generation wären z.B. der Wahoo Elemnt (der allerdings auf eigenes Kartenmaterial im Gerät zugreifen kann und demzufolge streng genommen zur Kategorie der Echtzeitnavigationsgeräte zählt, wenngleich meines Wissens die aktive Routenberechnung beim Elemnt vom Smartphone übernommen wird *) und die neue Lezyne Enhanced GPS Serie (10 Year Collection).
(* diesbezüglich muss ich mich nochmal schlau machen)

Betont werden muss, dass hierbei die dynamische Navigation mit der Kopplung der Smartphone App und vorallem deren Qualität steht und fällt (sowohl was die physische Kopplung - im allgemeinen Bluetoothverbindung - als auch die Qualität der App betrifft).

Ich habe testweise einen Lezyne Micro C in Betrieb und muss sagen, dass trotz meiner anfänglichen Skepsis dieses durch das Smartphone unterstützte Routing bisher recht gut funktioniert hat. Echte längere Testfahrten stehen aber noch aus und mein Testgerät weist auch noch die ein oder andere kleinere Kinderkrankheit auf, weshalb ich den Micro C derzeit (noch) nicht weiterempfehlen kann. Die Ansätze gefallen mir aber recht gut und ich werde das Gerät noch eine Zeitlang testen und hoffen, dass Lezyne noch das ein oder andere Firmware-Update nachreichen wird. Womöglich werde ich später ein Review zu diesem Gerät beisteuern.

Dieses Routing ist quasi semistatisch, das heißt, die Route wird als statische Vorgabe an das Gerät gesendet und im Gerät selbst Wegpunkt basiert abgearbeitet. Der Clou ist, dass das gekoppelte Smartphone die Route neuberechnet, sobald man von der Vorgaberoute abweicht.
Das Gerät ist dabei so schlau, bei kleineren Abweichungen den User erstmal darauf hinzuweisen, umzukehren und erst wenn ein gewisses Delta erreicht ist - sprich die Abweichung zum nächsten Wegpunkt zu groß ist -, eine Routen-Neuberechnung anzustoßen. In dem Fall wird der Part sozusagen an die Smartphone App übergeben, die im Hintergrund eine neue Route zum anvisierten Zielpunkt berechnet.

Das ist zwar keine Echtzeitnavigation - man kann das nicht genug betonen! -, wie ich sie weiter oben empfohlen habe, aber als Notlösung ein geeigneter Ansatz.
Ich habe mit diesem Gerät jetzt ein paar kleinere Testrunden gedreht und das hat soweit wirklich recht gut funktioniert. 

Again, das ist definitiv keine Echtzeitnavigation aber auch kein Vergleich zu den Pseudo-Navigationsgeräten der ersten und zweiten Generation, sondern durchaus ein Ansatz, der als Mittel zum Zweck taugen kann. Der hier beschriebene Lezyne Micro C ist wirklich sehr klein, sozusagen ein Gerät für Puristen, die kein großes Navi am Renner mit herumschleppen wollen :)

Ich hoffe damit etwas Licht gespendet oder zumindest die grundlegenden Eigenschaften dieser Geräte etwas beleuchtet zu haben. Wie gesagt, die Frage nach dem geeigneten Gerät ist sehr subjektiv und die Technik dahinter befindet sich im ständigen Wandel (die Anbindung der Geräte an Smartphones ist noch relativ neu).

Anmerken möchte ich, dass ich bei heimischen Rennradrunden sehr selten vorab erstellten Routen nachfahre, sondern selbst in unbekanntem Terrain einfach drauf losfahre und die Navigationsfähigkeiten meines Navis deswegen so gut wir gar nicht ausnutze.

Im Urlaub hat mir mein Garmin Edge800 hingegen schon sehr gute Dienste geleistet, sodass die Papierkarte meistens im Rucksack verbleiben konnte.

Insofern ist die Echtzeitnavigationsklasse die eierlegende Wollmichsau bzw. kommt dieser recht nahe. 

Hier im heimischen Terrain würde mir aber auch ein Gerät der dritten Generation genügen, weshalb ich mir demnächst neben dem Lezyne auch den Wahoo Elemnt noch einmal genauer ansehen werde (nicht nur des seltsamen Namens wegen :-) )

To be continued...

Montag, 23. Januar 2017

Working with Prototypes Part 2 ('Smooth' ist anders :-) )

Wieder mal Festplattenputz gemacht :-)

Vorab: diese Bilder sollen bitte nicht dazu animieren, diverse Interfaces nachzubauen (anstatt diese käuflich zu erwerben), wobei im Zeitalter der USB-MassStorage Devices und der drahtlos Verbindungen (Bluetooth, ANT+, WLAN, etc.) die Tage dieser Auslese-Interfaces eh gezählt sein dürften.

Ich will auch gar nicht groß rumlabern, sondern einfach nur ein Bild sprechen lassen.


Wenn man Glück hat wird man als Softwareentwickler schon recht früh in den Entwicklungsprozess eingebunden. Dann ist die (Serien)Produktion der Geräte natürlich noch nicht angelaufen, sondern man muss, wie bereits in einem vorangegangenen Beitrag erläutert, mit den ersten Prototypen vorliebnehmen (was sehr spaßig, aber auch recht stressig sein kann, wenn die Hardware noch nicht tut, was sie eigentlich soll und man nicht zum Implementieren kommt, sondern als Tester und Bugmelder den Firmware-Entwicklern zuspielen muss).

Kurzum, irgendwie muss man die Gerätedaten ja auslesen und früher kamen dabei des öfteren proprietäre Interfaces zum Einsatz. Wenn sich diese noch nicht in der Produktion befanden, dann musste eben gebastelt werden.

Hier sind zwei dieser Bastel-Interfaces zu sehen, die mir damals zum Teil von den Firmen zur Verfügung gestellt wurden (teilweise war auch Selberbasteln angesagt). In der Endproduktion sahen diese Interfaces dann doch merklich anders aus... :-)

Heute ist das wie gesagt alles etwas einfacher. Mittlerweile werden die Daten häufig drahtlos in die Cloud hochgeladen oder es genügt, ein USB-Kabel anzuschließen, um die Geräte als MassStorage Device anzusprechen.

Aber ganz ausgestorben sind diese Interfaces noch nicht, meinen Garmin Forerunner 620 kann ich z.B. alternativ mittels des dazugehörenden Lade(Interface)-Kabels auslesen, was trotz Cloudanbindung des FR620 per WLAN Übertragung von mir immer noch gerne genutzt wird, um die Aufzeichnungen in die TrainingLab Pro zu pumpen..

To be continued...

Dienstag, 27. Dezember 2016

Working with Prototypes (am Anfang ist alles eine Nummer größer :-) )

Und wieder bin ich beim Bilder-Aufräumen auf ein paar lustige Sachen gestoßen... 

Je nachdem, wie früh man in die Produktentwicklung einbezogen wird, laufen einem ab und an auch mal die ersten Prototypen über den Weg :-)
Kenner der Materie können wahrscheinlich erahnen, um welches Gerät es sich auf dem Foto handelt.

Zugegeben, heute fallen die Prototypen meistens kleiner aus, bzw. ähneln oft schon sehr den fertigen Endprodukten, aber Ende der 90'er Jahre (und auch noch Mitte 2000 :-) ) hatte man zum Teil noch mit echten handverlöteten Prototypen zu tun, die, was die Optik betrifft, noch sehr wenig mit dem angedachten Produkt gemein hatten.



Bei dem hier abgebildeten Projekt wurde ich als externer Entwickler softwareseitig schon sehr früh einbezogen, da ich zwei Programme - mein eigenes und deren Hausanwendung, das ich interimsweise übernommen hatte - an das neue Gerät anpassen musste. Auf diese Weise konnte ich sehr früh mit den Hardware und Firmwareentwicklern zusammenarbeiten. Seitens des Herstellers wollte man - soweit ich das als Außenstehender abschätzen konnte - gegenüber den Vorgängergeräten weitestgegend kompatibel bleiben, wohl auch, um etwaige Anpassungsarbeiten - soweit möglich - gering zu halten. Letztlich wies dieses neue Gerät dann aber doch ein mehr oder weniger abweichendes Datenformat auf, was zufolge hatte, dass die softwarseitigen Anpassungen doch etwas aufwendiger waren.
Die Gerätekommunikation wurde meinerseits in einer zentralen DLL ausgelagert, die von den anderen Programmen genutzt wurde, um die weiteren Anpassungsarbeiten in deren mitgelieferten (Haus)-Anwendungen gering zu halten. 
Auch wenn es sich bei dieser Import-DLL um (noch) kein echtes Plugin-System handelte, lehnt sich die in der TrainingLab Pro verwendete Import-Plugin Schnittstelle etwas an diese DLL an (was die Kernfunktionen und deren Namensgebung betrifft).

Das war ca. Mitte 2000, der Sport-Gadget-Markt war damals noch im Umbruch bzw. erfuhr gerade eine echte Neuausrichtung, da der jetzige Branchenprimus, der zuvor sein Portfolio primär am reinen GPS Segment  ausgerichtet hatte, den Sport-Gadget Markt für sich entdeckte. 

In dem Zusammenhang ist jene Auflistung TIMELINE 2016: GARMIN, POLAR, SUUNTO, TOMTOM - Análisis de productos. ZitaSport wirklich sehr interessant und lesenswert!

Mit Garmins Eintreten in den Sport-Gadget Bereich hatte sich der Markt doch sehr verändert, da die Mitbewerber nun gezwungen waren, schnell GPS-Funktionen aufzugreifen, was nicht jedem Mitbewerber auf Anhieb gelang. 
Garmin hatte auf diesem Gebiet ja eine Menge Know-How, das sie einbringen konnten, für die Konkurrenz war das hingegen meistens Neuland. 
Die Folge waren anfangs sehr abenteuerliche Geräte, welche z.B. den GPS-Empfänger in separaten Sensoren auslagerten und nur rudimentäre GPS-Funktionen aufgreifen konnten, wohingegen Garmin mit der Edge Serie bereits bei den höherwertigen Geräten eine Kartenunterstützung samt echter Navigation auffahren konnte.

Nebenbei hatte Garmin auch noch ein paar reine Sport-Computer wie z.B. den Forerunner 50 auf den Markt geworfen, auf den ich - in etwas anderem Gewand - lustigerweise Jahre später bei einem anderen Projekt noch einmal stoßen sollte :-) -, sodass sie auch im GPS-losen Segment (günstigere Geräte, lange Batterielaufzeiten, etc.) vertreten waren. 

Ich glaube, die Amerikaner haben alles richtig gemacht.-> wer weiß, wie der Markt heute sonst aussehen würde, mal darauf abzielend, dass heute ein integrierter GPS-Empfänger fast ein Must-Have ist (selbst bei meinen Laufcomputern möchte ich darauf nicht mehr verzichten).

To be continued...

Mittwoch, 21. Dezember 2016

Tagesbilanz = Null (Part 2: Reparaturmaßnahmen)

Wie bereits im ersten Teil angekündigt, möchte ich noch einige Reparaturmöglichkeiten vorstellen.
Je nach Ausgangslage und Art der Daten (textbasiert oder binär), sind die Reparaturmöglichkeiten allerdings begrenzt. Auch hängt der zu erwartende Erfolg der Reparaturmaßnahme von der Ursache, die jene korrupten Daten bedingt hat, ab (komplett versaubeutelte Daten wird man eher nicht mehr restaurieren können).

Diese Kurzanleitung kann natürlich nicht das ganze Spektrum an Reparaturmaßnahmen und Datenformaten abdecken und soll in erster Linie als eine Art Anregung verstanden werden. Letztlich müsst ihr auch selbst einschätzen, ob eine Reparatur der Daten überhaupt lohnt oder nicht.

Vorab auch noch folgender Hinweis: die meisten Entwickler - mich inbegriffen - versuchen ihre Programme stetig zu verbessern und auch bzgl. korrupter Daten fehlertoleranter zu machen. Manchmal kann es daher lohnen, die aktuellste Programmversion zu installieren oder - falls das nichts bewirkt - auch mal den Entwickler des Auswertungsprogrammes direkt anzumailen.
Z.B. konnte ich anhand einiger Muster-Fitfile-Dateien, die mir ein User freundlicherweise zur Verfügung gestellt hat, den Fitfile Import diverser Bryton Geräte, die - um es vorsichtig zu formulieren, etwas gewöhnungsbedürftige Fitfiles erzeugen -, in der TrainingLab Pro merklich robuster gestalten.

Wenden wir uns zuerst den textbasierten Datenformaten zu.


Textbasierte Daten:

Bei textbasierten Daten (*.gpx, *.tcx, etc.) bedingen häufig kleinere Formatierungs- und Syntaxfehler, die man - sofern etwas Grundkenntnisse vorhanden sind! - relativ einfach mittels eines Texteditors reparieren kann, Einleseprobleme.

Viele textbasierte GPS-Datenformate basieren auf dem XML Format. Dieses Containerformat zeichnet sich dadurch aus, dass die Parameter in sogenannten Tags eingebettet sind. Wenn z.B. ein Abschluss-Tag fehlt, dann kann dieser simple Syntaxfehler dazu führen, dass ein XML-Parser die Datei als ungültig interpretiert.

Ohne jetzt zu sehr in die Tiefe zu gehen, bei XML-basierten Daten verwende ich gerne den XML-Editor, wenn denn mal ein manuelles Eingreifen vonnöten sein sollte.
Dieser Editor führt unter dem Menüpunkt Tools eine MSXML-Validate Funktion auf, die dabei helfen kann, Syntaxfehler zu finden. Bei sehr großen XML-Dateien sucht man sich sonst einen Wolf, wohingegen diese Funktion die fehlerhafte Stelle normalerweise direkt anspringt.
Auf diese Weise könnt ihr also relativ einfach die fehlerhafte Stelle ausfindig machen und im XML-Editor direkt korrigieren.

Hier fehlt lediglich ein fehlendes </trkpt> Tag, das, nachdem es von mir händisch eingefügt wurde, wieder eine valide GPX-Datei zufolge hatte.





In Part 1 habe ich den Problemfall schwache Batterien gleich an erster Stelle aufgeführt (natürlich nicht grundlos). Zur Erinnerung, in dem von mir als schlechtesten Fall bezeichneten Szenario hatte ich beschrieben, dass die Geräte unkontrolliert beendet werden und daher korrupte, da nicht korrekt abgeschlossene Dateien, die Folge sein können.

Unter Umständen genügt es also, die fehlenden Abschluß-Tags anzufügen, um wieder eine valide GPX oder TCX Datei zu haben. Man wird also wahrscheinlich...

  1. den Trackpunkt (<trkpt>) sauber abschließen müssen (inkl. der dort eingebetteten Parameter)
  2. und die Abschluss-Tags der XML-Datei (z.B. </trkseg>,</trk>,</gpx>) 
... ergänzen müssen und hat hinterher im besten Fall wieder eine valide XML-Datei, die von Auswertungsprogrammen problemlos importiert werden kann.

Auf diese Weise konnte ich schon etliche GPX/TCX Dateien restaurieren. Die fehlenden Datenpunkte könnt ihr natürlich nicht mehr retten, aber wenn ihr Glück habt, fehlen nur die letzten paar Kilometer einer langen Tour, was man wohl einigermaßen verschmerzen kann.

Weitere Hilfestellungen bzgl. korrupter GPX Dateien gibt's auch in einem Beitrag im Naviboard und auch Madame Google wird den ein oder anderen Hinweis besteuern können.

Es gibt natürlich noch (viele) andere textbasierte (Aufzeichnungs)-Formate (z.B. *.csv, *.hrm). Meiner Erfahrung nach gibt es mit diesen Formaten eher selten Probleme, was auch darin begründet liegt, dass es sich dabei um keine echten Protokolldaten handelt, sondern diese Formate synthetisch von zwischengeschalteten Tools und Programmen (oder den Geräten selbst, allerdings erst nach Abschluss der Aufzeichnung!) generiert werden. Kein mir bekanntes Gerät (reine Datenlogger mal ausgenommen) zeichnet die Daten - mit Ausnahme von *.gpx und *.tcx Dateien - intern in einem textbasierten Format auf.

Binäre Daten:

Bei binären Daten (*.fit und diverse proprietäre Formate) sind die Reparaturmöglichkeiten doch relativ begrenzt. Zum einen hat man keinen direkten Zugriff auf die einzelnen Parameter, zum anderen ist schon etwas Informatikwissen unabdingbar, wenn man an binären Daten herumpatchen will.

Daher will ich an dieser Stelle nur auf zwei Reparaturwerkzeuge für das FitFile-Format verweisen, die quasi automatisiert versuchen zu retten, was noch (und für den Normaluser nicht mehr) zu retten ist.

  • FitFile Repair Tool
    (Wirklich mächtiges offline FitFile Repair Tool, das neben der eigentlichen Reparatur korrupter Fitfiles viele weitere Funktionen bietet. Defacto handelt es sich hier um eine sehr mächtige Toolbox. Mittlerweile handelt es sich dabei auch nicht mehr nur um eine Toolbox, sondern man kann das Tool schon als eigenständiges Auswertungsprogramm erachten.
    In eigener Sache: Mathias, der Autor des FitFile Repair Tools, hat mir bei der Implementierung des Strava Uploaders - Strava ist bzgl. des FitFile Formats nämlich sehr wählerisch -, mit Rat und Tat zur Seite gestanden. Daher will ich an dieser Stelle die Gelegenheit ergreifen, mich bei ihm noch mal explizit zu bedanken.)
  • Online Fit Repair Tool

Auch hier gilt, bevor ihr euch bzgl. vermeintlich korrupter *.Fit Dateien verrückt macht, erstmal schauen, ob es vielleicht eine neue Version des Auswertungsprogrammes eurer Wahl gibt, das mit den betreffenden Dateien unter Umständen fehlertoleranter umgehen kann. 

Garmin (resp. Dynastream) hat unlängst das FIT 2.0 Format eingeführt, welches gegenüber dem FIT 1.x Format grundlegend erweitert wurde. Das hatte zur Folge, dass Auswertungsprogramme, die das FIT 1.x Protokoll unterstützten, FIT 2.0 basierte Fitfiles nicht (mehr) importieren konnten, sondern der FitFile-Import zuerst entsprechend angepasst werden musste (siehe auch meinen Beitrag im Tour Forum und die enstprechenden Ausführungen bzgl. der TrainingLab Pro Vers. 7.12, die dahingehend angepasst wurde).

Das sind übrigens keine Programmfehler, sondern das Format hat sich wie gesagt grundlegend geändert und wurde Seitens Dynastream auch als groundbreaking deklariert.

Dies mal als kurze Einführung zum Thema Datenrettung diverser Sportprotokolldaten.

Again, mir ist klar, dass ich hier nur ein paar Anregungen geben konnte.

Fazit: mittels etwas Forscherdrang kann man den ein oder anderen Komplementärschaden egalisieren. Zum Teil wird man um diverses Fachwissen, welches man sich aber mit Madame Googles Hilfe aneignen kann, nicht umhin kommen. Auch kann man auf die Dienste diverser Reparaturtools zurückgreifen, die zum Teil wirklich Erstaunliches leisten.

To be continued...


Sonntag, 11. Dezember 2016

Tagesbilanz = Null (Part 1: Gründe für korrupte Aufzeichnungen)


Achtung, dieser Beitrag fällt etwas länger aus!


Fast jeder Datensammler kennt das, man hat eine schöne längere Ausfahrt hinter sich - oder eine echt harte Trainingseinheit, bei der die SPD-Rekorde nur so gepurzelt sind -, will dann hinterher die Daten am heimischen PC auswerten und plötzlich fällt einem die Kinnlade runter, weil das blöde heimische Auswertungsprogramm sich weigert, auch nur irgendwas Sinnvolles anzuzeigen.
Jetzt mal vom speziellen Fall abgesehen, dass das Auswertungsprogramm der Wahl nur Schluckauf hat - sprich ein hoffentlich behebbarer Bug, die Auswertung der Daten verhindert -, kann auch der Worst Case (Fall) eingetreten sein: korrupte Aufzeichnungsdaten.

In diesem Beitrag zähle ich einige mögliche Gründe auf, die mir bei meinen Projektarbeiten für diverse Firmen in den Jahren so begegnet sind.

In einem späteren Beitrag werde ich dann mögliche Reparaturmaßnahmen und Prophylaxemaßnahmen erörtern (wobei ich gleich anmerken will, dass die Möglichkeiten einer Datenreparatur - je nach Datenformat - doch leider sehr begrenzt sind :-( ).

Gnome-battery-caution

Schwache Batterien:

Meistens sind schwache Batterien der Grund des Übels, wenngleich die meisten Hersteller dieses Problem mittlerweile etwas besser im Griff haben und rechtzeitig Warnmeldungen auf dem Gerätedisplay anzeigen. Wirklich verlassen sollte man sich auf die Warnmeldung aber nicht, genauso wenig, wie man sich nicht alleine auf das rot (blinkende) Niedrig-Ölstand-Warnzeichen im PKW verlassen sollte, denn dann kann es unter Umständen schon zu spät sein -> get the hint!

Gerade jetzt im Winter, wo die Temperaturen auch mal die Null-Grad-Schwelle unterschreiten, kann bei einer schwächelnden Batterie, die Batteriespannung urplötzlich einbrechen und je nachdem, wie das Gerät die Daten protokolliert, kann das verheerende Folgen haben.

Im besten Fall schaltet sich der Bike-/Laufcomputer kontrolliert aus, speichert aber zuvor noch die Aufzeichnung definiert ab, sodass lediglich das Ende der Trainingseinheit fehlt.

Im schlechtesten Fall schaltet sich der Computer unkontrolliert aus, sodass korrupte Aufzeichnungen der Fall sind. Mitunter kann man diese mit speziellen Reparaturtools - oder bei textbasierten Formaten wie *.gpx, *.tcx, etc. auch mit Hilfe eines profanen Texteditors - noch reparieren.

Und dann gibt es noch den - zugegeben - sehr speziellen Fall, den ich dazwischen einordnen würde: der Bike-Computer ignoriert die zu niedrige Batteriespannung und schreibt weiter Daten in seinen Speicher. Aufgrund der zu niedrigen Spannung, kann er diese aber nicht mehr korrekt in den (Flash)-Speicher schreiben, sodass korrupte Daten das Ergebnis sind, die wirklich fern von gut und böse sind. Z.B. springende Temperaturwerte von einigen 100 Grad, HF-Werte, die jeden Kardiologen in den Wahnsinn treiben und Trittfrequenzwerte, die jeden Profi-Bahnsprinter zum Möchtegern-Amateur degradieren, um nur mal Einige zu nennen.
Leider ist dieser zwischen den anderen beiden Fällen eingeordnete Spezialfall der Worstcase, da man hier definitiv nichts mehr reparieren kann. Die Daten sind dermaßen korrupt,dass man sie auch mittels Glättungsfilter, etc. nachträglich nicht mehr kaschieren kann. Bei diesem speziellen Fall stehen dann auch die Support-Hotlines oftmals vor einem Rätsel (oder tun zumindest so :-) )

Kleiner Exkurs: Während einer meiner Projektarbeiten bin ich auf einen Gerätetypen gestoßen, bei dem sich das Phänomen derart geäußert hat, dass sich die aufgezeichneten Daten im Gerät selbst, sogar noch nach Abschluss der Speicherung(!), verändert haben. Ein Hardware-Experte hat mir das so erklärt, dass die Spannung zu gering war, die Daten korrekt ins Flash zu schreiben, sodass sie in einem nicht definierten Zustand dort abgespeichert wurden und einzelne Bits in den Speicherzellen hin-und herspringen können (jetzt sehr vereinfacht und aus dem Gedächtnis von mir wiedergegeben, für mich klang das recht plausibel).
-> wenn man softwareseitig binäre Datenströme einliest und sich diese im Nachhinein bei jedem erneuten Auslesen immer wieder verändern, dann zweifelt man irgendwann sogar an seinen Programmierkünsten, weil man als Softwaremensch von einem festen Istzustand ausgeht (wer wie ich aus der Nähe von Mainz kommt, der glaubt dann irgendwann, die benachbarten Mainzelmännchen oder Pumuckel himself im Haus zu haben!)

Fazit schwache Batterien: einem schwächelnden fest verbauten Akku, der am Ende seiner Lebenszeit angekommen ist, kann man das leider nicht so einfach ansehen (eine merklich geringere Laufzeit sollte immer aufhorchen lassen).
Bei wechselbaren Batterien/Knopfzellen sei folgendes angemerkt: es gibt minderwertige Knopfzellen, die zwar von einem Batterietester als (noch) gut bewertet werden - Ruhespannung im normalen Referenzbereich -, die aber unter Last urplötzlich einbrechen. Der User meint also, (noch) gute Batterie zu verwenden, weil sie im Ruhezustand ausreichend Spannung aufweisen, aber eben nur im Ruhezustand! Das gestaltet die Fehlersuche nicht gerade einfacher. Auch ich bin schon ein paar Mal in diese Falle getreten ('kann nicht sein, die Batterien sind 100% gut')!
Leider können sogar Markenzellen mitunter so ein Verhalten aufweisen, wobei das eher die Ausnahme sein dürfte.
Worauf ich abschließend hinaus will: wenn man regelmäßig derart geartete Probleme hat, dann kann es auch mal angezeigt sein, zum Test eine neue Batterie/Knopfzelle aus dem hiesigen Fachgeschäft für teueres Geld zu erwerben, die ein noch garantiert frisches Haltbarkeitsdatum aufweist. Auch Batterien unterliegen einem Verschleiß! (hat man günstig ein Sortiment Knopfzellen erworben, kann es nämlich gut sein, dass die ganze Serie minderwertig ist)

Funktioniert es damit, dann ist man schon mal einen großen Schritt weiter!

Funktioniert es damit aber nur für kurze Zeit (wenige Tage), dann kann das Gerät einen Hau weghaben (z.B. interner Kurzschluß und/oder Kriechströme, der/die dazu führt, dass ständig Strom gezogen, was z.B. nach einem Wasserschaden auftreten kann).

Das gilt übrigens auch für die externen Sensoren -> geflutete SPD/CAD-Sensoren erholen sich mitunter wieder nach ein paar Tagen, wenn das Wasser verdunstet ist, aber wenn man Pech hat, oxidieren z.B. die Inneren und der Sensor ist definitiv kaputt (mir sind schon einige SPD/CAD Sensoren auf diese Weise kaputt gegangen)..

Mangelnder Speicherplatz:

Früher wurden die Daten gerne in einem Ringspeicher abgelegt, was zur Folge hatte, dass bei einem Speichermangel ältere Daten überschrieben wurden. Speichermangel - im engeren Sinne - gab es also nicht, sondern man konnte Daten durch Überschreiben verlieren, wenn man die Daten auf dem Gerät nicht regelmäßig gesichert hatte (in dem Fall war man als User also selbst schuld -> wer nicht Ordnung hält, versinkt halt irgendwann im Chaos -> ich poste jetzt besser kein aktuelles Foto von meinem heimischen Büro :-)  ).
Vorallem mit dem Einzug der filebasierten Formate (z.B. Fitfile), aber auch schon früher, wenn eben kein Ringspeicher Verwendung fand, sondern die Daten sequenziell in einem Datenstream abgespeichert wurden, spielt(e) der noch vorhandene freie Speicher (nun) doch eine große Rolle.


Merksatz: wenn kein Platz mehr vorhanden ist, dann passt auch nix mehr rein :-)

Je nachdem, wie - und vorallem ob - dieses Szenario im Gerät (sauber) implementiert ist, wird das Gerät eine entsprechende 'Low-Memory'-Hinweismeldung ausgeben und/oder eben einfach nichts mehr speichern. Mir sind auch Geräte untergekommen, die diesen Fall mit einem Absturz quittiert haben.
Auch hier können dann entweder fehlende Daten oder korrupte Daten die Folge sein. Unter Umständen kann man diese noch reparieren (siehe weiter oben entsprechende Ausführungen unter schwache Batterie).

Ich bin gestern Abend auch wieder mal selbst Opfer dieser chronischen Unordnung geworden, nachdem ich mit der Familie eine Wandertour im Taunus bei schönstem Kaiserwetter unternommen hatte und meinem GPS-Logger der Speicherplatz ausging (was letztlich auch der Grund für diesen recht spontanen Blogbeitrag ist).

Fazit fehlender Speicherplatz: viel gibt es hier nicht zu schreiben, jeder ist seines Glückes Schmied (zumindest was diesen relativ einfach vermeidbaren Fall betrifft) und unsere Mütter haben mit ihrem Ordnungswahn manchmal doch richtig gelegen :-)

Fehlerhafte Firmware: 

Ich will an dieser Stelle keine Herstellerschelte betreiben. Fakt ist, dass fast jeder Hersteller dagegen anzukämpfen hat. Diese kleinen Computer sind mittlerweile dermassen komplex, dass sich der ein oder andere Bug nicht vermeiden läßt (und dann mittels Firmware-Update hoffentlich egalisiert werden kann).
Neuerdings gehen einige Firmen sogar dazu über, die Geräte-Firmware mittels einer Art Plugin-System, von Außen erweiterbar zu machen. Auch das kann dann den ein oder anderen Bug nach sich ziehen, wenn jene Apps nicht sauber arbeiten und macht die Firmware, bzw. das Betriebssystem, das im Hintergrund werkelt, noch komplexer und damit fehleranfälliger -> merke, auch in der IT Branche gilt: alles hat seinen Preis und einen Tod stirbt man immer!

Dumm nur, wenn aus Spargründen auf Firmware-Updates bewußt verzichtet wurde, was heutzutage wohl eher die Ausnahme sein dürfte (Low-Budget Geräte werden sicherlich weniger häufig mit Updates versorgt werden als das bei Markengeräten der Fall ist).

Dieses Phänomen kann auch bei nicht so komplexen, also eher einfachen Bike-/Laufcomputern auftreten, wobei diese selten eine Aufzeichnungsfunktion aufweisen. Falls doch, dann hat das Qualitätsmanangement versagt und  man hat als Kunde das Nachsehen bzw. sollte von seinem Umstauschrecht (Garantie) Gebrauch machen.

Und auch hier können wieder fehlende oder korrupte Daten die Folge sein. Unter Umständen kann man diese noch reparieren (siehe weiter oben entsprechende Ausführungen unter schwache Batterie).

Schlechte Batterie-Kontakte:

Sporadische Aussetzer und Geräteneustarts können Folge einer schlechten Kontaktierung der Batterie sein. Dies betrifft in der Regel primär Geräte mit auswechselbaren Batterien. Bei schlechter Kontaktierung kann z.B. bei holpriger Strecke (Stöße, die auf das Gerät einwirken) der Kontakt zwischen dem Batterieleitblech und der Batterie verloren gehen, sodass das Gerät für kurze Zeit stromlos ist.

Das kommt häufiger vor, als man denkt und der Fehler ist erstmal schwer einzukreisen.

Die Folge sind häufig korrupte Aufzeichnungen oder zumindest abrupt abgebrochene Aufzeichnungen.
Wenn das Gerät schlau ist, läuft die Aufzeichnung nach dem Neustart weiter - dann fehlen lediglich ein paar Sekunden, als Folge der Lücke.
Meistens aber wird die Aufzeichnung angehalten/beendet und sofern man das auf dem Display nicht registriert - was im Eifer des Gefechts häufig der Fall ist! -, dreht man seine Runde weiter und bemerkt nicht, dass die Aufzeichnung beendet wurde.
Hier kann übrigens ein dünner Moosgummistreifen, der bewirkt, dass die Batterien etwas fester gegen die Batterie-Leitbleche gedrückt werden bzw. die Batterien fester sitzen und sich nicht mehr losrütteln können, wahre Wunder bewirken!

Zu lange Pausen:

Es gibt Geräte, die den Aufzeichnungsmodus selbständig beenden, wenn über eine bestimmte Zeit keine Sensorsignale mehr eingehen. Die Aufzeichnung wurde also gestoppt/beendet und Zuhause stellt man dann fest, dass ab dem Stopp alle weiteren Daten fehlen.

Hinweis: Biergartenpausen haben schon manche Aufzeichnung zersemmelt und sind daher nicht nur aus sportlicher Sicht fragwürdig (aber das Bierchen zwischendrinnen schmeckt halt zu gut) :-)
Falls das verwendete Gerät so funktioniert, muß man sich halt angewöhnen, nach (längeren) Pausen die Aufzeichnung wieder zu starten.

Gestoppte bzw. (zu früh) beendete Aufzeichnung oder nicht gestartete Aufzeichnung:

Mann/Frau hat - aus welchen Gründen auch immer - die Aufzeichnung beendet und vergessen, diese wieder zu starten. Wirklich ärgerlich ist es, wenn das Stoppen durch eine etwas blöde Tastenkombination zu Stande gekommen ist, die man schon mal unbemerkt tätigt.

Auch kommt es vor, dass man vergessen hat, die Aufzeichnung zu starten. Es gibt Geräte, die sich immer im Aufzeichnungsmodus befinden (z.B. SRM Bikecomputer), andere geben eine Warnmeldung aus bzw. fragen bei der ersten registrierten Bewegung, ob eine neue Aufzeichnung gestartet werden soll, wiederum andere Geräte bleiben aber komplett stumm.

Bei manchen Geräten kann man dem Display relativ gut entnehmen, ob gerade eine Aufzeichnung läuft - sofern man das nicht doch übersieht -, bei anderen Geräten gibt es hingegen schlecht einzusehende oder gar keine Hinweise.

User-Kommentar: '...ich habe bei meinem Edge die Stoppuhr einem Displayfeld als Workaround zugewiesen.' (siehe Kommentare weiter unten)

Zumindest bei einigen Garmin Geräten kann man das Problem also etwas entschärfen, sofern man sich immer eine Seite anzeigen lässt, auf der ein Stoppuhr-Feld eingebettet ist.

Kein Fehler, sondern ein Fehlverhalten/Bedienungsfehler des Users.

Kurzum, das versehentliche Vergessen beim Start die Aufzeichnungsfunktion zu starten, kann wirklich sehr ärgerlich sein (auch mir ist das schon passiert :-( ).

Echte (versteckte) Gerätedefekte:

Kommt leider auch immer mal vor :-(
Wenn man Glück hat, verabschiedet sich das Gerät komplett (totes Display), dann weiß man wenigstens, was los ist.
Wenn man Pech hat, tritt der Fehler sporadisch auf (z.B. infolge einer schlechten Lötstelle), sodass sporadische Wackelkontakte das Gerät aus dem Tritt bringen

Der letzte Fall ist eher selten, aber mir sind schon Testgeräte untergekommen, die im Laborbetrieb sauber liefen und nur unter bestimmten Bedingungen (Hitze, Kälte, etc.) Fehler aufwiesen. Lustig wird das dann, wenn eines dieser Geräte eingeschickt wurde und der Hersteller dieses wieder unrepariert retourniert, mit dem Vermerk, dass kein Fehler gefunden werden konnte (was womöglich sogar stimmt) -> dann kann sich schon mal ein Ping Pong Spiel mit der Support Hotline anbahnen :-(.

Diese Fehlerart gibt es immer noch, früher, direkt nach der Umstellung auf das bleifreie Lötverfahren, waren solche Fehler (schlechte Lötungen) wohl noch häufiger anzutreffen.
Auch können fehlerhafte Komponenten (z.B. Barometersensor) zum Teil recht krude Verhaltensweisen herbeiführen.

Spezielle Fälle

Es gibt dann noch einige extremst seltene Fälle, die allerdings so selten sind, dass sie mir just im Moment nicht einfallen :-)

Bei GPS basierten Daten gibt es mitunter noch einen Fallstrick, der aber normalerweise vom Gerät mit einer entsprechenden Hinweismeldung quittiert wird. Startet man die Aufzeichnung, bevor das Gerät einen GPS Lock hat, kann das dazu führen, dass es lange Zeit dauert, bis das Gerät verlässliche GPS Daten beziehen kann. Durch die ständige Bewegung wird der GPS Fix dann noch erschwert, was zu unschönen Ausreißern führen kann.
Ich hatte auch schon mal den Fall, dass ich die Aufzeichnung ohne GPS Fix gestartet hatte und das GPS Gerät selbst nach der einstündigen Feierabendrunde immer noch keinen GPS Fix herstellen konnte. Die komplette Aufzeichnung enthielt hinterher also keine GPS-Koordinaten!

Bei manchen Geräten muß man sich beim Start der Aufzeichnung sogar bewußt entscheiden, ob man auf die Protokollierung der GPS-Daten verzichten will -> diese Geräte können nämlich bei fehlendem GPX Fix - warum auch immer? - nach dem Start der Aufzeichnung keinen GPS-Fix mehr herstellen.

To be continued...