Here is what I was suggesting. You keep an exchange in your status text like this:
1D MDC QSL XXXXXX
And that is transmitted in each of your APRS position packets (which also is displayed as a gridsquare on everyone's screens). Each time you want to QSL another contact you see in the STATIONLIST, you use the MENU button and 5 presses to then edit in the new call in place of the XXXXXX. Press BCON and wait for a response.
I am *not* a contester and have no idea if this constitutes a valid exchange, but the 1D and MDC are my usual FIeld Day excahnge. What would be best for APRS use?
So, I receive a packet from station X, I send my QSL, he sees it and sends his QSL. Aren't excahnged grids and exchanged QSL's a valid contact?
No ACKS and only manually controlled retries.
If I am missing something, correct me, thanks bob
On Sat, Apr 13, 2019 at 2:57 PM Clayton Coleman W5PFG via AMSAT-BB < [email protected]> wrote:
Like many topics in the amateur radio world, there is a mix of what is prescribed in protocol versus how it's applied in the real world.
Bob's right here. There are excess packets created by using APRS messaging vs a simple "one time" packet being sent as a UI.
The weakness in using the built-in APRS functions of Kenwood, Yaesu, or other traditionally-terrestrial messaging systems is the load of 'waste' packets generated vs using a simple UI packet. The APRS messaging functions will often continue to transmit until they receive an acknowledgement. This can be problematic in a short-duration LEO satellite pass, especially when one station tries to message everyone in their HEARD list!
Many people who operate solely with a radio such a Kenwood are oblivious to 'waste' packets being digipeated (repeat ACK's, REJ's, etc.) Unless you're sitting at a terminal and viewing all the packets, your view of what is passing by is extremely limited; not just by the tiny display of your radio. For fun, I suggest running a terminal attached to your radio and monitor all packets at Field Day.
I've observed passes when 10-15 stations were able to exchange packets and I've observed other passes when 2-3 struggled because one or two other stations were over-beaconing and sending messages repeatedly.
It's like the many new stations incorrectly assuming the best way to be digipeated is to keep pressing BCON on their Kenwood radio until the glorious "MY POS" flashes and they hear a beep! OUCH. Those are typically people on omni antennas or in their car that have no idea they've been digipeated every time but their station is not hearing.
Not everyone has the luxury of sitting in their shack to operate a packet/APRS-capable satellite. At home, I use UISS. By default UISS does not request acknowledgement or require it. It will only transmit a message or position packet upon pressing the appropriate function key. This helps limit the amount of "rapid-firing" typically employed by many of the folks using transceivers with built-in packet/APRS capabilities.
Occasionally I like to make contacts via ISS or other satellites with packet digipeaters using either one of my Kenwood mobile or HT transceivers. Do I use the status text method? No. I use the MSG function like others on this thread have described. I keep it short and sweet.
Do you want to strictly adhere to terrestrial protocol rules for acknowledging messages, often resulting in the logjam of packets, or do you want to increase efficiency and send the minimal frames necessary to get a clean exchange via satellite with another station? I leave that up to the operator.
73 Clayton W5PFG
P.S. I think the unattended beacons remain my favorite nit-pick of packet/APRS satellites' use. :-) _______________________________________________ Sent via [email protected] AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb