[aprssig] RFID Hotspot revised format

[Robert Bruninga]

My RFID HotSpot is working now in a stable environment

The web page and SPEC have been updated.
www.aprs.org/aprs-rfid.html

1) Uses HotSpot OBJECTS so full 9 character names can be used

2) Solves the ^C line-wrap problem by changing the SENDPAC
character and setting the CR command to suppress the ^C

3) You have to step on the hot spot.  If your foot is swinging
at full speed over the reader you might not get read.   

4) The coil Is 5" in diameter and your foot (with the card) has
to hit within an 8" diameter HotSpot to be read.

You can see the tag working as I walk in and out of my office:
http://aprs.fi/?c=raw&call=WB4APR-5

If anyone else wants to build one, let us know.
Bob, WB4APR


> -----Original Message-----
> From: Robert Bruninga [mailto:bruninga at usna.edu] 
> Sent: Sunday, February 21, 2010 2:00 PM
> To: bruninga at usna.edu; 'Lynn W. Deffenbaugh (Mr)'
> Cc: Bob Bruninga
> Subject: RFID Hotspot revised format
> 
> Lynn,
> 
> I have modified the spec somewhat based on new things.
> 
> FIRST, the packet format should be simply
> 
> SPOTID>APRFID,path:SddddddddddkkCL
> 
> The ^C problem has been eliminated thought I think you need to
> look for all possibilities, and there are at least 8 now
> depending on how the user sets up his TNC.  My new hotspot.txt
> file now gives the commands to:
> 
> 1) Change the COMMAND charcter from ^C to ^D
> 2) Change the SENDPAC character to ^C
> 3) Suppresse the transmission of that ^C with CR OFF
> 
> I have now made the HOTSPOT name be an object.  Generally it
is
> from the HOTSPOT TNC.
> 
> The format for that object will include this object text:
> dddddddddd at SPOT-NAMEfreetext... !DAO!
> 
> These will show u p nicely on all D&, D700 radio front panels.
> 
> So I have updated all the web page and the two spec files..
> 
> aprs-rfid.html
> rfid/hotspot.txt
> Rfid/associator.txt
> 
> I need to merge the bottom two text files back into a single
> document.
> 
> My tag reader is now on the air again, but I wont be here to
> trigger it...
> 
> Bob, WB4APR
> 
> > -----Original Message-----
> > From: bruninga at usna.edu [mailto:bruninga at usna.edu] 
> > Sent: Sunday, February 21, 2010 8:45 AM
> > To: Lynn W. Deffenbaugh (Mr)
> > Cc: bruninga at usna.edu
> > Subject: Re: RFID Reader Monitor Running
> > 
> > >> More importantly, it would have failed 
> > >> the checksum test and ... been ignored.   
> > >
> > > Actually, I'm still not sure I like the 
> > > checksum checking as it makes the entire 
> > > callsign translation database specific 
> > > to this ONE format of RFID tag. 
> > 
> > I don't follow?  The tag number is 10 bytes.  This initial 
> > system we are building -is- sepcific to that 10 byte RFID 
> > card and system.  It has to be.  If other type cards are 
> > introduced, then we have to parse them as well.
> > 
> > > As for bad checksums being ignored, they 
> > > would be because the 12 digits would not 
> > > match any registered callsign.
> > 
> > But that obviates any advantage of a checksum.  Sure it will

> > not match -that- call, but there is a good chance that it 
> > will match someone else's call.
> > 
> > > I'm thinking further out on this one than 
> > > restricting the solution to the SparkFun 
> > > readers.  There are certain to be clubs 
> > > out there that want active tags, faster 
> > > readers, longer range, and would still like 
> > > to register their raw tag values to callsigns.
> > 
> > And nothing prevents that.  Its like weather stations... we 
> > have to provide provision for parsing any of the various 
> > hardware and formats. 
> > 
> > > As for displaying the tag value, maybe we 
> > > need to swap the display around and put 
> > > the reader ID and RFID first, and let the 
> > > raw ID just continue off the screen.  
> > 
> > That's a good idea, but I don't see a good translation to 
> > english.  1234567890 at clubhouse makes sense.  But 
> > @clubhouse1234567890 does not.
> > 
> > > The raw value isn't important once it's been 
> > > translated to the real callsign.
> > 
> > Oh, not at all.  It is extremely important!  That is the 
> > mechanism that propogates the callsign association worldwide

> > everytime the card is used.  It is the basis of the entire
> system.  
> > 
> > Remember, your central server will only temporarily output 
> > these finished combined APRS CALL-POSITION-TAG.NO. packets 
> > into the APRS-IS just so people can start seeing this work 
> > immediately on APRS.FI, FINDU, etc.  All they have to do is 
> > build a reader and it will work immediately (instant 
> > gratification).  But once we have a client that is easy to 
> > install at someone's home or portable station (to serve his 
> > area), then all call associations are done LOCALLY so that 
> > they appear locally on RF first, independent of the
APRS-IS..
> 
> > 
> > But captured globally via the resulting APRS  
> > CALL-POSITION-TAG.NO. packet.  Your CENTRAL server at that 
> > point will also be monitoring and collecting all such 
> > associatinos, but not necessarily directly from the raw 
> > reader packets (most will not reach the central server since

> > they will be on a different clear channel in some cases...  
> > So your long-term central clearing house for all tag#'s will

> > rely on simply monitoring all the CALL-POSITION-TAG.NO.
> packets.
> > 
> > Your server then makes that data base available for download

> > to -seed- any new LOCAL client CALL-ASSOCIATOR and for 
> > queries if needed...
> > 
> > I'm revising my web pages at home, but cannot update them 
> > until I get to work.  Probably wont happen today (sunday)...
> > 
> > Thanks!
> > 
> > Bob, Wb4APR
> > 
> 
>