Making of a Software Application from Zero – Part 1 of n

The Problem

I have a few Garmin devices to track my outdoor activities. During an activity, each device shows different screens, each screen having 1 to 10 data fields like speed, distance, power, rode grade, around 100 different data fields.

When it comes to changing these data fields, the only available option is to do this on the device and this is quite tedious especially when you have only two or three physical buttons and no touchscreen and you need to scroll and scroll through tens of fields and screens.

It would be nice to have an application on the PC or on the mobile to edit those fields but Garmin doesn’t offer one. Googling around didn’t reveal anything useful, only more people wishing there was one.

Motivation

Motivation is a key factor not only for starting to work on a new software application but even more for getting it done.

So what’s my motivation? First of all because it is making my life easier, editing those damn data fields and screens.

Second, it seems others might benefit from it. And isn’t this the purpose of software engineering? To bring value to the world by using data and scientific principles?

Third, I also get to learn a bit about how others (Garmin) designs their systems, exercise a bit working with low level concepts like binary data and at also with high level concepts like MVVM and object oriented design.

So, los geht’s!

Defining what we want to do

So we have a list of screens, each screen having between 1 and n data fields. We want to:

  • view existing screens and data fields in each screen
  • add / remove / duplicate / reoder screens
  • for each screen, set/change the layout and the number of fields
  • for each field, chose from a list of prederfined fields

Sounds easy, many times the core functionality of an applications can be reduced to editing lists, or lists of lists of items.

Risks

Sounds easy, but, first of all, is it really possible? Garmin doesn’t document where and in which format those screens and fields are stored. So let’s put the Sherlock Holmes had and do some investigation.

So you can edit a profile on the device itself, change a data field, and the change will be persisted. This means it is saved somewhere. Every device can be connected to the PC through USB as a storage device, so the profile definitions should be either saved into this memory or, worse, in some special memory accessible only to the device and not exposed to the exterior.

In the second case it’s kind of game over, but that would be a somehow limited design, not allowing any sort of backup, so I kind of think/hope it’s the first case.

There’s only one way to find out: copy everything from the internal memory to PC, then change a field on the device, then copy again everything and do a diff.


This is interesting! Especially that Sports folder because I have changed a field in the MTB profile (this is on Garmin Edge 830 which is a GPS for bike riding, it has 3 profiles: Road, MTB and Indoor).

Inside that Sports folder, the CyclingMountainMOUNTAIN.fit file has changed. And all the ones in the Sports\Backups file, which kind of makes sense, it makes some copies before editing a profile, just in case something goes terribly wrong.

Other changes don’t look that important, some changelog, some bin inside WIFI, but those in Sports are definitely the first candidate. Must look more closely there. Let’s diff the changed file.

Ok, so one byte changed from 01 to 02 at offset 0x724 (probably some Id of the data field that I’ve changed?) and another two bytes changed at the end of the file… this could be some sort of checksum.

Time to see what’s with this fit type of file and ask Google about it. Ok, so this is official and looks quite well documented. The Flexible and Interoperable Data Transfer (FIT) protocol is designed specifically for the storing and sharing of data that originates from sport, fitness and health devices.

Exactly what I needed, let’s grab that SDK and see what’s inside. Decoding activity files looks in particular interesting! And there’s even a C# application already parsing the fit file and decoding some messages inside. Looks like a fit file is like a stream of messages.

Playing with the sample app turns out it reads the fit file and writes to the console the stream of messages:

And if I dump to console the two fit files from before and after, it looks something like this:

(this is for a Garmin Phenix 5 GPS watch, on a screen that has 4 data fields)

So it looks like the Mesg 14 contains the properties of a screen, and the field with Id 7 contains the Ids of the data fields inside that screen (hence the 4 value array there).

I think at this point I have enough information to say that what I want to do is actually achievable. Of course, there are quite a few things to find out like which field has which Id, and how the layout of the screen is defined, but that should be easy to find out with the same change’n’diff technique.

It’s now time to step back a bit and think to the big picture design for the app, in the next part.

Leave a Reply

Your email address will not be published. Required fields are marked *