| |
ZL3AI > APRDIG 12.02.04 13:05l 252 Lines 10335 Bytes #999 (0) @ WW
BID : 2829-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 10, 3/8
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL2TZE<ZL3VML
Sent: 040212/1039Z @:ZL3VML.#80.NZL.OC #:18932 [Chch-NZ] FBB7.00i $:2829-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: [ Frank - KG6JVE ] Re: Weather & OS Query.
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Tue, 10 Feb 2004 08:29:53 -0600
X-Message-Number: 12
>Both OS's have their advantages and disadvantages. Use what works best for
>you. OS choices are very personal. I don't want to start a flame war. A
>choice for using one or the other is fine with me.
Computer crashes these days on windows machines can usually be attributed
to a couple of things. For windows 9x and ME, it is typically that you
have a piece of hardware with a improperly written driver (win modem
drivers have been the problem for me), or you have an application that
either uses exhausts or uses too many of the "os resources". Windows 9x
has a memory layout and memory allocation scheme that does not do well in
large applications. It also has several Microsoft engineered restrictions
on number of available resources so that you'll have a reason to upgrade to
one of the bigger OSes. Graphics intensive applications can eat lots of
rendering resources and if they are not freed correctly, eventually your
application and the whole desktop will stop functioning because everyone is
waiting for more resources and there will never be any. Sometimes typing
CTRL-ALT-DEL will let you kill the offending app. Sometimes, there are no
resources left to display the dialog and you'll get a blue screen of death.
Windows NT, 2000 and XP are real operating systems that protect the OS from
user level code. So, there is litterly no way that an application bug
could crash the OS. The application bug might excite an OS or driver bug
that will crash the OS though. While there are still resource limitations
in XP home edition and less in XP pro (to get you to upgrade to
enterprise), they are far less visible.
Linux on the other hand has the ability to be reconfigured by the user to
do as much as your physical memory (and available address space, 32bit vs
64bit) can deal with. The X-windows infrastructure is more primative, but
some of that is the simplifying design that can make it more robust.
X-windows can be customized to your hearts content by switching window
managers, adding modules to window managers that support user expansion, or
writing your own window manager.
Linux has the same opportunity as Windows to be subject to driver bugs or
OS bugs. But, you are much more likely to find that your bug is fixed in
short order than to have to wrangle with continued crashes.
Linux is about choice for those that want choices...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Has any one talked to Microsoft ?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Tue, 10 Feb 2004 10:03:03 -0500
X-Message-Number: 13
>>>Jeff King <jeff@aerodata.net> 2/10/04 1:03:41 AM >>>
I truly do think APRS could be applied for more real public service...
....the new MURS radio service could be applied to a low cost AVL
network using APRS like techniques....
COMMENT: I was amazed when I got my new HT that the Marine Band now has
over 200 channels. Somehow I missed that happening. Does this mean there
is now room for APRS on a Marine Channel?
I woiuld have never considered it before in the small number of channels
available, But shucks, if there are 200+, there outta be room for one for
APRS. Problem is how could we ever get it legal....
Bob
----------------------------------------------------------------------
Subject: Re: Tweak your TXD!
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Tue, 10 Feb 2004 08:53:28 -0600
X-Message-Number: 14
>As Wes says, shortening your TXD from 300 to 100 can improve the network
>by 40%! Everyone should do this. DIGIs Too! (test, and if it works,
>shorten it)..
Keep in mind when you do this you are also testing the limits of the speed
at which the receiving parties squelch circuit functions. Setting TXD too
fast may work perfectly, but when the receiving station doees not decode it
because of their squelch response time, then you cannot measure the
effectiveness of your change and the receiving station may miss what you a
sending. You must also give your radio time to key up to full power and
become stable on frequency before sending any data. Some radio's have
trouble dealing with audio intelligence being passed while the radio is
trying to stabilize on frequency. You might recall some of the Radio Shack
equipment having an audio mute for a couple hundred milliseconds before the
voice audio is allowed to pass to the modulator.
Tim - N8DEU
Huntsville, Alabama
----------------------------------------------------------------------
Subject: Kantronics Packet Controller Chip Placement
From: Mark Kempisty <mskhbd@yahoo.com>
Date: Tue, 10 Feb 2004 10:32:37 -0500
X-Message-Number: 15
At my club's annual auction I picked up an old Kantronics Packet
Controller. (No other specific model number on it.) Unfortunately while
carrying it out, it slipped an hit the floor. All looks well except that
the ROM and RAM popped out of their sockets. The documentation that came
with it does not have a schematic so I have two chips and three sockets
(U4,5 & 6).
Can anyone tell me which socket is the ROM and which is the RAM?
Thanks in advance.
73,
Mark N3GNW
----------------------------------------------------------------------
Subject: Re: Kantronics Packet Controller Chip Placement
From: "Curt, WE7U" <archer@eskimo.com>
Date: Tue, 10 Feb 2004 08:18:24 -0800 (PST)
X-Message-Number: 16
On Tue, 10 Feb 2004, Mark Kempisty wrote:
>At my club's annual auction I picked up an old Kantronics Packet
>Controller. (No other specific model number on it.) Unfortunately while
>carrying it out, it slipped an hit the floor. All looks well except
>that the ROM and RAM popped out of their sockets. The documentation
>that came with it does not have a schematic so I have two chips and
>three sockets (U4,5 & 6).
>
>Can anyone tell me which socket is the ROM and which is the RAM?
I had to chuckle when I read that! Not laughing at you, but laughing at
things that have happened to me (and probably most of us) in the past.
The only difference with me is that I would have accidentally kicked it and
send it on multiple hops across the concrete causing even more damage to
the unit. I can recall doing that with pagers more than once.
Good luck!
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA 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: wlandb?
From: James Jefferson <jj@aprsworld.net>
Date: Tue, 10 Feb 2004 10:18:13 -0600
X-Message-Number: 17
Has anybody heard of a project called wlandb and or anything related to the
domain wlandb.com?
Besides FINDU hitting hard on my mapserver it also appears this group is
frequently requesting maps.
Thanks,
-Jim KB0THN
----------------------------------------------------------------------
Subject: Has any one talked to Microsoft ?
From: Gonzales Andy <agonzales@arc.nasa.gov>
Date: Tue, 10 Feb 2004 08:56:31 -0800
X-Message-Number: 18
E911 may have created a paying market for mapping services so why
should anyone give those services away ? Events, that HAMS may have
inspired, may have overtaken us.
--
Andy Gonzales
KG6RWO
NASA / Ames Research Center
Moffett Field, CA 94035-1000
Bldg. N-244, Rm. 240
MS 244-19
agonzales@arc.nasa.gov
650-604-0309
----------------------------------------------------------------------
Subject: Re: Tweak your TXD!
From: Jeff King <jeff@aerodata.net>
Date: Tue, 10 Feb 2004 11:57:10 -0500
X-Message-Number: 19
>>As Wes says, shortening your TXD from 300 to 100 can improve the
>>network by 40%! Everyone should do this. DIGIs Too! (test, and
>>if it works, shorten it)..
>
>
>Keep in mind when you do this you are also testing the limits of the
>speed at which the receiving parties squelch circuit functions.
>Setting TXD too fast may work perfectly, but when the receiving
>station doees not decode it because of their squelch response time,
Hold on now...... squelch time? We are looking 15+ years after a series
of circuits and articles on the wonders of open squelch operation, you mean
to tell me their are still folks that are running closed squelch on packet
radio? Naww..... you have to be kidding me, right? The only legitimate
use of squelch in packet/aprs I can see is for dumb trackers like the Tiny3
where the sole purpose is for hold off.
>then you cannot measure the effectiveness of your change and the
>receiving station may miss what you a sending.
OK, then that would be a good mechanism to turn their squelch
counter-clockwise. If you design a network for the Least Common Denominator,
then that is exactly what you end up with.
>You must also give
>your radio time to key up to full power and become stable on
>frequency before sending any data.
Good point. The TXD has to be adjusted for each individual radio. Bill Diaz
ran some tests on the kenwood "9600bps" aprs radios using standard 1200
baud. He was able to get away with a TXD of 7 (70 ms) on those. Other
radios might not work until you hit 10 12 or even 15 (150ms). Just to put
things in perspective here, almost 20 years ago, the TAPR TNC1 has a
DEFAULT TXD of 14, which equated to 140ms.
>You might recall some of the Radio Shack
>equipment having an audio mute for a couple hundred milliseconds
>before the voice audio is allowed to pass to the modulator.
Some radios shouldn't be used on packet radio. The German's in I believe
FlexNet had a interesting way of dealing with ham's who would use improper
radios like this one, their node would actually tell the ham to reduce TXD!
Myself, if a radio won't work with a TXD of 15 (150ms) or less on
packet/aprs, I don't use it on packet. It reduces the performance of my
experience as well as everyone elses on the channel.
Not every radio created is a good choice to use on packet radio.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
