[aprssig] whatever happened to....
bruninga at usna.edu
Tue Aug 21 13:39:19 CDT 2007
Regarding using the D7 as an object entery device at events:
First, see this page:
> I've found that if you mess around with the callsign,
> the radio gets tweaky.
Hummh, I've never noticed something like that..
> Besides, if you change the mycall setting [to the
> OBJECT name] then you have to remember to ID once
> every 10 minutes to be compliant.
That is part of preparation I mentioned. Put your callsign in
the text of the object once and it will work for all objects and
the entire event. Also set your TX rate to once every 10
minutes and you are guaranteed to be legal.
> at some point you'll get two or three bunched up
> together coming past.
I assumed one would write down the numbers on a scratch pad and
then send the data as convenient. Its never a good idea not to
have a notepad backup. Any such data application usually should
be planned with a paper trail anyway.
> Not only that, they would also pass each other at
> times, so simply incrementing/decrementing the ID,
> is not an option.
That was not what I meant. What I meant was that you can use
the TUNE knob on the D7 to rapidly increment or decrement each
digit and be able to quickly change one vehicle number to
another with just a few clicks and turns. Instead of having to
key in an entire multi-digit number from scratch each time. You
can do it in under 10 seconds per vehicle for even a 6 digit
vehicle number. (faster than voice...)..
> That's only really doable with a PC attachced running
> something like Link700, and I don't know how successful
> that would be. Forget about a stand alone D7, it's
> not viable for that sort of use.
Not my experience at all. We used D7's handheld at a boy scout
event to report Troop number and score from dozens of stations.
It worked beautifully, and even the old codgers at Netcontrol
that said it couldn't work appreciated it and agreed it was a
benefit for them.
There was not even any PC at net control either to receive the
data. It was just a D700 with its Front Panel attached to his
Clipboard. Here is why he appreciated it though he had never
seen a D700 before:
1) He was harried by 20 different voice reports of scores coming
in from dozens of voice operators. And he was trying to take
check ins, write down the data, acknowledge the number, and move
on to the next one all by voice.
2) For the D7 data coming in, that was one less
check-in-voice-transcription-re-check-evolution for each D7.
3) For the D7 data, he just waited for most of the voice stuff
to come in, or during any lull in activity, and then he could
simply press the LIST button and there was the data from each D7
station. He could write it down at his leisure and delete it at
4) Meanwhile he could respond with immediancy to anything new
that came up on the net, because he could interrupt his
transcription of the D7 data at any time and come back to it at
In other words, using a D7 to report data had these advantages:
A) removed a load from the voice reporting net
B) gave guaranteed, error free delivery
C) recorded instantly at net control for later review
D) moved transcritption from immediacy to background
E) Could be auto recorded by a PC with TNC/software
F) or simply a D700 control head puts the data at point of use.
Sure, poor planinng or poor application of sensible formats for
the data can make such an application unwieldy, but on the other
hand, the D7 can make a fantastic data entry device in many
applications if prior thought is put into it formats and the
Again, see how we did it for the Scout Event:
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.
> Dave G0WBX.
> > -----Original Message-----
> > From: Robert Bruninga [mailto: bruninga at usna.edu
> <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
> > > entered/exited a stage, and more than once, we lost
> > 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
> > has to do is change his MYCALL to the vehicle ID and
> > 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
> > will use that location. I'd suggest adding position
> > ambiguity so that all these vehicle symbols at each
> > are spread out a little bit on the map display...
> > It should be very easy to quickly dial in vehicle
> > the HT since all you have to do is inc/decrement the
> > from the last one... Then press the BCON button until
> > see confirmation that it was digipeated, and then you
> > all surrounding APRS displays are updated.
> > This also lets each D7 Holder SEE on his D7 display
> > the vehicles are (in range and bearing from his
> > Too few people use these radios to their full
> > 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
> > be scanned
> > > on the way IN to a stage and on the way OUT of a
> > >
> > > they could also be scanned IN to service and OUT of
> > >
> > > With a GUI of some form that could display data
> > > (tabulated....so maybe in columns with respect to
> > callsign has
> > > checked in, and totals for each station... so under
> > would be
> > > all cars checked into stage X, and under K9FRT
> would be all cars
> > > checked OUT of stage X, with similar arrangements
> > 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,
> > only STARTS
> > > FINISHES and SERVICE need to be on the network....
> > >
> > > at this point, it would probably be cut off from the
> > world, (most
> > > stages are well away from APRS coverage anyway), but
> > 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
> > 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
> > map some
> > > > sort of code to APRS and assist with generating
> > > >
> > > > 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
More information about the aprssig