[linux] LinLink

[Rob Roschewsk]

I would really like to see a "rebirth" or "transformation" of packet. Some
things I think need to be considered:

- SPEED -
At a minimum needs to be on par with modern dialup access .... at best
comparable with DSL or Cable. Sorry I'm not an RF engineer so I can't lend
much help here but would love to learn.

- IP -
It should be IP based. Lots of folks know how to code for IP and there is
plenty existing stuff out there that can handle it. AX.25 can remain as the
layer 2 frame.

Problem arises with how to route it??? At one point I think we tried
coordinating IP addresses and figured we would route in a particular
direction based on IP ... coordination down to the individual client level
is burdensome at best. Whatever the solution it needs to be dynamic. Maybe
we need a multi tiered DHCP or BOOTP. Coordinate regional IP blocks and let
local routers give out leases for client IPs. If I travel to another
location or even if I'm mobile my client detects it can't hear the last
router and sends out another BOOTP. Once I detect my IP change I send out a
dynamic DNS update so that someone can find me.

RIP could be used at the router level to determine how one router passes
packets along to the next.

So I think reasonable goals are a data rate of 56Kbs for mobile and 1Mbs for
base stations.

Thoughts????

--> Rob

----- Original Message ----- 
From: "Eric S. Johansson" <esj at harvee.org>
To: "TAPR Linux Mailing List" <linux at lists.tapr.org>
Cc: <hfsig at lists.tapr.org>
Sent: Wednesday, August 04, 2004 9:44 PM
Subject: Re: [linux] LinLink


Walt DuBose wrote:

  > Of course LinLink had two thrusts...on is high-speed on HF the other is
> high-speed on V/UHF...and by that I mean 19.2 KBPS as the botton and 54
> to 100 MBPS as the current top end.

thank you for clarifying.

> MFSK16 is more robust than MT63 but the not as fast ans MT63.  I belive
> that improvements can still be made in MT63's modem to make it faster.

cool.  I'm not married to a particular protocol or modulation scheme as
long as as it gets the job done.  like for instance:

http://translate.google.com/translate?hl=en&sl=pt&u=http://paginas.terra.com.br/lazer/py4zbz/hamdream.htm&prev=/search%3Fq%3Dhamdream%26hl%3Den%26lr%3D%26ie%3DUTF-8

which is probably going to get butchered by the mail client.  google for
"hamdream" and have it translate the Portuguese to English.  looks very
promising and in fact looks like it will become the next standard for
transmitting voice and pictures for hams.

>>in the end however, remember that it will be the e-mail infrastructure
>>that is important not how you get e-mail around.  asking emergency users
>>to use unfamiliar software to communicate in a time of high stress we'll
>>cost us credibility points.  If we can drop in a box and RF link and
>>they can use ordinary laptops with tools like Eudora or Thunderbird to
>>get their job done, then we win big-time credibility.
>>
>
>
> The message entry form is important.  I have Web Mail inputs that have
> been used in E-Comms and liked.  Everyone know how to use the web.

cool.  it's good if it works.  But again, use standard, well known by
any network connected techie infrastructure and it will be a huge
credibility win.

>>we win bigger credibility if they can keep working over the Internet
>>with minimal interruption when services are restored.
>
>
> The idea is to use the Internet to our advantage...however, if it
> becomes a burden then it won't be used.  The system will be designed
> with the idea that the Internet will not be available.

for communications within a disaster region, yes.  It will become its
own Internet.  However, it's also extremely important to terminate a
route on the Internet itself for communications with the regions outside
of the disaster for all the reasons we know and love.  This is why I
argue for letting the Internet standards try the implementation of the
infrastructure rather than letting the RF transport drive the
applications.  Unless of course there is an extremely compelling and
unique reason for doing so such as the GPS "here I am" tool hams have.

---eric


-- 
Speech recognition in use.  It makes mistakes, I correct most

_______________________________________________
linux mailing list
linux at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/linux