admin wrote:When you are roaming maybe it is an option for you to disable dataconnection and use free WLAN for example in restaurants. The tracker will uploaded all buffered trackpoints. Even if you upload buffered trackpoints using your data connection you will save bandwidth because the tracker compresses all buffered data.
For
offline track recoding / uploading to the cloud services - there are many other totally free alternatives on the scene. Even each of my navi devices has the track recoding feature (GPX).
Instead I want to post LIVE updates at a reasonable interval allowing our parents, relatives and friends to know where we are at any time given.
My ultimate goal is to have trackpoints transmitted LIVE at a reasonable interval, I would say every 60-120 seconds BUT at the same time:
1. Maintain track accuracy (for historical records), which is not possible in RTT as 120 seconds update interval = 120 seconds GPS point capture interval = poor track quality at the end. In RTT I'm missing the SEPARATE settings for "Server update interval" and "Location update interval". The only way to maintain track accuracy in RTT is to set Location Update interval (=GPS fix update=Server update) to a value of 5-15 seconds which will generate more traffic at the end.
2. Keep data traffic as low as possible (while maintaining track accuracy).
In other words I want GPS location to be captured every 1-5 seconds, some track decimation/speed/distance filter logic to be applied on the cached points and outcome to be posted to the server at a separately configured interval, e.g. every minute or two.
In the application I have spoken about above there is a very good trackpoints decimation logic built-in.
Quote from developer re track caching accuracy (I'm not adverting anything, but just giving ideas on what could be revisited/improved in RTT):
There is no configurable GPS location caching interval. But there is a decimation algorythm/logic built-in. It depends on many factors: speed, if you are doing lots of turns or moving in straight line. Course - a route with lots of turns will generate more coordinates and more data. Distance - if you location is not changing, extra coordinates are not cached. The goal is to upload as little data as possible, but still retain a detailed track. The logic triggers on changes in course, speed etc.. Moving for 500 m in a straight line will generate about 2 coordinates. Moving the same distance with lots of turns might generate 50 coordinates.
Quote re Server update intervals:
"Short" setting will post update to the web server almost instantly. Data will be posted every 5 - 15 seconds and the online map updated at the same time. Setting it to "short" then sends more data since it posts more frequent and the cache compression rate is lower. Setting it to "Long" give the opposite effect to short. Position data is posted less frequently to the server, about every 2-4 minutes on average. This makes the data transfer amount lower, since it’s less frequent and the compression rate is higher. The default is in the middle, which is a sweet spot. This gives a pretty good real time impression and the data transfer compression rate is good.
As you can see, location caching and server update are totally independant in that app which allows to maintain track accuracy irrespective from Server update intervals. This is something I would be really happy to see in RTT2
My provider does offer 30mb daily data roaming allowance for a small fee which I can allow myself, wondering if 20 hours of RTT service running with every 15 seconds update configured will fit into it (4800 server updates)?

(assuming the messaging will not be used much, e.g. 5-10 messages in a day)
admin wrote:Do you use the messaging feature frequently? At the moment this needs quite much bandwidth because location data will also be sent on messaging events.
No I don't, this is the first client with Messaging I've tried but I like this idea alot and keen to try it during upcoming travel when our parents and friends will be viewing our track online.
Wondering if Message/Viewer monitoring consumes lots of traffic? The updates on incoming Viewer/Message are almost instant, does that mean that RTT sends additional queries to the server on every update?
How much traffic is consumed for that?
In any case, if Viewer/Message monitoring consumes traffic - it would be good to have an option in the client to DISABLE viewer/messaging monitoring if users wants to save some traffic (e.g in roaming) an post only location updates to the server.
Apologies for a long post, but hopefully it will give you a few ideas and quickwins
