Thread: [Hamlib-stationserver] Terminology
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-stationserver
|
From: Nate B. <n0...@n0...> - 2014-03-07 12:19:45
|
In some of the threads I have noted a bit of confusion. Some of that may be a "here" thing. :-D Of note, it may be helpful to discern between clients and users. If we can agree on the following, it should help in further discussion: Client -- a program that exchanges data with Stationserver. User -- a person using one of more clients. At a minimum Stationserver should be designed to manage data between multiple clients and handle contention between those clients and the physical device. Multiple users may require some higher level handling but at their simplest would appear as multiple clients to Stationserver. At some point it may be necessary to discern users/clients as opposed to only clients. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us |
|
From: Art B. <ac...@in...> - 2014-03-07 16:30:29
Attachments:
PastedGraphic-2.pdf
|
On Mar 7, 2014, at 4:19 AM, Nate Bargmann <n0...@n0...> wrote: > Client -- a program that exchanges data with Stationserver. > User -- a person using one of more clients. Agreed for my part. The "user" is an Actor in UML terms... might be a person, might theoretically be an automated process, but in any event I think we've decided to only support one at a time. > At a minimum Stationserver should be designed to manage data between > multiple clients and handle contention between those clients and the > physical device. Depending on what we mean by "handle contention" this could be where we open Pandora's Box. It's fairly simple to queue different client's requests so they'll be serviced first-in-first-out. It would be much more complicated to implement and operate a feature-locking scheme to privilege one client above all others, and I'm wondering whether we might be chasing a hypothetical requirement there. Since we seem to be leaning toward simplicity I'd propose we adopt the former, simpler approach... multiple clients under control of a single user, with user inputs processed FIFO regardless of which client forwards them. Of course nothing would preclude someone from deploying simplified read-only versions of the client. > Multiple users may require some higher level handling but at their > simplest would appear as multiple clients to Stationserver. There's also the legalistic question of who is the control operator. Or, to put it more generically, an audibility question; how would we ensure that each of the users can be held accountable for his/her/its own actions? - Art KD6O PS - Here's the updated (LAN-only) reference-architecture diagram from the Requirements, which I hope represents our nomenclature correctly. |
|
From: Greg T. <gd...@le...> - 2014-03-08 14:58:55
|
Nate Bargmann <n0...@n0...> writes:
> In some of the threads I have noted a bit of confusion. Some of that
> may be a "here" thing. :-D
>
> Of note, it may be helpful to discern between clients and users. If we
> can agree on the following, it should help in further discussion:
>
> Client -- a program that exchanges data with Stationserver.
> User -- a person using one of more clients.
>
> At a minimum Stationserver should be designed to manage data between
> multiple clients and handle contention between those clients and the
> physical device.
While the client notion is fine, the notion that there is a human using
a client is unnecessarily limiting.
Another issue is the scale of stationserver (I just joined the list). I
am not entirely clear on the current world, but will try to sketch a way
things might go
* hamlib runs in a process and an instance controls one radio
* rigctld is basically an instance of hamlib with an RPC interface, as a
way for multiple programs to use one radio. But, it doesn't really
have access control.
* one could envision a program that adds to rigctld access control so
that it can be used remotely
* one could envision a program that adds to rigctld supporting multiple
connected radios at once
* one could envision a program running on multiple computers with one or
more radios per computer that provides a single interface to all of
them ("federation"). One might have read-only privs on some radios,
and write on another, perhaps to see frequencies of other sub-stations
on a multi-multi operation.
So, I think the first thing is to define the scope and that's best
driven by some example use cases.
From an implementation point of view, I wonder if one can spin up
multiple hamlib instances in the same process, each with a radio? That
seems like an obvious first step if it doesn't already work.
73 de n1dam
|
|
From: Tony L. <vk...@gm...> - 2014-03-11 07:29:31
|
I've been otherwise occupied the last few days, hence my silence.
On 9/03/2014 1:58 AM, Greg Troxel wrote:
> While the client notion is fine, the notion that there is a human using
> a client is unnecessarily limiting.
I agree, some clients can be automated/unattended, others that
Stationserver sees as "clients" could be actually add-on modules
providing extra functionality, one example that comes to mind is a
remote base module. One of these days I'll find a way to draw some
examples of possible configurations, and clarify some of the ideas I
had, so we're on the same page and can toss them over and see if they're
appropriate for the project or not.
>
>
> Another issue is the scale of stationserver (I just joined the list). I
> am not entirely clear on the current world, but will try to sketch a way
> things might go
>
> * hamlib runs in a process and an instance controls one radio
Yep
>
> * rigctld is basically an instance of hamlib with an RPC interface, as a
> way for multiple programs to use one radio. But, it doesn't really
> have access control.
Again yep. Other than a quick test to see how it works, I haven't had a
lot of chance to play with it, because I have to unload it to use other
radio control software (this problem being the issue that made me ask if
there was a better way).
>
> * one could envision a program that adds to rigctld access control so
> that it can be used remotely
I was going to experiment with using shell scripts from thelinkbox to
make a primitive client for rigctld, but haven't had the time yet.
>
> * one could envision a program that adds to rigctld supporting multiple
> connected radios at once
Yep, I see where you're going.
>
> * one could envision a program running on multiple computers with one or
> more radios per computer that provides a single interface to all of
> them ("federation"). One might have read-only privs on some radios,
> and write on another, perhaps to see frequencies of other sub-stations
> on a multi-multi operation.
This is the next logical step. I have two radios I want to control at
this point in time.
>
>
> So, I think the first thing is to define the scope and that's best
> driven by some example use cases.
Yep. Some of the examples I had in mind:
1. Single machine use. Stationserver and the client both run on the
same machine, communicationg via localhost. This is functionally
equivalent to running Hamlib, except that the client doesn't need to
know what make and model of radio it is using - instead it can
communicate using a generic protocol, and can get information about the
radio's capabilities from the server.
2. LAN use, single control. Same as above, except that the server and
client are on separate machines. Only difference in client
configuration would be the IP address or hostname of the server would be
something other than localhost (127.0.0.1 or ::1, depending on IP
version). Because I was assuming a single user (see below), I was
assuming a single network domain, by which I mean either a LAN (a single
PC being a special case) or in the case of multiple sites, a secure VPN
such as OpenVPN or IPSec connecting the sites.
3. Multiple radios - in this case, Stationserver is configured with two
or more radios. Clients can use those radios separately, or together
(for example, using one to transmit and another to receive for crossband
or satellite operation). If the protocol can include a timestamp, even
tricks like diversity reception may be possible if you have two or more
radios capable of receiving the same frequency.
4. Multiple simultneous access - here clients can simultaneously use
the same radio. It could be one user with 2 devices open at the same
time, or it could be an automated client (for example, an audio logger)
and a rig control program running together, or even a rig control
program on the LAN sharing with a remote base add-on. Another variation
is where two programs are used together for some reason (for example, I
might want to use dl-fldigi for tracking high altitude balloons, but I
prefer the interface of HRD to set the radio's frequency, then let
dl-fldigi automatically control the VFO from there, while using HRD to
monitor and tweak the frequency or change other settings.
The terminology I've been using so far:
Client - process that makes use of the services that Stationserver
provides. Automated processes that utilise Stationserver services are
also clients.
Radio - device being controlled - normally a radio, but I am aware
people want to control other accessories such as rotators as well. I
haven't thought much beyond the radio case, other than being aware some
people do have other accessories to control (at this time, I don't myself).
User - A person who accesses the system by use of clients. Clients may
be associated with a user, though there can be more than one client per
user, and automated clients have no live user interaction, although they
are at some stage configured and managed by a user at some stage (even
if that "configuration" is to accept the defaults!).
Owner - the person who runs Stationserver and configures the radio (and
presumably owns the radios and the server machine!).
Add-on - Special clients that provide additional functionality beyond
what the base level Stationserver would provide. One example I have
previously mentioned is a remote base add-on. This acts like a client
to Stationserver and provides access to the radio to Internet connected
users. The remote base add-on would provide support for multiple users,
authentication and validation, secure control channels and audio, audio
compression, access controls (i.e. who can transmit, who is receive
only, etc).
When I was thinking about new rig control architectures, I was thinking
of a single user system, where the owner was also the one and only user
( of the core system), and that's the perspective I have been discussing
this from, at least as far as the core system is concerned, with more
specialised functionality being provided by add-ons.
That's just the place where I was coming from for input, and may or may
not be appropriate for a generic system.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
|
|
From: Greg T. <gd...@le...> - 2014-03-18 23:06:45
|
Tony Langdon <vk...@gm...> writes: >> So, I think the first thing is to define the scope and that's best >> driven by some example use cases. > Yep. Some of the examples I had in mind: > > 1. Single machine use. Stationserver and the client both run on the > same machine, communicationg via localhost. This is functionally > equivalent to running Hamlib, except that the client doesn't need to > know what make and model of radio it is using - instead it can > communicate using a generic protocol, and can get information about the > radio's capabilities from the server. So by use case, I meant one level up: a story about how programs did things to radios and how people people interacted wtih the programs, that didn't presuppose that there was a thing called stationserver. Basically, I'm trying to suggest that the existence of stationserver is a possible system architecture after requirements are understood. I'm still not really clear on what ought to happen, and what sorts of things would be supported - and even what's wrong with the world now. |
|
From: Art B. <ac...@in...> - 2014-03-23 18:52:32
|
Greg / All - This is where I've gotten a bit stalled... I don't think we've reached critical mass on this list for collecting user inputs. One way to look at this project, I suppose, would be as a matter of putting a network front-end on existing hamlib modules. Not sure what are the status and/or shortcomings of rigctld... and I think I've seen reference to an XMLRPC mechanism as well. Maybe Nate or someone else could help bring us up to speed on the prior art? Meanwhile... in a scratching-my-own-itch sort of way... I've been noodling on the question of the most useful level(s) of abstraction. The existing hamlib appears to approach this at two levels... one at the individual "rig" level... and another at what I take it is a generic "virtual rig" level. But considering the enormous variety of existing rig configurations... and what I assume will be a sustained commercial incentive toward product differentiation by adding new and unique features (or at least controls)... I'm thinking this might not be the most sustainable model. There does seem to be a natural demark at the level of different CAT interface protocols 'twixt computer and radio. That appear to be structured largely by different vendors' implementations with perhaps some "dialects" within vendors' lines. This again, is somewhere I could use some help; maybe someone with more experience in CAT implementations could brief us on the current landscape of CAT protocols? Above that level, though, the practical definition of "rig" seems to be "a collection of features flying in loose formation." The functionality of a "rig" may be defined not just by a particular box, but also by its interconnections with other devices. Thus, if the functionality of a control interface isn't to be restricted to predictable "generic" functions, we need a way to discover which functions are on offer from a particular server instance. Once we have that configuration data describing a particular server's set of getter and setter functions... each with its value type (on/off, integer/enumeration, float value, array), permitted value range, units, item label, and probably a text description... I'm thinking a pretty basic set of get and set functions would permit control of... well, pretty much anything, really! Perhaps a RESTful web interface, and a JSON document for the station-configuration file (and perhaps also for combining controls and queries, e.g., for when a channel shift means changing frequency, mode and antenna all at once.) Just thinking... - Art KD6O On Mar 18, 2014, at 4:06 PM, Greg Troxel <gd...@le...> wrote: > > Tony Langdon <vk...@gm...> writes: > >>> So, I think the first thing is to define the scope and that's best >>> driven by some example use cases. >> Yep. Some of the examples I had in mind: >> >> 1. Single machine use. Stationserver and the client both run on the >> same machine, communicationg via localhost. This is functionally >> equivalent to running Hamlib, except that the client doesn't need to >> know what make and model of radio it is using - instead it can >> communicate using a generic protocol, and can get information about the >> radio's capabilities from the server. > > So by use case, I meant one level up: a story about how programs did > things to radios and how people people interacted wtih the programs, > that didn't presuppose that there was a thing called stationserver. > Basically, I'm trying to suggest that the existence of stationserver is > a possible system architecture after requirements are understood. I'm > still not really clear on what ought to happen, and what sorts of things > would be supported - and even what's wrong with the world now. |
|
From: Tony L. <vk...@gm...> - 2014-03-24 01:09:00
|
On 24/03/2014 5:52 AM, Art Botterell wrote: > Above that level, though, the practical definition of "rig" seems to be "a collection of features flying in loose formation." The functionality of a "rig" may be defined not just by a particular box, but also by its interconnections with other devices. Thus, if the functionality of a control interface isn't to be restricted to predictable "generic" functions, we need a way to discover which functions are on offer from a particular server instance. And then we can get into "virtual rigs", which could represent anything. One possible use for such a construct is to logically combine two rigs into one for satellite operation, to enable cross band full duplex with two radios that don't have this functionality. The application ultimately controlling the radio would see a single full duplex capable rig. I don't know if there's any advantages to this approach as opposed to applications seeing and using two rigs separately. > > Once we have that configuration data describing a particular server's set of getter and setter functions... each with its value type (on/off, integer/enumeration, float value, array), permitted value range, units, item label, and probably a text description... I'm thinking a pretty basic set of get and set functions would permit control of... well, pretty much anything, really! Nice and simple. :) > > Perhaps a RESTful web interface, and a JSON document for the station-configuration file (and perhaps also for combining controls and queries, e.g., for when a channel shift means changing frequency, mode and antenna all at once.) Hmm, web interface? I need to establish the exact function of this, because I think of a "web interface" as a front end (which sounds more like a client to me in our model), not something further back in the chain. Just trying to clarify and get our terminology straight. :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Art B. <ac...@in...> - 2014-03-24 01:18:59
|
On Mar 23, 2014, at 6:08 PM, Tony Langdon <vk...@gm...> wrote: > And then we can get into "virtual rigs", which could represent > anything. One acid test I like to apply to designs is "what WON'T this let me do?" Unnecessary restrictions and constraints seem often to reflect underlying design flaws. > Hmm, web interface? I need to establish the exact function of this, Probably I should have said "web-service interface" to clarify that. Although one of the nice things about RESTful web interfaces is that it's usually easy to implement clients as browser-based apps, that's not a requirement. But I'm talking strictly server-side here. Just using HTTP for transport and allowing all requests to be encoded as URLs, which is the essence of the REST style. BTW, another benefit of implementing things as web services is that things like user authentication and access control can often be implemented conveniently in the web server software. They also sidestep a lot of potential firewall hassles. 73, - Art KD6O |
|
From: Tony L. <vk...@gm...> - 2014-03-24 04:43:20
|
On 24/03/2014 12:18 PM, Art Botterell wrote: > On Mar 23, 2014, at 6:08 PM, Tony Langdon <vk...@gm...> wrote: > >> And then we can get into "virtual rigs", which could represent >> anything. > One acid test I like to apply to designs is "what WON'T this let me do?" Unnecessary restrictions and constraints seem often to reflect underlying design flaws. Yep, makes sense to me. > >> Hmm, web interface? I need to establish the exact function of this, > Probably I should have said "web-service interface" to clarify that. Although one of the nice things about RESTful web interfaces is that it's usually easy to implement clients as browser-based apps, that's not a requirement. > > But I'm talking strictly server-side here. Just using HTTP for transport and allowing all requests to be encoded as URLs, which is the essence of the REST style. Yep, that's why I asked, because the context suggested this is what you meant, but the words suggested a more client side focus. Sounds like a sensible approach. And I'd expect to see a browser based client alongside other alternatives (though I prefer dedicated clients to browser based ones, a client in a browser has its uses). > > BTW, another benefit of implementing things as web services is that things like user authentication and access control can often be implemented conveniently in the web server software. They also sidestep a lot of potential firewall hassles. Yep. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Nate B. <n0...@n0...> - 2014-03-24 02:43:04
|
* On 2014 23 Mar 13:54 -0500, Art Botterell wrote: > Greg / All - > > This is where I've gotten a bit stalled... I don't think we've reached > critical mass on this list for collecting user inputs. No problem, I have been moving and will now start the process of getting settled into the "new" digs, which the house I grew up in. Mailing lists have been a bit off of my radar lately and I have some catching up to do. > One way to look at this project, I suppose, would be as a matter of > putting a network front-end on existing hamlib modules. Not sure what > are the status and/or shortcomings of rigctld... and I think I've seen > reference to an XMLRPC mechanism as well. Maybe Nate or someone else > could help bring us up to speed on the prior art? XMLRPC is a feature of W1HKJ's Fldigi/Flrig. This is an RPC deamon in Hamlib 1.2.15.3 and earlier but has been removed in the forthcoming Hamlib 3.0. > Meanwhile... in a scratching-my-own-itch sort of way... I've been > noodling on the question of the most useful level(s) of abstraction. > The existing hamlib appears to approach this at two levels... one at > the individual "rig" level... and another at what I take it is a > generic "virtual rig" level. But considering the enormous variety of > existing rig configurations... and what I assume will be a sustained > commercial incentive toward product differentiation by adding new and > unique features (or at least controls)... I'm thinking this might not > be the most sustainable model. No argument from me! > There does seem to be a natural demark at the level of different CAT > interface protocols 'twixt computer and radio. That appear to be > structured largely by different vendors' implementations with perhaps > some "dialects" within vendors' lines. This again, is somewhere I > could use some help; maybe someone with more experience in CAT > implementations could brief us on the current landscape of CAT > protocols? Right now it appears that the Kenwood style command set is gaining ground although I doubt Icom will abandon CI-V anytime soon. The Kenwood command strings are human readable so that is an aid in development/troubleshooting. While some commands are rather universal, FA; to read the frequency of VFO A, in my experience the variance will be in the range of parameters each model supports. As you've noted, newer models often have additional commands. Other manufacturers will use Kenwood compatible commands and add additional ones (Elecraft, for example). Yaesu's binary CAT command set is dead for new models (hooray!). > Above that level, though, the practical definition of "rig" seems to > be "a collection of features flying in loose formation." Nice DC3 reference. ;-) > The > functionality of a "rig" may be defined not just by a particular box, > but also by its interconnections with other devices. Thus, if the > functionality of a control interface isn't to be restricted to > predictable "generic" functions, we need a way to discover which > functions are on offer from a particular server instance. This is a bit of a duplication of the usual Hamlib backend. Much useful information is stored there and a good part of it is reasonably debugged. The tricky part is dealing with differences in a radio's firmware. Where this cannot be determined reliably, we have resorted to separate backend models. I think the IC-756 series is broken out in a manner such as this. At least that would be my advice to a Hamlib contributor looking at different firmware revisions that would force backend functions to be supported in a different manner. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us |
|
From: Tony L. <vk...@gm...> - 2014-03-24 04:53:37
|
On 24/03/2014 1:42 PM, Nate Bargmann wrote: > No problem, I have been moving and will now start the process of getting > settled into the "new" digs, which the house I grew up in. Mailing > lists have been a bit off of my radar lately and I have some catching up > to do. Arrrgh house moving - fun... NOT! :) > Right now it appears that the Kenwood style command set is gaining > ground although I doubt Icom will abandon CI-V anytime soon. The > Kenwood command strings are human readable so that is an aid in > development/troubleshooting. > > While some commands are rather universal, FA; to read the frequency of > VFO A, in my experience the variance will be in the range of parameters > each model supports. As you've noted, newer models often have > additional commands. Other manufacturers will use Kenwood compatible > commands and add additional ones (Elecraft, for example). > > Yaesu's binary CAT command set is dead for new models (hooray!). So, we're basically down to two main command sets (with dialects) - Icom and Kenwood, at least for current models? > This is a bit of a duplication of the usual Hamlib backend. Much useful > information is stored there and a good part of it is reasonably > debugged. There is a good argument to support the use of Hamlib backends. This would be useful for 2 reasons: 1. Allows development to focus on areas other than specifics of rig support - the end result would be useable, while the native backend definitions are still being written. 2. Allows support of older models for which a new style backend may never be written (but have Hamlib support today). I'm thinking of radios like my FT-736R. > > The tricky part is dealing with differences in a radio's firmware. > Where this cannot be determined reliably, we have resorted to separate > backend models. I think the IC-756 series is broken out in a manner > such as this. At least that would be my advice to a Hamlib contributor > looking at different firmware revisions that would force backend > functions to be supported in a different manner. > > 73, de Nate >> > -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X