| |
ZL3AI > APRDIG 02.04.03 10:43l 254 Lines 10916 Bytes #999 (0) @ WW
BID : 1088-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 27, 2/6
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<VK7AX<ZL2BAU<ZL3VML
Sent: 030401/0857Z @:ZL3VML.#80.NZL.OC #:63026 [Chch-NZ] FBB7.00i $:1088-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: [ Alex ] Re: Digipeating and fun with PIDs
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Thu, 27 Mar 2003 09:04:50 -0600
X-Message-Number: 4
>I hate to disagree. The Cybiko stuff (I know, not a major player, but
>still..) is designed to operate in such an environment. Whenever I
>develop an interface (in this case a KISS/AX.25 driver) I assume that
>the data I receive is wrong, unless I can prove it is correct and I can
>prove that it is what I need. I can not see how else one could implement
>such interface/driver reliably, especially in an environment where
>frames get mangled due to other factors than a mere software bug
>(colliding frames, RF feedback). In fact I test the driver in an
>environment just as you describe. I make no assumptions about the data I
>receive. Doing so is setting yourself up for problems.
....
>Security holes and preventing an application from crashing due to some
>unknown data are two different things. Predictable behavior is what one
>should strive for.
>
>I'm not saying that one should expect that APRS software is bug free,
>but I think it is very reasonable to expect an application not to crash
>simply due to unknown data.
This is the difference between Software Engineering and Hobby Related
Programming. There are some on this list that do engineer their software.
There are others who are hobbiest. Recognizing this fact as the provider of
software and the users of the software is vital. We all need to measure
expectations, and manage our emotions...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Additional Outdoor Temp Probe Available for Ultimeter WX Stations
From: "Eric Christensen" <christensene@mebtel.net>
Date: Thu, 27 Mar 2003 9:39:25
X-Message-Number: 5
Good morning all. I thought this was of some interest to the group. I saw
a stainless steel temperature probe on the Peet Brothers' website which was
"suitable for soil and water temperatures". I called and talked with them
and they said that ANY Ultimeter weather station can have two external
temperature probes. All that was required was a "snip" of a wire or two in
the serial connection and an adapter for $x.xx (and of course the
additional probe) and it would be good to go. The modification disables
the indoor temperature, though.
I also asked her about APRS capability and if both temperature probes could
be transmitted. She said yes with a configuration change.
Thought this would be interesting if those that have weather stations on
the water wanted to do water temperature over APRS.
73s,
Eric KF4OTN
----------------------------------------------------------------------
Subject: Re: [ Alex ] Re: Digipeating and fun with PIDs
From: Alex <kr1st@amsat.org>
Date: Thu, 27 Mar 2003 11:14:13 -0500
X-Message-Number: 6
"Gregg G. Wonderly" wrote:
>This is the difference between Software Engineering and Hobby Related
>Programming. There are some on this list that do engineer their software.
>There are others who are hobbiest. Recognizing this fact as the provider of
>software and the users of the software is vital.
When does one leave the field of Hobby Related Programming and enters
the field of Software Engineering? Perhaps the question is, when does
one takes him or herself serious? I would want to strive for maturity,
especially if I would seek recognition. I think there's a responsibility
there when it comes to robustness, especially if you want to be part of
a colorful system as APRS.
It would be interesting to see though which products you see as being
engineered and which are HRPed. Would you even dare to present such a
list? Would the relationship with the programmer play a roll in the
classification? How will the end user know? (I can hear the
certification crowd thinking.....)
See, you really can't claim on one hand that you are building this great
system that can be used in an emergency situation (where you really need
a set professional tools), and when it fails come up with the
"hobby"-excuse on the other hand. I wouldn't want to explain to an EC
that the wonderful system I presented, and provided him or her with,
just died because some packet had a bad sniffle or got scared of the
unknown.
Because of this "hobby" attitude displayed here so often, I see APRS
merely as a toy. Nothing more, nothing less. A fun toy to play with
nonetheless though.
>We all need to measure
>expectations, and manage our emotions...
Demanding that a system doesn't go haywire when it receives something it
hasn't seen before or because a bit decided not to stay upright, which
is really the only point of discussion, is a very reasonable expectation
and nothing to get emotional about.
73,
--Alex KR1ST
----------------------------------------------------------------------
Subject: dumb tracker with just a GPS and TNC to display waypoints on GPS?
From: "Kelly Cushing" <kellycu@attbi.com>
Date: Thu, 27 Mar 2003 08:10:41 -0800
X-Message-Number: 7
On Tue, 18 Mar 2003, Darryl Smith wrote:
>>...and one of the recommended decoded APRS strings is $GPWPT. I would
>>like to suggest that this is removed from the recommendations on the
>>last page of chapter 6. I have **NEVER** seed this packet sent on air...
In a message dated 3/17/2003 bruninga@usna.edu replied:
>There is a very important reason for that to be in there. It is so you
>can send POSITION data to anyone with only a TNC and GPS! It lets
>a TRACKER built from just a TNC and GPS to display POSITION data
>(sent in Waypoint format) to be displayed on the GPS map. Thus, you can
>send POSIT data to Search teams or anyone using their GPS as the display.
What are the set-up commands necessary to set up a dumb tracker with just a
GPS and TNC to display position data in the form of waypoints on the GPS?
$GPWPT seems to be stripped down to just position information. What do you
tell the TNC so it will give waypoints to the GPS? Does the TNC need to be a
KPC3+ or can it be a TT3?
Thanks,
Kelly
KD7SPM
----------------------------------------------------------------------
Subject: Re: Digipeating and fun with PIDs
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Thu, 27 Mar 2003 10:29:09 -0600
X-Message-Number: 8
>As I said, terminal mode is by far the most common method used within APRS. You
>basically admit that the majority of APRS Users are at risk from this
testing...
Here is a philosophical perspective on the matter.
....and that is single biggest reason that most people have trouble setting
up their APRS software to work with brand XYZ TNC. The firmware and
revision of code in the TNC dictates whether it will work or not. I have
yet to find one that works with my DSP-12 modem since it does not
understand the converse command that all the APRS software packages
generate to control the CMD interface. The only saving grace is packages
that work with the KISS interface. With KISS there are no TNC parameters
(except in software) to cause confusion with the end user. The CMD
interface on the TNC was made popular many years ago when we only had
VT-100 terminals or PC's that ran terminal emulators to manually work the
CMD interface. It worked great for communicating with BBS systems. The CMD
mode is a legacy and still remains one of the single biggest stumbling
blocks for people setting up an APRS stations since there are so many
firmware versions and nuances to deal with.
KISS makes things so much simpler.
So why is kiss not widely used?
I think software authors can answer that question. Is it promoted.
How often are folks encouraged to use the KISS interface in software
documentation?
It seems to me that if somebody was having trouble with their setup, the
first thing I would recommend is the KISS mode on the TNC and remove that
level of frustration in the setup. The benefit is that the APRS software
will work more efficiently with the TNC. It eliminates the need for APRS
software to send silly CTRL-C's to the command interface to toggle in and
out of the Converse mode slowing down the efficiency of the setup. Many
problems are avoided using the KISS mode.
Yes, I know there are certain brands of TNC's that jump out of the KISS
mode. You always have the command interface if your TNC vendor does
not support their products and fix the firmware problem.
Something to ponder...
Tim - N8DEU
Huntsville, Alabama
----------------------------------------------------------------------
Subject: Re: [ Alex ] Re: Digipeating and fun with PIDs
From: Jeff King <jeff@aerodata.net>
Date: Thu, 27 Mar 2003 11:53:03 -0500
X-Message-Number: 9
On Thu, 27 Mar 2003 09:04:50 -0600, Gregg G. Wonderly wrote:
>Alex wrote:
>>I'm not saying that one should expect that APRS software is bug free,
>>but I think it is very reasonable to expect an application not to crash
>>simply due to unknown data.
>This is the difference between Software Engineering and Hobby Related
>Programming. There are some on this list that do engineer their software.
>There are others who are hobbiest. Recognizing this fact as the provider of
>software and the users of the software is vital. We all need to measure
>expectations,
Not withstanding, what is being discussed is the ratified APRS spec and the
inability of some organizations to conform to it (for whatever reason) which
potentially can cause problems.
I think it is a reasonable expectation that APRS applications don't break if
someone or something is following the spec (or as Alex points out, is not).
In fact, a validation suite and certification was supposed to be the result
of the APRS SPEC. I realize it never happened, but that was the intent. It is
not unreasonable to expect this compliance even in absence of WG follow
through.
ftp://ftp.tapr.org/aprssig/aprsspec/announcements/APRSWG_charter.pdf
>and manage our emotions...
People are going to make a million excuses why their software doesn't conform
to the spec and why it shouldn't have to. It is simply human nature. That is
not to disparage any of the APRS organizations/authors, it is just easier to
succinctly state this then fluff it up.
None-the-less, reality is an issue here, and that reality, as you correctly
point out, is we have some non-compliant software. Parsing the wide
disjointed mixture of APRS sentences is not an easy task so I fully
understand the issues here. I've supported Scott's effort because I feel he
is focused and what will ultimately result is a mission critical application.
Getting caught up a bunch of finger pointing and crashing non-compliant
software would distract the group from this mission, so I'd also suggest
another frequency then 144.39, at least in the initial stages.
73
Jeff
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
