[aprssig] MGATES for IS-Mobiles
Bob Bruninga
bruninga at usna.edu
Tue Dec 27 16:36:55 EST 2011
>> Topic: How does a mobile-APP with IS-access
>> get to be seen on the local RF net?
> Bob, why do you keep insisting on cludging up an
> already messed up system of tocalls and paths?
Well, I am not insisting.
I am offering ideas, because I don't see anyone else looking in a positive
manner for ways to try to do it.
> using the tocall for selecting localised gating
> means the mobile phone can not use mic-e for it's position
And why would he want to do that? Mic-E is an AX.25-ONLY shortcut which is
not needed in this case.
> nor can it use altnets, worse it will be seen as
> altnet by other software and might not display them or
> if any other software is being used they will not
> process any other stations...
Yes, it is an ALTNET, but most software seems to default to accept all
ALTNETS anyway. But if that is the only way we can do it and still be a
legal APRS-IS packet source (because the IS does not allow a path) then it's
the best I can come up with. Besides, it pretty well is an ALTNET group of
mobile ham operators that are using a wireless device to maintain
connectivity with the local RF situation.
> a bad idea.
I am very open to other suggestions of ways to make this work... We can
solve the ALTNET issue by making it APGvvN. That would still allow for over
1000 version numbers. But my preferred solution is inserting MGATEn-N in
the path. I'd like to hear why there is the restriction to only a single
TCPIP* in the APRS-IS path. What is so hard about allowing an additional
indicator. Then the packet injected into the APRS-IS could be
WB4APR-IS>MICEXX,MGATE2,TCPIP*:packet_goes_here. Anything that is looking
for TCPIP* should still be able to find it.
And if it doesn't, then that can be fixed in the next release. I do not
expect there to be any solution without upgrading existing apps. But we
have to start somewhere...
Bob, WB4APR
More information about the aprssig
mailing list