You can subscribe to this list here.
2014 |
Jan
|
Feb
|
Mar
(80) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2018 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Phesto P. N. <phe...@go...> - 2021-12-17 08:25:37
|
Hello Members We are currently conducting a study that aims to optimise User Experience (UX) in the development processes of Free and Open-source software (FOSS), including Ham Radio Control Libraries. This study believes that delivering projects of this nature with desirable UX is an organisational effort. Therefore, precisely comprehending what make FOSS projects with desirable UX, integrating them in the development processes, and optimally assessing these processes are mandatory. UX is still ambiguous and what create several FOSS projects with desirable UX are still unknown. Moreover, although these projects offer immense contributions, they are not widely adopted, and UX is recurring as the significant cause of ongoing adoptions misfortune. The FOSS community has not done enough to address these challenges. Therefore, to dig deeper into this problem, we have developed a questionnaire with several UX influencing factors seeking FOSS stakeholders' perceptions. The developed questionnaire provides evidence rather than opinions when capturing insights into how stakeholders in the FOSS community perceive UX influencing factors. Furthermore, it is the derivative of several psychometric scales, such as AttrakDiff, VisAWI, SUS, UEQ, meCUE, and reviewed literature. We kindly request that the network feel free and offer candid feedback by completing the appraisal in the link shown below. https://forms.gle/rzLcEwj3LpPkci3p7 -- | Phesto P Namayal | P.O. Box 40673 | Dar es Salaam. Tanzania | |email: pna...@mu... |website: http://www.mustnet.ac.tz |
From: Howard N. <hl...@cm...> - 2018-03-17 01:52:21
|
Yes, I've already done so. Mike helped with my recent CW problem, and the new files are working perfectly. --Howard -----Original Message----- From: Nate Bargmann [mailto:n0...@n0...] Sent: Friday, March 16, 2018 6:48 PM To: ham...@li... Subject: Re: [Hamlib-stationserver] Status Sounds good, Howard. BTW, if you have questions specific to Hamlib in the future, please post them to the hamlib-developer mailing list: https://sourceforge.net/p/hamlib/mailman/hamlib-developer/ 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: 0xD55A8819 GitHub: N0NB |
From: Nate B. <n0...@n0...> - 2018-03-17 01:47:50
|
Sounds good, Howard. BTW, if you have questions specific to Hamlib in the future, please post them to the hamlib-developer mailing list: https://sourceforge.net/p/hamlib/mailman/hamlib-developer/ 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: 0xD55A8819 GitHub: N0NB |
From: Howard N. <hl...@cm...> - 2018-03-17 00:06:12
|
Thank you, Nate. The project uses the Raspberry PI GPIO for an onboard Winkeyer, but also supports external Winkeyers and rigctld connections which send Morse through CAT. You can assign one keyer per radio, using multiple Winkeyers or CAT/rigctld connections for many radios. The code is written in HTML5, jQuery and PHP 7 running on an Apache server. UI is through any web browser, but will also be possible through a Kenwood-like interface. CommCat Mobile (my creation) for iOS will use this interface. VoIP is provided using an onboard audio board or external devices. It is username/password protected, with different security levels for different levels of access. You can see more at https://rigpi.com I'm working with MFJ on the hardware side. They will sell a plug 'n play RigPi ready to go. --Howard -----Original Message----- From: Nate Bargmann [mailto:n0...@n0...] Sent: Friday, March 16, 2018 4:30 PM To: ham...@li... Subject: Re: [Hamlib-stationserver] Status * On 2018 16 Mar 16:55 -0500, Howard Nurse wrote: > Hi All, > > > > I've just learned of the station server list, and have found the > discussion to be most interesting. But most of the discussion was in > 2014. Is there any current interest in the topic? I am not sure as the discussion went cold four years ago as you note. I set up the list to facilitate discussion of such ideas and to answer questions regarding Hamlib as best I could. > I'm working on a system that appears to mimic many of the ideas posted here. > It will be open sourced on Github, and runs on Linux, specifically the > Raspberry Pi. It is based on Hamlib. I'm looking forward to input and > feedback. I would say that so long as your project doesn't require specific hardware support of the Pi and is portable to x86 and other ARM hardware, you should have a winner. Since the time this list was created, Hamlib has made more use of the GitHub resources available. > I'm calling it RigPi, a MOMR server for amateur radio. > (Multiple-Operator, > Multiple-Radio) I think that is needed in this day and age. Feel free to use this list for your project. As long as SourceForge stays up, it should be reliable. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: 0xD55A8819 GitHub: N0NB |
From: Nate B. <n0...@n0...> - 2018-03-16 23:29:50
|
* On 2018 16 Mar 16:55 -0500, Howard Nurse wrote: > Hi All, > > > > I've just learned of the station server list, and have found the discussion > to be most interesting. But most of the discussion was in 2014. Is there > any current interest in the topic? I am not sure as the discussion went cold four years ago as you note. I set up the list to facilitate discussion of such ideas and to answer questions regarding Hamlib as best I could. > I'm working on a system that appears to mimic many of the ideas posted here. > It will be open sourced on Github, and runs on Linux, specifically the > Raspberry Pi. It is based on Hamlib. I'm looking forward to input and > feedback. I would say that so long as your project doesn't require specific hardware support of the Pi and is portable to x86 and other ARM hardware, you should have a winner. Since the time this list was created, Hamlib has made more use of the GitHub resources available. > I'm calling it RigPi, a MOMR server for amateur radio. (Multiple-Operator, > Multiple-Radio) I think that is needed in this day and age. Feel free to use this list for your project. As long as SourceForge stays up, it should be reliable. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: 0xD55A8819 GitHub: N0NB |
From: Howard N. <hl...@cm...> - 2018-03-16 21:19:32
|
Hi All, I've just learned of the station server list, and have found the discussion to be most interesting. But most of the discussion was in 2014. Is there any current interest in the topic? I'm working on a system that appears to mimic many of the ideas posted here. It will be open sourced on Github, and runs on Linux, specifically the Raspberry Pi. It is based on Hamlib. I'm looking forward to input and feedback. I'm calling it RigPi, a MOMR server for amateur radio. (Multiple-Operator, Multiple-Radio) 73, Howard W6HN |
From: William L. <wc...@wc...> - 2014-09-06 19:51:40
|
Good Afternoon, I currently have my controller hooked up to an OpenSuse box. The unit is hooked up USB to /dev/ttyUSB0. Last I tried, it worked in Windows, I have never gotten it to work in Linux. I am in the dialout group, the radio control does work. I have some time this afternoon to try to figure this out. Any ideas or suggestions? Has anyone gotten it to work USB or only serial?? The program I am using is CQRLOG. TNX Will WC2L |
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 |
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: 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 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-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: 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: Tony L. <vk...@gm...> - 2014-03-13 06:11:02
|
I finally got around to playing with rigctl/rigctld this afternoon with some mixed results. Firstly, the setup: I used the IC-7000, which is on COM10 (the USB CAT interface port). Initially I configured rigctld to use COM9 DTR for PTT, with no joy. I simply removed the -r parameter and set the PTT type to "RIG", so it used CAT commands, which worked. The server PC runs Windows Vista. Had to use the \\.\COM10 workaround as documented on the Hamlib site to talk to the radio. For the client, I ran rigctl on a Linux netbook, and pointed it to the IP and port of rigctld. After sorting out a baud rate issue (my bad, I got the IC-7000 and scanner baud rates mixed up), it worked, well sort of: What worked? Getting and setting VFO frequency. This was flawless. Getting and setting PTT state mostly worked. I sometimes had protocol issues getting the PTT state, but repeating the command or mixing it with getting the VFO frequency made it work. Setting the PTT state was reliable, especially directly from the command line. rigctl did report "protocol error", but the command worked. Getting the mode and CTCSS settings worked. And the not so good? I tried changing the mode, and here is where things went bad. I was not able to change the mode via the rigctl/rigctld combination (I'm sure I've done it using rigctl directly on the Windows box). Attempting to set the mode resulted in a timeout, and after the attempt, the commands that previously worked no longer worked, until rigctld was restarted. Unfortunately for my purposes, this one is a show stopper. I was able to get the current mode and filter, however (again until I attempted to set these parameters, then rigctld lost the plot, as described). That's as much as I have tried so far. Had this worked, I would have setup my EchoIRLP node as an experimental remote base server (since IRLP and Echolink take care of the security side of things, the rig control is purely over the Cat 5 LAN). -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
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: Art B. <ac...@in...> - 2014-03-09 04:36:38
|
Great thoughts, Greg! Comments below. On Mar 8, 2014, at 7:04 AM, Greg Troxel <gd...@le...> wrote: > But all of these seem to apply to hamlib and perhaps the rigctld > language, independently of stationserver. Some things can be made > common, and that's great, but the details will always differ. Which has me thinking about maybe turning the abstraction issue around. Given that rigs vary so broadly... and that time may (almostly surely will) see redefinitions of the whole notion of "rig"... perhaps the productive question isn't abstraction so much as discovery. In other words, might it work better to expose a collection of primitive input and output types... like the CONTROL and READING objects at the bottom of my earlier outline... along with a mechanism for each server to describe the particular set of widgets on offer to representing the attached equipment? Perhaps in the form of a JSON or XML data structure... which might also imply the template for control commands and queries? Seems like such an approach might allow a refactoring of the rig interfaces to be table configured rather than hard coded. It also would provide a degree of self-documentation... perhaps including some owner-suppled free text to note station peculiarities, e.g., local interference issues, antenna patterns and such. In any event it might avoid endless arguments about how best to abstract vendor-specific and innovative features. Focusing on a feature-discovery mechanism might also help with the question of audio (and video and whatever) content transports. The stationserver could simply assert the codec, rate, any other parameters and location (an IP port number, probably) for the gazinta(s) and gazoutta(s). (Although reference implementations might help drive folks toward de-facto standardization; for audio I've been looking at www.opus-codec.org / RFC 6716 but haven't played with it yet.) Then we could... if we wanted to side-step the whole user/authentication issue for the time being... simply let folks use VPNs for access control if they choose to expose their systems to the Wild Wacky Web. Or not, if they're bold... - Art KD6O |
From: Greg T. <gd...@le...> - 2014-03-08 15:04:44
|
Nate Bargmann <n0...@n0...> writes: > Ha! So true. I understand this issue fairly well. There is a lightly > documented "feature" of the control daemons that allows a raw CAT > command to be passed through to the backend. As the control daemons > share the same parsing code as the test utilities, this exposure is just > part of the deal. If a program knows that it is dealing with a specific > device/model it could issue raw commands through this path and parse the > raw data it receives. I guess a big question is the purpose. I see multiple purposes for rig control software: generic use, where a program (logger, fldigi, etc.) wants to control a radio in frequency, maybe filtering widths, or maybe just read frequency. Here the point is to hide the radio's details so that the program works with any radio (that's adequately capable) implementing a GUI front panel replacement where there are controls for everything on the radio. I don't find this super interesting except for remote operation. writing test equipment, likely for a specific radio, to do RF noise level surveys, etc. But all of these seem to apply to hamlib and perhaps the rigctld language, independently of stationserver. Some things can be made common, and that's great, but the details will always differ. So I see stationserver adding access control, multiple radios, and perhaps (big if) multiple computers federated. Am I totally missing the point? |
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: Art B. <ac...@in...> - 2014-03-07 18:40:19
|
On Mar 7, 2014, at 9:22 AM, John D. Hays <jo...@ha...> wrote: > DO NOT GO DOWN THIS PATH! It is the station operator's responsibility to meet the legal requirements of the jurisdiction governing their operation. Putting such responsibility on the software is both limiting and a mistake. Absolutely, John. My point was that if you don't authenticate users somehow you can't know who's operating your equipment and have no way of enforcing your policies or meeting your regulatory obligations. And if you authenticate over a shared network without encryption you're laying yourself open to well-known sniffing and impersonation attacks... and possibly a claim of negligence for not applying established best practice. Thus multi-user operation, as distinct from multi-client, brings with it a number of additional requirements on the software. As does the single-user, multiple-station scenario. * Like everything else on the Net, IMHO, authentication and access control is best implemented end-to-end. I wasn't suggesting that Stationserver somehow act as a control operator or set policy for any station, if that's what you feared. Stationserver is just software. It can't hold a license and it can't own property. I'll admit that I'm not real familiar with D-STAR, as I'm personally not at all interested in proprietary (or quasi-proprietary, for that matter) protocols in ham radio. I know there are folks who are intensely focused on challenging D-STAR, but that's not really my thing, nor do I understand it to be a particular goal of Stationserver. Although if it helps I have no objection in principle... ;-) - Art * To some extent this is another one of those processor-centric- vs network-centric-view issues I mentioned in an earlier thread. Currently hamlib is inherently processor-centric, and so authentication is implied in physical control of the processor. Once we attempt a networked client-server or multi-tier implementation new challenges start to arise that we haven't had to face before. It's just the price of admission to the networked world. |
From: John D. H. <jo...@ha...> - 2014-03-07 17:46:05
|
> > > Message: 2 > Date: Fri, 7 Mar 2014 08:30:17 -0800 > From: Art Botterell <ac...@in...> > Subject: Re: [Hamlib-stationserver] Terminology > To: ham...@li... > Message-ID: <CCF...@in...> > Content-Type: text/plain; charset="us-ascii" > > 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. > > There is value in placing some privilege/permission requirements on users. For example, you may have multiple "listeners" and/or observers of one radio object. Code can manage the "speaker" (one who is transmitting) while permitting others to listen and observe changing operating parameters. A mechanism should exist in the server code to authenticate, authorize, and permission clients. Permissions should be at the action/event level. E.g. client 'A' should receive events 1 (rssi), 2 (ber), and 3 (received traffic) and perform no actions, while client 'B' has all of the events plus actions 1 (ptt), 2 (transmitted traffic), and 3 (power up/down). > 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. > > The architecture should be robust and perhaps support multiple tiers. I envision the architecture supporting multiple radio (and accessory) objects. Those objects should be abstractions and applied to different physical devices. A collection of objects can then form a master control console for a station (or network of stations) with relatively simple plug-in inclusion. > > 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? > > DO NOT GO DOWN THIS PATH! It is the station operator's responsibility to meet the legal requirements of the jurisdiction governing their operation. Putting such responsibility on the software is both limiting and a mistake. Icom's D-STAR gateway / trust system attempts this, and what is legal and proper in one country is not in another. It is a bit of a mess (somewhat resolved by open source gateways using ircDDB). Provide the tools, but leave the policy to the station owner. Provide security, logging, and audit hooks but don't define or require their application. > - Art KD6O > ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays> > |
From: Art B. <ac...@in...> - 2014-03-07 17:25:48
|
On Mar 7, 2014, at 8:58 AM, Nate Bargmann <n0...@n0...> wrote: > I want to see something well beyond the limitations of Hamlib, so please > continue proposing. For the moment I'll confess I'm feeling a bit proposed-out. Maybe there are other folks on the list who have constructive suggestions? - Art KD6O |
From: Nate B. <n0...@n0...> - 2014-03-07 16:58:54
|
* On 2014 07 Mar 10:42 -0600, Art Botterell wrote: > On Mar 7, 2014, at 4:09 AM, Nate Bargmann <n0...@n0...> wrote > > I will note that there will be requests for certain device specific > > readings/settings and provision will need to be made for that. > > Right... those are the CONTROL and READING objects down at the bottom, > which in addition to their use inside higher-level device definitions > could be instantiated independently to access whatever gizmos a > particular station has on offer. I didn't wish to assume. :-) > This is a bit of a slippery slope, of course. If we think station > users are going to insist on mapping their particular rig's physical > UI literally to the network view, we might as well call it a day on > abstraction and simply slap a web-service facade on each of the hamlib > back-ends. Ha! So true. I understand this issue fairly well. There is a lightly documented "feature" of the control daemons that allows a raw CAT command to be passed through to the backend. As the control daemons share the same parsing code as the test utilities, this exposure is just part of the deal. If a program knows that it is dealing with a specific device/model it could issue raw commands through this path and parse the raw data it receives. I am not sure if that is such a grand idea to carry forward as it certainly destroys abstraction. However, it seems to allow limiting the abstraction and forcing rare/unique features to be supported in a primitive manner. > And if we're only concerned with the single-user application that > might well be the case. The benefits of abstraction come when folks > try to operate equipment they aren't familiar with in detail... > "interoperability" at the User level. I want to see something well beyond the limitations of Hamlib, so please continue proposing. We may want to also consider feature priorities to enable a development roadmap of sorts. 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:41:41
|
On Mar 7, 2014, at 4:09 AM, Nate Bargmann <n0...@n0...> wrote > I will note that there > will be requests for certain device specific readings/settings and > provision will need to be made for that. Right... those are the CONTROL and READING objects down at the bottom, which in addition to their use inside higher-level device definitions could be instantiated independently to access whatever gizmos a particular station has on offer. This is a bit of a slippery slope, of course. If we think station users are going to insist on mapping their particular rig's physical UI literally to the network view, we might as well call it a day on abstraction and simply slap a web-service facade on each of the hamlib back-ends. And if we're only concerned with the single-user application that might well be the case. The benefits of abstraction come when folks try to operate equipment they aren't familiar with in detail... "interoperability" at the User level. - Art KD6O |
From: Art B. <ac...@in...> - 2014-03-07 16:30:29
|
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. |