| |
ZL3AI > APRDIG 09.06.04 08:32l 732 Lines 30959 Bytes #999 (0) @ WW
BID : 3413-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 03, 3/6
Path: DB0FHN<DB0FOR<DB0MRW<DB0SON<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<7M3TJZ<
ZL2TZE<ZL3VML
Sent: 040609/0503Z @:ZL3VML.#80.NZL.OC #:25537 [Chch-NZ] FBB7.00i $:3413-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
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 16:50:52 -0400
X-Message-Number: 47
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. Of course, you could just
program in random number generators and save the cost of the GPS ;-)
Of course, there is a separate issue here, bandwidth. This is one more
packet every minute that gets sent from a high altitude balloon, through
multiple WIDEs, and is carrying roughly the same data as the APRS packet.
While this is a cool project, and the balloon certainly deserves to use
more of the APRS bandwidth during its half day in the air than a typically
boring APRS user, you still ought to show respect for other users through
considerate choice of path, beacon rates, and packet duplications.
For each thing that consumes bandwidth, you should ask yourself what is
gained by this, is it worth the cost in bandwidth (as well as battery
life)? I can see how the RELAY at low altitudes could be justified to
maximize the chances of an accurate fix after landing. I'm less sure of the
need to beacon every minute, if nothing else I'd think battery life would
be worth cutting that to two minutes. Can you explain what you gain from
sending the opentrack packet (other than the exhilaration of bogus
reports)?
Not trying to pick on you Robert, what you are doing is cool, just trying
to understand why you make the choices you do...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 13:53:08 -0700
X-Message-Number: 48
>Ok. Who's doing that? The OpenTrac binary packets are not supposed
>to be sent through. OpenTrac packets converted to APRS packets
>aren't supposed to be sent through either now, but might be still by
>some slightly older Xastir clients.
It's converse mode doing it. I've confirmed that my old KPC-3 does it
(though I don't normally run it in that mode), not sure about TNC-2 clones.
Can someone test this on a network with non-APRS traffic and see if their
TNC spews garbage when set to converse?
>The intent for the OpenTrac packets was to go through a separate
>internet network. I believe that is still correct.
Yep.
>By keeping everything possible off the system you don't know how
>susceptible the system is to problem packets...
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.
Scott
N1VG
----------------------------------------------------------------------
Subject: Wifi and APRS again
From: "Bill Vodall" <wa7nwp@jnos.org>
Date: Thu, 3 Jun 2004 13:54:01 -0700
X-Message-Number: 49
How's this for a WiFi version of the PocketTracker?
http://www.mjleonard.pwp.blueyonder.co.uk/index.html
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 17:01:50 -0400
X-Message-Number: 50
On 6/3/04 at 1:11 PM Scott Miller <scott@opentrac.org> sent:
>>Isn't the tracker sending out both APRS and OpenTrac packets? It's
>>ok to send out APRS packets with a different destination. It's in
>>the spec.
>
>APRS packets are sent with a TOCALL of APOT01, OpenTRAC packets are sent
>with a tocall of OPNTRK. And I know you understand this Curt, but to
>reiterate, that's NOT how they are distinguished.
Good, because OPNTRK is also a valid ALTNET ID, an IGate or hub should not
filter on it.
>The protocol identifier specifically identifies the packets as having a
>defined higher level protocol, that they're NOT generic UNPROTO packets like
>APRS uses. This is true for IP, Net/ROM, Appletalk, ARP, LQP, FlexNet, and
>every other non-text protocol used on AX.25. It's how the AX.25 protocol
>was designed.
>
>The problem is people running converse mode on IGates using TNCs that don't
>pay attention to the type of packets they're receiving. I've always felt
>that converse mode is a bad idea for anything besides keyboard-to-keyboard
>QSOs using a dumb terminal. The situation is equivalent to using TCPDUMP as
>a network interface layer.
Many people only have the capability of running converse mode, for many
others it is the easiest way to get on the air. For much of the life of
APRS, this was the only mode anyone could use. While you may think it is a
bad idea, it will not be going away any time soon. You can berate the IGate
operators all you want, but the fact remains that converse mode is a
supported mode of almost every client, and opentrack is not compatible.
Until such time as everyone has switched out of converse mode, opentrack
should not be used on 144.39.
Also, have you tested on the Kenwoods? Do they honor PID?
No doubt this will reopen the old debate about do we hold people back for
backwards compatibilty. This is one of those few things Bob and I agree on,
absolutely. APRS is a working system, and we should not risk it for
experimentation. The opentrack packets are interfering with the normal
working of the APRS network, and should be moved elsewhere...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 14:07:59 -0700
X-Message-Number: 51
>If your point is that it is not AX-25 on the air, you may be right, but the
fact
>is it is getting into the APRS in large quantity from multiple IGates, and
once
>there IT IS A VALID APRS PACKET!
I think the problem here is that it probably wasn't a good idea to enable
OpenTRAC on such a long-duration, high-altitude flight without a specific
reason. The Cal Poly flight several months ago ran OpenTRAC specifically as
a test, but that was a much shorter duration flight, over an area with a
limited number of IGates, the sysops of which I have some contact with.
If I'd known Robert was planning to run in dual-protocol mode, I would have
recommended against it, at least for use on 144.39. On a positive note,
we've seen no indication that the improperly gated packets have any negative
impact on anyone's applications or data, save that of the originating
station itself. And I'd be willing to bet that the corrupted packets
generated in this case don't contribute greatly to the number seen on the
APRS IS on a daily basis - we still se a lot of garbage from stations with
noisy serial lines or bad COM ports. Perhaps a sanity check filter at the
APRS IS nodes would be a good idea?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 3 Jun 2004 14:08:59 -0700 (PDT)
X-Message-Number: 52
On Thu, 3 Jun 2004, Steve Dimse wrote:
>Who says TNC's are supposed to filter on PID? Certainly the AX-25 spec says
what>PID an AX-25 packet should have when it is transmitted, but does it say
that a
>TNC must not pass any other PID packets out the serial port? I don't have my
>copy of the AX-25 spec handy, but I'd be surprised if it said that...correct me
>if I'm wrong.
I'd have to go check the spec myself. I'm sure we have one or two
spec-experts on this SIG though.
>But you also run the risk of crashing key assets at critical times. If you did
>this deliberately at times wwhen you knew no one in the APRS world was facing
>critical situations, then I'd say OK, but to do it randomly and hope the crash
>will not occur at a critical time and place sounds a bit like Russian Roulette
>(allbeit with a lot more than 5 empty chambers).
I'm just saying that small breaks at random intervals which are
fixed on-the-spot or nearly so are better than keeping our eyes/ears
closed and hoping nothing really breaks later on.
The old gopher hole in the irrigation ditch thing, which I have some
long hours of direct experience with. ;-)
--
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: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 17:08:00 -0400
X-Message-Number: 53
On 6/3/04 at 1:38 PM Curt, WE7U <archer@eskimo.com> sent:
>>Apparently large numbers do not, and we now have documentation of the problem
>I
>>hypothesized when I begged you to keep this off the APRS channel. Are you
>going
>>to blame all the TNC manufacturers and IGate operators and continue to place
>the
>>APRS network at risk, or are you going to take your protocol off the APRS
>>frequency?
>
>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. Once the packets leave the
serial port of the TNC there is no way to identify them, and clearly there
are a large number of TNCs running in converse mode (if this even is the
only cause of the problem). If they are picked up by the kenwoods, the
situation is even less tolerable.
Opentrack is not APRS, why should it be on the APRS network? If someone
were using the network to send DX spots with a different PID, would that be
tolerable?
As I say, if you have another proposal, I'm listening...
Steve K4HG
----------------------------------------------------------------------
Subject: Dynamic unproto path for land use
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Thu, 3 Jun 2004 17:20:15 -0400
X-Message-Number: 54
>From the excellent balloon KC8UCH-11 that is aloft right now, I got an idea.
If I could tell my tracker to change my path based on areas I was in...
That would be great. I would just make a box and say within this box make
my path WIDE, outside this box goto RELAY,WIDE and have provisions for
multiple boxes... Any ideas on this???
73s,
Eric KF4OTN
kf4otn@amsat.org
kf4otn@w4ral.#rtp.nc.usa.noam
ARRL Member
AMSAT Member: 35360
TAPR Member: 8869
Support your Hobby! Join a club.
All contact logs are uploaded to the ARRL LoTW and eQSL.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 17:19:13 -0400
X-Message-Number: 55
On Thu, 3 Jun 2004 13:04:34 -0700, Scott Miller wrote:
>It was apparently configured to use RELAY,WIDE,WIDE under 3000
>meters. The debate now is what path should be used at altitude.
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.
>Direct should do it in most cases, but I can see where a single WIDE
>might be needed to get to an IGate.
On Mars maybe? Currently, we are looking at a RF circle with almost a 700
mile diameter, that spans from Washington DC, to Toronto to the outskirts of
Chicago. Touching the states of Michigan, Ohio, Illinois, Indiana, New
Jersey, Delaware, Kentucky, Virginia, Tennessee, North Carolina,
Pennsylvania, West Virginia, New York and the majority of the populated
portion of Ontario.
One would think there might be an igate or two, in the above area, which
encompasses a land mass, across two countries, and 14 states, of over 341,000
sq miles.
But lets do the math for the typical "wide" (if there is such a thing).
First, lets look at the radio line of site (RLOS) of the mobile. Note, this
is to an antenna on the ground. Take a look at:
http://www.vwlowen.demon.co.uk/java/horizon.htm
For our mobile with its antenna 65,000 feet above the ground, we get a RLOS
of 361 miles. The typical home station, with a antenna at 35 feet, can hear
that mobile from a distance of 369 miles. So a home WIDE buys you 9 more
miles.
But lets look at a wide that is at 75 feet AGL. That will take you from 361
miles range, to 373 miles. Got ya 12 there.
And the mega wide, 1000 foot TV tower. That one gained you a range of 45
miles (from 361 to 406). So that 1000 foot tower, right on the very tip of
Maine, would let your balloon go 45 miles (in theory) out to sea.
Of course, the benefit of WIDES from 10K+ altitudes, no matter how far
fetched, are only of benefit right on the very edge of the range circle. To
the 300,000 other square miles, they activate each and every single wide, for
no benefit at all. 200,000+ additional transmissions cluttering the channel
for the duration of the mission. (~400 wides in coverage area, *60 times a
hour, * 10 hours. Remember, no dupes at all on the first reception, that
doesn't even include the second hop.
What was being debated here?
-Jeff
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 17:22:34 -0400
X-Message-Number: 56
On 6/3/04 at 2:07 PM Scott Miller <scott@opentrac.org> sent:
>>If your point is that it is not AX-25 on the air, you may be right, but the
>fact
>>is it is getting into the APRS in large quantity from multiple IGates, and
>once
>>there IT IS A VALID APRS PACKET!
>
>I think the problem here is that it probably wasn't a good idea to enable
>OpenTRAC on such a long-duration, high-altitude flight without a specific
>reason. The Cal Poly flight several months ago ran OpenTRAC specifically as
>a test, but that was a much shorter duration flight, over an area with a
>limited number of IGates, the sysops of which I have some contact with.
This sort of experimentation is not so bad, but still, the fact that every
sysop must be included in the test points out how incompatible your
protocol is with APRS.
Have you done any tests with the Kenwoods? From our past experiences, I bet
they do not handle it gracefully...
>If I'd known Robert was planning to run in dual-protocol mode, I would have
>recommended against it, at least for use on 144.39. On a positive note,
>we've seen no indication that the improperly gated packets have any negative
>impact on anyone's applications or data, save that of the originating
>station itself.
No, but that is important data to be corrupted!
>And I'd be willing to bet that the corrupted packets
>generated in this case don't contribute greatly to the number seen on the
>APRS IS on a daily basis - we still se a lot of garbage from stations with
>noisy serial lines or bad COM ports.
The issue is not bandwidth on the APRS IS, but rather just bad data...it is
wrong to deliberately put something onto the RF network that you know will
be mis-interpreted.
>Perhaps a sanity check filter at the
>APRS IS nodes would be a good idea?
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 anything > 1 degree off the last report is trashed? What
about those packets with smaller errors, they will still contaminate the
data, this just sweeps the problem under the rug. It also does nothing for
people hearing the station on RF, who will still get the full blast of bad
data.
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
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 14:28:27 -0700
X-Message-Number: 57
>Who says TNC's are supposed to filter on PID? Certainly the AX-25 spec says
what
>PID an AX-25 packet should have when it is transmitted, but does it say
that a
>TNC must not pass any other PID packets out the serial port? I don't have
my
>copy of the AX-25 spec handy, but I'd be surprised if it said
that...correct me
>if I'm wrong.
An AX.25 packet can be transmitted with any PID. The TNCs shouldn't do any
filtering on the packets, and they don't. But converse mode is NOT a method
to get AX.25 packets to the host. It's a method to CONVERSE with someone
using text / unproto packets. There is no valid reason a sane TNC should
print out the contents of a packet it knows isn't a human-readable text
packet in a human interface mode.
As an analogy, consider this serial terminal server device I've got plugged
into a high-speed printer. It knows that anything it receives over a
certain port is text that needs to be printed. There's a bunch of other
stuff going on at the same time, connection setup and tear-down, for
example, and it handles that. TNCs do that to, and might display
informative text about what's going on. But to display any random packet
that comes in would be like this device sending DNS queries or web traffic
to the printer. It's not how it's defined in the protocol, it's not
rational behavior on the part of the device, and there's no reason it should
ever be implemented that way.
>But you also run the risk of crashing key assets at critical times. If you did
>this deliberately at times wwhen you knew no one in the APRS world was facing
>critical situations, then I'd say OK, but to do it randomly and hope the crash
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
subject to a constant barrage of garbage anyway, thanks to noisy serial
lines and no error detection in KISS. But somehow, life goes on.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 14:33:08 -0700
X-Message-Number: 58
>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. =] 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... I'm not sure. I also
don't know how dense the IGates are back there.
If it can get to one reliably direct, then it should by all means do so.
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: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 17:32:08 -0400
X-Message-Number: 59
On 6/3/04 at 1:21 PM Scott Miller <scott@opentrac.org> sent:
>Looks like someone needs to add some sanity checking. It's awfully tough to
>get SOUTH of Scott Station. =] And 6,000,000 miles puts it several times
>the moon's distance from Earth...
Yes, some of them are impossible, but many correspond to real points on the
earth. I'm torn right now on adding checking...on the one hand impossible
ones should probably go into the error bin, but on the other hand, they
really help point out the less obvious errors. Personally, I rather see
errors of 6M miles than 60 miles, the former is easy for the wet computer
to ignore ;-)
>I'm surprised it's getting parsed at all.
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 -90<lat<90 and -180<lon<180 (and probably will), but many of the
positions fall on the earth, and paser completely valid.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 17:39:09 -0400
X-Message-Number: 60
On 6/3/04 at 4:40 PM Jeff King <jeff@aerodata.net> sent:
>http://www.findu.com/cgi-bin/posit.cgi?call=kc8uch-11
>
>I'm seeing the errors you speak of above in FINDU. Yet in APRSWORLD:
>
>http://maps.aprsworld.net/datamart/track.phtml?call=KC8UCH-11&hours=72
>
>I'm seeing what looks like solid data. Why do you think that is?
Jim will have to give the definitive answer as to how he is filtering them
out, my guess he is filtering on the OPNTRK ALTNET. However, as Scott
points out, this is a completely legal ALTNET address, and the
infrastructure is not supposed to filter based on ALTNETs, it is up to the
clients to do so.
Again, the issue here is not findU, if all I was concerned about is
cleaning up findU's data, I could perform that filtering. However the
problem goes much deeper...many clients do not filter ALTNETS and will see
the bad data just as findU does. I'm also deeply concerned that these
packets may cause some crashes in clients and/or Kenwoods.
The bottom line is this data is not APRS, and in my opinion does not belong
on the APRS frequency.
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: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 14:40:35 -0700
X-Message-Number: 61
>Of course, there is a separate issue here, bandwidth. This is one more packet
>every minute that gets sent from a high altitude balloon, through multiple
>WIDEs, and is carrying roughly the same data as the APRS packet. While this
is a
To be fair, it's probably more like 1/2 the number of bytes. Altitude alone
adds 9 bytes to an APRS packet, while it only adds 3 to an OpenTRAC packet,
yet the OpenTRAC packet provides a much greater range and resolution
(-10,000 to 157,772 meters in centimeter increments, if memory serves.)
Plus, there's no added TXD overhead. The packets are sent back-to-back, so
channel utilization (and transmit duration) is increased by maybe 40 or 50
msec.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: Paths again was Re: Garbled status text Re: Sola
r tetroon Sky Diamond 6 aloft right now!
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Thu, 3 Jun 2004 17:47:17 -0400
X-Message-Number: 62
I would have to say on the surface there really isn't a good way to collect
ALL the data coming from the bird because of duplicate suppression on the IS
side which is where you would need to go to get a collection of real-time
data. You could use that program UI-Traffic to get before, during, and
after data on the network. That program shows actual network load. But I
don't know how popular it is anymore.
Eric KF4OTN
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 17:50:00 -0400
X-Message-Number: 63
On 6/3/04 at 4:44 PM Christensen, Eric <CHRISTENSENE@MAIL.ECU.EDU> sent:
>Well, I think it is really neat to see that the technology exists to change
>the unproto path... If we can get all the data from this flight and graph
>the number of hops it had to take to get into an I-Gate v. the altitude,
>then we might have some very useful data to work with to answer this
>question.
This is a matter of the APRS Internet System being the wrong tool for the
job. The design of the APRS IS was based on getting data distributed
widely, not about characterizing the RF network. Therefore, the system is
designed at each stage to filter out duplicate versions of the same data
packet. However, it is precisely the differences between different
instances of the same packet that would allow you to draw interesting
and/or definitive conclusions about the RF network and propagation.
In this specific case, it is very hard to draw a specific conclusion based
on hop count. For example, I suspect the balloon is running without DCD
(otherwise it would never heard a clear channel to transmit). This means
IGates and digis in heavily populated areas are more likely to experience a
collision with a packet. Also, since findU and APRSworld dupe check, it is
only the first arrining packet that will be saved. While often this will be
the most direct, the configuration of the APRS IS may actually get a digied
packet to findU before a direct one, it depends on who is connected to who
and what kind of latency there is on each connection.
It is like the popularity poll a couple months ago. It is easy to get an
answer, but much harder to get an answer you can rely upon...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Paths again was Re: Garbled status text Re: Sola r
tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 17:48:50 -0400
X-Message-Number: 64
On Thu, 3 Jun 2004 16:18:56 -0400, Rochte, Robert wrote:
>>
>>So assuming it keeps going east, you'll loose touch with Chicago
>>and only saturate the network (wides) from Grand Rapids MI to New
>>York city at altitude.
>Each time I have flown a long-distance solar Montgolfier, the issue
>of "saturating the network" has come up.
That is why I asked Scott if OpenTrac had a means to enable "triggers" so
that the path could be changed as the balloon gained altitude. I assumed
this was an oversight or he hadn't put it in yet.
>The last time it seemed as
>though the argument centered around the use of RELAY in the path
>(yes, I did that!) - so this time the RELAY has been removed above
>3km.
I don't know about the last conversation, but as I understand it, "RELAY's"
typically are low level home stations. Every APRS station is supposed to
have this enabled. That is so someone in a rut, so to speak, can get a digi
out to the closest wide.
A good use for relay, wide, wide is a balloon on the ground or caught in a
tree.
If your looking for suggestions, I'd make the following:
ground = relay, wide, wide
50m AGL to 300m fAGL, WIDE, WIDE (as 50meter antenna takes you above a
typical "relay' station)
300M AGL to 1KM AGL, WIDE (as most wides are less then 3000 feet tall!!)
>1KM AGL direct only (at 1KM you have a RLOS of 81 miles)
Of course, you'd have to offset things for your highest terrain you expect to
encounter. Also, a sustained speed of zero might want to trigger the relay,
wide, wide.
>Out of curiosity (and because I personally haven't a clue), I ask
>the same question that I posed after my last flight:
>
>Apart from sheer speculation and textbook-style calculations of the
>network being inundated by packets from my evil balloon,
To be crystal clear. Every person, including myself, that has commented on
this, has been very careful not to be critical. You actually got me
interested in APRS by doing this. So no need to call the balloon evil. My
kids where quite excited about them in fact. We have watched it all day. My
orginial question was a suggestion to Scott to improve his software.
>That is, I understand (I think) most of the arguments about why this
>is a potential problem - but is the reality anywhere close to the
>prediction?
Does somebody in Washington DC, Detroit, Toronto, Cinncinati, ect need to
similtanous get on echolink and prove that an antenna at 65,000 feet has
coverage of all these areas? The balloon is about 200 miles from me now, and
is the second strongest signal I am hearing. Amazing for 500 milliwatts, you
don't need much for line of sight.
>Backing up a bit from that question, is it even
>*possible* to analyze the impact of my balloon's packets on the
>overall network (perhaps on a regional basis) in real-time or
>otherwise?
See my other post (i'll forward to you). I did swag on the number of WIDE's
in the coverage area, but tried to estimate lower.
>If there is no quantitative way of doing this, then can it at least
>be approached from a qualitative standpoint - is anyone seeing
>apparent degradation of the APRS network as a result of these
>packets? Not just "yes, a lot more packets are on the network"
>- but actual degradation of service?
I'm not sure that is the question to ask. The real question to ask, is there
a benefit from having your packets simultaneous duplicated by 400+ wide
digipeaters? If there is no benefit, then IMHO, one shouldn't do it.
What does WIDE, WIDE from 65,000 feet gain one? When in doubt, err on the
side of caution.
>The last time I asked this question there were no replies - zip,
>zero, nada (at least that made it into my mailbox). Having now
>gotten rid of the RELAY problem (thanks Scott!), I didn't expect to
>ever pose the question again... But now it seems that even a single
>WIDE is considered questionable. Anyone, anyone?? =)
Your station has a RF coverage radius in excess of 350 miles. What exact
benefit is a wide to a station with that kind of coverage?
In any case, I wouldn't take any of this personal. I'd just determine what
your mission is, and take the minimum steps needed to complete that mission.
BTW, going a step further, something like the "pocket tracker' would be even
better then OpenTrac. Why? Because at altitude, pocket tracker could QSY to
lets say 144.34, and only rejoin 144.39 at lower altitudes. The best of both
worlds, per say. The excellent coverage of 144.39, only when needed (during
low level and recovery) and the flexibility of 144.34 to beacon to your
hearts content.
73
Jeff
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
