rigserve-devel — Comments, questions, and discussion about the rigserve project

Re: [Rigserve-devel] Icom Receiver Development

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

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 DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Rigserve-devel mailing list
> Rig...@li...
> https://lists.sourceforge.net/lists/listinfo/rigserve-devel

Re: [Rigserve-devel] Icom Receiver Development

[Martin A. <aa...@ew...>]

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

Re: [Rigserve-devel] Icom Receiver Development

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

Hi Martin,

Thanks for getting back to me.

I agree with your idea for arranging the classes;


> Backend -> Icom -> Icom_rx -> {ic_r8500 | ic_r75 | ...}
> 
> 
I was wondering if it would make sense to build a 'serial' class that
handle hardware issues. This ought to be fairly small and essentilly be
instantiated with serial port parameters and consist of a couple of
read/write methods.  This class could then be reused by other types of
rigs that require serial port access.


A CI-V class could then be written to encapsulate all of the 'common'
functions (power on/off functions and the basic 'write tuple' methods
etc.) which in turn is inherited by an Icom_RX class. 

BTW, The default ID for an R75 is 0x5A, but this can also be changed
from the settings menu.

I'll have a bit more of a think about it over the weekend (that's
Thursday/Saturday here) and get back to you.

All the best,

- Jim (M0DNS)

Re: [Rigserve-devel] Icom Receiver Development

[Martin A. <aa...@ew...>]

Jim,

I'm glad the R75 works so easily.  Of course, it's not too surprising, 
since the R8500 is a similar product from the same company.

The question of how to establish classes is an interesting one.  You 
want to capture the "essential" qualities at each level of the family 
tree.  It's often a judgment call.

Right now, we have an Icom class and an IC_R8500.  *IF* all likely Icom 
products will have the CI-V interface, then I would say we should build 
in the CI-V behavior into the Icom class.  It already has the basic 
serial I/O setup.

A related issue - The CI-V bus allows many devices on a single serial 
I/O port.  Each device has a default address, according to its model 
number, but these can be reprogrammed.  (At least on my R8500 - I don't 
know if that works on all Icom rigs.)  So you could have a CI-V port 
that has multiple R8500's, R75's etc, and you could have multiple CI-V 
ports (serial devices).  To allow for that, we might pass the CI-V 
address as an argument to the rig subclass (IC_r8500 etc.) and let it be 
determined by the high-level rig INIT command along with the port 
device, etc.  (Or use the default address if nothing is specified?)

It would be reasonable to ask how many people are actually going to be 
operating multiple CI-V ports with multiple rigs on them.  I guess the 
point (as with Rigserve as a whole) is to show how it's fairly easy to 
allow these general cases without mucking up the code very much. 
(Compare Hamlib!)  The only downside is possibly producing code with 
great features that none of us can adequately test.  (That's a problem 
with Hamlib, too.)

If the R75 and the R8500 are so close, that suggests another way of 
"factoring" the class descriptions.  You might have

Backend -> Icom -> Icom_rx -> {ic_r8500 | ic_r75 | ...}

where there would be very little inside the _r8500 or _r75 subclasses 
except the few things that separate those models.  This is similar to 
how I handled the differences between the TT_orion_v1 and TT_orion_v2 
where the only difference (from our standpoint) is the S-meter calibrations.

I also realize that what I call ic_r8500_basic (subroutine library) 
probably applies to most all Icom rigs, but should be extended and 
renamed (?) to include the properties of the more complicated rigs. I 
need to acquire some more Icom rigs...

Keep us informed of your progress!

73 Martin AA6E

James Watson wrote:
> Hi,
> 
> I recently managed to get hold of an Icom R75 receiver and am hoping to
> contribute a little to the Rigserve project.  I've made a few changes to
> the IC-R8500 files and am able to control my rig quite happily using the
> renamed R75 files.  The changes are very minor;
> 
> - rig ID
> - modes
> - upper/lower frequency definitions
> 
> I'm very new to python but have experience in other object orientated
> languages.  I feel that the changes made are so minor it seems pointless
> generating a whole new class.  I was thinking that a general 'Icom CI-V'
> class would make more sense, this could then be sub-classed by rig
> specific classes.  Is anyone else on the list looking at this?  I'm not
> sure if my Python programming knowledge is sufficient to let me take
> this very far but am willing to give it a go if no one else is.
> 
> - Jim
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Rigserve-devel mailing list
> Rig...@li...
> https://lists.sourceforge.net/lists/listinfo/rigserve-devel

[Rigserve-devel] Icom Receiver Development

[James W. <jim...@ma...>]

Hi,

I recently managed to get hold of an Icom R75 receiver and am hoping to
contribute a little to the Rigserve project.  I've made a few changes to
the IC-R8500 files and am able to control my rig quite happily using the
renamed R75 files.  The changes are very minor;

- rig ID
- modes
- upper/lower frequency definitions

I'm very new to python but have experience in other object orientated
languages.  I feel that the changes made are so minor it seems pointless
generating a whole new class.  I was thinking that a general 'Icom CI-V'
class would make more sense, this could then be sub-classed by rig
specific classes.  Is anyone else on the list looking at this?  I'm not
sure if my Python programming knowledge is sufficient to let me take
this very far but am willing to give it a go if no one else is.

- Jim

[Rigserve-devel] our own wiki

[Martin A. <aa...@ew...>]

Sourceforge has a wiki service in beta, and we now have one for 
Rigserve.  Go to rigserve.wiki.sourceforge.org .  If anyone feels like 
organizing it in some useful way for this project, have at it.

73 Martin AA6E

[Rigserve-devel] Rigserve022a files

[Martin A. <aa...@ew...>]

Somehow the original tgz/zip files were corrupted in the release 
process.  I couldn't find the problem, but the files are now recreated 
as rigserve022a.tgz and rigserver022a.zip for your downloading pleasure 
on Sourceforge.

Thanks to Jim Watson M0DNS for the alert.

73 Martin AA6E

Re: [Rigserve-devel] Release 0.22

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

Hi,

I've tried downloading the both the tgz file and the zip files but
'Archive Manager' can't unpack them.  I can't unpack them from the
command line either.  Anybody else have the same problem?

gzip: stdin: invalid compressed data--format violated
/bin/gtar: Skipping to next header
/bin/gtar: Archive contains obsolescent base-64 headers
/bin/gtar: Child returned status 1
/bin/gtar: Error exit delayed from previous errors

Archive:  /home/jwatson/Desktop/rigserve022.zip   147065 bytes   22
files
warning [/home/jwatson/Desktop/rigserve022.zip]:  547 extra bytes at
beginning or within zipfile
  (attempting to process anyway)
error [/home/jwatson/Desktop/rigserve022.zip]:  start of central
directory not found;
  zipfile corrupt.
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly)

- Jim (M0DNS)

[Rigserve-devel] Release 0.22

[Martin A. <aa...@ew...>]

A new minor release is now on Sourceforge.net/projects/rigserve.

I have added a Python CGI script that shows how one could start 
implementing a web-based rig server.  Actually, it's a little baroque:

You have your favorite web server (W) that supports a web page 
(index.html) and the CGI script (rig_operate.py).  The user's browser 
connects to W, and the user enters data on a form.  The script on W 
starts up a session on another server (R), where rigserve.py runs.  Of 
course, W and R can be the same machine.

It would be more efficient to weave a webserver into rigserve.py itself, 
but it's too much work for a simple demo!

73 Martin AA6E

[Rigserve-devel] Modest progress - FT817

[Hugh B. <hu...@bl...>]

Hi Martin, All,

I've just succeeded in pulling the current frequency of operation out of my FT-817 using Martin's Orion code as a starting point.  

The Yaesu protocol is pretty simple, the thing that's been taking time as much as anything is me getting my head around Python :)

The CAT interface implemented by the '817 presents some interesting limitations, for example you can't tell whether you have VFO A or B selected, only toggle between them.  I think I can emulate the behaviour to some extent but this may suggest we need to expand our capability flags - eg to say you can't get VFOA's frequency, only the frequency of the current VFO.  Will cogitate on this further.

More to follow (including, obviously, source code :) once I've got a little bit more done.

vy 73
Hugh 
VK1YYZ/AD5RV

[Rigserve-devel] The Rigserve-devel List

[Martin A. <aa...@ew...>]

Welcome to the new rigserve-devel mailing list!

I have waited until we have a number of folks who have expressed an 
interest in this project before creating this list.  For one thing, 
Souceforge says they intend to keep the mail archives "forever", along 
with the SVN and release files.  That's good if you believe in the need 
to archive public source programs, but it means all our embarrassing 
false starts, flame wars, etc. are going to preserved too!

I encourage anyone to download the initial release and/or the current 
SVN files for experimentation or just for browsing.  If you are able to 
propose patches or extensions, please do so.  If you would like to be a 
full "co-conspirator" and share in the project development, please 
request SVN write/update access.  (Anyone can _read_ SVN, of course.)

Of course, we welcome any comments or suggestions, preferably addressed 
to this list, but to me privately if you wish.

73, Martin AA6E