[aprssig] POI engine on APRS-IS (no engine required!))

[Bob Bruninga]

NO POI/ITEM/OBJ engine needed!

The existing ITEM-in-MSG format (with the wildcard sender's position option)
can do everything we need here.  We do not even need a special server..

1) As originally intended, the ITEM-in-MSG format allowed for sending an
OBJECT to a mobile RADIO via the global APRS-IS system.  Thus, every client
that has implemented the ITEM-in-MSG format will already see this new
object.  The original intent of this was for the AVRS engine to be able to
send a FREQ object to a called party so he could see where to call.

2) This new use of ITEM-in-MSG for the mobile or handheld radio to initiate
an object can use the same protocol!  But to make it handy, we simply need
to add the wildcard character * to indicate that the sender's own posit be
used.

Beyond that one change, there is no special engine required, no timing
algorithms, no acks, no nothing.  If the sender wants so send an OBJEC To
another person, the protocol does that well and the message will be acked.
If the sender wants to send it so that it is seen on the APRS-IS or other
local clients, then he can send it to ITEM, POI, OBJECT, DF or any other
made-up address he wants and it will be transmitted 5 times and stop.  This
is exactly what we want.

Now, to give the sender some condifence, it would be OK for APRS-IS clients
to offer an ACK service such as if an ITEM is sent to "APRS.FI" as the
message address, then APRS.FI for example could send back an ACK to give the
sender the knowledge that it has been captured.  Hopefully APRS.FI already
does process the ITEM-in-MSG format though it will need to be updated to
recognize the LAT and LONG wildcard.

Done?

Bob, Wb4APR


-----Original Message-----
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Bob Bruninga
Sent: Tuesday, February 21, 2012 10:21 AM
To: 'TAPR APRS Mailing List'
Subject: Re: [aprssig] POI engine on APRS-IS (now the ITEM engine)

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
IGates)
* 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
the map.

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
proposal.  Wow!

Bob, Wb4APR

-----Original Message-----
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
below).

> 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
object!

Slick!

Bob, WB4APR


_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig


_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig