Sunday, 24 July 2016

Icom M710 Python control

Prompted by Christopher,  KD8QDZ, I've had a quick look at how fast I can cause the M710 to change frequency via the Python code I'd previously written.

I wrote a small test code which uses the existing python module "radio_functions_m710" to read the current RX Frequency and then to send a command to change BOTH the RX and TX frequencies (the M710 can operate in Duplex mode with separate RX and TX frequencies, so for amateur use we need to keep both RX and TX frequencies in step explicitly). The script runs a loop adding 1kHz, and then after 10 times around it starts subtracting 1kHz....

import radio_functions_m710 as radio
import time

count = 0
delta = 1
while True:
    rx_freq = radio.get_rxfreq()
    print "RX Freq : ", rx_freq
    new_rxfreq = float(rx_freq) + delta   
    count +=1

    if count%10 == 0:
        delta = delta*(-1) 

There is a certain delay for each instruction, and I don't know how responsive it would need to be to use this method to mimic a hardware VFO knob....

A video of the QSYing cycle. You can see the DUP/SIMP indicator alternating as the RX and the TX frequency are updated separately. SIMP showing that the TX frequency has been changed to agree with the RX frequency.

The example above reads the current RX frequency each time around the loop. I thought that perhaps it would be snappier if it just sent the "set freq" commands and didn't read back from the radio ech time...


import radio_functions_m710 as radio

rx_freq = radio.get_rxfreq()
count = 0
delta = 1
while True:
    print "RX Freq : ", rx_freq
    rx_freq = float(rx_freq) + delta   
    count +=1
    if count%10 == 0:
        delta = delta*(-1) 

 This appears a bit quicker, only reading the initial frequency and then sending commands to step in 1kHz:


Tuesday, 28 June 2016

Paper Chasing - "Ragchew DXCC" anyone?

I've never been a "Paper Chaser / Stamp Collector" type of person - especially regarding amateur radio. I see the hobby as something to do for its own sake, to learn something new, to tinker and investigate, rather than as a vehicle for a collecting stuff. For instance I've "given away" my WAB square (relatively rare HU35, since I'm up here in Shetland) on the WAB net on 40m to the avid collectors, but could  never imagine wanting to collect WAB squares, or SOTA summits or FloraFauna etc. etc..  I see why activators might get hooked by WAB / SOTA / IOTA / FloraFauna - the technical and physical challenges of taking radio out to interesting and unusual places - but can't quite grasp what the collectors get from it, simply ticking boxes in a book.

I understand, and enjoy, Birdwatching but fail to see the point of Twitching...

I've sent and received QSL cards over the years, but have never paid much attention to what countries I have "confirmed" or which of them I have just "worked" and I have no idea of what DXCC entities I've worked over the years. Probably not that many.

I've just started keeping a computer log, to coincide with starting a new spell of HF CW activity. This is mainly to help me remember if/when/where I've worked someone before, when I meet them again - not to assist my collection of rare DX.  I don't have the logging software (logger32) connected to the Cluster etc. I only ever look at the DX Cluster if I come across a pile-up and can't work out what they are all screaming about -  and only so I can tut quietly to myself and tune away, knowing which chunk of the band to avoid for the next few hours.

I don't like "rubber stamp" QSOs and much of what "DXing" seems to involve. "Paper Chasing" seems to revolve around confirming QSOs that have carried little, or no, actual information between the operators beyond their callsigns. Even the signal reports are bogus.

I've been wondering about trying to get DXCC myself (CW only) just to give me an incentive to keep track of the places I've worked - but with my own personal criteria for what QSOs will count towards the total.

I'm thinking about working towards DXCC  only using QSOs that fit the following conditions
  • Must have been of at least 5 minutes duration
  • Must have included the exchange of Name and QTH
  • Must have included the exchange of at  least two of the following
  1. Working Conditions (Rig / Power / Antenna)
  2. Weather conditions 
  3. Age & date licensed
  4. Any other information
  • Confirmation by paper QSL (I'm intending to use LOTW, but paper QSLs & LOTW records can't be mixed for the award of DXCC by ARRL, so for this "ragchew DXCC" it seems fitting to stick to proper paper QSLs)
  • Must have been for a QSO between June 2016 and June 2017 on any HF band
I wonder if anyone else has tried a similar thing - claiming an award by selecting only "real QSOs".

I wonder if it's even possible nowadays, given the rise of the DX Cluster and pile-ups and Reverse Beacon Network. Is it possible to find people in 100 different countries who are willing to chat rather than give out simple "599 TU". Getting 30 or 40 countries should be reasonably easy - in Europe most of the countries are not "DX" and should have a reasonable number of active stations who are happy to have a real QSO, even a "rubber stamp" one that goes beyond the basic "599 TU". There must also be stations in far away countries who still like to have a QSO - even using the universal language of CW where in depth knowledge of English isn't really needed:

 "ge om = rst 599 599 599 = op john john es qth shetland shetland = rig ic7200 es pwr 100w  = ant vertical = wx 16c 16c es sun = hw? bk"

I had a short CW QSO with JA1NUT this weekend on 20m. I just happened to be sitting with the radio on the frequency that he chose. Heard his "QRL?" and then his "CQ" call. I answered, and was amazed to get through. Weak signals, but we were still able to have a "real QSO" - although short due to condx - and Shin even asked me if I was operating from the location on my page. I replied that yes, I was. He commented that I should be able to put up some rhombics given the amount of open space. That wasn't a rubber stamp QSO, even if condx were not ideal, with weak, fluttery polar signals, but we still managed more than "599 TU".

I think (outside of contests) this was might have been my first Japanese station, it's certainly the first where I've had a "real QSO".

Grabbing the "DX" station before he gets spotted on the Cluster seems to be the only chance you get to have any sort of QSO nowadays.

I've had a few CW chats with Alan TF/W4MQC who's on holiday in Iceland this summer. He isn't interested in DXpedition-style rubber stamp QSOs, even though he's in a reasonably unusual DX location - and it's been good to bump into him a few mornings and find out what he's been getting up to. My CW has been neglected in recent years - and it's QSOs like these with Alan that make me want to improve - so I can have longer, quicker, more meaningful conversations with people using Morse Code, and not so I can send "599 TU" at 40wpm for a new DXCC entity in the log.

Let's see how it goes. I'll try to keep a list of Countries Worked / Confirmed that fit my criteria on this blog somewhere....

A return to HF CW

I've always considered myself to be a "CW Operator" (although not particulary active, fast or proficient) .  When I was discovering the world of Amateur Radio as a schoolboy in the 1980s my only real interest was HF, and I spent a few years as a Shortwave Listener on the HF bands. I knew that Morse Code would be necessary to get an "A Class" licence, and I had no problem knuckling down and learning CW. I passed my GPO test when I was 16 years old and have always seen HF CW as a major part of the radio hobby.

Over the years I've also played with digimodes and the occasional SSB QSO, but it's always been CW that draws me back to the radio.

Recently I've been involved with lots of other projects, many of which have made it to this blog, but now my attention once more is on Morse Code and the shortwave bands.

I've blown the dust off my old Hi-Mound HK708 key - the one I used back in the '80s to learn to send, and to have my first CW QSOs  - and also my Bencher paddles and a TiCK4 electronic keyer I built a few years ago and also an old brass GPO key.

Already I've had some nice QSOs on 60m, 40m, 30m and 20m. My reading speed is hovering around 25wpm and I'm practising to get it better. My straight key sending is comfortable at around 18wpm, although with some effort I can get to 20wpm.

I've built a "hacksaw-blade" sideswiper (Cootie-key) and while it's fun to use, and a little easier to maintain 20wpm+, it takes some practice to produce nice, readable morse.

My squeeze keying on the paddles is letting me down at the moment - I like to exchange more than a simple "599 QSL ok" and would like to be comfortable rag-chewing at 20-25wpm, and I think for the higher speeds it's going to be necessary to master the dark arts of the iambic keyer. I can use it, ok, but mistakes seem to occur for no obvious reason, and it's very easy to get completely confounded. On several occasions I've had to jump from the paddles back to the safety of a straight key. I can send practice text off-air with no problem but something seems to happen when I start sending for real. More practice on air is the only answer, of course.

I hope to see you on the HF bands.

Saturday, 26 March 2016

XGate Update - Raspberry Pi GPIO

I've been updating the UHF/HF "X-Gate" to correct a limitation in the system - the ability to control the channel being used on the HF radio via the UHF port.

In the basic X-Gate the HF radio is set on one fixed frequency where it remains. If conditions change, or interference appears, it isn't possible to move the frequency of the HF radio remotely, via the X-Gate system's UHF port.

Some background on the X-Gate so far...


Monday, 7 March 2016

Icom IC-M710 remote control

I've been dabbling in Python over the last year or so, writing small projects that
  1. Help me learn to write software 
  2. Provide something I can't find anywhere else
  3. it's fun (if sometimes frustrating)
I still don't know much about writing software but I've thrown together a few useful little bits of code (useful to me, at least).

My little projects have included:

  • Serial port remote control for Icom "CiV" radios
  • Serial port remote control for AOR AR7030 RX
  • TCP/IP client/server remote control for Icom & AR7030 allowing control of multiple radios from one GUI over a network.
  • MF/HF DSC message signal generator
  • CCIR 493 Selcal tone generator
  • Serial port remote control (NMEA) for Icom IC-M710 marine radio
  • XML-RPC interface for fldigi for displaying received text on a website
  • XML-RPC interface to allow fldigi to control the IC-M710
  • UDP network interfaces, message parsing and input to a MySQL database for DSC messages received over the internet, to drive my DSC website "YaDDNet".
  • A DSC "Test Message Auto-responder" with remote TCP admin client
My recent small project is to give TCP/IP remote control of the IC-M710 marine SSB transceiver, with a small "server" program running on the PC to which the IC-M710 is connected via a serial port and a "console" client that can run anywhere with network access giving the ability to remotely change: Operating Frequency, Operating Mode, Turn display backlight on/off, Turn speaker on/off, send a 3 second low power "tune" carrier for Auto ATU tuning.

The current code, in Python 2.x is here:

 IC-M710 Client / Server

(dropbox link updated 24 July 2016)

Initial work - local control by PC

The M710 is unusual in that it doesn't use Icom's normal "CiV" protocol but instead uses the marine standard NMEA protocol, using "proprietry" sentences. Once I'd got to grips with the basic format of the communication I wrote a set of Python functions to get access to the user-controllable features of the radio : Mode, RX Freq, TX Freq, TX Power, AF Gain, RF Gain, PTT, Noise Blanker, Squelch, AGC, Speaker Mute, Display dimmer. I wrote a GUI, using TKinter, to give a mimic front panel (loosely based on a Skanti TRP control head), and also a user-programmable set of "memories", in a separate floating panel.

This allows direct control of the M710. The M710, along with most other "professional" HF radios is not very user friendly as it's intended for fixed-frequency memory channels and not for rapid "tuning around" that hobby-radio users prefer. Control via PC allows for quick frequency selection, mode changing etc.

Network Server/Client

The first program requires the user to be sitting "in the shack" along with the PC and the radio. I wanted a simple client/server arrangement - no graphical interface, just the ability to change the radio frequency and mode from anywhere. The M710 is connected to my X-Gate interface which gives me the ability to use the HF radio using a UHF handheld, so I can operate on HF without needing to sit in the shed. The problem is that the X-Gate has no method to change the HF radio's frequency, requiring a trip to the shack to change the HF radio. This client/server solution means I can change the HF radio freq. & mode while sitting in the house, using my laptop, and continue to use the X-Gate for listening/operating - without frequent trips back to the shed.

I took the server & client code already written for remote (TCP/IP) control of  "normal" Icom radios and the M710 control functions already written for the "local" control and stripped out the un-needed parts to make a simple server/client giving "console" control. No doubt I could write a point & click GUI for the client, and that might be the next step.

Sunday, 18 October 2015

Icom IC-7200 USB UART/Hub

For digimodes I use an Icom IC-7200 which has a USB interface providing CiV CAT control and also RX/TX audio, via the radio's internal sound-card device. Previously this interface stopped working following a thunderstorm nearby and the radio was returned to Icom for repair, under guarantee. The symptoms were

Monday, 23 March 2015

CCIR 493-4 HF Selective Calling

During some recent tests of a portable setup using the FT817 / MX-P50M linear / Z817H ATU and a kite antenna, as well as some other tests on 20m SSB from the Landrover while mobile, with Peter G4VLC at the far end, it was mentioned that some form of "alert" or "Selcall" would be useful so that it wasn't necessary to sit monitoring while waiting for activity.  We tried simple DTMF, but it's prone to noise, false triggering and the effects of minor frequency errors. A properly designed Selcall system for the HF bands would be better.

I found some information at the HFLink website describing what is currently known about a rather old protocol - CCIR 493-4 which was the basis of the later ITU R M.493-xx GMDSS DSC, about which I've learned a great deal over the last few years.

There's scant information about the older CCIR protocol, although it forms the basis for the majority of Selcall systems in use by "land mobile" HF users with radios from manufacturers such as Barrett, Codan etc. These manufacturers have enhanced the basic Selcall with their own in-house functions, some of which are compatible with other radios, some only work with radios of the same make. No technical details seem to have been published of these enhancements.

In its basic form CCIR493-4 is similar to MF/HF DSC - it shares the same modulation scheme (170Hz shift, 100baud FSK) the same FEC interleaving (each symbol is repeated after four other symbols), the same dotting pattern for bit sync, the same basic phasing pattern for word-sync, and a very reduced subset of "format", "category" and "EOS" symbols. I modified my Python script which I recently wrote to generate HF DSC transmissions - removing un-needed functions etc.- so that I could experiment with CCIR493-4 over the air. Unfortunately, without access to a real Selcall-equipped radio, the only way of testing was to find a software decoder that could understand the protocol. YaDD would show the symbols, but of course the overall message format is not understood by YaDD. MultiPSK has a "493-4" function as part of the "GMDSS" decoder, but only very basic messages are understood. The only other software decoder seems to be "Sorcerer" which has a wide range of modes, including various flavours of HF Selcall. I discovered quickly that Selcall has an inverted tone sense, compared to DSC, so the mark & space frequencies have been switched in the generator.

A recording of a Selcall made using the Python generator is here:

The current GUI looks like:

There is also a CW ID function, which sends "FSK CW" of arbitrary text (generally "de GM4SLV") for identification on the amateur bands. It sound like this:

The current version of the Python program is here:

it runs on Windows, and Linux, although I struggle with the arcane details of the Linux sound-system so I tend to use it mainly from a little Windows XP netbook. There is an initial delay before the Selcall message is transmitted, due to the calculation of every sample-value in advance. The FSK modulator uses "Continuous Phase Frequency Shift Keying" to avoid sudden phase jumps at the boundaries between bits, and at the moment the final waveform is calculated in full before being fed via the "Default Soundcard". I use a Signalink USB interface with no need for any software PTT control etc, although I have also written a version that has direct control of an Icom IC7200 using CiV commands, but that's on the back burner at the moment.

I've successfully transmitted Selcall on 60m and 30m, being received by G4VLC, also using Sorcerer to decode:

[2015-03-22 13:23:16] [ BARRETT 22/03/2015 13:23]
[2015-03-22 13:23:16] Format: Beacon Request
[2015-03-22 13:23:16] Destination Address: 1234
[2015-03-22 13:23:16] Callers Address: 5678
[2015-03-22 13:23:16] Category: Voice
[2015-03-22 13:23:16] 123 12 34 100 56 78 117

[2015-03-22 14:13:10] [ BARRETT 22/03/2015 14:13]
[2015-03-22 14:13:10] Format: Beacon Request
[2015-03-22 14:13:10] Destination Address: 5699
[2015-03-22 14:13:10] Callers Address: 5678
[2015-03-22 14:13:10] Category: Voice
[2015-03-22 14:13:10] 123 56 99 100 56 78 117

[2015-03-22 14:13:34] [ BARRETT 22/03/2015 14:13]
[2015-03-22 14:13:34] Format: Selcall
[2015-03-22 14:13:34] Destination Address: 5699
[2015-03-22 14:13:34] Callers Address: 5678
[2015-03-22 14:13:34] Category: Voice
[2015-03-22 14:13:34] 120 56 99 100 56 78 117

Now I'm hoping to find some other amateur radio Selcall users, to get more experience, and find out more about the details of the protocol. Hopefully one day we'll have a software implementation of two-way Selcall, otherwise the only way to use it is to buy a purpose-built radio - but Codan and Barrett radios don't come cheap.