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…

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 :-(

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.

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.

Kde Crashes My VMware

KDE ON VMWARE appears to be a combination of instability.


At work I’ve been running Kde on two VMware Workstation installations, one Suse 10.0 and a Debian unstable. The experience is the same for both installs where the VMware session crashes at least on time a day, but more often as much as three times a day. At work we are four colleagues that are working in a VMware environment and we are all have problems with VMware sessions suddenly crashing. No particular pattern of work seems to provoke the crashes, but experiments show that it is only the Kde + VMware constellation that causes problems. A colleague found that replacing Kde with another window manager makes all the instability issues go away. Hence we have all abandoned Kde for other window managers.


I’m a long time Kde fan and on my personal Debian unstable install, Kde has run for years and it never crashes. Could be interesting to know what Kde is doing that makes VMware spill its guts.


For replacement window manager a couple of colleagues installed Enlightenment, another installed IceWM and I installed Xfce4.4. Xfce4 actually really impresses me. Not only does it look spectacular, but also it’s so much more responsive compared to Kde. Of course I cannot work without my trusted Kde applications and tools, but luckely Xfce4 provides optional Kde and Gnome integrations. The really big bonus of Xfce4 is the awesome keyboard nagivation abilities. Xfce4 provides global shortcuts for easy window resizing, moving, maximizing, minimizing etc. Nice :-)

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