Order Tray | Contact Us | Home | SIG Lists

[aprssig] Its time for new Igates...

Keith VE7GDH ve7gdh at rac.ca
Mon Sep 15 20:50:13 UTC 2008


Bob WB4APR wrote...

> The problem is, we need new IGate software that takes advantage of the
> New-N paradigm and better implements APRS messaging and acking.

In what way doesn't current software take advantage of "new-N" and not
implement APRS messaging and acking?

> 1) Few IGates do reverse-pathing for messaging as an IGate. The
> new-N paradigm assures that ALL packets are traceable, so reply
> messaging should work much better than it does now.

Fortunately, traffic gated by UI-View is traceable.

> 2) UI-View does not do many of the APRS techniques for improving
> ACK reliability so acking suffers significantly. UI-View does
> not do reply-acking which would also help

When did that change take place? Does that mean that UI-View will
suddenly stop gating ACKs to RF stations the way it always has? I just
ran a little test and sent a message via RF to a distant (out of range)
station. The local IGate (the other side of the house) gated it and the
destination station received the message and sent an ACK which I
received on RF. When can I expect it to stop working?

> 3) Most IGates do not allow for separate IS-to-RF paths separate
> from the stations own RF path. There should also be separate
> paths for objects.

When gating from the APRS-IS to RF, UI-View, the IGate operator can 
either...

1) use the default path as set in the station setup
2) use a path specified in IGATE.INI
3) use the reverse digi path that the RF station was last heard by

In my opinion, the "right path" should be determined by the location and
elevation of the IGate, the output power and antenna used by the IGate,
the location of the digis around it, the surrounding topography, and the
distance (number of hops) to the next IGate.

However, it would be good to be able to specify paths for objects 
separately.

> 4) Also, there should be specific techniques for assuring that
> the local IRLP and ECHOlink APRS objects get to RF in each
> IGate area (and only 1 hop usually)...

At this point in time, it is as far as I know up to the IGate operator
to configure the IGate to gate these objects. In UI-View, the path used
would be as specified in the station setup.

> 5) Any other lessons learned?  I'm sure there is a wish list
> somewhere?

As with anything that is developed "by the seat of the pants" there will
be changes needed. A "wish list" would certainly be a good idea. Perhaps
it could replace the "APRS working group" and when it has all been
hashed out, i.e. an updated APRS spec that includes everything from the
"wish list" could be made available and hopefully some authors will step
forward and write software that does what is needed. In the meantime, we
can make do with what is available.

73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"





More information about the aprssig mailing list