| |
ZL3AI > APRDIG 26.03.07 00:34l 261 Lines 9826 Bytes #999 (0) @ WW
BID : 9932-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 33 #22, 1/2
Path: DB0FHN<DB0RGB<DB0MRW<OK0PKL<OK0PCC<OM0PBC<OK0PPL<DB0RES<ON0AR<ZL2BAU
Sent: 070325/2318Z @:ZL2BAU.#79.NZL.OC #:39513 [Waimate] $:9932-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Today's Topics:
1. RE: javaprs port that doesn't send a "keepalive" packet? (AE5PL Lists)
2. Kam Plus Control Programs? (Mr Mike)
3. problems with uiview (Wes Johnston, AI4PX)
4. Re: Kam Plus Control Programs? (Stephen H. Smith)
5. RE: javaprs port that doesn't send a "keepalive" packet? (Dave Baxter)
6. RE: Does anyone have a fix for the intermittant tone encoder on the
TH-d7ag 70cm side? (Dave Baxter)
7. RE: Does anyone have a fix for the intermittant tone encoder on the
TH-d7ag 70cm side? (Thomas t)
----------------------------------------------------------------------
Message: 1
Date: Wed, 21 Mar 2007 14:04:53 -0500
From: "AE5PL Lists" <HamLists_at_ametx.com>
Subject: RE: [aprssig] javaprs port that doesn't send a "keepalive" packet?
>-----Original Message-----
>From: Matt Werner
>Posted At: Wednesday, March 21, 2007 9:01 AM
>Subject: Re: [aprssig] javaprs port that doesn't send a "keepalive"
>packet?
>
>Perhaps being able to send the server a command (similar to a filter
>command) to change the default keep-alive for that port to something
>else (or 0 to shut it off)?
Suffice it to say that this has been investigated in detail over the past
few years and the keep-alive comment lines provide the highest level of
service for both the client (all clients) and the server. As I stated in
my first post, there are some sysops who run specific servers without
keep-alives but have other less effective safe guards in place to prevent a
single client from causing issues with particular server and client
installations.
73,
Pete Loveall AE5PL
pete at ae5pl.net
------------------------------
Message: 2
Date: Wed, 21 Mar 2007 20:43:12 -0700 (PDT)
From: Mr Mike <kf8zn_at_yahoo.com>
Subject: [aprssig] Kam Plus Control Programs?
I am trying to get Back into Packet after a 20 year hiatus...sigh... I have
a Kantronics KAM PLUS with the 8.2 Firmware, which research indicates
supports APRS???
Question: The Pacterm Program is SO DAMNED CRYPTIC in terms of the Command
Structure. Are there any Menu Driven Terminal Programs that will Access all
the Functions and be a little more user friendly??
Any Help Appreciated.
KF8ZN
------------------------------
Message: 3
Date: Wed, 21 Mar 2007 23:53:20 -0400
From: "Wes Johnston, AI4PX" <wes_at_kd4rdb.com>
Subject: [aprssig] problems with uiview
I'm trying to register a very old pmap 5 that I bought several years ago...
If I go to help->registration in pmap, it's asking for a serial number,
which I should get from http://www.registermyapp.com/index.asp. Problem
is, I can't find the "unique" number for the product code. How do I get
that? I've been in the xastir world too long and can't remember this
stuff... and pmap 5 isn't supported anymore.
Wes
--
In theory there is no difference between practice and theory.
------------------------------
Message: 4
Date: Wed, 21 Mar 2007 21:00:19 -0700
From: "Stephen H. Smith" <wa8lmf2_at_aol.com>
Subject: Re: [aprssig] Kam Plus Control Programs?
kf8zn_at_yahoo.com wrote:
>I am trying to get Back into Packet after a 20 year hiatus...sigh...
>I have a Kantronics KAM PLUS with the 8.2 Firmware, which research
>indicates supports APRS???
>
>Question: The Pacterm Program is SO DAMNED CRYPTIC in terms of the
>Command Structure. Are there any Menu Driven Terminal Programs that
>will Access all the Functions and be a little more user friendly??
>
>Any Help Appreciated.
>
>KF8ZN
The Pacterm program is completely useless for APRS (except perhaps for
setting the digipeater configuration if you choose to use it). APRS is
completely different in it's conventions, path usages, protocols, etc from
traditional connected packet. You need to use an APRS-specific application
such as UI-View, APRSplus, WinAPRS, APRSpoint, etc.
For an introduction to some of the differences between classic packet and
APRS usage (which EXCLUSIVELY uses non-connected non-acked one-to-many
broadcast-like "UI Frames") see the intro on my website:
"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths
--
Stephen H. Smith wa8lmf (at) aol.com
EchoLink Node: 14400 [Think bottom of the 2M band]
Home Page: http://wa8lmf.com --OR-- http://wa8lmf.net
NEW! World Digipeater Map
http://wa8lmf.net/APRSmaps
JavAPRS Filter Port 14580 Guide
http://wa8lmf.net/aprs/JAVaprsFilters.htm
Updated "Rev H" APRS http://wa8lmf.net/aprs
Symbols Set for UI-View,
UIpoint and APRSplus:
------------------------------
Message: 5
Date: Thu, 22 Mar 2007 14:39:07 -0000
From: "Dave Baxter" <dave_at_emv.co.uk>
Subject: RE: [aprssig] javaprs port that doesn't send a "keepalive"
packet?
I also would find it *Very* usefull to be able to at least control the
"Keep alive" messages. Every 20 or 30 seconds is way to fast, 3 to 5
minutes more like would be better, but for those of us with paid for (on a
byte by byte basis) connection, the option of removing them altogether
would be good. There is usually enough other traffic to do the job.
Give the user the option via a "Filter" text parameter perhaps? Keep the
default as it is now, but if needed, allow the user to extend the period,
or kill them altogether.
Tin hat is ready..
Dave G0WBX.
>From: AE5PL Lists [mailto:HamLists_at_ametx.com]
>Sent: Tue 20/03/2007 15:18
>To: TAPR APRS Mailing List
>Subject: RE: [aprssig] javaprs port that doesn't send a "keepalive" packet?
>
>TCP keep-alives were looked at but do not provide the granularity needed
>for APRS-IS. Also, there are a number of (not broken) clients that look
>for data from the server to be assured that the connection to the server
>is still valid.
>
>73,
>
>Pete Loveall AE5PL
>pete at ae5pl.net
------------------------------
Message: 6
Date: Thu, 22 Mar 2007 17:05:48 -0000
From: "Dave Baxter" <dave_at_emv.co.uk>
Subject: RE: [aprssig] Does anyone have a fix for the intermittant tone
encoder on the TH-d7ag 70cm side?
Hi...
The more and more I think about this, from the original description below,
initialy I'd suspect the FT-817's and the repeater's RX tone DECODER's
ability to work correctly, in the presence of other very strong LF
frequencies in the transmitted audio path. Al's (K9SI) comments imply
thinking on the same lines. But posibly a different root cause reasion.
(poor LF) removal of the mic audio in the D7, before mixing with the ctcss
tone, so any "spurious" LF will totally swamp the ctcss (that is only at a
small deviation level compared to the mic anyway) so momentarily causing
the reciving tone detector to "loose" lock.
Have you consulted with your local repeater keeper? Do any other local
users have the same problem? Do "ALL" of them use D7's? Etc, etc...
Looking at the schematic in the manual, there seems to be little LF
rejection of the mic signal, unless U509 (pre-emphasis and limiting)
handles that too. Both the TNC tones and ctcss tone is applied after that
chip. From there, it goes to the RF side, and the VCO's.
About the only places you could alter things as far as I can see, would be
C559 and C557. But, there are other parts in that area tied in to the mic
audio path and U509. Without detailed data as to how U509 does what it
does, take great care... Messing with the signal path downstreem of that
lot, could grosly affect (in a bad way) how many other aspects of the D7
behaves.
Have you tried you test, with a false mic connected? To make sure it's
not accousitc LF that is indeed causing the problem. The VCO on the UHF
side could be a bit microphonic, in that case there is I suspect next to
nothing that could be done.
As I have the time (unusually) at the moment (I'm at home recovering from
Flu) I went and found my D7, and an old Standard C510A (minature dual band
FM radio, but with all the tone and ctcss etc bell's and whistles. Nice
bit of kit.) to duplicate your experience.
Sadly, I can find nothing wrong with the D7's tone encoding (or decoding)
on UHF (or VHF) and this is a TH-D7e, but with the frequency expansion mods
done. (D7A's and AG's are US spec models. European spec will be the e
versions by the way.)
Anyway...
No matter what I do, "clapping" the front pannel, tapping it with my
fingers, with or without a dummy plug in the MIC jack, the "Other RX's"
tone decoder and squelch stays open when the D7 is transmitting, just as it
should...
The D7 is working at EL power into a dummy load, the C510 also has a dummy
load, neither radios make the other full scale in this situation, except
when placed right next to each other.
This D7 was made in Japan, in 2001 for the French market, and is a V2.0
model. It's also running on the 4 AA drycell pack, as if that would make
any difference.
I still think, what you are seeing, if you say you've seen exactly the same
on many radios, could be the behaviour of your "Test Gear", ie, the 817 in
the presence of less than optimal input. 817's have their "Features" too
I hear. (I don't own one)
One thing that is known about the D7's and UHF working, is that the RF
carrier frequency can be "off" by up to a couple of k at times. Seems to
be thermally dependant too. Some are worse than others, but as most people
don't use them for anything other than voice comms at UHF, they tend not to
notice...
If either your D7 or 817 is significantly off frequency, that could also
have an effect on this problem.
Take care, tracking down this sort of thing takes a lot of time and
planning. Remembering the ABC's of any investigation. Assume nothing,
Believe nothing, Check everything. That last bit is the killer...
I've done what I can, with what I have, and I cannot confirm the problem
with my TH-D7e at least...
Best 73 etc...
Dave G0WBX.
------------------------------
Read previous mail | Read next mail
| |
