Re: [Hamlib-stationserver] Philosophy: Abstraction vs Rig Interface Artifacts
Library to control radio transceivers and receivers
Brought to you by:
n0nb
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 > |