World of Ham Radio 1994 January/AMSOFT_1994.iso/packet/docs/pd199010.doc

Text File | 1993-12-31 | 195.9 KB | 4,921 lines

Tue,  2 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #158
To: packet-radio


Packet-Radio Digest         Tue,  2 Oct 90       Volume 90 : Issue 158

Today's Topics:
    9600/1200 bps dual-speed full duplex repeater hassles (2 msgs)
              TNCs and DataRadio

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: Mon, 1 Oct 90 11:02:59 PDT
From: [e-mail] (Brian Kantor)
Subject: 9600/1200 bps dual-speed full duplex repeater hassles
To: [e-mail]

I'm in the process of building a full-duplex digital repeater to serve
packet user in my area, and I've been experimenting with some stuff I
thought might be of interest to others.

Initially, I hacked up a TNC-2 to act as the repeater's FSK regenerator.
That's an easy job: for regular vanilla AFSK 1200 bps you just:

- add a diode and capacitor to the gate circuit of the VN10KM PTT switch
to give it a delayed drop out time of about 10 to 12 seconds - you want
it long enough that the repeater stays keyed up between retries.

- add in two diodes so that the FSK chip unsquelches and the PTT is keyed
whenever either the SIO chip asserts RTS (i.e., the TNC firmware wants
to say something packetish) or when the XR2211 detects carrier (someone
blew a packet at the box).

- add a data selector (I use a 7400) so that the FSK modulator is driven
from the FSK demodulator unless the SIO chip asserts RTS.  That repeats
data but lets the firmware override for IDs and such.  (Since the TNC
is NOT in full-duplex mode, it will hold off whilst repeating a signal
since it thinks the channel is busy.)

This trick works fine with regular TNC firmware, Net/Rum, or KISS mode
stuff.

However, I'm trying to add a K9NG modem to make it ALSO do 9600 bps,
and WB6HHV and I found out a few things whilst experimenting this
weekend:

2-meter Motorola MICORs don't like to do FSK.  I suspect I'm going to
have to swap out the standard transmitter channel element with one of
the ones intended for 450 MHz use and modulate the thing through the
AFC circuit in order to get direct FM.

2-meter Motorola MAXARs do really nice FM.  It appears the modulator is
linear to well beyond +/-8kHz dev, and to well above 10kHz audio if you
go into the PL input.

Both MICORs and MAXARs seem to have a receiver modulation acceptance of
around +/- 7kHz before a 1 kHz sine wave distorts measureably, and the
K9NG stuff set to 3kHz seems to be received just fine.

By cutting the trace on the K9NG's FET analog switch that normally
drives the FSK output with 1/2 clock during receive, and routing the
output of the receive data slicer there, you make the K9NG act as an
FSK regenerator when it's in receive mode, and act normally in transmit
mode.  That causes it to act just as the 1200 bps stuff described above
acts.

The K9NG modem data slicer seems to be able to separate out 1200 bps
AFSK - with the FSK regen modification described above, it seems to
repeat 1200 bps packet just fine.  I suspect it isn't as good as the
1200 bps AFSK regen described above, since it will not regenerate the
tones themselves, but it is good enough that 1200 bps gets through the
repeater without hassle.  But then, it's not hard to arrange an audio
switch to mute the K9NG modem's output when the 1200 bps DCD sees a
real carrier - the 1200 bps modem (XR2211 with TAPR DCD mod) does NOT
see 9600 as 1200 bps carrier.

I suspect that ANY FSK or FM-AFSK signal would go through this, which
really makes the repeater pretty useful.  Since the primary usage of
the repeater is supposed to be 9600 bps with 1200 bps as a secondary
accomodation, maybe that's the right answer.  And it keeps the old
farts from trying to talk on it.

So, what's the problem?

The K9NG modem has a truely dreadful carrier detect circuit.  It works
as follows: there is a bit in the standard TAPR state machine digital
PLL prom that isn't used in calculating the next state; it's D7 (pin
19) on the prom.  It's normally high whenever the PLL is locked, but
pulses low whenever there is an error term in the PLL.  Thus it will
sit high on good carrier, and sputter low on random noise.  By using it
to dump the charge on a capacitor, and inverting that, you can get an
output that will go low when the PLL error bit stays high, as it will
when good data carrier is being received.  However, it will also give
you no error (and therefore, asserts carrier detect) when there is dead
silence on the channel - like during the repeater's hang time.  That
means that the repeater has to generate white noise during the entire
delayed drop-out time, or else EVERYONE has to modify their K9NG modem
to ignore dead carriers - a non-trivial task.  (You can do that by
adding circuitry to look for the data slicer toggling, which it won't
do on a dead carrier, and ANDing that with the state machine output.)

Well, if we want people to be able to use 9600 bps, we have to either
have no hang time or blow white noise during the hang time.  But if we
do the latter, the typical 1200 bps user's TNC will see the white noise
as data carrier (since most of them are really energy-detect circuits,
not data carrier detectors), and they'll hold off.  It's essentially the
same as blowing the squelch on the user's receiver.

Having no hang time at all is a bad idea - the transmitter can't get on
the air fast enough to allow the really short TXD times that you can
use if the carrier is already up, so that will degrade performance for
all users.  (We've successfully run with TXD set to 2 [20ms], which is
1/10th the delay used on simplex around here.)

I don't mind degrading performance for 1200 bps users a little bit if I
have to, so I've considered blowing white noise for like two seconds
after any input signal goes away - the K9NG modems would see that as an
available time slot, so a 9600 bps user would be able to transmit
immediately.  People with good DCD 1200 bps systems would also be able
to transmit immediately, but people with typical cruddy 1200 bps DCD
circuits would have to wait for the blowing to stop.  Perhaps the two
second delay isn't that bad.  Maybe even pulsing the white noise on and
off at a two second rate during the 10 second hang time is the right
approach.

Suggestions?  Comments?

A note: it's been suggested that having the repeater just toggle between
1200 and 9600 bps modes based on which it heard last.  That has some
merit, but if the TNC at the site is to be able to link the repeater to
other facilities, since it can't know which speed to transmit at when
the packet arrives from off-system.  We're going to leave the TNC and
networking stuff running at 9600; the 1200 bps people only get a
repeater.  Perhaps that will be incentive to up their speed.
    - Brian

------------------------------

Date: Mon, 1 Oct 90 16:14:16 PDT
From: Brian Lloyd <[e-mail]>
Subject: 9600/1200 bps dual-speed full duplex repeater hassles
To: [e-mail], ucsd.edu![e-mail]

Sounds good Brian.  I do disagree with you on the hang-time issue
tho'.  My repeater worked just fine with no hang time because it would
go from nothing to full output in just a couple of microseconds.  How?
I keyed the last multiplier and left all the other stages running all
the time.  Since all the driver stages run class-C they are cut off
without drive so no output and no noise.

The transmitter was keyed by a 2N2222 keying the emitter of the last
multiplier.  A TTL or RS-232 high on the base of the 2N2222 (through a
current limiting resistor, of course) would pull the emitter of the
last multiplier low and generate RF.

Keying transients were a problem at first.  Standard CW keying shaping
techniques get rid of the transient keying products.  I used a small
capacitor right at the base of the 2N2222.  Even with that the
transmitter can be made to key MUCH faster than anything else in the
system.  It also avoids all the problems having to do with detecting a
carrier.  Existing stations do not need any modifications to use the
repeater.

73 de Brian, WB6RQN

------------------------------

Date: 02 Oct 90 08:49 GMT
From: "Disini SW, Emmanuel Disini,PRT" <[e-mail]>
Subject: TNCs and DataRadio
To: [e-mail]

hello, pac-radio enthusiasts!

i am thinking of joining your ranks, but am in need of advice as to what to
buy. Recently I have been talking to the local reps of DataRadio (HQ in Quebec,
Canada), who carry a complete TNC-VHF radio combo that is quite pricey. I am in
need of a data link over radio waves that works at a range of about 50 miles,
and has decent error-correcting capabilities <especially during thunderstorms>.
I would think that a regular TNC and VHF radio would suffice, but I am told
that regular radios will probably only work at 1200-2400 baud?  Supposedly
regular radios have high attack times and turnaround times (approx 300 ms) as
opposed to dataRadio's (2-4 ms), and are suspect to frequency-drift, which
cause reception problems?

any info you guys can give is appreciated, especially e-mail addresses of other
TNC/pac-radio manufacturers.

thanks,
joel disini
manila, philippines

ps
pls cc: all responses to me, as i'm not on this list!


------------------------------

End of Packet-Radio Digest
******************************
Date: Wed,  3 Oct 90 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #159
To: packet-radio


Packet-Radio Digest         Wed,  3 Oct 90       Volume 90 : Issue 159

Today's Topics:
               DSY Modem Notes
                kam wefax mode
           LZW compression implementation available
               maxframe and efficiency
           Want Nacogdoches, Texas Contact

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: Tue, 2 Oct 90 16:51:48 EDT
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: DSY Modem Notes
To: [e-mail], [e-mail]

I encountered, and fixed, a problem with my DSY modem quite some time I ago
that I didn't bother mentioning to anyone, assuming that it was just an
isolated quirk.  Recently however, the same problem was discovered in
VE3MDL's modem, so it may be more widespread than I thought.  Time to tell
the world!

The symptom of the problem is excessive DCD falsing.  If you find that you
really have to crank up the threshold control to stop the falsing, or if your
DCD lights up more or less steadily when you remove the input to the receive
side of the modem, then you've probably got it.  The basic cause is that the
MC3359 FM demod chip doesn't have enough gain ahead of its limiter, and under
no-signal conditions the noise level isn't high enough to cause full
limiting, so the noise is relatively low (i.e., lower than the eye pattern
amplitude when a signal is present).  Since the modem DCD circuit thinks a
lack of noise equals signal, it declares carrier detect.

In poking around the 3359, I discovered there was a low frequency
oscillation present on some of the pins.  I don't remember exactly, but I
think it was in the 100 kHz region, and several volts in amplitude.  The
oscillation seemed to be related to a problem with power supply decoupling in
the 3359 or the preceding IF amplifier stage.  The cure was to add a bypass
capacitor of at least 0.15 uF on top of the board, from the lead of the fixed
inductor L4 at the end nearest the 3359, to ground.  This also improved the
gain ahead of the limiter and greatly improved the DCD falsing problem.  I've
heard a number of complaints about the DSY DCD circuit - I wonder if this
problem could be part of the reason?

While I'm on the subject... If you run the DSY modem in a full-duplex link,
or if you keep the tx side of the modem running continuously for any reason
(like minimizing the keyup time, as I've often advocated), be aware of a
potential problem.  The DSY encoder board contains a 3.579 MHz oscillator
which is keyed by the RTS line, and its 3rd harmonic at 10.739 MHz falls
smack into the receiver first IF (thanx to VE3MDL for first pointing this
out).  If enough of it gets into the modem receiver, it will cause both
desensing (higher BER on weak signals) AND DCD falsing.  To see it's a
problem in your modem, put a scope on the eye pattern (TP1 of the decoder
board) and key the tx side.  Under no-signal conditions, you should see
plenty of noise, with peak-to-peak amplitude a bit more than the eye pattern
of a valid signal.  If leakage from the encoder oscillator is present, the
noise will be lower in amplitude and "scrunched up" around one level (offset
from zero, since the birdie is not centered in the IF).  In my case, with the
modem boards spread out in the same horizontal plane in an aluminum chassis,
the leakage is quite severe with the cover off, but barely noticeable if it
is tightly fitted over the encoder board, and hopefully completely gone with
the cover fully on (refrigerator light bulb syndrome :-).  Your mileage
undoubtedly will vary, especially if you stack the boards, so check it out.

Barry VE3JF

------------------------------

Date: 30 Sep 90 01:50:20 GMT
From: unisoft!hoptoad!pacbell!pacbell.com!mips!swrinde!cs.utexas.edu!samsung!umich!umeecs!msi-s0.msi.umn.edu!noc.MR.NET!uc!shamash![e-mail]  (Jeff Comstock)
Subject: kam wefax mode
To: [e-mail]

In article <[e-mail]> [e-mail] ("Vincenzo G. Capuano") writes:
>Hi,
>I would like to write a program to display fax, and wefax on a Mac II
>using a Kantronics KAM or an AEA PK-232. Where can I find the documentation
>on how to understand the informations that these TNCs send to the serial port
>of my Mac ? I mean: how can I detect the color of a pixel by reading the
>serial port ? What signal of the rs232? Etc. Etc.......
>

Speaking for the PK232:
The only real way to do this is in host mode.  You have to get the
tech reference manual from AEA for about $20.00 .

There is one thing you should know about the 232, and I bet it is
true about the KAM also - the FAX is totally fake.  The TNC returns
a 1 or 0 that depicts what the demodulator is picking up.  There are
no gray scales or colors involved.  So the TNC returns a byte stream
that may be interpreted as pixel on or pixel off.  It looks ok, but
it leaves much to be desired for sat images on the wefax transmissions.
The tones of a fax signal vary between 1500 hz and 2300 hz.  The 232
can only hear 2 of these, the 1500 and the 2300.  ( actually 1200 and
2200 hz).

In summary:
The returned byte indicates if the 8 pixels are on or off. EG:
FF00FF  would turn the first 16 pixels on, the next 16 off, the
next 16 on.......

------------------------------

Date: 2 Oct 90 15:24:36 GMT
From: eru!hagbard!sunic!sics.se!sics.se![e-mail]  (Anders Klemets)
Subject: LZW compression implementation available
To: [e-mail]

This message is to announce the availability of version 3 of my LZW
compression protocol. The current implementation is for the KA9Q
Internet Package (NOS) where it can operate on TCP, NET/ROM and AX.25
connections. But it should be possible to port this implementation to
other software, such as dedicated BBS'es.

The compression algorithm works similar to the way GIF files are
compressed. The major difference between straight LZW and GIF is that
GIF uses a variable size for the codewords. My implementation also
uses variable size codewords.

The compression routine looks at data as 8 bit words and begins coding
input strings as 9 bit codewords. As the codewords get used up, it
increases the size to 10 bits, and so on. When the maximum codeword
has been reached, it clears the code table and restarts with 9 bit
long codewords.

It is possible for an application in NOS to specify the maximum number
of bits to use for codewords, and hence, what the maximum codeword
will be. The valid range is 9 to 16 bits. At 16 bits, there can be
65535 different codewords. That might not seem like very much at a
first glance, but at that point NOS will use 192 kbytes to keep the
code table, which should make things pretty tight.

I have tried to optimize my implementation in a memory efficient way,
that will however make the compression somewhat slow. But since it is
intended for 1200 Baud AX.25 links or SLIP links, I guess it will not
matter all that much. For those who are concerned about processing
speed, it is possible to specify an alternate code table algorithm.
It computes faster, but needs more memory. A code table using the
"compact" algorithm may grow to about (2^bits * 3) bytes, where 'bits'
is the maximum number of bits a codeword may use. The "fast" algorithm
may have to use up to (2^bits * 5) bytes.

Which algorithm to use, and how to set the 'bits' limit, is a policy
decision. A larger 'bits' value increases the efficiency of the
compression algorithm, but it uses more memory and takes longer to
compute. The "fast" coding algorithm reduces the computing time, but
needs even more memory.

LZW processes groups of characters when encoding. This is no problem
when compressing files, but on a network connection there are times
when this approach is not practical. For instance, when you press the
return key, you probably want what you have typed to be sent
immediately. But LZW wants to hold on to the data because it needs to
know what you intend to type after you have pressed the return key, so
that it can compress what you typed more efficiently.
I have solved this by interrupting coding whenever the output buffer
is flushed (by pressing the return key for instance) and signaling this
with a special flush codeword.

LZW is somewhat inefficient on interactive terminal traffic, since
there is lots of pressing of the return key. It works better for batch
traffic, such as mail forwarding, where packets are longer than 80
characters.
It is especially inefficient when one operates in remote echo mode
("full duplex") because then every coded character has to be followed
by the flush codeword. This is particular mode of operation makes my
LZW two or three times less efficient than without "compression."

There is also a special codeword ZCC which will cause an immediate
clearing of the recievers code table and setting of the current bit
size to 9 bits. This could be used to preempt low priority transfers
when NOS needs more memory for other tasks.

The LZW implementation sits in the socket library, and works on top of
any stream based socket, such as TCP, AX.25 or NETROM.
All the application needs to do is to make the following call:

         lzwinit(s,bits,mode);

where 's' is the socket descriptor. 'bits' is an integer between 9 and
16 specifying the maximum number of bits to use for each codeword.
The compression code table will always use this or a lower size, but
'bits' should only be regarded as a recommendation with respect to the
decompression code table. 'mode' specifies the compression algorithm
and should be either LZWCOMPACT or LZWFAST. Data should be sent and
recevied with usprintf(), usputc(), recvchar(), recvline(), etc. Calls
to send(), send_mbuf(), recv() or recv_mbuf() will bypass the coding,
which obviously will cause strange effects.

One of the better uses for the LZW compression is to transfer mail. It
should be noted that a connection for transfering mail might be left
connected even while there is no mail to transfer, to save the code
table. It would be very inefficient to transfer only one single piece
of mail for each connection, since the LZW code table has to be
rebuilt each time.

In the case of transfering mail with SMTP, I see two different
approaches. One is to have a special ZSMTP server that runs on a
different TCP port. The other is to have the client connect without
using compression, and then issue a special command, such as "XLZW."
If it is accepted, transfering of compressed mail can begin. However,
some SMTP server implementations panic when they get an unknown
command and close the connection, instead of sending a "500 command
unrecognized" response.

The source for the LZW implementation is available with ftp from
sics.se. The filename is archive/packet/ka9q/nos/lzw.arc. The files in
this archive are supposed to be merged with a recent version of the
NOS source code which is available from thumper.bellcore.com.
The archive contains no applications using LZW however, modifying
Telnet or SMTP to use the compression is left as an exercise for the
reader.

Anders, SM0RGV
[e-mail]

------------------------------

Date: 1 Oct 90 04:19:04 GMT
From: bellcore-2!thumper![e-mail]  (Phil R. Karn)
Subject: maxframe and efficiency
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>Someone recently mentioned that the MAXFRAME parameter should always be
>set to 1.  What if your link is a "solid" backbone link and you want
>to send more than 256 bytes/shot (Net/ROM link)?  In particular, what if
>a 1200 baud Net/ROM network is converted to 9600 baud, and the data rate
>transfer is less than 8 times as much?  How do you determine how long a
>transmitter should be keyed for maximum efficiency?  Use tcp/ip?  :-)

The "someone" was originally me. Several years ago I published in the
proceedings of the ARRL Computer Networking Conference an analysis of
a go-back-N protocol (i.e., the LAPB sublayer of AX.25). I found that
on half duplex channels with a very wide range of channel bit error
rates it was always best to set maxframe=1 and vary the packet length
according to the quality of the channel: short frames on noisy channels,
long frames on clean channels.

While it is certainly true that you can sometimes improve performance
by increasing maxframe above one, you can always do even better by
keeping maxframe at 1 and increasing the frame size instead. This
*does* require you in some cases to increase your frame size beyond
256 bytes. This is common practice in the TCP/IP world, but it may not
be practical in the straight-AX.25 world since many TNCs have
hard-coded buffer sizes.

One thing you can do to substantially improve throughput even with plain
AX.25 is to stamp out the practice of triggering a packet each time a
newline is seen in the input stream, even if the packet contains only
a single character. Certain BBS packages are notorious offenders here.

>When tcp/ip (ka9q version) backs off due to channel congestion, does it
>wait longer between frames, reduce frame size, both, or what?

Both. When a TCP retransmission occurs, only the oldest unacked
segment is sent even if the flow control window had opened up.  Each
successive retransmission interval is twice the proceeding one.  It is
easy to see that even over infinite time such a system will consume
only finite channel time (consider Zeno's paradox). This behavior
makes the system unconditionally stable no matter how many
transmitters you have.

Phil

------------------------------

Date: 30 Sep 90 23:50:51 GMT
From: venus!yalevm!maine![e-mail]  (Paul H. Risk)
Subject: Want Nacogdoches, Texas Contact
To: [e-mail]

I'm moving to Nacogdoches to accept faculty position at Stephen F. Austin
State University, School of Forestry.  I'd be interested in finding out
about packet activity there.  Is there a BBS I could work thru while
I'm still here in Maine..  Also interested in general info on ham
radio in the area- repeaters, etc...  CUD ragchew on HF.

Paul H. Risk N1DJD
Univ of Maine College of Forestry
Orono, Maine

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu,  4 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #160
To: packet-radio


Packet-Radio Digest         Thu,  4 Oct 90       Volume 90 : Issue 160

Today's Topics:
          Any comments on L.L. Grace DSP-12?
         Distributing newsgroups on AM radio?
            Help - Routing Problem
               High-speed KISS
          plexus p/35 unix box help (2 msgs)
               SoCal 2m packet channels

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 3 Oct 90 20:00:39 GMT
From: attcan!lsuc!atha!aupair.cs.athabascau.ca![e-mail]  (Ross Alexander)
Subject: Any comments on L.L. Grace DSP-12?
To: [e-mail]

[e-mail] (Robert McGwier) writes:
>after all.  The modems do not exist and the box has not passed or even been
>submitted for FCC testing.  I believe what he is doing in the advertisements

I just spoke with him (Brooks Vantel, KB2CST, [phone]) and he
confirmed that the DSP-12 hadn't made it through FCC type approval
yet.  And yes, he was taking orders and had a waiting list going.
Hmmm.  The thing that worried me was that the programmer's guide was
the *last* thing on his to-do list - I won't make a buy descision
until I've seen that.  He did say, though, that the firmware sources
would be available through a non-disclosure agreement.

Disclaimer:  your mileage may vary, & c. & c.  I suggest you phone
KB2CST if you want "horse's mouth".

BTW, anyone have a number for the *other* Grace Communications?  I am
trying to get a line on the PackeTen 68302-based board (and truth be
told, I'd a lot rather hack a 68xxx machine than an 80x86-flavoured
one, any day.  The learning curve will be a lot less steep for me.)

--
--
Ross Alexander    [e-mail]    [phone]    ve6pdq

------------------------------

Date: 3 Oct 90 19:21:27 GMT
From: attcan!lsuc!atha!aupair.cs.athabascau.ca![e-mail]  (Lyndon Nerenberg)
Subject: Distributing newsgroups on AM radio?
To: [e-mail]

[e-mail] (Lauren Weinstein) writes:

>And indeed, just because an experiment ends doesn't mean it wasn't
>worthwhile.  I would not call the experiment a failure.  To learn
>that a particular technology is not suitable for netnews is
>meaningful information.  While it would have been interesting if the
>results had been "positive", negative outcomes are useful too.

I agree. Conducting this experiment (no doubt) generated a lot of useful
data and experience. What bothers me is that nothing appears to have ever
been published about the experiment and its outcome. Surely this information
should be shared with a wide audience.

If there have been paper published about this, I would appreciate any and
all references. Thanks.

--
    Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
    {alberta,cbmvax,mips}!atha!lyndon || [e-mail]

      The only thing open about OSF is their mouth.  --Chuck Musciano

------------------------------

Date: Wed, 03 Oct 90 11:42:42 BST
From: [e-mail]
Subject: Help - Routing Problem
To: packet-radio <@nsfnet-relay.ac.uk:[e-mail]>,


Greetings,

Last night I went to a committee meeting of the North-West Packet User Group
(NWPUG) and it came apparent that we are having routing problems in the UK
in that Packet mail is not always reaching its destination outside the UK.

We are trying to track down the problem, and were wondering if all the people
on these two lists were to send one short message to me on packet plus a copy
to me here at work (so that we know how many messages to expect), it would
help us to plan the forwarding a bit better.

John

     John Heaton           NRS Central Administrator
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    JANET : [e-mail]           MCC Network Unit (G45)
 DARPA/BITNET : [e-mail]           The University
     UUCP : [e-mail]      Oxford Road
                         Manchester,   M13 9PL
  AMPR : [44.131.1.8] amiga.G1YYH.ampr.org   Tel : [phone]
 AX.25 : G1YYH @ GB7NWP  (QTHR)              Fax : [phone]


------------------------------

Date: 3 Oct 90 20:01:54 GMT
From: mcsun!ukc!slxsys!qtnet![e-mail]  (Nick Lawes)
Subject: High-speed KISS
To: [e-mail]

Does anyone out there know if there's a version of the KISS code code
that will cope with 9600 baud (from a G3RUH modem). The standalone
versions that I currently have send a lot of rubbish data to NET. The
version built into the 1.1.7 ROM seems to function okay, but requires
32K RAM in the TNC.

Source would be nice if there's any available, but binary or intel hex
files are fine...

Unfortunately I have no FTP facilities, so pointers to such sites are
of little use... uucp, e-mail, info-servers etc are all fine...

Thanks in advance,

    Nick
--
[    Nick Lawes, Systems Development    | voice:       [phone]    ]
[ Quotron Information Business Limited. | email: ..!ukc!slxsys!qtnet!nick ]
[ 12 Norwich Street, London.  EC4a 1BP  | ham  :        G8ZHR @ GB3XP     ]

------------------------------

Date: 3 Oct 90 19:49:40 GMT
From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!dip.eecs.umich.edu![e-mail]  (Ralph Seguin)
Subject: plexus p/35 unix box help
To: [e-mail]

Hi.  I am about to acquire a PLEXUS P/35 68000 based UNIX box running
Sys V.2 (yech, I know 8-).  I have several questions.

1:  Can I get something akin to DNET to compile on this beast?
2:  Can I get an ethernet board for it?
3:  It has 8 serial ports, so I'm hoping to get SLIP on it.
4:  Any other info anybody may have about this box.
**** 5:  Can SLIP run on it?
6:  Any way of adding sockets?
7:  Anybody got a cheap big SMD drive to sell?
8:  Easy and cheap way to move up from V.2?
9:  Any other interesting info, please?


I know that DNET won't compile since V.2 doesn't have sockets.

            Thanks, Ralph


[e-mail]       [e-mail]
[e-mail]     [e-mail]
[e-mail]    [e-mail]

Ralph Seguin            | Drinking a pan-galactic gargle blaster is
536 South Forest        | like being struck over the head by a large
Apartment 915           | brick of gold with a lemon wrapped around it.
Ann Arbor, MI 48104     |               - Zaphod Beeblebrox
[phone]

------------------------------

Date: 3 Oct 90 19:55:14 GMT
From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!dip.eecs.umich.edu![e-mail]  (Ralph Seguin)
Subject: plexus p/35 unix box help
To: [e-mail]

 Can I run SLIP (TCP/IP ?) on this box?
 Also is there a newer version of KA9Q?  I want to hook this thing
 up to my Amiga.  Where would be the best place/person to get
 info/programs on using SLIP?

 Hi.  I am about to acquire a PLEXUS P/35 68000 based UNIX box running
 Sys V.2 (yech, I know 8-).  I have several questions.

 1:  Can I get something akin to DNET to compile on this beast?
 2:  Can I get an ethernet board for it?
 3:  It has 8 serial ports, so I'm hoping to get SLIP on it.
 4:  Any other info anybody may have about this box.
 **** 5:  Can SLIP run on it?
 6:  Any way of adding sockets to V.2?
 7:  Anybody got a cheap big SMD drive to sell?
 8:  Easy and cheap way to move up from V.2?
 9:  Any other interesting info, please?

 I know that DNET won't compile since V.2 doesn't have sockets.

            Thanks, Ralph


 [e-mail]       [e-mail]
 [e-mail]     [e-mail]
 [e-mail]    [e-mail]

 Ralph Seguin           | Drinking a pan-galactic gargle blaster is
 536 South Forest       | like being struck over the head by a large
 Apartment 915          | brick of gold with a lemon wrapped around it.
 Ann Arbor, MI 48104    |               - Zaphod Beeblebrox
 [phone]

------------------------------

Date: 3 Oct 90 17:41:26 GMT
From: [e-mail]  (Brian Kantor)
Subject: SoCal 2m packet channels
To: [e-mail]

The following is primarily of interest to Southern California stations,
but just to give the rest of you an idea of packet usage here on the
left coast....

SCDCC and TASMA are the So Cal Digital Communications Council and Two
meter Area Spectrum Management Association, respectively.  Somewhere
along the line they seem to have arrogated coordination of packet nodes
and simplex frequencies to themselves, and a large number of hams tend
to go along with them.  (This may be beneficial, but I can't help but
feel uneasy about it...)

Anyway, the latest bumf on frequencies and usage:
    - Brian

            SOUTHERN CALIFORNIA TWO-METER PACKET
                  BAND USAGE PLAN

                   28 JULY 1990

The following Band Usage Plan for Amateur Packet operations in Southern
California was adopted by the Southern California Digital Communications
Council (SCDCC) Board of Directors on 28 July 1990.  The purposes of this
plan are:

1.  To provide the Southern California Two-Meter Area Spectrum Management
    Association (TASMA) with a Plan for the utilization of the additional
    200 KHz of spectrum earmarked for future allocation to digital modes.
    This additional spectrum was added to the Two-Meter Band Plan by vote
    of the TASMA General Membership at their Annual Meeting held in June.
    A provision of the action taken at that time was that the SCDCC was to
    provide the TASMA Technical Committee with a Usage Plan for the new
    frequencies in order that TASMA would be aware of the general plan
    concepts.

2.  To establish a baseline Plan which can be used by the SCDCC Board of
    Directors in performing their tasks of "coordinating .... the activities
    of the many specialized interest groups and individuals using Packet
    Radio, .... and developing recommended standards regarding .... elements
    of network design and implementation" as defined in their Bylaws.


The plan is based upon the following understandings and principles:

A.  The Two-Meter Band is currently, and will continue for some time to be,
    the primary set of frequencies used for User level access to the
    resources and facilities available in the service.

B.  The Frequency of 145.01 MHz is designated at the National level as
    being for inter-LAN use and is generally accepted as the "packet
    calling frequency."  This is being interpreted in Southern California to
    mean that this frequency should provide a maximum of network access
    opportunity for the general user but should not be directly inhabited
    by high intensity services like BBS's, Public MailBoxes, File Servers or
    Gateways.  Low-level cellular Nodes accessing the Network via secondary
    frequencies are preferred.

C.  A network architecture combining the concepts of a hierarchal
    frequency structure and cellular area design will provide the most
    effective system for Southern California and will offer the greatest
    opportunity for maximum individual and group involvement in the
    development and use of Packet Radio.  NET/ROM and NET/ROM compatible
    networking software/firmware is the current standard for the region.

D.  Establishment of a Band Usage Plan as compatible as practical with
    adjacent areas is in the best interest of all concerned.  Specifically,
    frequency use assignments recognizing prior designations made by the
    Northern California Packet Association (NCPA) have been considered.

E.  Occupancy of the new packet frequencies between 144.9 thru 145.0 and
    145.6 thru 145.7 will not occur until the frequencies have been
    released by TASMA.  At that time, stations will be expected to adjust
    their operations to conform with this plan.  It is suggested that
    stations providing Network services forward information regarding their
    intentions to use any of the new frequencies (or move their operations
    on existing frequencies) to the SCDCC in order that possible conflicts
    can be identified as early as possible.

F.  Hopefully all aspects of Packet Radio operation have been considered in
    the development of this plan.  Certainly, those interested in providing
    an input to it have had that opportunity.  The broad representation
    provided by the structure of the SCDCC Board of Directors has helped to
    insure that this is the case.

G.  Even though the DX Spotting Packet Network (DX Clusters) have chosen not
    to participate in the SCDCC, their needs have been included in the plan
    and DXSPN participants will be expected to adjust their operations
    accordingly.


PACKET FREQUENCY USAGE DESIGNATIONS

DX SPOTTING  - DXSPN User access channel.  1200/2400 BAUD.  No Inter-node
           linking.  (See Notes on specific frequencies.)

EXPERIMENTAL - The frequency is set aside for narrow-band experimental
           activities.  Initially included are operations at data rates
           of greater than 2400 BAUD although additional channels will
           be converted to higher speeds as the need arises.  IF YOUR
           OPERATION IS INCOMPATIBLE WITH OTHERS ON THE SAME FREQUENCY,
           YOU BELONG HERE.

KEYBOARD     - The frequency is intended for use by operators who wish to
           make keyboard to keyboard contact.  NET/ROM and Gateway
           stations are permitted as long as they do not interconnect
           with non-keyboard frequencies.  Private MailBoxes are allowed
           as long as they don't try to serve multiple individuals or
           perform automatic forwarding.  Conference Bridges may be
           acceptable if operating hours are restricted.

LAN          - The frequency is intended to serve as a Local Area Network
           channel in conformance with the cellular area of service
           concept.  LAN's may or may not be serviced by NET/ROM Nodes
           providing off frequency connection to the Metropolitan and
           Wide Area Networks.  BBS service at the LAN level is
           encouraged.  Inter-LAN forwarding on the two-meter frequency
           is to be avoided.  Typical service areas are expected to be
           defined by natural geographic boundaries.  Power levels and
           antenna heights should be adjusted to provide for maximum
           frequency re-use.

TCP/IP       - The frequency is intended for use by operators and services
           utilizing the TCP/IP Protocol.  Maximum use should be made of
           Area Routers and IP Gateway stations.  NET/ROM Nodes on these
           frequencies may interconnect with off frequency  Metropolitan
           and Wide Area Networks but should minimize the number of Nodes
           added to the Network by supporting designated Gateway stations.


PACKET FREQUENCY USAGE ASSIGNMENTS

144.91 MHz.  KEYBOARD Channel.  Corresponds with allocation in Northern
         California.  Expect some 145.09 NET/ROM Nodes to move here
         for linking purposes. FREQUENCY NOT AVAILABLE AT THIS TIME.
         ADJACENT FREQUENCIES IN USE.

144.93 MHz.  TCP/IP Channel.  Corresponds with limited allocation in
         Northern California. FREQUENCY NOT AVAILABLE AT THIS TIME.
         ADJACENT FREQUENCIES IN USE BY COORDINATED REPEATERS.

144.95 MHz.  DX SPOTTING.  Corresponds with allocation in Northern Calif-
         ornia.  Requires cooperation with infrequent SPACE operations.
         FREQUENCY NOT AVAILABLE AT THIS TIME.  ADJACENT FREQUENCIES
         IN USE BY COORDINATED REPEATERS.

144.97 MHz.  LAN Channel.  Corresponds with allocation in Northern Calif-
         ornia.  FREQUENCY NOT AVAILABLE AT THIS TIME.  IN USE BY
         COORDINATED REPEATER.

144.99 MHz.  EXPERIMENTAL.  FREQUENCY NOT AVAILABLE AT THIS TIME. ADJACENT
         FREQUENCY IN USE BY COORDINATED REPEATER.

145.01 MHz.  INTER-LAN Channel.  No high intensity services. See Notes above.
         Available.  Most existing high-level Nodes should be converted
         to a MAN or WAN frequency.

145.03 MHz.  KEYBOARD Channel.  Available.  Corresponds with allocation in
         Northern California.  Expect development in compliance with
         cellular concept.  Existing non-complying services will be
         asked to move when frequencies become available.

145.05 MHz.  LAN Channel.  Available.  Existing users should convert to
         comply with cellular concept as soon as practical.

145.07 MHz.  LAN Channel.  Available.  Corresponds with allocation in
         Northern California.  Existing users should convert to
         comply with cellular concept as soon as practical.

145.09 MHz.  EXISTING: KEYBOARD Channel.  Will remain as KEYBOARD Channel
               until 30 days after 144.91 MHz. becomes available.
         FUTURE:   LAN Channel.  Corresponds with allocation in Northern
               California.

145.61 MHz.  LAN Channel.  FREQUENCY NOT AVAILABLE AT THIS TIME.  COORDI-
         NATED SIMPLEX AUTOPATCHES BEING RELOCATED.

145.63 MHz.  LAN Channel.  FREQUENCY NOT AVAILABLE AT THIS TIME.  COORDI-
         NATED SIMPLEX OPERATIONS BEING RELOCATED.

145.65 MHz.  LAN channel.  FREQUENCY NOT AVAILABLE AT THIS TIME.  COORDI-
         NATED SIMPLEX OPERATIONS BEING RELOCATED.

145.67 MHz.  DX SPOTTING.  Available.  Existing DXSPN stations on 145.68 MHz.
         may move to this frequency as appropriate (see discussion below).

145.69 MHz.  DX SPOTTING/LAN.  Available for DXSPN stations prepared to
         comply with cellular concept installation.  Application should
         be made to the SCDCC.  Frequency will be used for both DX
         SPOTTING and LAN environments in compatible adjacent areas.

  NOTE: TRANSITION OF DXSPN STATIONS - Existing DXSPN stations have the
    following choices.  The 145.67 MHz frequency is currently available
    for occupancy and does not require conversion to a low level cellular
    site.  Some stations on 145.68 will probably want to make such a
    move in the near time frame. The alternative to making such a move
    at this time is to wait until 144.95 is available where again
    compliance with the low-level requirement will not be initially
    applied.  When 145.69 is made available, it will be open to low-
    level cellular compliant stations.  It is expected that DXSPN
    members will coordinate amongst themselves to ensure a smooth
    transition to the new frequencies and that application for use
    of 145.69 will be made as described above.


                      James T. Fortney, K6IYK
                      Administrative Director,
                      So. Calif. Digital Comm. Council
                      K6IYK@K6IYK

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri,  5 Oct 90 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #161
To: packet-radio


Packet-Radio Digest         Fri,  5 Oct 90       Volume 90 : Issue 161

Today's Topics:
         I need Amiga version of NOS (2 msgs)
                kam wefax mode
              Looking for PA0GRI
             Maxframe == 1 (ka9q)
               maxframe and efficiency
          Networking Conference Proceedings

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 4 Oct 90 10:01:40 GMT
From: crash![e-mail]  (Jim Burnes)
Subject: I need Amiga version of NOS
To: [e-mail]

Could someone please help me?  I would dearly like to get a hold
of the amiga version of NOS.  I found it on WB3FFV, but WB3FFV isnt
pc pursuitable and I didnt want to spend 40 minutes worth of SPRINT
time to download the 600k+ archive.  My network site obviously has
uucp but its internet connection is rarely used.  I checked on
thumper.bellcore.com but was unable to make heads or tails of any
of the files there.  If someone knows what machine on internet
its on and what directory and file name I would be more than happy
to ask my sysop to fire up his telebit and SLIP it on down the line.
He says the FTP costs are minimal.

Thanks in Advance,

Jim Burnes

------------------------------

Date: 4 Oct 90 21:11:46 GMT
From: uhccux!uhunix1.uhcc.Hawaii.Edu![e-mail]  (Mr. Antonio Querubin)
Subject: I need Amiga version of NOS
To: [e-mail]

You can FTP it from sayshell.umd.edu.

------------------------------

Date: 4 Oct 90 17:04:15 GMT
From: bu.edu!mirror!necntc!necis![e-mail]  ( NM1D)
Subject: kam wefax mode
To: [e-mail]

In article <[e-mail]>, [e-mail] ("Vincenzo G. Capuano") writes:
> Hi,
> I would like to write a program to display fax, and wefax on a Mac II
> using a Kantronics KAM or an AEA PK-232. Where can I find the documentation
> on how to understand the informations that these TNCs send to the serial port
> of my Mac ? I mean: how can I detect the color of a pixel by reading the
> serial port ? What signal of the rs232? Etc. Etc.......
>
> I know there are some programs for the MS-DOS world: I have seen them
> listed in wsmr-simtel20.army.mil archives: wefax.arc and autofax.arc, are
> they in source form ? If so I could try to understand the protocol by reading
> the source code....
>

The following is in reference to the KAM (actually all Kantronix TNC's, even
the KPC-2 has this ability):

  Well, they give all the information that you nead right in the owner's manual.
When I received the version that had the FAX capability I immeadiatly wrote a
program to make use of the information... It is fairly straight forward.

  Once you place the TNC in 'WEFAX' mode, the modem simply samples the
incoming fax signal and then outputs a series of bytes.   Be aware that these
are DIGITAL modems... that means no grey scale (or color) information is
presented at all.  The fax signal could vary from black through grey to white.
The TNC's modem will 'see' all shades from about the mid-grey shade to black
as black.. and anything above this shade as white.  This is not too bad as a
lot of the weather maps are sent as 'line drawings'... But don't expect good
results with images such as cloud cover or news pictures.

 The data stream from the TNC is a series of bytes.  For example if the
following stream of bytes was output (shown here in hex):

   0xff 0xff 0xff 0xff 0x55 0x55 0x55 0x55 0x00 0x00 0x00 0x00

You would consider each bit of each byte a pixel, if the bit is a '1', then
turn that pixel, on... it the bit is '0' then turn that pixel off.   So the
data example would be 32 pixels on, followed by the next 32 pixels where every
other pixel was off, followed by 32 pixels that are turned off.   You just
grab the bytes, place them into your video memory (in the proper manner to
turn the pixels on/off), and about 10 minutes later, you see the wefax image.

  The 'AUTOFAX' program on SIMTEL20 is my program that
does just what I describe... it is really simple and dumb... Sorry, the source
it not included.  This was a quick hack that I did to see what wefax was all
about... I found that it was kind of fun, but I got bored with it rather
quickly (I couldn't stand to wait the minutes that it took for the pictures
to appear).  I didn't develop the program any further because Kantronix and
other manufacturers finaly released their programs to do the same.


  Hope this helps,

  Rich (NM1D)

 /**************************************************************************\
 * Rich Bono (NM1D)    If I could only 'C' forever!!    [e-mail] *
 * [phone]          NEC Technologies Inc.                NM1D@WB1DSW *
 \**************************************************************************/

------------------------------

Date: 3 Oct 90 17:39:23 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Terry Bell)
Subject: Looking for PA0GRI
To: [e-mail]

Howdy!

Can anyone tell me how I can contact PA0GRI?

Thanks!!!
Terry

--
******************************************************************************
Terry Bell   [e-mail]       AMSAT-NA        N8HSP.AMPR.ORG [44.70.4.10]
UUCP: usenet.ins.cwru.edu!ncoast!tbell   Internet: [e-mail]
******************************************************************************

------------------------------

Date: Wed, 03 Oct 90 00:36:19 MDT
From: (null)
Subject: Maxframe == 1 (ka9q)
To: wb8zxu%wb8zxu@kf7tp, kf7tp@kf7tp, [e-mail],

Tks for passing that along Dave.
There is another reason (or maybe it helped cause the conclusion that PhilK
reached).  AX.25 cannot request a "fill."  All packets after a damaged packet
must be retransmitted.  That makes the "average size" of a retry to be some
multiple of a packet > 1.  For example, Max 3 retries average about 2 packets
per retry ... plus the greater retry size has more errors, etc ....
When maxframe is ONE, the average size of a retry is also ONE (plus the error
rate.)

Both NetRom and TCP/IP can request fills for missing data.  N/r by packet
number and TCP by byte number.  Both buffer what was received after the bad
spot so the ACK point can advance as soon as the fill is recvd.

------------------------------

Date: 3 Oct 90 15:36:55 GMT
From: sdd.hp.com!wuarchive!cs.utexas.edu!asuvax!mcdphx!.UUCP![e-mail]  (Dave Fritsche)
Subject: maxframe and efficiency
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>In article <[e-mail]> [e-mail] writes:
>>Someone recently mentioned that the MAXFRAME parameter should always be
>>set to 1.  What if your link is a "solid" backbone link and you want
>
>The "someone" was originally me. Several years ago I published in the
>proceedings of the ARRL Computer Networking Conference an analysis of
>a go-back-N protocol (i.e., the LAPB sublayer of AX.25). I found that
>on half duplex channels with a very wide range of channel bit error
>rates it was always best to set maxframe=1 and vary the packet length
>according to the quality of the channel: short frames on noisy channels,
>long frames on clean channels.

===========================================================================
Forwarded from packet for Gary, WS5N by Dave, wb8zxu ([e-mail])
===========================================================================

------------------------------

Date: 3 Oct 90 16:32:31 GMT
From: sdd.hp.com!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!geac!alias!earth![e-mail]  (C. Harald Koch)
Subject: Networking Conference Proceedings
To: [e-mail]

Is it possible to purchase the conference proceedings from the various
Amateur Radio Networking Conferences?  If so, who do I contact?

    Thanks!

--
C. Harald Koch  VE3TLA                Alias Research, Inc., Toronto ON Canada
[e-mail]      [e-mail]      [e-mail]
"Open the Zamboni! We're coming out!" - Kathrin Garland and Anson James, 2299

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat,  6 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #162
To: packet-radio


Packet-Radio Digest         Sat,  6 Oct 90       Volume 90 : Issue 162

Today's Topics:
               KISS ROMs for ASHBY TNC
             pac-radio magazines (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: Fri, 5 Oct 90 09:42:43 EDT
From: [e-mail] (John H. Klingelhoeffer)
Subject: KISS ROMs for ASHBY TNC
To: [e-mail]

Subject: KISS ROM set for Ashby TNC

*Several* years ago I purchased and used an Ashby TNC when packet
radio was just starting up.  In the environmental spirit of things,
I'd like to recycle the unit and continue to use it with a more
modern networking system (e.g., the KA9Q NOS package).

In one of the earlier versions of the KA9Q documentation, there
was a reference to using (and I'm loosely quoting here) "... the
HAPN/Ashby board..." which I presume both used the Intel 8273
for HDLC framing.

Does anyone have information on whether there was ever a KISS ROM
set for the Ashby board, and if so, is there anywhere that I can
get a clone of it, or the hex listing to blow into a PROM ?

I'd appreciate any info on the subject matter someone might know.
Responses can be either to the mailing list or to:

    [e-mail]


Thanks very much.

John...    WB4LNM
+-----------------------------------------+--------------------------------+
|                                         |  "Sex on TV is fine.....       |
| John H. Klingelhoeffer                  | as long as you don't fall off" |
| Director, Government Special Operations |                                |
| Advanced Computer Communications        +--------------------------------+
| Systems Division                        | Voice: 301-290-8100            |
| 10220 Old Columbia Road                 | Fax:   [phone]            |
| Columbia, Maryland  USA   21046-1725    | Radio: 224.56/147.135 WB4LNM   |
|                                         | Internet: [e-mail]   |
+-----------------------------------------+--------------------------------+

------------------------------

Date: 05 Oct 90 06:37 GMT
From: "Disini SW, Emmanuel Disini,PRT" <[e-mail]>
Subject: pac-radio magazines
To: [e-mail]

can anyone suggest a good magazine for packet-radio?
thanks,
joel disini


------------------------------

Date: 5 Oct 90 16:53:18 GMT
From: uc!shamash![e-mail]  (Jeff Comstock)
Subject: pac-radio magazines
To: [e-mail]

In article <[e-mail]> [e-mail] ("Disini SW, Emmanuel Disini,PRT") writes:
>can anyone suggest a good magazine for packet-radio?
>thanks,
>joel disini
>

I'm afraid this is as good as it gets [rec.ham-radio.packet] :-) . If
you are interested in TCP/IP, maybe you should subscribe to the
tcp-group mailing list.  I think that a months worth of messages from
it could be considered 'kind of like a small magazine.'

Jeff
NR0D

------------------------------

End of Packet-Radio Digest
******************************
Date: Sun,  7 Oct 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #163
To: packet-radio


Packet-Radio Digest         Sun,  7 Oct 90       Volume 90 : Issue 163

Today's Topics:
             atn: Paul Risk N1DJD
            Help - Routing Problem
             pac-radio magazines
              PACKET QUESTIONS BY NOVICE
            SLIP, KA9Q, UNIX and Me! Ack!

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: Sat, 6 Oct 90 22:26 CDT
From: <[e-mail]>
Subject: atn: Paul Risk N1DJD
To: [e-mail]

Paul, I keep getting "user unknown" from your mailing address.  How about
a good ol' amateur packet address, hi?  I can help you w/Nacogdoches.

73, Charles AA5AV @ W5AC.TX.USA.NA

------------------------------

Date: 5 Oct 90 18:57:39 GMT
From: sumax!amc-gw!pilchuck!ssc![e-mail]  (Tad Cook)
Subject: Help - Routing Problem
To: [e-mail]

In article <[e-mail]>, [e-mail] writes:
>
> We are trying to track down the problem, and were wondering if all the people
> on these two lists were to send one short message to me on packet plus a copy
> to me here at work (so that we know how many messages to expect), it would
> help us to plan the forwarding a bit better.
>          John Heaton           NRS Central Administrator
>  DARPA/BITNET : [e-mail]           The University
>          UUCP : [e-mail]      Oxford Road
>  AX.25 : G1YYH @ GB7NWP  (QTHR)              Fax : [phone]
>


For those who want to send him a test message, his complete packet
address is G1YYH @ GB7NWP.GBR.EU



Tad Cook
Seattle, WA
Packet: KT7H @ N7HFZ.WA.USA.NA
Phone: [phone]
MCI Mail: 3288544
Telex: 6503288544 MCI UW
USENET:...uw-beaver!sumax!amc-gw!ssc!tad
or, [e-mail]

------------------------------

Date: 5 Oct 90 21:52:26 GMT
From: bu.edu!mirror!ssi3b1!shyoon!tegra![e-mail]  (Johnathan Vail)
Subject: pac-radio magazines
To: [e-mail]

In article <[e-mail]> [e-mail] (Jeff Comstock) writes:
   In article <[e-mail]> [e-mail] ("Disini SW, Emmanuel Disini,PRT") writes:

   >can anyone suggest a good magazine for packet-radio?

   I'm afraid this is as good as it gets [rec.ham-radio.packet] :-) . If
   you are interested in TCP/IP, maybe you should subscribe to the
   tcp-group mailing list.  I think that a months worth of messages from
   it could be considered 'kind of like a small magazine.'

Here is a small plug for the New England TCPer.  This is a newsletter
for our group here.  Articles are user contributed and vary from issue
to issue.  Subscription is cheap:

It comes out every other month and Rates are:

1 Year for $12, 2 for $22, 3 for $32.

The address is  The NE TCPer
        252 Stow Rd
        Harvard MA
        01451

I could try sending a complimentary issue to anyone who asks.  The
compressed Postscript file is 128K.  I have had problems sending
things that big but could try again.

73s, jv


char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!n1dxg

------------------------------

Date: 7 Oct 90 07:49:20 GMT
From: crash![e-mail]  (Jim Burnes)
Subject: PACKET QUESTIONS BY NOVICE
To: [e-mail]

Anyone:

I have a question about using TCP/IP on packet radio.

How can you implement ftp or telnet over packet tcp/ip (even on
high speed lines) if everytime it goes from one machine to another
the person who runs that station has to inspect it for 'dirty
words' or commercial transmissions.  Telnet would run REALLY
slow if every packet has to be intercepted by the station
operator for a "bad word check".

Ooppss..cheated...i have one more question...

Is it possible to run mobile packet stations from cars or whatever
over GRAPES/TCP/IP setup while the cars are moving.  Sort of a roving
TCP/IP network.  I think it would be cool.  Run those systems on
portable pcs or regular pcs running off of power inverters.

Pardon me if these are ignorant questions...I'm new to ham and packet.

Regards,

Jim Burnes

------------------------------

Date: 6 Oct 90 07:56:22 GMT
From: mintaka!olivea!samsung!uakari.primate.wisc.edu!caen![e-mail]  (Ralph Seguin)
Subject: SLIP, KA9Q, UNIX and Me! Ack!
To: [e-mail]

Hi.  Sorry for the repost, but I am in desperate need of help here.
I have just purchased a Plexus P/35 UNIX box (Sys V, Rel 2).  It
has an 8 serial port board controlled by an "Intelligent Communications
Processor".  It looks as though I am not going to be able to afford
an ethernet board for this thing, so I want to run SLIP on the serial
port board instead (yeah, I know it's slow 8(  My objective is to
network this machine with my Amiga.
Anyhow, here's YASODQ (Yet Another Series of Dumb Questions):

1.  Where can I get PD (or damned cheap) TCP/IP software implementations
    that will run on this box and allow me to run SLIP over the serial ports?

2.  Where can I get KA9Q for UNIX, and will it work on this box?

3.  Has anybody got an ethernet board for one of these boxes that they are
    willing to part with for a mere pittance?

4.  Has anybody been able to get DNET to run under System V?  What about
    rel 2?

5.  Are there any other link protocols like DNET available for both the Amiga
    and for UNIX?

6.  Is there any hope for me at all?  8-)  8-(


            Thanks, Ralph


[e-mail]       [e-mail]
[e-mail]     [e-mail]
[e-mail]    [e-mail]

Ralph Seguin            | "You mean THE Zaphod Beeblebrox?"
536 South Forest        |
Apartment 915           | "No.  Haven't you heard, I come in six packs!"
Ann Arbor, MI 48104     |
[phone]

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon,  8 Oct 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #164
To: packet-radio


Packet-Radio Digest         Mon,  8 Oct 90       Volume 90 : Issue 164

Today's Topics:
           Data Engine & reverse forwarding
               world-wide map of PBBSes

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: Sun, 7 Oct 90 03:35 CDT
From: <[e-mail]>
Subject: Data Engine & reverse forwarding
To: [e-mail]

Here is a tip for anyone using a Kantronics Data Engine with firmware 1.0.
I could not get it to reverse forward to an MSYS bbs until I realized that
the SID, [DE1.0], is not a valid SID.  I changed the firmware so that it
appears as [DE-H$].  Reverse forwarding works fine now.  This data is at
location $C2FD in the EPROM.


73, Charles AA5AV @ W5AC.TX.USA.NA

------------------------------

Date: 07 Oct 90 18:07 GMT
From: "Disini SW, Emmanuel Disini,PRT" <[e-mail]>
Subject: world-wide map of PBBSes
To: [e-mail]

is there a map somewhere of all PBBSes worlwide?  I'd like to know how it is
that packet radio messages get forwarded say, from Texas to Manila, or from
Australia to Poland, and how many "hops" it takes to go from point A to point B
<and what the links are between both points - VHF, HF, microwave?>.

joel disini


------------------------------

End of Packet-Radio Digest
******************************
Date: Tue,  9 Oct 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #165
To: packet-radio


Packet-Radio Digest         Tue,  9 Oct 90       Volume 90 : Issue 165

Today's Topics:
                ADPCM
              G8BPQ questions  (2 msgs)
               KISS ROMs for ASHBY TNC
        Looking for packet sites running TCP/IP (KA9Q)
            Packet freqs in DC/nearby VA?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 8 Oct 90 17:20:13 GMT
From: usc!wuarchive!zaphod.mps.ohio-state.edu!mips!twg.com![e-mail]  (Hemanth S. Ravi)
Subject: ADPCM
To: [e-mail]

I am looking for some information on chips that do ADPCM (Adaptive differential
Pulse Coded Modulation). I would appreciate info on any such chips in the
market or pointers to where I could find such information.

------------------------------

Date: Mon, 8 Oct 90 11:40:39 PDT
From: [e-mail] (Brian Kantor)
Subject: G8BPQ questions
To: [e-mail], [e-mail]

One of the local clubs asked me about the G8BPQ switch software, and I
don't know the answers:

1. What is the COMBIOS interface referred to in the documentation, and
how is it used?

2. Can G8BPQ be used as a multi-tasking executive for simple programs?
(presumably that don't do screen access - like a C program that only
uses stdio.)

3. What kind of throughput can you expect on various types of
machines?

In particular, the proposed configuration is to run a 10MHz XT with 4
or 5 radio channels attached to it.  Two would be 9600 bps, one 4800,
one 1200 bps.  Probably KISS TNCs will be used, but maybe DRSI PCPA
boards.  There's some real concern that the XT might not have the
horsepower to handle three medium-speed ports and one low-speed.

What if we added the fifth port with 56kb?

(This will be a standalone packet switch - no BBS on the system.  It
seems to me that if you wanted to have the thing do both switch and BBS
you'd be better off running something like MSYS.)

Any comments?
        - Brian

------------------------------

Date: Mon, 08 Oct 90 15:20:10 MDT
From: Bdale Garbee <[e-mail]>
Subject: G8BPQ questions
To: [e-mail], [e-mail]

> One of the local clubs asked me about the G8BPQ switch software, and I
> don't know the answers:

Nor do I...

> In particular, the proposed configuration is to run a 10MHz XT with 4
> or 5 radio channels attached to it.  Two would be 9600 bps, one 4800,
> one 1200 bps.  Probably KISS TNCs will be used, but maybe DRSI PCPA
> boards.  There's some real concern that the XT might not have the
> horsepower to handle three medium-speed ports and one low-speed.

> What if we added the fifth port with 56kb?

If you put a 56kb modem on a DRSI PCPA card, any time you are transmitting or
receiving a frame, the machine is flat-lined.  All interrupts turned off.  Even
with 16550's on the asynch ports, my 10Mhz V20 clone at home loses characters
on the two 1200-baud serial ports whenever a packet is sent or received.  This
is not a very acceptable situation.

If you use something like the Grace PackeTen card to provide the radio
interfaces, all of the problems go away.  If you use one of their standalone
cards, you're even better off for a site... you'll get all the NET/Wrong
compatibility anyone could possibly want... but nothing is free.

Bdale

------------------------------

Date: 7 Oct 90 20:24:44 GMT
From: swlabs![e-mail]  (Jack Bonn)
Subject: KISS ROMs for ASHBY TNC
To: [e-mail]

In article <[e-mail]> [e-mail] (John H. Klingelhoeffer) writes:
>
>Does anyone have information on whether there was ever a KISS ROM
>set for the Ashby board, and if so, is there anywhere that I can
>get a clone of it, or the hex listing to blow into a PROM ?

The documentation for the KISS proms indicates that Mike Bruski,
AJ9X is associated with a dedicated PROM for this.  I would check
the callbook for his snail-mail address.

-Jack
--
Jack Bonn, KC1UH, <> Software Labs, Ltd, Box 451, Easton CT  06612
uunet!swlabs!jack (UUCP)
jack@kc1uh        (TCP/IP)
kc1uh@wb1cqo      (AX.25)

------------------------------

Date: 8 Oct 90 15:31:42 GMT
From: mvac23![e-mail]  (Thomas Lapp)
Subject: Looking for packet sites running TCP/IP (KA9Q)
To: [e-mail]

A friend of mine is looking for a site to communicate with.  He just
got the KA9Q software to run TCP/IP on his TNC and is looking for
someone else he can hit in order to test with.

He is located in this area, and would be able to hit someone in the
Philadelphia, PA, Baltimore, MD eastern MD and lower New Jersey area.
Apparently (I'm not versed very well on this stuff -- forgive me)
they run on 2 meters on 146.65 Meg.

Any contacts would be appreciated.
             - tom

--
internet     : mvac23![e-mail]  or  [e-mail] (home)
         : [e-mail] (work)
uucp         : {ucbvax,mcvax,psuvax1,uunet}!udel!mvac23!thomas
Location     : Newark, DE, USA
Quote        : I know how to spell banana, I just don't know when to stop

--
The UUCP Mailer

------------------------------

Date: 8 Oct 90 13:12:11 GMT
From: umigw!rsmas![e-mail]
Subject: Packet freqs in DC/nearby VA?
To: [e-mail]

I may be relocating to the DC area & am using a crystal rig for packet.  What
frequencies are used for packet in the DC-nearby VA area?

73 de Mark

--
C. Mark Eakin
Internet: [e-mail]
Amateur Radio: N4SYK      Packet Radio: [e-mail]
USnail: Univ. of Miami, RSMAS-BLR, 4600 Rickenbacker Cswy. Miami, FL 33149-1098

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed, 10 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #166
To: packet-radio


Packet-Radio Digest         Wed, 10 Oct 90       Volume 90 : Issue 166

Today's Topics:
              2400 baud packet modems..?
          Any comments on L.L. Grace DSP-12?
          Data Engine & reverse forwarding (3 msgs)
               G8BPQ questions (2 msgs)
          Networking Conference Proceedings
             pac-radio magazines
         PACKET QUESTIONS BY NOVICE (2 msgs)
         Setting up a CP/M station?? (2 msgs)
            SLIP, KA9Q, UNIX and Me! Ack!

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 8 Oct 90 19:26:23 GMT
From: uc!nachos.SSESCO.com![e-mail]  (Chris Elmquist)
Subject: 2400 baud packet modems..?
To: [e-mail]

Does anyone know what modulation scheme modems like the Kantronics
or DRSI 2400 baud packet units use?  Are these v.26 modems? or
Bell 201? or anything similar?  Are the DRSI and Kantronics units
compatible?  Inquiring minds want to know--

------------------------------

Date: 8 Oct 90 21:41:42 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: Any comments on L.L. Grace DSP-12?
To: [e-mail]

>BTW, anyone have a number for the *other* Grace Communications?  I am
>trying to get a line on the PackeTen 68302-based board (and truth be
>told, I'd a lot rather hack a 68xxx machine than an 80x86-flavoured
>one, any day.  The learning curve will be a lot less steep for me.)

Here's what I have handy at work, that is publicly printable.

Name:           Grace Communications
Work Address:   Grace Communications
        623 Palace Street
        Aurora, IL  60506
Phone:          [phone]
Remarks:        Don Lemley is contact

Name:           Don Lemley N4PCR
Email:          [e-mail]
CIS:            73230,310

I know that ldhmi is reachable via uunet, and via hp-col.  For email, if
nothing else works, try [e-mail]

Bdale

------------------------------

Date: 8 Oct 90 22:09:29 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: Data Engine & reverse forwarding
To: [e-mail]

>Here is a tip for anyone using a Kantronics Data Engine with firmware 1.0.

If you haven't already, give a call to Kantronics and let Mike Huslig know
about this...

Bdale, N3EUA

------------------------------

Date: 9 Oct 90 03:53:14 GMT
From: maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]  (Steve Schallehn)
Subject: Data Engine & reverse forwarding
To: [e-mail]

In rec.ham-radio.packet you write:

>Here is a tip for anyone using a Kantronics Data Engine with firmware 1.0.
>I could not get it to reverse forward to an MSYS bbs until I realized that
>the SID, [DE1.0], is not a valid SID.  I changed the firmware so that it
>appears as [DE-H$].  Reverse forwarding works fine now.  This data is at
>location $C2FD in the EPROM.

I have had similar problems with my KAM's rom, version 3.0   The low tech
solution to the problem was to set the PTEXT (The personalized message
on your PBBS) to [KAM-3.00-H$] which took care of the problem.

I spoke to Kantronics and they said that older versions of the MYSYS and RLI
BBS's didn't need the $, thefore the EPROM wasn't burned that way.

-Steve Schallehn, KB0AGD
 Kansas State University ARC

------------------------------

Date: 9 Oct 90 22:42:00 GMT
From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Data Engine & reverse forwarding
To: [e-mail]

Does anyone know yet if the Kantronics Data Engine Developers Reference is
available yet.

I know I could call them, but I don't want to do it too regularly as it is
not an 800 number (if you know one, that would be nice, too).

When I did talk to them, they did not tell me when it would be available,
nor would say they could tell me when it would be.

In fact, they suggested I order one through a dealer so it would be on back
order.  No thanks, the dealers don't need a cash loan from me.

For what I want the DE for, the developers reference would be THE
documentation, and I always get the documentation for what I buy.

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

Date: Tue, 9 Oct 90 09:58:01 EDT
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: G8BPQ questions
To: [e-mail]

>One of the local clubs asked me about the G8BPQ switch software, and I
>don't know the answers:
>
>1. What is the COMBIOS interface referred to in the documentation, and
>how is it used?

It's a TSR which replaces the INT14 comm port handler in the BIOS, and
provides various extended services.  Other variations on this theme
include MBBIOS and DVIOCOM.  The G8BPQ code is an enhanced COMBIOS
interface which provides TNC emulation, NET/ROM compatibility, etc.
They all grab the hardware ports, and provide services via INT14 calls.

>2. Can G8BPQ be used as a multi-tasking executive for simple programs?
>(presumably that don't do screen access - like a C program that only
>uses stdio.)

Yes and no.  You can run multiple programs that use the COMBIOS interface
on top of G8BPQ, but you need DESQview or equivalent to do the actual
multitasking.

>3. What kind of throughput can you expect on various types of
>machines?

That's a toughie... I haven't seen much hard performance data, but maybe
some others who are using BPQ in multiport switches will chime in.  I'm
running it as a BBS access system with 2 2400 bps and one 9600 bps async
ports, along with NET and other stuff under DV, but that's on a 16 MHz
386 machine.  My guess is that BPQ would be hard-pressed to handle the
situation you describe on an XT, even without a 56 kbs port.

>In particular, the proposed configuration is to run a 10MHz XT with 4
>or 5 radio channels attached to it.  Two would be 9600 bps, one 4800,
>one 1200 bps.  Probably KISS TNCs will be used, but maybe DRSI PCPA
>boards.  There's some real concern that the XT might not have the
>horsepower to handle three medium-speed ports and one low-speed.
>
>What if we added the fifth port with 56kb?

As I said above, this concern is well-founded.  My advice would be to run
NOS instead of BPQ - then the box will be a thinly-disguised IP switch :-)
I'm running NOS on an 8 MHz XT with two 9600 bps async ports and one
DMA'ed 56 kbs sync port, and it works fine.  If more horsepower is needed,
12 MHz AT motherboards are only $100 or so these days.

>- Brian

Barry VE3JF

------------------------------

Date: Tue, 09 Oct 90 07:10:13 PDT
From: "Roy Engehausen" <[e-mail]>
Subject: G8BPQ questions
To: [e-mail]

Some answers:

1. The COMBIOS interface is an extension to INT 14 for COM ports.
Jeff, WA7MBL, started it but other add-ons were done by myself.  G8BPQ
supports the full range and a few others.  The added functions are
things like send-break, send-block, receive-block.  See the INT14.DOC
file that comes with the code.

2.  G8BPQ has no external multitasking ability.  It is Terminate-
and-Stay-Resident (TSR) program.  You run whatever you like on top.

3.  I am not sure on throughput.  I advocate the use of DRSI cards
since a dropped character is caught by the CRC and KISS mode has
no such safeguard.

The AA4RE BBS program runs just fine on top of the G8BPQ switch.

Roy, AA4RE

------------------------------

Date: 8 Oct 90 21:44:18 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: Networking Conference Proceedings
To: [e-mail]

>Is it possible to purchase the conference proceedings from the various
>Amateur Radio Networking Conferences?  If so, who do I contact?

For the ARRL conference, contacting the ARRL directly is known to work:

Name:           ARRL
Work Phone:     [phone]
FAX Phone:      [phone]

Bdale

------------------------------

Date: 8 Oct 90 21:45:37 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: pac-radio magazines
To: [e-mail]

>can anyone suggest a good magazine for packet-radio?

The best general source of packet radio info today, in my less-than-humble
opinion, is the TAPR newsletter PSR.  Join TAPR and you'll get it, quarterly.
The membership fee was $15 the last time I asked.

Name:           TAPR
Work Address:   TAPR
        PO Box 12925
        Tucson, AZ  85732
Work Phone:     [phone]

Bdale
u can't find it
anywhere else, try col.hp.com, as ~ftp/ka9q/890421.1/tnc_ash.arc.

You're welcome!

This is *not* the same thing as the HAPN board, which is supported by an
internal driver in NET/NOS.

Bdale

------------------------------

Date: 8 Oct 90 22:08:35 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: PACKET QUESTIONS BY NOVICE
To: [e-mail]

>How can you implement ftp or telnet over packet tcp/ip (even on
>high speed lines) if everytime it goes from one machine to another
>the person who runs that station has to inspect it for 'dirty
>words' or commercial transmissions.  Telnet would run REALLY
>slow if every packet has to be intercepted by the station
>operator for a "bad word check".

This is only important if there is IP-level connectivity between an amateur
radio and non-amateur-radio station.  If two amateur stations are going at it,
the sender is by definition responsible for the content of his transmissions.

The rule is that the person who first introduces the traffic onto the amateur
packet network is responsible for the content.  This is the originator if it
is a direct ham station, or the operator of the gateway if the traffic is
from elsewhere.

>Is it possible to run mobile packet stations from cars or whatever
>over GRAPES/TCP/IP setup while the cars are moving.  Sort of a roving
>TCP/IP network.  I think it would be cool.  Run those systems on
>portable pcs or regular pcs running off of power inverters.

In theory, this is quite possible.  In practice, I haven't talked to anyone
who has gone mobile with the DSY modems...

Bdale

------------------------------

Date: 9 Oct 90 22:36:00 GMT
From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: PACKET QUESTIONS BY NOVICE
To: [e-mail]

> >Is it possible to run mobile packet stations from cars or whatever
> >over GRAPES/TCP/IP setup while the cars are moving.  Sort of a roving
> >TCP/IP network.  I think it would be cool.  Run those systems on
> >portable pcs or regular pcs running off of power inverters.
>
> In theory, this is quite possible.  In practice, I haven't talked to anyone
> who has gone mobile with the DSY modems...

This could be particularly valuable during emergencies.

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

Date: 9 Oct 90 13:03:26 GMT
From: usc!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!levels![e-mail]
Subject: Setting up a CP/M station??
To: [e-mail]

Hello all packeteers. . .

I don't have a license for radio, but have studied for one in 1988.
Never did go thru with it.  Now I'm here in OZ and have a few computers
laying around (Kaypros) and was thinking it would be nice to piece together
something like a packet station.  I have the software for the old Xerox 820
type station, (W0RLI ???) and was wondering about its limitations & what
it can do. I know I need a Radio & a TNC, but are there other hidden costs?
How much time does it take to keep a station up? ( My lifetime? )

Any repliers welcome. . .

Ronn

------------------------------

Date: 9 Oct 90 17:22:15 GMT
From: uc!shamash![e-mail]  (Jeff Comstock)
Subject: Setting up a CP/M station??
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>Hello all packeteers. . .
>
>something like a packet station.  I have the software for the old Xerox 820
>type station, (W0RLI ???) and was wondering about its limitations & what
>it can do. I know I need a Radio & a TNC, but are there other hidden costs?

Sounds to me like you are set to go.  You might want to investigate the
cost of putting up an antenna.  Coax cable and the actual antenna might
cost you some money, but maybe you can find a real bargain for this
stuff.  In case you didnt know, TNC's are designed to have a terminal
connected to them.  If you have a term program, that is all you need
to command the tnc and chat with your freinds.  Today you can even
get TNC's with mini-bbs's built into them.   If you can't get a terminal
program for your Kaypro, write one.  You can command a TNC with
a very small program.  I don't have any knowledge of the RLI software
you have.

Another thing is that there is alot of traffic
on the channels these days.  You might want a printer to keep a record
of important messages and bulletins.

>How much time does it take to keep a station up? ( My lifetime? )

If you run a TNC with a built in mailbox, you dont have to do anything.
Just fire it up and let it sit there.  When you want to send a message
or read your mail, turn on your computer and see what is in the TNC with
your term program. You can then turn off your computer when it is done.

Have fun,

Jeff

------------------------------

Date: 9 Oct 90 21:36:41 GMT
From: bacchus.pa.dec.com!shlump.nac.dec.com!wjg.enet.dec.com![e-mail]  (W. John Guineau)
Subject: SLIP, KA9Q, UNIX and Me! Ack!
To: [e-mail]

In article <[e-mail]>,
[e-mail] (Ralph Seguin) writes:
|> From: [e-mail] (Ralph Seguin)
|> Newsgroups:
comp.sys.amiga,comp.sys.amiga.tech,comp.unix.questions,comp.protocols.tc
cp-ip,comp.unix.wizards,rec.ham-radio.packet
|> Subject: SLIP, KA9Q, UNIX and Me! Ack!
|>
|> Hi.  Sorry for the repost, but I am in desperate need of help here.
|> I have just purchased a Plexus P/35 UNIX box (Sys V, Rel 2).  It
|> has an 8 serial port board controlled by an "Intelligent Communications
|> Processor".  It looks as though I am not going to be able to afford
|> an ethernet board for this thing, so I want to run SLIP on the serial
|> port board instead (yeah, I know it's slow 8(  My objective is to
|> network this machine with my Amiga.
|> Anyhow, here's YASODQ (Yet Another Series of Dumb Questions):
|>
|> 1.  Where can I get PD (or damned cheap) TCP/IP software implementations
|>     that will run on this box and allow me to run SLIP over the serial
ports?
|>
|> 2.  Where can I get KA9Q for UNIX, and will it work on this box?
|>
|> 3.  Has anybody got an ethernet board for one of these boxes that they are
|>     willing to part with for a mere pittance?
|>
|> 4.  Has anybody been able to get DNET to run under System V?  What about
|>     rel 2?
|>
|> 5.  Are there any other link protocols like DNET available for both the
Amiga
|>     and for UNIX?
|>
|> 6.  Is there any hope for me at all?  8-)  8-(
|>
|>

I've run the KA9Q package on my amiga and linked to a DEC MicroVAX Ii running
Ultrix using SLIP.

Worked very well. I had to add SLIP into the kernal to make it work (just
tweek machine configuration file and rebuild the kernel)


|>                      Thanks, Ralph
|>
|>
|> [e-mail]       [e-mail]
|> [e-mail]     [e-mail]
|> [e-mail]    [e-mail]
|>
|> Ralph Seguin         | "You mean THE Zaphod Beeblebrox?"
|> 536 South Forest     |
|> Apartment 915                | "No.  Haven't you heard, I come in six packs!"
|> Ann Arbor, MI 48104  |
|> [phone]
|>

--
W. John Guineau                         [e-mail]
Digital Equipment Corporation
Marlboro MA. 01752

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu, 11 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #167
To: packet-radio


Packet-Radio Digest         Thu, 11 Oct 90       Volume 90 : Issue 167

Today's Topics:
          Announcement: The Ottawa PI Board
          Any comments on L.L. Grace DSP-12?
         Distributing newsgroups on AM radio?
               High-speed KISS
               KISS PROMS for Ashby TNC
                  NET vs NOS
          Networking Conference Proceedings (2 msgs)
             pac-radio magazines
              PACKET QUESTIONS BY NOVICE

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: Wed, 10 Oct 90 13:59:40 EDT
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: Announcement: The Ottawa PI Board
To: [e-mail], [e-mail]

The WA4DSY 56 kbs modem has been available for about three years, and yet
only a small number of them seem to be actually in use.  One thing that has
held it back is that it is not a "plug 'n play" solution - you have to build
it up from a kit, and also provide external up- and down-converters between
28 MHz and the band(s) you want to use.  This is really not very difficult,
but there is another stumbling block: there has been no suitable hardware
available for interfacing the modem to a PC/XT/AT.  Most DSY users have
hacked up a TNC-2 and installed a special version of KISS which allows the
HDLC port to talk to the modem at 56 kbs, but the best the RS-232 port can do
is 19.2 kbps (and some have even found it necessary to drop down to 9600
bps), so the capabilities of the modem are wasted.  The DRSI card has also
been used with the modem, in which case you can actually run at the full 56
kbs, but only by disabling interrupts and using programmed I/O to handle the
56 kbs packets.  This means you can't service any other ports at the same
time, which is not too useful for most situations.

Now there's a better solution available.  The members of the Packet Working
Group of the Ottawa Amateur Radio Club have been enthusiastic proponents of
the DSY modem since we first put some on the air back in 1988.  In January of
this year, we installed the first 56 kbs full-duplex repeater.  As part of
our group's ongoing commitment to promote the use of this modem in packet
networking, we have developed an I/O board which overcomes the bottleneck
mentioned above.  Dubbed the PI board, it uses the standard ISA bus interface
and DMA to provide full 56 kbs throughput, while still allowing other low-
and medium-speed async ports to function without dropping characters.  Used
with NOS, this board has achieved FTP transfer rates of up to 5600 bytes/s
over a 56 kbs half-duplex RF link.  The board also includes a non-DMA
low-speed port.  A working prototype was demonstrated at the recent Computer
Networking Conference in London.

Lest I anger the net-gods, I hasten to add that the OARC is a non-profit
organization, and that any proceeds from the sale of boards will be applied
to improving the Amateur packet network.  Nevertheless, this is all the sales
pitch I plan to do via the Internet mailing lists.  If you would like further
details on the PI board and how to get it, please send *mail* to me:

  [e-mail]

Barry VE3JF

------------------------------

Date: 3 Oct 90 20:00:39 GMT
From: attcan!lsuc!atha!aupair.cs.athabascau.ca![e-mail]  (Ross Alexander)
Subject: Any comments on L.L. Grace DSP-12?
To: [e-mail]

[e-mail] (Robert McGwier) writes:
>after all.  The modems do not exist and the box has not passed or even been
>submitted for FCC testing.  I believe what he is doing in the advertisements

I just spoke with him (Brooks Vantel, KB2CST, [phone]) and he
confirmed that the DSP-12 hadn't made it through FCC type approval
yet.  And yes, he was taking orders and had a waiting list going.
Hmmm.  The thing that worried me was that the programmer's guide was
the *last* thing on his to-do list - I won't make a buy descision
until I've seen that.  He did say, though, that the firmware sources
would be available through a non-disclosure agreement.

Disclaimer:  your mileage may vary, & c. & c.  I suggest you phone
KB2CST if you want "horse's mouth".

BTW, anyone have a number for the *other* Grace Communications?  I am
trying to get a line on the PackeTen 68302-based board (and truth be
told, I'd a lot rather hack a 68xxx machine than an 80x86-flavoured
one, any day.  The learning curve will be a lot less steep for me.)

--
--
Ross Alexander    [e-mail]    [phone]    ve6pdq

------------------------------

Date: 3 Oct 90 19:21:27 GMT
From: attcan!lsuc!atha!aupair.cs.athabascau.ca![e-mail]  (Lyndon Nerenberg)
Subject: Distributing newsgroups on AM radio?
To: [e-mail]

[e-mail] (Lauren Weinstein) writes:

>And indeed, just because an experiment ends doesn't mean it wasn't
>worthwhile.  I would not call the experiment a failure.  To learn
>that a particular technology is not suitable for netnews is
>meaningful information.  While it would have been interesting if the
>results had been "positive", negative outcomes are useful too.

I agree. Conducting this experiment (no doubt) generated a lot of useful
data and experience. What bothers me is that nothing appears to have ever
been published about the experiment and its outcome. Surely this information
should be shared with a wide audience.

If there have been paper published about this, I would appreciate any and
all references. Thanks.

--
    Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
    {alberta,cbmvax,mips}!atha!lyndon || [e-mail]

      The only thing open about OSF is their mouth.  --Chuck Musciano

------------------------------

Date: 3 Oct 90 20:01:54 GMT
From: mcsun!ukc!slxsys!qtnet![e-mail]  (Nick Lawes)
Subject: High-speed KISS
To: [e-mail]

Does anyone out there know if there's a version of the KISS code code
that will cope with 9600 baud (from a G3RUH modem). The standalone
versions that I currently have send a lot of rubbish data to NET. The
version built into the 1.1.7 ROM seems to function okay, but requires
32K RAM in the TNC.

Source would be nice if there's any available, but binary or intel hex
files are fine...

Unfortunately I have no FTP facilities, so pointers to such sites are
of little use... uucp, e-mail, info-servers etc are all fine...

Thanks in advance,

    Nick
--
[    Nick Lawes, Systems Development    | voice:       [phone]    ]
[ Quotron Information Business Limited. | email: ..!ukc!slxsys!qtnet!nick ]
[ 12 Norwich Street, London.  EC4a 1BP  | ham  :        G8ZHR @ GB3XP     ]

------------------------------

Date: 8 Oct 90 13:49:30 GMT
From: njin!uupsi!uhasun![e-mail]  (Jon Bloom)
Subject: KISS PROMS for Ashby TNC
To: [e-mail]

In article <[e-mail]>, [e-mail] (John H. Klingelhoeffer) writes:
> Does anyone have information on whether there was ever a KISS ROM
> set for the Ashby board, and if so, is there anywhere that I can
> get a clone of it, or the hex listing to blow into a PROM ?

Actually, the Ashby board is a clone of the Vancouver board but
using some programmable logic to simplify things.  The KISS firmware
for the Vancouver board should run on the Ashby board as well.  It's
probably available on thumper.bellcore.com or col.hp.com via FTP.

--
Jon Bloom, KE3Z                              | American Radio Relay League
Internet: [e-mail]         |
Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

------------------------------

Date: 10 Oct 90 16:46:52 GMT
From: ogicse!littlei!foobar![e-mail]  (Jim Garver)
Subject: NET vs NOS
To: [e-mail]

After I got set up with NET, now there's NOS and some other TCP/IP things
too.  What's the difference here?  Is it worth it for me to change again
since I only use NET for ftp currently.  I like YAPP much better for AX25
stuff.  NET seems to have all kinds of horrid delays built in that I can't
find the params for.  I have been working with an MSYS station that recently
upgraded his version and that fixed a few things, but many remain.

It would be nice if someone in the know could publish a feature list for
the various host programs flying around these days.

Kinda half way there,

--
Jim Garver     Intel Corp.   <tektronix!psueea | uunet!littlei>!foobar!jim
 WA7LDV     Hillsboro, Oregon              jim@foobar<.hf.intel.com|.uucp>

------------------------------

Date: 9 Oct 90 12:41:13 GMT
From: njin!uupsi!uhasun![e-mail]  (Jon Bloom)
Subject: Networking Conference Proceedings
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bdale Garbee) writes:
> Name:           ARRL
> Work Phone:     [phone]
> FAX Phone:      [phone]
               ^
               |
Correction: FAX   [phone]


--
Jon Bloom, KE3Z                              | American Radio Relay League
Internet: [e-mail]         |
Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

------------------------------

Date: 5 Oct 90 13:10:28 GMT
From: njin!uupsi!uhasun![e-mail]  (Jon Bloom)
Subject: Networking Conference Proceedings
To: [e-mail]

In article <chk.654971551@earth>, [e-mail] (C. Harald Koch) writes:
> Is it possible to purchase the conference proceedings from the various
> Amateur Radio Networking Conferences?  If so, who do I contact?
>
>       Thanks!

Yes, ARRL has all 9 of them available.  The first four are in a single
volume; the remaining five are in individual volumes.  Contact ARRL HQ
for details (203-666-1541).

--
Jon Bloom, KE3Z                              | American Radio Relay League
Internet: [e-mail]         |
Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

------------------------------

Date: 5 Oct 90 16:53:18 GMT
From: uc!shamash![e-mail]  (Jeff Comstock)
Subject: pac-radio magazines
To: [e-mail]

In article <[e-mail]> [e-mail] ("Disini SW, Emmanuel Disini,PRT") writes:
>can anyone suggest a good magazine for packet-radio?
>thanks,
>joel disini
>

I'm afraid this is as good as it gets [rec.ham-radio.packet] :-) . If
you are interested in TCP/IP, maybe you should subscribe to the
tcp-group mailing list.  I think that a months worth of messages from
it could be considered 'kind of like a small magazine.'

Jeff
NR0D

------------------------------

Date: 8 Oct 90 19:44:55 GMT
From: [e-mail]  (Patricia Winter)
Subject: PACKET QUESTIONS BY NOVICE
To: [e-mail]

In article <[e-mail]> [e-mail] (Jim Burnes) writes:
>
>Is it possible to run mobile packet stations from cars or whatever
>over GRAPES/TCP/IP setup while the cars are moving.  Sort of a roving
>TCP/IP network.  I think it would be cool.  Run those systems on
>portable pcs or regular pcs running off of power inverters.

If you're asking particularly about 56K operations, I haven't tried
that. But I did some mobile TCP/IP (and AX.25) once while Phil and I
were driving around the San Francisco Bay Area. While he drove, I
played with a portable packet system we'd put together. It consisted of
his laptop computer (running off its own batteries), a handheld radio
(ditto), and I think my TNC-2 running off the car. The antenna was a
5/8-wave mag-mount on the roof.

I pinged a few TCP/IP base stations while we wandered around. I didn't
bother trying an SMTP or telnet, but there's no reason it shouldn't
have worked. I just didn't have any need to try it.


Patty
--
*****************************************************************************
Patty Winter N6BIS                        INTERNET: [e-mail]
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
*****************************************************************************

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri, 12 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #168
To: packet-radio


Packet-Radio Digest         Fri, 12 Oct 90       Volume 90 : Issue 168

Today's Topics:
         NOS and Conventional LandLine Link? (2 msgs)
              PACKET QUESTIONS BY NOVICE
           REQUEST FOR TEST EQUIPMENT TECH MANUALS

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: Thu, 11 Oct 90 13:34:55 GMT
From: [e-mail] (WHOI Port Office)
Subject: NOS and Conventional LandLine Link?
To: [e-mail]

Greetings!  I need source code to be able to use NOS on a PC and have
telephone access to it using QMODEM/PROCOMM/ETC.  Also I am running
Ethernet to a Novell File Server as well as to Internet.  I want to
be WA1QWA.AMPR.ORG to my KISS link and PORTCOMM.WHOI.EDU to my ethernet.
Can the mailer be set up for this?  I define each hostname before attaching
but I still have last defined problems.
      Tom Clark in his DV setup initializes his ethernet card inside the
DV window, but I would like to already be linked my Novell File Server
before starting DV.  Any suggestions would be appreciated!

Barry Hamilton WA1QWA
(508)-457-2000 EXT 3332
[e-mail]
Woods Hole Oceanographic Institute
Woods Hole, MA 02543
--------------------

------------------------------

Date: Thu, 11 Oct 90 13:34:55 GMT
From: [e-mail] (WHOI Port Office)
Subject: NOS and Conventional LandLine Link?
To: [e-mail]

Greetings!  I need source code to be able to use NOS on a PC and have
telephone access to it using QMODEM/PROCOMM/ETC.  Also I am running
Ethernet to a Novell File Server as well as to Internet.  I want to
be WA1QWA.AMPR.ORG to my KISS link and PORTCOMM.WHOI.EDU to my ethernet.
Can the mailer be set up for this?  I define each hostname before attaching
but I still have last defined problems.
      Tom Clark in his DV setup initializes his ethernet card inside the
DV window, but I would like to already be linked my Novell File Server
before starting DV.  Any suggestions would be appreciated!

Barry Hamilton WA1QWA
(508)-457-2000 EXT 3332
[e-mail]
Woods Hole Oceanographic Institute
Woods Hole, MA 02543
--------------------

------------------------------

Date: 9 Oct 90 22:49:38 GMT
From: sdd.hp.com!samsung!emory!emcard!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: PACKET QUESTIONS BY NOVICE
To: [e-mail]

In article <[e-mail]> [e-mail] (Bdale Garbee) writes:
> <lost header>
>>Is it possible to run mobile packet stations from cars or whatever
>>over GRAPES/TCP/IP setup while the cars are moving.  Sort of a roving
>>TCP/IP network.  I think it would be cool.  Run those systems on
>>portable pcs or regular pcs running off of power inverters.
>
>In theory, this is quite possible.  In practice, I haven't talked to anyone
>who has gone mobile with the DSY modems...

Dale did the original experiments with the modems mobile. He sent digital
voice, not packet, from base to car in motion. It degraded very gracefully
under severe multipath. We have one user here who runs a portable mailbox
in his car all the time, but that's at 1200 baud.

Gary KE4ZV

------------------------------

Date: Thu, 11 Oct 90 09:51:21 EDT
From: [e-mail] (John H. Klingelhoeffer)
Subject: REQUEST FOR TEST EQUIPMENT TECH MANUALS
To: [e-mail]

Subject: REQUEST FOR INFORMATION ON LAB TEST EQUIPMENT

I've been given some partially working lab test equipment that I would
like to use around the bench at home, but have no manuals which would
help a great deal in repair.

If you have manuals for one or more of these pieces of equipment, I'd
be more than happy to either pay for the copying at your location or
for the shipping to get them to here for copy and back to you.

Here is the list:

O'scope, Tektronix model 564B storage scope
    with : 3A1 Dual Trace Amp Plug In
           3B3 Time Base
           3A7 Differential Comparator

O'scope, Hewlett-Packard model HP180D
    with : 1805A 100 Mhz Dual Channel Vertical Amp
           1824A Time base and Sweep Expander

EiP Autohet Counter, Model 351C
    (has panel markings to go to 18 GHz, but someone has robbed
     the first mixer and also the basic counter board, which can
     probably be rebuilt)

Universal Counter, Hewlett-Packard HP5328A with Digital Voltmeter
    and "Universal Module" (what a great name!)


Mail, email, phone or fax reply would be appreciated.  I'd like to
get the stuff working again for ham radio use.  Thanks.

John, WB4LNM...

+-----------------------------------------+--------------------------------+
|                                         | The ORIGINAL ACC, from ARPANET |
| John H. Klingelhoeffer                  |  days, not the imposter that   |
| Director, Government Special Operations |   makes repeater controllers   |
| Advanced Computer Communications        +--------------------------------+
| Systems Division                        | Voice: 301-290-8100            |
| 10220 Old Columbia Road                 | Fax:   [phone]            |
| Columbia, Maryland  USA   21046-1725    | Radio: 224.56/147.135 WB4LNM   |
|                                         | Internet: [e-mail]   |
+-----------------------------------------+--------------------------------+

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat, 13 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #169
To: packet-radio


Packet-Radio Digest         Sat, 13 Oct 90       Volume 90 : Issue 169

Today's Topics:
               2400 baud packet modems
        Packet modifications on YAESU FT-212RH
             Setting up a CP/M station??

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 12 Oct 90 15:07:03 GMT
From: uc!nachos.SSESCO.com![e-mail]  (Chris Elmquist)
Subject: 2400 baud packet modems
To: [e-mail]

I posted this once before but didn't get any reply...so I'll try again:

Does anyone know the modulation scheme used in the Kantronics, DRSI and
MFJ 2400 baud packet modems?  Are these something like Bell 201, v.26,
or other QPSK scheme... or are they some agreed apon proprietary method.
I heard rumors of 1600 Hz carrier which would make it much different
than Bell 201 or v.26.

Any ideas?

Thanks.  Chris  N0JCF

--
Chris Elmquist, N0JCF
[e-mail]

------------------------------

Date: 12 Oct 90 20:28:42 GMT
From: bacchus.pa.dec.com!rust.zso.dec.com!shlump.nac.dec.com!ryn.esg.dec.com!atccad.enet.dec.com![e-mail]
Subject: Packet modifications on YAESU FT-212RH
To: [e-mail]

I just bought a YAESU FT-212RH 2m radio and a AEA PK232 multi-mode
controller to build my
packet station around.  The YAESU manual says to "open" a solder bridge
on the main circuit
board to remove the "tone burst" function.  Has anyone already made this
change and been
successful with the PK232 ?  Will I be missing something if I can't do
the "tone burst" ???


                             Thanks,

                              Lee Stogner

                              N4XBD

------------------------------

Date: 12 Oct 90 14:24:19 GMT
From: usc!wuarchive!sdd.hp.com!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!levels![e-mail]
Subject: Setting up a CP/M station??
To: [e-mail]

In article <[e-mail]>, [e-mail] (Jeff Comstock) writes:
> In article <[e-mail]> [e-mail] writes:
>>Hello all packeteers. . .
>>
>> I have the software for the old Xerox 820
>>type station, (W0RLI ???) and was wondering about its limitations & what
>>it can do. I know I need a Radio & a TNC, but are there other hidden costs?
>
> Sounds to me like you are set to go.  You might want to investigate the
> cost of putting up an antenna.  Coax cable and the actual antenna might
> cost you some money, but maybe you can find a real bargain for this
> stuff.  In case you didnt know, TNC's are designed to have a terminal
> connected to them.  If you have a term program, that is all you need
> to command the tnc and chat with your freinds.  Today you can even
> get TNC's with mini-bbs's built into them.   If you can't get a terminal
> program for your Kaypro, write one.  You can command a TNC with
> a very small program.  I don't have any knowledge of the RLI software
> you have.
>

My only problem is getting up to speed with radio, affording a rig, and
worrying about a license.  What is the situation with packet licences?
I heard that shortly after I left the US there had been a new class allowed
for digital and computer types which didn't require Morse code.  Is this
correct, and how about Australia?

> Another thing is that there is alot of traffic
> on the channels these days.  You might want a printer to keep a record
> of important messages and bulletins.
>
I'm not sure if the traffic density in Adelaide is anywhere near that of CAL
or parts of the US.  I'm sure it's a magnitude lower considering population
density alone!  That's why I would like to get this going.  Phone costs here
are phenominal to get to your favorite BBS which happens to be on the other
side of the island!

>>How much time does it take to keep a station up? ( My lifetime? )
>
> If you run a TNC with a built in mailbox, you dont have to do anything.
> Just fire it up and let it sit there.  When you want to send a message
> or read your mail, turn on your computer and see what is in the TNC with
> your term program. You can then turn off your computer when it is done.
>
Is it possible to act as a hub for other users?  Sorry if that's a dumb
question. I'd like to have one of my computers doing that kind of thing
while I use the others for cheap networking. I Want to get around the "public"
utilities here; namely the phone company.


> Have fun,
>
> Jeff

I try, Ronn.

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon, 15 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #170
To: packet-radio


Packet-Radio Digest         Mon, 15 Oct 90       Volume 90 : Issue 170

Today's Topics:
             pac-radio magazines
         PACKET TNC CARD FOR MS-DOS MACHINES
            TNC CARDS FOR MS-DOS MACHINES

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 8 Oct 90 18:05:08 GMT
From: [e-mail]  (Mike Chepponis)
Subject: pac-radio magazines
To: [e-mail]

Perhaps the best packet newsletter in the world right now is the NCPA Downlink.
It is published quarterly by the Northern California Packet Association.  Most
of the authors are from Northern California, but the subject content is about
all kinds of packet, and most is not Northern California specific.  Membership
runs on a calendar year basis from April 1st through March 31st.  If you join
now, you will receive the Spring, Summer, and Fall issues immediately, and the
Winter issue when it comes out.

Send $10 to:

    NCPA
    6680B Alhambra Ave. Suite 111
    Martinez, CA 94553

------------------------------

Date: 14 Oct 90 08:02:02 GMT
From: news!cartan!ndmath!nstar!w8grt!f301.n2600.z1.fidonet.org![e-mail]  (Bob M)
Subject: PACKET TNC CARD FOR MS-DOS MACHINES
To: [e-mail]

Hi Bob
A compnay known as Digital Radi systems (DRSI) makes a half length
card that comes in three types.  All have various options and go
for between $90.00 to $150.00, these prices are discounted by the
various mail order houses. Where I live,in the New York Metropolitan
area, These boards are very popular with the packet cluster operators.
They are advertised in magazines like QST, 73 and CQ. Hope this
helped you. If you are on packet at all my home station is WB2IBO-4.
This is a packet BBS on Long Island New York.
Gud Lk and CUL 73 Bob McLaughlin, N2IHL.
--- TBBS v2.1/NM
 * Origin: L.I.C. [KinkNet/NCC/FidoNet] 516-481-9256 HST  (2600/301)

--
Bob M - via FidoNet node 1:234/1
UUCP: ...!ncar!asuvax!stjhmc!w8grt!2600!301!Bob.M
INTERNET: [e-mail]

------------------------------

Date: 14 Oct 90 08:02:02 GMT
From: news!cartan!ndmath!nstar!w8grt!f730.n209.z1.fidonet.org![e-mail]  (SHAWN ADAIR)
Subject: TNC CARDS FOR MS-DOS MACHINES
To: [e-mail]

HI!  THERE ARE A NUMBER OF TNC-ON-A-CARD PRODUCTS AVAILABLE.  A COMPANY
CALLED DRSI CARRIES ONE, AS DOES HAL COMMUNICATIONS, AND PAC-COMM.  HERE ARE
THE SUGGESTED RETAIL PRICES AND ADDRESSES OF THE MANUFACTURERS... DRSI PC
PACKET ADAPTER...$140 HAL COMMS RC-2000.......$400 PAC-COM
PC-100...........$100

DIGITAL RADIO SYSTEMS, INC.
2065 RANGE ROAD
CLEARWATER, FL 34625
PHONE [phone]

HAL COMMUNICATIONS
PO BOX 365; 1201 W. KENYON ROAD
URBANA, IL 61801
PHONE [phone]

PAC-COMM PACKET RADIO SYSTEMS
3652 CYPRESS  STREET
TAMPA, FL 33607
PHONE [phone]

GLAD TO BE OF ASSISTANCE & "YOU'RE WELCOME" IN ADVANCE
73'S...KB7AWG...SHAWN

X

--- SLMAIL v1.36M  (#0528)
 * Origin: Shortwave Scanner Infonet 702-368-0846  (1:209/730)

--
SHAWN ADAIR - via FidoNet node 1:234/1
UUCP: ...!ncar!asuvax!stjhmc!w8grt!209!730!SHAWN.ADAIR
INTERNET: [e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue, 16 Oct 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #171
To: packet-radio


Packet-Radio Digest         Tue, 16 Oct 90       Volume 90 : Issue 171

Today's Topics:
               2400 baud packet modems
             tnc card for ms-dos machines

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 15 Oct 90 15:01:34 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: 2400 baud packet modems
To: [e-mail]



------------------------------

Date: Mon, 15 Oct 90 09:22:28 -0700
From: Doug Faunt N6TQS 415-688-8269 <[e-mail]>
Subject: tnc card for ms-dos machines
To: [e-mail]

Has anyone done a comparison of the Paccom, DRSI and HAL boards, and
would be willing to share the information or conclusions?

------------------------------

Date: (null)
From: (null)
The KPC-2400 is based on V26 `B'.  This is QPSK with a difference.
As you may know, QPSK is a two dimensional signal.  Adjacent bits are
modulated (multiplied onto) sin and cos of the same phase respectively.
This means that during each BAUD time (symbol time) TWO bits are
encoded.  You are GUARANTEED a transition happens in at least one
of the I and Q channels each and every baud time.  How?  The symbols
are encoded by means of phase transitions.  If the two dits you are
about to send are 00 then you make a 45 degree phase change.  The entire
table looks like


00          +45 deg
01          + 135 deg
11          +225 deg
10          +315 deg

This allows for an extremely simple decoding algorithm and one that doesn't
even need carrier phase to be recovered to provide nearly `optimal'.

You do a complex differential decoder at this point and recover the phase
CHANGE from one baud time to the next.  That is, if you consider the
low pass version of the complex signal generated by the standard `
multiply the signal in quadrature by your local carrier reference and
then low pass filter' then detection of the phase change can be had
by multplying the signal vector NOW by the complex conjugate of the signal
one baud time ago.  This represents a vector giving you the phase change
from one baud time to the next.  You do a simple algorithm which says
`which quadrant is this vector in' and use the table above to decode into
bits.

V26 (a and b constellatiosns) both use 1800Hz as their carrier.  So far
as I am able to tell, by looking both at the KPC-2400, and the AEA
PK-90 with 2400 bps addon, they all use a standard chip set and almost
all use the SAME chip set.  People continue to forget that radio is NOT
a telephone line.  These chip sets were designed for use in a place where
they were guaranteed by CCITT Fascicle VIII.1 - Rec. V.26 bis that
the carrier would be within 5 Hz of correct.  Therefore there is no NEED
for a PLL to recover phase since the algorithm I have briefly describved
is what is implemented in this chip set.  This is <THE> reason that
HF experiments with the V.26, V.29, etc. chips are ALL doomed to failure.
They all do this differential detection stuff since it provides near
optimal noise performance ON A TELEPHONE LINE.  Frankly, I think this
is one of the WORST things Kantronics has done and the others has blindly
followed in an effort to keep up with the Jones.  I can't wait for to
see how much better V26B performs in an `amateur radio oriented' implementation.

73
Bob

--
____________________________________________________________________________
    My opinions are my own no matter    |       Robert W. McGwier, N4HY
    who I work for! ;-)                 |       CCR, AMSAT, etc.
----------------------------------------------------------------------------

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu, 18 Oct 90 04:30:14 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #172
To: packet-radio


Packet-Radio Digest         Thu, 18 Oct 90       Volume 90 : Issue 172

Today's Topics:
             Mail forwarding help needed
                 Sub

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: Thu, 18 Oct 90 01:53 +0930
From: "Rob Mayfield, ASC" <[e-mail]>
Subject: Mail forwarding help needed
To: [e-mail]

Hello.
My name is Rob Mayfield, VK5ZEU South Australia.

We have started up a tcpip network here, and Im after some help ....

We have an existing AX25 net, running W0RLI bbs and AAR4E? bbs in the area.
Im not that familiar with the why's and wherefore's of our existing system
so if this doesn't sound right, please understand. My work includes
responsibility for a sizable ip network, hence my interest in improving and
streamlinig things by implementing tcpip on packet ....

Our problem is that we (all 2 of us at this stage) need to source some form
of BBS capable of accepting our ip mail via smtp and re route it on the ax25
net (soon to go ROSE i believe) as well as accepting any mail and bulletins
addresses to us and routing them to our machines.
Can this be done with a BBS, and can we include a domain name server ?

I have been told that W0RLI can be set up to do at least part of this but our
problem is that with only 2 of us here, there isnt a large amount of 'local'
expertise to tap for these sort of questions (well .... none actually :-( )

I suppose at this point, the questions are straight forward.

1. Can we do this all from one cpu.
2. If not how many.
3. In area's where ip is more established, what s/w packages are preferred to
   perform these functions ?
4. How many of the above functions do these packages provide?
5. Where can I get hold of these on the Internet ? (is there an up-to-date
   Australian ftp site for this type of software?)

Im running Netmac, and a friend NOS on an IBM clone. I believe the mac
version lags the IBM significantly, so if domain name serving is a function
of the IBM NOS version, we just havent got that far yet .....

Any help would be greatly appreciated. Ive only been on packet for 3 months,
but it seems to me that the locals here aren't really interested in the
advantages of tcpip. (are they mad, or are we ??) They also dont seem to
be terribly interested in supplying more than just an ax25 feed for us.

I may be barking up the wrong tree, but surely gateways exist for these
purposes ?!?!?!

I'm posting this to a number of you that I have found in documentation on
ka9q code, and other area's. I am interested in hearing opinions/suggestions
from all addressee's, so we can make a (hopefully) wise decision based on
a good cross section.
thanks in advance ....

73's .... Rob

+-Rob Mayfield-(VK5ZEU)----------------Australian Submarine Corporation------+
! Internet1 : [e-mail]     Internet2 : [e-mail]  !
! Applelink : AUST0177                 AMPR      : VK5ZEU @ VK5WI.#SA.AUS.OC !
! AMPR-TCPIP: 44.136.171.1             VK5 AMPRIP: Address Coordinator       !
! Priv.Mail : Post Box 46, Henley Beach, South Australia, 5022               !
! Voice (AH): [phone]           Voice (BH): [phone] (ext 7713) !
! Facsimile : [phone]           Telex     : AA186451                  !
+--Views expressed in my correspondence are my own, unless otherwise stated--+

------------------------------

Date: Wed, 17 Oct 90 18:19:07 EDT
From: Gary Perlman <[e-mail]>
Subject: Sub
To: [e-mail]

Please subscribe me to packet-radio.

------------------------------

Date: Wed, 17 Oct 90 15:36:04 EDT
From: Gary Perlman KA1BJX <[e-mail]>
To: [e-mail]

I would like to join the packet radio list.

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri, 19 Oct 90 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #173
To: packet-radio


Packet-Radio Digest         Fri, 19 Oct 90       Volume 90 : Issue 173

Today's Topics:
               Help w/KPC-II EQ command
               High-speed KISS
          Networking Conference Proceedings
        Packet modifications on YAESU FT-212RH
             Phil Karn's address?
                Total turnip.

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 18 Oct 90 14:40:10 GMT
From: hpda!hpcuhb!hpindda![e-mail]  (Gene Marshall)
Subject: Help w/KPC-II EQ command
To: [e-mail]

Hello all,

I was wondering if anyone had any experience with Kantronics EQ
(equalization) command on the KPC-II TNC.

I receintly changed my packet station's rig from an Alinco to a
Yeasu FT-212RH and now find that that I need to set EQ ON if I wish to
connect to local hams, while I need EQ OFF to connect to my local BBS
(on the same freq). If I don't make this change, I almost never get a
connect.

Couple of hints: The BBS is running the Data Engine (my friends KPC-IIs).
         The KPC-II I am running is using 3.0 firmware and I am
            making use of the DCD code (i.e. running squelchless)
         I think this problem showed up as I changed rigs.
         I did not modify the FT-212 for packet, as the mod only
            disables the tone burst function of one of their mics.


Oh well, if anyone has any ideas as to what I should look for, or what
other parameters could be tweaked, I'd appreciate it.

Tnx es 73,
Gene
AA6IY @ N6LDL.CA

------------------------------

Date: 17 Oct 90 20:12:16 GMT
From: hpcc05!hpdmd48![e-mail]  (Steve King)
Subject: High-speed KISS
To: [e-mail]

/ hpdmd48:rec.ham-radio.packet / [e-mail] (Nick Lawes) /  2:01 pm  Oct  3, 1990 /
> Does anyone out there know if there's a version of the KISS code code
> that will cope with 9600 baud (from a G3RUH modem). The standalone
> versions that I currently have send a lot of rubbish data to NET. The
> version built into the 1.1.7 ROM seems to function okay, but requires
> 32K RAM in the TNC.

>         Nick


I had problems with garbage being received using my 9600 baud
Pac-Comm modem (I beleive this is the G3RHU design).  The RXD from
the modem is garbage until it is locked and the RXC line is also
not on frequency.  This is going on when no signal is present.
My mheard was full of garbage after a little while both with
Pac-Comms PMS firmware for the tiny 2 and when using NOS (dont have
PMS revision number here at work).

The way I fixed this was to qualify the RXD from the modem with
the locked signal from the modem.  There is a 74HC14 used to drive
these lines and I removed the socket for this part and loaded the
part directly into the PC board.  I then piggy backed a 74HC00 on
top of the HC14.  I do not have the mod here at work but I is
fairly straight forward.  You want the UART to receive zeros until
locked is true.  Once locked is true, you want the UART to clock
the RXD from the modem.  I checked my mheard on the 9600 baud
TNC this morning and it had only one entry (the only other person
in the area using 9600 baud).   If you think this is what you are
seeing, you might want to make this change.  If you would
like more detailed information, let me know and I will gather up
more information and reply to anyone who is interested.

While I am at it, I also made another modification to the modem.
I now pass the 12 volt signal to a LM317 adjusted for about 9 volts.
This 9 volt supply is used for the modem board.
If your power supply sags on transmit and you are modulating the
crystal directly, you might get some frequency shift when the transmitter
comes on.  This is because the op amp which modulates the transmitter
is operating with a single supply.  If the supply voltage drops,
the frequency might shift slightly and then recover after the
coupling capacitor charges.  This will vary depending upon the
load that the modem is driving.  Low Z loads probrably will not
see the problem as bad.  I tried a smaller capacitor but the error
rate of the data was poorer.  The regulator fixed the problem by
better regulation to the op-amps.  The sag on my power supply was
very bad and the modem instructions did say that I should use a smaller
capacitor.  I figured that regulating the +12 would be worth the
effort even though I am no longer using Radio Shack jumper clips
to connect the radio to the power supply.

Steve King   email: [e-mail]
(KD7RO)             Disk Mechanisms Division
            Boise, Idaho

------------------------------

Date: 16 Oct 90 18:11:00 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: Networking Conference Proceedings
To: [e-mail]

>> Name:           ARRL
>> Work Phone:     [phone]
>> FAX Phone:      [phone]
>                       ^
>                       |
>Correction: FAX   [phone]
>

Boy... that explains why I had such trouble sending you a FAX a while back!!!

/o\

Bdale

------------------------------

Date: 15 Oct 90 14:32:30 GMT
From: hpl-opus!hpcc05!hpcuhb!hpindda![e-mail]  (Gene Marshall)
Subject: Packet modifications on YAESU FT-212RH
To: [e-mail]

/ hpindda:rec.ham-radio.packet / [e-mail] /  1:28 pm  Oct 12, 1990 /

> The YAESU manual says to "open" a solder bridge on the main circuit
> board to remove the "tone burst" function.
> Will I be missing something if I can't do the "tone burst" ???

Lee, I didn't implement this mod. I just acquired a 212 for use with
packet, and since tone burst is used in Europe when bringing up repeaters,
(here we may use PL), I fingured it really didn't matter. I believe if you
read further, you'll see this only works with a specific mic, which
is not the one you have.

I forget the second mod, one removed a jumper, one installed another. But,
I figured I didn't need that either.

Everything works fine, of course, but I do have a little funny. I am interfaced
to a KAM KPC-II, and I have to toggle EQUILIZATION on and off to better
receive signals. It doesn't make sense to me. This is part of the new
3.0 firmware from AEA with the build in DCD routines. If anyone has any info
on this it would be appreciated.

73,
Gene (AA6IY @ N6LDL.CA)

------------------------------

Date: 17 Oct 90 11:25:22 GMT
From: cti1![e-mail]  (Mark Pledger)
Subject: Phil Karn's address?
To: [e-mail]

As the subject line says, does anyone (Phil are you there?) have Phil's
network address?



--
Sincerely,


Mark Pledger

--------------------------------------------------------------------------
CTI                              |              [phone] [voice]
2121 Crystal Drive               |              [phone] [fax]
Suite 103                        |
Arlington, DC  22202             |              [e-mail]
--------------------------------------------------------------------------

------------------------------

Date: 19 Oct 90 06:02:35 GMT
From: tronsbox![e-mail]  (HIM)
Subject: Total turnip.
To: [e-mail]

Ok... I know there are probably those that will be upset that I am asking
for this (if this is like most other groups ;-) )

Overview:

    I am under the impression that packet radio will allow the transmission
    of computer data over some distance through the "ether" without
    having a wired pathway (hence radio).

    It is also my impression that proper equiptment will allow the
    selective transmission of data between specific machines.


Let me fill in a few details and ask some questions.

I have a 80386 Box running ISC 386ix.


1) Can I use packet radio to retrieve netnews data ?

2) What equiptment would be needed to have a quality setup to start in this
   area without spending a LOT of money.

3) What are the costs (equiptment, govt. fee's etc. )

   Thankx!

========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]=======
=Also the mantra and spells, the obeah and the wanga; the work of the wand=
=and the work of the sword: these shall he learn and teach.               =
=       He must teach; but he may make severe the ordeals.                =
=========== Ken Jamieson: uunet!tronsbox.xei.com!tron1  ===================
=    NONE of the opinions represented here are endorsed by either         =
=    Xanadu Enterpises or its clients, AT&T Bell Labs or others.          =
=== The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ====

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat, 20 Oct 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #174
To: packet-radio


Packet-Radio Digest         Sat, 20 Oct 90       Volume 90 : Issue 174

Today's Topics:
          56KB 70KHz modem vs 3KHz land-line modems
            Laws against scanners

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: Fri, 19 Oct 90 10:08:06 MDT
From: wsscal!dan (Dan Keizer)
Subject: 56KB 70KHz modem vs 3KHz land-line modems
To: ucsd.edu![e-mail]

I see that the 56Kbaud modem operates with 70KHz.  That seems to be the
same as the 2400 baud rates at the land-line 3KHz.  I also noticed that
with the land-line systems today, you can get 19.2KB over 3KHz voice-line.
Is it safe to assume that with the same type of technology applied that
you can get 440KBaud at 70KHz?  I don't know that much about spectrum
and bandwidth, but the figures look correct.  Anyone care to explain some of
this to me?

Dan
+---------------------------------+-------------------------------------------+
| Dan Keizer                      | To each his own ... thoughts included.    |
| Western Software Solutions      |                                           |
| ...!cpsc.ucalgary.ca!wsscal!dan |                                           |
+---------------------------------+-------------------------------------------+

------------------------------

Date: 20 Oct 90 00:06:00 GMT
From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Laws against scanners
To: [e-mail]

> There will no doubt be a contention that transmitting certain types of radio
> signals (such as baby monitors and cordless telephones) ENLARGES the personal
> space. I grant the right to determine if an RF signal entering my space harms
> me in some way. I doubt that that requires that I inspect the information
> contents of that RF signal.

Keep your personal space out of my personal space.

An enlargement of the person space would require first establishing the
concept that actual security of the radio transmission really exists.
It would be an invasion of my PHYSICAL personal space for you to determine
if I actually am listening in (and ONLY doing that).  Such security does
not exist for signals transmitted in conventional emission modes and not
encrypted.  Maybe we need more DES baby monitors.

> No, only the information.

Suppose you toss a sealed envelope into my front yard, which contains
pictures of you and your SO making love.  Is that an enlargement of YOUR
personal space?  Am *I* violating YOUR space by making an EFFORT (opening
the envelope) to get the information.

I contend that tossing the sealed envelope which has information in it is
no different that tossing out electromagnetic waves that have information
in them.  If you toss them MY way, I am CAPABLE of opening either, and you
have effectively given up your right to privacy.

You COULD have setup a wire-based baby monitor.  In fact the intercom
system in the house I grew up in had a way for the master unit to listen
in on anything going on near the slave unit.  You don't NEED to transmit
over the radio but you simply CHOOSE to.

Also, it is nearly impossible to be able to detect the signal without also
detecting the information.  Of course that is decreasing with technology.

>  > It should be noted that authoritarian regimes tend to place
>  > restrictions on radio receivers.  It's pretty dangerous to have all that
>  > free-thought being picked up by the masses.   Laws against radio
>  > receivers
>  > are censorship, plain and simple.
>
> Strange, but the U.S. is one of the very few places where people feel this
> way. In most other countries, including very democratic countries, the
> attitude is that the public only has the right to listen to radio
> transmissions that are the public's business. Listening to "private" radio
> transmissions is forbidden. ("That's rude, old boy!")

Strange, but the U.S. is one of the very few places where people felt this
way enough to revolt against an authoritarian regime and establish the
greatest democracy the world has ever seen.

Strange, but the U.S. is one of the very few places where we have a diverse
set of constitutional freedoms based on the concept that the government has
no more authority over people than the people themselves do.

Strange, but the U.S. is one of the very few places were have a reasonable
expectation of privacy of the things we do in our own personal space.

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

End of Packet-Radio Digest
******************************
Date: Sun, 21 Oct 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #175
To: packet-radio


Packet-Radio Digest         Sun, 21 Oct 90       Volume 90 : Issue 175

Today's Topics:
          56KB 70KHz modem vs 3KHz land-line modems
               Help w/KPC-II EQ command
               High-speed KISS
                Total turnip.

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 21 Oct 90 01:33:38 GMT
From: zaphod.mps.ohio-state.edu!usc!samsung!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: 56KB 70KHz modem vs 3KHz land-line modems
To: [e-mail]

In article <[e-mail]> [e-mail] (Dan Keizer) writes:
>I see that the 56Kbaud modem operates with 70KHz.  That seems to be the
>same as the 2400 baud rates at the land-line 3KHz.  I also noticed that
>with the land-line systems today, you can get 19.2KB over 3KHz voice-line.
>Is it safe to assume that with the same type of technology applied that
>you can get 440KBaud at 70KHz?  I don't know that much about spectrum
>and bandwidth, but the figures look correct.  Anyone care to explain some of
>this to me?

My understanding of the matter is that there are two techniques used to
achieve higher than 2400 baud data rates over phone lines. One uses data
compression (MNP 5, V42bis), the other uses multicarrier modulation (telebit).
Data compression can certainly be used with the 56kb modem, though the
effectiveness of compression depends on the content of the data. Text
compresses nicely, but binary data compression is not so impressive.
Multicarrier technology is totally different from the minimum shift
keying used by the 56 kb modem. It uses DSP bandwidth shaping and
training sequences to achieve high thruput. Used with conventional
packet protocols, this would not be effective since a new training
sequence would likely be required at the start of each transmission.
I don't know of any amateur work being done using multicarrier
techniques.

Gary KE4ZV

------------------------------

Date: 20 Oct 90 13:28:22 GMT
From: usc!wuarchive!emory!emcard!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Help w/KPC-II EQ command
To: [e-mail]

In article <[e-mail]> [e-mail] (Gene Marshall) writes:
>Hello all,
>
>I was wondering if anyone had any experience with Kantronics EQ
>(equalization) command on the KPC-II TNC.
>
>I receintly changed my packet station's rig from an Alinco to a
>Yeasu FT-212RH and now find that that I need to set EQ ON if I wish to
>connect to local hams, while I need EQ OFF to connect to my local BBS
>(on the same freq). If I don't make this change, I almost never get a
>connect.
>
>Couple of hints: The BBS is running the Data Engine (my friends KPC-IIs).
>                The KPC-II I am running is using 3.0 firmware and I am
>                   making use of the DCD code (i.e. running squelchless)
>                 I think this problem showed up as I changed rigs.
>                I did not modify the FT-212 for packet, as the mod only
>                   disables the tone burst function of one of their mics.
>
>
>Oh well, if anyone has any ideas as to what I should look for, or what
>other parameters could be tweaked, I'd appreciate it.
>

What you are experiencing is a classic case of tone twist. This was hashed
out by the experts several years ago. FM communications radios don't uniformly
adhere to the 75 microsecond preemphasis/deemphasis standard. Thus the ratio
of the levels of high frequency and low frequency tones isn't maintained
from the microphone jack of one radio to the speaker jack of another unless
the radios are of the same make and model. The expert's solution was to bypass
the preemphasis circuits by feeding the tones direct to the modulator and
extracting the tones directly from the discriminator. This worked wonderfully
well. Unfortunately, the expert's advice was uniformly ignored by the
average ham who didn't want to "modify" his radio by running two wires
inside the case. Some TNC manufacturers tried to solve the problem by
building equalizers into the TNC. Unfortunately again, the manufacturers
didn't agree on how much or in what direction the equalization was to be
applied. So you can wind up with as much as 20 db of twist between two
TNC/radio combinations that happen to go in opposite directions.

What to do about it. Volunteer to give a program about tone EQ at your next
LAN meeting. Urge everyone to adjust their equipment so that the high tone
has 3 db more deviation  than the low tone on a good deviation meter with
NO EQ. For the "I don't want to open my radio because it'll void the
warranty" types, a simple external RC network will work. EVERYBODY will
benefit from a good Level 1 signal.

Gary KE4ZV

------------------------------

Date: 20 Oct 90 12:50:24 GMT
From: swrinde!zaphod.mps.ohio-state.edu!samsung!emory!emcard!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: High-speed KISS
To: [e-mail]

In article <[e-mail]> [e-mail] (Steve King) writes:
>
>The way I fixed this was to qualify the RXD from the modem with
>the locked signal from the modem.  There is a 74HC14 used to drive
>these lines and I removed the socket for this part and loaded the
>part directly into the PC board.  I then piggy backed a 74HC00 on
>top of the HC14.  I do not have the mod here at work but I is
>fairly straight forward.  You want the UART to receive zeros until
>locked is true.  Once locked is true, you want the UART to clock
>the RXD from the modem.  I checked my mheard on the 9600 baud
>TNC this morning and it had only one entry (the only other person
>in the area using 9600 baud).   If you think this is what you are
>seeing, you might want to make this change.  If you would
>like more detailed information, let me know and I will gather up
>more information and reply to anyone who is interested.
>
>While I am at it, I also made another modification to the modem.
>I now pass the 12 volt signal to a LM317 adjusted for about 9 volts.
>This 9 volt supply is used for the modem board.
>If your power supply sags on transmit and you are modulating the
>crystal directly, you might get some frequency shift when the transmitter
>comes on.  This is because the op amp which modulates the transmitter
>is operating with a single supply.  If the supply voltage drops,
>the frequency might shift slightly and then recover after the
>coupling capacitor charges.  This will vary depending upon the
>load that the modem is driving.  Low Z loads probrably will not
>see the problem as bad.  I tried a smaller capacitor but the error
>rate of the data was poorer.  The regulator fixed the problem by
>better regulation to the op-amps.  The sag on my power supply was
>very bad and the modem instructions did say that I should use a smaller
>capacitor.  I figured that regulating the +12 would be worth the
>effort even though I am no longer using Radio Shack jumper clips
>to connect the radio to the power supply.
>
>Steve King   email: [e-mail]
>(KD7RO)             Disk Mechanisms Division
>                   Boise, Idaho

Any and all information on making G3RUH modems work is appreciated.
Please post anything you've done that works.

Thanks

Gary KE4ZV

------------------------------

Date: 20 Oct 90 13:59:29 GMT
From: usc!wuarchive!emory!emcard!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Total turnip.
To: [e-mail]

In article <[e-mail]> [e-mail] (HIM) writes:
>
>Ok... I know there are probably those that will be upset that I am asking
>for this (if this is like most other groups ;-) )
>
>Overview:
>
>    I am under the impression that packet radio will allow the transmission
>    of computer data over some distance through the "ether" without
>    having a wired pathway (hence radio).

True.

>    It is also my impression that proper equiptment will allow the
>    selective transmission of data between specific machines.

Also true.

>Let me fill in a few details and ask some questions.
>
>I have a 80386 Box running ISC 386ix.

Me too.

>1) Can I use packet radio to retrieve netnews data ?

Yes, but there are details. :-) There are both legal and technical issues
to consider. First the technical issues. ISC's TCP/IP has neither a slip
driver nor an AX25 driver that can be used for packet radio. A partial
solution is a version of KA9Q's Net code for Unix that does understand
packet radio, unfortunately, it is really a DOS program that has been
transplanted to Unix and won't integrate with your News software easily.
A better solution is a dedicated DOS box that runs the DOS version of
KA9Q and talks both to the radio and an ethernet board that in turn talks
to the regular ISC TCP/IP on your Unix box. This absolutely, positively
works.

Now the legal issues. If you are an amateur radio operator, handling messages
originated by other people is called "third party traffic" and must be
screened by a "control operator" before being transmitted. Certain things
are prohibited such as profanity and commercial use. This screening is
practically impossible for a full netnews feed, but can be done for a limited
number of groups. If you are not a ham, or the amateur rules are too
restrictive for you, then you may apply for a commercial license for a
point to point system from the FCC. There are certain fees involved in
this as well as issues of frequency coordination and proof of need. It
can be done, but is not necessarily easy or cheap.

>2) What equiptment would be needed to have a quality setup to start in this
>   area without spending a LOT of money.
>3) What are the costs (equiptment, govt. fee's etc. )

For an AMATEUR packet setup, assuming you buy everything new, you'll spend
between $600 and $900 per station. Equipment is available that will work
at 1200 baud, 2400 baud, 9600 baud, and 56000 baud. Somewhat surprisingly,
the 56 kilobaud equipment is not the most expensive system.

For a COMMERCIAL packet setup the costs run two to four times as much for
the same performance levels and 56 kb is not available at all.

Gary KE4ZV

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon, 22 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #176
To: packet-radio


Packet-Radio Digest         Mon, 22 Oct 90       Volume 90 : Issue 176

Today's Topics:
          56KB 70KHz modem vs 3KHz land-line
                cross-posting
          My Country is Better than Your Country ...

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 21 Oct 90 21:03:00 GMT
From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: 56KB 70KHz modem vs 3KHz land-line
To: [e-mail]

> Multicarrier technology is totally different from the minimum shift
> keying used by the 56 kb modem. It uses DSP bandwidth shaping and
> training sequences to achieve high thruput. Used with conventional
> packet protocols, this would not be effective since a new training
> sequence would likely be required at the start of each transmission.
> I don't know of any amateur work being done using multicarrier
> techniques.

If a packet transmitter were allowed to concatenate many packets it has
queued up together into a single transmission sequence (with some reasonable
limit, of course) then you would only need one training sequence for many
such packets.  This would require all the receiving stations to listen
from the beginning to a transmission that may contain few to none of their
packets.  Of course a means to separate the packets has to be part of that,
but that is probably the easy part.

This would work best in high volume paths.  Short of some large file
transfers, typical packet users would not benefit much from this.  It
should be workable on point-to-point links just fine, I'd think.

I am thinking of this being more useful in major backbone trunks.  When
there is only one packet to send, go ahead and sent it solo, with its
own training sequence.  If that added time causes more packets to be
queued up than can be sent one at a time, then start sending more in a
single transmission as they are now queued up and ready to go.  If the
node becomes overloaded you would benefit from the speed improvement
with not too much loss from the training sequence.

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

Date: 21 Oct 90 03:18:46 GMT
From: rochester!uhura.cc.rochester.edu!ee.rochester.edu!rochgte!f218.n260.z1.FIDONET.ORG![e-mail]  (David Stark)
Subject: cross-posting
To: [e-mail]

I have read three more messages in the "privacy (was CBS)" thread in
REC.HAM-RADIO.PACKET today.  I have also read the same three messages
in REC.HAM-RADIO and REC.RADIO.SHORTWAVE.  So what does this thread
have to do with packet?


--
*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*
David Stark - via FidoNet node 1:260/230
UUCP: ...!rochester!ur-valhalla!rochgte!218!David.Stark
INTERNET: [e-mail]
*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*

------------------------------

Date: 21 Oct 90  9:49 -0700
From: Doug Collinge VE7GNU <djc@[e-mail]>
Subject: My Country is Better than Your Country ...
To: [e-mail]

>X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)

> Strange, but the U.S. is ... the greatest democracy the world has ever seen.

Yes, well, ...  I am, myself, a great fan  of the American Constitution but
let's keep the rabid nationalism turned down a few dB.  We wouldn't want to
offend the, let's face it, fantastically productive European members of this
list, or us Canadians either, for that matter.

Nice boring nerd-talk on this  list, please.

73 doug


--
/\/\/\/\/\/
Doug Collinge,  first try: [e-mail]
        then try:  samisen![e-mail]
VE7GNU          VE7GNU@VE7GNU.#VIC.BC.CAN.NA
        Victoria, BC, Canada

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed, 24 Oct 90 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #177
To: packet-radio


Packet-Radio Digest         Wed, 24 Oct 90       Volume 90 : Issue 177

Today's Topics:
       HELP - PK-232 "Warbling" modulation of my HF TS-440S rig
            privacy, was CBS . . .
                  TNC-1 ROMs

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 16 Oct 90 20:55:01 GMT
From: van-bc!ubc-cs!alberta!adec23![e-mail]  (Mark Salyzyn)
Subject: HELP - PK-232 "Warbling" modulation of my HF TS-440S rig
To: [e-mail]

Well, I had the same kind of problem with my rig (an ICOM 751A). Two reasons.
The first is the Speech Compressor should be turned off (not sure if 440 has
one). Next, the MIC circuit should have the ground isolated. unfortuneately
you have this HUGH ground loop back to the rig. This ground loop picks up
your stray RF (EVEN IF FEEDING A DUMMY LOAD) and the mic amp rectifies it ...
If you use a 1:1 audio isolation transformer (ala Radio Scrap), that should
get rid of your problem. Try this test to confirm ... connect your station
ground, or PK-232 ground to JUST the mic ground pin on the connector. key up
and see if the audio goes NUTZ.

Perform all the other standard RF proofing if necessary ...

Good luck, 73 de VE6MGS/Mark,  ...!alberta!adec23!mark -sk-

------------------------------

Date: 22 Oct 90 22:32:04 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: privacy, was CBS . . .
To: [e-mail]

>Moreover, there is the fundamental issue: why would any decent person WANT to
>eavesdrop on the private lives of others?

Why do folks watch soap operas?  Does it matter?  They watch them...

73 - Bdale

------------------------------

Date: 22 Oct 90 19:38:11 GMT
From: cica!sol.ctr.columbia.edu!caen!math.lsa.umich.edu!spsd4330a.erim.org![e-mail]  (Steve Hideg (Mr. Fabulous) )
Subject: TNC-1 ROMs
To: [e-mail]

Hello. I have a tnc-1 (A Heathkit HD-4040). I have heard that there exist
ROMs that contain both the WA8DED and KISS firmware. The user simply
picks a mode of operation via a dip-switch setting.

Can anyone suggest a source for such an animal?


(Another question: Does anyone know if there are plans to put tcp/ip
software on tnc's ROMs in the future?)

Tnx es 73.

____________________________________
Steve Hideg  N8HSC

[e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri, 26 Oct 90 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #178
To: packet-radio


Packet-Radio Digest         Fri, 26 Oct 90       Volume 90 : Issue 178

Today's Topics:
          56KB 70KHz modem vs 3KHz land-line
               Help w/KPC-II EQ command
          My Country is Better than Your Country ...
               TAPR TNC Sources

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 25 Oct 90 05:47:01 GMT
From: bellcore-2!envy![e-mail]  (Phil Karn)
Subject: 56KB 70KHz modem vs 3KHz land-line
To: [e-mail]

Regarding the orginal question...

According to Shannon's channel capacity formula, the capacity of a given
noisy, band-limited channel is a function of both the bandwidth and
the signal-to-noise ratio. Telephone modems can achieve very high b/s-Hz
ratios because the S/N ratios are relatively high. The lower S/N ratios
typical of radio paths requires more bandwidth to achieve the same data
rates.

This also explains why telephone modems are not likely to give good results
over amateur packet radio. They are designed for a different set of
conditions.

Phil

------------------------------

Date: 25 Oct 90 14:11:52 GMT
From: hpda!hpcuhb!hpindda![e-mail]  (Gene Marshall)
Subject: Help w/KPC-II EQ command
To: [e-mail]

Gary,

Thanks for you comments.

After a closer review of the schematic, I found that one of the mic pins has
RX de-emphasized audio out. After using this audio instead of that from the
rear panel, everything works fine.

btw, I aggree with you regarding the folks who "don't want to open their
radios", but on the other hand, with all of today's surface mount technology
and single chip radios (well almost),  even if you have access to the node you
need to tap within a radio, it is often hard to.  There taking all the fun
out of this :)

73 es tnx again,
Gene

------------------------------

Date: 25 Oct 90 15:49:02 GMT
From: mnemosyne.cs.du.edu!isis![e-mail]  (William R. Hester)
Subject: My Country is Better than Your Country ...
To: [e-mail]

In article <271f6b46.samisen@[e-mail]> [e-mail]
c.ca writes:
>>X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)
>
>> Strange, but the U.S. is ... the greatest democracy the world has ever
seen.
>
>Yes, well, ...  I am, myself, a great fan  of the American Constitution
ut
>let's keep the rabid nationalism turned down a few dB.  We wouldn't want
to
>offend the, let's face it, fantastically productive European members of
his
>list, or us Canadians either, for that matter.
>
>Nice boring nerd-talk on this  list, please.
>
>73 doug

I agree...I have found that the most rabid chest puffers and flag wavers
have never had much experience living in another country and experiencing
their perspective...sometimes is best to keep one's mouth shut about things
one hasn't experienced personally.

My experience living abroad taught me to really appreciate the good things
about my country and not blindly accept those things that ought to be
changed.

Step down from soapbox and get back to packet racket.







--
Bill Hester, Ham Radio N0LAJ, Denver CO., USA
Please route replies to: [e-mail] or uunet!nyx!whester
Public Access Unix @ University of Denver, Denver Colorado USA
(no official affiliation with the above university)

------------------------------

Date: 26 Oct 90 06:12:15 GMT
From: usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uniwa!vax7![e-mail]
Subject: TAPR TNC Sources
To: [e-mail]

   Are the sources to the TAPR TNC code easily available? We have an
implementation here which is fine in all respects, except that there's no
way to get out of KISS once you've invoked it (short of jumping on the TNC
and buying a new one, that is!). I feel that, given the source code, it
would be a simple matter to fix this one. Anybody know the situation
regarding this stuff? And does anyone know how we can contact TAPR?
....Ron

 Internet: [e-mail]
 ACSnet: [e-mail]
 Bitnet: [e-mail]
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat, 27 Oct 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #179
To: packet-radio


Packet-Radio Digest         Sat, 27 Oct 90       Volume 90 : Issue 179

Today's Topics:
          56KB 70KHz modem vs 3KHz land-line
         56KB 70KHz modem vs 3KHz land line (2 msgs)
              Pinging Phil Karn........
           Returned mail: Data format error
        Summary:  What is Phil Karn's address

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 26 Oct 90 21:17:31 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu![e-mail]  (Phil Howard KA9WGN)
Subject: 56KB 70KHz modem vs 3KHz land-line
To: [e-mail]

karn@envy..bellcore.com (Phil Karn) writes:

>This also explains why telephone modems are not likely to give good results
>over amateur packet radio. They are designed for a different set of
>conditions.

Q: But how about on good microwave links where S/N is high?

A: Things far better than 19.2 kb can be done.
--

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

Date: Fri, 26 Oct 90 10:35:34 MDT
From: wsscal!dan (Dan Keizer)
Subject: 56KB 70KHz modem vs 3KHz land line
To: [e-mail]

Regarding reply as follows:
> From: bellcore-2!envy![e-mail]  (Phil Karn)
>
> The lower S/N ratios typical of radio paths requires more bandwidth to
> achieve the same data rates.

Hmmm, currently, I know of people operating locally with both 1200 and 9600
baud links.  Although, in this area, 1200 baud is the dominant force still and
there is a big resistance in moving to 9600.  At 9600 baud, what amount of
bandwidth is being used?  as compared to 1200 baud?  Also, the Ottawa group
is working with a 56KBaud link and have a 9600 baud satellite link to us,
although the datarate in use is 1200 yet again.

> This also explains why telephone modems are not likely to give good results
> over amateur packet radio. They are designed for a different set of
> conditions.

Granted ... there is more noise on a radio link than a land-line.  I guess the
position that I was trying to put forward was the effective utilization of
bandwidth (at least to some degree).  Well, it'll make sense to me soon.
I'm taking the new radio course for the new regulations.

Dan
+---------------------------------+-------------------------------------------+
| Dan Keizer                      | To each his own ... thoughts included.    |
| Western Software Solutions      |                                           |
| ...!cpsc.ucalgary.ca!wsscal!dan |                                           |
+---------------------------------+-------------------------------------------+

------------------------------

Date: 27 Oct 90 05:21:10 GMT
From: bellcore-2!envy![e-mail]  (Phil Karn)
Subject: 56KB 70KHz modem vs 3KHz land line
To: [e-mail]

In article <[e-mail]>, [e-mail] (Dan
Keizer) writes:
|> At 9600 baud, what amount of
|> bandwidth is being used?  as compared to 1200 baud?

The K9NG-type 9600 bps modems (which includes G3RUH, etc) occupy
roughly the same bandwidth as standard 1200 bps AFSK/FM: 15-20 KHz.

This is not because the 9600 bps modems are especially efficient, but
because 1200 bps AFSK/FM is incredibly INefficient. Roughly the same
signal power is needed to make a 9600 bps modem work as to make 1200
bps AFSK/FM work, but the signalling rate is 8 times faster. That
translates
directly into a 9 dB improvement in both Eb/N0 (S/N) and in bandwidth
utilization.


If we hams had to pay for the spectrum we burn up, I suspect that we'd
have
had much greater acceptance of newer modems...

Phil

------------------------------

Date: Fri, 26 Oct 90 09:34:50 EDT
From: [e-mail] (John H. Klingelhoeffer)
Subject: Pinging Phil Karn........
To: [e-mail]

Phil;

Tried to get a message to you, but as you can see below, had some
problems.  Could I please get a valid address?  Sorry about the
public fourm u     rum usage!

John...
---------------------------------37
Message 37:

------------------------------

Date: Fri, 26 Oct 90 09:09:34 EDT
From: [e-mail] (Mail Delivery Subsystem)
Subject: Returned mail: Data format error
To: <[e-mail]>

   ----- Transcript of session follows -----
can't get working directory; will try to continue
bad system name: bellcore-2
uux failed. code 65
501 <bellcore-2!envy![e-mail]>... Data format error

   ----- Unsent message follows -----
Received: from SALT.ACC.COM by rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
    id AA25360; Fri, 26 Oct 90 09:09:34 EDT
Received: from SATURN.ACC.COM by salt.acc.com (5.61/1.34)
    id AA21640; Fri, 26 Oct 90 06:10:05 -0700
Received: by saturn.acc.com (5.51/1.28)
    id AA11374; Fri, 26 Oct 90 09:08:40 EDT
Date: Fri, 26 Oct 90 09:08:40 EDT
From: [e-mail] (John H. Klingelhoeffer)
Message-Id: <[e-mail]>
To: envy![e-mail]

[Private message deleted]



Thanks very much.

John, WB4LNM

+--------------------------------------------------------------------------+
|                          ** DISCLAIMER **                                |
| All of these wonderful ideas and superb comments are not necessarily     |
| the opinion of my employer, nor would I necessarily want them to be.     |
[7m--More--[m
|                              So there.                                   |
+-----------------------------------------+--------------------------------+
|                                         |                                |
| John H. Klingelhoeffer                  |      THIS SPACE FOR RENT       |
| Director, Government Special Operations |                                |
| Advanced Computer Communications        +--------------------------------+
| Systems Division                        | Voice: 301-290-8100            |
| 10220 Old Columbia Road                 | Fax:   [phone]            |
| Columbia, Maryland  USA   21046-1725    | Radio: 224.56/147.135 WB4LNM   |
|                                         | Internet: [e-mail]   |
+-----------------------------------------+--------------------------------+




&

------------------------------

Date: 26 Oct 90 11:36:28 GMT
From: cti1![e-mail]  (Mark Pledger)
Subject: Summary:  What is Phil Karn's address
To: [e-mail]

Thanks to everyone (including Phil) for sending me his address.



--
Sincerely,


Mark Pledger

--------------------------------------------------------------------------
CTI                              |              [phone] [voice]
2121 Crystal Drive               |              [phone] [fax]
Suite 103                        |
Arlington, DC  22202             |              [e-mail]
--------------------------------------------------------------------------

------------------------------

Date: Fri, 26 Oct 90 20:46:05 EDT
From: AMSEL-GS-1  <[e-mail]>
To: [e-mail]

----- Forwarded message # 1:

Received: from [128.174.5.98] by MONMOUTH-EMH3.ARMY.MIL.ARMY.MIL id aa23078;
      26 Oct 90 14:37 EDT
Received: from VMD.CSO.UIUC.EDU by VMD.CSO.UIUC.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7772; Fri, 26 Oct 90 13:37:58 CDT
Received: by UIUCVMD (Mailer R2.07) id 7556; Fri, 26 Oct 90 13:37:57 CDT
Date:         Fri, 26 Oct 90 13:28:00 CDT
Reply-To:     [e-mail]
Sender:       Packet Radio <I-PACRAD@uiucvmd>
From:         Collette's Boyfriend <[e-mail]>
To:           "CPT GARY S. O'NEAL" <[e-mail]>

SUB I-PACRAD Ron Nelson

----- End of forwarded messages

------------------------------

End of Packet-Radio Digest
******************************
Date: Sun, 28 Oct 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #180
To: packet-radio


Packet-Radio Digest         Sun, 28 Oct 90       Volume 90 : Issue 180

Today's Topics:
                 Ottawa board
        Packet-Radio Digest V90 #178 (2 msgs)
              PSK-1 <---> KPC-II
                  subscribe

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 26 Oct 90 20:09:34 GMT
From: ncrlnk!ciss!lawday![e-mail]  ([e-mail])
Subject: Ottawa board
To: [e-mail]

A couple of questions about the nifty-looking packet board from the Ottawa
group:

1)  Can one pc support more than one of these boards?  IE, can we run two
56KBPS (or whatever) links on a single machine?

2)  Is the low-speed port an asynchronous one, or can it also be used to
directly drive a modem?  And if so, at what maximum speed?

3)  If the low-speed port is a standard serial port, can it be addressed
as COM3 or COM4?

4)  Is anyone working for a driver to use this board with the
G8BPQ netrom code?  NOS is fine with me, but we have a switch site where
we'll be using BPQ at least for a while.

5)  Finally, has anyone (outside Ottawa) been using the board enough to
provide a mini-review of it?

Thanks in advance for any info anyone can provide me.
--
John R. Ackermann, Jr.                                           [phone]
Law Department, NCR Corporation                              VoicePlus 622-2966
Dayton, Ohio                                      [e-mail]
     ***** Amateur Radio: ag9v@n8acv or [e-mail] *****

------------------------------

Date: Sat, 27 Oct 90 17:31 CDT
From: [e-mail]
Subject: Packet-Radio Digest V90 #178
To: [e-mail]

There is a new owner to this account.
Please do not send any more messages to this account.

Thanks in advance
Shane Holder.

------------------------------

Date: 27 Oct 90 22:46:30 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu![e-mail]  (Phil Howard KA9WGN)
Subject: Packet-Radio Digest V90 #178
To: [e-mail]

[e-mail] writes:

>There is a new owner to this account.
>Please do not send any more messages to this account.

>Thanks in advance
>Shane Holder.

This is a newsgroup that is piped through more than one automated mailing
list.  There are procedures for unsubscribing.  These things should be
known when you setup the subscription.  Since you have mentioned the
peculiar case of a new user using the same exact userid as a previous
user, I guess you would not know of these things.  I might suggest you
contact the previous user to ask what was done in the past.  The previous
user should have unsubscribed all mailing lists when ending use of the
account.

You need to look at the headers of the mail that is arriving there to
find out where your mail is coming from.  If there is a mention of LISTSERV
in the headers, take note of the hostname where it is coming from and the
exact name of the mailing list.  You need to send mail to the LISTSERV
address (so the server will read it as a command instead of sending it
to the rest of us).  In that mail put:

    unsub  listname

and that should do it.  If the mailing list is not a LISTSERV one, then
find the name of the list in the header and add the string "-request"
to the name of the list, but before the "@", and send mail to the request
address you just formed.  In that mail, simply ask to be removed from
the mailing list.  There may be a few days delay in processing since
there is usually a human being doing this and human beings often have
bad days at the office and take extended vacations.
--

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

Date: 27 Oct 90 21:17:41 GMT
From: unmvax!ariel.unm.edu!hydra.unm.edu![e-mail]  (Ollie N6LTJ)
Subject: PSK-1 <---> KPC-II
To: [e-mail]

Hi.

Boy was I surprised to learn that my new PSK-1 won't interface
with a Kantronics KPC-2.  (according to the PacComm manual)

Has anyone been able to make these two units talk to each other?

Any suggestions would be appreciated...

--
Ollie Eisman (N6LTJ)    [e-mail]     [phone]
3505 Lafayette Rd. NE #3, Albuquerque, New Mexico, 87131, USA

"That makes me mad."  --  Droopy

------------------------------

Date: Thu, 25 Oct 90 09:55:39 EDT
From: [e-mail]
Subject: subscribe
To: lectroid![e-mail]

ADD packet-radio

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon, 29 Oct 90 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #181
To: packet-radio


Packet-Radio Digest         Mon, 29 Oct 90       Volume 90 : Issue 181

Today's Topics:
                 Ottawa board

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 28 Oct 90 21:23:17 GMT
From: zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu![e-mail]  (Phil Howard KA9WGN)
Subject: Ottawa board
To: [e-mail]

[e-mail] ([e-mail]) writes:
>1)  Can one pc support more than one of these boards?  IE, can we run two
>56KBPS (or whatever) links on a single machine?

...or three or four, etc.?
--

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue, 30 Oct 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #182
To: packet-radio


Packet-Radio Digest         Tue, 30 Oct 90       Volume 90 : Issue 182

Today's Topics:
          56KB 70KHz modem vs 3KHz land-line modems
         Got NOS running on my Sun, Now what?
           KA9Q TCP/IP Binary sending & receiving.
            Looking for Digicom. (2 msgs)
                 None
             Packet-Radio Digest V90 #180
           slotted p-persist CSMA slottime?
               TAPR TNC Sources

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 29 Oct 90 16:39:07 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: 56KB 70KHz modem vs 3KHz land-line modems
To: [e-mail]

>
> Q: But how about on good microwave links where S/N is high?
>
> A: Things far better than 19.2 kb can be done.

But if S/N is truly so high (not just guard to cover QSB etc) why not
use it with an appropriate modulation method to obtain greater
channel capacity? If S/N is unnecessarily high it means you have already
wasted (not optimumly used) some hardware resources.

  But better than turning up the bits/baud turn up the bandwidth
since that gets you more channel capacity than trying to cram a lot
signalling info onto a narrow channel(inter-symbol interference problems).
If you are using reasonably directive antennas the extra spectrum isn't
"stolen" from someone else's use since frequency reuse can be going on
anyway.

Glenn Elmore -N6GN-

N6GN @ K3MC
[e-mail]
[e-mail]

------------------------------

Date: 30 Oct 90 05:03:21 GMT
From: uop!quack![e-mail]  (Nick Sayer)
Subject: Got NOS running on my Sun, Now what?
To: [e-mail]

I finally managed to compile NOS with the unix TUN driver hacks,
and it appears to be working (thanks to Gnu C). Now I need to configure it.
My Packet IP address is [44.2.1.17], and my ethernet has [138.9.100.1].
My internet subdomain (to be connected some day. Don't worry, I won't
try to gate inet and packet) is 138.9.100.x

Well, any suggestions addressing the two ends of the tun device,
and the ax0 device? I want to run this thing in the background
and use the normal sun daemons and network utilities. Any
great ideas? I have the net documentation, but it's not very
clear.

Since most of the nos package seems to be support for user commands
and daemons, nos may be overkill, but as long as it works, I'll be
happy.

Thanks in advance.

--
Nick Sayer               | Disclaimer: "Don't try this at home, | RIP: Mel Blanc
[e-mail]  | kids. This should only be done by    |   1908-1989
N6QQQ  [44.2.1.17]       | trained, professional idiots."       |  May he never
209-952-5347 (Telebit)   |                     --Plucky Duck    |  be silenced.

------------------------------

Date: 30 Oct 90 02:07:38 GMT
From: usc!zaphod.mps.ohio-state.edu!ub!canisius![e-mail]  (Karl Vesterling)
Subject: KA9Q TCP/IP Binary sending & receiving.
To: [e-mail]

    To:  Phil Karn  (KA9Q)

    Phil,  I don't know if you are alerted to this problem, but a while
ago I grabbed a version of your TCP/IP program for MS-DOS off of
louie.udel.edu

    I don't know if it is the current version, but we experimented with
it, and we found that doing SLIP between three machines at various bps rates
your SLIP implementation appeared to work flawlessly except that it would not
transmit binary files correctly.  We had everything set 8N1, and the files
arrived the same size as they were originally, but they were no longer binary
files.  Do you have any reasons for this?  Is this a new found bug?  Or isn't
that the most current version on louie.udel.edu, and if not, where can I get
the most current version?


Just some questions...


Thanks in advance...


--
------------------------------------------------------------------------------
Karl J. Vesterling                              [e-mail]
716-634-1643 (Answering machine, Box 1)         [e-mail]
Buffalo, NY                                     [e-mail]

------------------------------

Date: 30 Oct 90 02:25:07 GMT
From: usc!samsung!umich!vela![e-mail]  (Ron Srodawa)
Subject: Looking for Digicom.
To: [e-mail]

I am looking for a program named Digicom.  I understand this to be a
public domain program for packet radio which operates on a Commodore 64.
I'm emtering this on behalf of my son, John--KB8KRF.

--
| Ronald J. Srodawa               | Internet: [e-mail] |
| School of Engineering and CS    | UUCP:     [e-mail]          |
| Oakland University              | Voice:    [phone]                |
| Rochester, Michigan  48309-4401 |                                         |

------------------------------

Date: 30 Oct 90 04:48:58 GMT
From: agate!shelby!msi.umn.edu!cs.umn.edu!uc!shamash![e-mail]  (Jeff Comstock)
Subject: Looking for Digicom.
To: [e-mail]

In article <[e-mail]> [e-mail] (Ron Srodawa) writes:
>I am looking for a program named Digicom.  I understand this to be a
>public domain program for packet radio which operates on a Commodore 64.
>I'm emtering this on behalf of my son, John--KB8KRF.
>
Digicom is actually a small board that attaches to the C64, and allows
one to operate packet radio.  It only costs about 40 dollars to build.

This information is about 8 months old, but here is what I have:

Craig Rader N4PLK
922 Baltimore Dr.
Orlando, FL 32810-5531
[phone]

Here is another number - I think this person wrote some different software
to operate the Digicom:
Barry Kutner
614-B Palmer Lane
Yardley, PA 19067

Jeff - NR0D

------------------------------

Date: 29 Oct 90 12:31 GMT
From: "Disini SW, Emmanuel Disini,PRT" <[e-mail]>
Subject: None
To: [e-mail]

Attn: packet radio
SentBy: Joel Disini
Date   10/29/90
Subject    None

------------------------------

Date: Mon, 29 Oct 90 20:43 CST
From: Collette's Boyfriend <[e-mail]>
Subject: Packet-Radio Digest V90 #180
To: [e-mail]

INDEX Packet-Radio

------------------------------

Date: Mon, 29 Oct 90 11:20:27 -0800
From: brian (Brian Kantor)
Subject: slotted p-persist CSMA slottime?
To: [e-mail]

Although it came up in conjuction with some discussions of net/rum
networks, the question of how to choose a value for the slottime of a
slotted p-persistent CSMA TNC is one that has a wider application,
since KISS TNCs use that method as well.

A quick literature search yields the suggestion that the slottime needs
to be long enough to make sure that a transmitting station is detected
by all the stations that can hear it - that is, the slot has to be wide
enough that if station A begins transmitting in station B's slot s,
assuming that station B does not transmit, then when station B again
samples the channel in slot s+1, its carrier detect circuitry must have
already noticed the channel activity.

It seems to me that this would have to include the transmitter keyup
time, receiver unsquelch time (if a squelch is being used), and modem
PLL lockup time.  Most ham transmitters get on the air reasonably fast,
and the modems in current use aren't too slow, but some receiver
squelches are.  Thus many people use transmit delay times in their TNCs
that wind up sending around 200 to 300 ms of flags before they begin
sending data (i.e., a TXD setting of 20 to 30).  That's probably two to
three times longer than is needed, but since there is little hope of
ever correcting that in the great unwashed populace, those long delays
need to be taken into account when configuring anything that's going to
be on a general-access channel.

Net rom arrives with a default slottime of 100 ms.  For a 1200 bps
channel like most two meter channels, I think that's way too small.
Assuming that the TNC in which the net/rom is installed is equipped
with Eric Gustafsen's DCD mods (as available from TAPR), that's probably
fast enough for itself to avoid colliding, but there will be a lot of
other TNCs on the channel that wouldn't have detected carrier that fast
so it's perhaps best not to sample quite that often - in other words,
to enforce a bit of deadtime by making the slottime longer.  That way,
the TNC using ppCSMA won't wind up getting stomped on by the older
TNCs.

Thus I think that a slottime of around 250 to 300 ms is reasonable
for 1200 bps AFSK like most 2 meter user channels.

Any thoughts or experience on this?
    - Brian

------------------------------

Date: 29 Oct 90 19:22:25 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: TAPR TNC Sources
To: [e-mail]



------------------------------

Date: (null)
From: (null)
The source is tightly controlled by the author (Howie Goldstein) and will
almost surely never be released by TAPR.  This is NOT under TAPR control.
Have you tried sending KISS command 255.  This command means exit kiss and
is standard in all kiss implementations I know of.

Bob N4HY

--
____________________________________________________________________________
    My opinions are my own no matter    |       Robert W. McGwier, N4HY
    who I work for! ;-)                 |       CCR, AMSAT, etc.
----------------------------------------------------------------------------

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed, 31 Oct 90 04:30:09 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #183
To: packet-radio


Packet-Radio Digest         Wed, 31 Oct 90       Volume 90 : Issue 183

Today's Topics:
       KA9Q TCP/IP Binary sending & receiving. (2 msgs)
                 Ottawa board
           slotted p-persist CSMA slottime?
           TNC sources and non-return KISS

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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.
----------------------------------------------------------------------

Date: 30 Oct 90 17:34:07 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: KA9Q TCP/IP Binary sending & receiving.
To: [e-mail]

>
> Just some questions...
>


Did you send the command

type image


after you set up the ftp connection??

Just a question ;-)

Bob

--
____________________________________________________________________________
    My opinions are my own no matter    |       Robert W. McGwier, N4HY
    who I work for! ;-)                 |       CCR, AMSAT, etc.
----------------------------------------------------------------------------

------------------------------

Date: 31 Oct 90 04:07:02 GMT
From: usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu![e-mail]  (Phil Howard KA9WGN)
Subject: KA9Q TCP/IP Binary sending & receiving.
To: [e-mail]

[e-mail] (Karl Vesterling) writes:
>       To:  Phil Karn  (KA9Q)

This answer from another PHIL (KA9WGN)

>       I don't know if it is the current version, but we experimented with
>it, and we found that doing SLIP between three machines at various bps rates
>your SLIP implementation appeared to work flawlessly except that it would not
>transmit binary files correctly.  We had everything set 8N1, and the files
>arrived the same size as they were originally, but they were no longer binary
>files.  Do you have any reasons for this?  Is this a new found bug?  Or isn't
>that the most current version on louie.udel.edu, and if not, where can I get
>the most current version?

Since all the underlying TCP and IP protocols and headers have binary data,
if SLIP was not completely transparent, TCP/IP just would not work at all.

What method of file transfer did you try?

If FTP, you need to use a command like:

    type image

or

    binary

otherwise the transfer is text mode and that mode will translate CR/LF
and NL between machine types and many other things as well.
--

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

Date: Tue, 30 Oct 90 15:31:54 EST
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: Ottawa board
To: [e-mail]

>A couple of questions about the nifty-looking packet board from the Ottawa
>group:
>
>1)  Can one pc support more than one of these boards?  IE, can we run two
>56KBPS (or whatever) links on a single machine?

In principle, yes... but we haven't tried it yet, and we can't make any
promises to support multi-board configurations.  The board is intended to
fill a fairly specific niche: for the end user who wants to run 56kb, or
for a small packet switch which has a single high-speed trunk and a plethora
of lower-speed ports.  Multi-board applications run up against some pretty
severe constraints (e.g., lack of DMA channels and IRQ levels) of the XT bus.

>2)  Is the low-speed port an asynchronous one, or can it also be used to
>directly drive a modem?  And if so, at what maximum speed?

Directly driving a modem is the intended application for this port.  The
maximum speed is yet to be determined - we've only tested it at 1200 bps
so far.  Unless someone can make a convincing case for it, support for
using it as a general-purpose async port probably won't happen.

>3)  If the low-speed port is a standard serial port, can it be addressed
>as COM3 or COM4?

Even if the async support software materializes, the port would not be
addressible as a standard com port.

>4)  Is anyone working for a driver to use this board with the
>G8BPQ netrom code?  NOS is fine with me, but we have a switch site where
>we'll be using BPQ at least for a while.

Not yet, but the technical details of the board and the NOS driver haven't
been released yet.  As a TCP/IP devotee, my feeling is that you're better
off to run NOS in your switch.  You can always hang NET/ROM TNC's on the
low-speed ports to keep the ax.25 users happy.  That's what we're doing in
Ottawa.

>5)  Finally, has anyone (outside Ottawa) been using the board enough to
>provide a mini-review of it?

I don't qualify, but I can tell you that the answer right now is no.  We're
waiting on the PCB shop right now, and the first shipment of PI boards is
still a couple of weeks away.

>John R. Ackermann, Jr.                                          [phone]

Barry VE3JF

------------------------------

Date: 31 Oct 90 03:25:39 GMT
From: swrinde!zaphod.mps.ohio-state.edu!rpi!clarkson![e-mail]  (Tadd,Off Campus,,2653763)
Subject: slotted p-persist CSMA slottime?
To: [e-mail]



------------------------------

Date: 31 Oct 90 05:46:55 GMT
From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uniwa!vax7![e-mail]
Subject: TNC sources and non-return KISS
To: [e-mail]

   Thanks to all those who have replied. We are aware of the KISS
"param ax0 255" command, and this works fine on the version 1.1.7
ROM which we have. The particular 1.1.6 version that we tried has
a mailbox, which we figure could be handy (if we aren't running TCP/IP),
but, as I said, the only way out of KISS as far as we can see is to
disconnect the backup battery and power the TNC down. The normal
code then executes on restart. I will disassemble the KISS code and
compare it to the KISS sources I have, and see if I can get it to
work that way.
Thanks again,
....Ron

--
 Internet: [e-mail]
 ACSnet: [e-mail]
 Bitnet: [e-mail]
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ

------------------------------

End of Packet-Radio Digest
******************************