<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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:<br>
<br>
<a class="moz-txt-link-freetext" href="http://wa8lmf.net/bruninga/APRS-docs/MOBILE.TXT">http://wa8lmf.net/bruninga/APRS-docs/MOBILE.TXT</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
Lynn (D) - KJ4ERJ - Just adding my $0.02 for whatever it's worth<br>
<br>
Wes Johnston, AI4PX wrote:
<blockquote
cite="mid:a430b16b1002231140s2d996cbeh278cd6df7e260e63@mail.gmail.com"
type="cite">
<div>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. </div>
<div> </div>
<div>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. </div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Now let me take this one step further.</div>
<div> </div>
<div>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 <a
moz-do-not-send="true" href="mailto:25mph@90%B0">25mph @ 90°</a>. 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.
<br clear="all">
</div>
<div>This line segment table needs to be "located" over a vacant area
like a nearby lake. </div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>What you think?<br>
-- <br>
Wes<br>
---<br>
God help those who do not help themselves.<br>
</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>