| |
ZL3AI > APRDIG 13.06.04 07:30l 825 Lines 30246 Bytes #999 (0) @ WW
BID : 3446-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 07, 2/7
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<DB0ACC<DB0EA<DB0RES<ON0AR<IK1ZNW<
ZL2TZE<ZL3VML
Sent: 040613/0512Z @:ZL3VML.#80.NZL.OC #:25747 [Chch-NZ] FBB7.00i $:3446-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: The OpenTrac Debate and BS!
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Mon, 7 Jun 2004 01:32:52 -0400
X-Message-Number: 21
Bob... If OPENtrack Protocol is easier than APRS Protocol to build software
for, then can't you infer that the software will be easier to write (for the
programmers) and thus lead to better software (for the clients) because the
programmers can concentrate more on the extras of the program and not on the
protocol itself? Maybe we will see support for new mapping software/sources
and better handling of databases and more things that we in the field NEED.
AND in an earlier email, you stated that you would be shooting yourself in
the foot by implementing both protocols in a piece of software... Why is
that? A combo program out there now would lead to most, if not all, users
having compliant software in the event we did switch over to OPENtrack (or
to whatever protocol) in the next few years. Forget all this moaning and
groaning about reverse compatibility. Yeah, if tomorrow everyone switches
over to OPENtrack we are going to be in trouble, but you and everyone else
knows that isn't going to happen. If we start to implement some of the new
code into today's software for tomorrow's technology, then most won't have a
problem with the switch or addition of the new protocol.
73s,
Eric KF4OTN
kf4otn@amsat.org
----------------------------------------------------------------------
Subject: RE: KISS mode is not always the answer !
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 22:35:25 -0700
X-Message-Number: 22
>does anyone have any other good places to find configuration info on how
>to get AX25 up and running, better yet, talking to everything (and not
I think the source you linked to is what got me up and running. Looking
over my config, I've got:
- A file called /etc/init.d/ax25 that runs on startup and contains:
kissattach /dev/ttyS0 aprs 192.168.144.39
kissparms -p aprs -t 230
(plus soundcard modem setup, a local test port, and so on, but this is the
important part.)
- An entry in my /etc/ax25/axports file to define the port:
aprs N1VG 9600 255 2 144.39 APRS
- A KPC-3 TNC on port /dev/ttyS0 at 9600 baud
I think this is the critical stuff, anyway. Once you get the port defined
and run kissattach, you should be able to run 'listen' and see traffic.
Hope that helps.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: B2V path
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 01:38:08 -0400
X-Message-Number: 23
>>>Greg Kulosa <greg@kulosa.org> 6/6/04 11:16:12 PM >>>
>If the Digi only re-transmits the object DIRECT, then
>every participant may not see it, if the area is large,
>and you can't hear that particular Digi directly.
But it is only by having the DIGI transmit it direct to all users in range
that is what is the whole advantage of this technique! If a digi has to
digipeat it though other digipeaters, then nothing has been gained. That is
what users do already!
Bob
----------------------------------------------------------------------
Subject: RE: DIGI-OBJECT-MAINTENANCE format
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 22:41:46 -0700
X-Message-Number: 24
Hmm. You're right, it sounds like your scheme would work with only digi
code changes... though I'd want to see something besides APRSdos do it right
first before I'd believe it. =] I think my generic scheme might be more
flexible, but would of course require client changes to take advantage of
it.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 01:44:11 -0400
X-Message-Number: 25
>>>gregg@skymaster.cytetech.com 6/6/04 11:59:21 PM >>>
>The obsolecence of any equipment only happens if
>people have a better choice. [whatever] OpenTrac
>does... I can still use my THD7A. My radio keeps on
>working and I can keep using it...
What do you mean by "works"? My TH-D7 shows me everything that is going on
around me on the APRS channel. If half the users are using OPENtrack
formats, then I can no longer use the radio for this purpose and it ceases
to "work" for me. ANd to date, there is NO ALTERNATIVE all-in-one APRS
device...
TO me, that means it has just been obsoleted...
Bob
----------------------------------------------------------------------
Subject: RE: The NEXT Greatest thing to APRS!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 01:56:01 -0400
X-Message-Number: 26
>>>Sean Jewett <sean@rimboy.com> 6/6/04 10:57:00 PM >>>
>Allow everyone that wants to play to register for their
>own APRStouchtone ID... like IRLP. This info would
>be kept on a central website. At a minimum a 4 digit id,
>at worst 5 digits. The idea is that we cut down on the DTMF
>that a person has to press.
Wow, you missed the whole point! Your CALLSIGN is your APRSTouchtone ID.
Just type your call on any TT pad and that is all there is to it.. WB4APR
is 924277 K4HG is 5444. Since this only has to be unique within DIRECT
range of any given APRStt server, there will rarely if every be a conflict.
If there is, the APRStt servers says "ambiguous, re-enter" and then you
have to spell it out...
But once APRStt hears 924277 or 5444 it never goes beyond that. APRStt
converts it to WB4APR or K4HG when forwarded onto the APRS network...
Store it in DTMF memory #1 and any time you want to show up on APRSjust
replay DTMF #1 and you appear on FINDU an APRS everywhere...
>Allow users to define their codes. Allow users to
>have up to say, 99 codes. These codes could be
>triggers (ie, send an email), posits, messages, etc.
>The users defines what they are going to be.
Yes, yes! Thats exactly it...
>Thus, a user can access the TT system anywhere
>it's available and use their codes. All they would
>need to do is make sure the freq is clear,
>punch in their tt-id and then their two digit code.
You got it! Now you are on track...
Bob
----------------------------------------------------------------------
Subject: RE: APRS extensibility and OPENtrack
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Mon, 7 Jun 2004 09:01:41 +0300
X-Message-Number: 27
>Sure, its a trivial change, but it must be made
>by every-single copy of APRS that is running
>in order to reliably fix the problem. Again, seems
>unfair...
>
>Bob
Even if that were true. People update software everyday in both Linux and
Windows worlds, why would it be such a big deal except for the computer
neophyte? I update UIView every time there is an update because that is
just computing today. We wont even start to talk about windows updates. The
point is its very easy these days to distribute and install updates.
Julian
----------------------------------------------------------------------
Subject: Re: New APRS Digi-Object-Maintenance format
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 02:07:18 -0400
X-Message-Number: 28
>>>"Scott Miller" <scott@3xf.com> 6/7/04 12:35:52 AM >>>
>>Scott, what do you think about this? Should the Digi transmit
>>only DIRECT, or with a path?
>
>think it should transmit with the path it was given. Just like it
>actually received the packet in real time, direct.
Scott, Im flabergasted! Your whole point of having the digi originate the
object for its users was to avoid two channel slots for every object
transmission (the input and digipeted copy) and to avoid collisions. As
soon as you let that digi now DIGI through other digis you just gave up all
the advantages of your idea and is is hardly any different from just
letting the originator continue to do it like now.
No, the only way to get the advantages you proposed is for the digi to only
take local responsibiiltiy for the packet. and not then further flood the
network. Besides the object only has value locally anyway! We have got to
stop flooding the network with useless objects beyond their range of
value...
Bob
----------------------------------------------------------------------
Subject: Re: New APRS Digi-Object-Maintenance format
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 02:09:35 -0400
X-Message-Number: 29
>>>"Scott Miller" <scott@3xf.com> 6/7/04 12:35:52 AM >>>
>So... it'd seem to me that restricting the caching to
>direct-only digis would make the most sense.
Ah, thanks! You scared me. apparently you changed your mind by the end of
that message before I got to the end. I thought you were started by saying
that the path would remain intact...
thanks
Bob
----------------------------------------------------------------------
Subject: RE: New APRS Digi-Object-Maintenance format
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Mon, 7 Jun 2004 02:07:31 -0400
X-Message-Number: 30
Would it be possible to "address" an object to a particular digi? That way
you could have full control over which digi is sending them out and thus
could specify two different digis for distribution? I feel some sort of
control would need to be put on these object's path, though. I can point
out more than a handful of improper paths in my own area that are spamming
the network. I would really hate to see more traffic from these objects
than necessary from uneducated (or non-caring "I JUST WANT TO BE SEEN")
stations.
73s,
Eric KF4OTN
kf4otn@amsat.org
----------------------------------------------------------------------
Subject: APRSdos 3D projections of Altitude
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 02:19:07 -0400
X-Message-Number: 31
>>>"Christensen, Eric"16:58 AM >>>
>>But also strange enhancements like the /A altitude flag
>>Which HUMANS can read. /A=011345 which means
>>11345 feet...
>
>So, I guess you manually take APRS positions off your
>telnet screen and plot them on a paper chart, right?
Eric, have you ever seen the 3D projections in APRSdos?
No? ALL copies of APRSdos can project in 3D. It places any object or
station with an ALTITUDE in it into a 3D projection of the view... Thus,
not only can you see WHERE everything is, but how HIGH they are too. Just
look at any copy of APRSdos on ANY map and hit the "Y" key. This toggles
the APRSdos Y Axis between 2D and 3D projections.
But for those APRS versions that have not implemented 3D views, they can
still see /A=035000 and know that the airplane is flying at 35,000 feet,
because it is HUMAN readable...
Like I say, does YOUR version of APRS show you 3D projections? APRSdos has
done this since the mid 1990's... If you are judging the capabilities of
APRS by programs that have only implemented 10% of its capabilities, then
you dont know what you are missing...
Bob
----------------------------------------------------------------------
Subject: RE: APRSdos 3D projections of Altitude
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Mon, 7 Jun 2004 03:02:48 -0400
X-Message-Number: 32
Yep, Bob, I have seen these 3D projections (very cool, BTW)... And even
though my software won't show the vertical map, it does decode that /A flag
and puts it nicely beside the velocity and course in the station information
popup. As I am not an air traffic controller, I don't need to see the 3D
projection... j/k
Seriously, though, my software author is on the ball as he should be and
added the code for this and other additions almost as fast as it made it
through the decision process as he usually does. The new standard for
software updates is now counted in weeks in the case of regular updates and
hours for adding new urgent updates. The largest segment of the APRS
community is using this software and the up-and-coming may be implementing
faster than that!
Just out of curiosity, on the 3D projections in APRSdos, can a 3D topo chart
be added so if you were flying a remote-control airplane you could possibly
avoid a large mountain or see that a hiker just wasn't up at 10,000ft in mid
air and was actually on land??? I have toyed with the notion of downloading
the latest version of APRSdos to play with it and become familiar with it
again. I'll probably do that right after I play with Xastir... ;)
73s,
Eric KF4OTN
kf4otn@amsat.org
----------------------------------------------------------------------
Subject: Re: BINARY OPENtrack on APRS
From: Curt Mills <archer@eskimo.com>
Date: Sun, 6 Jun 2004 23:25:16 -0700 (PDT)
X-Message-Number: 33
On Mon, 7 Jun 2004, Robert Bruninga wrote:
>>>>gregg@skymaster.cytetech.com 6/6/04 11:11:51 PM >>>
>>You didn't jump up and down and tell all the
>>IGATES to stop sending packets until everyone
>>of them had a fix for MIC-E decoding did you?
>
>No, because Mic-E is part of APRS, its in the spec,
>and if code was choking on it, then that code needed
>to be fixed right away...
Probably not a good time to bring up base-91 compressed
Objects/Items, which are in the spec also, right? We've been asked
not to use these on the air because Kenwoods can't display them.
Neither can some of the client software out there.
Several clients don't support Items, or don't support them fully.
Many clients don't support mixed-case Object/Item names, treating
the same names with different case as the same Object/Item.
Many clients don't support base-91 compressed-mode posits at all, even
though it's in the spec as its own chapter.
I'd love to see any code that chokes on the above items to be fixed up to
be spec-compliant!
>BINARY simply CANNOT exist without problems on
>achannel that was not designed for it... any
>programmer surely must agree with that...
If you're talking about an end-to-end serial connection, I'd agree with
you. If you're talking about a layer-2 packet connection where you have a
protocol identifier byte to be able to multiplex various things onto the
same frequency, I cannot.
This is _absolutely_ the same as the problems we had coming on the air with
KA9Q NOS back when everybody was running Commodore Vic-20's and C64's.
Every "binary" packet sent across the air would lock up someone's Commodore
computer, and they hated us. Eventually they either figured out how to
filter on PID or fixed the bugs in their code that monitoring everything on
frequency triggered. The problem went away.
Assume someone sent TCP/IP across the APRS lan (which I'm sure happens
every so often), or some other protocol with a different PID than APRS
uses. If the APRS software doesn't properly handle it, is it the fault of
the other protocol? The TNC? The APRS software?
There are a lot of protocols out there that use AX.25 for their link-level.
Do you really expect that APRS software will never encounter any of them?
On any of the frequencies somebody might tune to and operate APRS?
I say it is the fault of the APRS software for not setting the TNC
parameters properly to begin with, in order to make sure their software is
as reliable as possible. There will be times that APRS software is used on
shared frequencies along with other protocols, perhaps in emergency
conditions in an EOC. You don't want it falling over.
That's why all of the tnc-startup files for Xastir that needed it were
updated within the last few days. To make sure Xastir doesn't fall over in
those cases.
--
Curt, WE7U. archer at eskimo dot com
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: KISS mode is not always the answer !
From: Curt Mills <archer@eskimo.com>
Date: Sun, 6 Jun 2004 23:26:50 -0700 (PDT)
X-Message-Number: 34
On Sun, 6 Jun 2004, Sean Jewett wrote:
>Aside from what I've found here:
>
>http://www.febo.com/packet/linux-ax25/index.html
>
>does anyone have any other good places to find configuration info on how
>to get AX25 up and running, better yet, talking to everything (and not
>from linuxdoc)? I've found it to be quite a pain to get up and running In
>fact, when I last played with it I never had any luck getting it running.
The docs seem to be forever out of date.
Best place for info is the linux-hams mailing list, or ask somebody with a
running system for examples of their config files.
--
Curt, WE7U. archer at eskimo dot com
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: KISS mode is not always the answer !
From: Ron Perry <ronk@sunlinux.com.au>
Date: 07 Jun 2004 19:38:35 +1000
X-Message-Number: 35
On Mon, 2004-06-07 at 08:47, Curt Mills wrote:
>On Sun, 6 Jun 2004, AE5PL Lists wrote:
>
>>If you use aprsd, you could use the Linux ax25 kernel support which
>>allows multiple applications to share the same TNC running in KISS mode.
>>javAPRSIGate makes use of this so people can use much more powerful digi
>>software such as Digi_Ned. There are versions of aprsd that make use of
>>the Linux ax25 kernel support, as well.
>>
>>So yes, KISS is an option and a powerful one, at that.
>
>And aprsd handles AX.25 kernel mode interfaces now, right?
Yes. v2.2.15 does.
Ron
vk3ecv
----------------------------------------------------------------------
Subject: Re: APRS Users beware (part 1)
From: Wes Johnston <wes@johnston.net>
Date: Mon, 07 Jun 2004 07:20:31 -0400
X-Message-Number: 36
At 11:01 PM 6/6/2004, you wrote:
>1) NMEA, how many people want their GPS/TNC combos
> instantly obsolete by OPENtrack?
This one is a bad thing? >80 characters for a position? When we started
down this road, a TNC cost $110 and a GPS over $200.... now we can get a
GPS for $60 and a tiny tracker for $30... and the tiny tracker sends much
shorter packets. This leaves the "dumb tracker" TNCs to jobs for which
they are better suited like digipeater use.
Wes
----------------------------------------------------------------------
Subject: New worldwide maps available for FindU
From: "Tim Makins, EI8IC" <contesting@eircom.net>
Date: Mon, 7 Jun 2004 13:00:07 +0100
X-Message-Number: 37
I have made available a set of 6 continental and 27 sub-continental outline
maps, covering most inhabited areas, for use with findu requests. See:
http://www.findu.com/cgi-bin/line.cgi?call=w3ado-11&start=9999&length=9999&geo=t
htp://www.qsl.net/ei8ic/aprs/usa_east.geo
or
http://www.findu.com/cgi-bin/line.cgi?call=w3ado-11&start=9999&length=9999&geo=t
htp://www.mapability.com/ei8ic/aprs/usa_east.geo
for an example of a plot using the Eastern USA map.
The geo-file addresses, which link to the maps are:
Africa
http://www.qsl.net/ei8ic/aprs/africa.geo
East Africa
http://www.qsl.net/ei8ic/aprs/east_africa.geo
Southern Africa
http://www.qsl.net/ei8ic/aprs/southern_africa.geo
West Africa
http://www.qsl.net/ei8ic/aprs/west_africa.geo
Asia
http://www.qsl.net/ei8ic/aprs/asia.geo
East Asia
http://www.qsl.net/ei8ic/aprs/asia_east.geo
Middle East
http://www.qsl.net/ei8ic/aprs/middle_east.geo
Eastern Russia
http://www.qsl.net/ei8ic/aprs/russia_east.geo
Central Russia
http://www.qsl.net/ei8ic/aprs/russia_central.geo
Western Russia
http://www.qsl.net/ei8ic/aprs/russia_west.geo
South Asia
http://www.qsl.net/ei8ic/aprs/south_asia.geo
South-East Asia
http://www.qsl.net/ei8ic/aprs/south-east_asia.geo
Europe
http://www.qsl.net/ei8ic/aprs/europe.geo
Eastern Europe
http://www.qsl.net/ei8ic/aprs/eastern_europe.geo
Eastern Mediterranean
http://www.qsl.net/ei8ic/aprs/mediterranean_east.geo
Western Mediterranean
http://www.qsl.net/ei8ic/aprs/mediterranean_west.geo
Scandinavia
http://www.qsl.net/ei8ic/aprs/scandinavia.geo
Western Europe
http://www.qsl.net/ei8ic/aprs/western_europe.geo
North America
http://www.qsl.net/ei8ic/aprs/north_america.geo
Eastern Canada
http://www.qsl.net/ei8ic/aprs/canada_east.geo
Western Canada
http://www.qsl.net/ei8ic/aprs/canada_west.geo
Eastern Caribbean
http://www.qsl.net/ei8ic/aprs/caribbean_east.geo
Western Caribbean
http://www.qsl.net/ei8ic/aprs/caribbean_west.geo
Eastern USA
http://www.qsl.net/ei8ic/aprs/usa_east.geo
Western USA
http://www.qsl.net/ei8ic/aprs/usa_west.geo
South America
http://www.qsl.net/ei8ic/aprs/south_america.geo
Eastern South America
http://www.qsl.net/ei8ic/aprs/south_america_east.geo
Western South America
http://www.qsl.net/ei8ic/aprs/south_america_west.geo
Southern South America
http://www.qsl.net/ei8ic/aprs/south_america_south.geo
Oceania
http://www.qsl.net/ei8ic/aprs/oceania.geo
Eastern Oceania
http://www.qsl.net/ei8ic/aprs/oceania_east.geo
Northern Oceania
http://www.qsl.net/ei8ic/aprs/oceania_north.geo
Southern Oceania
http://www.qsl.net/ei8ic/aprs/oceania_south.geo
(Note that the addresses use the underline character, rather than a space.)
The maps are also mirrored at mapability.com eg:
http://www.mapability.com/ei8ic/aprs/africa.geo
FindU cgis that can use these maps include:
breadcrumb.cgi
This draws an image with each track point shown as a small red square, the
current position has the callsign attached.
http://www.findu.com/cgi-bin/breadcrumb.cgi?call=k4hg-8&start=10000&geo=http://w
ww.qsl.net/ei8ic/aprs/usa_east.geo
line.cgi
This draws an image with each track point shown as a small red square with
the points connected by lines.
http://www.findu.com/cgi-bin/line.cgi?call=k4hg-8!Steve:0:255:100&start=100&geot
=htp://www.qsl.net/ei8ic/aprs/usa_east.geo
plot.cgi
This draws an image with current positions shown as a small red square with
the callsign attached.
http://www.findu.com/cgi-bin/plot.cgi?call=k4hg*&geo=http://www.qsl.net/ei8ic/as
pr/usa_east.geo
track.cgi
This uses the breadcrumb or line cgi's to produce a tracked image within a
page containing current position information and a street level map. All
parameters are passed to the drawing cgi, look here for description. If the
url includes line=1, then a line is drawn between each point.
http://www.findu.com/cgi-bin/track.cgi?call=k4hg-8&start=10000&geo=http://www.q.
slnet/ei8ic/aprs/usa_east.geo
http://www.findu.com/cgi-bin/track.cgi?call=k4hg-8&start=100&line=1&geo=http://w
ww.qsl.net/ei8ic/aprs/usa_east.geo
for more details, visit http://www.findu.com/
I will be adding an explanation page to my websites shortly; for the moment,
have fun with the maps.
73s Tim EI8IC
----------------------------------------------------------------------
Subject: My summary
From: Steve Dimse <k4hg@tapr.org>
Date: Mon, 7 Jun 2004 08:17:55 -0400
X-Message-Number: 38
I think the discussion has gone on long enough, at this point no one is
going to change their minds.
I'll give my summary and drop the subject, and encourage others to do the
same.
As Scott freely admits, opentrack is being written for developers, not for
users. This represents a huge departure from the way APRS evolved. Despite
Scott's use of HTML as an example, I'd argue Tim Berners-Lee was highly
focused on the user experience, and that was what lead to his success with
HTML.
In the long term, the best opentrack has to offer is that it will make
programmer's lives easier. In the short term, any adoption of this protocol
on the APRS frequency will several issues on RF and the internet sides of
APRS.
First, the increase in RF traffic alone is an issue...as we saw on the
balloon flight, Scott's tracker has a dual protocol mode, and while his
packets are not as long as the original APRS position report, they are
longer than the Mic-E report, and since his dual-protocol mode sends the
original format, the channel load is much, much higher than needed. If many
people start using this, the load on the local RF networks will rise, and
in many areas there is little if any spare bandwidth.
Second, as has been pointed out, preventing these packets from reaching the
APRS Internet System requires every IGate oeprator update their settings.
This sort of mass reconfiguration, whether involving just settings or
hardware and/or software upgrades has been very problematic...it will
happen slowly and incompletely. Therefore, people using APRS IS will be
exposed to these packets.
Finally, as was pointed out with the HamHud incident, broadcast of
non-protocol packets carry a risk of failure in software. Yes, there is
only one failure, but that does not mean there are not other bugs out
there. Also true, this wouldn't happen in an ideal world, but APRS is in
the real world, and code has bugs which can be exposed by unexpected input.
No doubt each client author will fix any problems exposed by this, but
until the developers and users complete the upgrade cycle (which in the
real world never completely happens), the system is at risk.
No one has tried to deny the right to experiment, all I am asking that
experiments not be performed on a working system with thousands of users.
This is just common sense, no competent system administrator installs
experimental software on a production server. APRS has reached the point
where it is a production system, and should not be the test bed for
experimentation.
If opentrack will be as great as some claim, they should have no problem
proving it on another frequency, without endangering something that has a
proven, 10 year long track record of being great!
Steve K4HG
----------------------------------------------------------------------
Subject: Re: New worldwide maps available for FindU
From: Steve Dimse <k4hg@tapr.org>
Date: Mon, 7 Jun 2004 09:28:55 -0400
X-Message-Number: 39
On 6/7/04 at 1:00 PM Tim Makins, EI8IC <contesting@eircom.net> sent:
>I have made available a set of 6 continental and 27 sub-continental outline
>maps, covering most inhabited areas, for use with findu requests. See:
Very nice!
Only problem is qsl.net is slow...I put copies on my server, can I
publicize this?
http://www.findu.com/cgi-bin/plot.cgi?call=*&geo=ei8ic/caribbean_east.geo
Also, the Oceanias don't work, I fear this is my problem, I'm guessing my
geo code doesn't work on maps that span 180/-180...I'll look in detail when
I get a chance.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: APRS user beware part 2
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 07 Jun 2004 09:25:23 -0500
X-Message-Number: 40
>>>>gregg@skymaster.cytetech.com 6/6/04 11:59:21 PM >>>
>>The obsolecence of any equipment only happens if
>>people have a better choice. [whatever] OpenTrac
>>does... I can still use my THD7A. My radio keeps on
>>working and I can keep using it...
>
>What do you mean by "works"?
>My TH-D7 shows me everything that is going on
>around me on the APRS channel. If half the users
>are using OPENtrack formats, then I can no longer
>use the radio for this purpose and it ceases to "work"
>for me. ANd to date, there is NO ALTERNATIVE
>all-in-one APRS device...
>
>TO me, that means it has just been obsoleted...
Obsolete means, to me, that I can't use it. For instance, an NTSC TV will be
obsolete when I can no longer find any NTSC transmissions to listen to. But,
my ATV transmitter that transmits NTSC VSB signals will never be obsolete as
long as I have an NTSC television to watch it on! And since I have an ATV VSB
transmitter, I can always use my NTSC TVs for what they were designed to do.
So, as long as there are TNCs, and computers that will run the software that
supports APRS, I consider it a valid and non-obsolete technology.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Voice Alert on 144.390 / 100 Hz
From: "Keith - VE7GDH" <ve7gdh@rac.ca>
Date: Mon, 7 Jun 2004 07:02:16 -0700
X-Message-Number: 41
I have 144.390 MHz programmed into a few radios with 100 Hz CTCSS. I do not
transmit APRS with the sub-audible tone enabled. My understanding is that
"voice alert" is when you make a quick voice call on 144.390 MHz with the
100 Hz tone and then QSY.
I have seen several messages in the past that indicated that some people
are actually running APRS while transmitting a 100 Hz tone, and have even
heard a few packet bursts in my area that had a 100 Hz tone enabled. My
understanding is that the 100 Hz tone should NOT be transmitted with the
packet data, and that it should be reserved for making a quick voice call
to another APRS user and then QSY. Would anyone care to comment on this?
73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am."
----------------------------------------------------------------------
Subject: Re: Voice Alert on 144.390 / 100 Hz
From: Earl Needham <needhame1@plateautel.net>
Date: Mon, 07 Jun 2004 08:50:01 -0700
X-Message-Number: 42
At 07:02 AM 6/7/2004, Keith - VE7GDH wrote:
>I have 144.390 MHz programmed into a few radios with 100 Hz CTCSS. I do
>not transmit APRS with the sub-audible tone enabled. My understanding is
>that "voice alert" is when you make a quick voice call on 144.390 MHz with
>the 100 Hz tone and then QSY.
Correct, AFAIK.
>I have seen several messages in the past that indicated that some people
>are actually running APRS while transmitting a 100 Hz tone, and have even
>heard a few packet bursts in my area that had a 100 Hz tone enabled. My
>understanding is that the 100 Hz tone should NOT be transmitted with the
>packet data, and that it should be reserved for making a quick voice call
>to another APRS user and then QSY. Would anyone care to comment on this?
Actually, if you're MONITORING for Voice Alert, you would want to transmit
your packets with the 100 Hz tone. This lets other Voice Alert users know
that you're there.
The REAL problem in this is when someone sets up a DIGI with a 100 Hz
tone...DON'T DO THAT!
7 3
Earl
Earl Needham, KD5XB, Clovis, New Mexico DM84jk
SETI@Home: 11589WU/7.52yrs
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
