I recently acquired a wireless network card for my laptop. Whilst sitting at the kitchen counter one evening I had an interesting thought. It occurred to me that during a typical PSK31 QSO, I rarely, if ever, need to actually touch the transceiver. I thought of the idea of a network version of the WinPSKX control that would allow me to operate PSK31 from the kitchen, while running the rig over the network.
The WinPSKX ActiveX control was developed in collaboration with Moe Wheatley, AE4JY. Moe has written an excellent Windows DLL that encapsulates the functionality for PSK31 communications. My addition to this was to write an ActiveX wrapper that provided both the PSK31 communications functionality to a Windows application, but also provided an integrated user interface that handled the complexities of the visual data displays and handling mouse inputs.
The following diagram illustrates the structure of the WinPSKX control.
In addition to encapsulating both the PSK31 communications and the user interface, the ActiveX control wrapper makes it very easy for programmers to use this in an application. Visual Basic programmers, for example, simply select the WinPSKX control from the toolbox and drop it onto the application form. With a bit of coding to connect the WinPSKX control to the Visual Basic application's other form controls, you can write a very simple PSK31 monitor with just a few lines of VB code.
The general concept for the network version of the WinPSKX ActiveX control is that the user interface elements are handled on the client side, and the PSK31 communications functions are handled on the server side. Moe's PSKCore code establishes a well-defined interface for the PSK31 communications functions, so it was fairly easy to split the standard version of the WinPSKX control at this interface point.
The following diagram illustrates the general architecture of the system.
The primary concern I had in the beginning was whether or not the local area network would be capable of sustaining the volume of data required for the waterfall display, which consisted of 1,024 longwords of data transferred every 256 ms, i.e., 31,625 bytes per second. While this may not seem to be an exorbitant amount of data for a typical LAN, I wasn't sure how much additional overhead the protocol layers would add to this by the time the data got down to the network wire. Furthermore, I didn't know if latencies in the network might also impact the performance, or even the operation, of the PSK31 communications.
Preliminary prototyping indicated that, on a relatively quiet 11 Mb wireless network, there was no problem with the data flow. At this point, I decided to go ahead and fully implement the remote procedure interfaces.
My initial inclination for the network transport was to employ DCOM (Distributed Component Object Model). While COM itself is somewhat daunting to many programmers, I am fortunate to have experience in that area. The advantage of using COM, (and specifically DCOM), is that the Microsoft Visual Studio can be used, which takes a lot of the work out of building the components and the underlying network communications. The disadvantages are that COM programming can get complicated if you need to do anything out of the ordinary, and you have no control over the efficiency of the underlying implementation.
My initial implementation using DCOM was relatively promising as far as being able to accomplish the desired result. However, I found myself getting mired down with workarounds as I started into the details. As is often the case with RAD tools and technology, 10% of the effort gets you 90% of the way there, and the effort to achieve the final 10% skyrockets.
Rather than waste a lot of time with the "ideal" solution (at least in Microsoft's opinion), I decided to get down to the basics. Every COM programmer worth his/her salt knows that RPCs are the underlying transport mechanism for DCOM, What many seem not to realize, however, that RPCs are not that difficult to use directly. I went ahead and tried a direct implementation and found the result quite satisfactory. By cutting to the chase, I eliminated all of the complexity and unknowns (no pun intended) of the COM layer.
My initial experiments using standalone client and server applications progressed well, so I started to re-implement the PSKCore function calls within the WinPSKX control as remote function calls. I didn't start out with the expectation that my prototype would result in a full implementation of the WinPSKX control, but I wound up implementing all of the PSKCore functional interface in order to test it.
To my surprise, the remote WinPSKX system worked right off the bat! I suppose I shouldn't have been too surprised, RPCs are intended to be essentially transparent interfaces to the remote service. But still...
The primary issue at this point is, while the system works fine when it's working, it is not robust by any means. It is quite easy to crash the client simply by shutting down the server application. Furthermore, the client needs better error handling in the case where it is started before the server.
Another issue that will be under investigation will be network throughput and latency effects. The results of these investigations will be posted when available.
Not likely. For those of you who have ever used an "Internet Phone" utility, you know how susceptible the Internet is to significant latencies and data loss. While I wouldn't rule it out, it seems unlikely to me that it would be practical. However, there is room for improvement in the current implementation. For example, many parameters are passed as 32 bit longwords when they do not actually need the entire 32 bits. By reducing the data types of certain parameters, the data bandwidth can be reduced. Compression probably wouldn't provide any improvement since the data is binary and often consists of only a few octets per RPC transfer.
Now that the proof-of-concept demonstrates that the idea is feasible, I may return to a DCOM implementation. DCOM does have some advantages, particularly in its robustness. The RPC mechanism is a very low-level network protocol. As such, you are expected to deal with all errors and exceptions. DCOM, on the other hand, wraps the low-level handling and returns errors rather than exceptions. Furthermore, setting up and managing DCOM components is generally easier than with RPCs.
This project started simply as a "what if" scenario. The question now is, is it practical? And the most important question is, is it useful? I created the remote WinPSKX control purely to satisfy my own wishes. I don't intend to publish a public version of this WinPSKX control unless there is sufficient interest. However, if you have any opinions on the value of this scheme, I would be happy to hear from you.
73 to all! ...de Dave, WAØTTN...
|p.s. This is the Happy-Dance I did when I got this project working...|
Go to the WAØTTN Web page.
Go to the Dave Cook Consulting Web page.
Last updated October 31, 2001