| |
ZL3AI > APRDIG 30.10.06 21:45l 212 Lines 7130 Bytes #999 (0) @ WW
BID : 8947-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 28 #29, 1/1
Path: DB0FHN<DB0MRW<OK0PPL<DB0RES<ON0AR<TU5EX<SR1BSZ<IW2OAZ<ZL2BAU
Sent: 061030/1945Z @:ZL2BAU.#87.NZL.OC #:12274 [Waimate] $:8947-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Today's Topics:
1. Where to from here for APRS ? (Andrew Rich)
2. Re: Where to from here for APRS ? (Rod,VE1BSK)
3. APRS data entry device (Bob Bruninga )
4. Re: APRS data entry device (Art)
5. RE: Too many digi's ? (Robert Bruninga)
----------------------------------------------------------------------
Message: 1
Date: Sun, 29 Oct 2006 06:30:54 +1000
From: "Andrew Rich" <vk4tec_at_tech-software.net>
Subject: [aprssig] Where to from here for APRS ?
What do you think the future will hold for aprs ?
1) Touch screen tablets with moving maps, GPS and radio built in ?
ideas ?
Andrew Rich
Amateur radio callsign VK4TEC
email: vk4tec_at_tech-software.net
web: http://www.tech-software.net
Brisbane AUSTRALIA
------------------------------
Message: 2
Date: Sat, 28 Oct 2006 18:12:10 -0300
From: "Rod,VE1BSK" <rodpadmore_at_ns.sympatico.ca>
Subject: Re: [aprssig] Where to from here for APRS ?
Tablets seem more manageable in a mobile environment I would think. I'm
thinking of getting one for APRS.
73 de Rod.
------------------------------
Message: 3
Date: Sun, 29 Oct 2006 09:24:15 -0500 (EST)
From: "Bob Bruninga " <bruninga_at_usna.edu>
Subject: [aprssig] APRS data entry device
The more I think about Scott's idea about a data entry device, the better I
like it.
Especially if it is just a small keypad added to the side of a small
tracker device. This tracker, running on a 9v battery and about the size
of a cigarette pack, would make an excellent data entry device in the
field. Plugged into any HT, it becomes HAM radio's data entry system for
all kinds of public service:
1) Reporting scout troop patrols arrival, departure and scores at check
points
2) Reporting triage patient numbers for Disaster exerciese
3) Reporting passing runners at race events
4) Inventorying large stuff over large areas
etc.
The packet format of such a numeric key pad would be a standard APRS STATUS
packet but with a leading "#" sign as a type identifier. By being a status
packet, then all existing TH-D7's can also enter the same data and be fully
compatible. So here is what it would look like on the air:
TRACKR>APOT11,WIDE1-1:>#1234567890ABCD*#
Notice that all the keys of a standard DTMF keypad would be encoded. And
these numbers can mean anything at any event.
Only the event planners decide what format is required for their own
application, since they will also then write the software to parse out the
info they want.
For our scout troop report, we might call this particular format, "format
1".
>#4*1234*23*95*1115
Meaning that troop 1234 just left checkpoint/station 23 with a score of 95
at 11:15. And in the same format
>#4*1234*24*00*1120
Might mean they just arrrived at station 24 at 11:20.
Such status packets would be transmitted by the tracker using the STANDARD
APRS DECAY DESIGN... that is, the packet is transmitted imediately, then 8
seconds later, then 16, then 32, then 64, then 2 mins then 4 mins, then 8
mins and then 16 mins and then 30 mins... Thus there is excellent
probabiliy that the packet is delivereed quickly, but then there is
redundancy in case of collisions. When a new status packet is entered,
this cancels the previous one and the decay algorithm begins anew.
The packet begins with the TYPE digit which can define several different
formats such as:
1 XXXX a single 3 digit number
2 xxxx*xxx a two field record
3 xxxx*xxxx*xx a three field record
4 xxxx*xxxx*xx*xx a four field record
5 xxxx*xxxxx*xx contians a 5 digit field
6 xxxx*xxxxxx*xx contains a 6 digit field
By specifying the exact number of digits also, then the central data engine
can use format checking to help eliminate errors. If someting comes in
with the wrong format and wrong number of digits, then it will announce
(preferably by voice) "W3XYZ INVALID ENTRY" on the voice channel.
I used 4 digit numbers in these cases, becasue TIME and TROOP numbers are
bot 4 digits. The above are only representative. But hopefully as APRS
users come up with applications, they will better define some standard
formats and also write some neat applications to reecive and tabluate this
data. These then will become defacto-standards, because they will be
readily available.
So if anyone has any formats that would meet their public service needs,
let us know. How many digits are the runner numbers at BIG marathons? We
would need a format to cover that. Something like TIME, RUNNER, CODE where
the code would indicate the type of report... like arrived MM13 or dropped
out, or needs assist, etc...
de Wb4APR
------------------------------
Message: 4
Date: Sun, 29 Oct 2006 10:10:48 -0500
From: Art <KY1K_at_verizon.net>
Subject: Re: [aprssig] APRS data entry device
x-avg-checked=avg-ok-8B8324C
Anyone interested in scanning bar codes should know about the Cue Cat
barcode reader. Originally intended as a privacy invading tool by big
business and given away for 'free', they are cheap and have been declawed
(made safe).
They send a globally unique serial number to a keyboard input on a PC
(wedge), and the contents of the scanned barcode, and then a carriage
return. The globally unidentifiable serial number allowed the now defunct
Digital Convergence Inc. to collect information about your online shopping
habits::>
Hackers discovered a test mode, which defeats the encryption and does not
send the serial number, so the result is a safe and cheap bar code scanner.
http://www.cexx.org/cuecat.htm
http://runme.org/project/+cuecathacks
http://www.gleezorp.com/cuecat/
There are USB cuecats, but they are rarer and command higher prices.
The PS2 keyboard wedge types are very cheap to buy now.
Regards,
Art
------------------------------
Message: 5
Date: Sun, 29 Oct 2006 11:50:51 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] Too many digi's ?
I just updated the recommendations for the old KPC3 8.2 ROMS
This is because we noticed that people using the SS1-1,SSn-N
path would only get one hop and die through an old 8.2 ROM. In
those digipeater TNC's, the UIDIGI list should inlude SS1-1.
The recommendation is now UIDIGI ON
SS1-1,WIDE1-1,WIDE4-4,WIDE5-5 unless it is in an area where 3 hops are not
desired. Then the list should be UIDIGI ON SS1-1,WIDE1-1,WIDE3-3,WIDE4-4
The page is:
http://www.ew.usna.edu/~bruninga/aprs/kpc3+82WIDEn.txt
De Wb4APR, Bob
>-----Original Message-----
>Sent: Wednesday, October 25, 2006 6:29 PM
>
>A few notes about using SSn-N routing:
>
>1) Unless N is bigger than the preferred WIDEn-N, then just use WIDEn-N.
>2) To go beyond the local WIDEn-N and still stay within state, that is what
> the SSn-N system was designed for.
>3) Since SSn-N does not trace, the best way to use it is to use the path
> of SS1-1,SSn-N. This will cause the FIRST digi and the LAST digi to be
> included in the path on arrival.
>
>Good luck
>De Wb4APR
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 28, Issue 29
Read previous mail | Read next mail
| |
