[aprssig] IGate test needed

[Bill Diaz]

Bob,
  I have to agree with Spider.  Have a few other problems with this as well.
See below:

>-----Original Message-----
>From: aprssig-bounces at lists.tapr.org 
>[mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Spider
>Sent: Saturday, January 29, 2005 10:43
>To: TAPR APRS Mailing List
>Subject: Re: [aprssig] IGate test needed
>

>Bob,
>
SNIP
>
>Just some thoughts/comments:

>a.  Although PHG is useful to some, as an avid APRS user in 
>the field, I do not need to see this, it is not of any value 
>to me and just takes up space (my opinion).  I suspect this 
>to be true for 98% of all APRS users.

I agree.

>b. Why on earth have the Packet in standard format and then have the 
>callsign lowercase....looks really bad.

IMO, the packet should also use a standard format for the originating call.
The author should be encouraged to reduce the originating call to 6
characters or less with optional SSID. 

I assume the originating call and the call sign refer to the same station.  
 
>c.  What is the ________  for?

The multiple underline char take up space and serve no useful purpose I can
see.  The author should be encouraged to eliminate them or reduce them to a
single unique identifying char to reduce bandwidth required for the packet.

SNIP

>
>73,
>
>Jim, WA6OFT

>
>----- Original Message ----- 
>From: "Robert Bruninga" <bruninga at usna.edu>
>To: <aprssig at lists.tapr.org>
>Sent: Saturday, January 29, 2005 8:53 AM
>Subject: [aprssig] IGate test needed
>
>
>> We need someone to test the IRLP to RF objects to see
>> if they can be decoded on various APRS clients *over-the-
>> air*.  The reason is, because they are all being injected into
>> the APRS-IS with 7 character callsigns such as STN4090:
>> Here is the raw packet as seen on FINDU:
>>
>> 
>STN4090>APRS,qAO,IRLPGW:!4233.15NI07608.55W0PHG8760.442.850Mhz+
>71.9IDLE______kb2faf

>> notice that this is not an OBJECT format, but a standard
>> position report.  But it has a 7 character call in the AX.25
>> pseudo header.  When this is sent back out over the air,
>> in 3rd party format, it may or may not be decoded by all
>> APRS clients.  We need to find out if any clients have
>> problems.. especially the mobiles

If a packet is sent in a non-standard format, it is not the responsibility
of the client application to accept it.

I see no reason these packets cannot conform to the APRS spec and to
generally accepted APRS practices.

The author should be encouraged to create packets understood by clients and
not expect all authors to modify code to accommodate his non-standard
packets. 


Bill KC9XG

>> You can use FINDU to find all the IRLP nodes that are
>> injecting their status into the APRS-IS...
>>
>> http://www.findu.com/cgi-bin/symbol.cgi?icon=I0&limit=200
>>
>> Thanks
>> Bob
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org
>> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>> 
>
>
>
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>