hamlib-stationserver Mailing List for Ham Radio Control Libraries (Page 3)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Just sketching some ideas... thought I'd share this and make sure I'm on the same page as everyone else... - Art

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).
> 

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

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.  

So... here for discussion is a first, top-level and partial, draft for discussion of what logical objects we'll need to support in StationServer:

------------------------------
Domain Object Outline for “StationServer”
Draft for Discussion #1, 5 March 2014

Outline structure describes composition (“has a”) relationships.  ALL CAPS indicates an inheritance (“is a”) relationship.  “*” indicates that multiple instances may be present

STATION (defined as all equipment controlled by a single StationServer)

	* Power Source
		Voltage READING
		Current READING
		Max. Current (configuration constant)
		Name

	* Receiver
		Power Source (reference)
		* Frequency Range (configuration constants)
		Preamp
		RF Gain (Value CONTROL)
		Frequency
			Center, Carrier or slave to Mode setting (Select CONTROL)
			Value (Value CONTROL / READING)
		Mode / Modem
			Selection (Select CONTROL / READING)
			(various mode-specific controls and readings)
		* Filter (each has various controls and readings)
			Bandwidth
			Passband
			Roofing
			Notch
			Noise Blanker
			Digital Noise Reduction
			Audio Equalizer (Vector CONTROL)
		* Content Output Channel
			Audio
			Video
			Data
			Subchannel 
				(various readings for CTCSS, DCS, DV ID Text, etc.)
			Spectrum View
				Bandwidth (Value CONTROL)
				Dimension (Value CONTROL)
				Data (Vector READING)
		S-Meter (Value READING)
		Squelch Level (Value CONTROL)
		* RX-Inhibited-By (typically a reference to a Transmitter)
		Antenna Selection 
			(Select CONTROL / READING)
		Name

	* Transmitter
		Power Source (reference)
		Frequency
		Mode / Modem (various mode-specific controls and readings)
		Speech Processor
		* Content Input Channel
			Audio
			Video
			Data
			Subchannel 
				(various settings for CTCSS, DCS, DV ID Text, etc.)
		Transmit / PTT (Toggle CONTROL)
		VOX 
			On/Off
			Level
			Anti-VOX Level
			Delay
		RF Power Level (Value CONTROL)
		Power Amplifier
		Antenna Tuner
		Antenna Selection
		Name

	*  Antenna
		Description
		Name

	* Rotator
		Associated Antennas (references)
		Azimuth
		Elevation
		Name

	* Other Devices
		Readings
		Controls
		Name

....................................
Generic Classes
Outline structure describes subclasses (inheritance) except that items in parentheses are components.  (All object instances get unique names.)

CONTROL
	Trigger
	Toggle
	Select
		(List of legal values)
	Value
		(Range of legal values)
	Vector
		(Dimension / Number of Elements)
		(Range of possible values)

READING
	Event Signal
	Flag 
	Selection
		(List of possible values)
	Value
		(Range of possible values)
	Vector
		(Dimension / Number of Elements)
		(Range of possible values)
	Reference
		(Name of referenced object)

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
> 

* On 2014 05 Mar 01:39 -0600, Ian Wade, G3NRW wrote:
> See the #DD2 and #DD3 commands on the last page.

Thanks, Ian, for the additional data 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

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

Indeed, Ian, that's exactly what I was thinking about.  Thanks!

- Art

On Mar 4, 2014, at 11:37 PM, Ian Wade, G3NRW <g3n...@nt...> wrote:

> Described in the "TS-990S PC Control Command Reference" manual:
> 
> <http://www.kenwood.com/i/products/info/amateur/pdf/ts_990_pc_command_e.p
> df>
> 
> See the #DD2 and #DD3 commands on the last page.
> 
> -- 
> 73
> Ian, G3NRW
> 

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

------- Original Message -------
From:  Nate Bargmann <n0...@n0...>
Date:  Tue, 4 Mar 2014  20:26:48

>* On 2014 04 Mar 15:36 -0600, Art Botterell wrote:
>> 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.
>

Nate/Art

This capability is here already, in the Kenwood TS-990S.

Described in the "TS-990S PC Control Command Reference" manual:

<http://www.kenwood.com/i/products/info/amateur/pdf/ts_990_pc_command_e.p
df>

See the #DD2 and #DD3 commands on the last page.

-- 
73
Ian, G3NRW

The TS-990S Resources Page:
   http://homepage.ntlworld.com/wadei/ts-990.htm

* 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

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

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

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.)

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

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.")

On 5/03/2014 8:01 AM, Art Botterell wrote:
> True that!  It's somewhat easier on the network, as network interfaces tend to support messages/events better than the internal APIs of many languages and OSs
>
> - Art
Yes, makes sense, since networks are supposed to exchange all sorts of 
information from multiple sources, so the interfaces would have been 
designed early on to allow handling of multiple messages/events.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

True that!  It's somewhat easier on the network, as network interfaces tend to support messages/events better than the internal APIs of many languages and OSs

- Art

On Mar 4, 2014, at 12:55 PM, Tony Langdon <vk...@gm...> wrote:

> On 5/03/2014 7:33 AM, Art Botterell wrote:
>> Got it... multiple simultaneous clients for control, content or both.  I'll add that.
> Yep.  The current situation with rig control brings back nasty memories 
> of DOS networking, and attempting to use the same network interface from 
> multiple applications simultaneously (under DESQview).  And even with 
> the shim that was supposed to make it work, it was about as stable as a 
> house of cards in a hurricane. :) Also brings back memories of Wordstar 
> and Word Perfect in DOS, where the application had to have its own 
> driver for the printer (like today's control applications have to 
> support the radio, rather than using an abstraction).
> 
> Upgrading to OS/2 20 years ago, and later Linux and Windows was a breath 
> of fresh air, on this front (though Windows had many other issues that 
> took longer to be addressed).
> 
> -- 
> 73 de Tony VK3JED/VK3IRL
> http://vkradio.com
> 
> 
> ------------------------------------------------------------------------------
> 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

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

On 5/03/2014 7:33 AM, Art Botterell wrote:
> Got it... multiple simultaneous clients for control, content or both.  I'll add that.
Yep.  The current situation with rig control brings back nasty memories 
of DOS networking, and attempting to use the same network interface from 
multiple applications simultaneously (under DESQview).  And even with 
the shim that was supposed to make it work, it was about as stable as a 
house of cards in a hurricane. :) Also brings back memories of Wordstar 
and Word Perfect in DOS, where the application had to have its own 
driver for the printer (like today's control applications have to 
support the radio, rather than using an abstraction).

Upgrading to OS/2 20 years ago, and later Linux and Windows was a breath 
of fresh air, on this front (though Windows had many other issues that 
took longer to be addressed).

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

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

Got it... multiple simultaneous clients for control, content or both.  I'll add that.

- Art

On Mar 3, 2014, at 8:57 PM, Tony Langdon <vk...@gm...> wrote:

> On 4/03/2014 12:48 PM, Art Botterell wrote:
>> Thanks, Tony, lot's to chew on, there.  Hope you don't mind if I tease out some individual threads.
>> 
>> For starters... I'm not sure I totally grasp what you have in mind about "sharing of a radio between multiple applications."  Do you mean multiple clients, or multiple server threads, or something else?
>> 
>> Could you help me with an example of what you mean?
> Multiple clients - for example, I may have dl-fldigi decoding telemetry 
> on the shack PC, but am sitting in another room with HRD keeping an eye 
> on the VFO frequency, or even another copy of fldigi, to keep an eye on 
> the waterfall and making sure it's centred.
> 
> Or I might have a remote base module loaded, and want to locally take 
> over the radio, while remote base users are free to log in and listen.
> 
> RMS Express is another good example.  As it stands, it's good in that 
> when you close a session, it returns the VFO back to where it was, but 
> with applications able to share, RMS Express could go further...  When 
> you start the session, it still remembers the previous VFO frequency, 
> but then it takes exclusive control of the radio, runs a mail session 
> and when you end, returns the VFO and releases exclusive control, 
> without having to unload anything else.
> 
> Could also make things easier for the ALE operators who also run a 
> WINMOR based BBS.  How this works normally is you send a text to the BBS 
> on ALE then start a RMS Express session, but I think you have to jump 
> through some hoops to make it work with current architectures. With the 
> radio server, it should be a breeze.
> 
> Trying to avoid the having to unload one application to load another 
> scenario, which becomes a real pain when dealing with multiple machines :)
> 
> -- 
> 73 de Tony VK3JED/VK3IRL
> http://vkradio.com
> 
> 
> ------------------------------------------------------------------------------
> 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

* On 2014 03 Mar 22:25 -0600, 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.
> 
> 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.

I like these perspectives, Art.

I can see them clearly now, thanks.  Hamlib the library is of the
processor-centric perspective and the control daemons were a baby step
into the network-centric perspective.  It may be of interest that my
"day" job is telecom so those terms are just as familiar to me and why
I've thought for a long time that network-centric is the better way to
proceed.

> 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

Very good.  Defined interfaces and modularity are the hallmarks of sound
design, IMO.

> 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!

This is clearly thought out well beyond any consideration I gave to any
of this and that is a good thing.  I think the "freedom to adapt as
technology and user perspectives evolve over time" is going to be a
critical component of this project moving forward.

Looking very good, guys.

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

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

On 4/03/2014 12:48 PM, Art Botterell wrote:
> Thanks, Tony, lot's to chew on, there.  Hope you don't mind if I tease out some individual threads.
>
> For starters... I'm not sure I totally grasp what you have in mind about "sharing of a radio between multiple applications."  Do you mean multiple clients, or multiple server threads, or something else?
>
> Could you help me with an example of what you mean?
Multiple clients - for example, I may have dl-fldigi decoding telemetry 
on the shack PC, but am sitting in another room with HRD keeping an eye 
on the VFO frequency, or even another copy of fldigi, to keep an eye on 
the waterfall and making sure it's centred.

Or I might have a remote base module loaded, and want to locally take 
over the radio, while remote base users are free to log in and listen.

RMS Express is another good example.  As it stands, it's good in that 
when you close a session, it returns the VFO back to where it was, but 
with applications able to share, RMS Express could go further...  When 
you start the session, it still remembers the previous VFO frequency, 
but then it takes exclusive control of the radio, runs a mail session 
and when you end, returns the VFO and releases exclusive control, 
without having to unload anything else.

Could also make things easier for the ALE operators who also run a 
WINMOR based BBS.  How this works normally is you send a text to the BBS 
on ALE then start a RMS Express session, but I think you have to jump 
through some hoops to make it work with current architectures. With the 
radio server, it should be a breeze.

Trying to avoid the having to unload one application to load another 
scenario, which becomes a real pain when dealing with multiple machines :)

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

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)

hamlib-stationserver Mailing List for Ham Radio Control Libraries (Page 3)

Library to control radio transceivers and receivers

hamlib-stationserver — Discussion of station server a possible successor to rigctld/rotctld