[aprssig] rfid uses in real world.

[Lynn W. Deffenbaugh (Mr)]

My first problem with this isn't with the RFIDgate software, but with 
the RFID hardware.  As Bob recently pointed out, you can't even WAVE 
your foot across the reader, so I really don't see a way that the 
currently proposed readers can catch a motorcycle crossing a 
checkpoint.  I've worked professionally with passive tags on tractors 
and trailers as they move slowly through a gate, and it's not even easy 
to catch them reliably.  The SpeedPass sensors (or whatever they're 
called in your neck of the woods) set up a huge RF field with multiple 
high power readers to pick up cars with powered RFID tags moving at 
35mph (although Orlando finally gave us highway-speed lanes).  But this 
is multiple thousands (if not tens or hundreds) of $$$ per reader 
station.  Probably a bit beyond the budget of a motocross race through 
the woods.

With that technical issue aside, I really have trouble seeing this as a 
logical extension of the RFIDgate that deals with a single position 
update (without speed or heading) at a static reader.  Bob's old 
Destination Waypoints and Manual Position Updating spec seems like it 
would be more applicable.  You can read about it at:

http://wa8lmf.net/bruninga/APRS-docs/MOBILE.TXT

If that doesn't fit the bill (and who knows how many APRS clients do or 
do not implement it), then I'd have to say this calls for a more custom 
program than the generalized RFIDgate that we're attempting at this 
point.  Of course, you could always code the speed/heading text into the 
"freetext" of the reader at an individual checkpoint, and you'd have to 
rely on the actual displaying APRS client to do the dead reckoning 
display after that single beacon was generated.  A stylized map (similar 
to those used in mass transit systems) could be constructed of the 
course so that these speed/headings would bear some semblance of reality 
with a single update per checkpoint.  I don't know if the free text 
would land at the proper position in the position update packet though.

I'd still tackle the question of an RFID reader that can pick up a 
motorcyle moving at speed through a fairly large area.  I suspect you'll 
have some issues getting that accomplished.  If that fails, the 
remainder of your idea could be done with just an Object generator that 
is manually updated by eyeballs at the checkpoints.  The objects could 
still have a speed/heading included in them (Bob, are objects 
allowed/supposed to dead-reckon?) so they'd still do what you described.

Lynn (D) - KJ4ERJ - Just adding my $0.02 for whatever it's worth

Wes Johnston, AI4PX wrote:
> Every year there is a huge motocross race here in the forest.  400 
> riders.  I had thought several years ago about using rfid for them. 
>  
> What would be cool would be if the RFIDgate had two modes.... static 
> table and moving object.  Bob showed us what a static map of rfid woud 
> look like last week over the top of the dayton arena. 
>  
> What about moving objects?  I remember years ago Bob mentioned about 
> how to track runners without a GPS.  Bob said to create an object 
> moving at 6mph for the lead runner and 4mph for the slowest runner.  
> Why can't the RFIDgate do just that?  We know the average speed of the 
> motorcycles should be in the range of 25mph, so why not have a 
> provision in the gateway to publish ojbects with a bearing to the next 
> checkpoint at xx mph?  This would still give us the spacial diversity 
> we're looking for in the static table made by diddling the hundredths 
> of a minute.  In this case we dead recon an object instead of mucking 
> with the lat/long.
>  
> Now let me take this one step further.
>  
> In the case of our motocross race, the course is 5x13 miles of forest, 
> but it's over 70 miles of trails.  These trails crisscross each other 
> like a tangled string.  To see a rider's location on a map doesn't 
> really tell you how far he is thru the race (unless you have a GPS 
> breadcrumb map overlaid)  In the end, people just want to know how far 
> the riders are on the course... in linear terms.  Rider 1 is 50% 
> between checkpoint 1 and 2 for example.  So why not create a pseudo 
> map that contains checkpoints vertically down the left hand side with 
> horizontal lines leading away to the east.  So as a rider crosses 
> check point one, we move him to the position of the checkpoint (on the 
> map) and give him a velocity of 25mph @ 90°.  In the 15 minutes it 
> takes him to get to the next checkpoint, his icon will have dead 
> reckoned 6-1/4 miles due east.  When he gets to check point 2, we 
> reset his lat/long to the QTH of checkpoint 2 and give him a speed and 
> bearing of 25mph @ 90° <mailto:25mph at 90%B0>.  We have now  provided 
> the audience with a linear map of the course.  They can now see how 
> far along completing the course a rider is.  We'll end up with x 
> number of rows of motorcycle icons dead reconing on the map. 
> This line segment table needs to be "located" over a vacant area like 
> a nearby lake. 
>  
> Another perk of this is that riders who don't make it to the next 
> checkpoint just keep right on deadreconing to the east right off the 
> end of the course.  So now we know at a glance that we have some 
> riders who probably broke down between checkpoint X and checkpoint Y.  
> We no longer have to wait for all the riders to get back to the start 
> to begin looking for the breakdowns and medical cases.
>  
> As far as the RF logistics go, we'll have too many riders and packets 
> to fit in the 1200 baud channel.  Figure on 5 checkpoints in a 2 hour 
> race, 400 riders and you've got to transmit 30bytes 2000 times in 4 
> hours.  We'd have to run each check point on a different frequency 
> back to the start of the race (or commo trailer).  Then we can MUX all 
> this data into one stream using a copy of xastir running a telnet port.
>  
> What you think?
> -- 
> Wes
> ---
> God help those who do not help themselves.
> ------------------------------------------------------------------------
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20100223/379ecba8/attachment.html>