| |
ZL3AI > APRDIG 02.04.03 10:43l 240 Lines 9961 Bytes #999 (0) @ WW
BID : 1090-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 27, 4/6
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<IK6PYS<VK7AX<ZL2BAU<ZL3VML
Sent: 030401/0904Z @:ZL3VML.#80.NZL.OC #:63028 [Chch-NZ] FBB7.00i $:1090-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Software FSK implementation
From: "Curt Mills, WE7U" <hacker@tc.fluke.com>
Date: Thu, 27 Mar 2003 13:39:10 -0800 (PST)
X-Message-Number: 18
On Thu, 27 Mar 2003, Miller Scott Contr 30SCS/FTI wrote:
>On a completely different (and hopefully non-inflammatory) topic, can
>someone point me to a good resource on implementing Bell 202 FSK encoding in
>software? I'm specifically interested in what sort of sample rate is
>required to generate a clean audio signal. I'd assume the absolute minimum
>would be 4400 hz, but I don't know how well that'd work.
Look at the "soundmodem" source code for Linux.
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: RE: Software FSK implementation
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Thu, 27 Mar 2003 21:41:52 -0000
X-Message-Number: 19
I was hoping for a microcontroller example. PCs don't have nearly the
resource limitations of MCUs. I probably should have stated this in my
request, but I'm working on a system with 192 bytes of RAM and 8k of FLASH.
Sine wave generation's not that big a deal, it just needs a lookup table,
but I'm curious about the exact requirements.
----------------------------------------------------------------------
Subject: Re: Digipeating and fun with PIDs
From: WA8LMF2@aol.com
Date: Thu, 27 Mar 2003 17:01:37 EST
X-Message-Number: 20
In a message dated 3/27/2003 8:32:10 AM Pacific Standard Time,
tim_cunningham@mindspring.com writes:
>How often are folks encouraged to use the KISS interface in software
>documentation?
>
>It seems to me that if somebody was having trouble with their setup, the
>first
>thing I would recommend is the KISS mode on the TNC and remove that
>level of frustration in the setup. The benefit is that the APRS software
>will
>work more efficiently with the TNC. It eliminates the need for APRS software
>to send silly CTRL-C's to the command interface to toggle in and out of the
>Converse mode slowing down the efficiency of the setup. Many problems are
>avoided using the KISS mode.
Rodger G4IDE, the author of UI-VIEW constantly pressures users to use KISS
mode, both in on-line postings on the UI-VIEW Yahoo group, and in the
help system and prompted first-run setup of UI-VIEW.
It's ALWAYS his first comment when someone posts a message to the effect " I
can't get my Brand xyz TNC to work with UI-View -- What do I do?"
Stephen H. Smith wa8lmf @ 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: Re: Digipeating and fun with PIDs
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 27 Mar 2003 22:09:17 +0100
X-Message-Number: 21
At 19:00 26-3-03 +0000, Miller Scott Contr 30SCS/FTI wrote:
>when seeing this? Will TNCs spit out the contents of the packets when in
>monitor mode? Henk, how about DIGI_NED?
Yes, packets are shown on the screen, with the assumption that it is uses
the normal AX.25 V2.0 protocol primitives. But DIGI_NED does not digipeat
those, it only digipeats:
0xF0 - Normal AX.25 text
0xCC - TCP/IP datagram
0xCD - ARP packet
0xCF - NETROM
Reason for not allowing others is mainly because the tricks of modifying
the header as APRS does may not be applicable and could damage the packet.
For example digipeating using the destination SSID, where the SSID is
lowered every hop, is damaging to TCP/IP datagrams because changing the
destination SSID changes the "mac-address" for TCP/IP. Since I know this,
digipeating on destination SSID only works for PIDs 0xF0 packets. Another
example is the "kenwood-mode" that truncates excessively long APRS packets,
of course that should not be done with any of the other packet types. But
since I don't know the specifics of an unknown protocol (otherwise it would
not be unknown :-) ) I just do not make any assumption about it (other than
tracing on the screen assuming AX.25 V2.0 format).
As soon as PID 0x77 is accepted I will add it. I assume I can use the same
digipeating rules as for APRS (RELAY, WIDE, TRACE, WIDEn-N, TRACEn-N,
digipeating on SSID). Otherwise I have to take care of the OpenTrac
specific exceptions.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Digipeating and fun with PIDs
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 27 Mar 2003 22:46:14 +0100
X-Message-Number: 22
At 16:27 26-3-03 -0500, Steve Dimse wrote:
>I disagree. No APRS program was ever designed to run in an environment that
>throws what amounts to random binary data at it. In fact, it was precisely
That is strange! So you say it cannot coexist on frequencies that also
transports TCP/IP datagrams, ARP packets and NETROM data? All these are UI
frames, but with a different PID. I know is a lot to say about the way
Kenwood implemented the TH-D7, but this is something so basic that even
they have done it right.
>because we could not guarantee the way other programs would react to undefined
>data that we added the user-defined type. One program could send any sort of
Of course you can! When the PID is not 0xF0 then just ignore the data,
nothing magic.
I just looked with the TH-D7 on our local access point and the only frames
it shows on the monitor are packets with PID=0xF0, is just ignores all
other packets (I know there are TCP/IP and NetRom packets on this link too,
I can only hear them but not see them on the monitor). So even with the TNC
in text mode it should not be a problem to use other packet types with a
different PID on the same QRG. Of course one can only hope other TNCs do
the same, but since NetRom and TCP/IP over AX.25 UI packets exists for more
that 10 years I would be suprised if there is any TNC that attempt to
display this binary data... These protocols were one of the drivers to
switch to KISS, in KISS this data is offered to the client and the client
shall check the received data before doing anything with it.
This also means that OpenTrac cannot use a TNC in text mode with this new
PID, but that is okay since it is a binary protocol...
Except additonal load to the QRG I can't see any problem whatsoever. All
APRS programs that use the TNC in text mode ignore non 0xF0 PIDs, since the
TNC only passed packets with PID=0xF0 to the monitor. I'm 99.999999% sure
that all implementations using AGWPE do it correctly since AGWPE definately
knows about the different PIDs. All programs that use KISS shall examine
the PID before proceeding with the data also. I don't see any reason why an
APRS client should have a problem.
Inserting the binary format on the IS is a problem, but that only starts to
happen when people *explicitly* modify software to do so. Then of course an
extra identification will be needed to discriminate between APRS and
OpenTrac (like a PID....).
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Digipeating and fun with PIDs
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 27 Mar 2003 23:06:16 +0100
X-Message-Number: 23
At 21:13 26-3-03 -0500, Alex wrote:
>develop an interface (in this case a KISS/AX.25 driver) I assume that
>the data I receive is wrong, unless I can prove it is correct and I can
>prove that it is what I need. I can not see how else one could implement
This is the one and only way this shall be done! There is no way to write
any reliable software any other way.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Digipeating and fun with PIDs
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 27 Mar 2003 23:00:31 +0100
X-Message-Number: 24
At 20:16 26-3-03 -0500, Steve Dimse wrote:
>On 3/26/03 at 9:46 PM Scott.Miller@vandenberg.af.mil (Miller Scott Contr
>30SCS/FTI) sent:
>
>>The only clients that will be trying to interpret OpenTRAC data as APRS are
>>those that totally disregard the AX.25 specification. Nothing is throwing
>>random binary data at it - the client is CHOOSING to disregard critical
>>AX.25 header information.
>>
>What AX-25 header information? If you mean the PID, that data is not passed to
>the clients in terminal mode, which is by far the most common mode in use.
Yes, it is, the only data you get to see in terminal mode is data with
PID=0xF0. You should never see other data in terminal mode. So you don't
need the PID in the header, you know it is 0xF0 since it cannot be anything
else...
>No PID information is passed to the internet system, and I have no idea
>how any
>of the programs I've written (APRServe, javAPRS, and findU) will handle it.
Without making any new software there will also never be any other packets
that those with PID=0xF0 on the IS. All clients in terminal mode will never
receivet anything else and those that use KISS and AGWPE should filter on
it already to avoid probelems with other uses of UI frames like TCP/IP and
NetRom.
>As I said, terminal mode is by far the most common method used within
>APRS. You
>basically admit that the majority of APRS Users are at risk from this
>testing...
So all these stations are safe for other PIDs already, that means that the
majority can already handle this gracefully... Not even Kenwoods have a
problem!
Kind regards,
Henk.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
