Messages sent multiple times

[k4ety]

I tried out the new mesaging capability, using build 1.1-5-g0c0d454, dated 2011-09-11. It worked as I expected, showing "TCP OK" with a timestamp of 13:59:57. Then, unexpectedly, it sent again at 14:00:28, at 14:01:29, and again at 14:03:30, at which point I clicked "Stop Tracking" to stop the service. Each time the status "TCP OK" was displayed.

13:59:57 14:00:28 diff =~30 secs 14:01:29 diff =~60 secs 14:03:30 diff =~120 secs

It looks to be sending at a decaying rate, as you might expect for a retry, though the status indicated success.

Great job on your work, so far. I am looking forward to when packet decode capability is added, created a complete standalon APRS application - just add a radio.

I mentor a group of high school students, and we use APRS to do balloon chases, with the students setting up equipment, building expirements, doing some arduino programming, and then we all have fun releasing and chasing the balloon in South Georgia. This has been a great way to get students interested in ham radio and taking license exams. We have had over a dozen students get licensed in the past 2-3 years, with more studying this year. We have had enough interest that my Daughter has restarted a ham radio club (the school had one in the late 50's and early 60's), and we obtained a school club callsign: W4CHS. You will occasionally see this callsign show up with APRS when we do our balloon chases. I have some ideas about how you could enhance APRSdroid for balloon chases, but I will make that a different post...

Thanks again on the good work!

[ge0rg]

Thanks for the feedback!

Message retransmission occurs until the receiving station sends an ack. According to aprs.fi, your conversation partner did not ack, so APRSdroid properly kept repeating the message in increasing intervals.

APRSdroid indicates success by making the message dark green as of now. I am still working on a better success/failure display in the conversation dialog, it will be implemented in one of the upcoming versions.

[k4ety]

I was unaware that the norm for APRS messages was an exception to other packet types, and expected ACKs. I have never used a PC implementation of APRS that implements this feature - all just send the message a single time and then stop. I looked Bob's documentation, and for reliability this certainly makes sense. For any traffic coming from the internet, though (so far the only native option for APRSdroid), a Digipeater would need to be configured to repeat messages to RF, so unless you are at your "home" digi, this is unlikely to be the case. In instances where the ACK never takes place, how long do you continue to attempt to send the message? I could find no way to flush "old" messages from retrying. After not using APRSdroid for a few days, when I turned it on it sent a message again that I had sent days ago. It did only send the one attempt, but that does not seem like the expected behavior.

In most cases, the individual user would probably know if it were likely for their messages to be digipeated to RF. In the cases where it were unlikely (or impossible) for the messages to be ACKed, you may want to consider creating an option for the user to choose whether to resend messages until ACKed, or to send a single attempt. Or maybe to set a max message send limit.

On a bit of a different note, how high on your priority list is two-way AFSK? This has my vote for highest wish-list item. With dual-band HTs available now for $55 USD (google MTC dual band radio), this seems by far the most cost-effective option for putting together an APRS station, for those who already have Android phones. With a radio and a simple cable, you would have everything you need. This would be a great option for students who are new in the hobby and wanting to setup their own APRS station.