Notices

There is no error from terminal, just
loaded the Generic plugin
loaded the N900 plugin

Usually the GPS would start after a couple of starting and exiting the app, most of the time after 5-10 tries.

In the actual build, there is an hardcoded delay for the gps initiazlization equal to 0.100 Seconds.
Next week i will prepare a new build for you with an increased delay.
In the meanwhile, check the qtm packages that you have installed with:

dpkg -l |grep qtm |grep location

Thanks.

ii libqtm-location 1:1.0.2-maemo4+0m5+0cssu1+thumb2 Qt Mobility location module
ii python-qtmobility12.location 0.2.2-0maemo1 Qt Mobility Location module - Python bindings

@yrannadx
sorry, i was wrong, latest build 542x has already a gps initialization delay of 1 second. (while the 2.1.1 builds have 0.100)
Please, could you try again disabling the gps supl server?

Unfortunately I see no changes with or without supl. What's more, now I cannot start GPS at all despite many tries.

Just installed and yes, I see the same as yrannadx - no gps started. However, not yet having rebooted, I got the gps up with gpsjinni and then trackaway reported the sats. with a fix (not surprising) BUT, once I had killed gpsjinni, trackaway then could start and stop the gps (a little surprising). Will test some more....

PS: trackaway starts the gps just fine after a reboot. Would it have done so without having used gpsjinni and trackaway together? Likely it would. Nevertheless, perhaps yrannadx could try with gpsjinni as well....

@handaxe
Trackaway requires a least 4 satelites to obtain a 3d fix.
Altitude is very important while walking in mountains and recording tracks (that require the altitude)
I will ask Willy Gardiol (the developer) about a possible workaround.

At the moment... to obtain a fix from a cold start it could be that tracakway requires more time when compared to other apps.

Hi! i am Willy Gardiol, the author of Track@Way.
Honestly i am a bit loss on this issue. First of all i don't have an N900, but i can tell you that altitude precision is fairly low on all the devices i have tested (Symbian, Android, MeeGo).

Probably it's a limit of the QtMobility package i guess. It has been deprecated a long time ago but unfortunately unless moving to Qt 5 there is no alternative at this point.

Besides experimenting with various startup delays i don't knwo what could be done. Suggestions welcome anyway!

(I am rewriting the app to move away from Qt to a general pure C++ core with platform-specific frontend (so Qt for Maemo), but it will take probably more than a year at this point)

To be more clear...
Track@Way required a GPS fix with 4 satellites. Having only 3 satellites might lead to a faster fix... But that fix will be mostly useless for outdoor activities, and you have to wait for the fourth satellite anyway.

Honestly, i prefer to wait a little bit more and get a useable fix. Also, DOP will not be calcolated with less than 4 satellites... so, what good such a fix would be?

I normally use either a Nokia 5800XM (mostly) or (seldomly) an Samsung Galasy S2, and i use it pretty much all around the world. I can say that the fix time is VERY variable and VERY dependent on sky (coulds), elevation, clear LOS, night/day/sun, GPS chipset on the phone, whatever and more.

Overall, my suggestion is never turn the GPS off after you start tracking, keep it on until the end of the track even if you get indoor for a while or stop. After the initial fix it will work great.

When i was in Uzbekistan a few weeks ago, my 5800XM had a great cold boot fix (<2 minutes), which is really unheard of. The Samsung instead could take over 15 minutes and no fix yet.

Last summer in Kamchatka, instead, the 5800 would randomly lose the fix in the woods, while the Samsung would fix in less than 30 seconds rock solid. I don't know why.

One last post for today

Sailfish... Well, Track@Way is based on Qt4 using widgets. Porting it to QML and Qt5 is a task i am _not_ willing to do, because thanks to Nokia strategy i think it's an effort i don't have time for.

What i am working on is rewriting the entire Track@Way core to be in pure C++/STL. This will guarantee high portability to many platforms. After this step will be complete, it's a matter of writing a frontend for your phone of choice. Sailfish included.

I cannot state i will commit myself to a Sailfish port.... Android will be on top of the list, but i guess Sailfish IS the second. But it will take at least one year before i get there.

Of course, if somebosy is willing to help, good things might come out. Track@Way is GPL afterall.