| |
ZL3AI > APRDIG 09.06.04 08:31l 769 Lines 29158 Bytes #999 (0) @ WW
BID : 3414-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 03, 4/6
Path: DB0FHN<DB0FOR<DB0MRW<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<7M3TJZ<ZL2TZE<
ZL3VML
Sent: 040609/0503Z @:ZL3VML.#80.NZL.OC #:25538 [Chch-NZ] FBB7.00i $:3414-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 18:00:48 -0400
X-Message-Number: 65
On Thu, 3 Jun 2004 14:33:08 -0700, Scott Miller wrote:
>>Debate implies two opposing viewpoints. Where is the viewpoint that says you
>>should use WIDES from mobiles that have antennas that are 65,000 feet high?
>>My assumption was this was just an oversight, and will continue to
>>be my assumption. Not a big deal in the greater scheme of life, but
>>certainly something to learn from.
>Chill, Jeff. =]
Sorry, but this is a good example where math and reality really can be seen
by the naked eye.
>I just seem to remember that there was a point in
>a previous flight when a balloon wasn't getting IGated for stretches
>with no path. Or maybe that was when the tracker froze...
Tracker froze.
>I'm not
>sure. I also don't know how dense the IGates are back there.
The start point is the Detroit area. With the Jet stream, it typically takes
the balloon east, towards the east coast. I suspect quite dense
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 18:06:32 -0400
X-Message-Number: 66
On 6/3/04 at 1:53 PM Scott Miller <scott@opentrac.org> sent:
>I'm really surprised that FindU, with its rigorous treatment of APRS
>parsing, doesn't toss these packets out. If you look at my OpenTRAC decoder
>library, it's got a set of checks in every element decoder that makes sure
>things like lat/lon values are valid - if they're not, it returns a code
>indicating invalid data, as opposed to a 'parse failed' type error.
The base91 section is not as robust as the more commonly used sections of
the parser, it has not been extensively tested. I make no claims that my
parser is able to handle any sort of mangled packet sent at it. Still, even
after adding a check, some of the bogus packets would not be rejected, they
are valid APRS data in every sense of the word. Look at:
http://www.findu.com/cgi-bin/posit.cgi?call=kc8uch-11
the 10th position down parses to latitude 69.92143 longitude -100.50974
course 128 speed 8.6. This is absolutely legal, the only way to reject this
would be to compare every incoming position report with the last received
and consider it invalid if it jumped more than a certain amount. Besides
greatly increasing the load on the MySQL server (roughly 750,000 extra
searches a day, one for each position report), it still will only get the
errors above that arbitrary set point, smaller errors will still occur, and
you risk throwing out good data.
So the options at findU are:
1. remove the grossly illegal positions (I'll probably do this, though it will
make the legal errors less obvious).
2. Add quite a bit of extra load, and risk tossing good data by comparing
each posit to the last (I won't be doing this)
3. filter on the OPNTRK altnet (I won't be doing this, it violates the APRS
spec).
A better choice, and the only one which will remove all bad data from findU
and all APRS clients, is to move incompatible non-APRS traffic off the APRS
frequency!
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 15:07:52 -0700
X-Message-Number: 67
>Sorry, but this is a good example where math and reality really can be seen
>by the naked eye.
Probably true. Given that we have two profiles to work with, where should
the altitude threshold be set? I can't make anyone use suggested settings,
but we can at least make the suggestion.
Also, I see that the timestamp option is turned on. I think this is
probably a good idea if it's running on a separate channel, but for regular
APRS use it's probably adequate to go by the database timestamp.
Reliability goes up as packet size goes down... I'll leave it as an
excercise for the reader to determine the increase in probability of a bad
packet for each extra byte of payload, given a specified signal-to-noise
ratio.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 15:12:45 -0700
X-Message-Number: 68
>Opentrack is not APRS, why should it be on the APRS network? If someone were
APRS is not a keyboard-to-keyboard QSO, why is it using unproto and converse
mode?
If we only ever used things for their original intended purposes, ham radio
would be a horribly boring hobby. And APRS would never have happened.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OPNTRK packets and exciting position reports from Findu RE: [apr
ssig] Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 18:09:18 -0400
X-Message-Number: 69
On Thu, 3 Jun 2004 16:50:52 -0400, Steve Dimse wrote:
>On 6/3/04 at 3:53 PM Rochte, Robert <rrochte@gpacademy.org> sent:
>
>>Personally, I find some of these position reports based on OPNTRK
>>packets to be quite exhilarating:
>>
>>Position of KC8UCH-11
>>
>>6094008.4 miles southwest of SCOTT STATION, ANTARCTICA
>>
>>Course: 155.0 Speed: 437.3 MPH
>>
>It's your balloon, feel free if you prefer the thrills of bad data
>and don't mind the contamination of good data.
OK, now I see where Robert's "evil balloon" comment' came from. ;-) Maybe we
will see a Tetroon on the next episode of SouthPark?
Steve, I'm decoding the balloon direct, and every OpenTrak packet has a PID
of 77 on it. It should never make it to APRS-IS. BTW, NETROM and TCP/IP also
have have different PID's, and as I recall, at one time "Europe' was
corrupting APRS-IS. Same problem, how did you solve it then?
If it is corrupting FINDU, it is not the balloon's fault as it is completely
compliant with the APRS spec, in the sense you should never see it. We
operate on mixed channels, that is a fact of life, and the software should be
robust enough to deal with it.
Not to say there isn't a problem, but the problem needs to be correctly
identified, before the finger pointing starts.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 3 Jun 2004 15:16:52 -0700 (PDT)
X-Message-Number: 70
On Thu, 3 Jun 2004, Steve Dimse wrote:
>As I say, if you have another proposal, I'm listening...
Already proposed it: Track down what TNC's/software are passing
this data so that we have somewhere to start from.
--
Curt, WE7U http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: OPNTRK packets and exciting position reports from Findu RE: [apr
ssig] Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Rochte, Robert" <rrochte@gpacademy.org>
Date: Thu, 3 Jun 2004 18:13:58 -0400
X-Message-Number: 71
>It's your balloon, feel free if you prefer the thrills of
>bad data and don't mind the contamination of good data.
<snip>
>still ought to show respect for other users through
>considerate choice of path, beacon rates, and packet duplications.
Copied from www.m-w.com:
Main Entry: tongue-in-cheek
Function: adjective
: characterized by insincerity, irony, or whimsical exaggeration
(Good thing I didn't send my,
"I-don't-want-to-pay-duty-if-it-lands-in-Canada" email in response to that
airspace question...)
->My beacon rate was an accident (I make them every so often).
->My use of WIDE,WIDE at altitude was a mistake. (Interestingly, most
responses to the previous question of an appropriate path for a balloon -
this list, 18 Feb 04 - suggested using WIDE at altitude, not simply going
direct.)
->My use of an Opentracker beaconing both Opentrac and APRS packets was
intentional.
After carefully re-reading your email for the fifth time, I can only
conclude that you have confused me with someone else.
Regards,
Robert
KC8UCH
----------------------------------------------------------------------
Subject: Re: Dynamic unproto path for land use
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 15:23:10 -0700
X-Message-Number: 72
I thought about doing this. The main problem is that I'm running out of
configuration space in the OpenTracker. Let's see... a single box would
need six bytes of storage to define the corners to about 2.5 meters
resolution. That wouldn't be too bad. Multiple boxes would be more
trouble, especially dealing with dynamic storage requirements. It'd add to
the code required, and I'd have to add more user interface stuff to handle
data input for the configuration program. But it's doable.
Hmm. That'd also let you switch to a slow beacon rate and a pre-programmed
beacon message when you arrived home, for instance. I'm sure there's more
stuff you could do, especially in combination with the other parameters it
already allows.
If there's enough interest, or I get bored enough, I'll see if I can
implement it.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 18:23:24 -0400
X-Message-Number: 73
On Thu, 3 Jun 2004 15:07:52 -0700, Scott Miller wrote:
>>Sorry, but this is a good example where math and reality really can
>>be seen by the naked eye.
>
>Probably true. Given that we have two profiles to work with, where
>should the altitude threshold be set? I can't make anyone use
>suggested settings, but we can at least make the suggestion.
Common sense. A typical "relay" station is a home station, with a low home
antenna. As the balloon goes higher and higher (AGL) the "class" of station
it is, changes. Also the area it is in, or predicted to go in. In another
message I posted, I listed three examples... but you say there are two
choices?
In that case, it has to do with the "class" of station the balloon is most
likely emulating. On the ground, or at LOW AGL's, the balloon is best treated
as a "HT class" station. Meaning relay, wide, wide.
Once it exceeds the highest known wide *2 (which I think is 1000 feet AGL),
then I'd start to think about shutting the digi's off.
Now, one could make the case to ramp through the numbers (like I did
earlier), i.e.
1. relay, wide, wide
2. wide, wide
3. wide
4. <nothing>
but I really don't think the transition from case #1 to case #4 has to be
that subtle. Reason being is the balloon would spend so little time in case
#2 and #3, that it just isn't worth it.
So, going from case #1 to case #4, at 1km AGL seems like a good choice. At
1000meters AGL, your RLOS is 81 mile radius, or a circle with a diameter of
162 miles. I'd think in many cases a Igate or two would be in that circle.
But of course, local conditions need to be accounted for. East of the
Mississippi, I think(?) the highest ground height is under 5000 feet, so just
add that in as a offset.
Does a selection also exist for a sustained ground speed of 0? and/or GPS
loss of lock? That would also be a good failback for worst case. Also, a
timer that would automatically kick in relay, wide, wide after lets say the
sun goes down or a certain length of time.
I'm assuming MISSION 1 is the recovery of the payload, so any channel
bandwidth conservation steps should have a "deadman' switch on them. If not
sure, return to relay, wide, wide
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 18:25:31 -0400
X-Message-Number: 74
On 6/3/04 at 3:12 PM Scott Miller <scott@opentrac.org> sent:
>>Opentrack is not APRS, why should it be on the APRS network? If someone
>were
>
>APRS is not a keyboard-to-keyboard QSO, why is it using unproto and converse
>mode?
By definition APRS uses unproto. You might as well ask why TCP/IP uses IP.
It does, by definition. Converse is used because it is the easiest way to
send and receive unproto with a TNC.
>If we only ever used things for their original intended purposes, ham radio
>would be a horribly boring hobby. And APRS would never have happened.
Exactly. But when Bob used TNC's in a different way to develop an
unconnected network, and when I used the internet to link the local rf
networks, we weren't interfering with the fundtioning of an already
existing system, we were creating something new. It is great that you want
to create something new, but does that give you the right to interfer with
the functioning of a system used by tens of thousands of people, or to
demand that hundreds of IGate operators change their systems to be
compatible with yours?
Steve K4HG
----------------------------------------------------------------------
Subject: Re: OPNTRK packets and exciting position reports from Findu RE: [apr
ssig] Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 18:28:16 -0400
X-Message-Number: 75
On 6/3/04 at 6:13 PM Rochte, Robert <rrochte@gpacademy.org> sent:
>Copied from www.m-w.com:
>
> Main Entry: tongue-in-cheek
> Function: adjective
> :characterized by insincerity, irony, or whimsical exaggeration
I was well aware of that, I added my own comment to that, even adding a
smiley to be certain you would understand my meaning.
>->My use of an Opentracker beaconing both Opentrac and APRS packets was
>intentional.
Again, I ask in all earnestness, why? What does this gain?
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 15:30:51 -0700
X-Message-Number: 76
>Have you done any tests with the Kenwoods? From our past experiences, I bet
they
>do not handle it gracefully...
I thought they only worked with regular APRS TOCALLs. Is there anything
that's NOT a valid ALTNET? I'd be happy to change the TOCALL being used.
>What sort of sanity filter? Certainly some filtering is pretty easy, some of
>those reports parse out wildly, like a latitude of -261 degrees. However, many
>of them are real lat/lons. Do you go to a state-dependent filter, where say
No need for keeping state. It'd actually be very difficult to make an
OpenTRAC packet that didn't contain a lot of values in the range of 1 to 30
or so, which you'd never see in any valid APRS packet. If your Base91 code
is just subtracting the ASCII value for '!', yeah, you're going to have a
problem. Just scan it for non-printable ASCII, throw it out if any is found
(except for the one valid non-printable character), parse it, and throw it
out if the lat/lon is invalid.
Scott
N1VG
----------------------------------------------------------------------
Subject: APRS SSID's defaults
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 18:28:33 -0400
X-Message-Number: 77
The defaults for APRS SSID's have been updated on:
http://www.ew.usna.edu/~bruninga/aprs/SSIDs.txt
The OZ discussion about being able to quickly recognize HOW stations are
getting into APRS is something that is easily shown by SSID. So I have
added HF, APRStouch-tone and the Internet as shown below:
-6 is for Operations via Satellite
-7 is for TH-D7 HT's (legacy)
-8 is for maritime applications, boats, sailboats and ships
-9 is for Mobiles (legacy)
-10 is for stations operating on the internet only
-11 is for APRStouch-tone users (and the occasional Balloons)
-14 is for Truckers (legacy)
-15 is for HF
All others are for digis, and of course this list is only a recommendation
for a default in the absence of any other overriding situations. Notice I
am trying NOT to assign any SSID's to things that can easily be shown by
ICON.
I want to use SSID's to be a default means of showing the type of network
used to get into APRS... If 802.11 APRS networks actually start being used,
we may consider reserving -8 for that....
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: OPNTRK packets and exciting position reports from Findu RE: [apr
ssig] Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 15:34:39 -0700
X-Message-Number: 78
>I'm not. Unlike the original position report which lends itself to regex
>parsing, base 91 allows almost any character in any position other than the
>first, which makes it difficult to add validity checks. Sure, I could look
for
I don't see how you're getting valid positions. Base91 starts at what, 33
decimal? OpenTRAC elements are going to start with a length, which will be
less than 33 for most element types (including position), and all of the
basic position/altitude/course/speed elements have IDs of less than 33 that
are going to be invalid as well.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: Dynamic unproto path for land use
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Thu, 3 Jun 2004 18:38:03 -0400
X-Message-Number: 79
Yeah... If it were implemented with radio control, then you could have it
go to low power in certain areas, etc.
73s,
Eric KF4OTN
kf4otn@amsat.org
-----Original Message-----
From: Scott Miller [mailto:scott@opentrac.org]
I thought about doing this. The main problem is that I'm running out of
configuration space in the OpenTracker. Let's see... a single box would
need six bytes of storage to define the corners to about 2.5 meters
resolution. That wouldn't be too bad. Multiple boxes would be more
trouble, especially dealing with dynamic storage requirements. It'd add to
the code required, and I'd have to add more user interface stuff to handle
data input for the configuration program. But it's doable.
Hmm. That'd also let you switch to a slow beacon rate and a pre-programmed
beacon message when you arrived home, for instance. I'm sure there's more
stuff you could do, especially in combination with the other parameters it
already allows.
If there's enough interest, or I get bored enough, I'll see if I can
implement it.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 15:40:33 -0700
X-Message-Number: 80
>So, going from case #1 to case #4, at 1km AGL seems like a good choice. At
>1000meters AGL, your RLOS is 81 mile radius, or a circle with a diameter of
>162 miles. I'd think in many cases a Igate or two would be in that circle.
Sounds good to me. For a helium balloon I think I might go a bit higher,
just on the assumption that it's going to climb fast enough to not hang
around long enough to matter.
>Does a selection also exist for a sustained ground speed of 0? and/or GPS
>loss of lock? That would also be a good failback for worst case. Also, a
>timer that would automatically kick in relay, wide, wide after lets say the
>sun goes down or a certain length of time.
Sustained, no. It's an instantaneous measure, not counting the integration
interval in the GPS. But yes, you could set it to Speed < 1 kph or
something. Handling loss of GPS lock is still on my to-do list.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 18:41:53 -0400
X-Message-Number: 81
On 6/3/04 at 3:16 PM Curt, WE7U <archer@eskimo.com> sent:
>>As I say, if you have another proposal, I'm listening...
>
>Already proposed it: Track down what TNC's/software are passing
>this data so that we have somewhere to start from.
There are hundreds of IGate operators, every one of them not using KISS
would need to change, in some cases that may mean hardware costs. Every
person on RF also would need to switch to KISS. Finally, if it turns out
that the Kenwoods ignore PID (and I bet they do), you would need Kenwood to
produce an update for the D7/00, and get it installed in all users.
Until all of that is done, opentrack packets on 144.39 will be placing
bogus data on the APRS system. Not everyone using APRS wants to be cutting
edge, many, I suspect the majority, want something that just works, and
opentrack interferes with that. Backwards compatibility is important!
I really do not see why this is such an issue. Opentrack is not APRS, it is
clearly incompatible with APRS. It is great if some people want to create
something new, but can't they do that without interfering with a
successful, working system? What is wrong with setting up a network that
will not interfere with those people that just want to use APRS as it
exists now?
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Dynamic unproto path for land use
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 15:43:23 -0700
X-Message-Number: 82
I that case, you might as well design the network to provide that sort of
information. I think cellular networks do power management, though in a
more refined manner. But I can see some uses for an area-based trigger.
Hmm. Six bytes of storage, plus two flag bits, and maybe 6 or 8 lines of
code... shouldn't be too hard to do.
Scott
N1VG
----- Original Message -----
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
>Yeah... If it were implemented with radio control, then you could have it
>go to low power in certain areas, etc.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 15:50:51 -0700
X-Message-Number: 83
>Again, running OpenTRAC on such a wide-reaching platform as this wasn't a
>really good idea. But as I've mentioned before, the APRS IS is still
In Robert's defense, he did ask me about this. Looking at old emails, I see
now that I said to go ahead with the dual-protocol setting, so the blame for
any disruption that caused rests solely with me, not him. I still stand by
my assertion that properly implemented TNCs won't have a problem, and even
those that do shouldn't cause any disruption to others.
If anyone has a good technical contact at Kantronics, let me know - I'd like
to talk to them about getting this bug fixed in future firmware revisions,
if it hasn't been fixed already.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 18:47:57 -0400
X-Message-Number: 84
On Thu, 3 Jun 2004 17:08:00 -0400, Steve Dimse wrote:
>On 6/3/04 at 1:38 PM Curt, WE7U <archer@eskimo.com> sent:
>>Ban the packets instead of trying to fix the problem? How about a
>>little ham cooperation, experimentation, and problem-solving here
>>instead?
>>
>If you have another idea, I'm listening, but from what I see, this
>is having a detrimental effect on APRS today.
A detrimental effect on FINDU, or APRS?
As I mentioned earlier, the track from APRSWORLD didn't have bogus data in
it:
http://maps.aprsworld.net/datamart/track.phtml?call=KC8UCH-11&hours=72
yet FINDU does:
http://www.findu.com/cgi-bin/posit.cgi?call=kc8uch-11
>Opentrack is not APRS, why should it be on the APRS network?
I think it is 'aprs' even though the creator of it might disagree with me.
You see, I know how fixed and rigged the whole APRS spec development process
is (you see, I can read). When you find an open and honest way one can extend
the APRS spec to do the things OpenTrack can do, come back and talk to me.
Otherwise stop getting in the way of people that have brought real progress
to this aspect of the hobby.
>If someone were using the network to send DX spots with a different
>PID, would that be tolerable?
I might not like it, but the fact of the matter is, the frequencies are
shared. Ones software should not break so easily.
>As I say, if you have another proposal, I'm listening...
Honestly enforce the APRS specification instead of just using it as a sword
when it suites you? With a PID of 77, OpenTrak shouldn't be causing a
problem. I don't have alot of pity for the whining and crying now myself.
You either man up, release APRS is a house of cards, and fix it, or let the
house of cards almost collapse just like it did in 1999 when the APRS-WG
was first formed.
Better now then in a real emergency. This is the tip of the iceburg. Pay
now or pay later, it will just get worse.
First thing I would do, is find out if APRSWORLD has a more robust parser
then FINDU, and implement it. It is open source so you can do that.
----------------------------------------------------------------------
Subject: Re: Garbled status text Re: Solar tetroon Sky Diam ond 6 aloft right
now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 18:46:37 -0400
X-Message-Number: 85
>>>"Rochte, Robert" <rrochte@gpacademy.org> 6/3/04 2:02:43 PM >>>
>I have the Opentracker configured to use
>"RELAY,WIDE,WIDE" below 3k meters
>and "WIDE,WIDE" above this altitude.
Why? Above 3k feet why generate so much QRM!?
I can see nothing but disadvantages for that. If it is smart, then use that
smartness to actually cut the path to nothing when it can he heard direct
over several hundred miles...
Just an opinion..
Bob
----------------------------------------------------------------------
Subject: Re: Garbled status text Re: Solar tetroon Sky Diam ond 6 aloft right
now!
From: "Rochte, Robert" <rrochte@gpacademy.org>
Date: Thu, 3 Jun 2004 18:55:05 -0400
X-Message-Number: 86
>>and "WIDE,WIDE" above this altitude.
>
>Why? Above 3k feet why generate so much QRM!?
I knew you'd say that! =) Look back at our discussions on 18 Feb 04. Your
own suggestion for a balloon at altitude was WIDE (I remembered it wrong and
used WIDE,WIDE instead - oops!).
Here's an excerpt from a thread titled, "Excessive paths on balloons..." on
18 Feb 04:
">>> "Scott Miller" <scott@opentrac.org> 2/18/04 5:49:38 PM >>>
>It seems to me that it'd still be useful for recovery though. Since the
>OpenTracker now has the capability to drop the path above a specified
>altitude, what would you suggest for a standard setting? I think it
>defaults to 4999 meters right now.
I like the idea someone posted of just no movement. (but data still
valid and in lock). No movement for more than 30 seconds?
This will work in Denver and Florida.
WIDE while moving
RELAY,WIDE when stopped.
I dont think any further hops are needed since if the GPS was working when
it got near the ground, everyone knows what digi its near and will drive
there.
I toyed with the idea of NO DIGI while moving, but that is dangerous,
because I can imagine the last 200 feet skimming along in a valley and not
anyone hearing it direct..
de WB4APR, Bob"
----------------------------------------------------------------------
Subject: Re: Garbled status text Re: Solar tetroon Sky Diam ond 6 aloft right
now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 18:51:05 -0400
X-Message-Number: 87
>>>"Rochte, Robert" <rrochte@gpacademy.org> 6/3/04 2:02:43 PM >>>
>I have the Opentracker configured to use
>"RELAY,WIDE,WIDE" below 3k meters
>and "WIDE,WIDE" above this altitude....
But it violates the APRS protocol and no one that is running APRS in
default mode that honors altnets will see it.
You are using the UNPROTO string TO OPNTRK
KC8UCH-11>OPNTRK
Which will be ignored by all users that dont turn off their ALT-NET filters
and of course, none of the Kenwoods will see them either. This will make
finding this thing difficult...
Bob
WB4APR
----------------------------------------------------------------------
Subject: Modes and Frequencies
From: "Bill Vodall" <wa7nwp@jnos.org>
Date: Thu, 3 Jun 2004 16:04:04 -0700
X-Message-Number: 88
>I maintain that opentrack is completely incompatible with APRS, and does not
>belong on 144.39 any more than DX spots, BBSes, or RF TCPIP.
>
>Steve K4HG
144.39 is not exclusively APRS any more then the other frequencies are
exclusively non-APRS. Predominantly but certainly not exclusively. There
are times when it's reasonable to use the other modes on 144.39 just as
there are even more uses for APRS on the other frequencies. Our systems
have to be tolerant of all alien packets.
Bill - WA7NWP
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
