G4HPE-L HF GATEWAY TEST ANNOUNCEMENT

birthdaytestAI and Robotics

Nov 17, 2013 (3 years and 8 months ago)

90 views

G4HPE
-
L HF GATEWAY

TEST ANNOUNCEMENT


A test of the HF Gateway is scheduled as follows


TEST ID:
T02


Date:


Sunday 21
st

October 2007

Time (UTC):

1400
-
1700

Frequency A:

3663kHz USB

Frequency B/C:

3660kHz & 3657kHz USB



Control Station:




G4HPE, G
4KUJ, AE2EE

Stations on Echolink:



VU2RBI HB9SLM GW0VMZ







G4PGZ HP1/OE5CEN

Stations on Radio Frequency:

G0DUB/P G7JAK M1DFO







G8OJQ G4MWO GI7THH



Purpose of test:
To assess the performance of the HF Gateway for
passing traffic under simulated em
ergency net conditions.



Proposed activity:
A formal net will be established which will
include: 1. SSB stations on an HF frequency 2. VoIP stations on
the IRESC Echolink conference (node 278173). A single Net
Control Station (NCS) will simultaneously
control both the HF and
VoIP sides of the net.



Instructions:
Only stations that had pre
-
registered took part in this
test. Unique exercise traffic items were emailed to each
participant in advance. The nature of the traffic is described in
more detail

below. The NCS firstly established contact with each
of the participants, then, under strict net control, participants were
allowed to exchange traffic with other specific participating
stations, both receiving data they were missing and sending data
tha
t was required by others. NCS was changed several times
during the exercise, controlling sometimes on HF SSB and
sometimes on Echolink.


Test report:
The test was well attended by stations from an
interesting selection of locations around the world. The

proposed
HF frequency already had a well
-
established QSO on it; therefore a
move to 3660 kHz USB was made. USB was used (as opposed to
the more conventional LSB for amateur communications) in the
hope that less non
-
exercise attention would be drawn to th
e
activity.


G4HPE supervised the Gateway operation, using the recently
completed interface unit. This unit now features a ‘voice
recognition’ squelch circuit that is designed to mute the audio if
there appears to be no human speech on the radio channel.


VoIP stations connected to the IRESC Echolink conference but
found that their ability to transmit was inhibited automatically
unless they were as registered participant in the exercise. This
was a useful security feature to prevent abuse of the system fr
om
the VoIP side although this would be extremely unlikely.


A recording of audio on the HF frequency was made by G4PGZ
and the equivalent recording on Echolink was made by G4HPE.
Clips from both of these recordings are referred to later.


To generate a l
arge amount of traffic between the stations taking
part, a simple system that would require a lot of different contacts
between them was arranged. The material was emailed out in
advance of the exercise. Each participant had a grid, on which
there were s
ome number and letters groups. The requirement
was to collect letter groups that corresponded to numbers, and
vice versa. Every participant also had some sets of number/letter
equivalents, the ‘answers’ required by others.


An automatic ‘end
-
of
-
transmiss
ion’ bleep was generated on the HF
transmitter to more clearly indicate that a VoIP station had
finished sending. The Gateway was set to identify itself
automatically in voice every 5 minutes and regular descriptive
identifications were made by the NCS st
ations. Because the
automatic identification can be set to wait for a ‘clear frequency’
there were no conflicts with net traffic when this was made.


The radio propagation conditions of 80m were not particularly
inspiring. A couple of the participants we
re not at all strong, even
on a clear frequency, but this only added to the realism of the
exercise. One might expect some stations to be operating in less
than ideal circumstances, perhaps operating ‘portable’ in the field
with a limited power supply and

a temporarily constructed
antenna. G0DUB/P was just such a station: Greg was actually
operating at a Raynet event simultaneously with this exercise and
was using a temporary 80m installation in a field at the village of
Malpas, in Cheshire, northern Engl
and. G0DUB/P was using 20W
set up in his car next to St. John Ambulance control, to a W3EDP
antenna suspended over a low tree limb. He nevertheless put a
good signal into the HF Gateway and the voice recognition squelch
system operated near
-
perfectly on
his signal, as a listen to the
audio clips (detailed below) testify.


During the middle hour of the exercise, the radio channel also
suffered heavily with strong stations on adjacent frequencies.
These were probably taking part in the Scouts’ Jamboree
-
On
-
The
-
Air event that coincided with this test.


In terms of realistically stretching the performance of the Gateway
on the VoIP side, the operating circumstances of some
participating stations are worthy of note.


NCS station AE2EE was operating from a FEMA
bunker in Batavia,
New York. To reach his own Echolink Gateway, Dennis made use
of a series of VHF and UHF repeaters normally used by Genesee
County ARES group. We were very grateful to the KC2JAD team
for permitting the use of the repeater system and fo
r activating
the Emergency Management Building next to Batavia airport,
where AE2EE set up his NCS position for this test.

The repeater chain was subject to significant switch
-
around
delays. A test prior to the main exercise revealed that five
seconds w
as a safe period for stations to wait, in order to ensure
that the switching was complete. This time had to be added to
the inherent latency of the Echolink codec.


Another interesting participant was HP1/OE5CEN, operating
another VoIP HF Gateway located
on the outskirts of Panama City.
Claus’ recently established IRESC facility was operating remotely
with HP1/OE5CEN himself located at his residence in the centre of
the city. The system is still in the setting
-
up stage and on this
occasion had to be fixe
d to an 18MHz frequency which was fully
occupied for most of the test. It was unfortunately necessary for
this Gateway to remain muted for most of the time, meaning that
an opportunity was lost to witness the effect of having two
stations on HF, but on op
posite sides of the globe, operating
through TWO radio Gateways bridged via Echolink. Nevertheless,
HP1/OE5CEN was still able to take part in the exercise, using
Echolink from his residence.


It must have been quite strange for listeners on 80m in the UK
to
hear exotic callsigns during daylight hours, such as VU2RBI in New
Delhi, HP1/OE5CEN in Panama and AE2EE in New York amongst
others.


There were no instances of non
-
participating stations attempting
to call on 80m.


One issue that came to light from t
he previous test T01 was that
of slight peak distortion on the HF transmission. This was almost
definitely due to a combination of slightly too much compression in
the transmitter audio plus minor RF induction back into the
transmitted audio. The new int
erface unit has been designed to
be more RF proof (200W of SSB was being generated less than
10cm from its unbalanced audio connections) and this time no ill
effects were noted.

Some Echolink stations were either over
-

or under
-
modulated, as
is often expec
ted. The compressor of the HF transmitter was set
to smooth out both of these attributes, meaning that the
transmitter was always fully modulated despite significant
variations in the VoIP station speech levels. It is considered that a
shortcoming of the

Echolink software is the fact that there appears
to be no audio compression or limiting in the audio input stage. If
this were the case, the VoIP stations would offer a far more
consistent audio level to the Gateway


a considerable advantage.
When Echo
link passes particularly low audio levels, there is a
perceivable modulation of the noise floor which follows the speech
pattern envelope. This is highly undesirable because when this
audio is modulated via an HF transmitter using audio processing
and com
pression, the effect is exaggerated and can sound like
distortion or RF induction to the listener.


Some Echolink stations, again as often expected, did not offer
‘communications quality’ audio, lacking presence via the higher
audio frequency artefacts. O
n this occasion, the HF transmitter
audio path was treated to try to improve clarity and remove
unwanted low frequency elements and percussive ‘pops’. As well
as the compression mentioned above, audio DSP filters were set to
tailor the response to that re
quired for effective SSB working.

Generally speaking, it would be wise for a Gateway provider to
assume that the audio being offered by VoIP participants is likely
to exhibit wide variations in all parameters. This stems mainly
from the poor facilities
offered by most simple sound card
controllers that are majority use


Windows Audio Mixer for
example offers basic gain control and possibly some treble and
bass control (dependent on sound card) but little else. As far as is
practical, technical treatmen
t of the signal should be attempted at
the Gateway location (even on a moment
-
by
-
moment basis by the
supervisor) but requests for adjustment and education regarding
audio improvement for the future may have to be considered.


The voice recognition squelch

faired quite well. Generally, it
opened and closed on speech despite a high noise level on the HF
frequency, with a workable ‘open’ time constant. Nearby stations,
off channel but still recognisable as speech, tended to hold the
squelch open. Careful u
se of IF filtering reduced this effect but
most Echolink stations noticed that the squelch was being held
open at times, slowing communication. It was also noted that the
voice recognition circuit tended to open for a few seconds,
immediately after a peri
od of HF transmission. Sometimes this
was a useful feature, at other times (when a QSO between two
VoIP stations was taking place, for example) it was less beneficial.


One auxiliary aim of the test was to see how the use of a Gateway
had any effect on th
e already difficult job of Net Control Station
(NCS). For this purpose, the control of the net was passed
between G4HPE (at the Gateway), G4KUJ (on 80m in the UK) and
AE2EE (on VHF in New York, via Echolink).

AE2EE probably had the hardest job, controll
ing stations on HF
from a distinctly remote location via a time
-
delayed repeater chain.
The round
-
trip
-
time across the circuit could have led to chaos if
stations jumped in too early. However, it is a credit to the
disciplined way in which the net was co
nducted that this did not
happen. This test showed that the complex mix of technology can
allow effective communications. The odd misfiring of the voice
recognition squelch could have led to information being missed,
but it didn’t happen in practice.


G4
KUJ was a good signal into the Gateway and likewise was well
heard via it to VoIP. He too was able to keep good control of the
net. The bleep on the end of the Gateway transmissions on HF
proved to be a useful aid to understanding when to go ahead.
Unor
thodox or amateurish it might be dubbed by some, but
efficient communication was aided.


In a more frenetic emergency situation, operators may have been
less disciplined if they had what they considered ‘urgent’ traffic to
impart, because some stations may

fall victim of mis
-
switching of
the Gateway or latency issues across the network. This is hard to
replicate under test circumstances but some ideas to explore this
will hopefully be introduced in further tests.


There is a possibility that if the Gateway

becomes locked on
constant HF traffic, the VoIP side of the net (including its
Controller) would not be able to break in and, further, many
VHF/UHF repeaters would time out after a few minutes leaving
remote users on this system completely unable to hear
the net.
This is a situation in which the Gateway supervisor would need to
intervene to manually allow a period of silence in order to allow
the repeater chain to reset.

Of potential use to the VoIP controller in this instance is a piece of
server/client
software kindly developed specifically for this project
by Len Stefanelli N8AD. The computer that is running Echolink at
the Gateway location runs a small server program, allowing
authorised logins via a TCP port. The remote VoIP NCS logs in to
this TCP
port with the simple client software, which takes the form
of a small screen containing a red TX and a green RX button.
When they click on the red button, they place the HF Gateway
transceiver into transmit through an instruction via the TCP port
which, i
n turn, changes the state of a pin on the PC’s serial port
output, toggling the PTT line of the transmitter thus forcing it into
transmit regardless of the status of the voice squelch. This works
well when the HF frequency is congested, can be made secure

to
wanted logins only, and is an instantaneous action wherever the
sender is on the globe. But it must be remembered that any audio
that follows the instantaneous remote PTT instruction will be
delayed in arrival, thus the remote NCS must not be too quic
k to
send the closing RX instruction otherwise 1 or 2 seconds of the tail
end of the desired audio will not be transmitted! Using this
system, the NCS may choose to bypass any form of squelch in the
HF receiver, electing instead to switch the PTT remotely

for every
transmission they require.


A possible Gateway problem would be a missed check
-
in or check
-
out, almost definitely suffered by the VoIP side of the net, because
the Gateway had switched away from the HF channel and a VoIP
station had started to t
ransmit. This is a hazard which needs to be
understood as requiring intelligent operation, and can probably not
be resolved by simply controlling the technology. NCS should
request check
-
ins and check
-
outs regularly to avoid missing
anyone in this mode o
f net.



Some Echolink participants also reported some packet loss on
VoIP. This manifests itself as ‘chopping’ of the audio although
generally this does not prevent understanding as compensation
software within the programme comes into play and the effec
t is
far less noticeable when listening on HF.



To summarise, some of the lessons learned from this test were:


1.

The audio quality offered by the Echolink station can have a
considerable effect on clarity on the HF frequency.
Insufficient modulation, exce
ssive LF content and mic ‘pops’
all contribute to reducing understandability.

2.

The Echolink text box can be a very useful means of alerting
NCS to an issue or problem. It also allows for instant
feedback to a simple enquiry. This data stream could be
inte
rleaved with the audio on the HF frequency


something
for future development?

3.

The delay introduced by the encoding, transport and
decoding of the audio over the Echolink network is highly
variable from station to station. This depends on the quality
of t
he bulk Internet path, the capability of their station and
the true bandwidth of the local Internet connection. Those
taking part in a net must allow significant pauses before
assuming that an Echolink participant is not going to
transmit! The end
-
of
-
tra
nsmission bleep helps this.

4.

Controlling and monitoring the HF Gateway is a task in its
own right. It may be asking too much of the Gateway
operator to also act as NCS. There are advantages to
combining the two tasks, however, in that an NCS who is
acros
s both sides of the Gateway regardless of its
performance can clearly stay in command of both groups of
stations most effectively. Once the NCS is based on only
one side of the Gateway, their effectiveness to control may
be challenged by the performance o
f the Gateway itself.
However, this test has shown that it is quite possible for an
HF NCS to effectively control the whole net, and similarly an
NCS using the VoIP side. The key appears to be allowing
good pauses between ‘overs’, strong net discipline u
nder
trying conditions, and understanding the potential
shortcomings of the HF voice recognition squelch.

5.

The ability to correctly squelch the HF receiver is critical to
good switching of the Gateway. Voice recognition circuitry
definitely helps the situa
tion but is subject to a number of
pitfalls; for example, reacting to off
-
frequency speech. The
Gateway operator will almost certainly need to intervene in
some circumstances to ensure that communications flow and
the Gateway switches properly, so the int
erface must allow a
number of supervisor controls to make this possible. In all
reality the Gateway supervisor will also be required to adjust
a number of parameters on the HF transceiver to optimise
operation and this will need to take place ‘as it happe
ns’ with
the supervisor listening critically to both the VoIP and Radio
sides simultaneously. Some transmitter parameters that
may need adjustment are drive level, compression and audio
filtering. Some receiver parameters that may need
adjustment are AGC
, audio filtering, IF filtering (to reduce
off
-
channel effects), notch filtering, noise reduction and
noise blanking. Furthermore, the external voice recognition
squelch can be helped by careful use of the receiver’s
standard noise
-
operated squelch. With

all these potential
adjustments to consider, the sentiments of point 4. are
perhaps given additional weight


the Gateway supervision
role is a potentially challenging one.



Snippets:

HP1/OE5CEN: “I know what to change on my site: the remote
control to c
hange frequency. The Gateway did a great job
-
congratulations on this setup!”


G7JAK: “I really did enjoy the whole thing while I was able to hear
it, but things went bad about 4.30 local time, I was picking
Dutch/German/ stations up louder on that freque
ncy than I was
our own crew, so to speak.”


VU2RBI: “it was very interesting talking to radio hams on HF radio
through Internet via Echolink. Everybody’s signals were very
good.”


G0DUB: “The noise level for me was very low as would be
expected from such
a rural location.”




Audio clips are available for download at the following links. It is
suggested that you right
-
click on the links, then select ‘Save
Target As…” to save them somewhere convenient on your own
computer.


1.

G0DUB/P on 80m working AE2EE
on Echolink.

G4KUJ controlling on HF.

This is an interesting clip of QRP station G0DUB/P acting as a
station out in the field requesting to exchange information with an
Echolink station. This clip demonstrates how a station on HF can
satisfactorily contro
l the net. Even though the frequency is heavily
congested, the voice recognition squelch performs satisfactorily.
The end
-
of
-
transmission bleep can also be heard. AE2EE is
working at the far end of a repeater chain.

Recorded on Echolink at G4HPE

1.2MB

http://www.iresc.org/g4hpe/hfg/T02R01.wav


2.

G4PGZ working GW0VMZ, both on Echolink.

G4KUJ controlling on HF.

Another good demonstration of how the full net can be controlled
effectively by an HF N
CS. Note the voice recognition squelch
sometimes being held open by the heavy off
-
frequency HF
stations.

Recorded on Echolink at G4HPE

760KB

http://www.iresc.org/g4hpe/hfg/T02R02.wav


3.

G4PGZ w
orking GW0VMZ, both on Echolink.

This is the same exchange as in clip 2. but as recorded on HF,
allowing a comparison to be made as experienced by the various
participants.

Recorded on HF at G4PGZ


857KB

http://www.iresc.org/g4hpe/hfg/T02R03.wav


4.

G8OJQ working G4KUJ, both on HF, then GW0VMZ on Echolink.

G4HPE controlling at the Gateway.

A good example of one station working firstly on HF then Echolink.

Recorded on HF at G4PGZ



1.4MB

http://www.iresc.org/g4hpe/hfg/T02R04.wav


5.

HP1/OE5CEN HF Gateway as heard on Echolink.

This short clip demonstrates an NCS using the Panama HF
Gateway


sadly not the participating station we were hopi
ng for
but good DX anyway!

Recorded on Echolink at G4HPE

235KB

http://www.iresc.org/g4hpe/hfg/T02R05.wav


6.

HP1/OENCEN HF Gateway as heard on HF

This is a slightly longer version of clip 5., but

this time as heard on
HF in the UK. This demonstrates that it should be quite possible
for an HF station in Europe to work an HF station in Central
America, using both Gateways bridged by Echolink. The audio
seems quite workable.

Recorded on HF at G4PGZ


350KB

http://www.iresc.org/g4hpe/hfg/T02R06.wav


7.

HP1/OE5CEN working AE2EE as heard on Echolink.

G4HPE controlling at the Gateway.

Recorded on Echolink at G4HPE

889KB

http://www.iresc.org/g4hpe/hfg/T02R07.wav


8.

HP1/OE5CEN working AE2EE on Echolink.

This is the same exchange as in clip 7. but this time as heard on
HF in Europe. Notice that there is a degree of fading on the HF
signal c
aused by the propagation effects.

Recorded on HF at G4PGZ


866KB

http://www.iresc.org/g4hpe/hfg/T02R08.wav


9.

VU2RBI working G4HPE, both on Echolink.

G4KUJ controlling on HF.

Recorded on HF at G4P
GZ


1.1MB

http://www.iresc.org/g4hpe/hfg/T02R09.wav


10.

VU2RBI on Echolink working GI7THH on HF.

G4HPE controlling at the Gateway.

GI7THH was a variable signal


the Gateway supervisor had to
manu
ally switch the system at times. Communication was
marginal due to occasional weak signal strengths and interference,
but despite this the message got through.

Recorded on Echolink at G4HPE

844KB

h
ttp://www.iresc.org/g4hpe/hfg/T02R10.wav