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.
Wednesday, November 27, 2013
Wednesday, November 20, 2013
Friday, July 19, 2013
Remote Bases - Time for a new architecture?
I just started down the remote base road in the
last few weeks, after getting my station back on the air after a house
move. My main use is to monitor and control the radio from around the
house, as the shack isn't the most convenient place to actually operate
from, but it has by far the best access to outside for antennas.
I'm currently using VNC for control, switching between Ham Radio Deluxe, RMS Express and whatever else I need to run at the time. Audio is currently using Skype, because all of my devices support Skype.
In my research into options, I found all of them wanting. I currently have 2 radios I can control remotely - a FT-736R (with external FT-847 - FT-736R CAT converter, so newer software sees it as an 847), and an IC-7000. The shack PC runs Windows Vista, but I prefer not to run it 24x7 due to power consumption. I'd prefer to use one of my Linux netbooks, or even a Raspberry Pi. However, the Windows box is working well for the time being. Complicating matters is that my client machines are either a MacBook Pro or iPhones and iPads. So far, I haven't found a neater solution. I did try HRD under WINE, but that had more lag than VNC, and meant I had to keep stopping and starting the remote when I wanted to change software, so I stuck with using VNC.
This situation got me thinking about the current state of remote bases. It seems that almost all solutions are limited to one desktop OS, and very few support mobile devices natively (CommCat is a notable exception here with its iOS support). My cross platform needs aren't supported at all, at least by traditional systems. I did also encounter the Pignology hardware, but that looks rather pricey.
A couple of major issues really stood out. Firstly, just about everything looks proprietary - HRD only works with HRD, etc. You can't mix and match frontends or backends to suit your situation and preferences. Secondly, the control is very low level transporting COM port data over IP. This is reminiscent of the DOS days of networking, where networking was done at a low level, and each application had to supply its own protocol stack, or similar for DOS based word processors. As a user hanging off the end of an Internet connection, my application shouldn't have to care that I'm talking to an IC-7000 using CAT commands, the back end at the remote base should be looking after low level details like that.
My dream remote base system has:
Drivers to support CAT capable radios. These drivers can be used by any compatible backend, and also report the radio's capabilities up the stack. Drivers can also emulate some needed capabilities. FOr example, "reading" of an FT-736R's VFO can come from the driver, with the driver writing that value to the radio. Like Windows device drivers, radio drivers should be updateable.
Network communications should be higher level. Radio control would be commands to "set VFO on radio 1", etc. Audio support is integrated and can use one of two codecs - GSM (good enough for natural sounding voice) and either raw PCM or ulaw (mainly for unsupported digital modes). Digital modes can be supported by having a server side add-on, which does the leg work of modulation, demodulation and other protocol necessities. The client side would provide the user interface, for typing, viewing, reading, etc. Data would be transported between the two ends. If hardware is required, which end it goes on would depend on the hardware - a Pactor controller would need to be at the radio end, while a DV Dongle could be at the user's end (transporting audio as AMBE over IP), or at the radio end. It goes without saying that the protocols used would be open standards, so any software vendor or developer can support it.
The amount of control and status data sent could be adjusted to suit the link - across a LAN, the control can be sent using a high bitrate in real time, while on a mobile data connection, the status and control information can be scaled back.
As for authentication and access control, this could be modular too, as a single user remote base like mine has quite different access control requirements to a public Internet remote base with users all over the globe.
Another use for this setup was to allow a DTMF decoder to be used as a "front end", which could talk to a back end on the same host, over a LAN or over the Internet. This would allow remote bases linked to VHF repeaters or Echolink/IRLP.
I know this sounds rather ambitious, but it's a wish list based on what I've seen as well as want to attempt, and the point was to stimulate discussion as well as get people thinking in a different way about remote bases.
Sadly, I'm not a programmer, otherwise I'd have at least cobbled together a basic demonstration of analogue operation.
Thoughts anyone?
I'm currently using VNC for control, switching between Ham Radio Deluxe, RMS Express and whatever else I need to run at the time. Audio is currently using Skype, because all of my devices support Skype.
In my research into options, I found all of them wanting. I currently have 2 radios I can control remotely - a FT-736R (with external FT-847 - FT-736R CAT converter, so newer software sees it as an 847), and an IC-7000. The shack PC runs Windows Vista, but I prefer not to run it 24x7 due to power consumption. I'd prefer to use one of my Linux netbooks, or even a Raspberry Pi. However, the Windows box is working well for the time being. Complicating matters is that my client machines are either a MacBook Pro or iPhones and iPads. So far, I haven't found a neater solution. I did try HRD under WINE, but that had more lag than VNC, and meant I had to keep stopping and starting the remote when I wanted to change software, so I stuck with using VNC.
This situation got me thinking about the current state of remote bases. It seems that almost all solutions are limited to one desktop OS, and very few support mobile devices natively (CommCat is a notable exception here with its iOS support). My cross platform needs aren't supported at all, at least by traditional systems. I did also encounter the Pignology hardware, but that looks rather pricey.
A couple of major issues really stood out. Firstly, just about everything looks proprietary - HRD only works with HRD, etc. You can't mix and match frontends or backends to suit your situation and preferences. Secondly, the control is very low level transporting COM port data over IP. This is reminiscent of the DOS days of networking, where networking was done at a low level, and each application had to supply its own protocol stack, or similar for DOS based word processors. As a user hanging off the end of an Internet connection, my application shouldn't have to care that I'm talking to an IC-7000 using CAT commands, the back end at the remote base should be looking after low level details like that.
My dream remote base system has:
Drivers to support CAT capable radios. These drivers can be used by any compatible backend, and also report the radio's capabilities up the stack. Drivers can also emulate some needed capabilities. FOr example, "reading" of an FT-736R's VFO can come from the driver, with the driver writing that value to the radio. Like Windows device drivers, radio drivers should be updateable.
Network communications should be higher level. Radio control would be commands to "set VFO on radio 1", etc. Audio support is integrated and can use one of two codecs - GSM (good enough for natural sounding voice) and either raw PCM or ulaw (mainly for unsupported digital modes). Digital modes can be supported by having a server side add-on, which does the leg work of modulation, demodulation and other protocol necessities. The client side would provide the user interface, for typing, viewing, reading, etc. Data would be transported between the two ends. If hardware is required, which end it goes on would depend on the hardware - a Pactor controller would need to be at the radio end, while a DV Dongle could be at the user's end (transporting audio as AMBE over IP), or at the radio end. It goes without saying that the protocols used would be open standards, so any software vendor or developer can support it.
The amount of control and status data sent could be adjusted to suit the link - across a LAN, the control can be sent using a high bitrate in real time, while on a mobile data connection, the status and control information can be scaled back.
As for authentication and access control, this could be modular too, as a single user remote base like mine has quite different access control requirements to a public Internet remote base with users all over the globe.
Another use for this setup was to allow a DTMF decoder to be used as a "front end", which could talk to a back end on the same host, over a LAN or over the Internet. This would allow remote bases linked to VHF repeaters or Echolink/IRLP.
I know this sounds rather ambitious, but it's a wish list based on what I've seen as well as want to attempt, and the point was to stimulate discussion as well as get people thinking in a different way about remote bases.
Sadly, I'm not a programmer, otherwise I'd have at least cobbled together a basic demonstration of analogue operation.
Thoughts anyone?
Subscribe to:
Posts (Atom)