[aprssig] Protocol translation - please no.

Lawrence LaBranche capdiamont at yahoo.com
Wed Jun 26 19:14:30 EDT 2013



Lawrence LaBranche

On Jun 26, 2013, at 8:41, "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to> wrote:

> 
> 
> 
>> 
>> a) OpenTRAC and APRS would not be transmitted on the same frequencies, so the translator would be functioning as a cross-frequency repeater;
> 
> Someone, somewhere, sometime wouldn't realize this design intent and would do it anyway.  Long after anyone that knows the ramifications has moved on to different pastures.
> 
    OpenTrac still uses AX.25, just uses a different protocol ID and payload. Others have done OpenTrac on the same frequency as APRS. It would be more an issue with RF bandwidth. If a TNC/Microcontroller had enough memory and speed, it could decode both types at the same time giving the user a seamless experience. Or nearly so. To prevent loops flagging, etc would have to be used. 
>> 
>> b) the APRS-IS backbone would never carry native OpenTRAC packets (a separate backbone would be needed to carry the different binary packet format).
> 
> Theoretically, if you make them 3rd party packets on RF, it might help?
> 
>> 
>> But you're right; a loop could still occur if two translators were "back-to-back" in the network (either over RF or via I-Gates on the APRS side), because translator#1 wouldn't recognize that the output of translator#2 was a previous input to translator#1 (even without the other issues you mentioned of digipeater/I-Gate mangling of packets).
> 
> Yep, and loops are bad, very bad as you already know.
> 
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig



More information about the aprssig mailing list