Order Tray | Contact Us | Home | SIG Lists

[aprssig] rfid uses in real world.

Patrick winston at winston1.net
Tue Feb 23 21:37:45 UTC 2010


I don't think the idea was with the currently proposed hardware.. I  
believe the idea was to make the spec able to be flexible to be used  
with this sort of application as well rather then only with stationary  
'I am here' setups.

The hardware we have been discussing is a suggestion for the purpose  
of these sites 'I am here' sites being standardized and able to  
interact with people who are from different areas..  Whereas  
specialized applications, such as marathons or motocross would need  
different hardware.

The RFID hardware we use for running races is quite happy moving at  
5-8m/s (18-28 km/h | 11-18 mph) and maintaining a high read rate with  
10 or more tags in the read area at once..  The problem for general  
use because of its specialized nature the hardware and systems to  
drive it are more in the couple thousand dollar range then in the $30  
home brew range.

Faster moving situations will require the move to active tags (which  
is what your SpeedPasses (our 407 transponders) are), which means  
adding batteries and weight, but will give much larger read ranges  
because they are actively listening for the read gate, and able to  
transmit as soon as they are near one because they have a battery...   
whereas the passive tags need to get their power from the reader which  
takes more time.  These systems also tend to have better antennas  
since they have more space.

p

Quoting "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to>:

> 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
>>
>
>




More information about the aprssig mailing list