23940RE: [aprsisce] RE: Problem with sending message via RF
- Sep 21 3:52 PM
What James says is true about APRSISCE/32 being a bit internet relient, but to be fair the original software was designed as a IS stream viewing client.
The RF was added on. That’s admittedly a simplistic view.
Lynn has stated that he intends to do a redesign of APRSIS32. I know he has had thoughts on how to change things. Obviously a lot has been learnt over the time APRSIS32 has been going.
And of course someone keeps distracting him, with other projects. Sorry
Amateur Radio Callsign G6UIM
Torbay Freecycle Owner
APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com
From: firstname.lastname@example.org [mailto: email@example.com ] On Behalf Of g.isringhaus@...
Sent: 21 September 2013 23:16
Subject: [aprsisce] RE: Problem with sending message via RF
Well said James. I try not to rely too much on the internet for this particular SSID because I want to make sure that it is 100% running on RF when a disaster strikes. Everybody has preferences and different ways of doing things. That is what makes the hobby fun!
--- In firstname.lastname@example.org , <ve6srv@...> wrote:
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
> 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 >>