Announcing new app: RTT2

Please post your questions/comments here. You are also very welcome to support other users if you think you can help them.
Post Reply
Dusha
Posts: 22
Joined: Wed Jan 01, 2014 10:52 pm

Re: Announcing new app: RT2

Post by Dusha »

Hi Florian,
admin wrote: OK, I decided to change the timestamp display a bit. From now the app does not display the send time of GPS and network location anymore. Instead it displays the timestamp of those locations. In other words, instead of the send time the recording time is displayed. For the send time (last server sync time) a new field has been added.
Before I'll update the translation, would like to clarify.
With a new version we have 3 revised statuses:

1. Synchronization time
2. Sent GPS timestamp
3. Sent Network timestamp

My understanding from above message is that:

1 = Last server update time (last time location buffer was successfully posted to the server)
2 = last GPS location update received (logged) = Last GPS fix timestamp
3 = Last Network location update received (logged) = Last Network fix timestamp

But I'm confused by the original English wording: "Sent xxxx timestamp"
Sent to where? I guess it is received... (either from GPS or from Network data)

Please clarify

tnx!
admin
Site Admin
Posts: 3127
Joined: Tue Feb 06, 2007 12:36 pm

Re: Announcing new app: RT2

Post by admin »

Hi,
Thanks for asking. I had indeed diffuculties to find a short translation which at the same describes the behaviour without confusion. So I try again:
1.) Synchonization Time. Exact what you assumed. Time of last post to server.
2.) Sent GPS Timestamp. Almost exact what you assumed. It's not the recording time of the latest recorded GPS location but the recording time of the latest GPS location that has been successfully sent to the server.
3.) Same as in 2.) for network locations.


Example:
Lets assume this:
10:00 am: tracker records a GPS location
10:01 am: tracker records a network location
10:05 am: tracker posts locations to server

Now the fields have following values:
Synchonization Time: 10:05 am
Sent GPS Timestamp: 10:00 am
Sent network timestamp: 10:01 am

Let's assume further:
10:07 am: tracker records a GPS location
10:08 am: tracker records a network location

Now no one of those fields has changed because the tracker has not posted the values to the server yet. My goal was to inform the user which parts of the tracks have been published and can be viewed by your viewers. "Sent GPS Timestamp: 10:00 am" means that you can be sure that the viewers can see your location recorded at 10:00 am (because it has been posted to the server at "10:05 am").

I hope I did not create even more confusion now. If anybody knows a better English translation for that please post here :-)
Dusha
Posts: 22
Joined: Wed Jan 01, 2014 10:52 pm

Re: Announcing new app: RT2

Post by Dusha »

Well, now it's clear...

But in that case I personally do not see a big practical use of maintaining generic pt.1 (Sync. time) in the status bar.... Maybe apart from the scenario when GPS update interval is much higher than Server Update interval....(like in your example, however, there is no logic behind that approach)

Most of the time, I believe, the configuration will be opposite with GPS Update interval less (or much less) than Server Update interval (e.g. 15 sec GPS / 60 sec Server)
In that case "Sent GPS timestamp" = 10:00AM - will actually mean that last trackpoint successully posted is 10:00AM (irrespective from what "Sync. time" will show).
Practically, users should not care about the last server connection timestamp at all. They want to know what is timestamp of the latest location successfully posted to the server (=pt.2/pt.3) AND number of locations kept in the Buffer (not yet posted).
So I personally was more than happy with your initial response here: viewtopic.php?p=4233&f=7#p4233


However, maybe there are some scenarios when having separate Sync.time will be adding value (some troubleshooting/debugging).
(e.g. to control the app behavior, being able to capture strange app. activities, like "Sent GPS" being idle and "Sync. time" being updated at the same time).

Question:
What will happen (with the RTT2 app logic) if Server update interval is reached but there are NO new (buffered) locations recorded since last server sync?
10:00AM GPS location recorded
10:01AM GPS location posted to the server
10:02AM new Server update interval is reached (every 60 sec), but NO new valid GPS locations were recorded since last posting (e.g. traffic jam in the Tunnel)
Will connection with server will still be initialized with no location data posted at the same time? Sync time will be also updated?
Hopefully, data connection session with the server will be SKIPPED by RTT2 if there is no location data recorded in the buffer at a given update interval. " :)
nav
Posts: 8
Joined: Fri Jul 05, 2013 10:50 am

Re: Announcing new app: RT2

Post by nav »

Practically, users should not care about the last server connection timestamp at all.
+1
They want to know what is timestamp of the latest location successfully posted to the server (=pt.2/pt.3) AND number of locations kept in the Buffer (not yet posted).
... if there are several not yet posted locations in the buffer, why not to just send the latest (possibly decimated within the set accuracy tolerance for cell towers / GPS samples), sending a number of locations buffered just as the info useful to optimize the sample frequency algo?

Also, I don't see a logic with separating GPS and network sampling as two independent async threads/processes. IMHO, if GPS set ON (i.e. for better accuracy and worse battery life), and retrieved successfully (i.e. within accurancy tolerance and reading timeout), there is no need to even ask for network location at all.
Therefore, if no location could be retrieved there is no need to send to the server anything, possible except keep the app alive tickling bit for the cases when neither GPS or network location couldn't be retrieved for prolonged period of time (as an example, when GPS is OFF and network location for some reason unknown - I had such situation with overloaded with apps low memory specs phone).
Dusha
Posts: 22
Joined: Wed Jan 01, 2014 10:52 pm

Re: Announcing new app: RT2

Post by Dusha »

nav wrote: ... if there are several not yet posted locations in the buffer, why not to just send the latest (possibly decimated within the set accuracy tolerance for cell towers / GPS samples), sending a number of locations buffered just as the info useful to optimize the sample frequency algo?
Apologies, but I'm not getting your point here... All location records kept in the buffer are already decimated by the app using 2 individual options:
a) GPS update interval = xx sec; which means that locations are recorded at a configured interval only, and not on every single second
b) Min. Distance = xx m; which means that all location updates received at a given update interval (pt.a) and being located less than in "Min. distance" from each other are dropped by the app. (applies only for GPS updates)
And it is important to send all buffered locations (not only the latest one) as this directly impacts track accuracy.
Also, I don't see a logic with separating GPS and network sampling as two independent async threads/processes.
IMHO, if GPS set ON (i.e. for better accuracy and worse battery life), and retrieved successfully (i.e. within accurancy tolerance and reading timeout), there is no need to even ask for network location at all.

Well, I would agree that sending BOTH Network and GPS locations (if both are enabled in the app) looks a bit excessive. If GPS location is updated successfully at a given intervals, there is no logic to submit Network location (if enabled) on top. When both are enabled I guess Network location should be used only as a backup for GPS (e.g. in case if no valid GPS locations were received within configured "Network Update interval" => network location update is triggered. Example: GPS Update =30 sec; Network update = 120 sec.=> If no GPS updates are received in 120 sec, Network Update is triggered, if Valid GPS location is received less than in 120 sec, Network location update is skipped).

Personally, I have disabled the Network location update in the app from the beginning and not using it at all.
But someone might want to use network locations only (for the sake of battery life and disable GPS completely), someone would like to use Network location update together with GPS update as a backup option (as is the example above).
admin
Site Admin
Posts: 3127
Joined: Tue Feb 06, 2007 12:36 pm

Re: Announcing new app: RT2

Post by admin »

What will happen (with the RTT2 app logic) if Server update interval is reached but there are NO new (buffered) locations recorded since last server sync?
You just found one reason why synchronization time might make sense in some cases :-). You will see that the timestamp won't change after one minute because no connection will be established. By the way, there might be some other reasons why the tracker synchonizes from time to time even if there is no location update. The tracker polls for new messages, remote commands, and so on from time to time. Apart from that it sends battery information from time to time.
Practically, users should not care about the last server connection timestamp at all.
I agree with you. The user does not need to care about this timestamp. On the other hand I think it does not hurt if the timestamp is displayed anyway (if there is any negative effect please tell me). Users can just drag and drop the field to the last position if they are not interested in that value. Actually there were two reasons why I have added this field:
1.) Provide some kind of backward compability because RT1 also displays the send time instead of the recording time
2.) Increase transparancy, i.e. show to the user what the tracker is doing. At least for me as developer it makes it easier to test if the tracker works as expected. And maybe it will also be helpful to some users (most probably techies :-)) who are playing around with update intervals to optimize data usage.
AND number of locations kept in the Buffer (not yet posted).
This is exactly what the field "buffer size" displays: The locations not yet posted

a) GPS update interval = xx sec; which means that locations are recorded at a configured interval only, and not on every single second
Generally this is true, but there is one exception. If the map window is in foreground the tracker assumes that users want to see their up-to-date location. So the location is updated every second on the local map (but not sent to the server). As soon as the map is in background the tracker switches back to the configured update interval.
And it is important to send all buffered locations (not only the latest one) as this directly impacts track accuracy.
I agree. It's important (especially for Track Loading users who want to see their tracks in detail).

Also, I don't see a logic with separating GPS and network sampling as two independent async threads/processes.
IMHO, if GPS set ON (i.e. for better accuracy and worse battery life), and retrieved successfully (i.e. within accurancy tolerance and reading timeout), there is no need to even ask for network location at all.
I agree and I even thought about changing that. The problem is that for historical reasons internal design is not optimal for that change. When I started this project I totally focused on GPS locations (the tracker even did not support network locations). As more and more users started to ask for network locations I added a separated (very simple) module to track network location. But as the GPS module is very complex (supports many options and handles GPS-specific problems) it is not that easy to merge these modules. So all in all I would say, merging is possible but so far I was too lazy ;) and this issue has not high priority because in my opinion querying does not really hurt battery. It will increase data usage a bit but not that much (especially if you raise the network update interval).
nav
Posts: 8
Joined: Fri Jul 05, 2013 10:50 am

Re: Announcing new app: RT2

Post by nav »

Apologies, but I'm not getting your point here...
We are thinking basically the same, except I suggested to obey the Accuracy setting for network locations (may be separate values) to decimate readouts with low accuracy and in-house motions to suppress unnecessary location updating traffic to the server.
The tracker polls for new messages, remote commands, and so on from time to time. Apart from that it sends battery information from time to time.
1. There are many users that have not need to use the built-in RTT messaging, so I'd assume there shouldn't be architectural performance penalties or severe dependencies on that part.
2. Thought that remote commands were implemented with GCM thus no need to poll.
3. Battery info is another good candidate for samples decimation, wouldn't you think? Say its important when your battery readout drops from 8 to 3%, but not when from 76 to 55%.
4. Maybe battery info is one of the values that can be updated on every sync to server, i.e. these timestamps should be the same?
I added a separated (very simple) module to track network location.
Looks like an after thought extra :oops: Maybe that's too simple ad-hoc to coupe with GPS settings and will eventually confuse users expecting the app's consistency, New arch for RTT3?
Dusha
Posts: 22
Joined: Wed Jan 01, 2014 10:52 pm

Re: Announcing new app: RT2

Post by Dusha »

nav wrote: 4. Maybe battery info is one of the values that can be updated on every sync to server, i.e. these timestamps should be the same?
No-no, any extra data that is not really important for the main app purpose (= Location tracking) should be optional. Otherwise it will start impacting traffic consumption.
I find current approach (configurable battery update interval) pretty much optimal...

I agree that we already have pretty much novations in RTT2. :D

As idea, maybe Florian can start sometime in a future a dedicated Idea campaign to collect votes for the new features in a bit more consistent manner (there are many free "Idea campaign" platforms available on the net giving an excellent overview of all ideas, comments, and votes). We have "Feature requests" section on the forum, but it is not really easy for end-users to navigate through them, comment and vote.
nav
Posts: 8
Joined: Fri Jul 05, 2013 10:50 am

Re: Announcing new app: RT2

Post by nav »

When server updates are frequent, I agree that no battery % should be submitted on each update. But, when server update interval > (Max)BatteryStatusUpdateInterval, that would automatically shorten server update interval to battery update interval.

As to "Idea campaign" the pure defining of the ideas that the author would be willing to implement possibly involves the rethinking of interfaces between the program modules. Even then, that's not open source with several developers, so everything is up to the author :?
admin
Site Admin
Posts: 3127
Joined: Tue Feb 06, 2007 12:36 pm

Re: Announcing new app: RT2

Post by admin »

Yes, the tracker uses GCM but nevertheless it polls sometimes for new messages and remote commands because there are some scenarios where GCM does not work (some networks seem to block it).
Sure it would be possible to even more optimize network location and battery monitoring. But as I said in my opinion these issues are not that critical because both intervals are configurable.
Post Reply

Who is online

Users browsing this forum: No registered users and 61 guests