Thread: Re: [Hamlib-stationserver] Domain Object Outline: What's in a Station? (Page 2)

Library to control radio transceivers and receivers

Brought to you by: n0nb

hamlib-stationserver

Re: [Hamlib-stationserver] Domain Object Outline: What's in a Station?

From: Greg T. <gd...@le...> - 2014-03-08 15:04:44

Nate Bargmann <n0...@n0...> writes:

> Ha!  So true.  I understand this issue fairly well.  There is a lightly
> documented "feature" of the control daemons that allows a raw CAT
> command to be passed through to the backend.  As the control daemons
> share the same parsing code as the test utilities, this exposure is just
> part of the deal.  If a program knows that it is dealing with a specific
> device/model it could issue raw commands through this path and parse the
> raw data it receives.

I guess a big question is the purpose.   I see multiple purposes for rig
control software:

  generic use, where a program (logger, fldigi, etc.) wants to control a
  radio in frequency, maybe filtering widths, or maybe just read
  frequency.  Here the point is to hide the radio's details so that the
  program works with any radio (that's adequately capable)

  implementing a GUI front panel replacement where there are controls
  for everything on the radio.  I don't find this super interesting
  except for remote operation.

  writing test equipment, likely for a specific radio, to do RF noise
  level surveys, etc.

But all of these seem to apply to hamlib and perhaps the rigctld
language, independently of stationserver.  Some things can be made
common, and that's great, but the details will always differ.

So I see stationserver adding access control, multiple radios, and
perhaps (big if) multiple computers federated.

Am I totally missing the point?

Re: [Hamlib-stationserver] Domain Object Outline: What's in a Station?

From: Art B. <ac...@in...> - 2014-03-09 04:36:38

Great thoughts, Greg!  Comments below.

On Mar 8, 2014, at 7:04 AM, Greg Troxel <gd...@le...> wrote:
> But all of these seem to apply to hamlib and perhaps the rigctld
> language, independently of stationserver.  Some things can be made
> common, and that's great, but the details will always differ.

Which has me thinking about maybe turning the abstraction issue around.  Given that rigs vary so broadly... and that time may (almostly surely will) see redefinitions of the whole notion of "rig"... perhaps the productive question isn't abstraction so much as discovery.  

In other words, might it work better to expose a collection of primitive input and output types... like the CONTROL and READING objects at the bottom of my earlier outline... along with a mechanism for each server to describe the particular set of widgets on offer to representing the attached equipment?  Perhaps in the form of a JSON or XML data structure... which might also imply the template for control commands and queries?

Seems like such an approach might allow a refactoring of the rig interfaces to be table configured rather than hard coded.  It also would provide a degree of self-documentation... perhaps including some owner-suppled free text to note station peculiarities, e.g., local interference issues, antenna patterns and such.  In any event it might avoid endless arguments about how best to abstract vendor-specific and innovative features.

Focusing on a feature-discovery mechanism might also help with the question of audio (and video and whatever) content transports.  The stationserver could simply assert the codec, rate, any other parameters and location (an IP port number, probably) for the gazinta(s) and gazoutta(s).  (Although reference implementations might help drive folks toward de-facto standardization; for audio I've been looking at www.opus-codec.org / RFC 6716 but haven't played with it yet.) 

Then we could... if we wanted to side-step the whole user/authentication issue for the time being... simply let folks use VPNs for access control if they choose to expose their systems to the Wild Wacky Web.  Or not, if they're bold...

- Art KD6O

Re: [Hamlib-stationserver] Philosophy: Abstraction vs Rig Interface Artifacts

From: Nate B. <n0...@n0...> - 2014-03-04 14:48:22

* 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

[Hamlib-stationserver] Domain Object Outline: What's in a Station?

From: Art B. <ac...@in...> - 2014-03-05 20:05:21

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)

Re: [Hamlib-stationserver] Domain Object Outline: What's in a Station?

From: Nate B. <n0...@n0...> - 2014-03-07 12:10:07

For some reason my mail program has this message threaded into a prior
thread.  Oh well.  :-)

* On 2014 05 Mar 14:07 -0600, 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.  
> 
> 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:

This looks complete enough for a good start.  I will note that there
will be requests for certain device specific readings/settings and
provision will need to be made for that.  For example, the K3 has a read
only parameter that gives the  IF center frequency which changes when
the operator uses the Shift control.  This may not seem important but I
know of at least one Hamlib client program that uses this to center an
SDR band scope display.

It seems that one cannot think of everything initially.  Sigh...

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

Re: [Hamlib-stationserver] Philosophy: Abstraction vs Rig Interface Artifacts

From: Ian W. G. <g3n...@nt...> - 2014-03-05 07:38:52

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

Re: [Hamlib-stationserver] Philosophy: Abstraction vs Rig Interface Artifacts

From: Art B. <ac...@in...> - 2014-03-05 07:46:42

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
>

Re: [Hamlib-stationserver] Philosophy: Abstraction vs Rig Interface Artifacts

From: Nate B. <n0...@n0...> - 2014-03-05 12:54:30

* 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

Re: [Hamlib-stationserver] [with attachment] A very preliminary requirements draft for discussion

From: Tony L. <vk...@gm...> - 2014-03-04 00:11:47

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.
Just took a quick look at the draft. I think we're better off kicking
it around in here before creating a document, but thanks for the stab at it.

For me, the status quo has a number of limitations:

1. Most solutions are single platform and proprietary (Hamlib is an
exception).

2. There are no solutions that allow for the sharing of a radio between
multiple applications.

3. Because of #2, there is no API for requesting exclusive control of
the radio and releasing it.

4. No integration between remote base software radio control, meaning
you can't share a remote base with local control - see #2 and #3 above
(as well as making it easier to use your own radio, could also be a
useful training and PR tool).

What I would like to see:

Having a networking background, I tend to think in layers, and this
model is relevant here.

Layer 1 - Physical. This is where the actual radio control takes
place. Here we define the ports and soundcard resources used, as well
as the control protocol between the radio and server. The physical
layer should be defined by a "driver", which requires no code (should be
a list of definitions that a relative non programmer can change or
write) in a standardised format. A tool could be written to help users
and radio tinkerers to create their own driver files. I'm thinking
something like RigCAT XML files in concept (but use what is best). The
ability to use Hamlib drivers would also be useful to help facilitate
rapid adoption, since many Hamlib drivers are fully functional. Similar
can be done for rotator control.

Layer 2 - server/abstraction. Here the specific commands sets of the
radios and rotators are abstracted into a generalised API. The server
knows (from the drivers) the capabilities of each device and is
configured with the resources (serial/audio/network/etc) that each one
uses. The API is the means by which client software communicated to the
radio(s) and rotator(s). Space should be made in the API for other
devices (amplifiers, remotely controlled switches, etc). The API is
also network aware, has minimal latency and only needs moderate
security. This API should NOT be used outside of a controlled
environment such as a single machine or a LAN. Given that it is now
2014, the radio control API should work over both IPv4 and IPv6. Also
at this level comes the ability to request exclusive use of one or more
resources, so other software accessing that resource can't inadvertently
change settings such as VFO or mode, or rotate the antenna at an
inappropriate time.

Layer 3 - Additional functionality. Here we "bolt on" additional
functionality that is not part of the core control system. This
additional functionality would be implemented in additional (possibly
and most likely third party) modules which communicate with the server
via the API. Examples of add-on modules would include:

- Remote base. This provides the functionality we are now familiar with
to share your radios over the Internet. The remote base module would
incorporate the functions specifically needed for remote base operation,
such as enhanced security, user authentication and validation, audio
compression, etc. Astute readers will notice that the remote base can
be overridden by local access controls at the server level, in case you
want to use your radio for something which keeping the remote base
active (e.g. for remote listeners), but prevent it from changing any
settings.

- Data transmission. Modules for popular data modes could be linked to
the server to perform the modularion and demodulation, and exchange
baseband data and optional diagnostic information (S/N, summarised
waterfall, etc) with a compatible data client. Want to run PSK-31
without a soundcard (on the client)? :) This would potentially reduce
the bandwidth used by data modes, especially for remote bases.

- Digital voice, D-STAR and other modes. Modes such as D-STAR, FreeDV
and others could be implemented as modules and effectively add to the
command set of radios which have the appropriate capabilities (e.g. 9600
bps capability for D-STAR). Of course, a D-STAR module would need a
DV-RPTR AMBE board or a DV Dongle. The DV Dongle could be positioned at
the server end (for sharing among multiple clients) or at the client end
(for saving network bandwidth). This type of add-on would effectively
add extra mode buttons to your radios, with the magic happening behind
the scenes. DV modules also may need to set certain radio parameters
such as mode and 9600 bps.

- Legacy radio emulation. It's going to take a while for developers of
radio control software to adopt the server API. Radio emulation
presents a traditional (virtual) serial and soundcard interface, using a
well known radio command set (e.g. late model Kenwood). It may be
possible to use existing virtual device emulators (e.g. VSPE and Virtual
Audio Cable in the case of Windows, etc) for the sound and serial
support, which would save development of these parts. The radio emulator
would ideally be network aware (since it uses a network aware API), so
it wouldn't need to reside on the same box as the server, which would
make old client software instantly network capable. A Hamlib module
could also be developed to enable Hamlib capable applications to
directly access the server API without having to go through serial port
emulation.

- Infrastructure linking - This sort of module is related to the remote
base module, and would allow the server to be linked to and controlled
by other radio networks - e.g. IRLP, Echolink, D-STAR, etc. For
example, creating an IRLP remote base, which would require the module to
interface with an IRLP node for audio and accept commands generated by
scripts for the control side. An Echolink remote base could accept
commands via a text window. The infrastructure linking could be
delevoped in conjunction with other open source projects such as
thelinkbox (but not share code, otherwise you'll end up being GPL, which
we don't want at this stage).

Anyway, that's a few of my thoughts. Ad this stage a wish list, but
hopefully to give some idea. For priorities, I'd say that layers 1 and
2 are the priorities, as well as the radio emulator, as these are the
things needed to make the system work, as well as encourage users of
existing software to adopt the system.

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

[Hamlib-stationserver] Sharing a radio between multiple applications

From: Art B. <ac...@in...> - 2014-03-04 01:48:33

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?

Thanks!

- Art