Re: [Rigserve-devel] Icom Receiver Development

[James W. <lei...@gm...>]

Hi Martin,

Thanks for getting back to me.  I've come across the documentation on
CI-V before and agree that all of the Icom rigs appear to be outwardly
the same yet are tantalisingly different when it comes down to the
details.

I've noticed that the mode/filter commands are slightly different for
example.  The setting that I've used in the R75 class are based on the
front panel display, and don't align with the documentation in the
manual and took a couple of hours messing around to get it sorted - I've
just checked to link you provided and it acknowledges the mistake in the
manual (Homer Doh!).

As far as establishing a capability goes, I feel that 'generic'
libraries such as Hamlib, rigserve etc should adhere to a simplified
common denominator command set that apply across the board to all rigs.
I make use of the 'grig' application to control my radio but the front
panel doesn't fully align with the capabilities of the receiver.  I
prefer to see a smaller number of fully operational features than a
larger set of loose ends that may or may not apply to a specific
receiver.  I would find a library that had common commands for all rigs
to be of most use - there's nothing stopping users from extending the
core functionality to create rig specific GUIs and applications.  

I really see rig control only useful when working with other
applications, not as an end in itself. e.g. I developed a couple of OSX
apps (homepage.mac.com/jimwatson) that allow a user to search the ilg
database and present search results in a table.  Double clicking a table
entry re-tuned the receiver.  Digging deep into menus on a screen just
doesn't appeal when I could simply lean over and twiddle 'real' buttons.
The program fldigi is an excellent example of a program making use of a
generic library.

I'm still not up to speed with Python but was thinking that a single
'CIV' class could be used to define a generic set of methods.
Instantiate the class with a separate rig specific class that
essentially contains a set of definitions, similar to the way that the
serial class is generic but fully defined when it's instantiated with a
class defining port locations, speeds etc.

I'm not sure that my programming skills will allow me to illustrate what
I'm talking about here but am prepared to give it a go at the weekend.

All the best for now

Jim

On Mon, 2007-07-23 at 21:47 -0400, Martin AA6E wrote:
> Jim,
> 
>    I have been looking at the problem of multiple Icom rigs & classes a 
> little bit.  There is useful CI-V command documentation at 
> http://www.plicht.de/ekki/civ/index.html - if that helps.  The 
> conclusion is (in part) that Icom CI-V capable rigs are all quite 
> similar, but they are all different.  How to express all that 
> information in a natural and compact way is an interesting question.  It 
> would be nice to have a CIV base class with subclasses for each distinct 
> model.
> 
> On the other hand, in the short run it's way easier to do what you've 
> done and just copy the hardware interface subroutines and adapt to the 
> one particular model you're interested in.
> 
> There is also the problem we have talked about in Hamlib for some time. 
>   Are we trying to invent a system that expresses the full capability of 
> each type of rig, or are we looking to implement some lowest common 
> denominator?  For example, I'm inclined to ignore the scanning and 
> memory capabilities that vary a lot from rig to rig - at least until 
> someone comes along who really wants to implement it.
> 
> Hopefully, I'll have more to say after a while.
> 
> 73 Martin AA6E
> 
> James Watson wrote:
> > Hi Martin,
> > 
> > Sorry for the delay in getting back to you but I've been stupidly busy
> > at work.
> > 
> > I've attached the files that so far seem to work on my R75. I've tested
> > most routines fairly thoroughly. I've also added a simple routine ant to
> > select the antenna input (my first Python script).
> > 
> > I'm not sure of the best way to organise the code to reduce re-coding
> > for similar receivers but was wondering about a CIV class that
> > initialised with rig specific class that consisted essentially of
> > definitions, i.e. dictionaries of valid modes (the modes/filter
> > bandwidths are called up with the same syntax but not all modes appear
> > to be supported on all receivers).
> > 
> > Anyway,  I hope the attached is of interest.  If there's anything I can
> > do to help, please let me know.
> > 
> > 
> > 
> > 
> > o readOn Sun, 2007-07-15 at 16:00 -0400, Martin AA6E wrote:
> >> Jim -
> >>
> >> I would only point out that the Python 'serial' package already provides 
> >> the basic serial class.  Is there something that it lacks for our work?
> >>
> >> Maybe there is room for a CI-V class that is effectively based on 'serial'.
> >>
> >> -Martin
> >>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Rigserve-devel mailing list
> Rig...@li...
> https://lists.sourceforge.net/lists/listinfo/rigserve-devel