[aprssig] POI engine on APRS-IS (now the ITEM engine)
bruninga at usna.edu
Tue Feb 21 09:21:12 CST 2012
HOW ABOUT THIS?
We already have ITEM-in-MESSAGE since 2008. We simply use it! Then even on
the first transmission from the radio, any client that already has
ITEM-in-MSG will automatically plot it.
The only modification to the ITEM-in-MSG is to let the POSIT have a wildcard
option to be the SENDER's present position.
EXISTING ITEM-in-MSG FORMAT:
* Is normally sent do an individual recipient (so the object can get through
* Normally has a full DDMM.mmN/DDDMM.mmW posit
CHANGE: If the POSIT field is replaced with */* then the posit date from
the sender is used. SO here is an example of placing the hiker FOOTSORE on
MESSSAGE TO ITEM.
MESSAGE: )FOOTSORE!*/*]CSE/SPD comments
This is the existing ITEM-in-MSG format except the DDMM.MMN and DDDMM.mmW
were replaced with *. Notice how the TABLE character is preserved in its
usual position too.
IN this case, ANY existing object/item/df format may be used and we do not
need to invent any new format.
I will update the ITEM-in-MSG format document today to include this
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Bob Bruninga
Sent: Tuesday, February 21, 2012 10:09 AM
To: 'TAPR APRS Mailing List'
Subject: Re: [aprssig] POI engine on APRS-IS (now the ITEM engine)
> POI. Also, can we make the [ts] (table symbol) allowed
> to appear anywhere in the message and if not present,
> a default symbol will be used. Special characters are
> harder to type than characters and if the sender
> doesn't care, why put them through the agony.
I prefer the fixed format requiring the symbol in brackets as the 2nd word.
My assumption is that one only has to enter such an object once, and from
then on, he simply calls up his last transmitted object and cursors over to
only change what he needs to change to uplink the next object. He should
never have to find the [ and ] keys again and for many applications, the
symbol will not be changing muchfor a given event.
> If the first word contains more than 9 characters,
> a failure response is returned.
Agreed. In this case, the incoming messageITEM is ACKED and the error
message sent (and retried as normal)
NEW IDEA. Instead of POI, lets make the engine simply respond to ITEM.
That is more in keeping with the existing APRS nomenclature (and more, see
> ADOPT and KILL are reserved first words for the POI server.
ADOPT is not needed. It is inherent in all APRS applications. Any new ITEM
of the same name will automatically overwrite and adopt in other occurrence
of the same name.
The KILL cannot be a first word, since that is the ITEM name. I think what
we need here is a MESSAGE ADDRESS reservation for KILL (just like OBJ).
Send the same message to ITEM and it makes an ITEM, send the object to KILL
and that results in a kill.
> If the first word is already known as a station or object
> recently in APRS-IS at a different position and different owner,
> then a warning is ...
Not needed as noted before. These message objects are as legitimate as any
other APRS ITEM and so they are already handled properly by all systems.
That is, they overwrite the previous object/item. This is firmly entrenched
in the APRS process.
> I'm trying to figure out an easy way to specify an object interval
> and lifetime, but haven't landed on anything that is memorable
> enough to actually work.
Not needed. The radios that will be used for this will transmit the object
(message) 5 times and then stop. The ITEM engine takes each such
retransmission and does another ITEM generation. The ITEM engine needs no
intelligence or timing.
Transmitting the same ITEM to KILL will do the same thing. It will be sent
5 times to assure it probably gets received, and the KILL engine similarly
needs no timing of its own, but just generates the KILLED object.
Oh, and of course, the KILL and ITEM messages are never acked. Though the
ITEM server can send back (and retry) its own message to the originator
indicating it has been processed. This would be a message back to the
senders call using the ITEM-in-MESSAGE format! Even though the present
radios cannot move these to their STATION list, they at least see that it
was processed, and the advangttage here is that ALL OTHER CLIENTS in the
local RF area, will also see the ITEM-IN-MESSAGE message and if they are
modern clients, then they will PLOT THEM!
In otherwords, the CLIENTS do not need any special OBJ recognizer (other
than implementing the ITEM-in-MSG already proposed). They simply wait for
the OBJ engine to send back the ITEM-in-MESSAGE, and then they all show the
aprssig mailing list
aprssig at tapr.org
More information about the aprssig