OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   13.09.03 09:52l 207 Lines 9144 Bytes #999 (0) @ WW
BID : 1906-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 10, 3/4
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<VK6HGR<ZL2BAU<ZL3VML
Sent: 030912/1348Z @:ZL3VML.#80.NZL.OC #:8209 [Chch-NZ] FBB7.00i $:1906-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Re: IGate WEB page.
From: "Spider" <spider@rivcom.net>
Date: Wed, 10 Sep 2003 13:10:25 -0700
X-Message-Number: 25

Think of it's primary purpose.  What does it do?  An EOC is kinda like a
Hotel.....it does nothing.  And Igate on the other hand, does something.You
can identify it better in the Status text or Station Information Query
setup.
I would make it an Igate, Eric and then better define it in the Status Text
under your setup.  If you activate, it's easy to change to the EOC  SYMBOL
on the map!

And, without trying to start a war, an ICON controls something, a SYMBOL is
something on a map!  :)

Jim, WA6OFT

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

Subject: Re: Revised Homeport Proposal
From: "hasan schiers" <schiers@netins.net>
Date: Wed, 10 Sep 2003 10:18:43 -0500
X-Message-Number: 26

----- Original Message ----- 
From: "Bob Bruninga" <bruninga@usna.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Tuesday, September 09, 2003 5:01 PM
Subject: [aprssig] Revised Homeport Proposal

>After lots of discussion and input, here is my revised proposal:
>
>4) This homeport concept should be AUTOMATIC and requrire no maintenance
>by the IGate operators (they have enough to do already!)...

I don't like the "AUTOMATIC". There should be a turn off feature in the
client Igate software, such that every REQUEST can, if so desired, be
reviewable by the Igate op. Otherwise we have sacrificed local control for
automation, per my other post. I don't oppose the change as long as it can
be defeated by the person responsible for the Igate. That way, those that
don't care what happens, can do as they like, and those who want to maintain
the stability of a potentially fragile network can do so, without being
inundated by automatic traffic, over which they have absolutely no control.

Bob was right to be concerned in his prior remarks....the more we automate
anything that happens on the RF side, the riskier things become. I disagree
with the concept at its foundation. No remote station, outside my service
area should be able to cause the local RF network to suffer his/her wishes.
They can ask, but not command. You want to give them command. I don't.
Perhaps we could have pending requests as an option? Just because someone
wants to do something, doesn't mean it's such a good idea that all the
decision makers should be removed from the loop.

As UI-View32 and the filtered servers work right now, it is quite easy to
accomodate someone traveling outside their home area. All they have to do is
ask. You live in the area, you should have a good working relationship with
your Igates and digipeater network adminstrators. If you don't, get off your
duff and build one. No volunteer network is going to hang together without a
LOT of cooperation, consultation and education. It is sooooo easy to do this
the way things are right now...anti-looping is already built into UI-View32.

If someone travels all the time, then I put them permanently in the gate to
RF list of UI-View32. I put them permanently in the b/callsign filter
exception. UI-View32 has no problem preventing the double-gating problem.

Right now, I don't see the homeport concept solving anything for our area,
and I don't feel put upon making an entry or so a week to accomodate my
friends. (I consider anyone locally on aprs to be a friend...it's simple
courtesy.)

I really hope that any implementation of the homeport concept has a "turn it
off" switch, so those of us that wish to can keep LOCAL control of what
happens on RF.

....hasan, N0AN

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

Subject: Re: Revised Homeport Proposal
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 10 Sep 2003 17:00:13 -0500
X-Message-Number: 27

Very well said, Hasan.  I agree completely with your entire post.

73,

Pete Loveall AE5PL
pete@ae5pl.net

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

Subject: Re: IGate WEB page.
From: "Dick Stanich" <dick@kb7zva.com>
Date: Wed, 10 Sep 2003 18:14:22
X-Message-Number: 28

>Think of it's primary purpose.  What does it do?  An EOC is kinda like a
>Hotel.....it does nothing.  And Igate on the other hand, does something.You
>can identify it better in the Status text or Station Information Query
>setup.

When I first developed that web page ( http://igates.kb7zva.com ), the 
purpose was to show the correct use of the 'I' overlay as an IGate. Ui-View 
software goes a step further by adding a box around Igates. Very easy to 
spot. First and foremost, we 'are' Igates and the easiest way is to let the 
world know by using the correct symbol as your primary function. We can 
always further define another purpose by adding comments to our status text 
or beacons. Sounds easy. Then I got the hate mail and comments that the 
page didn't reflect all Igates.

How can the average APRS user know the location of an Igate without 
guessing? Are they really going to home-in on 'suspected' symbols... 
probably not. This was nothing more than to try to make users aware that 
there should be some sort of standard for Igates, over A YEAR AGO! Finally, 
the light comes on and all I can say is... if you don't want to use it. 
Don't <g>. Those that don't will be recongnized across APRS as just another 
station.

Can we define this a little further? What is an Igate? Does it really 
function as an Igate? Does it send all local stations it hears to the 
internet? Is it smart enough to do reverse messaging back to it's locals 
(Inet to RF)?

My guess if it doesn't... you might as well use a no-parking sign <g>. The 
point is simple... use the correct symbol if you are a full function 
IGate.

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. Then the message is 
sent. The setting can be adjusted to expire the waiting outgoing message in 
minutes, hours, days, etc. Retry on heard. Easy when using the javAPRSSrvr 
Tier 2 servers on port 1314. Message only port... messages along with 
associated position reports. Works great for Igates.

Homeport Igates?

The ability to let the home town users see you travel across country on RF. 
Works great here. I am the automated sysop <g>. Everyone within my local 
area of coverage knows I am an Igate (proper symbol). Some even further 
away. Dick I'm going back east for 2 weeks and want my friends to track me 
on RF. Ui-View let's you add the mobile callsign to it's rebroadcast list 
on the fly. Don't have to reboot. Once the mobile leaves the local area of 
coverage and is heard by other Igates, my Igate will rebroadcast its 
position out locally or as many hops as I want to. I like to confine my 
Igate to one hop. A WIDE or pointing it at a specific digi.

I don't think we need to change server or Igate software and add to the 
complexity. Many times I have forgotten to remove those mobile calls. No 
harm. The software knows that the station is local and won't attempt 
rebroadcasts as long as it is in the local area.

Much of the new ideas/suggestions posted are already in place and seem to 
work fine. It's like waking up in the morning wondering what day it is. 
Development sometimes is almost faster than asking the question... how do 
I.... <g>.

Forgot to mention my new Ui-View32 Webserver <g>. Great tool for Igates... 
and it's almost plug n play. You can use a default setup or practice a 
little with html code... either way, a neat way for an Igate to show the 
world what it hears. http://webserver.kb7zva.com

Dick, KB7ZVA
APRSWest 

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

Subject:  Re: IGate WEB page.
From: "Spider" <spider@rivcom.net>
Date: Wed, 10 Sep 2003 17:53:16 -0700
X-Message-Number: 29

To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Wednesday, September 10, 2003 6:14 PM
Subject: [aprssig] Re: IGate WEB page.

>>Think of it's primary purpose.  What does it do?  An EOC is kinda like a
>>Hotel.....it does nothing.  And Igate on the other hand, does
something.You
>>can identify it better in the Status text or Station Information Query
>>setup.

Eric,
I forgot to point something out.  If you 'need' to transmit the position of
your EOC, you can!  You can make an OBJECT and use the EOC symbol.  And,
then your station can be set as an Igate, transmitting at the normal
intervals, etc. and your EOC Object can be set to transmit at 'Object
Interval' time under Setup, Misc.

Other stations that are dual purpose can do this too....running UIView.  If
you are an IGate and if that is honestly your
primary function, set up your station to reflect that.  Then, if you are
also a Digi, create an object reflecting that and set the timer so that it
beacons every hour or so.  Problem solved?

Jim
WA6OFT

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



Read previous mail | Read next mail


 04.11.2026 18:04:31lGo back Go up