23949Re: [aprsisce] RE: Problem with sending message via RF
- Sep 22, 2013I do agree that APRSISce/32 is APRS-IS centered, but I think your comments take out of context, the point of the original discussion. I may have read read some things into it, but followed (IMO) the point he was trying to make from the original discussion.
> You really should use the "RF Only" option on the Chat dialog to forceI don't have full original message, but the point (as I read it) was EVEN WITH "force RF" enabled, a user "should" keep APRS-IS messages enabled (don't disable it) because "if you lose the RF by the other station leaving your range", you still have the IS system (or IS-> RF from another I-Gate.
> it to RF and keep APRS-IS Messages enabled. This allows lots of capability
> including continuing an APRS QSO with a station that might have left
> your range but is still within range of another message-gating IGate.
> If you have APRS-IS Messages disabled, you'll simply lose the QSO.
That is STILL good advice so the message gets to them.Disabling APRS-IS messages when forced RF is check reduces your options, especially if IGATE access is limited in the area.Robert Giuliano
From: James Ewen <ve6srv@...>
Sent: Saturday, September 21, 2013 4:15 PM
Subject: Re: [aprsisce] RE: Problem with sending message via RF
On Sat, Sep 21, 2013 at 12:54 PM, Rob Giuliano <kb8rco@...> wrote:
> I think you are reading more into this than the intent. It is NOT
Nope, I didn't add extra words like you have...
>> If you have APRS-IS Messages disabled, you'll simply lose the QSO.
> There was NO mention of a definite loss of communication, but increasing the
> probability by keeping both paths open - if the other path is lost - not
> saying it WOULD BE LOST, but it could be lost. Included in that is the
> IGATE messaging gating.
The statement was "you'll simply lose the QSO", you are adding in
"definite" and "increasing probability" into the statement.
Lynn and I butt heads a lot about how APRSISCE/32 works because we
come from opposite sides of the concept of APRS.
Lynn built the program based on 100% internet connectivity, and added
in RF connectivity after the fact. A lot of the thought process he
uses, and concepts built into APRSISCE/32 are rooted in being tethered
to the internet.
I come at APRS from an RF based implementation, where I use APRS with
RF as the primary connection, and occasionally have access to the
So, keeping that in mind, let's look at the concept above.
I am sitting at home, with the ability to send APRS packets out via RF
and IS simultaneously. I am sending APRS messages to you (you are on
RF only), and you are located well beyond the reach of the local RF
network. Therefore, to be able to get messages to you, my messages
have to enter the APRS-IS, then get gated back out to RF for delivery
Obviously if I can inject directly to the APRS-IS, my message will
travel across the internet, and then get gated to you. With my message
also being sent via RF, it will be heard locally as well. Should the
internet connectivity drop out, then that RF packet could be heard by
another i-gate, and enter the APRS-IS that way. I will not simply lose
the QSO, the messages will automatically find an alternate route.
If however the software being used to send those messages makes
assumptions about the "best" path to use, and shuts off alternate
routes, then it could disrupt the QSO.
This isn't about starting a war... I'm just offering different
observations about the assumptions being made.
When you work very close to a project, you can get locked into a
specific mindset, and it is helpful to have differing points of view
I enjoy discussions like this because I too end up with a narrow focus
on different ideas and concepts, and by listening to what others have
to say, I can gain more insight into the concept, learn more than I
new before, and possibly change my conceptualization of the whole
- << Previous post in topic Next post in topic >>