| |
ZL3AI > APRDIG 13.09.03 09:54l 132 Lines 5835 Bytes #999 (0) @ WW
BID : 1907-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 10, 4/4
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<VE3FJB<W4JAX<WB0TAX<N1UAN<ZL2BAU<
ZL3VML
Sent: 030912/1353Z @:ZL3VML.#80.NZL.OC #:8210 [Chch-NZ] FBB7.00i $:1907-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: IGate WEB page.
From: "Georgette Sampson" <georgette.sampson@cox.net>
Date: Wed, 10 Sep 2003 20:21:06 -0500
X-Message-Number: 30
>Without waving a flag or sounding super prejudice, has anyone looked at how
>messaging can work in Ui-View32? If you turn on a switch and send a message
>to a station that hasn't sent a position report, the message is retained by
>Ui-View until a valid position report is recieved.
Bob seemed a little upset about that a couple of days ago. Any
transmission is supposed to get you your message, not just a position.
>Forgot to mention my new Ui-View32 Webserver <g>. Great tool for Igates...
Too bad he doesn't use MySQL for his "internal" database... :-)
----------------------------------------------------------------------
Subject: Re: IGate WEB page.
From: "Spider" <spider@rivcom.net>
Date: Wed, 10 Sep 2003 19:54:43 -0700
X-Message-Number: 31
From: "Georgette Sampson" <georgette.sampson@cox.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Wednesday, September 10, 2003 6:21 PM
Subject: [aprssig] Re: IGate WEB page.
>Bob seemed a little upset about that a couple of days ago. Any transmission is
>supposed to get you your message, not just a position.
Bob gets bent out of joint like the rest of us from time to time!...no big
deal. We come back here and there as friends and concerned APRS users and
discuss issues that concern or interest us! Reasonable people
disagree....if they didn't it would be a pretty boring world!
I do not think it was explained correctly so I'll try to make it a little
more clear.....
"Retry on heard - If this option is checked, then a failed message will be
retried if traffic is heard from the station to which it was addressed, on
the port on which it was sent.
If 'Retry on heard' is enabled, and an APRS format message fails, then any
other messages addressed to the same station will be held. When the station
is heard, the failed message is sent again, and, if it succeeds, then the
next message queued for the station is released, etc. Held messages have a
status of 'H' in the Message window.
If 'Retry on heard' is NOT enabled, and an APRS format message fails, then
UI-View32 will immediately attempt to send the next message queued for the
station.
Keywords are 'traffic', 'failed', message'!
So, the original message is sent immediately....BUT.....if it fails, it will
be held until the station is heard again!
All this does is gives a user a greater chance of getting the message
through.
Would you rather have the message get to you or would you rather loose it?
If, for example, I was on the air all day and had to shut down for a
generator refueling or servicing. It is possible I might miss a message
directed at my station. However, if the sending station held upon failure
to deliver, then when I come back on line and that station hears me again,
I'll get it! OR, how about if I'm mobile and going thru some canyons and
the coverage is very poor. I might miss a message and people my not hear me
thru that bad area. When I come into good RF range and the sending station
again hears my mobile, it will try to send me the message again. Odds are
I'll get it.
It is a great tool and I can not imagine Bob not liking it. If he still
does not like it...OH WELL, can't please everyone!
>>Forgot to mention my new Ui-View32 Webserver <g>. Great tool for
Igates...
>
>Too bad he doesn't use MySQL for his "internal" database... :-)
It's a great $16 program worth a countless amount of money. Roger has
implemented almost every idea that he has been approached with that was
reasonable and has explained many times why he has not implemented an idea!
His focus, I think, is dead on track and he welcomes external authors to
jump in and write support programs, which many have done...UI-Radar and
UI-Paintbrush, to name ones I use, for example.
If you approach him about using MySQL, I am sure beyond any doubt he'll give
you an answer he can live with!! :)
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: IGate WEB page.
From: "Dick Stanich" <dick@kb7zva.com>
Date: Wed, 10 Sep 2003 22:25:7
X-Message-Number: 32
>Bob seemed a little upset about that a couple of days ago. Any transmission is
>supposed to get you your message, not just a position.
For purposes of messaging... if you don't have a position, you don't exist
on APRS. The sender will never get an ack and the receiver will never get
the message. An Igate has to learn its local stations, only then can it
effectively handle message traffic to locals. The Igate has to be able to
reach those locals, if there is inbound traffic from the inet. Some
overlapping Igates compete for local users. Inbound messages may come from
several Igates in that case. All trying to reach users in your area. The
easiest way not to overlap... shorten your paths.
Is it a trade off? Local users set their paths using too many hops around
their local Igate, causing multiple Igates to think they are local to them
hundreds of miles away. Igates often run too many wides trying to cover
larger areas at the same time. It's going to come to the point that Igates
should only reach their 'direct heard' locals. Direct is not via a
digipeater. Some Igates send what they hear locally to the internet, and
turn off the gate to RF, allowing only certain favorites to get gated
traffic. They are proud to show they are Igates, but don't function as
such.
Test an Igate. Find the nearest RF station to it. Send that RF station a
message. Go to findU and see who gated the message <g>. If the message got
to that station from anywhere but that Igate... it's time to have a meeting
:)
Dick, KB7ZVA
APRSWest
---
END OF DIGEST
Read previous mail | Read next mail
| |
