Hello Guest

Recent Posts

Pages: [1] 2 3 ... 5
1
SGARN / SGARN HF Multicast SYSOP Guide
« Last post by USPacket on September 17, 2013, 05:04:09 PM »
SGARN HF Multicast SYSOP Guide

Mission and Philosophy:

The Second Generation Amateur Radio Network (SGARN) is an attempt to build a global, all-amateur radio network that will succeed where the Packet network failed, by avoiding the miscalculations which affected the Packet network so adversely.

See the article "SGARN Basics and Philosophy" elsewhere in the SGARN section here at USPacket to see the big picture. Here the discussion is narrowed down to the HF section of the SGARN network, and how to participate as the SYSOP of one of the HF multicast servers.

The SGARN HF network is a self-organizing multicast network, generating data streams that an unlimited number of amateurs can tap into at any time to receive the latest information of interest to amateurs. The information will come from recognized and respected sources, not some fellow ranting on a soap-box, and the SGARN multicast network model has a reasonable expectation to achieve wider coverage than the old Packet net at its peak, by several orders of magnitude. Global coverage is not an unreasonable goal for a self-organized multicast streaming data network.

Apart from amateur radio operators, no other group has a reasonable expectation to build and maintain an independent global information network. This is our unique privilege and challenge as hams.

This guide is set up in sections, covering first the software, then the equipment, then at last an operation and content guide.

Read the whole thing.

Software:

SGARN has adopted W1HKJ's programs FLDIGI and FLAMP as the best possible software for our use on HF.

To transmit the SGARN multicasts, you will need the current version of FLDIGI and FLAMP from the W1HKJ website.

w1hkj.com

At the top of the page there is a DOWNLOAD link. Go there and download FLDIGI and FLAMP for your operating system. There are versions available for Windows, Linux and OSx.

-- Software Setup:

To operate a Server (transmitting) station, you must run FLDIGI, then FLAMP so that they run together. Consequently, the SGARN-specific setup for FLDIGI will be described first, then the setup for FLAMP, then a few notes about running them together to transmit the SGARN multicasts.

-- FLDIGI:

You may already be using FLDIGI, as it is the most popular digital multimode program for amateurs at this writing. You will need a ham radio soundcard interface which connects your computer and radio together and operates the Radio's push-to-talk or activates its VOX so that you can transmit data.

Any of the popular soundcard interfaces will do... Pick your favorite, what somebody you trust uses, what is cheapest, or what works best with your equipment. Mine is a home-brew haywired Frankenstein's monster, but it works and that's the main thing.

When you first start a new installation of FLDIGI, there is a setup routine that all must go through, where you enter your callsign and choose your preferences. It is recommended that you set up and use FLDIGI normally in order to familiarize yourself with its use before going on to utilize it for originating SGARN multicast transmissions. It is a great program that will do a lot.

To get started and to verify that your setup is working properly, use FLDIGI for a few PSK31 QSOs at 14.070 USB, the PSK31 watering hole.

This is good practice, as SGARN servers also operate within a watering hole type environment, so that amateurs know where to look for the data streams and can choose the one that they can receive best from their location.

To begin the SGARN-specific setup of FLDIGI, click the "TxID" button at the top of the FLDIGI screen, so that your station will automatically send TxID transmissions. When the TxID button has a green light, TxID is activated.

Now, under the "Configure" menu item, choose the "IDs" section, then check the "End of xmt ID" box at the bottom right.

-- FLAMP:

Setup of FLAMP for SGARN transmissions is just as easy as setting up FLDIGI for them.

In FLAMP, click the "Configure" tab for the Configure menu. Here you enter your callsign and some brief info about your station.

Below, there are a number of check-boxes, only two of which should be checked: Check the box that says "Auto sync fldigi to flamp mode selector", and check "Change fldigi mode just prior to transmit".

This will cause FLDIGI to automatically follow FLAMP's advice as to which mode to utilize, so that both programs work smoothly in concert.

No other box should be checked.

Equipment:

Whatever kind of radio and equipment you use, you will be making long, continuous transmissions. The enemy here is heat build-up, which can damage your radio if you do not monitor and control it carefully.

I have been experimenting with HF multicast for close to twenty years, and until recently I was the only amateur who had ever done so. In all of this time I have never damaged or destroyed a radio, all because of a few simple precautions that I have followed.

I have used solid-state radios ( Usually a Kenwood TS-450sat ) and have developed a rule of thumb for these...

* Grasping the heat-sink on the back of the rig firmly, if it is too hot for my hand, it's also too hot for the radio.

By following this one standard faithfully, I have never damaged a radio.

Reach back there and check often, especially whenever you change anything or try something new. ( New mode, new antenna, new cooling fan, new frequency, etc. )

I check every five minutes for the first half hour, and every half-hour or so thereafter. I have found that usually it will be as warm as it is going to get after a half-hour of transmitting, but if you have nothing better to do, it never hurts to check it again, every once in a while.

-- Heat Reduction Strategies:

The primary heat-reduction strategy is to keep the power down. On my 100 watt TS-450sat, I never run more than 25 watts while making a multicast transmission, and quite often I run 20 watts if trying a new mode, frequency etc..

Your radio may run cooler or hotter than mine. Remember that if you firmly grasp and hold the heat sink and it is uncomfortable for you, then it is probably uncomfortable for the radio too.

A good general rule of thumb here is to be sure that your radio is well-ventilated, not crammed in a tight space. Use 2" sections of 1" PVC pipe over the feet to get it up off of the desk-top. Make sure there is plenty of room around at the back, and use a small fan to keep a constant movement of air over the heat-sink.

Be certain that your antenna is resonant, and that reflected power is kept as close to zero as you can get it. Reflected power is a heat source that you can minimize or eliminate.

Run the radio in a cool area.

Your first reaction to the radio getting too hot should be to either stop transmitting or reduce power while you check to see what might be wrong.

This is how I have managed to do this for decades without damaging or frying a rig.

Operation:

This section assumes that you have the software set up, your radio set up for continuous operation, preferably with a small fan blowing across the heat-sink, your antenna tuned on your frequency of choice and you are ready for your first multicast transmission.

--- Content:

SGARN policy is to only send news and information of interest to amateurs, originating from established, respected sources. That generally means the various ARRL bulletins, an HTML version of Southgate Radio News eMails, AMSAT bulletins, etc..

No soap-box BS. - Save all of that for the internet, this is ham radio.

It is recommended that you start with the ARRL bulletins, which will generally add up to 20-30kb. - If you try to send much more than that with a digital mode that will not fry your rig at 25 watts output, it will take so long for all of it to be sent - and then sent again so that recipients can get fill-ins on blocks that they may have missed - that you will defeat the error-detection and correction feature of Amateur Multicast protocol. (AMP)

In general, faster modes are wider, and wider modes generate more heat build-up. Lately I have been using Domino X22 to good effect. It is reasonably fast without being so bad about generating heat as many of the other digital modes. Experimenting with various digital modes is encouraged, but if you start off with DOMX22 you won't go far wrong.

Choose DOMX22 in the FLAMP "Transmit" tab and it will automatically change FLDIGI over to DOMX22 as well.

The idea here is to send a stream of data that amateurs can tap into at any time, not on a particular schedule, and within a reasonable amount of time get all of the data being sent, and get fills where necessary for 100% accurate copy of that data.

You can get the files by listening to another SGARN server if you have no internet, or you can get them via eMail from the ARRL, Southgate Amateur Radio News, etc.. W1AW is not a good source because errors will creep in, even if you usually get good copy. There is no error detection or correction for the W1AW transmissions so any kind of interference will result in garbled reception.

Convert from email to Text or HTML files, and put the files to be sent in the FLAMP Tx folder. If you choose the FILE menu item in FLAMP, then choose FOLDERS, you will see the Tx folder in there. Go to the FLAMP Tx folder and right-click it for its properties. That should show its location in your computer. Make a shortcut on your desktop, as you will be updating the files in there regularly.

In addition to the bulletins, include a brief text file that has information about your station and SGARN. - I send a text and an HTML version of this file, mixed in with the bulletins.

-- Transmission Setup:

Now your software is set up, your radio is set up, your files are waiting in the FLAMP Tx folder, and you are ready for the final setup before transmitting.

First check to be sure that in FLDIGI, the "TxID" button at the top is turned on and green.

In FLAMP, Click the "Transmit" tab. There are number of settings here that I will recommend. - Start off with my recommendations, but do not hesitate to experiment with them later.

Blk size: 128

Xmt Rpt: 1

Hdr Rpt: 1

Comp: base64 and check the Comp box for bulletins, but not for your brief Station Info text files so that hams can "read the mail" on those.

Now click the "Add" button and it will display the FLAMP Tx folder. Choose a file, and it will appear in the "Transmit Queue" pane at the bottom of the FLAMP window. Keep adding files in the order that you want them to transmit until you are done.

On longer files, do not forget to check the "Comp" box.

Before making any transmission, check to be sure the frequency is clear on the waterfall. If there is activity in your preferred spot either move over a bit,  or just wait until the frequency is clear.

When you are ready to start transmitting, go to FLDIGI, click the "Tune" button at the top and adjust your rig for 20-25 watts output with no ALC action.

Now go back to FLAMP, click the "Events" tab, make sure the "Continuous repeat of transmission" box is checked, and click "Start Events" to begin the transmission.

-- Stop Transmission:

Under the FLAMP "Events" tab, click "Stop Events" at the bottom, then under the "Transmit" tab, click the "Cancel" button. This will cause FLDIGI/FLAMP to gracefully end the transmission within about ten seconds or so.

<<<  For more information or if you have a question, contact Charles, n5pvl@uspacket.org >>>

2
SGARN / Multicast Protocol and PART97
« Last post by USPacket on September 17, 2013, 05:01:19 PM »
Sections of PART97 Relevant to Multicast Protocol Operation

Following are sections of PART97 that specifically affect multicast protocol operation. All of PART97's regulations of course apply, but these are of particular interest to operators utilizing amateur multicast protocol. (AMP)



97.3 - definitions:

(10) Broadcasting. Transmissions intended for reception by the general public, either direct or relayed.

(26) Information bulletin. A message directed only to amateur operators consisting solely of subject matter of direct interest to the amateur service.

(32) Message forwarding system. A group of amateur stations participating in a voluntary, cooperative, interactive arrangement where communications are sent from the control operator of an originating station to the control operator of one or more destination stations by one or more forwarding stations.

97.111   Authorized transmissions

(b) In addition to one-way transmissions specifically authorized elsewhere in this part, an amateur station may transmit the following types of one-way communications:

(6) Transmissions necessary to disseminate information bulletins.

97.117   International communications.

Transmissions to a different country, where permitted, shall be limited to communications incidental to the purposes of the amateur service and to remarks of a personal character.

97.219   Message forwarding system.

(a) Any amateur station may participate in a message forwarding system, subject to the privileges of the class of operator license held.

(b) For stations participating in a message forwarding system, the control operator of the station originating a message is primarily accountable for any violation of the rules in this part contained in the message.

(c) Except as noted in (d) of this section, for stations participating in a message forwarding system, the control operators of forwarding stations that retransmit inadvertently communications that violate the rules in this part are not accountable for the violative communications. They are, however, responsible for discontinuing such communications once they become aware of their presence.

(d) For stations participating in a message forwarding system, the control operator of the first forwarding station must:

(1) Authenticate the identity of the station from which it accepts communications on behalf of the system; or

(2) Accept accountability for any violation of the rules in this part contained in messages it retransmits to the system.

97.221   Automatically controlled digital station.

(a) This rule section does not apply to an auxiliary station, a beacon station, a repeater station, an earth station, a space station, or a space telecommand station.

(b) A station may be automatically controlled while transmitting a RTTY or data emission on the 6 m or shorter wavelength bands, and on the 28.12028.189 MHz, 24.92524.930 MHz, 21.09021.100 MHz, 18.10518.110 MHz, 14.095014.0995 MHz, 14.100514.112 MHz, 10.14010.150 MHz, 7.1007.105 MHz, or 3.5853.600 MHz segments.

(c) Except for channels specified in 97.303(h), a station may be automatically controlled while transmitting a RTTY or data emission on any other frequency authorized for such emission types provided that:

(1) The station is responding to interrogation by a station under local or remote control; and

(2) No transmission from the automatically controlled station occupies a bandwidth of more than 500 Hz.



3
SGARN / Receiving SGARN Multicasts
« Last post by USPacket on August 25, 2013, 01:49:38 PM »
Receiving SGARN Multicasts


The Second Generation Amateur Radio Network (SGARN) transmits bulletins of interest to amateur radio operators, daily.

These bulletin transmissions are sent via AMP, Amateur Multicast Protocol, which allows an unlimited number of Client (receiving) stations to receive bulletins from a single multicast server at the same time, with 100% accurate copy.

This is very similar to what the ARRL's W1AW station does, the difference being that SGARN's  AMP transmissions allow for errors in reception to be corrected for 100% accurate copy.

Software:

SGARN has adopted W1HKJ's programs FLDIGI and FLAMP as the best possible software for our use on HF.

To receive the SGARN multicasts, you will need the current version of FLDIGI and FLAMP from the W1HKJ website.

w1hkj.com

At the top of the page there is a DOWNLOAD link. Go there and download FLDIGI and FLAMP for your operating system. There are versions available for Windows, Linux and OSx.

Software Setup:

To operate a Client (receiving) station, you must run FLDIGI, then FLAMP so that they run together. Consequently, the SGARN-specific setup for FLDIGI will be described first, then the setup for FLAMP, then a few notes about running them together to receive the SGARN multicasts.

FLDIGI:

You may already be using FLDIGI, as it is the most popular digital multimode program for amateurs at this writing. Many new users of FLDIGI can get started by placing their computer's microphone close to the radio speaker in order to decode the digital transmissions, but best performance is obtained by using a ham radio soundcard interface which connects your computer and radio together so that they may hear each other directly.

Any of the popular soundcard interfaces will do... Pick your favorite, what somebody you trust uses, what is cheapest, or what works best with your equipment. Mine is a home-brew haywired Frankenstein's monster, but it works and that's the main thing.

When you first start a new installation of FLDIGI, there is a setup routine that all must go through, where you enter your callsign and choose your preferences. It is recommended that you set up and use FLDIGI normally in order to familiarize yourself with its use before going on to utilize it for receiving SGARN transmissions. It is a great program that will do a lot.

Use it to read the mail on PSK31 QSOs on 14.070 USB as a good way to test your setup.  Or better yet, use FLDIGI for a few PSK31 QSOs of your own.

--- SGARN-specific setup recommendations for FLDIGI:

Be sure the RxID button in the upper right corner of the FLDIGI window is check marked, and its green light is glowing.

Click on Configure, then click IDs. In the resulting window, change the "Errors" slider to 1, then click Save and close.

These settings help to ensure that the proper mode will be selected automatically for your receiving station.

FLAMP:

Setup of FLAMP for receiving SGARN transmissions is more involved than setting up FLDIGI - but not by much. It is still fairly simple.

In FLAMP, click the "Configure" tab for the Configure menu. Here you enter your callsign and if you like, some brief info about your station.

Below, there are a number of check-boxes, only one of which should be checked, the second box down: Check the box that says "Auto sync flamp to fldigi mode selector"

This will cause FLAMP to automatically follow FLDIGI's advice as to which mode to utilize, so that both programs work smoothly in concert.

No other box should be checked.

Now, just click the "Receive" tab at the top of the FLAMP window - and assuming you already have FLDIGI running too, you are now ready to receive the SGARN transmissions.

SGARN Multicast Reception:

From here, it is assumed that you have a basic working knowledge of FLDIGI, have the RxID activated, have FLAMP running and set up as indicated above, and are tuned in to an ongoing SGARN multicast transmission.

Times and frequencies for SGARN transmissions are listed in the database at the SGARN Yahoo! e-Group:

 http://groups.yahoo.com/neo/groups/SGARN/info

They are also listed periodically on the NBEMS, fldigi-windows, and linuxham Yahoo! e-groups.

When you first tune into an ongoing SGARN transmission, nothing much will happen until the current file has been sent, and the next file to be sent comes up to be transmitted. - At this time, a TxID will be sent that FLDIGI will respond to by changing to that mode, and autotuning to latch onto that signal. The mode in both FLDIGI and FLAMP will change to the proper mode, if they are not already there. As the file information is received at your station, your FLAMP "Recieve" tab screen will show the blanks being filled in for the new file.

File, Date/Time, etc. will be filled in and as the first DATA statement is received, you will see a block indicated in the FLAMP Recieve "Blocks" pane. - You will also see data in the "DATA" pane as the file is received.

After all of the blocks for a particular file are received, it will be created on your system 100% accurate, and will show in the "Receive Queue" pane.

When you click a file in the "Receive Queue" pane, you can choose whether to SAVE or REMOVE it.

For SGARN use, ignore the "To TxQ" and "Report" buttons. SGARN does not take or respond to reports, instead re-transmitting the files in a continuous loop so that an unlimited number of stations can access and use the data stream at any time. - If you miss a block on a particular file, just leave it as it is and the next time that file is transmitted, the block will most likely be filled.

The best system is to tune into a SGARN data stream and let it go until all of the files are intact on your system, then save the files and you are done for the day.

At present the current ARRL bulletins, categories X,P,K,D and B are being sent, along with brief SGARN bulletins in Text and HTML format. As new ARRL bulletins are released, the SGARN files are updated so that by receiving the SGARN transmissions, you will always have the latest from ARRL HQ.

In the future, other content will be added. Check back here to see what will be added. The PART97 restriction upon what may be transmitted via multicast is that it be information "of interest to amateurs". SGARN will be interpreting "of interest to amateurs" as being information released by recognized amateur radio news and information sources - not what somebody might want to get up on a soap-box and rant about.

Signal reports are requested, and greatly appreciated. If you receive a SGARN transmission, let us know about it by sending an eMail to N5PVL, using the address given in the SGARN bulletins.

4
SGARN / SGARN Basics and Philosophy
« Last post by USPacket on August 04, 2013, 08:39:29 PM »
The Second Generation Amateur Radio Network is an effort to start afresh, avoiding various pitfalls that the original AR network, the Packet network fell into.

SGARN has an e-group where discussion takes place, notifications originate, and operating schedules are posted:  http://groups.yahoo.com/group/SGARN/

The illustration below shows the landscape upon which the SGARN network must be built.



SGARN Structure, Policy

Here are listed modules for the Second Generation Amateur Radio Net, listed by band designation: HF, VHF, UHF, SHF

Part of our task is to integrate these into a single coherent network.


----------------------------- HF


Multicast bulletin network ( self organized )

Bulletins originating from organizations: ARRL, AMSAT etc.


----------------------------- VHF


Advanced Packet Network User Access ( Flex32 or better )

Multicast information distribution

HF content - plus Personal messaging, Bulletins originated by individual amateurs


----------------------------- UHF


Advanced Packet Network User Access ( Flex32 or better )

Advanced Packet Network Backbone Links ( Flex32 or better )

HF, VHF content - plus images, some binary files.


----------------------------- SHF


Advanced Packet Network Backbone Links ( Flex32 or better )


HF, VHF, UHF content - plus Amateur TCPIP - HSMM



================= Policy / Philosophy =================


No proprietary software or firmware.

No non-ham links or connections at any point. - SGARN is all Ham Radio.

As you go higher in frequency, start with what is distributed on lower frequencies - and build from there.

Avoid emulation, strive to innovate.
5
Articles / Amateur Radio Operators Advancing the Radio Art
« Last post by USPacket on August 02, 2013, 11:52:40 AM »
Amateur Radio Operators Advancing the Radio Art

Here are two areas that amateurs can work on to advance the radio art with digital modes and protocols that will have lasting value.
 
Narrowband Digital Modes
 
(1) The number of amateurs is expected to rise - but unfortunately the amount of spectrum that we will have access to, particularly on HF, will not follow that rise. This tells us that our spectrum will become progressively more congested for the forseeable future.
 
(2) Also note that any fool can "do more" by hogging up more spectrum - but it takes considerable ingenuity to discover ways to do more with less spectrum. This tells us that the strongest emphasis should be placed upon improving performance of narrowband digital modes.
 
(3) Noting (1) and (2) it follows that a paradigm that seeks to do more by using more spectrum will have no lasting value, and a paradigm that seeks to do more with less spectrum will have value that lasts far into the forseeable future.
 
Conclusion (A) Amateurs who work on advancing narrowband digital modes will return lasting value, and a true advancement of the radio art. Work on wideband modes that hog up more and more spectrum is a self-absorbed, thoughtless substitute for advancing the art that will not have any lasting value.
 
Network Design
 
(1) Wired Network design assumes that long-haul links will have much greater bandwidth than access links, thus providing 'transparency' where users are not slowed down by the fact that there are many other users on the high-capacity long-haul 'backbone' links.
 
(2) Radio networks have long-haul, 'backbone' links that have much less bandwidth than the user access, the direct opposite of what wired networks are designed to work with.
 
(3) Noting (1) and (2) it follows that a paradigm that seeks to innovate, improving our ability to network with RF will have lasting value, advancing the radio art. Any fool can "speed things up" by using an internet crutch, but it takes considerable ingenuity to do more with radio. Work on trying to emulate a wired networking paradigm with RF is a sure prescription for failure, will be of no lasting value and of course will do nothing to advance the radio art.
 
Conclusion (B) Amateurs who work on innovation in RF networking will return lasting value, and true advancement of the radio art. Work on trying to emulate wired networking with RF is a self-absorbed, thoughtless substitute for advancing the art that will return no lasting value.
 
A Note about Network Design and Advancing the Radio Art
 
Terrestrial, wired network design is well-developed. Researchers in this area are backed by large instututions vwhich, despite thier enormous resources both intellectual and financial - have only managed to bring incremental advances forward in recent years.
 
Radio networking has not had much attention because here on Earth, one can simply hook up to a wired 'backbone' link to achieve the transparency that wired networking design assumes.
 
In the foreseeable future though, groups of people people living off-Earth on planets, moons and space habitats will not have the option of simply hooking up to wired networking backbone links and so they will face the very same set of conditions that Amateur Radio RF networking faces today. - User access and local communications that have significantly more availble bandwidth than what is possible on the long-haul links.
 
This is amateur radio's outstanding opportunity to contribute significant innovation today, advancing the radio art in a way that will have lasting value for future generations. We have the singular advantage of a planet-sized working laboratory, and more intellectual assets than any other group or institution working upon this particular issue today.
 
If we get cracking on this right now, nobody will question the utility of the amateur radio service for many long years to come. Right now, we can contrubute to the radio art in a way that matches that of the work of  the amateur scientists who initiated amateur radio more than a century ago.
 
This is our challenge and our opportunity today.
 
73 DE Charles, N5PVL
 
6
Multicast Protocol / Multicast Protocol and PART97
« Last post by USPacket on July 25, 2013, 02:49:08 PM »
Sections of PART97 Relevant to Multicast Protocol Operation

Following are sections of PART97 that specifically affect multicast protocol operation. All of PART97's regulations of course apply, but these are of particular interest to operators utilizing amateur multicast protocol. (AMP)



97.3 - definitions:

(10) Broadcasting. Transmissions intended for reception by the general public, either direct or relayed.

(26) Information bulletin. A message directed only to amateur operators consisting solely of subject matter of direct interest to the amateur service.

(32) Message forwarding system. A group of amateur stations participating in a voluntary, cooperative, interactive arrangement where communications are sent from the control operator of an originating station to the control operator of one or more destination stations by one or more forwarding stations.

97.111   Authorized transmissions

(b) In addition to one-way transmissions specifically authorized elsewhere in this part, an amateur station may transmit the following types of one-way communications:

(6) Transmissions necessary to disseminate information bulletins.

97.117   International communications.

Transmissions to a different country, where permitted, shall be limited to communications incidental to the purposes of the amateur service and to remarks of a personal character.

97.219   Message forwarding system.

(a) Any amateur station may participate in a message forwarding system, subject to the privileges of the class of operator license held.

(b) For stations participating in a message forwarding system, the control operator of the station originating a message is primarily accountable for any violation of the rules in this part contained in the message.

(c) Except as noted in (d) of this section, for stations participating in a message forwarding system, the control operators of forwarding stations that retransmit inadvertently communications that violate the rules in this part are not accountable for the violative communications. They are, however, responsible for discontinuing such communications once they become aware of their presence.

(d) For stations participating in a message forwarding system, the control operator of the first forwarding station must:

(1) Authenticate the identity of the station from which it accepts communications on behalf of the system; or

(2) Accept accountability for any violation of the rules in this part contained in messages it retransmits to the system.

97.221   Automatically controlled digital station.

(a) This rule section does not apply to an auxiliary station, a beacon station, a repeater station, an earth station, a space station, or a space telecommand station.

(b) A station may be automatically controlled while transmitting a RTTY or data emission on the 6 m or shorter wavelength bands, and on the 28.12028.189 MHz, 24.92524.930 MHz, 21.09021.100 MHz, 18.10518.110 MHz, 14.095014.0995 MHz, 14.100514.112 MHz, 10.14010.150 MHz, 7.1007.105 MHz, or 3.5853.600 MHz segments.

(c) Except for channels specified in 97.303(h), a station may be automatically controlled while transmitting a RTTY or data emission on any other frequency authorized for such emission types provided that:

(1) The station is responding to interrogation by a station under local or remote control; and

(2) No transmission from the automatically controlled station occupies a bandwidth of more than 500 Hz.



7
HF Network / FBB Forwarding Protocol
« Last post by USPacket on July 14, 2013, 07:27:47 PM »
     FBB Forward Protocole.
            ----------------------

            FBB software includes  two forward protocoles.  The first one
       is standard with MBL/RLI protocole.  The second one was developped
       to allow  a better  efficiency, particularly  on long  links where
       propagation time  of data  are long.  The exchange  of commands is
       reduced to a  minimum, and not  acknoledged to get  time. The data
       transfer direction is changed every block of data, a block of data
       holding up to  five messages.  This uses the  "pipeline" effect of
       long links (Nodes and digipeaters),  and gain some time over short
       links (HF...).

            FBB protocole is very simple in its principle. It is based on
       MID/BID usage. The identification  is made by the  F letter in the
       SID (system  type identifier  contained  in square  brackets). All
       command lines must start in  first collumn with the 'F' character.
       All command lines are ended by a return (CR) character.

            Suppose I  call  another BBS  to  forward some  mail.  When I
       connect another BBS  using FBB  protocole, I will  receive the SID
       followed by a text and the prompt (">"). If the SID contains the F
       flag, I will send immediately my SID and the first proposal.

            Proposals looks like :

       FB P F6FBB FC1GHV FC1MVP 24657_F6FBB 1345
       F>

       FB          : Identifies the type of the command (proposal)
       P           : Type of message (P = Private, B = Bulletin).
       F6FBB       : Sender (from field).
       FC1GHV      : BBS of recipient (@field).
       FC1MVP      : Recipient (to field).
       24657_F6FBB : BID ou MID.
       1345        : Size of message in bytes.
       F>          :  End of proposal.

            ALL the fields are necessary.  This kind of command must hold
       seven fields.  If  a field  is  missing upon  receiving,  an error
       message will be send immediately followed by a disconnection.

            A proposal can  handle up  to five  FB command  lines. If the
       total size of messages seems to be too important, the proposal can
       handle less  lines. In  FBB  software, a  parameter is  defined in
       INIT.SRV file to tell the maximum size of the message block. It is
       set by default to 10KB  for VHF use. It can be  adjusted according
       to the quality of the link.

       Exemple of proposal :

       FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345
       FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346
       FB B F6FBB FRA FBB 22_456_F6FBB 8548
       F>

            This proposal is limited to three  FB lines, as the amount of
       messages overran the 10KB limit defined for this link.

            When receiving  the  proposal,  the  other  BBS  will reject,
       accept or defer the message. This command is made by a FS line :

       FS -+=

            This means :

            - I don't want the first message (-).
            - I need the second message (+).
            - I defer the third message, as I'm still receiving it.

            It should  interesting to  defer a  message if  you are still
       receiving it on a other channel, or  if you think that the size is
       to big,  or for  another  reason. The  message should  be proposed
       again at the next connection.

            FS line  MUST  have  as  many +,-,=  signs  as  lines  in the
       proposal.

            When  receiving  the  FS  lines,  I  can  send  the block  of
       messages. Each message is  made with the title  on the first line,
       the text, and  a Ctrl  Z in  the last line.  The is  no blank line
       between the messages.

       Title of 2nd message
       Text of 2nd message
       .....
       ^Z

            When the other  BBS has  received all the  asked messages, it
       acknoledges by sending its proposal, and the system is reversed.

            If it has no message to send, it only sends a line :   

       FF

            This line must not to be followed by a F>.

            If the other hand has no message, it sends a line :

       FQ

            and asks for the disconnection.





       Example :
       ---------


       F6FBB                    FC1GHV
       ----------------------------------------------------------------

       Connects FC1GHV

                                Connected

                                [FBB-5.11-FHM$]
                                Bienvenue a Poitiers, Jean-Paul.
                                >

       [FBB-5.11-FHM$]   (F6FBB has the F flag in the SID)
       FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345
       FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346
       FB B F6FBB FRA FBB 22_456_F6FBB 8548
       F>

                                FS +-+  (accepts le 1st et le 3rd).

       Title 1st message
       Text 1st message
       ......
       ^Z
       Title 3rd message
       Text 3rd message
       ......
       ^Z

                                FB P FC1GHV F6FBB F6FBB 2734_FC1GHV 234
                                FB B FC1GHV F6FBB FC1CDC 2745_FC1GHV 3524
                                F>

       FS --  (Don't need them, and send immediately the proposal).
       FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345
       F>

                                FS +  (Accepts the message)

       Title message
       Text message
       ......
       ^Z

                                FF  (no more message)

       FB B F6FBB TEST FRA 24654_F6FBB 145
       F>

                                FS +  (Accepts the message)

       Title message
       Text message
       ......
       ^Z

                                FF  (still no message)

       FQ  (No more message)

       Disconnection of the link.


            In this example,  FBB protocole is  used as the  two BBS were
       identified by the  F flag in  the SID.  If F6FBB had  sent the SID
       [FBB-5.10-MH$] when answering FC1GHV,  the protocole should be the
       standard MBL/RLI.

            All callsigns are only examples !




       Extension to the protocole. Compressed forward FBB.
       ---------------------------------------------------

       The protocole utilized for the  transfer of ascii files compressed
       is an extension to the  existing protocole. The compressed forward
       is  validated  by  the  presence  of  the  letter  B  in  the  SID
       [FBB-5.12-BFHM$]. The transfer  of compressed files  can only take
       place under FBB protocole. The presence of the letter B in the SID
       without the F letter will remain without effect.

            The only difference as regard to the standard protocol is the
       submit line.  It can  specify the  type of  data contained  in the
       compressed message. FA  means that  the transfer will  be an ascii
       compressed message.  FB means  that the  message will  be a binary
       compressed file (this  last possibility is  not yet implemented).

       The submission of an ascii message will be in the form :
       FA P FC1CDC F6ABJ F6AXV 24754_F6FBB 345

       The submission of a binary file will be in the form :
       FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345

       The transfered data are of a specific format. The transfer will be
       done in binary mode. This last one is derived of the YAPP protocol
       which is very reliable. All transfer  is made of a header, a block
       of data,  an  end of  message  and  a checksum.  Each  transfer is
       equivalent to the transfer of one message of the standard protocol
       and shall  not  be  followed  by  a control  Z,  the  end  of file
       specifier is defined in another way.  Unlike YAPP transfers, there
       is  no acknowledgement  during the  transmission of  messages, the
       protocole is then more simple and efficient.

       Format of header for an ascii compressed message (submission FA) :

       <SOH>                    1 byte = 01 hex
       Length of the header     1 byte = Length from the title,         
                                     including the two <NUL> characters.
       Title of the message     1 to 80 bytes
       <NUL>                    1 byte = 00 hex
       Offset                   1 to 6 bytes
       <NUL>                    1 byte = 00 hex


       Format of header for a binary compressed file (submission FB) :

       <SOH>                    1 byte = 01 hex
       Length of the header     1 byte = Length from the filename,
                                     including the two <NUL> characters.
       Name of the file         1 to 80 bytes
       <NUL>                    1 byte = 00 hex
       Offset                   1 to 6 bytes
       <NUL>                    1 byte = 00 hex


       As to follow  the french regulation,  the title of  the message or
       the file name are transmitted in readable ascii, not compressed.

       The offset is also  transmitted in ascii  and specifies the offset
       at which the  data should be  inserted in  the file (in  case of a
       fragmented file).  In  the  version 5.12,  this  parameter  is not
       utilized and is always equal to zero.

       A data  block contains  from one  to 256  bytes. It begins  by two
       bytes which specify the format.

       Data block format :

       <STX>                    1 byte = 02 hex
       Number of data           1 byte = 00 to ff hex.
                                if length is 256 bytes, the value is 00.
       Data bytes               1 to 256 bytes


       The last data block  is followed by the  end of file specifier and
       the checksum.

       End of file specifier format :

       <EOT>                    1 byte = 04 hex
       Checksum                 1 byte = 00 to ff hex

       The checksum is  equal to  the sum  of all  the data  bytes of the
       transmitted file, modulo 256 (8 bits) and then two's complemented.

       The checking of the checksum is very simple :

       The sum  of the  datas  from the  file  and the  checksum received
       modulo 256 shall be equal to zero.

       In case of a checksum error, the  message or the file is not taken
       to account and the system issues a disconnect request after having
       sent the comment :

       *** Erreur checksum



       Ascii values of the characters (1 byte) used in the protocole :

       <NUL> = 00 hex
       <SOH> = 01 hex
       <STX> = 02 hex
       <EOT> = 04 hex

       Most of  ideas for this  binary transmission  are issued from YAPP
       protocole. Thanks to WA7MBL.

 
8
Software / com0com Virtual Null-Modem Software
« Last post by USPacket on March 30, 2012, 04:32:54 PM »

I was digging around and tried com0com, a virtual null-modem progran that creates virtual com ports and links them.

http://com0com.sourceforge.net/


That's "com-zero-com"  - com0com

If you have Microsoft Net framework 2.0 installed, then you get a nice GUI interface for setting up com0com.

Otherwise, it's the command line for you, buddy!

It worked perfectly for linking a BPQ Async port to MixW's virtual KISS TNC function.

So I get to use MixW as a KISS TNC, and it only took one real COM port for the soundcard interface PTT. - The link between MixW and BPQ is virtual.

Works great, it's free, etc... Highly recommended.

73 DE Charles, N5PVL
9
Articles / Amateur Radio Communications
« Last post by USPacket on April 18, 2011, 09:00:56 PM »
A while ago, I was involved in an email discussion between Packet Radio BBS SYSOPs about message routing problems introduced by "internet forwarders", people who hook up ham radio BBS software to the internet instead of amateur radio, thereby bypassing the apparently onerous challenge of communicating - via amateur radio.

Don't ask me why they want to be radio-less ham radio operators... - It doesn't make any sense to me, at all.

They want to participate in an amateur radio digital network - but they don't want to use radio... Does that make sense to you?

Anyway...

Since they do not use or understand radio, these "hams" constantly cause trouble for those of us who do. - There's always some soft-hearted or soft-headed SYSOP who wants to be "inclusive" and hooks up with one or more of them.

So, naturally, I made some kind of disparaging comment about how the "non-ham" internet forwarders always claimed to intrude into our ham radio network in order to "help out", but that in practice what they really do most often is "screw things up".

An indignant internet forwarder named Art apparently didn't like my "non-ham" characterization and replied:
 
----- Original Message -----

Ham radio is about experimenting and contact with other
hams. Internet is just another tool at our finger tips.
It keeps hams in touch with hams.   Art

----- My Reply -----

I'll have to call BS on that one, Art.
 
Ham radio is not about "contact with other hams" - It is about amateur radio, with communicating via radio ( and only by radio ) as a necessary adjunct of such.
 
Communication via other methods beyond amateur radio - are not amateur radio communications.
 
On this email reflector for example, we talk about amateur radio, and we are all amateurs, and we use the list to stay 'in contact' with each other - but this does not qualify posting here or reading the posts as an 'amateur radio communication', by any stretch of the imagination.
 
It's not happening via radio, on amateur radio frequencies.
 
That means that it is not an amateur radio communication.
 
My station is connected to the local power grid, for another example... This does not qualify the power grid as an amateur radio artifact.
 
I could 'experiment', and find a way to hook up ham radio software to the power grid and 'contact other hams' who also had amateur radio software hooked up to the power grid.
 
This would in no way qualify those communications as "amateur radio communications" even though hams might use them to 'stay in contact'.
 
It would be a lot like BPL, but nobody who is honest with themselves and others could possibly characterize the result as an amateur radio communication.
 
It's not happening via radio, on amateur radio frequencies.
 
That means that it is not an amateur radio communication.
 
Furthermore: My 'experimentation' with using amateur BPL to 'stay in contact' with other 'hams' would in no way, shape or form advance the technology relevant to amateur radio which is - amateur radio.
 
As you can perhaps see now, Art, attempts to put 'communication' above the 'radio'  in amateur radio communications actively undercuts rather than supports the growth and advancement of the hobby.
 
So I'm calling BS - on that BS.
 
73 DE Charles, N5PVL
10
Multicast Protocol / Old Multicast Article from 2003
« Last post by USPacket on March 01, 2011, 12:37:31 PM »
Emergency Digital Communications - Another Angle
- by Charles Brabham, N5PVL -
- U.S. Packet Net -

In the last decade or so, amateurs have been treated to dozens of excellent new programs and protocols that have greatly expanded our capabilities. APRS, CLOVER, PSK31, PACTOR II, FlexNet, and AGWPE immediately come to mind. So many new ideas have been presented in this way, it is inevitable that sooner or later something really great would end up being overlooked. This has been the case with RadioMirror, the Terrestrial Multicast protocol/software package developed several years ago by John Hansen, W2FS.

RadioMirror works much like the familiar EMWIN weather data and alert transmissions provided by the National Weather Service. One transmitting station provides information to an unlimited number of recieving stations simultaneously by means of a digital transmission to many stations at once, called a multicast.

Before reading about applying RadioMirror and its multicast protocol to digital emergency communcations, you can get a better idea of what RadioMirror is and what it does at the RadioMirror Home Page, as John can do a much better job of describing his work than I can. Here I will quote the major points of the system, from his pages:

RadioMirror is a new file server designed by John Hansen, W2FS (ex-WA0PTV), to use a multicast protocol in packet radio. The current version runs under Windows 95/98. This results in relatively high speed file transfers from a central server to many client computers at once. Key features of this software include:

    * Packets are transmitted in unconnected mode so they can be received by an unlimited number of stations at the same time.
    * File transfers are faster than on traditional connected packet connections because the server need not wait for acknowledgment packets from the clients. Data streams out of the server without interruption.
    * The system does not require users to purchase any new hardware. It is capable of transferring up to 20 MB of data per day (assuming 50% compression) at a transmission rate of 1200 baud.
    * The client software saves partial files that are received with holes and fills in the holes as the file is retransmitted.
    * The client software keeps track of the file modification dates and will update files that have been modified, but ignore files that it has already received and have not been updated.
    * Unlike the PACSAT broadcast protocol, the filenames on the clients are exactly the same as they appear on the server, making this an excellent mechanism for distributing HTML files.
    * Entire directories and directory structures that reside on the server can be replicated exactly on the clients, making this an ideal way, for example, for transferring files that have been downloaded from the PACSATs, so that stations that do not have satellite groundstations can still use groundstation programs like WiSP to access satellite files.
    * Hooks are built into the server to allow other programs, such as packet bulletin boards, to kick off server file transfers.
    * Files can be specified to be transmitted once, or on a continuous loop.

The RadioMirror distribution file gives you a copy of both the RadioMirror server, and the client software that picks up and decodes the data being sent by the servers' multicast transmissions. RadioMirror is designed to work with Win95/98. Both client and server programs require a KISS TNC.

What RadioMirror sends is files. Not only files, but directory structures along with their files can be transmitted by this versatile software to any number of recieving stations. Any kind of file can be sent, but HTML and text files may be the most useful for emergency communications.

RadioMirror and Emergency Communications

Obviously, there are dozens of potential uses for a supercharged amateur radio version of EMWIN.

I believe that RadioMirror can be especially useful for distributing information to non-hams that we work with such as Law Enforcement entities, the Red Cross, National Weather Service centers, Hospitals, and Government offices. Very few of these persons can be depended upon to learn how to use special software or radios, but they all know how to use an Internet browser.

All of these offices, along with local ARES/RACES groups and anyone else who is interested can be continuously kept up to date by a single RadioMirror server located in your community.

The RadioMirror clients at each location require an old 486 or better computer to run Win95/98 and RadioMirror Client, the built-in IE browser set up with links to the files you wish to display, and a 2 meter FM reciever (any kind) capable of picking up the multicast information. An old scanner, or ham rig that doesn't transmit any more would do fine. A TNC capable of KISS mode operation is also required for each location.

If you need to buy new TNC's, an inexpensive alternative would be the PIC - based KISS TNC that John Hansen has designed and offers as either a kit, or as an assembled and tested unit. This is the PIC-based TNC featured in the November, 2000 issue of QST.

Once a RadioMirror client is set up, let's say at the Sherriffs' office for example, an amateur radio operator need not be present in order for the people there to use it. The client system does not transmit, it only recieves amateur radio transmissions and anybody can legally do that.

RadioMirror can simultaneously distribute the information you provide to any number of such client locations, freeing up your local RACES/ARES hams for more interesting and useful work. Most of the present setups, both digital and voice, require a ham at each location served so this is a significant advantage for small groups, struggling to do a lot with just a few active members in the field.

RadioMirror Multicast Network
RadioMirror Multicast Network
Note that most locations have emergency power systems or generators.

Once you have set up your server, start putting together a few client stations. You will want at least one of them right away of course, to test the server. After that, assemble clients ( as you can afford to ) for the various non-ham agencies and entities that you have arrainged to serve.

Set the client machines for non-hams up so that when the power is flipped on, the computer automatically loads RadioMirror Client, and then the Internet browser with its pre-loaded links to the relevant files in the client computer's hard drive. Create an internal HTML page with those links, and set that as the browser's default startup page.

If you power the reciever and TNC from the computer's power supply, they will automatically come up too, making it a single-button operation to bring up the entire system. This makes it easy to start over if things go wrong. You could even put the receiver and TNC in the computer's case, to keep things uncluttered and simple. The idea is to make it simple, easy to deal with during the course of an emergency, and obviously useful. A turn-key system.

Updating the Data on the Server

RadioMirror has no provision for remotely updating the information it will send. If you change the contents of the "continuous" or "one-time" directories, RadioMirror will send the updated files immediately. It is up to you though, to figure out how to update files residing in a computer at a distant tower site. Probably the best solution is to run a copy of FBB BBS along with RadioMirror, because of the extensive remote SYSOP controls and great security FBB offers. You can remotely do most regular DOS chores with FBB, and it handles YAPP and BinHex file transfers, another good feature for effective remote control and update of the RadioMirror server.

The BBS software should have one radio port for control purposes, and be configured for high security (password access only) along with minimal function as a BBS. If you want to use it as a regular BBS with additional radio ports, be sure your computer is up to the load that this will present while RadioMirror runs in the background! The BBS function is optional though, as you are primarily using FBB as a file transfer and remote disk control for RadioMirror.

Any other packet program that allows remote control of the disk, has good security and handles packet radio file transfers will do just as well, maybe better. I'm used to FBB, so that's what I tried.

You decide who gets the password and can update which files. FBB makes it easy to do this, as only the originator of an uploaded file (or the SYSOP) can modify or delete that file. Once a file is updated, the updated version goes out over RadioMirror and that updates all of the RadioMirror client systems listening.

For example, hams at the National Weather Service E.O.C. could have control of a text file in the BBS. In the RadioMirror server, you would have it send that file continuously, along with the files it sends from other sources. Whenever the NWS updates the text file, the updated version immediately gets out to the police, city hall and the TV station, and all other client systems that are operating within effective range of the server's transmitter.

Files can be created for each source of information, including amateurs in the field. They could either carry along a portable packet station, or relay thier reports over a voice repeater to a home station with both voice and packet capability nearby.

The RadioMirror server, it must be noted, requires a transmitter but no reciever. The transmitter must be rated for continuous duty, as it is only unkeyed very briefly and spends over 95% of its time keyed up. Reduce power, or get a pretty tough transmitter and set it up with a cooling fan. It will need it. If you start off with a 100 watt transmitter and tune it down to 20 watts or so, that would be a good starting point. Don't burn up your transmitter!

Going over the main advantages to this setup, they are:

# A turnkey system for providing important data to non-hams and hams alike.

# Frees up amateurs from babysitting voice or regular packet systems at non-ham sites, so they can do more in the field.

# Is generally inexpensive, uses existing equipment and even equipment that is no good for anything else. (2meter rigs with no TX , no tone boards, and so on..)

# Anybody with a TNC and a VHF reciever can recieve the multicasts.

Between Emergencies

To keep your system ready, the server should operate at all times, ready to be used for testing client systems at non-ham locations around the city. The clients will only see the files that you specify on their system's default HTML pages, so in-between emergencies, your group could transmit other general information of interest to amateurs, including "Ham Home Pages" for individuals and clubs, located at the server.

John Hansen describes some of these everyday ways to utilize a RadioMirror server at his web site, along with detailed information about the protocol, and the commendable philosophy behind this system. When an emergency arises, tell the system to only send the most vital files, so that it will cycle through them and update quickly. A small number of text or HTML files will cycle around and update every few minutes. The more data you add to the cycle, the longer the update interval becomes for any particular file. Balance this (content vs update speed) to suit your needs during emergency operations. In between times though, update speed is not such an issue, and content becomes more important. (VE testing scheds, Club meetings, Swap-Fests, ARRL Bulletins, Club HTML pages, and so on.)

Note: I haven't mentioned RadioMirror as replacing current voice and packet emergency communications systems because it never could do that. RadioMirror's multicast works best when used to enhance other systems, not replace them. All of our ham emergency communications methods have a place in the hobby, and I believe RadioMirror really ought to be in there with the others because of the unique capability it offers to amateur radio emergency communicators. It allows a small number of amateurs to get a lot done, generates good public relations and most importantly, it can save lives and property.

Charles Brabham N5PVL
Pages: [1] 2 3 ... 5