| |
ZL3AI > APRDIG 07.03.04 18:50l 325 Lines 12500 Bytes #999 (0) @ WW
BID : 2983-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 05, 9/9
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0BEL<EA5RQ<KP4IG<KD7HAH<WA7V<
VK7AX<ZL2BAU<ZL3VML
Sent: 040307/1048Z @:ZL3VML.#80.NZL.OC #:20539 [Chch-NZ] FBB7.00i $:2983-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: TNC-2 and MFJ-1270 performance
From: "Ernie Zingleman" <ks4q@zingleman.com>
Date: Fri, 5 Mar 2004 18:31:04 -0500
X-Message-Number: 50
Scott,
This is not an answer to your question but is pertinent. Most 1270 (B) or
(C) units need alignment. This includes the clock freq, freq of the mark
and space, and alignment of the demodulator center frequency.
This week I finally figured out how to properly set the demodulator center
frequency as I could not get the method in the MFJ manual to work. I also
am not that good at looking at determining equal time excursions of the
waveform above and below the center line on an oscilloscope.
I don't have any objective comparisons with other TNCs, but I can say this
for certain: Most people would get better performance from the TNC-2 units
if they aligned them.
If anyone is interested, I can later on post some links on how to do it.
73, Ernie KS4Q
----------------------------------------------------------------------
Subject: RE: stir up the path pot!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 05 Mar 2004 17:00:12 -0500
X-Message-Number: 51
Yes, I abandoned that first message within 10 minutes of having sent it
and after your first response where you said that it would never make it
in if it was truncated. Thats when I changed to a "marking" process (how to
mark it is yet to be determined)...
Bob
>>>Steve Dimse <k4hg@tapr.org> 3/5/04 3:32:41 PM >>>
On 3/5/04 at 3:09 PM Robert Bruninga <bruninga@usna.edu> sent:
>No, this will never work. it will only generate ill-will. It never
>works in HAM radio to try to cut someone off. That only makes
>matters much worse.
>
>All I was after was "feedback" to the users about paths.
>Not draconian measures to cut them off.
I reread all your posts, must be missing where you updated you
proposal:
On 3/4/04 at 7:35 PM Robert Bruninga <bruninga@usna.edu> sent:
>No, it will display his original packet like this:
>
>LID>APRS,WIDE7-7,RELAY7-7:Packet Truncated due to too-big-path in
>area...
As I read this, you want to take this packet
LID>APRS,WIDE7-7,RELAY7-7:=....valid position packet here....
and replace the data portion with an error message, so that the packet gets
sent to the APRS IS as
LID>APRS,WIDE7-7,RELAY7-7:Packet Truncated due to too-big-path in
area...
This is denying the use of the APRS IS to this person (as well denying the
data to other user of APRS). This will also generate ill-will, though
rather than at you it will be generated at the IGate operator and even more
at me.
If this is not your proposal then please elaborate more clearly...
Steve K4HG
----------------------------------------------------------------------
Subject: THE FEEDBACK PROPOSAL
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 05 Mar 2004 17:54:50 -0500
X-Message-Number: 52
Since there has been all kinds of confusion, here is exactly what I have
been proposing since the 3rd email on the subject:
1) Packets with excessive paths as determined by local criteria in the
vicinity of an IGate are "marked" as such as they are forwarded to the
APRS-IS. (I don't say how!)
2) FINDU displays the packets normally, but also displays a polite mark
that says something to the effect of "this path appears to be excessive
at Igate XXXXX" (but again, I leave this up to the colective wisdom).
Nothing more, nothing less. Notice I have NOT said how the packets are
marked, nor how FINDU handles them. Yes the very 1st inital email did
propose a method, but it was immediately shown to not work that way, and I
immediately abandoned that thought.
But one thing I do NOT want to see is a public list of these marks. The
mark only stays associated with the single packet, it does NOT go on a wall
of shame or any other single display. Only the display where the packet
would normally be.
Again, the GOAL is to provide user feedback on a packet per packet basis as
to evaluation of the packets path by the collective wisdom of the IGate and
digi gurus in the vicinity of the IGate that makes the determinatin.
Im late for a socut function tonight.
See ya later.
Bob
----------------------------------------------------------------------
Subject: RE: stir up the path pot!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 05 Mar 2004 17:02:36 -0500
X-Message-Number: 53
Yes, this too was abandoned almost within minutes as it became clear that
cutting people off would be a terrible idea. and removes the feedback
path.
Bob
>>>Steve Dimse <k4hg@tapr.org> 3/5/04 3:44:59 PM >>>
On 3/5/04 at 3:09 PM Robert Bruninga <bruninga@usna.edu> sent:
>Steve Reeiterates his proposal. Bob's excerpted comments:
>
>All I was after was "feedback" to the users about paths.
>Not draconian measures to cut them off.
>You are still totally missunderstanding my proposal. It has
>NOTHING to do with filtering. And it has NOTHING to do
>with users of long paths in areas where such use is acceptible!
>I would NEVER do that. It NEVER works to deny service or
>to BLOCK people. That just never works on HAM radio.
>
>I have no clue where you get these concepts.
Where do I get them? Here is the first proiposal I say from you, the one I
have been fighting so vigoursly against, which certainly seems to me to be
advocating filtering people!
====== Forwarded Message ======
Date: 3/4/04 1:46 PM
Received: 3/4/04 6:50 PM -0000
From: Robert Bruninga <bruninga@usna.edu>
To: TAPR APRS Special Interest Group <aprssig@lists.tapr.org>
>We. need. to intercept the packets on the IS and filter
>them OUT!
Hummh... interesting concept.
I always object strongly to any on-air filtering or policing, because
we just cannot tell what that person's immediate needs are
at any instant in time. Such filtering ruins the integrity of the
network if it makes arbitrary decisions like this.
BUT!!! we have to penalize the long term use of such paths
somehow if we expect them to ever learn... and change...
Eric's suggestion to Filter them from the APRS-IS is something
worth considering...
If we penalize them from getting to the APRS Global Internet
system because of long paths, then we are not "interfering"
with their immediate RF communicaitons needs, but we are
offering a penalty... That is the only way to get these people to
learn...
Would this work?
1) All IGATE clients DEFAULT to not accepting any packet
with a path length greater than WIDE2-2.
2) Local IGate SYSOP can determine based on TRAFFIC,
and local topology whether 3-3, 4-4, 5-5, or even 7-7 are
permissible in his area.
Then again, where 5-5 can be used, then it can be used.
But where it is intolerable, the IGate filters it out. It puts
the IGate sysops in control of stuff in their areas, and because
of the penalty, the end user learns why he is not getting in.
====== End Forwarded Message ======
Geez Bob, sometimes I think you need to see a neurologist ;-)
Steve K4HG
----------------------------------------------------------------------
Subject: Re: THE FEEDBACK PROPOSAL
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 5 Mar 2004 20:15:13 -0500
X-Message-Number: 54
On 3/5/04 at 5:54 PM Robert Bruninga <bruninga@usna.edu> sent:
>2) FINDU displays the packets normally, but also displays
> a polite mark that says something to the effect of
> "this path appears to be excessive at Igate XXXXX"
> (but again, I leave this up to the colective wisdom).
Under these conditions I will not provide this. This adds clutter to pages
I'm already anxious to simplify, and there is no way to refer the accused
back to the accuser for help, so the few that actually care will come to
me, which will cost me time and provide no benefit to the user, because I
cannot keep track of the requirements in hundreds of different RF networks.
Education is not part of my APRS job description...I do enough of that
teaching the young doctors at work!
Just to be clear, the most important part of my proposal is this:
---------------
My personal take on things is that almost all of these issues can and
should be handled by Elmerish contacts between local hams. My suspicion
is that many people complaining about the problem have not made any
serious attempt to contact the offenders, and are looking for others to
do the dirty work.
---------------
The real purpose behind my proposal is that by developing this protocol, it
will force local action by those people with complaints. They will either
have to do some Elmering, or shut up. Frankly either is fine with me, this
is a local issue!
The findU ban I suspect would be rarely used, and even more rarely
effective. This is to push the issue back to the local users, where it
belongs!
Steve K4HG
----------------------------------------------------------------------
Subject: Re: TNC-2 and MFJ-1270 performance
From: Mark Cheavens <mcheavens@usa.net>
Date: Fri, 05 Mar 2004 22:41:45 -0600
X-Message-Number: 55
I have done extensive testing of decode performance on MFJ-1270B and C's as
well as a wide range of PacComm TNC-2's (micropowers, Tiny-2's, TNC-200's,
etc.) as well as KPC-3's.
Testing has been done using a wide range of receivers and from being set up
properly to NOT-Properly to test decode performance. In ALL cases the TNC
was PERFECTLY aligned prior to testing.
Test results here will use an example radio that has a .25uV receiver.
(slight bacon frying when receiving voice).
I have NOT done as much testing for twist with the KPC-3 and no testing
with a KPC-3+ (which likely will not decode quite as well as the modem is
NOT designed for 1200/2200 tones)
KPC-3 will decode 100% of the packets at about .35uV
TNC-2's at about .5uV
MFJ's 2-3uV
Basically I have relegated all MFJ's to bench service only. I would NOT
even consider it for a digi doing weak signal work!
Twist:
If you use discriminator audio into the TNC you will end up with (assuming
the transmitter is working properly) 6db per octave of twist. Since 1200
and 2200 are (almost) an octave apart I will for the sake of this email say
that they should needs to be 6db of de-emphasis in the receiver before the
TNC to get the audio FLAT again.
What I have found is that all the TNC's I have tested had significant
improvement when getting the audio to within +3db of flat with a SLIGHT,
but steady improvement to about +1db of twist.
From +1db to Flat there was not much difference or NONE that I could measure.
ALL OF THE ABOVE IS ASSUMING THAT THE HIGH TONE IS GREATER THAN THE LOW
TONE, HENCE THE +db.
Continuing past flat and adding negative twist (low tone greater than the
high tone) has almost immediate DISASTROUS results!
at about -1db of twist most TNC would almost stop decoding altogether.
I therefore try to engineer in about a 5db de-emphasis network. This allows
a +/- window that I think is ideal for people that DON'T set up there tnc's
and radio's using a service monitor correctly!
So, I am torn between the FAR superior code of using a TNC-2 with UI-Digi
code and using a KPC-3 with better decode performance.
The next phase I plan on doing (once moved into my new house) is to test
the TNC-X project and a KPC-3+. IF the TNC-X performs as well as the KPC-3
then I will move in that direction. A group of us have also looked at
adding some of the filtering design from a KPC-3 and retrofitting TNC-2's.
The audio reaching the modem is MUCH different!
In an ideal world I would use a disk less computer running dos or Linux
with Digi-Ned with KPC-3 quality decoders that was FIXED in KISS mode.
Digi-Ned is in my opinion the CLOSEST thing we have right now to fixing the
ENTIRE path problem. With a FEW additions to the code and putting it in a
rock solid computer we could ACTIVELY fix ALL the digi's!
(A disk less computer that has one serial port and NO moving parts for
under $100 is what is needed).
PS for testing of decode performance I have two files on my web site. Both
are wave files that are sequentially numbered packets that I open and put
into loop mode on a computer. The audio is then used as the input into a
service monitor so that the attenuator can be used to measure the decode
performance. One file is a FLAT audio file, the other has 6db of
Pre-Emphasis. Since most older service monitors only transmit what comes in
the pre-emphasis file is what is normally used.
http://www.cheavens.com/mark/radio/packetradio/
Mark Cheavens
KC5EVE
---
END OF DIGEST
Read previous mail | Read next mail
| |
