You would be amazed at how many people fail to realize the strengths of an already designed protocol for dealing with slow and saturated links.

TCP already deals with route saturation. It was built for 300 bps links.

I've been talking in the SGARN group, and it doesn't appear much at all is "designed" really, as far as a network goes. A few stations continuously sending bulletins is far from a "network", and not much different than what we have already with things the Amateur Radio Newsline.

The HF system I am utilizing is new, and is an attempt to innovate rather than emulate.

One of the more self-destructive Boo-boos in the Packet network was it being a case of emulation rather than innovation. Old stuff was kludged up to work more or less over the radio, but it was designed for wired networking and so of course it never quite worked right. - The long range "backbone" links were significantly slower than the user access and local communications, the exact opposite of the conditions that wired networking models like TCPIP are designed to work with.

By your standards perhaps the SGARN net is not "designed" because it does not use the system that you are familiar with. To those of us who are working on SGARN though, the situation may look and feel a little different.

It is my feeling that adding TCPIP protocol would only serve to complicate matters, reduce participation, and ultimately introduce more setbacks and delays than advantages.

You can of course setup and operate the kind of network that you prefer, as SGARN network operation will do nothing to prevent you from doing so.

If what you are doing is more successful and gets more participants, I will then be happy to acknowledge that that is the case.

Note that I'm talking about doing, not theorizing. - You will have to actually do something that does the exact same task better, not just talk theory.

73 DE Charles, N5PVL

I'm not implying you should employ TCP... Just saying it's already designed to handle slow links (Such as 300 bps links).

Now, that being said, I would love to see the system. It's, shall we say, lacking in documentation.

For example, lets say I want to start my own network node. How do I begin?

I'm not implying you should employ TCP... Just saying it's already designed to handle slow links (Such as 300 bps links).

Now, that being said, I would love to see the system. It's, shall we say, lacking in documentation.

For example, lets say I want to start my own network node. How do I begin?

Yes, documentation is always the hardest part to do right when something new comes up.

I would recommend that you obtain the software and familiarize yourself with it. The help files for W1HKJ software are really decent.

The FLAMP software will show you which digital modes are currently available for multicast operation.

The NBEMS folks transmit AMP multicasts as part of their EMCOM training activities. The transmission schedules can be found on the NBEMS Yahoo! e-Group. Reading the mail on those transmissions will serve best to show how the system basically works.

The AMP 3.0 amateur multicast protocol can be downloaded or viewed at w1hkj.com

Once you have done this, contact me for information on the specific setup of FLDIGI and FLAMP for SGARN service on HF, and on how to protect your HF rig from heat build-up which is the single most significant limiting factor for long-term, continuous-duty service.

The cooler you can get your rig to operate, the more power or bandwidth your station will be capable of.

Power will give you a larger coverage area, which is more significant than bandwidth for measuring the effectiveness and efficiency of SGARN HF multicast systems, which distribute perhaps half a dozen or so ARRL bulletins and occasional AMSAT bulls that are not too lengthy, along with SGARN bulletins in text and HTML format. - The point here being that in order to keep the update cycle of the multicasts at a manageable level, the overall amount of data in a SGARM HF multicast transmission must be kept as small as possible.

The software is available at w1hkj.com

I am working on tutorials for both Server and Client stations, but can't say when I will have them ready. The sticking point here is that the W1HKJ software is being actively developed, so if you show a screen-shot of the current version, that image will be obsolete in short order. Consequently, I will have a craft a tutorial that can be quickly and easily updated.

Copyright 2000-2019 eHam.net, LLC
eHam.net is a community web site for amateur (ham) radio operators around the world.
Contact the site with comments or questions.
WEBMASTER@EHAM.NETSite Privacy Statement