I have written in the past about my dissatisfaction with the current state of amateur rig control and remote base systems, and some of the things that might improve the situation. Since then, I have started playing with the RCForb software from remotehams.com. This software is quite good, though only available for Windows at this time. However, it is possible to have web based control and at least receive access via a Flash control, so some level of cross platform operation is possible via a web browser. However, having to turn the system off every time I want to run data modes or otherwise remotely use the radio outside of RCForb is still rather annoying. This got me thinking about a new architecture in more detail. I've come up with the following so far:
The new architecture should be both modular and network aware at all levels, with the hardware details only needing to be taken care of at one point, not in every piece of software. First, I'll cover some of the modules I've identified:
Radio Drivers - The drivers take care of the details of handling the specifics of communicating with a particular model of radio The driver is the piece of software that knows how to communicate with a specific model (e.g. FT-847), or family (e.g. Icom CI-V) of radios. The driver handles the low level communication, and presents a list of radio capabilities to the next layer of software.
Radio Server - The radio server handles the higher level functions. Firstly, the radio server maintains a list of what radios are physically connected to it, and what resources (e.g. COM port and sound I/O) they use. It also manages application access to the radios, so that applications can share nicely. The server should have an API that apps can use to request exclusive selective control of the radio, so one package could control the VFO, while another has exclusive audio and PTT control. Control software should access the radios via the server API. The control software could be run on the same machine as the server, which would be the typical case for most amateurs, or across a LAN, so the radio could be operated from another location in the house. Audio sent using the API should be uncompressed for minimum latency and maximum compatibility with data modes. The radio server API should be fully documented and have some basic security (though with the understanding that it's meant to be deployed on a single machine or LAN, not the Internet). Radio servers should be able to communicate with others on the LAN, which can help to aggregate resources.
Radio Emulator - Amateurs will have a lot of legacy software lying around. The radio emulator would provide a virtual COM port and soundcard for older software to access the services provided by the radio server. The emulator would be capable of emulating one or more popular models of radio (or perhaps the drivers can have an emulation mode?). Perfect when the author of your favourite software hasn't got around to supporting the radio server API directly. :)
Remote Base Server - The remote base server makes the radio server's facilities available to users over the Internet. Many readers would be familiar with this aspect of the system, since there are a number of remote base systems out there. The remote base server has to handle authentication, validation (or have access to an external validation network), audio compression, sharing the radio between multiple remote users (i.e. who can tune and talk), security (who can do what and on what frequencies?). These functions are the same as those managed by systems such as RCForb. The difference being instead of talking direct to the radio, they would communicate with the radio server. Again, the protocol used by the remote base server should be open and fully documented. It should incorporate a higher degree of security, and be capable of running over IPv6 as well as IPv4.
Remote Base Clients - The other side of the remote base equation. Provided the interface and audio for the remote user. Remote base clients should be written for the major OSs (Windows, OS X, Linux), as well as mobile devices - Android, iOS, Windows Mobile, etc. A web based client could be developed as well.
Further down the track, remote base data mode support could be added. Data modes would require a standard for encoding data like waterfall displays in a minimum of bandwidth, as well as exchanging the raw data over the Internet. This would require a rethink on how data applications work, or encoding audio for data purposes. Remote data applications haven't been really considered by anyone, so this is a new area needing a brainstorm.
Anyway, that's the outline of how rig control could look in the future.