[aprssig] Universal Messaging (and new qAP feedback?)

[Lynn W. Deffenbaugh (Mr)]

I like the the idea of the IGate feedback, but I know my current 
configuration would still mess that up.  I've got a javAPRSsrv running 
that believes it is bi-directionally gating packets.  It feeds them into 
AGWPEpro which is configured as Receive Only, but even if it wasn't 
configured that way, there is no physical connection to a transmitter of 
any sort.

My IGate software would reply back that it gated the message to RF, but 
the RF side would never, ever hear it.

So, if this gets implemented, at least in javAPRSsrv, we'd need a way to 
tell the embedded IGate that it does not, in fact, have a transmitter 
out there and is running as a receive-only IGate. 

Given the recent discussion about IGate owner liability for what gets 
transmitted, others may get scared into doing receive-only IGates.  Mine 
is that way only as I get it going until I have a functioning T2-135 
card in my Alinco so that I can remove AGWPEpro and the sound card from 
the mix.  I really want javAPRSsrv to talk BlueTooth RS-232 directly to 
the T2-135 to remove any coupling between the radio side and the 
computer side.  Call me lightning-paranoid, but I live in Florida (the 
lightning capital of the world, so they say).

Lynn (D) KJ4ERJ

PS.  Cross-posting this one to the javaprssrv Yahoo group as well.

Robert Bruninga wrote:
>
> Actually, it could be many things, and that is why these kinds
> of Message entry portals need to implement the full APRS message
> function, which includes:
> 1) Retries using the decay algorithm
> 2) Message line numbers to require acks
> 3) retry and ack status display feedback to the sender
> 4) ROUTE (qAP) feedback to the sender (this is new)
>
> This item 4 or something like it is something we should consider
> adding to the APRS-IS and Igate codes...  It means the Igate
> that gated a packet to RF should also send back via the APRS-IS
> information showing what it did with the packet!  This would
> help in the tracing of problems through the network.  Right now,
> it is impossible to see, since all Igates ignore the on-air
> packets from other Igates so this information is not avaialbe.
>
> Maybe it could be a new "qAP" packet.  Following the "qAP" would
> be the callsign of the Igate, then its RF PATH (maybe WIDE2-2,
> or WIDE1-1, or whatever it is using).  This kind of feedback on
> the APRS-IS would be very valuable.  Pete, AE5PL and Steve, K4HG
> and others should have the best ideas how to do this kind of
> stuff.  Of course, all of the existing Uiview Igates will never
> be upgradeable, but we have to start somewhere and now is a good
> time.
>
> Anyway, back to the UNIVERSAL MESSAGING ISSUE, by having this
> "qAP" feedback information, then we can see how outgoing
> messages are being handled by the APRS-IS and from that improve
> our overall goal of Universal Messaging Connectivity.
>
> Bob, Wb4APR
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>