[aprssig] whatever happened to....

[Patrick Green]

They have 3 status text fields, that's good, they only have 1 path field,
not enuf and 1 callsign field.  I've found that if you mess around with the
callsign, the radio gets tweaky.  At one time I desided to switch from
ka9scf-9 in the car to ka9scf when I was on foot, the radio needed a hard
reset after a couple callsign switches.  I don't see this as working very
well.  Besides, if you change the mycall setting then you have to remember
to ID once every 10 minutes to be compliant.

73 de Pat --- KA9SCF.

On 8/21/07, Dave Baxter <dave at emv.co.uk> wrote:
>
> Hmmmm...
>
> As a D7 owner and user....
>
> Have you actualy ever tried to change ANY of the D7's parameters on the
> fly, "quickly"?
>
> As in most competitive rallies, even if they start them minutes apart,
> at some point you'll get two or three bunched up together coming past.
> Not only that, they would also pass each other at times, so simpley
> incrementing/decrementing the ID, is not an option.  And that's assuming
> they start in numerical order too.
>
> That's only realy doable with a PC attachced running something like
> Link700, and I don't know how successful that would be.   Even using the
> messaging facility is dificult enough, I know I've tried it for just
> such a purpose.  Forget about a stand alone D7, it's not viable for that
> sort of use.   And in a tree infested environment, you'd need several
> digi's about just to get the info back to raly control, with all the
> time delays that entails.
>
> Someone else some time ago mentioned using bar code readers and trackers
> at known fixed locations.   An equivalent would be a numeric pad for an
> operator to just key in the competitors number into, as they past.
> They'd need a collegue too, to write it down as backup for safety cover.
>
> 73
>
> Dave G0WBX.
>
>
> > -----Original Message-----
> > From: Robert Bruninga [mailto:bruninga at usna.edu]
> > Sent: Monday, August 20, 2007 5:10 PM
> > To: 'TAPR APRS Mailing List'
> > Subject: RE: [aprssig] whatever happened to....
> >
> > > I worked the 100 Acre Wood Rally (www.100aw.org)...
> > > oftentimes, net control would ask how many vehicles have
> > > entered/exited a stage, and more than once, we lost a
> > vehicle either
> > > in service, or in transit.
> >
> > Easy to do.  Just station someone at each check point with a D7 HT.
> >
> > Each time a vehicle passes his checkpoint, all that HT user
> > has to do is change his MYCALL to the vehicle ID and send out
> > a few packets.  This will add that vehicle's object to that location.
> > Done.
> >
> > You preload the D7 with its location, so that all the objects
> > will use that location.  I'd suggest adding position
> > ambiguity so that all these vehicle symbols at each station
> > are spread out a little bit on the map display...
> >
> > It should be very easy to quickly dial in vehicle numbers on
> > the HT since all you have to do is inc/decrement the digits
> > from the last one...  Then press the BCON button until you
> > see confirmation that it was digipeated, and then you know
> > all surrounding APRS displays are updated.
> >
> > This also lets each D7 Holder SEE on his D7 display where all
> > the vehicles are (in range and bearing from his location)...
> >
> > Too few people use these radios to their full potential...
> > Bob, WB4APR
> >
> > > APRS seems like a logical tool to help aleviate this problem a
> > bit...
> > >
> > > since it is impossible to expect every entrant to have an APRS
> > rig in
> > > their car (or be licensed for that matter) and we already have
> > radio
> > > people at the start and finish lines....
> > >
> > > IF the entrant's scorecards could be barcoded, they could
> > be scanned
> > > on the way IN to a stage and on the way OUT of a stage.
> > >
> > > they could also be scanned IN to service and OUT of service.
> > >
> > > With a GUI of some form that could display data received
> > > (tabulated....so maybe in columns with respect to which
> > callsign has
> > > checked in, and totals for each station...  so under KC9UMR
> > would be
> > > all cars checked into stage X, and under K9FRT would be all cars
> > > checked OUT of stage X, with similar arrangements for
> > service and all
> > > other stages)
> > >
> > > The only "issue" might be coming up with a single digi that could
> > > cover the entire race area, though if one or two stations could
> > > digipeat for the event, that might fix tat as well, since
> > only STARTS
> > > FINISHES and SERVICE need to be on the network....
> > >
> > > at this point, it would probably be cut off from the APRS
> > world, (most
> > > stages are well away from APRS coverage anyway), but the
> > main part is
> > > to get the info from point A to point B....
> > >
> > >
> > > > seems to me it would be entirely up to you as to whether or
> > > not it is
> > > > useful.
> > > >
> > > > If the barcode scanner had an RS232 output and the bar code
> > was long
> > > > enough, you could print a complete APRS packet on the
> > barcode and
> > > > connect the scanner straight to a TNC.  Not sure if barcodes
> > can be
> > > > that long...
> > > >
> > > > A bit of glue logic on a microcontroller or a laptop could
> > map some
> > > > sort of code to APRS and assist with generating packets.
> > > >
> > > > Want to tell us about your application?
> > > >
> > > > -Jason
> > > > kg4wsv
> > > >
> > > >
> >
> >
> >
> >
> This mail has been scanned by Palmer Cook Computer Services Limited.
> www.palmercook.co.uk
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.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/20070821/bccef6c7/attachment.html>