[aprssig] APRS data entry device

[Bob Bruninga]

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