[aprssig] rfid uses in real world.

Tue Feb 23 16:26:16 EST 2010

Hmmm.... We don't have to catch the bikes at full speed.  In the enduro
race, they have to pause at the checkpoint so that a check point worker can
write the time on their placard.  While the checkpoint worker is doing that,
he waves a wand near the RFID tag.  How's that?  Sorry, I didn't include
that in the orginal post.  Of course the catch is that once they start using
RFID, they aren't going to want to slow down since it will no longer be
necessary to write the time on the placard.  I can reason that they would
continue to use the time on placard method as a failsafe scoring backup.

Wes
---
God help those who do not help themselves.

On Tue, Feb 23, 2010 at 16:09, Lynn W. Deffenbaugh (Mr) <
ldeffenb at homeside.to> wrote:

> 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°<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 listaprssig at tapr.orghttps://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>
> _______________________________________________
> 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/590d7e03/attachment.html>