Thread: [Hamlib-stationserver] [with attachment] A very preliminary requirements draft for discussion
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-stationserver
|
From: Art B. <ac...@in...> - 2014-03-03 21:13:43
Attachments:
StationServer Requirements DRAFT 1.pdf
|
Friends - Here's a very rudimentary requirement document, mainly to illustrate the form. For now I'm hoping the list is configured to allow attachments. However we probably should start a file repository ASAP. Nate, can that be done on SourceForge? I've formatted this as a document so we can assert the CC license right from the start. And I've made it PDF deliberately in order to discourage direct editing and the sort of confusion that can result from premature "redlining." Instead, my recommendation would be that we discuss needed changes point-by-point in email and then roll our conclusions into an updated document occasionally (say, weekly, or maybe even faster at first.) That way we can control crosstalk among distinct issues and keep a record in the archive not just of the changes but also of the rationale for them. That will become important later as new folks join the conversation, as they'll be able to review prior debate offline and (hopefully) only add new perspectives rather than going over old ground. Of course we don't need to get the requirements anywhere near perfect, IMHO, and we'll surely revisit them from time to time, but I've found it's really helpful to have a touchstone to which we can refer to make sure we're still draining the same swamp. 73, and big ups to Nate for bringing this together! - Art |
|
From: Nate B. <n0...@n0...> - 2014-03-03 21:39:57
|
I've uploaded the document to: https://sourceforge.net/projects/hamlib/files/stationserver/documents/requirements/ 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-03 21:42:50
|
Thanks. We should probably pause briefly to see who accretes to the list... but in the meantime, I'd very much appreciate some help in the Background section. Without being hypercritical I'm thinking it might be useful to highlight some of the things we'd like to improve over the status quo, and that's really not my area of expertise. - Art On Mar 3, 2014, at 1:39 PM, Nate Bargmann <n0...@n0...> wrote: > I've uploaded the document to: > > https://sourceforge.net/projects/hamlib/files/stationserver/documents/requirements/ > > 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 > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Hamlib-stationserver mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-stationserver |
|
From: Tony L. <vk...@gm...> - 2014-03-03 21:50:02
|
On 4/03/2014 8:42 AM, Art Botterell wrote: > Thanks. We should probably pause briefly to see who accretes to the list... but in the meantime, I'd very much appreciate some help in the Background section. > > Without being hypercritical I'm thinking it might be useful to highlight some of the things we'd like to improve over the status quo, and that's really not my area of expertise. I can help with this big picture/wishlist stuff Art, since I'm one of those who raised this. :) I've only just joined the list, so have missed the discussion. Will take a peek in the archives. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Art B. <ac...@in...> - 2014-03-03 22:54:05
|
Started some very preliminary doodle of the object models, and looking at the rigctld man page it occured to me that a number of the commands are really pass-throughs of legacy UI mechanisms. E.g., there are a variety of options for RIT (and XIT), split and repeater shift... all of which are really just ways of making the transmit and receive frequencies different according to various rig interfaces and technology legacies. Seems like it might be cleaner to abstract all that out and simply model each receiver and each transmitter as having independent frequency and other settings that might or might not happen to be the same at any point in time. Which might require adding some rig-specific shims to order up the required configuration in language each particular rig understands... and of course, familiar mechanisms such as RIT, split or shift could be reproduced in client UIs as folks desire. But I'm thinking what we're really after is a universal abstraction layer... or at least as universal as we can make it... rather than just passing through every CAT command there might be. However I suspect this isn't a new dilemma, so I'd appreciate any background or insight anyone can offer. Thanks! - Art Also, I'm not seeing a lot of support for control of various filtering options. As that's been a competitive feature among rig vendors it may be another area where we have to decide whether to abstract or accept various proprietary styles. |
|
From: Tony L. <vk...@gm...> - 2014-03-04 00:21:54
|
On 4/03/2014 9:53 AM, Art Botterell wrote: > Started some very preliminary doodle of the object models, and looking at the rigctld man page it occured to me that a number of the commands are really pass-throughs of legacy UI mechanisms. > > E.g., there are a variety of options for RIT (and XIT), split and repeater shift... all of which are really just ways of making the transmit and receive frequencies different according to various rig interfaces and technology legacies. > > Seems like it might be cleaner to abstract all that out and simply model each receiver and each transmitter as having independent frequency and other settings that might or might not happen to be the same at any point in time. I like this Art. Certainly for split, VFO A/B, etc, all these could be handled in one API. We could try doing repeater shift the same way, and only use shims where necessary. > > Which might require adding some rig-specific shims to order up the required configuration in language each particular rig understands... and of course, familiar mechanisms such as RIT, split or shift could be reproduced in client UIs as folks desire. But I'm thinking what we're really after is a universal abstraction layer... or at least as universal as we can make it... rather than just passing through every CAT command there might be. Agree totally. The only thing the clients should know about the connected radios is the capabilities. For example, the client needs to know I can't dial up 14.200 MHz on my FT-736R, or 1296.100 on the IC-7000 (it should get an error if I attempt to do these things), but it doesn't need to know how I implement repeater shift, RIT, XIT, etc. It just needs to request these functions and let the server work it out, since the server has the information it needs to best communicate with and configure the radios. > > However I suspect this isn't a new dilemma, so I'd appreciate any background or insight anyone can offer. > > Thanks! > > - Art > > Also, I'm not seeing a lot of support for control of various filtering options. As that's been a competitive feature among rig vendors it may be another area where we have to decide whether to abstract or accept various proprietary styles. Might need a bit of research to determine the best approach. The IC-7000 brings out 3 bandwidth settings (called 1, 2 and 3, with 1 being the widest), but these in turn can be configured elsewhere in the menus. Also need to handle errors for radios that report errors when trying to select nonexistent filters (or be able to configure this capability in the driver setup - nonexistent filters could cause confusion for remote base users). I have no idea what other radios do. I'm for abstraction where possible, and only going proprietary where there's no viable alternative. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Nate B. <n0...@n0...> - 2014-03-04 03:13:24
|
* On 2014 03 Mar 16:54 -0600, Art Botterell wrote: > Started some very preliminary doodle of the object models, and looking > at the rigctld man page it occured to me that a number of the commands > are really pass-throughs of legacy UI mechanisms. > > E.g., there are a variety of options for RIT (and XIT), split and > repeater shift... all of which are really just ways of making the > transmit and receive frequencies different according to various rig > interfaces and technology legacies. There is a, as we call it, a "virtual rig" sort of abstraction to the Hamlib C language API, although this is poorly reflected by rigctld/rotctld (from now on I'll refer to them as the "control daemons") which are essentially a "flat" command namespace. Unfortunately, there is no document available that outlines this abstraction. Each programmer using Hamlib's C API has had to figure it out, often by reading the header and or source files. Certainly, any willing backend contributor has had to do the same. This has greatly limited Hamlib's currency with new rigs. Also, Hamlib's virtual rig only supports three VFOs, A-C, for example, which are certainly far too limiting for the modern rigs coming down the pike. Originally, the goal was to support all features of available rigs in the virtual rig interface. In 2000 when the project went public this probably seemed like an attainable goal. Today, not so much as it is just not practical, IMO, to try and include the unique features of every model. > Seems like it might be cleaner to abstract all that out and simply > model each receiver and each transmitter as having independent > frequency and other settings that might or might not happen to be the > same at any point in time. > > Which might require adding some rig-specific shims to order up the > required configuration in language each particular rig understands... > and of course, familiar mechanisms such as RIT, split or shift could > be reproduced in client UIs as folks desire. But I'm thinking what > we're really after is a universal abstraction layer... or at least as > universal as we can make it... rather than just passing through every > CAT command there might be. > > However I suspect this isn't a new dilemma, so I'd appreciate any > background or insight anyone can offer. Perhaps one question would be, how should a radio "look" to a calling application? By that I mean that it may not "look" much like a radio at all. My reading of Hamlib over the years has led me to understand that its API tended to mirror the way we humans approach a radio. We have knobs and buttons and the API reflects that through C functions that mimic our interaction with the actual radio. At first glance it makes sense, but does it make any more sense than the earliest GUI programs that were often patterned after a generic transceiver front panel? Quite likely not. A different paradigm now exists for the UI for rig control so perhaps as well, a new paradigm should be developed for the way we control it via software. I look forward to seeing the ideas here. > Also, I'm not seeing a lot of support for control of various filtering > options. As that's been a competitive feature among rig vendors it > may be another area where we have to decide whether to abstract or > accept various proprietary styles. Hamlib supports filter selection as part of setting the mode. If a new bandwidth is desired the mode is set with the new bandwidth. It is up to the backend to work out the details between the virtual rig and the hardware. My explanations of Hamlib's implementation are for the collective reference and not to tilt the discussion one way or the other. 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-04 04:23:47
|
Thanks, Nate.
If I may make a general observation: There are two common perspectives on a project like this, in my experience. They're both valid and they're so similar that sometimes folks miss the subtle difference between them and wind up talking past each other. I call those two approaches the "processor-centric" and the "network-centric" views.
The processor-centric view, as the name suggests, puts a computer in the middle of the mental model. This is typically how software folks view problems. The term "API" is a often a signature of the processor-centric perspective.
Telecommunications folks, OTOH, tend toward the network-centric view. They talk about "messages," "protocols" and "exchanges" and tend to see the wire (or the cloud) as the center of things and the processors as nodes... leaves on the network tree... and largely treat them as black boxes with (hopefully) standardized interfaces.
Again, both views are valid in their own domains. The trick I've had to learn is to recognize which perspective is being use at any point in time. Although I've written a fair bit of code over the years I'm a comms guy at heart and thus my personal dominant mode is net-centric.
That said...
On Mar 3, 2014, at 7:13 PM, Nate Bargmann <n0...@n0...> wrote:
> Perhaps one question would be, how should a radio "look" to a calling
> application? By that I mean that it may not "look" much like a radio at
> all.
From a net-centric view I'm thinking it should look like an instance of an abstract, Platonic-ideal model of a radio... composed of building-block components... transmitters, receivers, filters and so on... that can be assembled to describe any particular device.
The "server" is a gateway between the IP network environment and the digital controls on a radio... and a "client" is a gateway between a human (or non-human) user's inputs and the IP network that's compatible with the server's capabilities. Like a radio each is made up of internal components that are (again hopefully) highly modular.
And between those components we have a series of interfaces:
USER <=> User Interface <=> CLIENT <=> Network Interface <=> SERVER <=> Device Interface (e.g., CAT) <=> RADIO
We achieve interoperability by eliminating unique or instance-specific features of the shared network interface... but at the edge interfaces (the client UI and the radio CAT connection) we can still accommodate diversity.
Which means that client user interfaces could, at least in principle, be customized to fit whatever paradigm the user knows or prefers. E.g. a client could offer a RIT widget that looks and works just like RIT traditionally does... without necessarily implementing a literal "RIT" command on the network interface or even using that literal feature on the device interface.
In other words, taking the network interface to a higher level of abstraction doesn't mean not giving users an interface they understand. It just makes interoperability a lot easier behind the curtain and on the wire. And it gives more freedom to adapt as technology and user perspectives evolve over time.
My thought at this point, therefore, is that in the near term we'll be designing a network "facade" interface to the existing hamlib virtual rig and rig-specific backends, enabling a variety of stationserver-compatible clients to offer different UIs to different users and for different applications.
Once we've done that it may make sense to work back into the hamlib codebase and see if that can be streamlined or otherwise improved. (I'm guessing that by taking a less literal approach to the individual rig interfaces it may be possible to simplify it.) I'd expect that the individual rig interfaces would be the last thing to refactor, except in cases where there are serious shortcomings or, of course, when there are new radios to support!
- Art
|
|
From: Tony L. <vk...@gm...> - 2014-03-04 05:20:23
|
On 4/03/2014 3:23 PM, Art Botterell wrote: > Thanks, Nate. > > If I may make a general observation: There are two common perspectives on a project like this, in my experience. They're both valid and they're so similar that sometimes folks miss the subtle difference between them and wind up talking past each other. I call those two approaches the "processor-centric" and the "network-centric" views. I just see things my way. How that fits into these paradigms, I don't know. :) > > The processor-centric view, as the name suggests, puts a computer in the middle of the mental model. This is typically how software folks view problems. The term "API" is a often a signature of the processor-centric perspective. > > Telecommunications folks, OTOH, tend toward the network-centric view. They talk about "messages," "protocols" and "exchanges" and tend to see the wire (or the cloud) as the center of things and the processors as nodes... leaves on the network tree... and largely treat them as black boxes with (hopefully) standardized interfaces. Yeah, that works too, I can see opportunities to have multiple radio servers in a networked arrangement that clients just see as nodes. > >From a net-centric view I'm thinking it should look like an instance of an abstract, Platonic-ideal model of a radio... composed of building-block components... transmitters, receivers, filters and so on... that can be assembled to describe any particular device. > > The "server" is a gateway between the IP network environment and the digital controls on a radio... and a "client" is a gateway between a human (or non-human) user's inputs and the IP network that's compatible with the server's capabilities. Like a radio each is made up of internal components that are (again hopefully) highly modular. That makes sense to me, probably similar to how I see the project, though expressed differently. > > And between those components we have a series of interfaces: > > USER <=> User Interface <=> CLIENT <=> Network Interface <=> SERVER <=> Device Interface (e.g., CAT) <=> RADIO Yep, with branches off the side at both ends for things like digital modes. :) > > We achieve interoperability by eliminating unique or instance-specific features of the shared network interface... but at the edge interfaces (the client UI and the radio CAT connection) we can still accommodate diversity. > > Which means that client user interfaces could, at least in principle, be customized to fit whatever paradigm the user knows or prefers. E.g. a client could offer a RIT widget that looks and works just like RIT traditionally does... without necessarily implementing a literal "RIT" command on the network interface or even using that literal feature on the device interface. > > In other words, taking the network interface to a higher level of abstraction doesn't mean not giving users an interface they understand. It just makes interoperability a lot easier behind the curtain and on the wire. And it gives more freedom to adapt as technology and user perspectives evolve over time. That's why I like abstraction - interoperability. > > My thought at this point, therefore, is that in the near term we'll be designing a network "facade" interface to the existing hamlib virtual rig and rig-specific backends, enabling a variety of stationserver-compatible clients to offer different UIs to different users and for different applications. That's probably a good starting point, though in the long run I'd like the backends to be definitions, rather than actual code. Something non programmers can edit, with or without the help of a "radio editor" program to assist with the syntax. It would be nice to have a consistent and well documented virtual radio to work with, which would be what the clients are actually interacting with. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Art B. <ac...@in...> - 2014-03-04 20:38:21
|
On Mar 3, 2014, at 9:20 PM, Tony Langdon <vk...@gm...> wrote: > That's probably a good starting point, though in the long run I'd like > the backends to be definitions, rather than actual code. Great point. I'll add something along the lines of "wherever possible, permit user configuration of radio interfaces by means of properties tables or other easily-edited mechanisms" in the next rev. Thanks! - Art |
|
From: Tony L. <vk...@gm...> - 2014-03-04 21:00:31
|
On 5/03/2014 7:38 AM, Art Botterell wrote: > On Mar 3, 2014, at 9:20 PM, Tony Langdon <vk...@gm...> wrote: >> That's probably a good starting point, though in the long run I'd like >> the backends to be definitions, rather than actual code. > Great point. I'll add something along the lines of "wherever possible, permit user configuration of radio interfaces by means of properties tables or other easily-edited mechanisms" in the next rev. Yep. It would be good if we can use Hamlib as an interim transition mechanism, but I think it's best to have user configuration as much as possible. That said, I'm sure we will encounter new technologies that do require code to be written. How will we handle radios that are capable of having multiple simultaneous receivers, for instance? (e.g. the TAPR HPSDR software defined radios can have up to 7 receivers independently running at the same time). -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Art B. <ac...@in...> - 2014-03-04 21:36:09
|
On Mar 4, 2014, at 1:00 PM, Tony Langdon <vk...@gm...> wrote:
> How will we handle radios that are
> capable of having multiple simultaneous receivers, for instance? (e.g.
> the TAPR HPSDR software defined radios can have up to 7 receivers
> independently running at the same time).
A great question. My current thinking is to define a "device" (aka a "rig") as a black box that has a single connection to a server. Within the device there may be multiple receivers, possibly even multiple transmitters, and various other components... amplifiers of various types, filters of various types, meters and controls of various types, etc. (This is why we need the capacity to "discover" from the device its particular composition.)
Again, we get into questions of what's essential and what's just an artifact of individual product design. E.g., many rigs have memories, multiple VFOs, RIT, XIT and so on, even though in actuality each transmitter and each receiver can only be set to one operating frequency at a time. *
Thus those features strike me as expedients ("facades" in the programming sense) added to make the rig's front panel interface more convenient for the user, but don't reflect essential reality. They can reproduced on a client as desired without reproducing all the vendor-specific details end-to-end.
The essential, for each transmitter for example, is to set-and-get a frequency, a modulation mode/modem, a power level and... well, those are the ones that spring immediately to mind. Receivers are more complicated (as usual) but again, the essentials for each receiver are relatively limited in number. Given those essential parameters in the protocol and a computer at the other end we could construct as sophisticated or as simple a UI as any particular user needs. Thus the same rig might look very different to a contester than to a MARS op.
At the other extreme... many higher-end rigs and SDRs can display a spectrograph, which visualizes energy levels in intervals across a segment of the spectrum. Do any of the existing CAT interfaces make that vector of values available outside the rig? This may be an area where we'll need to innovate, not to say lead.
- Art
* (I'm neglecting spread-spectrum and other broadband modes for the moment, but it might be more precise to say "one channel at a time.")
|
|
From: Tony L. <vk...@gm...> - 2014-03-04 22:17:23
|
On 5/03/2014 8:35 AM, Art Botterell wrote:
> On Mar 4, 2014, at 1:00 PM, Tony Langdon <vk...@gm...> wrote:
>> How will we handle radios that are
>> capable of having multiple simultaneous receivers, for instance? (e.g.
>> the TAPR HPSDR software defined radios can have up to 7 receivers
>> independently running at the same time).
> A great question. My current thinking is to define a "device" (aka a "rig") as a black box that has a single connection to a server. Within the device there may be multiple receivers, possibly even multiple transmitters, and various other components... amplifiers of various types, filters of various types, meters and controls of various types, etc. (This is why we need the capacity to "discover" from the device its particular composition.)
I agree. The capabilities need to be discovered. The driver (with
maybe some manual configuration in some places) needs to be able to tell
the server what the radio can do. A "radio" could be modelled as an
entity with a transmitter (might need to allow for more, though I am not
aware of a currently available radios with more than one transmitter)
and one or more receivers (most will have one, HPSDR being one of the
few exceptions).
>
> Again, we get into questions of what's essential and what's just an artifact of individual product design. E.g., many rigs have memories, multiple VFOs, RIT, XIT and so on, even though in actuality each transmitter and each receiver can only be set to one operating frequency at a time. *
Those features are peripheral. Issues such as memories for instance are
more a "convenience" thing. Here you run into some proprietary
oddities. For example, the IC-7000 has 5 banks of 99 memories, though
this could be mapped into a "flat" space (1-499), with 4 unprogrammable
gaps (virtual memories 100, 200, 300 and 400), by the abstraction.
So what is a "radio"? It's an entity that contains:
0 or more transmitters (some receivers are controllable). Currently,
only the cases of 0 or 1 transmitters exist in the wild.
0 or more receivers (I am not aware of any transmit only controllable
radios, but 1-7 receivers are availavle today).
The case of 0/0 might seem useless, but could be a "dummy" driver to
allow testing.
Radios will have a number of properties:
1 or more "modes" - AM, FM, USB, LSB, CW, etc...
One or more receive frequency ranges. Can be a single frequency (e.g. a
repeater receiver).
One or more transmit frequency ranges. Again, can be a single frequency
(e.g. for a beacon or repeater transmitter).
A feature list - Here we specify what inbuilt features the radio has,
and how these features are mapped to the virtual radio model in the
server. Examples of features include VFOs, filters, RIT/XIT, repeater
offsets, noise reduction, noise blanker, RF gain, audio gain, ATU,
memories, etc. Also in here I would put a full duplex flag. The radio
server should be inherently full duplex, but know whether it's connected
to a full duplex capable radio. Duplex may be conditional (e.g. some
radios are only duplex when in satellite mode, others can go duplex
whenever configured to transmit and receive on different bands, some are
inherently full duplex - e.g. a repeater). The feature list in this
context is basically what the radio can be made to do by commands, and
may or may not be how the functionality is implemented by the radio
server/driver combination.
A resource list - This is the list of resources (COM ports, soundcards,
etc) used to communicate with the radio and the settings of those
resources (baud rate, data format - data bits, stop bits, parity, audio
gain settings).
A protocol - this is the definition of the command set used by the radio
to access its features. This can be as simple as toggling RTS or DTR
for PTT in the case of a fixed frequency transceiver, or it can (usually
will be) a full blown command set. This would have to be some sort of
capabilities table and would be linked to the feature set.
The combination of feature list and protocol would have an impact on how
the virtual radio in the server and the real radio interact. For
example, with my 2 main radios, the FT-736R has a very limited CAT
capability (e.g. you can't read the VFO frequency), so the virtual radio
needs to maintain the radio state and send it to the real radio as
necessary. My IC-7000, OTOH, is capable of sending its state back to
the PC, so the virtual radio has to be able to read that state
information and update its own state if the radio changes (e.g. I turn
the VFO, change bands, mode, filter settings, etc manually from the
front panel).
I'm sure you programmer types can tidy this up a bit. :)
>
> Thus those features strike me as expedients ("facades" in the programming sense) added to make the rig's front panel interface more convenient for the user, but don't reflect essential reality. They can reproduced on a client as desired without reproducing all the vendor-specific details end-to-end.
>
> The essential, for each transmitter for example, is to set-and-get a frequency, a modulation mode/modem, a power level and... well, those are the ones that spring immediately to mind. Receivers are more complicated (as usual) but again, the essentials for each receiver are relatively limited in number. Given those essential parameters in the protocol and a computer at the other end we could construct as sophisticated or as simple a UI as any particular user needs. Thus the same rig might look very different to a contester than to a MARS op.
>
> At the other extreme... many higher-end rigs and SDRs can display a spectrograph, which visualizes energy levels in intervals across a segment of the spectrum. Do any of the existing CAT interfaces make that vector of values available outside the rig? This may be an area where we'll need to innovate, not to say lead.
Spectrographs are also going to be something that need to be handled
when considering encoding data modes as data rather than audio (waaaay
off in the future). :)
>
> - Art
>
> * (I'm neglecting spread-spectrum and other broadband modes for the moment, but it might be more precise to say "one channel at a time.")
Yep.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
|
|
From: Art B. <ac...@in...> - 2014-03-04 22:47:53
|
OK, so... starting at the level of an individual Rig as we generally use the term... or perhaps more precisely, as something that has a single CAT interface... what are its essential components and attributes? So far I have: 0-n Transmitters (to be detailed in a separate thread) 0-n Receivers (ditto) o-n Power Source (selector for active source, may have pointer to external PS meters or controls) Physical location (optional?) Flag: Duplex capable yes/no Reference Name Owner Profile (this is the data structure that describe the particular Rig in terms of the above) What else? - Art PS - I'm thinking we may need a multi-level namespace or "breadcrumb" naming scheme, e.g., "KD6O_Home:IC7200:DC_Supply:Voltage_Meter" (where "KD6O_Home" is actually one level up from Rig at the Station level.) |
|
From: Tony L. <vk...@gm...> - 2014-03-04 23:23:17
|
On 5/03/2014 9:47 AM, Art Botterell wrote: > OK, so... starting at the level of an individual Rig as we generally use the term... or perhaps more precisely, as something that has a single CAT interface... what are its essential components and attributes? > > So far I have: > > 0-n Transmitters (to be detailed in a separate thread) > 0-n Receivers (ditto) > o-n Power Source (selector for active source, may have pointer to external PS meters or controls) > Physical location (optional?) > Flag: Duplex capable yes/no Add conditional to this. > Reference Name > Owner > Profile (this is the data structure that describe the particular Rig in terms of the above) > > What else? > > - Art That seems to be a good starting point. More will come to mind as we flesh it out. > > PS - I'm thinking we may need a multi-level namespace or "breadcrumb" naming scheme, e.g., "KD6O_Home:IC7200:DC_Supply:Voltage_Meter" (where "KD6O_Home" is actually one level up from Rig at the Station level.) That might work. :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Tony L. <vk...@gm...> - 2014-03-04 23:32:14
|
On 5/03/2014 9:47 AM, Art Botterell wrote: > PS - I'm thinking we may need a multi-level namespace or "breadcrumb" naming scheme, e.g., "KD6O_Home:IC7200:DC_Supply:Voltage_Meter" (where "KD6O_Home" is actually one level up from Rig at the Station level.) This really allows a network centric view, though at the radio server level, I don't envisage multi-site use, unless you have a VPN. That said, there is no reason why a remote-shack module (providing audio compression, protocol optimisation for WAN links and enhanced security, at the cost of slightly increased latency) couldn't be implemented to link shacks at multiple sites. I like the idea of a multi-level scheme. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Nate B. <n0...@n0...> - 2014-03-05 02:26:57
|
* On 2014 04 Mar 15:36 -0600, Art Botterell wrote:
> On Mar 4, 2014, at 1:00 PM, Tony Langdon <vk...@gm...> wrote:
> > How will we handle radios that are capable of having multiple
> > simultaneous receivers, for instance? (e.g. the TAPR HPSDR software
> > defined radios can have up to 7 receivers independently running at
> > the same time).
>
> A great question. My current thinking is to define a "device" (aka a
> "rig") as a black box that has a single connection to a server.
> Within the device there may be multiple receivers, possibly even
> multiple transmitters, and various other components... amplifiers of
> various types, filters of various types, meters and controls of
> various types, etc. (This is why we need the capacity to "discover"
> from the device its particular composition.)
The manufacturers are throwing new wrinkles at us all the time. I
learned earlier this year that the FT-950 has a command to control at
least one of the Yaesu rotor models. Hamlib has entirely separate code
paths for radios and rotors and not easily resolved. On a related note,
Elecraft has the K-line which consists of the K3 transceiver, P3
panadapter, KAT500 auto tuner, and KPA500 amplifier all of which can be
daisy-chained to a single RS-232 port and they handle receiving commands
between the devices.
At the rate things are going, the server will need to expect any sort of
device on a physical port and multiple devices of differing sorts as the
K-line above.
> Again, we get into questions of what's essential and what's just an
> artifact of individual product design. E.g., many rigs have memories,
> multiple VFOs, RIT, XIT and so on, even though in actuality each
> transmitter and each receiver can only be set to one operating
> frequency at a time. *
Case in point, up through version 1.2.15.3 Hamlib assumes that when the
RIT or XIT is set to 0 Hz that the intention is to disable the RIT/XIT
function. Sounds good in theory, but one developer of a downstream
contest logger wants to have his program clear the RIT on his K3 while
leaving the RIT activated so he can manually adjust it when needed on
some future QSO. I was able to give him a specific work-around for the
K3 and then implemented a more general solution for the dummy and k3
banckends in anticipation of Hamlib 3.0, but haven't gotten motivated to
tackle the other backends. Sigh.
At the time it was probably a reasonable assumption to do it that way.
I guess I shouldn't be bogging this discussion down with war stories...
> Thus those features strike me as expedients ("facades" in the
> programming sense) added to make the rig's front panel interface more
> convenient for the user, but don't reflect essential reality. They
> can reproduced on a client as desired without reproducing all the
> vendor-specific details end-to-end.
>
> The essential, for each transmitter for example, is to set-and-get a
> frequency, a modulation mode/modem, a power level and... well, those
> are the ones that spring immediately to mind. Receivers are more
> complicated (as usual) but again, the essentials for each receiver are
> relatively limited in number. Given those essential parameters in the
> protocol and a computer at the other end we could construct as
> sophisticated or as simple a UI as any particular user needs. Thus
> the same rig might look very different to a contester than to a MARS
> op.
>
> At the other extreme... many higher-end rigs and SDRs can display a
> spectrograph, which visualizes energy levels in intervals across a
> segment of the spectrum. Do any of the existing CAT interfaces make
> that vector of values available outside the rig? This may be an area
> where we'll need to innovate, not to say lead.
Not that I have seen, but I have not done an exhaustive review of all of
the commands available. The few that I am aware of treat the control
channel as separate from the information channel but this too is bound
to change at some point.
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-05 07:44:46
|
On Mar 4, 2014, at 6:26 PM, Nate Bargmann <n0...@n0...> wrote: > On a related note, > Elecraft has the K-line which consists of the K3 transceiver, P3 > panadapter, KAT500 auto tuner, and KPA500 amplifier all of which can be > daisy-chained to a single RS-232 port and they handle receiving commands > between the devices. Marine electronics vendors have been doing the same thing for awhile, creating proprietary data busses to link their radars, depthfinders, and so on. (DECnet / Corvus Servers, anyone?) > At the rate things are going, the server will need to expect any sort of > device on a physical port and multiple devices of differing sorts as the > K-line above. Hmmm... yes, the Rig level of abstraction may become less meaningful than it used to be. It may make more sense to model in terms of a Station as a collection of functional components accessible via a single server. Thanks! - Art |
|
From: Tony L. <vk...@gm...> - 2014-03-05 08:26:51
|
On 5/03/2014 6:44 PM, Art Botterell wrote: > Hmmm... yes, the Rig level of abstraction may become less meaningful than it used to be. It may make more sense to model in terms of a Station as a collection of functional components accessible via a single server. Good point! However, physically, tuners are connected to radios, unless you use switches or re-patch cables, so the abstration (mostly) holds, in that the rig has a tuner and/or rotator attached, the question being whether the command path is via the radio (like with the new equipment in the examples given) or direct to the peripheral. And that could be done with the drivers - radios with the ability to control peripherals via CAT could expose these control pathways in their drivers. These would appear as an instance of the peripheral, associated with the radio. A separate peripheral would use a separate control path, but still be associated with a radio, though in this case, the association can be changed. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Art B. <ac...@in...> - 2014-03-05 17:37:15
|
Great observation, Tony! There are challenges of multiplicity at both ends... multiple "rigs" requiring multiple device interfaces from the server, but logically linked (e.g., a linear that's physically separate but logically part of the transmit chain)... and also devices that are shared by multiple other devices (e.g., a rotor that swings multiple antennas at once, or a shared power source.) Personally I'd recommend that the network view encapsulate any physical details of station wiring that don't actually affect user capabilities. One way to do that might be to have a table-driven configuration layer in the server between the network interface and the individual rig-specific (hamlib) drivers. That layer would route commands and readouts between the logical model of the station as presented to the network and the actual physical configuration of the station. - Art KD6O On Mar 5, 2014, at 12:26 AM, Tony Langdon <vk...@gm...> wrote: > On 5/03/2014 6:44 PM, Art Botterell wrote: >> Hmmm... yes, the Rig level of abstraction may become less meaningful than it used to be. It may make more sense to model in terms of a Station as a collection of functional components accessible via a single server. > Good point! However, physically, tuners are connected to radios, unless > you use switches or re-patch cables, so the abstration (mostly) holds, > in that the rig has a tuner and/or rotator attached, the question being > whether the command path is via the radio (like with the new equipment > in the examples given) or direct to the peripheral. And that could be > done with the drivers - radios with the ability to control peripherals > via CAT could expose these control pathways in their drivers. These > would appear as an instance of the peripheral, associated with the > radio. A separate peripheral would use a separate control path, but > still be associated with a radio, though in this case, the association > can be changed. > > -- > 73 de Tony VK3JED/VK3IRL > http://vkradio.com > |
|
From: Tony L. <vk...@gm...> - 2014-03-05 22:06:40
|
On 6/03/2014 7:05 AM, Art Botterell wrote: > OK, we're starting to get into the tall grass now... not complicated, really, just a lot of detail. And an outline isn't really adequate to describe all the details. Still, before we start drawing UML diagrams maybe we can do an initial scope-check. Somewhere you need to add an output gain for the radio's audio channel (whether audio is used directly or not) - some radios support this (e.g. IC-7000). Similarly, some radios have support for adjusting the "mic gain" (i.e. input gain of the signal path). In the model you've outlined, this is not always in the content path, since this affects the AF signal level in the system, and this AF could be either content (when using analogue voice modes - AM, FM, SSB) or a very low frequency IF (when using data, image and DV modes). -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Art B. <ac...@in...> - 2014-03-05 22:22:26
|
Just so, Tony. I was thinking that each of the input and output channels would have controls such as gain, as appropriate to their content. - Art On Mar 5, 2014, at 2:06 PM, Tony Langdon <vk...@gm...> wrote: > Somewhere you need to add an output gain for the radio's audio channel > (whether audio is used directly or not) - some radios support this (e.g. > IC-7000). Similarly, some radios have support for adjusting the "mic > gain" (i.e. input gain of the signal path). > |
|
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: 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 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 |
×
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