Monday, 14 July 2014

Night of Nights 2014

I've followed the story of the USA's "Maritime Radio Historical Society" and their restoration of the former coast station KPH at Point Reyes/Bolinas in California over the last few years. For background reading they have a nice website : www.radiomarine.org and various You Tube videos: https://www.youtube.com/channel/UCzOHX9NbY07RXMfBzQKjpNQ

Each year, on the anniversary of the initial closure of KPH they bring the station back to the air for "Night of Nights", and have pulled in other former Morse Coastal stations who still have facilities, such as WLO in Alabama. This year I wanted to see if I could hear any of the action.

KPH and most of the other stations are on the West Coast, and mid-summer, with static crashes and little darkness, means hearing them on MF or the low HF bands is unlikely. VOACAP showed a chance on bands between 8 and 17MHz. WLO in Alabama was likely to be a little easier to hear, although again, 500kHz was never likely to be successful.

The event was due to begin at "one minute past 5 pm" PST - one minute after the anniversary of the shutdown on July 12th 1999.

This is 0001 UTC which is 01:01 BST!

The MRHS published the planned frequencies of the participants in their newsletter http://archive.constantcontact.com/fs149/1109843077277/archive/1117617624147.html

I programmed the frequencies into my HF radio and settled down for a late night looking for weak CW.

At 2045 UTC I heard "NMC de KKUI" on 16736kHz and then shortly afterwards "WLO do KKUI" also on 16736kHz. KKUI is the callsign of "American Victory", a museum ship anchored in Tampa, Florida. http://en.wikipedia.org/wiki/SS_American_Victory

Later I began to hear WLO sending it's "wheel", the repeating channel announcement listing their listening frequencies. I could hear them on their 8MHz, 12MHz and 16MHz channels, although shortly afterwards the 12MHz channel fell silent.

Here's a recording from 16968.5kHz https://dl.dropboxusercontent.com/u/3551430/wlo_wheel_non_2014.mp3

At 0001 UTC I began to hear, very weakly - affected by static crashes and all manner of polar fluttering etc. a barely detectable Morse signal from KPH on 17016.8  and in parallel from KFS on 12695.5  and 17026.0

The best recording I could manage is here https://dl.dropboxusercontent.com/u/3551430/kph_non_2014.mp3

Not good, but with a bit of imagination you can hear "VVV" and "KPH" and a few other things drifting out of the noise.

At 0030 UTC I again heard "American Victory" KKUI calling KPH, and heard the KKUI side of a contact with the former coast station. Quickly checking the frequencies used by KPH showed nothing I could read, so I've only got the KKUI side of the QSO:

https://dl.dropboxusercontent.com/u/3551430/kkui_wkg_kph_nightofnights_2014.mp3

After this QSO with KPH I heard KKUI calling the partner station of KFS, and again captured the KKUI side of the exchange:

https://dl.dropboxusercontent.com/u/3551430/kkui_wkg_kfs_nightofnights_2014.mp3

There were also amateur stations active at KPH and WLO - K6KPH and W4WLO respectively. I heaerd WLO's wheel giving the frequencies, but heard nothing of W4WLO - but there was a big amateur radio contest in full flow (the IARU HF Championship). I did hear a station, K4JJW, calling K6KPH briefly on the amateur 17m band (18097.5kHz):

https://dl.dropboxusercontent.com/u/3551430/k4jjw_clg_k6kph_17m_non_2014.mp3

I lasted until 2am local time before calling it a night. I'm sure more traffic would have been audible later, especially on the lower channels, 12MHz and 8MHz.

I checked the channels at around 0700 UTC and heard weakly the final closing message, not really readable, but the odd snatch was clear enough to determine what the signal was, on one of the 8MHz channels used by KPH/KSM/KFS

https://dl.dropboxusercontent.com/u/3551430/kph_qrt_non_2014.mp3

Looking at WLO's channels and I found their closing statement, ending with the first message sent by Samuel FB Morse: "What hath God wrought?"

https://dl.dropboxusercontent.com/u/3551430/wlo_qrt_non_2014.mp3

I enjoyed knowing that these old transmitters were back on the air, imagining the lights dimming on each dot and dash when keying multiple high power transmitters in parallel. It's a pity that none of the European power houses of the past have been conserved and could join in this celebration and remembrance of the history of Marine Radio using Morse Code. At least we still have the MRHS to keep CW alive.





Wednesday, 9 July 2014

Update on VHF/HF Cross-gate

The Voice Operated Squelch used in the first test version was okay for detecting human speech, but suffered from false triggering on static crashes from thunderstorms. Further research showed that the kit I got via eBay is a copy of the Naval VOS-4 design :

http://www.naval.com/vos/

This is also the squelch circuit used by Steve G4HPE in his experimental HF-Internet Gateway:

https://sites.google.com/site/gatewayhf/

I decided to try the "original" syllabic squelch circuit, as published in 73 Magazine in 1982 and is a copy of the Motorola "Constant SINAD Squelch" which was originally part of their MICOM range of HF SSB radios:

http://www.repeater-builder.com/projects/jpl-vox-sq/orig-article-large.pdf


This proved to be much more successful, and since it's adequately documented it is possible to make changes to component values to alter the behaviour to suit different purposes. The Jet Propulsion Lab modified this circuit to use on a link feeding NASA-Select downlink audio into a VHF Repeater:

http://www.repeater-builder.com/projects/jpl-vox-sq/ssb-squelch.html


I'm planning to replace the V/UHF link transceiver - currently an FT817 which gets warm even when on Low Power during a long "HF to UHF" transmission - installing an FT8900R which is capable of higher power, and also has a cooling fan. The external "data" interface is identical to the FT817 and therefore can easily be swapped in without re-making cables.

Since this is effectively "Remote Operation" under Clause 10 of the UK Amateur Licence, the 70cm port can run at any power (up to the maximum allowed by the license) as the "communication link" to operate the main station

10(1) The Licensee may conduct Unattended Operation of Radio Equipment provided thatany such operation is consistent with the terms of this Licence. Additional restrictions whichapply to the Unattended Operation of Beacons are specified in Schedule 2 to this Licence.  
10(2) Subject to Clause 10(3), the Licensee may also conduct Remote Control Operation ofRadio Equipment (including, for the avoidance of doubt, Beacons) provided that any suchoperation is consistent with the terms of this Licence.  
10(3) This Clause 10 does not permit the Licensee to install Radio Equipment capable ofRemote Control Operation for general unsupervised use by other Amateurs.  
10(4) Any communication links used to control the Radio Equipment or to carry Messages to or from the Radio Equipment in accordance with Clause 10(2) must be adequately secure so as to ensure compliance with Clause 3 of this Licence. Any security measures must be consistent with Clause 11(2) of this Licence. 
10(5) The use of any such communication links referred to in Clause 10(4) must be failsafesuch that any failure will not result in unintended transmissions or any transmissions of atype not permitted by this Licence. 
10(6) If this Licence is a Foundation Licence or an Intermediate Licence, and the Licenseewishes to establish communication links to operate the Radio Equipment in accordance withClause 10(4), then the Licensee may only do so using wireless communication links and theLicensee may only use the amateur band allocations detailed in Schedule 1 to operatethose links. Any such communications links shall be subject to a maximum power level of500 mW pep e.r.p. 
10(7) Only where this Licence is a Full Licence, Full (Reciprocal) Licence, Full (TemporaryReciprocal) Licence or a Full (Club) Licence, the Licensee may make use of anycommunications links (including, for the avoidance of doubt, the amateur band allocationsdetailed in Schedule 1) to establish the wireless communication links referred to in Clause10(4).

Clause 10(4) is taken care of by

  1. Using DCS on the 70cm port, with "code" which is is regularly changed.
  2. Using DTMF to control the talk-through, which requires a 4-digit "PIN" number before the instruction to enable/disable the HF-UHF and the UHF-HF talkthrough. The ability to enable each direction separately allows for "HF Monitoring" without enabling "HF Transmit" and only enabling the UHF-HF direction when two-way comms is required.
The link can't be "encrypted" as that's forbidden by the general licence conditions, but I think the steps of "DCS" to access the UHF port and "DTMF" to enable/disable talkthrough meet the terms of clause 10(4):

10(4) Any communication links used to control the Radio Equipment or to carry Messages
to or from the Radio Equipment in accordance with Clause 10(2) must be adequately secure
so as to ensure compliance with Clause 3 of this Licence.

I've used the remote link to have QSOs with GM4WMM by operating the home station on 5.298MHz while I was located approx 26km from home, and the system worked well.

Thursday, 26 June 2014

First Place in CQWW

I dabbled in the CQWW SSB Contest last year and submitted a log. I've just checked the CQWW results and it appears I came First in my country for the Single Op, All Band, Low Power category!

Since Shetland is a separate country for CQWW, and there were only 3 active stations in the contest

Saturday, 21 June 2014

HF - VHF Cross-gate

I've been playing with the idea of being able to cross-band repeat between HF and VHF, after reading about the Barrett 2062 x-gate on their website:

http://www.barrettcommunications.com.au/2062.html

Initial tests last year, just using the simple RF-level squelch from the HF transceiver to trigger transmit PTT on the VHF port proved rather poor, as fairly readable HF SSB signals were not causing the squelch to open. What was needed was a syllabic squelch - as found on professional HF SSB radios - for the HF port. Using the VHF transceiver's normal FM squelch is perfectly okay, of course.

I found various designs for "Voice Activated Squelch" circuits and then stumbled on a kit on eBay:

http://www.ebay.co.uk/itm/VOS-Voice-Operated-Squelch-Audio-Muting-Kit-Form-/321145239752

I bought a couple and built one to play with, in series with the audio from the HF receiver. It certainly worked much better on weak SSB than an AGC/RF level squelch.

The Barrett device also used DTMF (or SELCAL) to activate the talkthrough, so I thought I'd try and emulate that, and found another kit that would fit the bill:

http://www.cstech.co.uk/dtmf-kits/dtmf-decoder/

I built the kit, but never tested it. I consigned both the VOS board and the DTMF board to the "in progress" pile, and forgot about them for 12 months!

Today I thought I'd resume the project......

After modifying the VOS board to trigger a relay, which could be used as a PTT source for the VHF radio, I wired it all up on the bench, and it works, I even get the revertive CW signals from the DTMF board sent back over the VHF port when the commands are issued to turn the relay on & off.

Adding a few switches to manually inhibit talkthrough, or to override the DTMF driven active/inhibit relays and it's all boxed up and working. I need to add some LEDs, to show what's happening inside. The one main difference between this box and the Barrett 2062 is that the Barrett device allows remote channel changing of the HF transceiver via the VHF port - something that's not immediately possible in this simple version. I guess a PIC and some programming and it might be possible to send CiV signals tothe IC7200 on receipt of specific DTMF sequences, but that's starting to get more complicated!


Using the IC7200's rear-panel accessory socket also has the bonus that the Speech Processor is available, unlike the old IC718 (where the processor only worked on the front panel Mic socket).

Now I need to try it out on the air, 5MHz would seem the ideal place to test these things - so I need to set up a sked with a willing volunteer...

EDIT:

After much local testing, and quite a bit of listening, I heard MM1MAJ/P on 5403.5kHz operating from a SOTA summit near Loch Leven. Weak, barely moving the S-Meter on 5MHz but triggering the syllabic squelch in the x-gate reliably so I thought I'd try a call to him. He came back instantly and gave me a 5/7 report. The only minor issue is the few seconds the HF squelch takes to drop at the end of an incoming transmission, but that's no real problem. I'm quite pleased it worked on the first real on-air QSO.

I've thought a bit about HF channel changing, and the only simple solution seems to be to use one of the DTMF relays (there can be up to 6 relays) to trigger an up/down channel change via the Mic socket (pin 3). Unfortunately the "pulse" option of the DTMF board toggles a relay for 1/2 a second, which is too long for a single channel step. I will think about a pulse shortening circuit (differentiating the 1/2 second pulse and using that to click a relay for a brief instant.....?).

Or just leave the HF transceiver on one frequency.

I will try to monitor 5298.5kHz as this channel tends to be lightly used, and the regular occupants tend to mess about with odd setups too, so perhaps it's a good place to try some tests.

I've found it necessary to leave the DSP Noise-blanker turned on to remove the occasional (weak) clicking from a distant electric fence, which would occasionally trigger the syllabic squelch. I also find that night-time lightning static crashes can also be a nuisance, as they tend to occur at roughly speech pulse rate, I guess. Using the DSP Noise Reduction and (for good measure) leaving the Auto Notch Filter engaged might just be enough to keep things usable.

A 5-minute TimeOutTimer on the V/UHF transceiver (an FT817) means it's possible to recover control should something (a long...long...over for example) hold the x-gate open in the RXHF->TXVHF direction. Once the V/UHF rig "times out" it's possible to send the DTMF "OFF" sequence and kill the x-gate until the long QSO on HF is over, or the HF channel can be changed.

Tuesday, 17 June 2014

New box for GB3LU

Our old Icom repeater unit at GB3LU is starting to show its age - already the internal PSU has died and it was running on an external 12V PSU, and recently it's being turning itself off, for no obvious reason. Time for an upgrade....

I had a Simoco PRF1050 in my "rainy day" cupboard under the stairs that would do the job nicely, as long as it would interface with the existing Logic (a G8CUL designed controller I built some years ago). Checking it out on the bench showed that RX & TX Audio, Squelch (COR) and PTT were easily accessible via the 37-way facilities plug:

PIN NO.PRF10FUNCTIONALITY
1Tx600 Ohm-14dbm nominal for 60% dev at 1Khz (Range -37dbm to 0dbm)
Transformer coupled to pin 20 or AF high if unbalanced
2-ve-ve
3Rx600 Ohm-14dbm nominal for 60% dev at 1Khz (Range -37dbm to 0dbm) Transformer coupled to pin 22 or AF high if unbalanced
4No connection made
5Common Station AlarmOpen collector low, when active
6Not assigned reserved for future use
7Not assigned reserved for future use
8CTCSSUnprotected input to TX modulator. Level and input impedance to be advised shortly
9+13.6v unswitched1 amp available to power external devices
10TX KeyPull down. Typical current 1.5mA. Open circuit voltage typically 5V
11TX Lock AlarmOpen collector low when activated
12-ve-ve
13RX Lock AlarmOpen collector low when activated
14CTCSS Decoder DefeatPull down to activate. When activated allows squelch to open with any signal
15RSSIRange as follows but can be negotiated if difficult to implement Graph attached
16Channel Line 6Binary C6, Normally high, pull low
17Channel Line 4Binary C4, Normally high, pull low
18Channel Line 2Binary C2, Normally high, pull low
19Channel Line 0Binary C0, Normally high, pull low
20TX600 Ohm-14dbm nominal for 60% dev at 1Khz (Range -37dbm to 0dbm)
Transformer coupled to pin 1 or AF return/ground if unbalanced
21No connection made
22RX600 Ohm-14dbm nominal for 60% dev at 1Khz (Range -37dbm to 0dbm)
Transformer coupled to pin 3 or AF return/ground if unbalanced
23External LS HighExternal loudspeaker typically 16 Ohms
24Squelch StatusOpen collector, low when squelch open
25Squelch Relay NC1 amp DC maximum at 48V DC. Floating
26Squelch Relay NO1 amp DC maximum at 48V DC. Floating
27Squelch Relay CommonFloating
28DC Input under voltage alarmThe PRF10 can charge external 12V Sealed Lead Acid battery. The battery can be damaged is subject to a deep discharge. The PRF10 automatically disconnects at a predetermined voltage. An alarm is signalled at 100mV prior to disconnect. Open collector low, when activated
29Talk Through EnablePull down to activate
30Squelch DefeatPull down to activate
31No connection made
32No connection made
33RF Output AlarmOpen collector low, when RF fails to meet power
34Unfiltered and unmuted RX AFEffectively discriminator output. Level and impedance to be defined shortly
35Channel Line 50Binary C5, normally high, pull low
36Channel Line 3Binary C3, normally high, pull low
37Channel Line 1Binary C1, normally high, pull low


The plan to interface with the existing GB3LU Logic :

Audio
TX Audio : PRF10 pin 1 - Logic pin 12
RX Audio : PRF10 pin 3 - Logic pin 10

Also Earth PRF10 pin 20, 22 (to PRF10 pin 12) for unbalanced audio

SQL - low on Squelch open :
Earth PRF10 pin 27 (SQL relay common)
SQL signal : PRF10 pin 26 - Logic pin 4

PTT:
PRF10 pin 10 - Logic pin 7 (logic pulls this low to transmit)

Power for the Logic unit from PRF10 pin 9 - Logic pin 1
Ground : PRF10 pin 12 - Logic pins 14-25

This worked fine except for 2 problems....

1) The TX line-input greatly attenuated the CTCSS tones sent from the logic unit and it was not possible to achieve a sensible deviation for the 77Hz CTCSS on transmit.

2) The RX line-output also had a reduced amplitude of the RX CTCSS tone, which is used in the Logic unit to enable the talkthrough (we don't use old fashioned 1750Hz access, but require "continuous" CTCSS)

Problem 1 was solved by finding that there is a direct feed in from pin 8 for injecting external CTCSS tones. Initially this proved not to work as expected until I discovered there's a handbag link on the main PCB that connects the input from pin 8 through to the analogue circuits of the PRF10. Installing the missing link got the external CTCSS input working. I modified the Logic unit to feed a separate TX CTCSS signal from the CTCSS encoder chip into the PRF10 / pin 8. A pot on this feed allowed the deviation to be adjusted to around 500Hz. The driving factor with wanting to use the Logic unit's own CTCSS signal, and not simply configuring the PRF10 to transmit a 77Hz CTCSS tone, is that we carefully adjusted the timing of the Logic's CTCSS to aid the use of personal "cross-band repeaters" - and users who avail themselves of this were keen to maintain the function. This requires that the outgoing CTCSS is muted shortly after the "pip/K" end of over signal, allowing x-band repeaters to drop back to "idle". If the CTCSS was enabled continuously during the time the box is "open" then the only way to operate a x-band repeater is to let the box close down at the end of each over, and then re-access it once your x-bander has dropped out. Keeping the custom-timed CTCSS is therefore an important requirement. Also, as a pleasant side effect, the CTCSS is also muted during the regular repeater idents, so anyone choosing to monitor with "Tone Squelch" will only hear actual traffic.

GB3LU Logic Unit

Re-programming the controller

PRF10 under test


Problem 2 was investigated further....

I found that a normally modulated input signal (with > 300Hz deviation of the CTCSS) would trigger the Logic's CTCSS decoder, even though the 'scope showed the amplitude of the CTCSS tone at the input to the Logic to be only around 14mV rms, and a long way below the amplitude of the main audio signal. A problem still existed though - if an over-deviated signal was present I found that the CTCSS decoder dropped out on speech peaks, and then the talk-gate would close briefly- leading to breaks in through audio on speech peaks - but only with either very noisy or over deviated input signals.

There is a feed of un-processed "discriminator" audio from the PRF10 at pin 34 and this had ample CTCSS level, but also the full audio signal too. I built a 2 pole active LPF with a 300Hz cut-off and put it in series with the "raw" RX audio, and then paralleled this (via a 1k resistor) with the normal RX Line input to the Logic. This improved the detection of the CTCSS tone, it would open with a CTCSS deviation of around 200Hz, but simply tee-ing the two audio feeds (LPF feed of CTCSS and the de-emphasised main RX audio) wasn't the right solution. I would need to modify the Logic unit to provide a separate "CTCSS Input" directly to the CTCSS chip - fed from the LPF'd raw audio.

I decided to revert to the initial condition- one audio feed - and to re-programme the Logic back to "classical 2m repeater behaviour" in that CTCSS is only needed to initially open the repeater, and not to maintain talk-through. This seemed to be a decent compromise, and I also restored the 1750Hz tone-burst access too. The repeater was only configured for continuous CTCSS to overcome a problem with local interference on the repeater's input frequency, generated by a site-sharer at the repeater site, and it appears that the device responsible for this interference is no longer in use.

Bench measurements show that the RX sensitivity is good:

Squelch opens at -113dBm / 20dB SINAD with the PRF10 set to its minimum Squelch threshold (parameter 105.xx = 1). The squelch threshold at this setting  is nominally "9dB" but this isn't actually the case in reality. I experimented with varying PRF10 parameter 921 (factory set squelch calibration) and found:

As found : 077
Threshold : -113dBm / 20dB SINAD

Adjusted to : 020
Threshold : Squelch permanently Open
-117dBm  / 15dB SINAD

Adjusted to: 028
Threshold : -115.5dBm / 18dBm SINAD

I reset the parameter to the default value (077) for the time being. Squelch threshold can be revisited once the box has had a bit of on-air use, and after the antenna/feeder is replaced.

For reference the higher squelch settings:
Parameter 105.xx:
2 (nominally 12dB SINAD) : Threshold = -111dBm / 23dB SINAD
3 (nominally 15dB SINAD) : Threshold = -109dBm / 24dB SINAD

The various timings for the Logic are currently:

"Pip" time (from squelch close to sending the "pip/K" ) = 1 second
CTCSS off time (from squelch close to cutting outgoing CTCSS ) = 2 seconds
Off Time (from squelch closing to closing repeater if no further input) = 9 seconds
Toneburst length (minimum 1750Hz toneburst to be recognized) = 500mS
Latch Time (length of carrier required after toneburst to cause the repeater to open fully) = 1 second
Squelch Delay (minimum length of carrier required to cause an "ack") = 1 second
Timeout Time (overs longer than this will cause the repeater to "timeout" and then to closedown) = 10 minutes
Timeout End Time (period of "pips" marking the timeout before closedown) = 10 seconds

Beacon Time : 15 minutes
Send Locator with beacon : every 4 (i.e. once per hour)

To access : at least 500mS of 1750Hz toneburst or a valid 77Hz CTCSS and one second of carrier/audio
The repeater will key up briefly on input signals for shorter than this duration.

To prevent 10 minute Time-Out - ensure you wait to hear the "pip/K" at the end of the over before you start to transmit. This indicates the 10 minute timer has been reset. If a station transmits for > 10 minutes the repeater will cut the through audio and send a series of 10 one-seconds pips before closing down. Once the input signal has gone the repeater will key up and send "OK" in morse, and will then be available as normal.

A stronger signal can re-set a timeout that's in progress by sending a valid 1750Hz toneburst, or 77Hz CTCSS, as long as they can overcome the signal that's currently transmitting.

There is also a remote DTMF Closedown and Startup command - to be circulated to the Repeater Closedown Operators - which will cause the repeater TX to be inhibited or restored, by sending specific DTMF codes. This assumes you are able to overcome any signal on the input frequency that might be causing problems, but at least it will allow a remote shutdown, even if you have to travel nearer to site. If it means not actually having to get up the hill, and into the hut in a Shetland winter storm, that's a good thing!

GB3LU is back on the air as of June 13th 2014, using the PRF10 - notionally on "soak test".

GB3LU in the hut & on the air

Coverage is reduced at present due to antenna/feeder problems - and these will need to be addressed before the end of the summer.

Sunday, 8 June 2014

Echolink & Svxlink

Following my setting up of the APRS Gateway MB7UZE on 144.800MHz I considered what to do about the Echolink node I was experimenting with last year, running SVXLINK under the callsign MB7IZE. I hadn't used the Voice Gateway for many months, but setting up the APRS gateway made me wonder about resurrecting the Echolink node at the same time.

MB7IZE was licensed for 144.9625MHz and obviously couldn't be used at the same time as a 2m APRS gateway/node. My previous trials of SVXLINK and Echolink proved that due to my location the only station likely to use my Voice Gateway was me.... so perhaps a 70cm port would be acceptable. I set up a new installation of SVXLINK (a self-compiled installation of the current version 13.12) on a Linux PC (eventually I'll move it over to a Raspberry Pi) and connected the PC to an FT817 on 430.050MHz, terminated in a 50 ohm dummy load. This allows me to test the setup, and it seems to work well.

I have applied for an NoV - initially asking for a change of frequency for MB7IZE, to move it to 70cm. This isn't allowed - for some arcane reason unattended simplex voice gateway operation isn't allowed on 70cm in the UK, although it's okay on 10m, 6m, 4m & 2m and unattended duplex voice repeaters are allowed. I've decided to leave MB7IZE alone, with a 2m port, which will be used only when the APRS station is turned off, and to apply for an "attended" NoV under my own callsign GM4SLV on 70cm. This is still in the "vetting" stage with the RSGB.

I now have a VHF/UHF duplexer (a Diamond MX-72A) which will allow me to share the dual-band colinear between the 2m APRS transceiver and the 70cm SVXLINK transceiver and I'm planning to replace the little FT817 with a single-band FT-1907. In the meantime, while I wait for the NoV, I'm running the 70cm SVXLINK node into dummy load. I can still use it from anywhere within the house and garden. Makes you wonder what the point of an "attended" Gateway is.... rather stifles the spirit of experimentation, I feel.

My Echolink node is GM4SLV-L / node number 886089 and is only online when I'm at home, of course. SVXLINK is able to run external scripts on receipt of DTMF tone sequences, so it's now set up to so that I can connect or disconnect from Echolink by sending specific DTMF sequences, so I can enable Echolink when I'm "at home" and disable it before I leave, without needing to sit at a PC screen, it can be done over the air.

I installed SVXLINK following the instructions at the Sourceforge page:

http://sourceforge.net/apps/trac/svxlink/wiki/InstallationInstructions

I then made two config files - one that includes the Echolink Module and one that doesn't.

A bash script "svx_el.sh" starts the program (as a daemon) using the config file that includes the Echolink Module. I've found that svxlink doesn't always exit cleanly, so I "sudo killall svxlink" three times to ensure the current running version is killed before starting the new version.

#!/bin/bash

CFG=/home/gm4slv/svxlink_el.conf
LOG=/home/gm4slv/svxlink.log

sudo killall svxlink
sudo killall svxlink
sudo killall svxlink
sudo svxlink --daemon --logfile=$LOG --config=$CFG
exit 0


Another bash script "svx_noel.sh" kills any existing svxlink and restarts the daemon using a config file that doesn't include the Echolink module. This allows me to control whether I'm logged into Echolink or not, while keeping the basic svxlink functions alive.

#!/bin/bash

CFG=/home/gm4slv/svxlink_noel.conf
LOG=/home/gm4slv/svxlink.log

sudo killall svxlink
sudo killall svxlink
sudo killall svxlink
sudo svxlink --daemon --logfile=$LOG --config=$CFG
exit 0

Adding a "local" event to svxlink's events directory means it's possible to trigger either of these scripts over the air, using DTMF tones.

###############################################################################
#
# Generic Logic event handlers (local extension)
#
###############################################################################

#
# This is the namespace in which all functions and variables below will exist.
#
namespace eval Logic {

#
# Executed when a DTMF command has been received
#   cmd - The command
#
# Return 1 to hide the command from further processing is SvxLink or
# return 0 to make SvxLink continue processing as normal.
#
proc dtmf_cmd_received {cmd} {
  global active_module

  if {$active_module != "" && [string index $cmd 0] != "*"} {
    return 0
  }
  if {[string index $cmd 0] == "*"} {
    set cmd [string range $cmd 1 end]
  }

  if {$cmd == "99"} {
    puts "Executing external command"
    exec /home/gm4slv/svx_el.sh &
    return 1
  }
  if {$cmd == "98"} {
    puts "Executing external command"
    exec /home/gm4slv/svx_noel.sh &
    return 1
  }
  if {$cmd == "5417"} {
    puts "Executing external command"
    CW::play "QRT"
    exec /home/gm4slv/qrt.sh &
    return 1
  }

  return 0
}

# end of namespace
}

#
# This file has not been truncated
#

This file is saved as  /usr/share/svxlink/events.d/local/Logic.tcl

In this example sending the DTMF tones "*99#" will trigger the "Connect to Echolink" script and sending "*98#" will trigger the dis-connect from Echolink script. Sending "*5417#" will play "QRT" in morse code over the air, and then trigger the script "qrt.sh" which simply kills svxlink. A Remote Shutdown....

#!/bin/bash

sleep 10
sudo killall svxlink
sudo killall svxlink
sudo killall svxlink

SVXLINK runs as a "daemon" so to keep an eye on it, I use a log-file, which I can monitor using "tail -f":

Here's what is shown in the log as I send the "*99#" command to restart SVXLINK, and connect to Echolink:


Sun Jun  8 11:20:06 2014: Rx1: The squelch is OPEN (1.66469)
Sun Jun  8 11:20:06 2014: SimplexLogic: digit=*
Sun Jun  8 11:20:09 2014: Rx1: The squelch is CLOSED (5.2813)
Sun Jun  8 11:20:09 2014: Tx1: Turning the transmitter ON
Sun Jun  8 11:20:25 2014: Tx1: Turning the transmitter OFF
Sun Jun  8 11:21:17 2014: SimplexLogic: digit=*
Sun Jun  8 11:21:17 2014: Rx1: The squelch is OPEN (2.07459)
Sun Jun  8 11:21:17 2014: SimplexLogic: digit=9
Sun Jun  8 11:21:18 2014: SimplexLogic: digit=9
Sun Jun  8 11:21:20 2014: SimplexLogic: digit=#
Sun Jun  8 11:21:22 2014: Rx1: The squelch is CLOSED (5.26572)
Sun Jun  8 11:21:22 2014: Executing external command
Sun Jun  8 11:21:22 2014:
Sun Jun  8 11:21:22 2014: SIGTERM received. Shutting down application...
Sun Jun  8 11:21:22 2014: SvxLink v1.3.0 (Jun  3 2014) Copyright (C) 2003-2013 Tobias Blomberg / SM0SVX
Sun Jun  8 11:21:22 2014:
Sun Jun  8 11:21:22 2014: SvxLink comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
Sun Jun  8 11:21:22 2014: welcome to redistribute it in accordance with the terms and conditions in the
Sun Jun  8 11:21:22 2014: GNU GPL (General Public License) version 2 or later.
Sun Jun  8 11:21:22 2014:
Sun Jun  8 11:21:22 2014: Using configuration file: /home/gm4slv/svxlink_el.conf
Sun Jun  8 11:21:22 2014: --- Using sample rate 48000Hz
Sun Jun  8 11:21:22 2014:
Sun Jun  8 11:21:22 2014: Starting logic: SimplexLogic
Sun Jun  8 11:21:22 2014: Loading RX: Rx1
Sun Jun  8 11:21:22 2014: Loading TX: Tx1
Sun Jun  8 11:21:22 2014: Loading module "ModuleHelp" into logic "SimplexLogic"
Sun Jun  8 11:21:22 2014:       Module Help v1.0.0 starting...
Sun Jun  8 11:21:22 2014: Loading module "ModuleParrot" into logic "SimplexLogic"
Sun Jun  8 11:21:22 2014:       Module Parrot v1.1.0 starting...
Sun Jun  8 11:21:22 2014: Loading module "ModuleEchoLink" into logic "SimplexLogic"
Sun Jun  8 11:21:22 2014:       Module EchoLink v1.2.0 starting...
Sun Jun  8 11:21:22 2014: SimplexLogic: Event handler script successfully loaded.
Sun Jun  8 11:21:23 2014: EchoLink directory status changed to ON
Sun Jun  8 11:21:24 2014: --- EchoLink directory server message: ---
Sun Jun  8 11:21:24 2014: EchoLink Server v2.5.9997
Sun Jun  8 11:21:24 2014:
Sun Jun  8 11:21:24 2014: ECHOEC2-3: Herndon, VA USA
Sun Jun  8 11:21:24 2014:

Saturday, 7 June 2014

APRS in Shetland

I dabbled with APRS last year, both on VHF (2m) and on HF (30m). This being Shetland, and sparsely populated with other amateurs, there wasn't really much APRS traffic - only what I generated myself from my mobile TinyTrak installations. This year has been much more productive. Tony GM7AFE has set up an I-Gate, and even went to the trouble of getting a "Notice of Variation" to run an unattended gateway, under the callsign MB7UZL. I thought I'd join the project - knowing from previous periods of dabbling in APRS that it only makes sense if more people are active. I applied for, and was granted, my own NoV - callsign MB7UZE and have installed my own I-Gate on 144.800MHz.

Initially I was using a Windows XP netbook and the old favourite software UIView, but then I started to read around the subject and decided to try running the I-Gate on a Raspberry Pi. Various iterations followed, using firstly the Linux "AX25 Soundmodem" as the virtual TNC, then an old Kantronics KAM+ TNC in "Kiss" mode, with the Linux AX25 stack, until the final solution - a TNC-Pi kit for the R-Pi which plugs directly into the GPIO connector, and makes the R-Pi into a standalone APRS gateway.

I have the R-Pi in "headless" mode, accessing it via SSH, with no monitor or keyboard connected, and tried various APRS software. A good, low-resource solution is APRX, which runs beautifully on the R-Pi, but I've settled on "DIXPRS" - more CPU intensive, but also more features than APRX.

I run an APRS Tracker (a TinyTrak4 from Byonics) fed by a small SIRF GPS module in the Land Rover as GM4SLV-9 and positions are reported to the APRS-IS internet servers by being received at either Tony's QTH (MB7UZL) or my own (MB7UZE). Tony has a tracker, GM7AFE-9, too.

My I-Gate, running on the Raspberry Pi / TNC-Pi uses "DIXPRS" and a summary page of current info is available via the web at http://www.gm4slv.org:9999 as well as more comprehensive information of received and transmitted APRS packets at the DIXPRS database http://udplog1.dixprs.net:8880/aprspackets.php?source=MB7UZE


The main place to find APRS information : tracks, positions, telemetry, status etc etc. is at APRS.FI

It is possible to send messages to any APRS stations worldwide when in range of either of our I-Gates, and to received messages too.


The R-PI and TNC-Pi:


The R-Pi and below it, the 2m transceiver (FT2900) :



The various steps to get AX25 working on the R-Pi, once all the relevant packages have been installed.

1) Create an AX25 port for the TNC by editing /etc/ax25/axports

# /etc/ax25/axports
1 MB7UZE 19200 236 2 VHF APRS (1200 bps)

2) Attatch the TNC-Pi (which is a "KISS Mode" TNC) to the AX25 port listed in /etc/ax25/axports

kissattach /dev/ttyAMA0 1 10.0.0.1

Adjust various paramaters:

kissparms -p 1 -f n -l 50 -r 32 -s 320 -t 400

Configure the AX25 port as a  TCP/IP interface:

ifconfig ax0 10.0.0.1 netmask 255.255.255.0
ifconfig ax0 hw ax25 MB7UZE up

Start the mheard daemon:

mheardd -f

This sets up basic AX25 operation. You can use the "axcall" and "axlisten" programs to make packet connections, or to monitor activity, assuming there's packet activity in your area - not here!

 To monitor with axlisten:

axlisten -cart


The mheardd daemon keeps a list of AX25 calls heard, and you can see them using "mheard":

root@aprs:/usr/local/dixprs# mheard
Callsign  Port Packets   Last Heard
MB7UZE     1       889   Sun Jun  8 08:53:03
MB7UZL     1       448   Sun Jun  8 08:51:44
LA3QMA-1   1        92   Sun Jun  8 05:07:00
LA6I       1         4   Sun Jun  8 05:03:26
LD5BE      1        54   Sun Jun  8 05:02:10
LA1VNA     1        12   Sun Jun  8 05:00:22
LA5NRK     1         6   Sun Jun  8 04:58:43
LA4FPA-9   1        16   Sun Jun  8 04:57:45
LA3SP      1         3   Sun Jun  8 04:55:45
OZ1NPL-2   1         3   Sun Jun  8 04:54:18
LD3HS      1         6   Sun Jun  8 04:51:36
LD4ST      1        55   Sun Jun  8 04:49:27
LA4FPA     1        12   Sun Jun  8 04:46:28
LD4SJ      1        13   Sun Jun  8 04:41:22
LD6FD      1         3   Sun Jun  8 04:40:42
LD4NB      1         7   Sun Jun  8 04:35:10
LD5VO      1         5   Sun Jun  8 04:34:46
OZ8DIG-2   1         3   Sun Jun  8 04:32:49
LA7RTA-1   1        24   Sun Jun  8 04:30:47
LD5AG      1         4   Sun Jun  8 04:30:00
LA3QMA     1         7   Sun Jun  8 04:29:34
LD6SA      1         1   Sun Jun  8 04:27:34
LD4EI      1        18   Sun Jun  8 04:26:58
OY1OF-9    1         7   Sun Jun  8 04:26:02
LD5KH      1         9   Sun Jun  8 04:25:56
OZ4DIZ-2   1         2   Sun Jun  8 04:24:42
OZ2DXE-2   1         5   Sun Jun  8 04:17:05
LD4EG      1         5   Sun Jun  8 04:16:26
OZ6PAC-2   1         6   Sun Jun  8 04:15:31
LD5MT      1         6   Sun Jun  8 04:12:47
OZ5DIL-2   1         1   Sun Jun  8 04:11:53
LD4HS      1         5   Sun Jun  8 04:09:17
LA4DSA-7   1        26   Sun Jun  8 04:07:52
LA1J       1         7   Sun Jun  8 04:00:07
LD4SR      1        10   Sun Jun  8 03:49:24
LD6FL      1         6   Sun Jun  8 03:30:00
LD6SH      1         1   Sun Jun  8 03:23:34
M0XER-5    1        63   Sun Jun  8 03:18:10
LA3QR      1         1   Sun Jun  8 03:18:04
LA3SP-1    1         4   Sun Jun  8 03:11:59
LD5SK      1         4   Sun Jun  8 03:08:16
LD4FF      1         9   Sun Jun  8 03:01:50
OZ5DIM-2   1         1   Sun Jun  8 01:59:07
OZ2BMN-10  1         2   Sun Jun  8 01:54:16
LA4YPA-7   1         1   Sun Jun  8 01:08:03
GM7AFE-9   1        17   Sat Jun  7 18:23:46


Looks like there was a lift on in the early hours of this morning!


To automate the process of bringing up the AX25 system I wrote a small script (ax_start.sh) which is run from /etc/rc.local at boot,.

ax_start.sh:

#!/bin/bash
kissattach /dev/ttyAMA0 1 10.0.0.1
kissparms -p 1 -f n -l 50 -r 32 -s 320 -t 400
ifconfig ax0 10.0.0.1 netmask 255.255.255.0
ifconfig ax0 hw ax25 MB7UZE up
mheardd -f
screen -dmS dixprs /usr/local/dixprs/dixprs.py -c /usr/local/dixprs/config.txt



The last line starts the DIXPRS APRS server in a "screen" session so that I can monitor it by logging into the R-Pi using SSH and attaching to the screen session, and then can detach and log out, leaving DIXPRS running. 

Installation of DIXPRS is a little tricky, requiring various pre-requisites to be installed/configured first, and then requiring the DIXPRS files to be exracted from their tarball. 

The full instructions at the DIXPRS site were followed and no problems were encountered, so that's the best place to start:


Install to /usr/local/dixprs and then edit the included config example config-ax25.txt, saving it as config.txt:

#

[GENERAL]

# Mandatory parameters

# Your callsign with SSID
CALLSIGN=MB7UZE

# Degrees; West is negative, East is positive
LONGITUDE=-1.4251

# Degrees; South is negative, North is posittive
LATITUDE=60.2885

# Optional parameters

# Station height abvove the see level in meters; no default
ASL=30

# Owner name and contact; no default
OWNER=John, GM4SLV

# Spool directory to import packets; no default
SPOOL=/home/gm4slv/spool

# Station symbol; default is S#
#SYMBOL=<xy>

# UDP port base number; default is 31110
#UDPBASE=<n>

# Beacon frequency in minutes; default is 30
BCNTIME=10

# Beacon text; %v replaced with actual version string; default is %v
# Used as default for ISGW and RADIO
BCNTXT=I-Gate Clousta, Shetland 144.8MHz

# Select km/mi on monitor and in DX list; default is y (km)
#METRIC=<y/n>

# Max number of digis passed for local stations
# Used as message gating condition for gating to Rf
# Default value is 2
#LOCALHOPS=<n>

# Range in km within messages gated to Rf
# If defined, checked after hop count (local) check
# No default
#MSGRANGE=<fv>

#################################################################
#                                                               #
# IS gateway settings; remove this section to disable GW        #
#                                                               #
#################################################################

[ISGW]

# Mandatory parameters

# Domain name of IS server to connect
host=euro.aprs2.net

# Optional parameters

# Port number; default is 14580
#PORT=<n>

# Filter; default is r/@/150
# @ is replaced with station position
FILTER=m/100

#################################################################
#                                                               #
# WRB server settings; remove this section to disable it        #
#                                                               #
#################################################################

[WEBSERVER]

# Mandatory parameters

# WEB server port, no default
port=9999

#################################################################                                                               #
#                                                               #
# Radio port configuration settings; repeat section for         #
# multiple ports                                                #
#                                                               #
#################################################################

[RADIO]

# Mandatory parameters

# Interface type
INTERFACE=AX25

# Device; as listed by ifconfig; it is nbot the ax.25 port name!
DEVICE=ax0

# Optional parameters

# Modem speed, default is 1200
#SIGNALRATE=1200

# Enable/disable NWS WX bulletin and object gating from IS to Rf
# Disabled by default
#GATENWS=<y/n>

# Enable/disable BOM WX bulletin and object gating from IS to Rf
# Disabled by default
#GATEBOM=<y/n>

# Descripton of port; no default
DESCRIPTION=144.800MHz APRS

# Via used to send locally generated packets; default is WIDE1-1,WIDE2-2
AXVIA=WIDE1-1

# Digipeaters processed with WIDEn-n algorithm; default is WIDE1,WIDE2
#WIDEN=<lst>

# Blacklisted stations; they are not digipeated, not gated; default is NOCALL,N0CALL
#BLACKLIST=<lst>

# PHG string, do not mix with range; no default
#PHG=<str>

# Range value in miles, do not mix with PHG; no default
#RNG=<n>

# Enable/disable transmission; change it to PTTON=1 to enable trasmission; default is no
PTTON=1

# Gate locally generated frames to IS gateway; default is no
# Useful for rx-only radio ports
# Experimental, use carefully
#GATELOCAL=<y/n>

# Gate digipeated frames to IS gateway; default is no
# Experimental, use carefully
#GATEDIGI=<y/n>

# Beacon text; %v replaced with actual version string; default is %v
#BCNTXT=<str>

# Enable/disable digipeater; default is enabled
#DIGIPEATER=<y/n>

# Modem/TNC setup parameters 0...255; no defaults
# Use to setup modem/TNC by DIXPRS

#TXD=<n>

#PPERSIST=<n>

#SLOTTIME=<n>

#TXTAIL=<n>

#DUPLEX=<n>

# Below these are the traffic shaping settings for gating messages
# From IS to Rf
#
# For advanced users only; do not change if you do not know how
# traffic shaping works and if you do not have good reason !!!
 
# Traffic shaping high treshold, default is 0.75
#TRAFFICHIGH=<fv>

# Traffic shaping low treshold, default is 0.5
#TRAFFIClow=<fv>

# Traffic shaping transmission delay, default is 5.0 sec
#TRAFFICDELAY=<fv>

# Comma separated list of addresses to send receveid/transmitted frames
# in hostip:port format. No default.
UDPCC=udplog1.dixprs.net:8889,udplog2.dixprs.net:8889




You can start DIXPRS while you're in the /usr/local/dixprs directory as:

./dixprs.py -c config.txt

Once it seems to be running correctly it's better to start it from within a Screen session, as shown in my startup script above.

The Screen session running DIXPRS looks like: