[aprssig] APRS RFID central approach (spec5)?

[Robert Bruninga]

Stop the presses!
Now that I see how easy it is to make the RFID reader...

I'm thinking of scrapping the specialized TAG-TRACKER hardware
proposal and designing the system so that ANYONE can attach a
$25 RFID reader to ANY TNC, and bingo, a HOT SPOT results...
Here is the new thinking...  Lets call it spec version 5...

For the APRS-IS, then only ONE central site is needed to make
the callsign association for the APRS-IS and this will get this
system launched rapidly.  But in local RF domains, a local
verison would also be needed to put the result out on RF.  But
by making it work immediately on the APRS-IS, it lets everyone
get going... I'm suggesting this could all be done at APRS.FI
(though I have not even mentioned it to Hessu yet, but I will
use it as an example...)...  We need three things to make any
RFIS system work.  A tag number, a callsign association, and a
position of the reader.  OK here it is:

*** TAG NUMBER ***

APRS.FI (or other central processor) looks for packets of the
form

SPOTID-S>APRFID,path:SddddddddddKKCLE

Where S is STX
Where dddddddddd are 10 hex characters representing the 5 BYTE
tag number
Where KK is a hex checksum
Where CLE is CR, LF and ETX

This allows ANYONE to plug this off-the shelf $24 RFID reader
into ANY dedicated TNC that has been preloaded with the MYCALL
of their SPOTID-S and the UNPROTO TOCALL of APRFID.  That is the
total hardware investment at any HotSpot.  The reader, any TNC
and a radio.

APRS.FI saves this tag number associated with that SPOTID-S
HotSpot..

*** POSITION INFO:

APRS.FI looks for a standard POSITION PACKET from the SPOTID-S
TNC.  It puts it on the map.  The format of the position report
is standard plus information on the desired latitude and
longitude offset for the list of tag-users at that location from
*that* TNC.

SPOTID-S,APRFID,path:!DDMM.mmN/DDDMM.mmWA AARC club +100/-000

Where most of it is a standard position report with...
Ten bytes describing the location such as AARC Club, etc
Then two signed 3 digit numbers.
The first is the latitude increment in thousandths of a minute
The second is the longitude offset for the callsign list origin

*** CALLSIGN ASSOCIATION:

APRS.FI or other central processor looks for any MESSAGE packet
from any station reporting its TAG NUMBER.  Bingo, now we have
everything.  Tag number, callsign, and position.  APRS.FI puts
them on the map using the incrementing latitude concept in the
indicated thousandths of a minute of latitude above and below
the SPOTID-S location +/- the longitude offset if any.  The
format of the APRS message making the callsign association is:

MYCALL-S>RFCALL,path::RFID_____:dddddddddd

Done!

Won't that do it and make it work entirely within existing APRS
and using any old TNC.  The only purchase for a HotSpot is the
$24 RFID reader?

Lets go!
Bob, WB4APR

> -----Original Message-----
> From: aprssig-bounces at tapr.org 
> [mailto:aprssig-bounces at tapr.org] On Behalf Of Heikki
Hannikainen
> Sent: Thursday, October 22, 2009 11:43 AM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] Tier 2 Routing Question
> 
> On Thu, 22 Oct 2009, Jason KG4WSV wrote:
> 
> > On Thu, Oct 22, 2009 at 9:06 AM, Matti Aarnio 
> <oh2mqk at sral.fi> wrote:
> >
> >> There was some radical APRS-IS Tier-2 netsplit at 03:00 
> UTC this morning.
> >> About a third of global flow stopped flowing to aprs.fi.
> >
> > Why would aprs.fi be connected to tier 2 and not the core?
> 
> Why would it not be connected to a tier 2 server? The same
stuff is 
> (usually, except this morning) available there.
> 
> I'm hosting a local tier 2 server in the next rack at the 
> same site with 
> aprs.fi. That's the server aprs.fi connects to. The server
used to be 
> directly connected to the core servers, so there wasn't much 
> practical 
> difference whether aprs.fi connected to the local tier2 
> server or directly 
> to the core. It does save a little downstream bandwidth (one 
> downstream 
> full feed instead of two - not that it would matter at all
given the 
> gigabit uplink), and a socket connection from the core 
> servers (they've 
> been on short supply at times).
> 
> It does automatically connect to the core directly in case the
local 
> server goes down. Also, in case the core would not be
available from 
> Finland, at least the data from igates in .fi does get to 
> aprs.fi via the 
> local T2 server. :)
> 
> If there are any further problems with the T2 core 
> connectivity, I'll have 
> to reconsider, of course. But I think the issue will be fixed
and the 
> lesson has been learned.
> 
>    - Hessu
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>