| |
ZL3AI > APRDIG 01.01.04 13:12l 200 Lines 9516 Bytes #999 (0) @ WW
BID : 2582-ZL3AI
Read: GUEST
Subj: TAPR Digest, Dec 31, 1/3
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0NOS<DB0BI<DB0FBB<DB0GOS<DB0EEO<DB0RES<
ON0AR<WB0TAX<SP7MGD<ZL2TZE<ZL3VML
Sent: 040101/1043Z @:ZL3VML.#80.NZL.OC #:15803 [Chch-NZ] FBB7.00i $:2582-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Wednesday, December 31, 2003.
1. Re: APRS CWXXXX ID
2. Wx via SATCOM (KF4OTN-4/6)
3. Source Code for TNC-X available now.
4. DCD implementation on TNC-X
5. DCD implementation on TNC-X - Correction
6. fourth.aprs.net outtage
7. Re: Source Code for TNC-X available now.
8. If you climb a tower, you need to read this....
9. Subject: SmartBeaconing and corner pegging... utility?
10. Re: Subject: SmartBeaconing and corner pegging... utility?
11. Re: Subject: SmartBeaconing and corner pegging... utility?
12. Re: Subject: SmartBeaconing and corner pegging... utility?
13. Re: Subject: SmartBeaconing and corner pegging... utility?
14. Pioneer Car GPS
----------------------------------------------------------------------
Subject: Re: APRS CWXXXX ID
From: "Stephen H. Smith" <WA8LMF2@aol.com>
Date: Wed, 31 Dec 2003 00:46:36 -0800
X-Message-Number: 1
Richard Garcia wrote on 12/30/2003, 5:59 PM:
>Set up a station just for the
>Igate and another one for your normal operation, possibly using the same
>radio. Either 2 TNC's hacked to 1 radio and 2 com ports and 2 processes
>of the application or 2 PC's feeding 1 TNC and 1 radio with the
>probability of some mangled or missed packets.
Actually the AGW Packet Engine is ideal for this! Most people in the
U.S. think of AGWpe as only a soundcard software modem, but it can also
function as sort of a router or "distribution amp" to allow multiple
applications to share one or more hardware or soundcard TNCs.
You can run multiple instances of UI-View, or other apps, with each one
set to a different SSID. Each instance will connect seamlessly to AGW
which will forward data to a TNC in KISS mode. Incoming off-air packets
with a particular SSID will be forwarded to the appropriate instance or
application automatically.
I have successfully run two copies of UI-View, a copy of APRSplus and
the UI-Traffic application (which monitors channel loading on 144.39 and
periodically beacons packets-per-minute objects) all on a single KPC3+
and radio.
Stephen H. Smith wa8lmf (at) aol.com
Home Page: http://wa8lmf.com
Ham Radio/Mobile SSTV page: http://members.aol.com/wa8lmf/ham
APRS Stuff
http://members.aol.com/wa8lmf/aprs
----------------------------------------------------------------------
Subject: Wx via SATCOM (KF4OTN-4/6)
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Wed, 31 Dec 2003 10:26:28 -0500
X-Message-Number: 2
Just as a follow-up to an experiment that I was running during the "good
conditions" on PCSAT (NO-44).
The experiment was as follows:
To setup an unattended weather station to send weather data via PCSAT to the
APRS network and to determine if it was feasible. Also, I wanted to find
out whether or not there were ample I-Gates monitoring the PCSAT downlink
frequency (145.825) to get packets in on most, if not all, passes.
The Setup:
Peetbrothers Ultimeter 2000 hooked directly to a Kantronics KPC-3+ with a
Kenwood TM-261A (144MHz FM transceiver). The antenna is a copper J-Pole at
approximately 90 feet on top of a building. Operated the transceiver at 50
watts.
KF4OTN-6 was used for the experiment. A path of W3ADO-1,SGATE,WIDE2-2 was
used.
The Outcome:
It was determined that with a position tx rate of 2 minutes and a weather
data tx rate of 5 minutes, that the positions were making it in to the
network, but sometimes the weather data was not. After approximately 72
hours of having 5 minute weather tx I lowered the rate to 2 minutes. With
both packets being sent every 2 minutes, it was found that usually one
packet was seen on the APRS-IS during each pass of PCSAT.
Overall the system worked great for sending weather information to the APRS
community and to the APRS-IS. The only problem that I have is that the
passes on PCSAT are not frequent enough to get a trend of weather
information. The passes being 90 minutes or greater apart leave a lot of
dead time for the station. Also, it isn't a system that could be used all
the time with PCSAT failing at this time.
End Result:
With this knowledge in place, if a failure of the terrestrial system occurs,
we will be able to use PCSAT to keep the data flowing.
Any questions/comments should be directed to christensene@mail.ecu.edu.
----------------------------------------------------------------------
Subject: Source Code for TNC-X available now.
From: John Hansen <hansen@fredonia.edu>
Date: Wed, 31 Dec 2003 11:39:44 -0500
X-Message-Number: 3
The firmware for TNC-X (both source code and .HEX file) are now available
from the documentation link off of:
http://www.tnc-x.com
The code was written in C for the CCS PCM compiler and was developed on
MPLAB ver 6.3. The source is extensively commented and also be of interest
to those who are interested in doing things other than developing packet
equipment. For example, a separate file is included that contains
read/write routines for the Ramtron 25640 FRAM. It was intentionally
written so that it could be simply "dropped in" to other projects.
John W2FS
----------------------------------------------------------------------
Subject: DCD implementation on TNC-X
From: John Hansen <hansen@fredonia.edu>
Date: Wed, 31 Dec 2003 12:08:19 -0500
X-Message-Number: 4
A week or so ago the question was raised on this list of how DCD was
implemented on the TNC-X and what the likelihood of false triggering
was. I'm sorry not to have gotten around to responding to this sooner, but
here is how it works...
When TNC-X is not transmitting, it is listening for packet signals on the
audio input. It is designed to be operated with the radio in open squelch
mode. When no audio is presented to the MX-614 modem chip, the modem chip
sends out a string of high and low pulses. When I developed the original
PIC KISS TNC, I didn't have the equipment necessary to analyze this pulse
string in any detail, but thanks to my employer, I acquired a really good
Agilent scope. What I found is that the modem doesn't throw out random
ones and zeros but instead pulses of varying lengths. However, these
pulses are weighted toward fairly long pulses and it is reasonable to
assume that ever few 10's of milliseconds it will toss out at least one
pulse that is longer than one would ever see contained in packet data. I
use this to determine when packet audio is no longer present on the input
of the modem chip.
In terms of looking for the beginning of a packet, I made the observation
that all known TNC's currently either idle by sending zeros (0x00) or flags
(0x7E). Because amateur packet signals are encoded using the non return
to zero inverted (NRZI) technique, a 0x00 will result in a string of
alternating 0 and 5 volt signals 833 us in duration out of the modem. The
flag character will result in pulses that are 833 us and pulses that are
approx 5.83 ms long. Thus, when looking for a flag, TNC-X looks for pulses
that are either 833 us or 5.83 ms. Sometimes, the modem chip will randomly
generate pulses of this length, so it is important to look for more than
one of these in a row. However, the more of these pulses that occur in a
row, the less likely it is that they were generated randomly by the
modem. There is a trade off here... the more of these pulses that you
insist on getting in a row before deciding that the data is "real", the
less likely it is to trigger on a false signal. However, waiting for more
of these pulses in a row also causes you to need a longer TXDelay by the
transmitting station. Currently, TNC-X waits until it gets 5 of these
pulses in a row before assuming that the data is real. If the transmitting
station is idling with zeros, this is less than 1 byte long. If the
transmitting station is idling with flags this is about 2 bytes long. As
Wes noted, this produces occasional false positives (as indicated by a
brief flickering of the DCD LED), but these instances are relatively rare.
You can see how this is implemented by looking at the findflag() function
in the source code.
I suspect that if you increased the required number of these pulses to 10
or so, you would find it almost never accidentally triggered. A version of
TNC-X can be provided by me that has this characteristic if anyone desires it.
The occasional false triggering that does occur doesn't have a significant
effect on the performance of the TNC because while it is receiving data it
is also always looking for pulses that are longer than 5.83 ms. When it
finds one it knows that the modem is receiving noise and the program is
immediately kicked out of the receive loop. Thus, even if it falsely
triggers, within a small fraction of a second the TNC is back to looking
for a signal again. This can be seen in practice by noticing that the
occasional false positive is a very short flicker.
Someone asked me whether the presence of voice signals on a channel
increases the incidence of false triggering of the DCD. Since I didn't
know anything about the internal workings of the modem chip, the only way
to figure out whether this was the case or not was to test it. I did that
by putting TNC-X on a local repeater channel and found that the presence of
voices did not result in the TNC's DCD circuit triggering.
73, John W2FS
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
