Problem with sending message via RF


Greg Isringhaus
 

I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 

 

Thanks in advance.

 

Greg..


James Ewen
 

Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.

If you send:

Message Line 1
Message Line 2

and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.

When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.

When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.




On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@...> wrote:


I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 

 

Thanks in advance.

 

Greg..






--
James
VE6SRV


Greg Isringhaus
 

 I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.


--- In aprsisce@..., <ve6srv@...> wrote:

Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.

If you send:

Message Line 1
Message Line 2

and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.

When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.

When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.




On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@...> wrote:


I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 

 

Thanks in advance.

 

Greg..






--
James
VE6SRV


Greg Depew
 

Greg KB3KBR Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: goatherder_4891@hotmail.com
Date: Sat, 21 Sep 2013 02:59:51
To: <g.isringhaus@gmail.com>
Reply-To: goatherder_4891@hotmail.com
Subject: Re: [aprsisce] RE: Problem with sending message via RF

I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
Greg KB3KBR Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: g.isringhaus@gmail.com
Date: Sat, 21 Sep 2013 02:55:17
To: <aprsisce@yahoogroups.com>
Subject: [aprsisce] RE: Problem with sending message via RF

 




 I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.


--- In aprsisce@yahoogroups.com, <ve6srv@...> wrote:



Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.


If you send:


Message Line 1
Message Line 2


and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.


When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.


When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.







On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@... <mailto:g.isringhaus@...> > wrote:




I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi <http://aprs.fi> and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 
 
Thanks in advance.
 
Greg..






--
James
VE6SRV


Greg Isringhaus
 

  I just tried to send another message after the last one failed at 9 attempts.  Appears that APRSISCE is trying to send it out, as it goes 1,2,3,4,5,6 attempts and not triggering the RF port.


--- In aprsisce@..., <g.isringhaus@...> wrote:

 I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.


Greg Isringhaus
 

 Lynn can you confirm?

 

QUOTE:  I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
Greg KB3KBR Sent from my Verizon Wireless BlackBerry

 

Is there a fix on your end that you can do so that I don't have to select RF only each time I want to send a message.  Seems like "Best" method is getting confused and should know that my I have the IS disabled for messaging.


--- In aprsisce@..., <goatherder_4891@...> wrote:

Greg KB3KBR Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: goatherder_4891@...
Date: Sat, 21 Sep 2013 02:59:51
To: <g.isringhaus@...>
Reply-To: goatherder_4891@...
Subject: Re: [aprsisce] RE: Problem with sending message via RF

I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
Greg KB3KBR Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: g.isringhaus@...
Date: Sat, 21 Sep 2013 02:55:17
To: <aprsisce@...>
Subject: [aprsisce] RE: Problem with sending message via RF

 




 I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.


--- In aprsisce@..., <ve6srv@...> wrote:



Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.


If you send:


Message Line 1
Message Line 2


and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.


When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.


When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.







On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@... <mailto:g.isringhaus@...> > wrote:




I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi <http://aprs.fi> and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 
 
Thanks in advance.
 
Greg..






--
James
VE6SRV


Greg Isringhaus
 

Or is is maybe that it takes a little bit for APRSISCE to learn that the transmit is disabled on the IS.  Because now it seems to be working.  I think it is a slow learner.  Anyway, I'll let you know if it acts up again.


--- In aprsisce@..., <g.isringhaus@...> wrote:

 Lynn can you confirm?

 

QUOTE:  I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
Greg KB3KBR Sent from my Verizon Wireless BlackBerry

 

Is there a fix on your end that you can do so that I don't have to select RF only each time I want to send a message.  Seems like "Best" method is getting confused and should know that my I have the IS disabled for messaging.


Lynn Deffenbaugh
 

Are you sure that the ack is getting to APRSISCE/32?  Or is your message pane (upper left of map) staying Yellow or Orange?  Check Messages / Pending Messages and I suspect you'll see that the first message is still waiting for an ack.  That should be the only thing that causes subsequent messages to wait because they're sent FIFO with an ack required before the next one will transmit.

Any hint as to why you don't have everything enabled on the APRS-IS port?  Especially Messages?  APRSISCE/32 is (semi-) intelligent about whether or not a message will be sent to RF, -IS, or both.  And you can still force it to RF Only directly in the Chat dialog.

Just because you see an ack in aprs.fi doesn't mean that ack got to your APRSISCE/32 instance.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 9/20/2013 10:24 PM, g.isringhaus@... wrote:

I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 

 

Thanks in advance.

 

Greg..



Lynn Deffenbaugh
 

You threatened it by asking the question so it decided to behave.

"Best" means that if APRSISCE/32 has "recently" heard the station on RF, it will send to RF.  It will ALWAYS send it to the APRS-IS (assuming you have Messages enabled, which you really should have).  If the station you're sending a message to is completely unknown, "Best" will send it out all available ports because it has no idea where the station is.

You really should use the "RF Only" option on the Chat dialog to force 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.

Lynn (D) - KJ4ERJ -Author of APRSISCE for Windows Mobile and Win32

PS.  Another reason that the radio might not key up is that the TNC believes the channel is "busy".  APRSISCE/32 can only deliver packets to the TNC.  There's no handshaking to know if they were actually transmitted or not.  An enabled trace log on Port() can help you know if APRSISCE/32 is sending the data out that port or not.

On 9/20/2013 11:10 PM, g.isringhaus@... wrote:

Or is is maybe that it takes a little bit for APRSISCE to learn that the transmit is disabled on the IS.  Because now it seems to be working.  I think it is a slow learner.  Anyway, I'll let you know if it acts up again.



James Ewen
 

On Fri, Sep 20, 2013 at 10:01 PM, Lynn W Deffenbaugh (Mr)
<kj4erj@arrl.net> wrote:

You really should use the "RF Only" option on the Chat dialog to force 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.
The above is an inaccurate observation. Hundreds of stations with RF
only access successfully send and receive APRS messages with stations
outside of their local RF network by having their messages injected
into the APRS-IS by other i-gates in the area.

The messaging source station does not have to directly inject a
message into the APRS-IS to be able to have their message gated into
another area.

--
James
VE6SRV


Keith VE7GDH
 

Greg (callsign?) wrote...

I am having problems with sending messages via RF...
What is the callsign-SSID of the station sending the messages?

73 es cul - Keith VE7GDH
www.ui-view.org
--
"I may be lost, but I know exactly where I am!"


Greg Isringhaus
 

The SSID is K0GDI-1, I was wanting to keep the IS from TX because of my own preference.  This is just for the SSID of -1, I keep it open both TX and RX for my main SSID.  It seems to be working fine for now.  Just seems like either it takes about 10 minutes or so for the program to know that the TX is turned of on the IS, or because it recently heard that station on RF and knows to send via RF.  I'll keep an eye on it.


--- In aprsisce@..., <ve7gdh@...> wrote:

Greg (callsign?) wrote...

> I am having problems with sending messages via RF...

What is the callsign-SSID of the station sending the messages?

73 es cul - Keith VE7GDH
www.ui-view.org
--
"I may be lost, but I know exactly where I am!"


Greg Isringhaus
 

 Yeah, it still seems to get stuck.  I kind of still wanted to view IS stations and only broadcast on RF, but seems like APRSIS has no way on doing this reliably.  I of course could hit RF Only each time I try to send a message out to somebody, but would be nice if the program was intelligent enough to determine that the IS has been disabled on TX and to send all packet via RF.  Guess for now, I'll just check the RF Only each time. 


--- In aprsisce@..., <g.isringhaus@...> wrote:

The SSID is K0GDI-1, I was wanting to keep the IS from TX because of my own preference.  This is just for the SSID of -1, I keep it open both TX and RX for my main SSID.  It seems to be working fine for now.  Just seems like either it takes about 10 minutes or so for the program to know that the TX is turned of on the IS, or because it recently heard that station on RF and knows to send via RF.  I'll keep an eye on it.


Rob Giuliano
 

James,
I think you are reading more into this than the intent.  It is NOT inaccurate.

> You really should use the "RF Only" option on the Chat dialog to force
> 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.

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.

 
Robert Giuliano
KB8RCO


---------------------------------------------



From: James Ewen
To: aprsisce@...
Sent: Saturday, September 21, 2013 12:41 AM
Subject: Re: [aprsisce] RE: Problem with sending message via RF

 
On Fri, Sep 20, 2013 at 10:01 PM, Lynn W Deffenbaugh (Mr)
wrote:

> You really should use the "RF Only" option on the Chat dialog to force 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.

The above is an inaccurate observation. Hundreds of stations with RF
only access successfully send and receive APRS messages with stations
outside of their local RF network by having their messages injected
into the APRS-IS by other i-gates in the area.

The messaging source station does not have to directly inject a
message into the APRS-IS to be able to have their message gated into
another area.

--
James
VE6SRV



James Ewen
 

On Sat, Sep 21, 2013 at 12:54 PM, Rob Giuliano <kb8rco@yahoo.com> wrote:

James,
I think you are reading more into this than the intent. It is NOT
inaccurate.
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
internet.

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
to you.

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
brought out.

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
idea.

--
James
VE6SRV


Greg Isringhaus
 

 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 aprsisce@..., <ve6srv@...> wrote:

On Sat, Sep 21, 2013 at 12:54 PM, Rob Giuliano <kb8rco@...> wrote:

> James,
> I think you are reading more into this than the intent. It is NOT
> inaccurate.

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
internet.

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
to you.

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
brought out.

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
idea.

--
James
VE6SRV


sbd sbd
 

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

 

Steve Daniels

Amateur Radio Callsign G6UIM

Torbay Freecycle  Owner

http://uk.groups.yahoo.com/group/torbay_freecycle

APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

 


From: aprsisce@... [mailto:aprsisce@...] On Behalf Of g.isringhaus@...
Sent: 21 September 2013 23:16
To: aprsisce@...
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 aprsisce@..., wrote:

On Sat, Sep 21, 2013 at 12:54 PM, Rob Giuliano <kb8rco@...> wrote:

> James,
> I think you are reading more into this than the intent. It is NOT
> inaccurate.


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
internet.

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
to you.

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
brought out.

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
idea.

--
James
VE6SRV


Rob Giuliano
 

I 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 force
> 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.

I 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.

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
KB8RCO


---------------------------------------------



From: James Ewen
To: aprsisce@...
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:

> James,
> I think you are reading more into this than the intent. It is NOT
> inaccurate.

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
internet.

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
to you.

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
brought out.

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
idea.

--
James
VE6SRV



James Ewen
 

On Sun, Sep 22, 2013 at 1:48 PM, Rob Giuliano <kb8rco@yahoo.com> wrote:

I 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.

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.
Yes, your options are reduced IF you have internet access. If you are
where there are no i-gates, and you have internet connectivity turned
off, then you would simply lose the QSO when the other station moves
out of RF range.

The point was that there were assumptions being made with the original
statement... it was assumed that there were no i-gates in the area,
and that the user HAD access to the internet. To "simply lose the QSO"
when a station moves out of local RF range requires all internet
access (both internal and provided by others) to be non-existent.

BTW, "local RF range" includes the whole area which an RF signal can
be heard, not only directly, but through ALL accessed digipeaters.

If you have internet access, and RF access, then allowing both methods
to be used to deliver a message is good advice, but losing
connectivity via one port does not necessarily cause the loss of
communications capability.

--
James
VE6SRV


Rob Giuliano
 

But the MAIN POINT of the group MUST BE to provide CLARITY - SPECIFICALLY with respect to the answer to the question posed - without confusion.

When I read your response to Lynn, had I been the person who posed the question, I could have been confused - SPECIFICALLY because the statement directly said the answer was "inaccurate", while quoting pretty much the whole answer.

>> You really should use the "RF Only" option on the Chat dialog
>> to force 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.
>
> The above is an inaccurate observation. Hundreds of stations with RF
> only access successfully send and receive APRS messages with stations
> outside of their local RF network by having their messages injected
> into the APRS-IS by other i-gates in the area.

The assumptions were to make a point about settings, not to "bash or imply inability" of the system.  Countering them "could have been done" in a method that was less aggressive to the point being made (and therefore less confusion to the person LOOKING FOR ANSWERS".  

Don't get me wrong, the banter and comments all have value and are opportunity to learn more about APRS in general and APRSISce/32 specifically.  I know I have learned more from those points.

BUT the points need to be made without confusion about the original message's question or request for assistance.

Robert Giuliano
KB8RCO


---------------------------------------------



From: James Ewen <ve6srv@...>
To: aprsisce@...
Sent: Sunday, September 22, 2013 4:12 PM
Subject: Re: [aprsisce] RE: Problem with sending message via RF

 
On Sun, Sep 22, 2013 at 1:48 PM, Rob Giuliano wrote:

> I 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.
>
> 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.

Yes, your options are reduced IF you have internet access. If you are
where there are no i-gates, and you have internet connectivity turned
off, then you would simply lose the QSO when the other station moves
out of RF range.

The point was that there were assumptions being made with the original
statement... it was assumed that there were no i-gates in the area,
and that the user HAD access to the internet. To "simply lose the QSO"
when a station moves out of local RF range requires all internet
access (both internal and provided by others) to be non-existent.

BTW, "local RF range" includes the whole area which an RF signal can
be heard, not only directly, but through ALL accessed digipeaters.

If you have internet access, and RF access, then allowing both methods
to be used to deliver a message is good advice, but losing
connectivity via one port does not necessarily cause the loss of
communications capability.

--
James
VE6SRV