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.

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.

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.

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.

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.

Mechanischer Speeddaten Generator (oder auch mal lässig einen 50'er Schnitt wie Miguel Indurain fahrend :-) )

Bei meiner letzten großen Bilder Aufräumaktion drüber gestolpert.
Gerade bei neuen Testgeräten waren verwertbare Aufzeichnungen, die es dann softwareseitig zu implementieren und auszuwerten galt, erst mal rar gesät.

Im Labor gab es professionelle, aber sauteure mechanische Speedgeneratoren (analoge Sendetechnik), die auf Knopfdruck synthetische Daten generieren konnten. Später (digitale ANT+ Sensoren) gab es dann Software basierte Simulatoren (z.B. Antware Simulator), die das virtuelle Datensammeln merklich einfacher gestalteten.
In der Zwischenzeit musste man sich als kleine Softwareklitsche irgendwie behelfen, denn allen Unkenrufen zum Trotz, verbringen auch Entwickler von Sportauswertungssoftware einen Großteil der Zeit im Büro und nicht auf dem Rennvelo :)

Hier ist einer meiner selbstgebauten Speed-Generatoren zu sehen (der sogar parallel Cadence-Daten generieren und variable Werte erzeugen konnte :) ). Ich benötigte diesen, um Daten für ein damals neues Gerät zu sammeln, das in der TrainingLab - damals übrigens noch auf den vielsagenden Namen SAS lautend - implementiert werden musste.

Bei diesen Bike-/Laufuhren kam leider ein proprietäres Format zum Einsatz - das Fitfile Format war zu dieser Zeit noch nicht geboren -, das wirklich sehr tricky war und mir das ein oder andere graue Haar beschert haben dürfte (Dynastream stand mir Gott sei Dank mit Rat und Tat zur Seite, die hatten das Format aber auch verbrochen :-)).

Damals war ich in der Firma ein echter Held, da ich einen > 50'er Schnitt mit relativ moderaten Herzfrequenzen - < 100 bpm - fahren konnte, denn rein sitzend bleibt der Puls halt doch recht niedrig (was ich ja mittels protokollierter Aufzeichnungen zweifelsfrei belegen konnte :-) ).

Heute wirkt das wohl alles etwas oldschool-mäßig, um nicht zu sagen sehr strange :-)

In echt sah das dann so aus:

Roadmap: wieso, weshalb, warum?

Mitunter erreichen mich Anfragen, mit der Frage, ob es für die TrainingLab Pro denn eine Roadmap gäbe. Darüber hinaus wird der mögliche Erwerb einer Lizenz gerne auch mal von der Existenz (oder zeitnahen Umsetzung) der ein oder anderen speziellen Funktion abhängig gemacht.

Um die Frage zu beantworten, jein, natürlich gibt es eine vage Vorstellung, was die Weiterentwicklung der TrainingLab Pro betrifft.

Allerdings handelt es sich bei der TrainingLab Pro um eine Nischen-Software. Die Entwicklung wird von mir nach wie vor alleine gestemmt, was bedeutet, dass die Umsetzung diverser ToDos auch auf eine Zeitfrage hinausläuft. Manchmal fehlt mir auch schlicht und ergreifend das Knowhow, sodass ich mich erst mal schlau machen muß (was auch wieder Zeit kostet).
Demzufolge ändern sich auch mal diverse Priorisierungen, was bedeutet, dass eine geplante Funktion auch mal nach hinten rutscht bzw. dann mitunter auch mal komplett rausfällt.
Um jetzt gar nicht erst in die Bredouille zu kommen, verzichte ich daher aus gutem Grund auf eine öffentlich gemachte Roadmap!
Nichts ist schlimmer, als irgendwelche in Aussicht gestellte Funktionen, die dann nicht - oder sehr verspätet - kommen.
Ich will hier keine Vaporware ins Leben rufen und gerade in der Sport-Gagdget Branche gibt es sehr viele negative Beispiele: großspurig angekündigte Produkte, die dann niemals Umsetzung erfahren haben. Das braucht kein Mensch (zumal es hier auch keine Marketingabteilung zu unterhalten gibt).

Ich hoffe, das ist einigermaßen nachvollziehbar, aber es ist wirklich niemanden damit gedient, irgendwelche Erweiterungen anzukündigen, die dann zu lange auf sich warten lassen.
(Auf entsprechende EMail-Anfragen antworte ich in der Regel aber ehrlich, sodass man sich ggfs. doch etwas Klarheit verschaffen kann, wenn das denn unbedingt nötig sein sollte)