[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