| |
PA2AGA > HDDIG 18.02.00 00:22l 200 Lines 7535 Bytes #-9576 (0) @ EU
BID : HD_2000_48A
Read: GUEST
Subj: HamDigitalDigest 2000/48A
Path: DB0AAB<DB0ZKA<DB0ABH<DB0SRS<DB0AIS<DB0NDK<DB0ACH<PI8JOP<PI8ZAA<PI8HWB<
PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 000217/1913Z @:PI8VNW.#ZH2.NLD.EU #:52255 [HvHolland] FBB7.00g24
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA30597 ; Thu, 17 Feb 00 17:28:49 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.70/7.5.3) with SMTP
id AA00017992 ; Thu, 17 Feb 2000 18:21:37 MET
Date: Thu, 17 Feb 00 18:18:41 MET
Message-Id: <hd_2000_48A>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 2000/48A
X-BBS-Msg-Type: B
Ham-Digital Digest Thu, 17 Feb 2000 Volume 2000 : Issue 48
Today's Topics:
a TNC made with PIC's??? (4 msgs)
Dx Telnet via Proxy server (2 msgs)
NEW HARDWARE FOR DIGITAL MODES!
PAC TERM98
Swap
TNC
Voda-Phone, was Re: What is a good TNC? (2 msgs)
What is a good TNC? (6 msgs)
Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives/ham-digital".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
Loop-Detect: Ham-Digital:2000/48
----------------------------------------------------------------------
Date: Wed, 16 Feb 2000 13:28:46 GMT
From: Laura Halliday <va3ldh@sympatico.ca>
Subject: a TNC made with PIC's???
I've been looking into this, and the big issue is that
many protocols (e.g. KISS) require that the TNC store an
entire frame and validate the checksum before passing
it on. While the smaller PICs (e.g. 16F84) do not have
enough memory to do this, the larger ones do. My next
Digi-Key order will include a 16F877 which has enough
memory to do the job, and an on-chip UART as well.
--
Laura Halliday VA3LDH "Laisse le vent tout emporter..."
Grid: FN03gs - Foly/Viennet
>.
------------------------------
Date: Wed, 16 Feb 2000 19:40:12 -0500
From: ksproul@hardees.Rutgers.EDU (Keith Sproul)
Subject: a TNC made with PIC's???
TAPR has both the PIC-E and the MIC-E that doe exactly this..
Check out:
http://www.tapr.org
Keith Sproul, WU2Z,
In article <38aa0dc6.15578277@news.mindspring.com>, tj@johnston.net (Tj
Johnston) wrote:
> Is anyone or any group currently working on a fully functional TNC
> made with PIC's? It seems these are very popular chips now.. and quite
> versatile. I would love to build my own TNC... in my own case... using
> these new chips. I am looking to do this for APRS and would love to
> build one with multiple rs-232 inputs for GPS, RDF and such...
>
> Unfortunately I am not up to speed on PIC's ... yet... and would hate
> to re-invent the wheel.. if someone else is doing this already.
>
> Tj Johnston, N4UYQ
>.
------------------------------
Date: 17 Feb 2000 00:05:56 -0600
From: tjs@garnet.tc.umn.edu (Timothy J Salo)
Subject: a TNC made with PIC's???
In article <38AAA6FC.42EFB76@sympatico.ca>,
Laura Halliday <va3ldh@sympatico.ca> wrote:
>I've been looking into this, and the big issue is that
>many protocols (e.g. KISS) require that the TNC store an
>entire frame and validate the checksum before passing
>it on. While the smaller PICs (e.g. 16F84) do not have
>enough memory to do this, the larger ones do. ...
It ought to be possible to extend KISS with something analogous to the
HDLC abort sequence. That is, the PIC would indicate after-the-fact
that the preceeding frame was bad. This could be done, for example,
by defining two trailing sequences, one to terminate a packet with a
good CRC, the other to terminate a packet with a bad CRC.
Of course, this assumes that you can extend KISS, namely that you control
the software on the host.
On the other hand, a large-memory (well, OK, a larger-memory) PIC sounds
like more fun.
-tjs
>.
------------------------------
Date: Thu, 17 Feb 2000 09:05:02 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: a TNC made with PIC's???
Timothy J Salo <tjs@garnet.tc.umn.edu> wrote:
>In article <38AAA6FC.42EFB76@sympatico.ca>,
>Laura Halliday <va3ldh@sympatico.ca> wrote:
>>I've been looking into this, and the big issue is that
>>many protocols (e.g. KISS) require that the TNC store an
>>entire frame and validate the checksum before passing
>>it on. While the smaller PICs (e.g. 16F84) do not have
>>enough memory to do this, the larger ones do. ...
>It ought to be possible to extend KISS with something analogous to the
>HDLC abort sequence. That is, the PIC would indicate after-the-fact
>that the preceeding frame was bad. This could be done, for example,
>by defining two trailing sequences, one to terminate a packet with a
>good CRC, the other to terminate a packet with a bad CRC.
>Of course, this assumes that you can extend KISS, namely that you control
>the software on the host.
Instead of inventing yet another incompatible extension, you can use one of
the many existing "KISS plus checksum" implementations, and send a wrong
checksum at the end of the packet. The host will then discard it. At
least when it understands the particular KISS extension.
However, that will not save you from having a buffer, because:
- it will only work when the effective host-tnc bitrate is higher than
the hdlc bitrate. for this to be guaranteed the RS232 baudrate
must be more than 10/8 the HDLC bitrate (because of stop/startbits).
so you can't run your modem at 9600bps and the RS232 at 9600 baud!
- to be able to transmit, the RS232 bitrate would have to be EQUAL to the
above rate, and you could still run in trouble because of bitstuffing.
it would be more safe to assume that you will have to buffer (nearly) an
entire packet on the transmit side.
- as most host programs in KISS mode do not use any flowcontrol (it is
defined that way in the spec), the only way to do flowcontrol on transmit
is to discard packets the host sends. this will cause extreme
inefficiency when you can't buffer as many packets as the host program
uses as the MAXFRAME. assuming reasonable MAXFRAME settings (for a
low-end system, which we are likely talking about) this means you need
about 2Kbytes of buffer for transmit.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.
------------------------------
Date: Wed, 16 Feb 2000 21:58:26 GMT
From: Art Santella <santella@optonline.net>
Subject: Dx Telnet via Proxy server
Is there anyone out there using DxTelnet from a client machine through
proxy server software? If so please tell me how it is done. I am
using WinGate home and cannot figure out how to get DXTELNET to telnet
through the server. Yet I can get standard windows telnet to make a
connection to the Dx packet cluster.
Art Santella (K1VKO)
"If You Ain't The Lead Dog, The Scenery Never Changes."
>.
------------------------------
Date: 16 Feb 2000 23:33:26 GMT
From: "Christopher W. Buckley" <cwbuckle@mtu.edu>
Subject: Dx Telnet via Proxy server
I'd check the porting. I know of some clusters that use port 9000 as the
To be continued in digest: hd_2000_48B
Read previous mail | Read next mail
| |
