[aprssig] Gating Objects from Internet to RF (fina?l)
Robert Bruninga bruninga at usna.eduWed Jul 22 20:23:34 UTC 2009
- Previous message: [aprssig] Gating Objects from Internet to RF (fina?l)
- Next message: [aprssig] Gating Objects from Internet to RF (fina?l)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lynn, Great work! I have only been trying to get this for the last half dozen years or so. I have been badgering Jonathan (Echolink author) for years, but apparently I had not realized that he had finished his half (getting Posit data centralized). It is so great that you have jumped in with the missing link. > Done. Check out the current proposed objects at > http://ldeffenb.dnsalias.net/EchoLink.txt. 1) However, I agree with Steve, that you should not use the EchoLink callsign as the AX.25 FROM address, since it will conflict with that same station's HOME or other APRS station -0 and violate the principle of ownership or common expectations. Besides it will also be wasting space in the APRS radio display by having the Echolink callsign in TWO places on the display when this is actually a minor bit of info. I recommend that you make ALL of these objects be originated by your callsign... Something like KE4ERJ-EL. Notice that a non 1-15 SSID can be used, since this is being directly injected and does not have to go through a TNC. Then everything works as desired, plus we get to see the real source of this data KE4ERJ-EL and not some person's call who has no idea how it got to APRS. 2) PHG data: > It only uses PHG if the frequency doesn't > adhere to the valid ones listed in > http://aprs.org/info/freqspec.txt... PHG should not be included in these objects in any case. As I explained before, when displayed on a D700 (the primary target screen for these objects) the PHG data will not be parsed, but will show up as TEXT "PHGxxxx" pushing the other useful information another 8 characters off the screen. SO do not include PHG in any case. 3) > Any "invalid" frequency will still be included in > the status text, but only in its owner-specified > format, not in a normalized FREQ object. Actually, I would rather see all non-standard entries DUMPED to a NEEDS-FIXING file that we can send to Echolink and get the originators to fix the problems at the source. 4) I see lots of these showing [offline] in the text, yet they all show a different % status byte. And none of the ones listed showed the . Offline status? 5) Do you see anything that we need to feedback to the Echolink Author as a global change that would help force his users into entering correct data? Thanks Bob, WB4APR >>> The only mod I'd make is that the source >>> call be the station's call. No, as per above. Bob
- Previous message: [aprssig] Gating Objects from Internet to RF (fina?l)
- Next message: [aprssig] Gating Objects from Internet to RF (fina?l)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
