Global Chinese amateur radio conference network                     Dec-2003

Since our first attempt to conduct global conference (during lunar New Year period) between amateur radio stations at different countries, we finally reached a platform where multiple users (radio and internet based) can be joined up freely. Thanks to the effort of various pioneers who dedicated their time and resources to make this a reality.

Briefing on structure of this conference media

This new platform is built on two popular ham VOIP applications Echolink and EQSO. Both platforms support radio gateway operation to provide access from local radio users to internet conference media. Echolink allows radio users to execute remote connection to their target stations via DTMF commands. It is very close to another successful platform IRLP but has the advantages of running on window based PC (easier for user to setup). Like IRLP, Echolink requires validation of user’s identity before they are allowed to join in as echolink nodes. This is an effort to ensure all echolink users are licensed amateur radio stations. EQSO provides a more open self-serve support environment with less security screening. This is an advantage if users have difficulty to get verification of their license status over the country (during the application of an echolink node registry). In EQSO environment, the connection of a gateway with other internet VOIP parties is a responsibility of the EQSO gateway owner. Even though people using EQSO might not carry equivalent security clearance as Echolink users, their participation within a strict licensed amateur radio environment can be monitored and controlled by their gateway owner. By the way, EQSO uses less bandwidth to exchange voice packet and can therefore provide a more fluent conversation if user has ISP bandwidth limitation.

Thanks to fellow hams from Kentucky and Los Angeles, they worked out four servers and a cross over scheme to join up these two platforms. These server connections provide the main horse power for our conference activities. Minor issues were identified during the initial trial run period that leads to setting up of certain guide lines for future practice. These issues will be discussed a bit later.

Following is a diagram showing a typical connection scenery when these conference are exercised.

The primitive conference server was set up by AF4BH on EQSO platform in mid 2002. It is now known as:

EQSO server AF4BH.NET port 10024.

Inside this server, we can open up multiple rooms for conference. The most important rooms are Chinesehams and repeaters. These two rooms house participants that are valid amateur radio stations or district gateway repeaters. Through these rooms, we conducted our initial test to allow users from different Chinese speaking areas to talk with each other (via their local EQSO gateway or EQSO installed PC). We also have rooms like “off air” for conversation between users who do not want on-air conversation or simply if they do not have legal status to exercise RF transmission (like SWL discussion).

The result is an overwhelming success except we soon run into the first issue - bandwidth shortage. In reality, a domestic internet link can not support a lot of EQSO users in the same conference. We encountered stability issue as soon as the participants in a conference exceed 9. Situation could get critical if one or more participants have serious digital delay (e.g. if they were using poor quality dial up internet access). Under worst case scenery, the server can collapse while all users were being disconnected without warning.

This issue directed us to consider techniques related with bandwidth sharing. That’s what made Echolink platform so interesting. Echolink by itself uses more bandwidth then EQSO hence a better audio quality. It is less favorable if a single Echolink application has to house the same number of user (as compared with EQSO). Yet Echolink has a very important feature of allowing conference to be deployed in layers. Under this condition, bandwidth consumption can be spread upon multiple users (each supporting a small conference underneath deeper layers). In this case, the maximum bandwidth usage of each conference node is much smaller as compared to one single EQSO server handles all users. This created a second issue of variable multi-hop delay. Unlike EQSO where every participant in a conference bears only one hop delay (same round delay between the server and every user for each voice packet’s circulation), shared bandwidth configuration under Echolink can have serious difference for the same voice packet to reach multiple users. To improve this issue, Bay area members come up with the next solution - they provide three extra servers.

Seagate,Sealink and Seanet are three Echolink servers sponsored by the Bay area hams (W6EE,KK7BEN,KG6TN). By theory, each server can handle over 100 users “logically”. The real capacity differs based on the supporting internet backbone and are tested out as between 6 to 22 users (differs between servers). With virtual link up (provided by KE7KD and KG6TN), all three servers can be joined during major big events. This boasted their combined limit to somewhere between 40-45 users. These virtual links are not activated normally so as to allow different but smaller groups of users to make multiple conferences at the same time (on different topics of interest).

In order to allow Echolink users to talk with EQSO users, we set up a cross-connect point at AF4BH. This basically is a digital crossover at data bus level. AF4BH-L is an echolink gateway. It is coupled with AF4BH-G (EQSO gateway). By default, AF4BH-L logged into SEANET server. AF4BH-G logged into EQSO room Chinesehams. With this setup, EQSO users talking into Chinesehams can cross over to Echolink platform via Seanet. The trade off is a remarkable delay of 2 sec (which is the minimum safe margin for audio to cross the two platforms without serious threat of stability. This set up also made server *SEANET* slightly different from the other two since it is an EQSO-Echolink bridge.

Conference session set up and operating procedure

Operating profile on a global conference is similar to H.F. net operation. Be reminded that your voice can appear on a totally different country zone while there can be other users standing by. In general, the rule of thumb is to listen for a while to see if there is on-going traffic after your fresh connection. If the channel is quiet, identify yourself as soon as possible. Ask if anyone is on standing by and if any on-going discussion is running. Don’t go for a CQ DX call unless you are certain that doing so would not interrupt on-going conversation. Remember to state full call sign with phonetics spelling. This is a concern that audio quality going through multiple systems can degrade and it is required by law to ensure positive identification of every station in contact. So please don’t drop the prefix of your call letter even if such practice might be acceptable at your local area.

We are all licensed amateur radio operators. It is unnecessary to repeat rules and regulation regarding contents of discussion. Just treat it like the H.F. environment and exercise the same attitude and respect during operation.

To join the conference, one of the following set up is required:

Direct internet access to EQSO via home PC. This can be achieved by using a PC with EQSO software installed to access internet. Make a connection with AF4BH.NET port 10024 into room Chinesehams. You can expect to hear users in the same room or from Echolink platform who is in conference inside server Seanet. If you speak into EQSO server, they can hear you as well. To get EQSO software, visit and download from www.eqso.net .

Direct internet access to Echolink via home PC. This can be achieved by using a PC with Echolink software installed to access internet. Locate and connect with node *SEANET*. This node can be found inside the node type “conference? Once connected, you can see all other connected nodes inside SEANET.?If you see AF4BH-L connected, you can expect your voice be heard by other EQSO users listening on EQSO room Chinesehams. To get Echolink software, visit and download from www.echolink.org . Have the software installed and fill in your true callsign, name and address data. Once the filled data are verified over the net (part of the software’s function), your attempt to log on Echolink’s global participants server will be granted. For users outside North America, you might have to send copies of documents that can prove your status as a valid amateur station before such access can be granted. Feel free to contact Echolink to find out more detail if you run into access issues www.echolink.org/authentication.htm .

Remote access to echolink nodes or server via radio. This can be achieved by using your radio to work with your local Echolink gateway repeater and if they allow DTMF remote access control originating from local radio users. Make a transmission when the system is idle, identify yourself and key in DTMF code 08. This is a general command to check if the gateway is connected with any Echolink nodes. You can expect to hear a voice announcement confirming if the gateway is “not connected” or is “connected with ??????”. If it says “connected with S E A N E T, then you know you are already in the conference. If it is “not connected” , you can key in DTMF code 121958 (node number of Seanet or node number of your target repeater/server). You can hear voice message “connected with S E A N E T if you got a successful connection. To release a connection after you finished your QSO, key in DTMF code #. These are just general default procedures for a fresh start Echolink gateway. Different system operator might change the code sequence at their own discretion. Please check with the owner of the concerned Echolink gateway if you encountered difficulties. Some of them might need special arrangement or set up conditions. Node numbers of Echolink supported Cantonese repeater will be released later in separate web page. 

Remote access to preset EQSO conference media via radio. This can be achieved by using your radio to work with your local EQSO gateway. Only system operator of the gateway knows where the gateway is connected with. Consult him for the time schedule and specific procedure if exist.

Additional hardware to setup your own gateway

If you are interested to provide a R.F.gateway for your local stations to participate in these activities, you might consider to build a simple interface (a cable normally) between your PC and a radio system. By using built in VOX mode of both software, one doesn’t even need modifying the simplex radio for COS (carrier operated squelch) trigger.

Please check with your local telecommunication authority if special qualification is required to do so (this is equivalent to running a repeater). In North America, we need advance level license status before we can exercise such activity. Help files within Echolink (sys-op mode) or EQSO gateway mode will give you better idea on how remote connections can be made and what has to be prepared.

Above shows a typical temporary setup using a laptop with dial up access to support a mini gateway for small area. As a start, even a simplex portable radio can do the job very well. Following diagram shows how one can build such an interface cable (using VOX mode activation of Echolink or EQSO), In order to support full DC control on Tx towards internet, you only need a receiver with COS output. You don’t need additional and complicated interface circuits.?

Feel free to contact us over the conference or Email me ve3rgw@rac.ca  for more detail

See you down the net at Echolink *SEANET* or EQSO room “Chinesehams

 

Return to Dreamland