[FADCA] BASICS for SUN CITY

Chuck Hast wchast at gmail.com
Sun Dec 5 21:40:42 EST 2004


On Sun, 5 Dec 2004 10:37:44 -0500, bud thompson <budt at cfl.rr.com> wrote:
> NOTE: Subject Changed from Re: Sat. Metting at Hamfest
> 
> See my bottom posting below..
> 
> bud
> 
> ----- Original Message -----
> From: <Kg4fcd at aol.com>
> To: <fadca at mailman.qth.net>
> Cc: <RNBishop at aol.com>
> Sent: Saturday, December 04, 2004 20:23
> Subject: [FADCA] Re: Sat. Meeting at Hamfest
> 
> > Bud,
> > After the meeting on Saturday Dick Bishop Pres. of the Kings point Amateur
> > Radio Club and myself had a short conversation on getting a switch in Sun
> > City
> > Center.
> > With our fingers crossed and the help of both Radio Clubs along with some
> > help from the developer WCI we feel it could be and should be done.
> > I have been ask to contact you and get a list of equipment needed,
> > I would like two list:
> > One, an ideal set up.
> > Two, a bare bones set up
> > When we have that we will set up a meeting of those involved including our
> > local CERT group and go from there.
> > Also, we would like to set up a demonstration by you regarding the net
> > work
> > and how it functions. I understand that your schedule may take that out to
> > February and that is fine.
> > I think we have some interest going here and I want to follow up on it.
> > As for Paclink AGW. Where can I find that software? I have used AOL search
> > and come up with a blank.
> >
> > 73
> > Virgil Gibbs Kg4fcd
> > Manager NTS Eagle Net
> > WCF Information Officer
> > Mentor Online EMCOM Study
> > Packet Mail Box Kg4fcd-1
> > _______________________________________________
> > FADCA mailing list
> > FADCA at mailman.qth.net
> > http://mailman.qth.net/mailman/listinfo/fadca
> >
> 
> Hi, Virgil -
> 
> We can plan a demonstration/presentation for your local group there anytime
> after the Orlando Hamcation.  I request that you have as many served agency
> representatives in attendance as possible.  Best get a schedule early as our
> dance card gets filled up quickly and we can't do very many too close
> together!  We'll need a computer to large screen projector, and it would be
> very beneficial if there were a Telpac node installed that we could reach on
> 2M for the demo - more details on that later if needed.
> 
> On putting a full network switch at Sun City - I'll defer to Chuck KB4DJT
> and Gary KC5QCN to counsel us on whether a full switch is needed there and
> we can from there.  They know not only a lot more about the existing
> coverage in the area, but any plans for near term changes.  You might not
> need a full switch which would save a lot of effort and costs.  On the other
> hand, if Sun City is a good spot to not only cover your 2M user LAN but also
> connect to a neighbor LAN/switch via UHF using beams, that would help not
> only your users, but benefit the network as a whole.  A switch, of course,
> requires more hardware, thus more expense and maintenance.
> 

I see my name being taken in vain a lot so I suppose I should jump in here.
(By way the call is KP4DJT, got it while I was a kid in Puerto Rico and never
changed it)
Sun City will be about midpoint between Tampa and SRQ. If the antennas support
structure has some altitude to it, it would be a very good network site.

> > I would like two list:
> > One, an ideal set up.
> > Two, a bare bones set up
> 
> I preface this with the fact that I do not know the lay of the land there,
> so the following information is generic and may be used almost anywhere a
> group is needing to become part of the existing network.  (I'm advising a
> group in Texas and have included the contact in cc:)  My counsel can best be
> provided as building blocks - barest bones to full switch, as much of the
> hardware is the same and may simply be added at successive stages, if the
> switch is not installed initially.
> 
> SITE - An initial test requires a site from which the closest neighbor
> network switch(es) can be reached on the neighbor 2M LAN.  This will require
> an antenna with sufficient elevation (likely at least 100 ft in most cases)
> that can provide the following:

At least, but could work with 50 ft, but coverage would be limited. They would
have no problem accessing the neighbor switch sites in TPA and SRQ, and
probably could get to Arcadia also.


> 
> (1) With 60w output (or less!) on two meters cover the entire area of your
> users' interest - which in most cases should not be more than about 30 miles
> in radius.  To cover much more would likely require at least 150 ft antenna
> elevation.  (2)  Reach the nearest existing switch with reasonable S/N on
> 2M. If this is not possible, jump now to BARE BONES OPTION #2 below
> 
> > . . .  a bare bones set up
> 
> BAREST OF BONES (initial testing phase) -  Install a digipeater on the same
> 2M frequency as the existing neighbor switch .  This simply brings users in
> your area into the area of the switch, thus extending the effective range of
> the existing switch.  For this to work, your site must have sufficient
> antenna height to see the existing switch 2M LAN.

This is true 'barest of bones' sun bleached ones at that... It is good
for testing but
unless the site is in a bowl, you will probably have no problem
getting to either
neighbor switch. We can always drive down with the "CYHMN-mobile" (Can You
Hear Me Now) and ask both switches on each side how well they can hear us
with a 20 foot mast and the equipment I have in the van. I suspect that we will
be able to hit both SRQ and TPA no problem, indeed we were able to do so
from the hamfest, the only issue was that the digi in the Kenwood radio did not
pass level 3 frames so that killed that demo.


> 
> Antenna - Use a 2M vertical gain antenna at the height to cover your users'
> area with no more than 60 w.  Where sufficient antenna height is attained,
> in many cases 30W may  be enough. Unless a 60w radio is available w/o
> significant cost, I suggest  starting with a 2M FM mobile radio that can put
> out at least 30w.  It is likely not prudent to add an amplifier just to get
> to 60w. Avoid small hand held radios for any of this work.

TPA is 25 Mi N, SRQ 25 Mi south, I believe that they are looking at putting
a switch at the Manatee EOC, so that will put a switch no more than about
15 miles from you. I think that a 25-30 watt radio is more than enough. You
may not need even that much. Again testing will tell us.

The cost of the 3db to go from 30 to 60 watts is not worth it. Most
packet activity
is done from more or less fixed locations anyhow with in most cases antennas
which are generally better than the usual mobile setup.


> 
> Feed line - For the tests, use any RG-8-sized (or larger) coax available,
> but keep in mind with 100 ft of coax there will be significant losses if the
> coax is too small or too old.  The ideal situation would be to use existing
> coax on the tower which had been originally installed for vhf or uhf
> application.

Better to use the 9913 or similar products particularly for the UHF piece.
The VHF piece can probably get away with GOOD RG-8.


> 
> Lightning Protection - in Florida this is a must.  Use Polyphasors (or
> equal) placed at the proper position in the feed line, usually right at the
> hut at a single point ground.  If you are piggy backing on a commercial
> installation, just follow the layout there and do as has been done by the
> existing users of the site.  We hams must be the best neighbors of a shared
> commercial site as we are usually non-paying guests and want to maintain a
> low profile!

YES!!!

> 
> Radio - For testing this bare bones set up, any 2m ham band radio will work
> for 1200b packet.  It would be beneficial if the radio had a true 'data
> port' for Transmit Audio (TXA), Receive Audio (RXA) and Puss To Talk (PTT).
> Radios with such ports may be run on 1200b packet with the squelch full open
> which offers several advantages.  If you must use the speaker jack output to
> supply RXA to the TNC, use a "Y" audio cable and small external speaker to
> assist in setting things up.
> 
> TNC - Any  functioning 1200b TNC you can dig up will work.  MFJ, Kantronics,
> PacComm, etc.
> 
> The TNC is initially set up with a computer so that DIGIPEATING is ON.  The
> TNC will have to have a MYCALL-SSID that cannot be used by any users on the
> frequency, and can usually also have an 'ALIAS' (e.g. SUNCC, etc) for
> digipeating.  There are other AX.25 parameters that Chuck can provide for
> the area.  The computer is not required for operation of this digipeater,
> just for initial set up.  If you use a typical Kantronics TNC (KAM, KPC-3,
> KPC-9612, etc..) you can do some modification of the TNC parameters over the
> air using  the REMOTE command, thus saving the requirement for site access
> and a trip if there is any need to trim the parameters. Other brands may
> also offer REMOTE.  Most TNCs also provide a Personal BBS or Mailbox that
> can be used for testing around the area - allowing a single person to do
> range testing w/o the need for someone else being 'live' to help.  Over
> time, however, using a PBBS routinely on your digipeater might provide
> bothersome interference on the neighbor LAN.  There is nothing wrong with
> using it for initial and on-going testing of your local coverage.

I at best view a digi as a 'test environment'  the [hidden termianl syndrome] is
worse case in this particular scenario, users on the main lan can not here the
users who are accessing the network over the digi and you will get a lot of
collisions, but for testing and given that there is not much user base right now
it is not a great problem.

> 
> BARE BONES OPTION #2 - Your own Sun City LAN - and half a switch (well
> almost a switch.)
> 
> Antenna - Use a vhf vertical gain antenna and a 6-element or larger beam for
> UHF.  Using two antennas will require two separate feed lines. (If you are
> installing a new VHF vertical and it is not the highest antenna on the
> tower, consider a dual band VHF/UHF, in addition to the beam.  The other
> side of the dual band antenna might come in handy later.  However, if the
> tower you are on is prone to lightning attacks, you best seek local counsel
> on whether a non-DC grounded antenna is wise to install.  Your local users
> will be on VHF on a separate frequency than the neighbors' LANs. This will
> require frequency coordination through FADCA.
> 
> Feed line and lightening protection is as before - though you'll need two of
> each!
> 
> Radios - The same radio as above may be used for 2M.  You will need a 9.6kb
> capable UHF radio on the backbone frequency to reach  the neighbor switch.
> We have not thoroughly tested the typical Kenwood, ICOM, and Yaesu "9.6kb
> ready" radios, but most work satisfactorily providing the s/n is very good.
> None work acceptably on weak signals, and likely are not acceptable in high
> RF environments such a as sites where a lot of commercial and/or amateur
> devices are co-located.
> 
> TNC - Using a single KPC-9612 and the two radios, your group will  have a
> "private" 2M LAN and be able to 'switch over' to the UHF side for network
> access.  As above, a computer will only be required for initial
> configuration and the TNC parameters may be modified remotely.
> 
> NOTE: Where ever 9.6kb is employed any 'plug 'n play' concept must be taken
> with a grain of salt.  That said, there are plenty of experienced folks
> close by who can help set this up and after that all should work fine.
> 
> The 'band switching' function of the KPC-9126 is accomplished in the
> firmware-based KA-NODE which is similar to TheNet or an X1-J4 node.
> However, it is not automatic as with an FPAC switch.  Users may navigate
> through the node from the LAN side to get to the network switch on the UHF
> backbone, usually requiring two or three successive keyboard commands for
> network access.  The Paclink AGW Program used by your users for E-mail over
> ham radio can be programmed with scripts to provide automatic connections
> through the KA-NODE then on to the network and a TelPac node.  However, the
> DOS version of FPAC cannot automatically readily negotiate from the switch
> back through the KA NODE to your local users.  (We can check with Chuck to
> learn if the LINUX version of FPAC can do that.)

I assume that you have to connect to the KA-Node and then issue a connect to
the target via the switch, address. What is the reverse issue on this?
In the past
when we had Ka-nodes in this area, you would just connect to the Ka-node and
then pull a heard list and see if your target was heard on the other port. Was
never a issue except like going out of the bugger you had to do a dual level
connect.

We should avoid non-network devices on the trunks, indeed the "flat network"
between TPA, SRQ, ARC, and some of the other gear down there needs to
be re-worked at some point, I do not recommend adding another device to
that network if we can avoid it. We already have hidden terminals on the north
and south ends of the link


> 
> NOTE:  For e-mail over ham radio applications, it is not necessary,
> appropriate, nor even possible for users' Paclink AGW in users' computers to
> accept an incoming connect request, so the fact FPAC can't make the
> negotiation through a KA NODE is moot.
> 
Is there a way to issue a connect through a KA-node and have it do X-band
digi? If so then it is quite easy to do so.
Here is the connect string to do so:

c target v switch,address,Ka-digi

If the Ka-node can cross band digi it should then go in the port that is shared
with the switch and exit on the other port, and visaversa.


> * * * *
> NOT SO BARE BONES OPTION - Your very own switch... Highly recommended right
> after you know you can reach another neighbor from your side on UHF with a
> beam.  Skip all the above if you can other than for testing.

This is what I would recommend from the get-go. A dual port is not such a big
deal, and it is quite easy to add ports to it as it grows. With the
proper selection
of hardware you can build a quite solid and low maintenence switch.

> 
> If is it determined that you want to go beyond a digipeater (or are not in
> digipeater range and need a UHF beam to reach the nearest network switch),
> then put up an FPAC switch at your site.  I suggest you consider this even
> before the BARE BONES OPTION #2, and certainly if Chuck recommends you put
> up a switch to extend the network between one switch and another.
> 

I do recommend it. With FPAC Linux we can provide a lot more user services
and automated calls to commonly used services.

Indeed I hope soon to have the telpac application tested out, allowing for the
elimination of one more box and integrating it into the switch.


> Antennas - as  in BARE BONES OPTION #2 except you'll need one more UHF
> antenna if this is a complete Network Switch.  If this switch is only needed
> to bring your area in the network, you'll only need the two antennas above.

I would like to see this become both a user access device and a transit trunk
device so it provides multiple paths out of the area and also provides for a
good point to go to in order to have good strong signals. We do have issues
with the SRQ link even now with inversions and other nastieness given that
the path is either not truely line of sight or it comes so near the earth as to
put the path well in the first fresnel zone causing all sort of messy multi-path
issues. Arcadia is even worse.

> 
> Feed lines and lightning protection - same as above or three for a full
> switch.
> 
> Radios - The same 1200b radio will work for your 2M LAN.  You will need a
> 9.6kb capable radio for each of the UHF ports.  I will defer to Chuck - but
> if you have any financial support, I'd suggest you consider the Tait radios
> or similar that Chuck was demonstrating at the Ham Fest.  The Motorola
> Mitreks (circa 1980s) we are using for 9.6kb on our three switches here in
> E. Central FL work swell.  However, we have an average of $100 and five to
> ten man hours of time in conversion, modification and wiring to TNCs, powers
> supply, etc.  This work is not for the faint of heart.  Something like the
> radios Chuck was using would be truly Plug 'n Play - and there is a lot to
> be said for that.  Where there are more bucks, get a similar VHF radio for
> the LAN -it has much better co-existence tolerance and looks better in the
> cabinet!  (Also if most of us used the same radios, sharing spares would
> work out swell when one had to go in for repair.)
> 
> Chuck will know the details, but the Tait data radios are in the $450 range
> in single qty and might come down to $400 in qty of ten- only a guess on my

1-5 $440 Above 5 it drops by $50.
There are even greater reductions with higher order counts but you
need to contact
Linda at 813.874.2980


> part.
> 
> TNCs -  Use one KPC9612 dual port - 1200b for the VHF LAN and 9.6kb for one
> of the 9.6kb backbones.  If you have a 2nd backbone, you can use another
> KPC9612 and not use the vhf side, or a single port 9.6kb TNC such as PacComm
> Spirit 2.  I'm testing an AEA PK-96 now and it seems to work fine. A
> benefactor has donated three for the Melbourne switch and I plan on putting
> all three there (vhf LAN and two backbones all 9.6kb).  The price was right!
> I'm less partial to the Tiny 2s with the add on 9.6kb daughter board, but
> only because all mine were picked up for junk prices and when I need to do
> any trouble shooting it is more of a chore. (So much so I send them to the
> W. Palm Beach Gang who has more experience and patience than I.)  However,
> those TNCs work just fine once set up.
> 

You wanted BERT testing ability those Tinys have the BERT stuff on the RUH
modem board, they may not be pretty, but you can not beat the RUH modem
for decoding data, it will pull signal out of places where the others
go to sleep.

Both the Spirit/Sprint, Tiny and the MFJ units use the RUH modem so I know what
the modem can do, and the BERT piece is a part of it on all of them.


> The PK-96 will work either 1200b or 9.6kb (not both at the same time.) A
> neat option for this three port switch would be three PK-96s with one set
> for 1200b on the user LAN.  I believe the cost of these is $250 ea or so.
> The costs of new KPC-9612s is $350 or so.
> 
> NOTE: I believe there is support for sound card packet modems with LINUX
> FPAC - Chuck will have to address this possibility.  Because of the cost of
> TNCs, this option needs to be investigated as soon as possible.  However,
> even with LINUX I'd guess this will require a somewhat faster computer
> processor than w/o.

The sound card support is at the AX.25 level all the rest of it rides on top of
the AX25 piece so if it works it works. I have not gone there yet, trying to get
too many other things going, and I like to see the little flashing LEDs as the
data moves back and forth across the wires and radios. The sound modem
would allow you to get rid of TNCs possibly more than one depending on
what the sound modem can do. I do not believe that the sound modem piece
demands so much under Linux, I will see exactly what is needed using the
sound cards.


> 
> Computer - Now you will need a computer - not much of one - Seek counsel
> from Chuck on computer requirements as I recommend you go right to LINUX
> FPAC and skip over DOS FPAC.  LINUX FPAC will support both radio ports of a
> KPC-9612 with a single comport so you'll only need two comports for a
> three-port switch.  There are other details (i.e. 6PACK) that Chuck will
> soon elaborate on for all of us but that is not a issue of expense.   In a
> discussion last night over dinner three of us came to the conclusion that a
> laptop such as Chuck was using for his demo at the Ham Fest would really
> offer a lot for our remote sites.  However, where there is a satisfactory
> hut with air conditioning and space, a standard desk top or tower case
> computer will work find.  Speed and memory requirements are very minimal
> compared to Windows OS.  Keyboard/mouse and monitor are only needed for
> configuration.  I expect configuration files for LINUX FPAC can be
> configured remotely; DOS FPAC can.

A old pentium or 486 is more than enough. Get it with a bit of memory so it can
do other things while doing the FPAC thing, Particularly if we put the TelPac
app in there. I do not know how much that uses, but leave it some leeway.
Also you could share the switch with a BBS (I prefer a separate machine for
the BBS thing, but there are lot of them running both on one machine)
The laptop is nice because it does not demand much space nor power. But
they can create problems too, use what you can get your hands on.

> 
> Internet connection at your site?  Oh, would that be beneficial!
Yes.


> TELPAC - If you have access to an Internet connection you can run a TelPac
> Node which will (1) give your local users e-mail access w/o going through
I hope to have the Linux app tested and if it proves to be as it is said to be
then that will eliminate the need for a additional box of course providing you
have internet access to your fpac switch. TELPAC needs the internet connection.


> the network to another LAN/TelPac, and (2) offer mutual aid for your
> neighbors who could get to your TelPac through the network when needed.  For
> a TelPac node you would need to have a computer running 24/7 (Win 98 or
> later MS OS).  You will have to have Internet port 12001 'outbound' open for
> that.  I'm not certain that the TelPac node can be run at the same time on
> the same KPC-9612 TNC as would be used in the BAREST OF BONES or BARE BONES
> OPTION #2 above but it might be. I can check that out.  However, with  LINUX
> FPAC I would expect Chuck can make that work some way.  We are treading on
> new territory there.

Under Linux the TelPac node is just another app that can be called, either as
a alias call on the fpac machine or a command on the fpacnode, and/or both.
I just need to test it out and give you guys a report then we will go
from there.


> 
> Winlink EMCOMMs PMBO - With the internet connection you will be able to run
> a WL2K PMBO to support 'hubbing' of e-mail messages among your local group
> when the internet connection is down.  There is no more hardware to include
> for this, but another Internet port will need to be open (I forget which
> one.)  It would also be beneficial for Mutual Aid Communications for port
> 12001 to be open both inbound and outbound.  (All this is password
> protected.)  If necessary, all this could be inside the DMZ of the site.
> 
> Okay - I hope you can use this information and make the lists of gear you
> need.  If you have any questions, just let them fly.
> 
>

Bud, that was very good. Now we need it on a power point!!



-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."


More information about the FADCA mailing list