Amateur Radio Voice Switch

The switch configuration is currently as follows:

Some years ago radio amateurs began to experiment with linking amateur radio to the internet. Echolink and IRLP are two good examples of this experiment. Both these systems are great fun, allowing radio amateurs often using low power handheld radios to literally chat across the world for free, but... somehow... though I enjoy using both it just doesn't seem right.

I began some years ago to think of just what I thought wasn't right and what I could do to put it right, the result of this was my amateur voice switch.
I think my basic objection to internet linking is that unlike any other form of amateur radio traffic it involves a 3rd party carrier that is not owned by radio amateurs.
To give the same sort of service, though agreed initially on a local basis I came up with the basic design for the voice switch.
The idea is that a switch rack frame will provide 4 audio buses + a 'conference bus' + a serial comms bus.

This rack will be populated by up to 8 'radio interface cards' to each of these a radio is attatched. A user on one of the serviced channels can by dialing DTMF stings have his audio patched to any of the other ports, or if desired the conference bridge.
Typically many of the ports may be radios on local repeaters, some may be simplex radios, some of the simplex radios may 'talk' to simplex radios on other voice switches, thus a large network of voice switches can be built, scalable in both served channels and area.
This looks great, and pretty simple, but as so often is the case looks are deceiving!
Anyhow I managed to get a special Notice Of Variation to my license to test this idea and got it to the point where, on the bench I could patch between 3 ports on a frame.
About then licensing of 70cms repeaters got very difficult and I'm not very interested in running this switch only when 'attended by the licensee'.
The conditions I was required to meet to satisfy Ofcom required some messy modifications to my MK1 repeater controller for repeaters in use on the switch, so I've spent the last few months developing a new repeater controller which is now nearing completion, once that is done I'm back on the voice switch, watch this space.

Over the past few weeks I've been putting a fair bit of work into adding voice prompts to the switch. Whilst morse prompts are OK they are a bit clunky and many users can't or don't read the morse. In any case when morse is heard on a repeater the natural assumption is that the repeater is sending it and it is safe to talk over it. Voice prompts are much more informative and less likely to be ignored.

The voice prompts currently on the switch come from a separate 'prompts card' which sits on the backplane just like the radio cards. The prompt card looks at traffic between the cards on the RS485 data bus, and when it sees a call being set up or cleared it jumps in to announce what is going on. So far I have implemented prompts only for successful connection and disconnection of calls. The 2 error states - 'called port busy' and 'called port does' not exist are still reported by morse prompts. Whilst reporting of problems by speech prompt would probably have been the most useful feature to add it is also the most difficult - call setups and clear downs are already on an audio bus - so making an announcement is easy, error calls at present never go to an audio bus, so I have nothing to make the announcement on. In due course I will modify the switch software to set up a dummy call for errors so that the prompt card can announce what went wrong then clear the call down. However for the time being errors are sent in morse - so if you hear some morse, something went wrong!

For those interested in the technology the prompts are recorded using 'Windows sound recorder' set for 8 bit sampling at 8khz sample rate (64Kbit/sec). Each prompt (16 are provided) is saved as a separate file. The individual prompt files are written to a 512k x 8 FlashRAM by a programming utility in the prompt card, with Windows Hyperterminal being used to send the files. Once the files are written to Flash the PC is no longer required, the prompts are held permanently in none volatile Flash memory. Playback is then simply a case of counting through the appropriate addresses in FlashRAM with a simple R2R ladder D to A converter on the data lines. In this way I can store 16 x 4 second prompts of telecoms quality speech and play them back using an 8 bit microcontroller.

Work will continue mainly on adding prompts for error conditions over the next few weeks.

The NOV allowing unattended operation of the voice switch on a 24/7 basis arrived from Ofcom on 30th Septemper, just a couple of days after I emailed my list of closedown operators, another big pat on the back goes to Rod Wilkinson at Ofcom for his exceptional efficiency in getting the NOV back so fast.

Now the Mk2 repeater controller is pretty much complete I intend to put some work into the Voice Switch again. Pretty soon I will be having a new batch of PCBs made, these will be the 3rd and hopefully last hardware revision. The new PCBs will add support of an I2C eeprom to hold programmable parameters, allowing a wider choice of microprocessor, particularly a couple with much more code space allowing me to add extra features. The new PCBs will also have provision for 2 levels of morse allowing my ID to be sent a low level in background during users overs, hopefully making it less intrusive. Once these changes are in place I intend to move the switch from my bench up into the loft. This will allow me to add extra ports that at the moment I can't do owing to an acute shortage of space for coax in the trunking from my shack into the loft. I already have verbal agreement from the keepers of GB3LS and GB3DS to add their repeaters to the list of those served. The new list will be GB3DY, GB3EE, GB3RB, GB3DS and GB3LS, expanding the total coverage of the switch as a whole to something resembling an 'East Midlands Repeater Network'

The Notice Of Variation permitting me to connect GB3RB via the switch arrived in the post on Saturday (18/3/06) I should take a moment to commend Ofcom and the RMC for the speedy work in getting this NOV through. Considering that my original enquiry regarding GB3RB to Rod Wilkinson at Ofcom was on 4/3/06 this is pretty speedy. My original enquiry was passed to Andrew Barrett (G8DOR) of the RMC. Andrew agreed the changes in under 10 days, resulting in Rod asking me to fill in a formal request form 'online' late on 14/3/06, the printed NOV arrived in the post, just 4 days later on 18/4/06. A big pat on the back to Rod, Andrew, Ofcom and the RMC. What a change from the situation I met at both organisations when I first started on this project in late 2002!

Still in shock at the speedy response I have made some interim changes to the switch, so please check the "current port configuration" at the top of the page.

I intend to replace the 51.950 port with 430.025 later in the week. My logs show that nobody has ever used the 6 meter port; on the other hand the 430.025 port is frequently used by me for testing around the shack. Since GB3RB gives superior coverage of Bolsover I intend to downgrade the 430.025 port from 5 Watt ERP from an antenna at about 6 metres. AGL down to 500mW at 2mtrs AGL. This will still allow me to get into the 430.025 port from around my shack, whilst giving enhanced coverage around Bolsover using GB3RB.

It present I'm limited to running only 4 ports, that's the number of PCBs I have available. I have a new revision of PCB laid out ready to order, but I also have a couple of technical questions still with Ofcom. The answers I get from Ofcom will affect the design of the hardware. Although I have a very advantageous arrangement for PCB manufacturing it would be silly to order more boards until I'm pretty sure that they will be 'right' so for the time being we look like sticking with 4 ports. This does not mean that work will stop completely.

I intend (as soon as I can get parts in from Farnell) to change from using the 89S8252 processor to the newer 89C51ED2. This new chip (amongst other things) has 8 times as much code space as the present one, allowing me to add several new features. The first addition I have in mind is a 'group call' allowing a group of several specific units to be set up on a conference call, similar to the current 'conference' facility but not requiring each participant to dial in. It would also I think be useful to add an 'include call' allowing a third (and fourth etc.) participant to be brought in to an existing 1 to 1 call. These 2 features, so easily described in a few lines will actually require some major bits of code to be re-written, largely thanks to my lack of planning when writing the original code!

Usage Documentation for the voice switch, which is now being tested on GB3DY, GB3EE, 430.025Mhz & 51.950Mhz is now available. Please select a format below.

Things progressed pretty well this weekend.
I've now added the morse routines, so users get a C when connecting a D when disconnecting and an ERR if they do something silly. The programming routines are also in, so I can now give the switch a callsign, which it merrily churns out in morse to comply with my NOV.

In fact things when so well that late this afternoon I thought "I could put this on air now".
I dusted off a couple of old UHF mobiles that I put aside for the job some time ago, lashed up power leads (I put them aside so long ago that the proper power leads have long since been used elsewhere!) and bingo, I can patch 430.025 to GB3EE. So I called and called, but nobody answered - apart from somebody who could only find his toneburst - thanks mate that was a great help. Eventually I resorted to my 'phone a friend' lifeline, and within minutes Steve M1ERS became my first QSO through the amateur voice switch. Audio was very easy to read but a bit low and a bit compressed.

The main thing is it works! I've since made some adjustments to the audio levels and it seems to sound a lot better, more testing over the next few days I think. I hope to bring GB3DY in to the tests maybe next weekend after I've tidied things up a bit, with the possibility of linking 2 relatively busy repeaters things should get really interesting! As a final test I had a quick surf round the IRLP nodes (GB3EE is IRLP connected courtesy of Steve) it all seems to work and sound just fine, DTMF passes through the switch OK to open and close IRLP nodes, the switch is able to ignore this but act on commands directed at it very nicely. At last work on the switch is begging to show some rewards.

In case anyone is thinking I've given up on this one here is a quick update. Over the last couple of weeks I've been attempting to test the stability of my software. Since my intention is to eventually try for an NOV to operate the switch unattended from remote sites I have to be sure that it will be stable for many months of operation without any intervention. Ensuring this is something of a task in it's self.

I've been running some tests by setting up my Schlumberger 4922 Radio Code Analyser to repeatedly setup and clear a call. Early tests crashed the switch within 1-2 minutes. I've made several changes and now have stable operation for at least 8 hours with 4 calls per minute, over 1900 calls in total. However I'm not really happy with this test, or the result, really, eventually I will need to test a fully populated (8 channel) switch by having 4 of the units simultaneously randomly dialling any valid destination and clearing down any resulting call. This should simulate real world conditions much better, since some calls will be to busy units or absent units, any many calls will be passing at once. To do this I will need to build 4 random call generators, a sizable project in it's own right, but essential before long I think. However for the time being I will press on as I am, since I'm still able to break it just by repeating the same call on an otherwise quiet system. Over the past 2 weeks the switch has started to show some real signs of eventually working properly, however there is still a great deal to do.

Over the past week work on the voice switch has progressed reasonably well. I am now able to connect and disconnect calls between any 2 of the 3 prototype cards in my development system. The main problem has proved to be making the connect and disconnect commands work with the busmaster card. RIC number 1 on the switch assumes to roll of 'control' all requests to connect and disconnect calls are sent to the busmaster which keeps track of which switch resources are busy and which are available and issues instructions to the other RICs to 'go to channel' or 'terminate call'.
This makes the busmaster an 'exception' it issues all commands, but it also has to act on commands that involve it, allowing it to pass voice traffic just like any other RIC in the switch. The problem could have been easily solved by designating RIC number 1 as 'control only' not allowing it to handle voice traffic. This approach would have been easy but to misquote JFK "I choose to build an amateur voice switch not because it is easy, but because it is hard." In any case having a 'different' card in the switch with 'different' software if I could make it work with one standard card would be messy and wasteful.

Keeping all the RICs the same makes fault finding and spares holding easier, through maintaining a 'homogenous environment'. The problem of the busmaster exception was eventually solved by designating RIC number 2 as the 'busmasters helper'. This approach allows all RIC hardware and software to be the same, whilst still allowing all RICs to be fully functional voice channels. Since the minimum reasonable implementation of a switch is 3 or at a push 2 channels, I'm not making any extra hardware demands by requiring that RIC's 1 and 2 are always present. JFK chose to "go to the moon by the end of the decade." I'm hoping to have the voice switch ready somewhat before then, hopefully.
Development work continues...

After a long while on the shelf this project is now definitely 'work in progress'. Over the last couple of weeks as my Mk2 repeater controller has neared completion I've built up 2 of the 3 voice switch 'Radio Interface Cards' that I had PCBs made for over a year ago. The new cards are much neater than the first effort, which in reality was little more than a 'proof of concept' prototype. As you can see from the picture I've settled on 160mm 'eurocards'. Though I generally mistrust anything with 'euro' in it this approach leads to a neat, modular and standard architecture. A fully populated switch will consist of a simple backplane with up to 8 of these cards plugged in, each RIC will serve 1 radio (or network?) channel. I layed out these cards some time ago, the first change on the next revision will be to make virtually all passive components surface mounted, experience with the Mk2 repeater board has shown this to be 'the way forward'

Since the Rev B RIC is radically different from my original prototype I chose to start again with the software. This is the first multiprocessor system I have build and the software is proving to be a challenge, however over the past couple of weeks I have made some encouraging steps forward. One of the first tasks to achieve was the put in place routines for the RS-485 bus. This is the serial bus that my RIC's use to talk to each other. RS-485 is similar to a radio channel in that many may listen but only 1 may talk. The first challenge then was to provide a protocol which prevents collisions on the RS-485 bus. This seemingly easy task took over a week, however I now have a suitable system, the lowest number RIC assumes the role of master and regularly issues a sync signal, the other RIC's use this signal to timeslot any messages to be sent on the bus to avoid collision. This task which takes 1 sentence to describe took over 1 week to get working! Next I put in place the relatively simple task of reading DTMF from the radio, parsing it and passing requests out on the RS-485 bus in response. This was relatively easy, taking only a couple of nights. I'm now putting in place the audio switching, to allowing the RIC to select an audio and control bus channel, this work is going on in parallel with reading requests from RS-485 and acting on such requests. Tonight this has culminated in my being able to successfully set up a connection between 2 RIC's and pass audio between the 2. This is a major milestone, however there is still a great deal to do. I need to add code to allow the master RIC to keep track of which bus pairs are in use, who is using them and which are clear for traffic. I also need to add code to disconnect calls. Once all that is in place I need to add morse prompts and timeouts. Then there are conference calls to add. Finally I need to put in some error trapping, to handle things like requests to connect while already connected and other such 'sillies' that will inevitably happen. A long way to go but at last I feel like I'm getting somewhere!