| |
ZL3AI > APRDIG 12.06.04 21:31l 755 Lines 31057 Bytes #999 (0) @ WW
BID : 3436-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 06, 4/9
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040612/1900Z @:ZL3VML.#80.NZL.OC #:25697 [Chch-NZ] FBB7.00i $:3436-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: OPENtrack Binary Versus ASCII
From: John Hall <n5jrh@houstonhams.org>
Date: Sun, 06 Jun 2004 12:30:56 -0500
X-Message-Number: 47
At 11:50 AM 6/6/2004, you wrote:
>>>>Henk de Groot <henk.de.groot >>>
>>>4) APRS allows extensions just just fine.
>>
>>Not true, APRS relies on ASCII... You can't extend APRS
>>with a pure binary protocol...
>
>Programmers whining again. And why would the END
>USER in the field care if its ASCII or BINARY as long
>as it works?
The Programmers are not whining, they are just pointing out the current
problems with APRS. A protocol that is easier for an embedded machine to
read, will benefit the end users in the long run.
>>I don't know how you envision to squeeze in a binary
>>protocol..
>
>We dont, APRS never planned on using binary and never
>will. It was fundamental to APRS that all packets were
>7 bit ascii to avoid any problems with Binary, ASCII works
>everywhere. Binary does not. Remember, APRS is supposed
>to work for users, not make the job simple for programmers...
Why not use binary? It is an acceptable form of encoding, parses easier
than ASCII, and the end user really does not have to see the packet, just
the parsed output.
----------------------------------------------------------------------
Subject: RE: The NEXT Greatest thing to APRS!
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 10:35:48 -0700
X-Message-Number: 48
>Remember, APRStouch-tone lets ANY HT, or mobile
>radio with a touch tone pad do ANYTHING and MORE
>than any of the Kenwoods. But in a similar manner.
I think the main thing that's turned me off to the concept is my experience
with cellphones using the same type of input device. It's tedious and
frustrating - I'd prefer having a single button to talk to my phone with CW,
it'd be faster.
And looking at the four 2-meter handhelds I've got in easy reach, one
doesn't have a DTMF keypad (Alinco DJ-S11T), and none of the others show the
corresponding letters on the keys like a phone does. And the placement of Q
and Z doesn't follow the convention used in any of the cell phones I've
used.
My phone also lets me see what I've typed. My HT doesn't.
I'm not saying it's not a useful innovation. It's just one that I don't see
how I could put to efficient use.
I'd rather see something like a tiny barcode wand with an APRS encoder
that'd plug in like a speaker mic. Or that WAS a speaker mic, too. The
encoder would know your callsign and such to avoid having to enter that
every time. At fixed checkpoints, you'd have pre-printed barcodes with the
location encoded. No need to even pre-program the server side with
locations.
A card with individual letters and pre-selected words or phrases could let
you send messages. Yeah, it'd still be tedious, but not as bad as entering
DTMF tones all day.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Mikael Eriksson" <mikael.eriksson@mbox301.swipnet.se>
Date: Sun, 6 Jun 2004 19:40:38 +0200
X-Message-Number: 49
>This paragraph is being interpreted in a manner that was NOT
>the original intent. I wrote it. That sentence says NOTHING
>about PID's. It was referring to all other UI packet formats.
>And UI packets ALL have a PID of F0. The same as APRS...
If you look into the AX.25 spec it says that UI packets can have
pids (layer 3 protocol) that are:
0x01 ISO 8208/CCITT X.25 PLP
0x06 Compressed TCP/IP
0x07 Uncompressed TCP/IP
0xC3 TEXNET
0xC4 Link Quality Protocol
0xCA Appletalk
0xCB Appletalk ARP
0xCC ARPA Internet Protocol
0xCD ARPA Address Resolution
0xCE FlexNet
0xCF NET/ROM
0xF0 No layer 3 protocol implemented
This mean that all these pids can show up on the APRS frequency and are
legal AX.25 UI frames. But APRS can't share the freq with any of the above
protocols without breaking. This means that is is the APRS frequency that
tells if it is APRS or not!??
>1) The spec was very clear in saying that APRS *TRANSMIT
> with a PID of F0
>2) The authors of the spec and anyone with any experience
>over the last 22 year of AX.25 knew that it was IMPOSSIBLE
>to declare that APRS "should" only RECEIVE same.
>Since the authors of the spec all KNEW that this is a TNC
>function and the APRS spec was REQUIRED to only
>address APRS, and not TNC's.
Why bother to transmit with 0xF0 if it isn't sure that is ends up at the
other station as 0xF0? Everyone SHALL transmit 0xF0 but can't be sure that
everyone else does?!
All this APRS pid stuff does not make sense........
Regards
Mikael Eriksson
----------------------------------------------------------------------
Subject: Introducing "OPENAPRS"
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Sun, 6 Jun 2004 21:12:47 +0300
X-Message-Number: 50
Since it seems that the APRS world is about to be split apart into two
groups. Why not introduce a new Specification based on the Opentrac concept
and call it OPENAPRS?
I know this sounds like im throwing fuel on the fire, but believe me, I
would rather see a new spec than to continue this argument. Hell OPENAPRS
could also be implemented in a way that it can also ingest APRS 1.0
formatted data while still providing the functional benefits being argued
for by Scott.
The result would be people who are interested would get envolved, those who
are not would not. Those like me who see the value of both systems would
have the best of both worlds. What do you think?
Julian
OH8GEJ
DG2JW
----------------------------------------------------------------------
Subject: Re: 30 Meter Policing needed.
From: Arte Booten <n2zrc@earthlink.net>
Date: Sun, 06 Jun 2004 14:19:00 -0400
X-Message-Number: 51
Hi all,
Rich G. wrote:
>W7LUS and I were a couple of ["zero-beat" stations] with W3ADO. Peter and
>I are gone and I believe W3ADO is also.
and Clay O. added:
>W3ADO's APRS HF beacon station fell from priority ...
Hasan Schiers (can't remember his zero-land call) also ran one. So I
guess there isn't anyone nowadays that stations can tune to as a reference
frequency. Perhaps several of you with TCXO-regulated rigs can agree to be
such reference points. At least one of them would need accurate measuring
instruments to be sure you're tuned correctly so everyone else can use you
as that standard.
Me? I'm just one of those no-code wonders ... 73
+-------------------------------------------------------------------------+
|Mr. Arthur "Arte" Booten !>>ReMoVe .n0sPaM<<! <n2zrc.n0sPaM@arrl.net>|
|Official Emergency Station NYC ARES/ Bronx County Radio Officer NYC RACES|
|Riverdale, New York 10463 [FN30bv] !4052.71N/07354.06WNPHG5370/A=00240|
|PGP Key Fingerprint: 90B6 9236 A783 2C3C E08B DDCB 2F12 AE42 410B A7A8|
+-------------------------------------------------------------------------+
----------------------------------------------------------------------
Subject: Re: OPENtrack Binary Versus ASCII
From: Jeff King <jeff@aerodata.net>
Date: Sun, 6 Jun 2004 14:27:25 -0400
X-Message-Number: 52
On Sun, 06 Jun 2004 12:50:41 -0400, Robert Bruninga wrote:
>>>>Henk de Groot <henk.de.groot >>>
>>>4) APRS allows extensions just just fine.
>>
>>Not true, APRS relies on ASCII... You can't extend APRS with a pure
>>binary protocol...
>
>Programmers whining again.
The ITU differs with you.
http://life.itu.int/radioclub/rr/art01.htm
1.56 amateur service: A radiocommunication service for the purpose of
self-training, intercommunication and technical investigations carried out by
amateurs, that is, by duly authorized persons interested in radio technique
solely with a personal aim and without pecuniary interest.
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: Jeff King <jeff@aerodata.net>
Date: Sun, 6 Jun 2004 14:27:30 -0400
X-Message-Number: 53
Hi Juregen:
On Sun, 6 Jun 2004 18:23:37 +0200, db2fm wrote:
>Am Sonntag, 06.06.04 um 13:52 Uhr schrieb Robert Bruninga:
>
>>>>>Danny <danny@messano.net> 6/5/04 10:40:04 PM >>>
>>>There are flaws in the APRS system.
>>I wouldn't call them flaws, but hindsight. Of course, things can
>>be put together more streamlined with a total re-invention of the
>>wheel, but why? When it would sacrifice all existing users?
>
>That's big b***sh*t! Sorry to say that as hard as I did! You
>americans normally tend to use hard words and propaganda
WHOOOO Jurergen! Please don't paint broad brushes here. I'm seeing
what your seeing here, and it appears the broad brushes are indeed being
used by SOME Americans, but not all.
I've stressed not to make this into a US vs. THEM thing, and that applies
across the pond(s) as well as the protocols. Not saying you are at all, but
wanted to cut this off at the knees.
That much being said, I don't disagree with your post at all, just letting
you know I, as well as many others, see it largely the same way you do,
that we too want innovation in the hobby. I'm sure you know this, but
better to state it then assume it.
Now, something a bit more incidius that you brought up, was the word
PROPAGANDA. That is a tough one to deal with it. And I've not had alot of
luck dealing with it here myself. Look at the two things I did here to deal
with PROPAGANDA:
1. Every person loudly screaming about OpenTrak problems, I asked them to
document first hand what problems they observed. At least 15 times I asked
this on and off SIG
2. The APRS-WG "still exists" myth.... now and in the past, when APRS
celebrities implied the group was still viable, I said "show us the money".
Who are the members, is the charter being followed? etc etc
3. "3000 Kenwoods where broken by OpenTrak". 20,000 users obsoleted!! See
my Empirical data on Kenwood problem post (Henk also provided some hard
data as well).
And you know what? In each and every case, those challenged here ignored
the direct question. In history, this is how the propagandist operates.
They tend to either ignore or suppress direct and documented challenges to
their position. This is not at all unique to APRS, it is part of the
human condition.
All I can say, is hang in their, I was kinda down about this at first, but
I am seeing there are hams interested in innovation, even in my own
country. Think of this as the struggle humanity faced when it entered the
industrial age or the reaction anything "new" can bring out in a tribal
society. Same human dynamics at work here and logic and reason are taking a
backseat. We've got more change ahead, but I am seeing some faint light at
the end of the tunnel. Through all the smoke, mirrors and chest beating, I
am seeing some hams working to make things work, and not telling us why
they can't. There is hope still for this hobby.
73
Jeff wb8wka
----------------------------------------------------------------------
Subject: Re: OPENtrack Binary Versus ASCII
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sun, 06 Jun 2004 20:33:15 +0200
X-Message-Number: 54
At 12:50 6-6-2004 -0400, Robert Bruninga wrote:
>Programmers whining again. And why would the END
>USER in the field care if its ASCII or BINARY as long
>as it works?
Clear bennefits for the end user:
1) more up-time
2) air-time efficiency build in
3) doesn't crash as soon as somebody comes om air with a correctly tagged
completely different protocol.
4) doesn't put users in China because of a wrong TNC setting
5) allows addition of the symbols they need for the job
6) saves air time by packing the needed elements into a single packet
7) enables the availability of small feature rich low-power devices
8) reliable, you KNOW what you get on air:
8.1) no random positions where you have to guess what datum is used
8.2) standardised metic data
8.3) higher precision
9) clear way to expand which for the end user means getting new features faster
10) ability to use non-latin languages
11) last but not least a development crew who is willing to listen to the
end-users needs
Now let's assess these clear bennefits with APRS:
1) The more kludges added to APRS, the harder to pass an the more
unreliable the end-users programs get. No I have not forgotten the crashing
WinAPRS clients that kept the APRS-SIG busy for months.
2) Using only 37% of a byte (92 values out of 256) is not efficient.
3) The OpenTrack issue already showed that this is not one of APRS's assets
4) Remember the MIC-E problems, so much for "ASCII works everywhere"
5) APRS allows a limited number of symbols. End-user proposals have to be
shot down because there is no space to put them. APRS doesn't provide a
mechanism to fall-back to a more generic symbol if an application doesn't
have the more specific symbol.
6) APRS is not able to combine data elements at will, sending WX data
simultaneously with telemetry is for example impossible, it takes 2 packets
in APRS.
7) Parsing APRS is a nightmare, if there are small devices they are not
feature rich. Devices like the TH-D7 can only handle a subset of all
features due to APRS's code-space requirements. Small feature rich
low-power devices for the end users using APRS, you may be lucky to get the
basics in.
8) APRS used to be using the WGS84 but that was shot down a few weeks ago,
you can't rely on what you get:
8.1) APRS provides: an ugly datum hack, incompatible with all existing
APRS clients (they all disrecard the datum and keep showing the wrong position)
8.1) APRS uses imperial measurements that nobody else in the world uses
anymore which means mode code to convert and more bugs
8.2) The highest precision in APRS doesn't meet SAR requirements. The
higest precision position format is now excluded for objects. This would
never happen if there was only 1 position format that provided all. Extra
precision was added with yet another ugly hack, which again is recognized
by any of the existing clients in the field
9) Every extension in APRS requires a discussion and contemplating which
trick to use next to sequeeze it in, these is no defined way at all to do
it. Virtually every proposal on the APRS-SIG will be first shot down by the
APRS founder and will then magically re-appear a week later in an other -
often less favourable - format which is of course FUNDAMETALLY different
than the original propsal and which subsequently nobody implements because
of the nasty repercussions on the code to implement it.
10) APRS doesn't even know about Latin languages, it only knows 7 bit
ASCII. The ability to add Chineese will enable 1 billion potental new users
that have been cut off from APRS.
11) The APRS-WG is dead, the APRS founder is against any change he did not
invent himself. Every other need is shot, most of the time using
obvuscation that it was never intended for APRS or FUNAMENTALLY wrong or
the most recent example that it is already in since 1994 but so hidden that
knowbody knows that it was, let allone how it's put to use. The end user
suffers, his needs are NOT addressed.
So the end-user has a lot to gain by a new clear protocol. Co-existense
enables a smooth transision. OpenTrack can be first used in closed groups,
oftern those groups that have been asking to get their needs served in APRS
and never got a satisfactory response. I think about SAR groups and events
here.
The APRS comunity can blame the existence of OpenTrack only on themselfs.
The cumbersome way to get new things added and get the user-needs addressed
was bound to lead to rebellion. I think Scott made the only sensible
discision to start from screatch and let APRS dig their one grave. It is
the gross neglect to serve the END USER, the very same you say to serve,
that led to this.
Just continue the APRS hacks to provide short term solutions if you think
that is in the best interest of your end-users. Let OpenTrack take care of
the future and long-term solutions. I know who in the long-run serves the
end-user best...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: OPENtrack for programmers, APRS for users
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sun, 06 Jun 2004 20:45:56 +0200
X-Message-Number: 55
At 13:24 6-6-2004 -0400, Robert Bruninga wrote:
>Programmers whining again. Where is PID 77 of any benefit
>to the END USER IN THE FIELD?
Do you suggest he should have used PID F0 (TEXT) for the binary OpenTrack
protocol and trash every existing APRS application including Kenwoods
instead? The bennefit to the end-user of using PID 77 is that the OpenTrack
packets do not trash the equipemnet used by the END USER IN THE FIELD.
I wonder if you understand the technology at all, have you every read the
AX.25 specification?
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: RE: OPENtrack for programmers, APRS for users
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 12:04:34 -0700
X-Message-Number: 56
>Programmers whining again. Where is PID 77 of any benefit
>to the END USER IN THE FIELD?
It was programmers who developed HTML and HTTP. Where was the benefit to
users there? Why not keep on using Gopher and FTP? You could go on
cramming new features there all day.
>I dont see that at all. 95% of all mobils are Kenwoods
>using the very short Mic-E format that works just fine. As
Gopher worked just fine too. Still does work. Heck, your browser might
even still support it.
>packets and his was 66 bytes compared to the 38 or so
>in APRS todo the SAME THING.
Not to do the same thing. If you don't understand the difference between a
machine-readable information transport mechanism and a plain-text comment
field, I'm not going to waste more time explaining it again.
>I fear you are being sucked into the missleading propaganda
>of programmers again, and not looking at the value for the
>end user...
And these damn network engineers keep at it with their IPv6 migration
without showing any benefit to the millions of home DSL users out there,
too.
>channel is for letting EVERYONE ON THE CHANNEL
>participate in the net and to SEE ALL IMPORTANT
>data of interest in the event.
I hate to tell you this, but 98% of what happens on APRS isn't important.
Take a look at your APRS IS feed right now and tell me how many real-time
special events you see going on. No one is suggesting that we come in with
OpenTRAC-only systems and start trying to participate in APRS events.
>Programmers whinning again. No one said it was easy,
>but shucks, I did it in BASIC for gosh sakes...
Let's see you fit that BASIC implementation into a device with a few
kilobytes of flash and a few hundred bytes of RAM. Heck, try it in
assembly. Kenwood wasn't able to do it, if I recall. They don't support
all of the weather formats that were published at the time, do they?
>job easier EVERY TIME it added a new feature. It still
>requires NEW CODE EVERY SINGLE TIME YOU ADD
>A FEATURE!.
Two things. First, the goal of the spec is to define a rich set of building
blocks that'll let you implement all sorts of applications in a consistent
manner. Second, I think what was being said here is that in OpenTRAC you
never risk breaking existing code by adding new features.
Adding new code will never require going back and re-writing unrelated bits
because someone tried to cram more features in by adding new context rules.
Taking the example of the Kenwoods again, if they used a scheme like this
you'd be able to add your datum specifiers, additional precision, or
whatever without breaking what they already do or making the users sift
through more alphanumeric garbage on their screens.
>APRS avoids this issue by targeting the END USER,
>not the end programmer. Thus, APRS can add anything
>that the end HUMAN USER CAN READ and it never
Then why define anything besides a comment field? What is your
justification for telemetry and weather formats when that could all be done
in plain text?
Maybe because people like seeing wind speed and direction indicators? Or
because it's convenient to see telemetry values plotted on a graph? Do you
not consider that a benefit to the end user?
> 12v / 102 deg.
This is what the OpenTracker does in APRS mode. It's simple, but there's no
way to plot changes over time, or to see at a glance what stations are
reporting this information without looking at their comments.
>In OPENTRCK, Every single HAMHUND will have to
>download and install NEW CODE to parse it and EVERY
>OTHER single change as well. This is why APRS targets
>the END USER. No upgrades required...
You can still put stuff in the comment field if you want - no one's going to
stop you. But we're back to the HTML analogy again. HTML was designed to
be device-independent - used right, it renders just fine on a PDA screen as
well as a full-sized monitor.
On something like the HamHUD or Kenwood radios, display space is very
limited. Having the device know what piece of information is what lets it
display it in the most appropriate way. Or perhaps more importantly, not
display it at all if that's what the user chooses.
And what about our non-English speaking friends? There's some direct
benefit for you. And I'm not just talking about Unicode support. Units and
unit labels can be localized, as well. In the example above, you don't
specify units of temperature, and to non-English speakers it might not even
be obvious what it's referring to. That, and everyone outside the US would
probably rather see it in C anyway.
>Programmers again, not users....
I think you need to get your head out of QBasic for a while and take a look
at what's out there now. With the Internet, and with more modern languages
like Java, it's much simpler to distribute updates to address new features.
We can benefit the users by adding new features quickly, without drawn-out
debates on how to squeeze them into the spec.
>[that nobody on there already can read!] To me that
>is called interference in an existing net...
No different than a user-defined APRS format. You've said repeatedly that
if I want centimeter resolution in a position I should define a new format
for it. If I do that, I'm in exactly the same position, putting data out
there that no one currently understands.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: Introducing "OPENAPRS"
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 12:07:50 -0700
X-Message-Number: 57
>I know this sounds like im throwing fuel on the fire, but believe me, I
would rather see a new
>spec than to continue this argument. Hell OPENAPRS could also be
implemented in a way that it can >also ingest APRS 1.0 formatted data while
still providing the functional benefits being argued for >by Scott.
We've talked about an APRS 2.0 spec many times, and Bob shoots it down for
the same reasons he does OpenTRAC. I seem to remember going through this
debate before I finally decided it wasn't going to happen and starting
OpenTRAC as a separate and parallel effort.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Introducing "OPENAPRS"
From: Jeff King <jeff@aerodata.net>
Date: Sun, 6 Jun 2004 15:08:43 -0400
X-Message-Number: 58
Hi Julian:
On Sun, 6 Jun 2004 21:12:47 +0300, DG2JW wrote:
>Since it seems that the APRS world is about to be split apart into
>two groups. Why not introduce a new Specification based on the
>Opentrac concept and call it OPENAPRS?
I actually think this is a good idea. But APRS is a U.S. trademark
describing an AVL format, so call it something else so we don't have a
problem there
By the way, I have backed away from my earlier thought that is would be a
good idea to reboot the APRS-WG. In reviewing the charter, there is some
trademark and royalty ($$$) language in their, that might be a problem to any
OpenSpec, so really the only thing to do would be to completely scrape it.
Also, everyone that is interested in OpenTrak seems to be pulling together,
so if any new protocol "does no harm", it doesn't make alot of sense to merge
it into APRS.
And lastly, the "powers to be" have made it crystal clear that the APRS spec
is fixed in the year 2000, and somehow it can handle any upgrades within the
existing spec. Fighting windmills is never productive.
But certainly someone else can take the idea and run with it, I just don't
want to at this point.
>The result would be people who are interested would get envolved,
>those who are not would not. Those like me who see the value of both
>systems would have the best of both worlds. What do you think?
I'm hearing there are going to be some OpenTrak presentations at the DCC, so
maybe some informal gatherings might develop there to discuss such things?
I'd certainly be interested myself, and really hope to be able to go. A bit
of a drive for you though ;-) Does Europe have anything similar to the
DCC?
73
Jeff
----------------------------------------------------------------------
Subject: RE: The NEXT Greatest thing to APRS!
From: Sean Jewett <sean@rimboy.com>
Date: Sun, 6 Jun 2004 13:41:26 -0500 (CDT)
X-Message-Number: 59
On Sun, 6 Jun 2004, Scott Miller wrote:
>>Remember, APRStouch-tone lets ANY HT, or mobile
>>radio with a touch tone pad do ANYTHING and MORE
>>than any of the Kenwoods. But in a similar manner.
>
>I think the main thing that's turned me off to the concept is my experience
>with cellphones using the same type of input device. It's tedious and
>frustrating - I'd prefer having a single button to talk to my phone with CW,
>it'd be faster.
Not carrying a cellphone I'm fairly sure I understand your point. The few
times I've tried to do something like navigate a touchtone menu w/ a cell
or cordless I end up hanging up and finding a beige box.
>And looking at the four 2-meter handhelds I've got in easy reach, one
>doesn't have a DTMF keypad (Alinco DJ-S11T), and none of the others show the
>corresponding letters on the keys like a phone does. And the placement of Q
>and Z doesn't follow the convention used in any of the cell phones I've
>used.
Well, it's not like the S11T is a powerhouse to begin with. It's designed
to be a simple radio that you don't mind dropping (which is why I more
often that not carry my S41 at hamfests rather than my F6A).
>My phone also lets me see what I've typed. My HT doesn't.
Well, there's been a bit of work done on that, just listen to a repeater
where touchtone use is quite active, ie phone patch.
>I'd rather see something like a tiny barcode wand with an APRS encoder
>that'd plug in like a speaker mic. Or that WAS a speaker mic, too. The
>encoder would know your callsign and such to avoid having to enter that
>every time. At fixed checkpoints, you'd have pre-printed barcodes with the
>location encoded. No need to even pre-program the server side with
>locations.
Well, I would suggest starting with those CueCat's Ratshack gave away.
Better yet, interface it with Hansen's D700 keyboard interface since the
CueCat's were designed to be the eq of a keyboard wedge. That said, the
data that comes out of those cuecats are "encrypted". Hacking the
encryption is well documented and I believe there are hardware hacks to
turn it off. Larry Wall did a one liner in perl that's completely sick
but shows how easy it is to decrypt the data from the cuecat.
Obviously going the Hansen keyboard interface route is the easiest though
I've not tried to modify any cuecats to disable the encryption in the
hardware.
The question then becomes, if the hardware hack is not easy / impossible
can you still use it and have the decryption done on the client end?
Better yet, would it be legal? It's not like it's hard to decrypt but it
is encrypted.
>A card with individual letters and pre-selected words or phrases could let
>you send messages. Yeah, it'd still be tedious, but not as bad as entering
>DTMF tones all day.
Well, if you use a D700 w/ Hansen's keyboard interface you can save
yourself an additional bit of time.
I would say that Hansen has most of the work done (thanks again John!) and
it'd just be a matter of figuring out how to decrypt either via PIC or on
the Cuecat itself to make this happen.
Sean...
--
The punk rock will get you if the government don't get you first.
--Old 97's
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
KG4NRC http://www.rimboy.com Your source for the crap you know you need.
----------------------------------------------------------------------
Subject: RE: OPENtrack for programmers, APRS for users
From: Steve Dimse <k4hg@tapr.org>
Date: Sun, 6 Jun 2004 15:35:30 -0400
X-Message-Number: 60
On 6/6/04 at 12:04 PM Scott Miller <scott@3xf.com> sent:
>>Programmers whining again. Where is PID 77 of any benefit
>>to the END USER IN THE FIELD?
>
>It was programmers who developed HTML and HTTP. Where was the benefit to
>users there? Why not keep on using Gopher and FTP? You could go on
>cramming new features there all day.
Geez, that really sums up the difference between the people that built APRS
and you. Our focus from the beginning was on the users of the system, that
is what has driven us. It neatly explains why you show no concern about the
problems you could cause to APRS users...you do not care about benefiting
the users, so why should you care about hurting them???!!!
>>channel is for letting EVERYONE ON THE CHANNEL
>>participate in the net and to SEE ALL IMPORTANT
>>data of interest in the event.
>
>I hate to tell you this, but 98% of what happens on APRS isn't important.
>Take a look at your APRS IS feed right now and tell me how many real-time
>special events you see going on. No one is suggesting that we come in with
>OpenTRAC-only systems and start trying to participate in APRS events.
My ***, do you really believe that? No wonder you do not care about harming
the APRS system.
Yes, a person's position is not important to you, but that does not mean it
isn't important to them or to others. You seem to totally lack the ability
to understand the wants and needs of others. If the data on APRS were
unimportant, findU wouldn't be getting nearly 10 million hits a
month...that data you dismiss must be important to someone...but it isn't
you, so you call it unimportant. Do you realize how much of yourself you
have revealed?
What about CWOP? Do you consider improving the forcasting of weather
unimportant? Probably not, you'd probably blame people for living in the
path of a storm.
APRS is a system that was developed to meet the needs of others, not to
show off our programming skills. It is a shame you choose not to focus your
skills on serving others, it has its own rewards.
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
