[FADCA] Autum TAPR Newsletts has it all!

[email protected] [email protected]
Sat, 9 Nov 2002 13:05:05 -0500


I just looked at it the other day too. 

.
> 
>   2.4GHz +13db gain  yagi antenna  - cute little thing would 
> make a 5w amp a
>      big fella.

I have some links to material describing the use of DBS dishes
for 2.4G. I have two of them and plan to try them as soon as I
can find them. Those give you some good gain and very nice 
directionality.
> 
>   Use of e-mail messaging for emergency planning - someone 
> else sees The
>      Light.

Finally, it starts to soak through.

> 
>   Flex-Net is growing in the US North East - It is obvious 
> that interest in
>      ham digital is growing.

You know we had one of them here in Tampa when we had the NCC
here in Tampa, we talked to them about handling X.121 addresses
the treatment from them was a real cold shoulder, and as I
understand it, their protocol is still proprietary, I think some
of the LINUX guys have been trying to reverse engineer it but
they have got no help from the FlexNet people. I would like to
play with it and see how much of what I have been told is true
and how much is inflation of the truth. It is my understanding
that thought the network does all kinds of self corrections that
there is a enormous amount of over head on the trunks between
nodes, in that sense FPAC/ROSE is very light, once the link is
set up there is only 3-5 chars of additional overhead at the net-
work layer. LINUX FPAC does can be made to do more network disc-
overy activities, but the feedback I have gotten is that many
prefer the lower overhead in order to obtain greater throughput.

Another point that I am not sure of with FlexNet, FPAC/ROSE both
support what is known as the "M" bit in the packet headers, if
your running IP and fragging the IP frames at the AX.25 level
to a smaller sized packet you can then send the IP stuff in
only the first packet of the IP frame, the "M" bit is set and
does not get reset until the last packet that builds up that
IP frame goes out. The end where the IP frame is rebuilt then
looks for that reset "M" bit and does it's magic with the data
on the far end. TNOS was the only software that I know of that
took advantage of this, though I suspect that LINUX Ax.25 and
the IP interface can also do the same thing. Sure makes for
allowing IP to go over the network much faster, that way you
do not have to frag the IP at the AX.25 layer which adds
40 bytes of over head to each one of those AX.25 packets.

This is the bugger with using NetRom and it's derivatives as
you have to manually set up your data source to take into
account the additional IP overhead when sending data over
NetRom et al.

The Germans have done quite well in propagating FlexNet in
the EU as well as some parts of this country. When we get
the switch sites converted to LINUX we can test the open
source version and see how it runs. There is a PC based
version of FlexNet, but I think the big FlexNet networks
use dedicated controllers to do the networking.

One other point, FlexNet like NetRom keeps a lookup table
of all of the nodes on the network, FPAC does not do so,
it routes on addresses so does not need to keep such a 
large amount of data in memory. The more distant a switch
the less you need to know about it.

Because FlexNet runs on a larger processor, it can store
a much larger model of the network in memory, but nodes
need to propagate through the network, and since there is
not a "addressing" scheme it does not have the simplicity
of offering such things as our 411 and 555 addresses. I
am sure they have something similar, but again have not
had a chance to use it so I can not say for sure how it is
all handled except that the network is self building and
propagating, and each node has to build up the whole network
model in order to be able to route to any other node on the
network, so the more distant a node is the longer it will
take for that data to propagate across the network.

Addressing either X.121 or IP is much more elegant for
routing reasons.


*****************************************************************
This e-mail and any files transmitted with it are confidential and are
intended solely for the use of the individual or entity to whom it is
addressed. If you have received this transmission in error, please notify
the sender immediately and destroy any hard copies you may have printed and
remove all copies of the e-mail from your hard drive. Opinions, conclusions
and other information in this message that do not relate to the official
business of Utility Partners, Inc shall be understood as neither given nor
endorsed by it.

Visit us on the web at http://www.utilpart.com 
*****************************************************************