🚀 go-pugleaf

From: karn@ka9q.bellcore.com (Phil Karn)
Date: Wed, 19 Jun 91 04:41:12 UTC
Subject: Re: A plea when sending stuff

Geert Jan,

I sympathize. My "free" PI card from Ottawa cost me $10 and a trip to my
local post office - which is NOT the closest one to my house. More than half
of the $10 charge was a postal fee for collecting the customs duty.

So much for the US/Canada "Free Trade Agreement". :-)

Phil



----
From: Bdale Garbee <bdale@col.hp.com>
Date: Tue, 18 Jun 91 23:19:55 MDT
Subject: V.29 vs FSK

> I think this topic has been disucussed here before but I'll repeat
> my view.  The V.29 modem used for fax is not suitable for packet radio
> because it depends upon a lengthy training sequence, during which time
> it performs adaptive equalization.  

Actually, I'm not sure I feel as strongly about this now as I did several
months ago when I was writing in PSR about V.29...

> But the key to fast throughput on
> shared access channels is fast keyup time.  Old relay voice radios
> with TxD times ar a problem.  At 9600 bps, the keyup time is longer 
> than the packet time, which really kills the efficiency. 

The problem I've been seeing is that in any given area, if you're running FSK
9600, and there's anyone on the channel who is not running a made-for-data
radio, and/or a radio that's been hacked to "do the right things", what happens
is that everyone backs off their tx/rx switching time to "be able to talk to
Joe", and you're not much, if any, better off than if you'd run V.29 in the
first place.

> That's why direct FSK and AMI codes make more sense.

Absolutely agreed, *if*, and only if, the implementation of FSK 9600 in a given
area is done in such a way that fast tx/rx switching times are real, or not
an issue.

The one big win of a V.29 approach (usually run at 7200 baud in Japan, by the
way), is that you can populate any band that has voice gear available without
needing special radios...

Dunno that either is a clear winner.  If I were buying everything, and all my
friends were buying from scratch too, I'd go FSK with real data radios like
the Tekk or Kantronics units, but there's a *lot* of V.29 on the air in Japan
today, and I dunno that we can say as much for FSK in the US... makes me wonder
who's really got the better approach.

Bdale


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Tue, 18 Jun 91 11:58:48 EDT
Subject: DOS 5.0 on 286


I have installed numerous copies of 5.0 on 386 machines but today
was my first on a 286 with 640K and 384K extended. It works fine
the install knows how to use the 384K to move DOS and any TSR's
up there. I had 630K+ available to programs on my system. Since
the additional memory (384K) is extended adding more extended RAM
should allow you to load more TSR's and also have a RAmdisk, although
I have not tried that. Few 286's have more than the 384K.

So a temporary relief to NOS memory shortage sufferers should be DOS 5.0
That is if you have an AT/286 or above.

Doug


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Tue, 18 Jun 91 11:58:48 EDT
Subject: DOS 5.0 on 286


I have installed numerous copies of 5.0 on 386 machines but today
was my first on a 286 with 640K and 384K extended. It works fine
the install knows how to use the 384K to move DOS and any TSR's
up there. I had 630K+ available to programs on my system. Since
the additional memory (384K) is extended adding more extended RAM
should allow you to load more TSR's and also have a RAmdisk, although
I have not tried that. Few 286's have more than the 384K.

So a temporary relief to NOS memory shortage sufferers should be DOS 5.0
That is if you have an AT/286 or above.

Doug


----
From: "k1io@fn42jk 18-Jun-1991 1229" <goldstein@carafe.enet.dec.com>
Date: Tue, 18 Jun 91 12:33:56 EDT
Subject: Re: Innovative 9k6bps modem

I think this topic has been disucussed here before but I'll repeat
my view.  The V.29 modem used for fax is not suitable for packet radio
because it depends upon a lengthy training sequence, during which time
it performs adaptive equalization.  In a full-duplex environment,
where the carriers are always on, that's fine.  And in some packet
radio cases (fdx backbone point to point links come to mind), thhey
may work for the same reason.  But the key to fast throughput on
shared access channels is fast keyup time.  Old relay voice radios
with TxD times ar a problem.  At 9600 bps, the keyup time is longer 
than the packet time, which really kills the efficiency.  That's
always the case with V.29; even with the newer data-oriented radios
like Kantronics, Tekk and Ramsey, you'll need too long a TxD with V.29.

That's why direct FSK and AMI codes make more sense.
    fred


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Tue, 18 Jun 91 00:51:34 EDT
Subject: BBS mailer ??


I seem to be having a problem with the NOS bbs forwarder that maybe
someone can answer.

Sending mail to a group (expanded by alias) many of the expansions are
to mailboxes (/spool/mail/*.txt) on my system. A few of these are not
TCP/IP. The mailer (BM) expands the local addresses to call@wa3dsp
(wa3dsp being my call) - This is fine for tcp/ip - users use pop and
pick up there mail.

The problem is with the bbs auto forwarder. It attempts to send the
message as folllows - SP call@wa3dsp < wa3dsp - What this does is
set up a nice routing loop as the message is placed on the remote
BBS for remailing to me.

I know that I can place a 'replacement' address in the last line of
the block for this station in forward.bbs, but I would have to do this
for every known (and some may not be known) station that goes to this
bbs, would I not??

Should'nt the code be smart enough to know to remove the @source when it
is the source when sending to another bbs?


The replacement line in forward.bbs could be 

call   call < wa3dsp

but as I said a line would have to be entered for each call expected.
This would take mail for call with any @ address and just send it
to call with the forwarding info for this block.

Hope I make sense here. Maybe there is a very logical reason why it is 
this way.

Doug


----
From: geertj@ica.philips.nl (Geert Jan de Groot)
Date: Tue, 18 Jun 91 21:41:09 +0200
Subject: A plea when sending stuff

A quick note for all those wonderful people who sell modem boards,
HDLC cards and the like:

Please be VERY CAREFUL when you send a package to a HAM in Europe.
The government in the countries here have a wonderful 'feature' called
VAT, which, together with customs tax, makes us pay 25% (yes, a quarter)
on tax over the amount we payed you.

I guess that is not your intention.. How can you prevent it?
1. Make the 'value for customs' as low as possible. Do you really have
   to declare the cost of the package, or can you declare just the real 
   component cost? Most groups try to fund their own network on the 
   markup of the kits. I guess that markup can be left out on the
   'value for customs'.
2. Please note that the TAX goes for shipping costs as well!
3. I have not checked exactly, but a gift below a certain value is
   tax-free. Can't I donate your group some money, and can't you
   send me something as a gift in return?
4. I believe special, lower ratings go for educational material. Since
   the amateur service is a service of self-education, maybe there are 
   possibilities here..
I guess it is worth asking a customs agent!

Why do I bring this up? I just received a package of $140, and had to pay 
Hfl 70,- (say $35) for customs! Needless to say, I am not amused!
It certainly ruines the fun of receiving it!

Since I have has a similar 'accident' with another type of kit some time ago,
I thought it is a good idea to broadcast this. I can't blame anyone for not
knowing this, but I guess it is worth knowing if you start shipping..

Sorry for bringing up this non-technical item, but I think it is worth it..

Thank you,

Geert Jan, PE1HZG


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Tue, 18 Jun 91 10:05:13 EDT
Subject: MBOX (more)


I did alittle more "playing" around with the MBOX last night and
discovered the following..

First of all I like to use BM to mail. The BBS mailer is very limited
I.E. it does not allow the reading of other messages or files. I am not
being critical of it - in fact to put all of the nice BM features in it
would only make NOS larger. It is fine to have BM as a seperate program.

When sending mail in BM to a BBS user (vs. .ampr.org tcp) you have to send
it to just the call (no @) - 'mail w3xyz'  - this causes the message to
be deposited in a notesfile on your system - '/spool/mail/w3xyz.txt'

The BBS code (when it kicks) then searches the forward.bbs file to see if
there is a message in /spool/mail/*.txt that matches a forward address.
If w3xyz's mail should go to BBS w3aaa then under the w3aaa forward block
in forward.bbs the line - 'w3xyz w3xyz@w3aaa'  must appear. In fact all
calls that are forwarded to w3aaa bbs must appear here, line by line in this
format. The @ address does not necessarily have to be the bbs you are 
forwarding to. I.E. when forwarding to w3aaa - the line could be
'w3xyz w3xyz@w3bbb' - w3aaa would then know how to forward this to w3bbb
bbs.

The code automatically adds the '< yourcall' to the end. I found this out
when I did 'w3xyz w3xyz@w3aaa < mycall' and it constructed
'SP w3xyz w3xyz@w3aaa < mycall < mycall' !!

The thing to remember is that when sending mail in BM to a bbs (non tcp/ip)
station it must go to just the call. Putting an @address in the 'TO' field
causes it to look for a tcp/ip match in the domain file (unless it is your
own so it is placed in local mail). You must also have an entry for each
bbs in forward.bbs and under each bbs block in forward.bbs entries for
each call (file in /spool/mail/*.txt) that you want to forward to this bbs
with an address translation (as shown in the above paragraph).

All of this seems fairly simple but it is the interaction of alias/forward
etc. that is confusing.

Doug


----
From: Michael Chace <mikec@praxis.co.uk>
Date: Tue, 18 Jun 91 13:26:24 +0100
Subject: Innovative 9k6bps modem


Hi All,

Does anyone know what happened to this ?...... I wrote to those mentioned
but never got a reply. I'm convinced we need something like it to really
get 9k6 off the ground i.e *NO* radio mods required....


(From this mailing list about a year ago)

>From Jim.Grubs@f216.n120.z1.fidonet.org Fri Aug 17 12:43:42 1990
From: Jim.Grubs@f216.n120.z1.fidonet.org (Jim Grubs)
Newsgroups: rec.ham-radio.packet
Subject: 9600 BPS FAX modem on packet
Date: 15 Aug 90 15:18:29 GMT
Organization: FidoNet node 1:120/216 - Air Studio BB, Royal Oak MI


 * Forwarded from "PACKET - 13"
 * Originally from Jeff King
 * Originally dated 08-12-90 22:25

 @MSGID: 1:120/216 150cb329


             9600 BAUD (BPS) FAX TEST RESULTS


Conducted between WB8WKA (NOS TCP/IP) and WA8OOH (MSYS v1.08)

(Please reference my earlier posting "9600 baud FAX MODEM" for a more
detailed description of the circuit.)


Between 7/25/90 and 8/6/90, the amateur radio stations of WB8WKA and WA8OOH
tested a "V.29 FAX modem" chip, the YAMAHA 7109, between there respective
packet radio stations. Distances involved where about 7-8 miles over urban
terrain. Results where quite positive with respect to the performance of the
radio link. Equipment and power levels used at each station follow:


RADIO EQUIPMENT:


WA8OOH                                    WB8WKA
Livonia MI                                Farmington MI

ICOM28A (5 watts)                         KENWOOD 7950+amp (160watts)
MFJ 1270 TNC                              GLB TNC2A
MSYS V1.08 on IBM AT                      NOS on IBM AT

Additional radios where also tested. At WA8OOH, good results where also
obtained with a 215 Kenwood HT at 200-300 milliwatts. A Kenwood 7730 was
also tested with very poor results. Past experience with this radio and the
failure of any PL to function correctly on it may need further investigation.

At WB8WKA, tests where also run at power levels less then 160 watts with
excellent results, but due to the sharing of the radio with one of the
Detroit/Windsor TCP/IP lan's, running lower power full time was not practical.
In addition, a ICOM 2AT was tested at 100mw with excellent results.

Signal strengths at both stations where full scale, even at lower power
levels. Antennas used at WB8WKA consisted of a AEA ISOPOLE at 50' while
at WA8OOH we had a Hustler G7 at 20 feet. All tests where conducted on
2 meters.


THROUGHPUT:

As was to be expected, throughput took a dramatic step up. About one megabyte
of files where moved via tcp/ip, with the throughput hovering around 100
bytes/sec. While this is certainly nowhere near "9600 baud", it was a signifi-
cant jump over earlier tcp/ip testing at 1200 baud. It is thought that there
may be some incompatibilities between msys tcp/ip and net/nos. Tests will
be run latter this week between two msys stations to see if this figure can
be improved upon.

In AX.25 operations, ("user" to bbs) operation was simply put, a dream. By
using the "XF" command in msys, full packets where transferred. Setting "X22"
allowed a full screen to be transferred at a time. Throughput was about
1 page a second, which worked out to be about 6000-8000 bits per second. From
a "user" perspective (I was the user in this case) it made operating the bbs
much more enjoyable. As many of our LAN's in the southeastern MI area our
crowded, the additional speed did not go to waste.

If I may quote WA4DSY, "Oh where oh where is my HIGH SPEED DIGITAL"? What this
means of course, is that we where not able to fully exercise the modems due to
MSYS and/or our TNC's not being able to go beyond 9600 baud. The tnc's where
modified for 19200 baud operations but we experienced dropped characters. In
any type of KISS operation, it is important for maximum throughput, that your
DATA link (async link) be at least twice as fast as your radio link. As we
where not able to achieve this, then our hope is that much faster throughput
can be obtained.


GENERAL IMPRESSIONS:

Audio setup is much more critical. Tones will tend to sound undermodulated.
In addition to audio setup, a "keyup delay" circuit must be setup as well.
This is due to the fact that these modems send a "training sequence" upon
keyup. This must be held off until the radio is fully keyed up. (generally
100-200ms) Once these parameters are set up, things seem to be fairly
stable and the modems can be relied upon in day to day operations.

IMPROVEMENTS:

A easier method for tuneup needs to be developed. If possible, mounting inside
the TNC would also help. Current carrier detect in YAMAHA chip is useless.
Have been unable to get state machine DCD to work on this chip but it is what
is needed. Current layout use's +-5V, this needs to go. Must run on only +5V.
Also will add programming header and mode select DIP switch.

Existing PC (a carbon copy of the PRUG circuit board) needs to be improved.
Quite a bit of digital noise exists on this chip and a re-layout of the
PC board would help greatly.


THOUGHTS:

While my original idea of the use of this modem was "networking", more and more
I am beginning to feel this will be the next step for the end user. In many
applications such as the DX cluster, TCP/IP and bbs operation, increase of
speed on the user LAN is becoming more important. While this modem should be
a fine performer on our "network backbones", the ease of implementation and
the fact that IT CAN BE USED ON EXISTING RADIOS UNMODIFIED should be quite
appealing for the amateur that wishes to increase LAN throughput.

WHATS NEXT:

In the next week or two, I need to re-layout out the circuit board to include
the improvements I have found. In addition, I DESPERATELY need schematics for
TNC's. I have schematics so far for the TNC1, TNC2, PK232 and DRSI. If you
have schematics for any *other* tnc, PLEASE send me a copy to the address
below:

Jeff King WB8WKA
22816 Maple Ave
Farmington, MI 48336.

Also, if you would like copies of the article describing this chip, please
send a SASE to me at the above address.

BETA TEST:

So far, about 16 people have expressed interest in participating in a beta
test of this modem. What this basically means, is that we will all get to-
gether and make a group buy of parts and such to reduce our costs. In addition
of course to the sharing of information that a beta test implies. With a
professionally done PC board and all parts I expect costs to be on the order
of 60-70 dollars. This is of course assuming we can get a decent discount of
the YM7109 (fax chip) as it alone goes for $55!!



73's

Jeff King WB8WKA
Farmington, MI
44.102.0.52        @WA8OOH.MI.USA

--- TAGMAIL v2.30
 * Origin: The <<< Air Studio >>> BBS 313-546-7045 (120:216) (1:120/216)

--  
  |\/\/\/|
  |      | Jim Grubs - via FidoNet node 1:234/1
  | (o)(o) UUCP: ...!ncar!asuvax!stjhmc!w8grt!120!216!Jim.Grubs
  |     _) INTERNET: Jim.Grubs@f216.n120.z1.fidonet.org
  | ,___|  ____________________________________________
  |   /     "I wanna go to the ham radio National Park
 /____\         of the Mind and ride the NOS!"



----
-- 
*****************************************************************
   ___  ____  ___    _  _ ___ ___   ___ ___ ___     ___ _  _
  /__/ / / /   /    /\ / /__   /   /__//__//   /__//__ /\ /
 / \  /   / __/_   /  / /__   /   /  //  //__ /  //__ /  /