Garmin Forerunner 610 and Garmin Connect on Linux

GETTING PROPRIETARY ELECTRONICS to work on Linux can be a hassle sometimes. More often that not, companies develops controller software for Windows only, or at best for Windows and Mac OS, but neglects to support the Linux platform. Then us that enjoy the freedom and wonders of Linux is often out of luck, or have to reverse engineer a solution. Fortunately a couple of hackers did just that for the Garmin Forerunner 610.

With thanks to Tigge and Dave Lotton it is possible to download files from the watch and upload them to Germin Connect.


Tigge have created the tools to connect to the watch and download training pass files from it. Download from github and install:

» git clone
» (cd openant; sudo python install)
» git clone
» (cd antfs-cli; sudo python install)

Now insert the ANT+ usb dongle, and run this command to download all training pass from the watch.

» antfs-cli

The files will end up in the directory ~/.config/antfs-cli/<id>/activities.


To upload the files to the Germin Connect service, install the GcpUploader made by Dave Lotton:

pip install gcpuploader

Next setup a credentials file for GcpUploader.

echo -e "\
password=" > ~/.guploadrc

Edit the file and set credentials. When setting the username your must write your e-mail address. Otherwise you will get a login failure *1 .

Finally upload all files:

~/.config/antfs-cli/3894281250/activities» -t "running" *.fit
File:    ID: 707690585    Status: SUCCESS    Name: N/A    Type: running
File:    ID: 707690640    Status: SUCCESS    Name: N/A    Type: running
File:    ID: 707690660    Status: SUCCESS    Name: N/A    Type: running
File:    ID: 707688520    Status: EXISTS    Name: N/A    Type: N/A

As seen from the output, already uploaded files are skipped, so if not wanting to specify each file specifically, the *.fit wildcard works perfectly fine. Note that supports other taggings than running. Run --help for more information.


Side note:
For the version that I downloaded (GcpUploader-2015.2.21.3 I had to patch it to accept login with the credentials file:

---     2015-02-28 14:03:14.223948320 +0100
+++  2015-02-28 16:24:35.738408614 +0100
@@ -92,7 +92,7 @@
       self.msgLogger.debug('Using credentials from command line.')
-    elif os.path.isfile(self.configCurrentDir):
+    elif os.path.isfile(configCurrentDir):
       self.msgLogger.debug('Using credentials from \'%s\'.' % configCurrentDir)

If not wanting to venture into patching, also accepts credentials as arguments (see --help for more information).


Addendum: Dave Lotton recommends that instead of GcpUploader, one should use the tapiriik service instead…

F1 Timing App 2013

FOR THE 2013 Formula-1 season I though I would treat my self with buying the official live timing app: ‘F1 Timing App 2013’ by Soft Pauer Limited. At season start it costed around €22 – a hole lot of money of a one season app. So I had high expectations, but I quickly discovered that the app is utterly superfluous and added zero value to the Formula-1 watching experience

The app promises the following features:

The last one I don’t really know what means, but otherwise it sounds awesome. In reality only the Live Text Commentary have any grain of value (it displays some additional official insights into important events happening in the races).

The prime feature of the app is the realtime visual overview of car positions on the track.
Track Overview
It sure did sound great, but unless the race evolves into a train-set of cars, the actual overview clutters due to the overlap. And when watching the race, it isn’t really an information abstraction that is needed.

The secondary high profile feature of the app is the live timing overview.
Live Timing
This would have added great value some many years ago – before the TV transmission began showing equivalent information. You don’t need a costly app for what you can already see on the TV.

All in all, a costly app that has appalling scarce value. A lesson learned, which I will not repeat

Serial Port Not Working On Fedora Due To GPS Daemon (gpsd)

THE SERIAL PORT on my Fedora 15 install, mysteriously refused to be accessed. I discovered that when inserting a USB-to-Serial device, GNU screen would refuse to access the created device /dev/ttyUSB0.

» screen /dev/ttyUSB0 115200
[screen is terminating]

Since I could use screen for serial access as root, and because the newly installed Fedora did have some hiccups in adding my user (the /home/monzool directory already existed from a previous Ubuntu install), I first checked group permissions, but they seemed fine for this situation.

» ll /dev/ttyUSB0
crw-rw----. 1 root dialout 188,  0 Jun  6 08:27 /dev/ttyUSB0
» groups
monzool tty wheel uucp dialout tcpdump screen vboxusers

Screen didn’t offer much indication of the problem, but using strace I could see that some of the last things checked for permissions where /var/run/screen. I then removed that directory and recreated the directory setup by starting screen with sudo.

» ll /var/run/screen
drwxrwxr-x. 4 root    root    80 Jun  6 08:27 screen
» rm -rf /var/run/screen
» sudo screen /dev/ttyUSB0
» ll /var/run/screen
drwxrwxr-x. 4 root    screen    80 Jun  6 08:47 screen

This helped nothing! :-(

I then tried minicom, which was more informative about the problem

» minicom
minicom: cannot open /dev/ttyUSB0: Device or resource busy

This would mean that something else had hijacked the port. A quick check confirmed that something called gpsd was using the port.

»  lsof /dev/ttyUSB0
gpsd    883 nobody    8u   CHR  188,0      0t0 11408 /dev/ttyUSB0
»  ps ax | grep gpsd
  883 ?        S<s    0:00 gpsd -n -F /var/run/gpsd.sock

Now gpsd is for handling GPS devices, but it made no sense to trigger this daemon for a simple USB-to-Serial adapter.

Knowing what was causing the hazzle, I found this bug rapport In it, it is proposed to set USBAUTO=no in /etc/sysconfig/gpsd.

» echo "USBAUTO=no" >> /etc/sysconfig/gpsd

And sure enough, this fixed the problem. The USB-to-Serial adapter could now be accessed by any serial terminal.

Linux Nvidia Driver GLX Failure

I’VE BOUGHT A copy of the game Sacred Gold in an edition that is ported to Linux. This would be very exiting… if it didn’t segfault every time I start it :-(

$ sacred
sacred 1.0.1, built for i386        
Segmentation Fault: I dont believe in dragons! oh...
This is a BUG, please report it to
Stack dump:                                                             
        /usr/lib/gtk-2.0/modules/ [0xb68299a6] 
        /usr/lib/gtk-2.0/modules/ [0xb6829a5d]
        /usr/local/games/sacred/lib/lib1/ [0xb7700443] 
        sacred [0x860422e]                                                                  
        sacred [0x8620770]                                                                  
        sacred [0x860839b]                                                                  
        sacred [0x809ab90]
        /lib/i686/cmov/ [0xb71557a5]
        sacred(gtk_widget_grab_focus+0x31) [0x8053849]

The game publisher Linux Game Publishing has provided a test tool that evaluates if your system should be able to execute the game…

# testtool
Testing installation... OK, installed at /usr/local/games/testtool
Base system Test
Testing architecture of system... 32 bits
Testing system CPU... 1242MHz
Testing CPU flags... MMX SSE SSE2 SSE3
Testing system memory... 2025MB
Graphics Test
Looking for OpenGL library
Accepting /usr/lib/
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  26
  Current serial number in output stream:  26

So It appeared that I had some trouble with the proprietary Nvidia driver. I ran glxinfo and indeed it gave an error.

$ glxinfo | grep -i error
Error: glXCreateContext failed

On the world wide web I found some hints about adding the following lines to xorg.conf.

Section "Files"
    ModulePath      "/usr/lib/xorg/modules/extensions"
    ModulePath      "/usr/lib/xorg/modules/drivers"   
    ModulePath      "/usr/lib/xorg/modules"           

That didn’t help. :-(

Grepping the logs however revealed some useful information

$grep -i glx /var/log/*
/var/log/Xorg.0.log:(II) "glx" will be loaded. This was enabled by default and also specified in the config file.
/var/log/Xorg.0.log:(II) LoadModule: "glx"
/var/log/Xorg.0.log:(II) Loading /usr/lib/xorg/modules/extensions//
/var/log/Xorg.0.log:(II) Module glx: vendor="X.Org Foundation"
/var/log/Xorg.0.log:(==) AIGLX enabled
/var/log/Xorg.0.log:(II) Loading extension GLX
/var/log/Xorg.0.log:(EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
/var/log/Xorg.0.log:(EE) NVIDIA(0):     log file that the GLX module has been loaded in your X
/var/log/Xorg.0.log:(EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If
/var/log/Xorg.0.log:(==) NVIDIA(0): Enabling 32-bit ARGB GLX visuals.

It was clear that the Nvidia driver failed to intitalize the GLX module, but before that, it can be seen that another GLX module was actually loaded Module glx: vendor="X.Org Foundation". This was a big hint.

Looking into earlier investigated directories I could see that I had two different versions of the glx library files installed?

/usr/lib/xorg/modules/extensions# ll
-rwxr-xr-x 1 root root 1269220 2009-07-25 13:10
-rw-r--r-- 1 root root  337008 2009-09-28 07:32

It seemed strange that I had two so differently sized versions of libglx laying around, and also that the Nvidia version appeared not to be the default file.
Searching for the libglx file revealed that only the fglrx-driver and the Nvidia drivers supplied that file.

$ apt-file search
fglrx-driver: /usr/lib/xorg/modules/extensions/
nvidia-glx: /usr/lib/xorg/modules/extensions/
nvidia-glx: /usr/lib/xorg/modules/extensions/
nvidia-glx-legacy-173xx: /usr/lib/xorg/modules/extensions/
nvidia-glx-legacy-173xx: /usr/lib/xorg/modules/extensions/
nvidia-glx-legacy-71xx: /usr/lib/xorg/modules/extensions/
nvidia-glx-legacy-71xx: /usr/lib/xorg/modules/extensions/
nvidia-glx-legacy-96xx: /usr/lib/xorg/modules/extensions/
nvidia-glx-legacy-96xx: /usr/lib/xorg/modules/extensions/
xserver-xorg-core: /usr/lib/xorg/modules/extensions/
xserver-xorg-core-dbg: /usr/lib/debug/usr/lib/xorg/modules/extensions/

Although the only glx package that was installed on the system was libgl1-mesa-glx.

$ aptitude apts glx
p   fglrx-glx
i A libgl1-mesa-glx

Looking at libgl1-mesa-glx showed that that package installed a OpenGL library file

$dpkg -L libgl1-mesa-glx

Strangely also here a Nvida version of the library existed in /usr/lib

-rwxr-xr-x 1 root root   667528 2009-07-25 13:10

This seemed like the Nvidia installer have had collisions with other already installed packages and had failed to resolve the situation properly. Unfortunately the installer had warned nothing about this situation. What I did then was to remove the existing libraries and make a symlink to the Nvidia libraries for libglx and libGL.

/usr/lib/xorg/modules/extensions# ll libglx*
lrwxrwxrwx 1 root root      19 2009-10-01 22:22 ->
-rwxr-xr-x 1 root root 1269220 2009-07-25 13:10
/usr/lib# ll libGL*
lrwxrwxrwx 1 root root       18 2009-09-13 13:40 ->
lrwxrwxrwx 1 root root       18 2009-10-01 22:52 ->
-rwxr-xr-x 1 root root   667528 2009-07-25 13:10

And then… glxinfo ran with no errors.

The log also changed for the better

$grep -i glx /var/log/*
/var/log/Xorg.0.log:(II) "glx" will be loaded. This was enabled by default and also specified in the config file.
/var/log/Xorg.0.log:(II) LoadModule: "glx"
/var/log/Xorg.0.log:(II) Loading /usr/lib/xorg/modules/extensions//
/var/log/Xorg.0.log:(II) Module glx: vendor="NVIDIA Corporation"
/var/log/Xorg.0.log:(II) NVIDIA GLX Module  173.14.20  Thu Jun 25 19:49:59 PDT 2009
/var/log/Xorg.0.log:(II) Loading extension GLX
/var/log/Xorg.0.log:(II) NVIDIA(0): Support for GLX with the Damage and Composite X extensions is
/var/log/Xorg.0.log:(==) NVIDIA(0): Enabling 32-bit ARGB GLX visuals.
/var/log/Xorg.0.log:(II) Loading extension NV-GLX
/var/log/Xorg.0.log:(II) Initializing extension GLX

Unfortunately Sacred still segfaults big time :-(

Menu Disappeared From GVim

THE MENU IN GVim suddenly disappeared?! I did not provoke this by making changes in any .vimrc, .gvimrc or in any files in the .vim directory. The menu was just gone after a boot when GVim auto-loaded the documents open before the reboot. The system is Kubuntu 8.04 and vim-gnome.

I googled for a solution and eventually found an answer at Nabble (thanks goes to mmarko). It appears that something (?) changed the Gnome setup for GVim in the file ~/gnome2/vim.

No menu:


With menu:


Word 2007 Learn From Vi

MICROSOFT WORD 2007 was in todays pool of software upgrades at work. Our previous edition of Word was the 2003 edition, and I must say that the UI and MMI has been changed to a whole new concept. It looks fine and all. And its actually pretty easy to navigate the new “Ribbon”, but the direct keyboard shortcuts are not visible in the (non-existing) menu’s anymore – so I forget them.

Complementary to the normal direct shortcuts, Microsoft has introduced a feature known from e.g. both the Opera and Konquerer browsers. When pressing the Alt key, every menu, group and function gets assigned one or more keys which activates the item… wait. That sounds familiar…

Skimming though Microsoft’s Word 2007 navigation tutorial a funny quote emerges: “In other words, you need to get out of text entry mode and into command mode.

That sounds like something taken right out of the Vi/Vim manuallol.

Debian On Macbook

LIBERATED AT LAST. No more torment and self-punishment of using Mac OS X. I finally caved and wiped the Apple operating system from my Macbook and installed Debian and KDE 4. Sweet.

For a long time I’ve been reluctant to wipe the Mac OS X. I wouldn’t just give up on Mac OS X that easy. If so many people finds it that great, why did I keep hitting shortcoming after shortcoming and stupidity after stupidity?

If I should list what I like about the Mac OS X, I could list three things: Front-row is a pretty good media center. Mac OS X boots really fast. I like the zebra wallpaper – I kept that.

As for reasons that I don’t like the Mac OS X experience I could list a few. For example: Finder sux bad and is slow as molasses and stupid. The terminal is broken. I hate when CD’s won’t eject. Its frustrating that wireless cannot reconnect after standby. Hate those stupid obscure keyboard shortcuts. Feel back at Window 2000 with software updates that requires rebooting. I loathe those giant updates to iTunes which I rarely used. The multi-workspace concept in Spaces, its borked. The hibernation support is lousy at best. Hate that stupid inefficient application task switcher. And not by fault of Apple, I’m unhappy with the endless row of bad Total Commander/Krusader clones. I’m also irritated on an almost endless row of broken macports and broken fink ports.

It actually required two attempts to get the Macbook up and running. On the first attempt I followed the directions from the Debian Macbook Wiki, which preach that Lilo must be install for a later replacement by Grub. After installing Grub it was no longer possible to boot. On the second attempt I installed Debian like normal, and chose Grub as boot manager. Then it worked. Actually in a few other occasions I got into troubles when following the guides. It seems that the Debian Macbook Wiki is somewhat outdated on certain areas, as some special “jumping though loops” measures are no longer required, but would rather get you into trouble. Installing the 915resolutions package for example, crashed my X, but was in fact not necessary to get the prober resolution anyways. However it provides many valuable informations and links, and generally ease the installation considerable.

Krusader On Mac OS X

HAVING GROWN UP using Norton Commander for DOS, Total Commander on Windows and Midnight Commander and Krusader on Linux, its hard, if not impossible, to do work without a proper Norton Commander clone. This is true, especially on Mac OS. The standard file tools in Mac OS X are useless compared to the mentioned tools. For Mac OS X a range of native alternatives exists like Disk Order, XFolders, Fork Lift and muCommander. None of them are really good though. They all have their own weirdness’ and shortcomings, and generally none comes near the functionality and speed of used offered by Krusader or Total Commander.

I’ve used Midnight commander on Mac OS X, but I prefer Krusader, and thankfully its pretty easy to get Krusader up and running on Mac OS X thanks to the Fink project. If not having installed Fink already, do so by performing the following steps after downloading the source distribution (a binary installer is provided for Mac OS X Tiger).

$ tar xvf fink-0.28.1.tar
$ cd fink-0.28.1
$ ./bootstrap
$ /sw/bin/
$ source ./
$ fink selfupdate

Fink is now installed, configured, updated and ready for use. Installing Krusader and the required dependencies takes only a single command.

$ sudo fink install krusader

Wait for compilation to complete (may take a while). If everything goes well, Krusader should be able to be started from the terminal window.

$ krusader &

Running Krusader I discovered that the Meta/Alt key was not possible to use. This is unfortunate as many keyboard shortcuts in Krusader uses that key. Fixing this requires two setup modifications. In the X11 preferences I deselected all options under the tab ‘input’. This makes sure that X11 won’t override any personal settings made on the keyboard setup. Alas this is exactly what is required for the Meta/Alt key to work. Terminate the X11 session and edit the file ~/.Xmodmap (create it if not existing). Add the following keyboard mappings.

clear Mod1
keycode 66 = Meta_L
add Mod1 = Meta_L
keycode 69 = Mode_switch
add Mod1 = Mode_switch

Now Krusader can be used with working keyboard shortcuts :-) (note that my MacBook has a Danish keyboard, so the above mappings may possible be different if using another keyboard layout).

OpenSuse Network Configuration Problems

YAST MAY BE a powerful tool, but sometimes Suse and OpenSuse still manage to screw up their configuration so not even Yast can rectified the situation. We use Suse and OpenSuse at work, and twice I’ve experienced that the network configuration cannot recover from a netcard being changed. During boot an error message “eth0 renamed to eth2” would show, followed by another error message (after a looong timeout) “no configuration found for eth2” and afterwards DHCP would fail. After booting I would have to run ifup-dhcp eth2 to get network up and running.

Okay. The situation is amendable and requires only two setup modifications (hacks). First an easy edit in the udev network rules, to fix that the one and only netcard was being named eth2 and not eth0.

The netcard MAC-addresses and names are associated in the udev network persistent name rule-file. /etc/udev/rules.d/30-net_persistent_names.rules

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:14:e6:1b", IMPORT="/lib/udev/rename_netiface %k eth0"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:e9:d1:b6", IMPORT="/lib/udev/rename_netiface %k eth1"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:32:11:fd", IMPORT="/lib/udev/rename_netiface %k eth2"

This file contained some mappings not belonging to any netcards in my current system. Ensuring that the MAC-address mached the eth2 entry, I renamed the entry and deleted the other two.

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:32:11:fd", IMPORT="/lib/udev/rename_netiface %k eth0"

If booting after this modification, the first error message would vanish and, as remapping now is no longer enforced, the second would now be “no configuration found for eth0“.

The missing configuration can be fixed in Yast by creating a new ethernet device called ifcfg-eth0, or as I did, by just soft-linking the existing network configuration to that name.

# ln -s /etc/sysconfig/network/ifcfg-eth-bus-pci-0000\\:02\\:00.0 

Yehaa. Network errors be gone, and automatic DHCP now working :-).

I’ve experienced this problem on Suse 10.0 on a fresh install where I changed a VMware virtual netcard from the computers build-in netcard to a secondary USB netcard. At that time I didn’t want to spend to much time on it and just reinstalled. We’d just upgraded to OpenSuse 10.2 and I was handed a copy of a colleagues VMware image. As his netcard did not have the same properties as mine (i.e. MAC-address) I was hurled into the same problems once again.

What GUI Toolkit To Use?

GUI PROGRAMMING IS not something I’ve done in quite a while. At work I do embedded programming and that’s mainly also what I’ve been doing for my own personal projects. Except for some small utility applications I really haven’t done large GUI projects since MFC 6.0 was cool (if such a time ever was) ]:->.

An absolute requirement is that the end result must be multi platform capable (Linux, BSD, Mac OS X and Windows). Plenty of frameworks and toolkits exists that fulfill that requirement, but I find that the Kde/Qt constallation is the most exiting and complete toolkit(s) around – especially given the multi platform perspective introduced by Kde 4. Although Kde 4 is not quite stable yet, I think the choice is wise in a longterm perspective.

I primarily do C/C++ programming (and a bit of Lua scripting), but I really would like to extend my horizon (or more precise raise above n00b level) in other programming languages like C# and Python. Given that I have much to learn about Kde, GUI’s and what else is hot in the desktop programming world, the option of C# is not a mandatory requirement. I could settle on a C++ and Python solution.

Mixing two complete different kinds of languages (static and dynamic) requires either good binding layers or Mono. The Kde Project provides a large suite of binders in the KdeBindings package. The README contains a concise description of the project contents:

This package contains:
* working:
  * korundum: KDE bindings for ruby
  * qtruby: Qt bindings for Ruby
  * smoke: Language independent library for Qt and KDE bindings. Used by QtRuby 
    and PerlQt.
  * kalyptus: a header parser and bindings generator for Qt/KDE. Used for
    Smoke, Java, C# and KSVG bindings generation at present.
  * ruby/krossruby and python/krosspython which are plugins for the kdelibs/kross
    scripting framework to provide scripting with python+ruby to applications.
  * PyKDE: KDE bindings for python, requires PyQt from
  * Qyoto: Qt bindings for C#
  * Kimono: KDE bindings for C#

The Mono project seems to be somewhat controversial. A lot of writing has being going on lately on Mono vs. Novell/Microsoft vs. freedom. Anders Hejlsberg and his team have created both clever and interesting stuff in the .NET architecture like C#, DTS (Common Type System) and CLR (Common Language Specification), but I can’t appreciate embracing other closed proprietary technologies from the .NET portfolio, when other alternatives exist in the FOSS community. I think Robert Devi summed it up nice in the comments (the personal rantings of Robert on Mono speed/memory, Amarok etc. I don’t agree on).

As far as I can tell, the above observations give me the following constructs:

  1. C++ + Kross + PyQt + PyKde(*1).
  2. Mono + C# + limited managed C++ + Qyoto/Kimono + IronPython.

*1: PyKde is not released for Kde 4 at present time.

Its a difficult decision whether to choose the one or the other construct. Because I have already done much C++ coding (and shot a foot off more that once) and not much C# coding, I lean mostly towards the Mono solution. Unfortunately this could potentially force me to use MonoDevelop. Tried it eight months ago and tried it again yesterday; it’s still the single most unstable piece of software I ever used :-(. Hope its not the case that it only works on OpenSuse or Suse. That would not be freedom. Anyways, selecting C# would mean that the money I spent on the book Professional C#, 3rd Edition won’t go to waste.

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress