[aprssig] APRS data entry device

[Art]

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



At 09:24 AM 10/29/2006, you wrote:

>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
>
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.408 / Virus Database: 268.13.17/505 - Release Date: 10/27/2006
>
>
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.408 / Virus Database: 268.13.17/505 - Release Date: 10/27/2006


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.408 / Virus Database: 268.13.17/505 - Release Date: 10/27/2006