RRT is indispensable to me as a tool for informing me of current SOTA activity. I would not be without it.
But I have had some problems with it.
Most recently I activated VK3/VC-025. Last night I tried to spot Mike 2E0YYY/P and entered all the data. I was dismayed to see that his QTH had been changed to my local summit VK3/VC-025. I was able to correct this but because the alerts sent by me are via SMS I could not retrieve or delete the incorrect ones. This morning I see the draft message has reverted to having Mike back on VK3/VC-025! I can only guess that the Google monster in my Android phone is trying to be helpful and put in my last known summit at every opportunity it gets.
Does anyone out there have the same problem?
Does anyone have any suggestions as to what is the cause?
Hi Guys,
I have had old summits that I have activated appear mid activation. So I correctly spot being on one summit, then when I change frequency and want to spot again (only changing the frequency), sometimes the summit has changed to the one I activated a couple of weeks before. I haven’t seen this and have then only realised the error when I see my own spot come back. At this point some chasers probably think I have moved on to my next summit.
I had thought this was a bug in RRT, but you may be correct that it’s Android auto filling the fields and missing the latest entry on occasion.
Peter, thanks for the heads up… I think it’s a feature of RRT. If you have your SUMMITS box ticked it will insert the nearest summit (it assumes you are there) anytime it gets a chance. Saves time and prevents errors in QTH when activating. I have unticked that box.
I found another problem this morning. Its not RRT but the SMS system. I tried to spot Ian VK1DI and got no response so tried again and when nothing happened I went inside to my computer and spotted him that way. Three hours later my SMS spots appeared on SOTA Watch!
OK, I’ve unchecked the Summits check-box even though the summit being inserted is not the nearest summit (I’m on the nearest summit when this is happening). Let’s see if disabling summits fixes it anyway.
Ed.
May I suggest you get yourself a decent mobile provider!
Sun Sep 14 03:57:22 2014: +CMGL: 2,“REC UNREAD”,“14/09/14,03:56:56+04”,vk1di/p VK2 st-036 7.085 ssb very good sigs now (via RRT)
Your message is timed by the network as being sent at “03:56:56” and it was processed at “03:57:22” some 26 secs delay.
Sun Sep 14 03:57:23 2014: SPOTLITE: 303
The spot was received by SOTAwatch 1 second later when I had processed the message.
An identical message with the same source time was received at the same time and sent within 1 sec of receipt. That’s indicative of issues with your local phone connection or provider.
Considering there is a 60sec sleep inbetween process loops, a 26 sec delay doesn’t sound excessive.
Messages are routed:
your phone>your local cell>your message centre>my message centre>my local cell>my phone>my server
If you use the alternate number:
your phone>your local cell>your message centre>my virtual message centre>my server
That cuts a lot of systems out of the loop and processing is speedier and should be more reliable. Whatever was tardy, it wasn’t anything I can control or influence.
