hamlib-developer — hamlib developers forum

[Hamlib-developer] API suggestions

[Frank S. <vk...@ix...>]

Hi,

previously, on this channel.....
> 
> > > cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> > > long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
> > > vfo);
> > >
> >   Looks definitely better this way!
> >   Just a question: what if the application just wants to change
> >   the mode only? It might be troublesome in certain case to have
> >   to remember the current frequency or having to query it.
> 
> true, I guess we have some options...
> 
> API provides
> cmd_set_freq_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> 
> and possibly
> cmd_set_mode(RIG *rig, rig_mode_t mode)
> cmd_set_vfo(RIG *rig, vfo_t vfo)


I must have had too many beers during the Olympic opening
ceremony :-)


Actually now that I think about it, the cleanest approach
is probably for the frontend API to provide as a minimum functions
like 

cmd_set_mode(RIG *rig, rig_mode_t mode)
cmd_set_vfo(RIG *rig, vfo_t vfo)
cmd_set_freq_(RIG *rig, freq_t freq)
cmd_set_filter_(RIG *rig, filter_t filter)

and in general
cmd_set_xxx_(RIG *rig, xxx_t xxx)

and that optional  convenience functions like 

cmd_set_channel_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo
....,,,, filter_t filter..)

is some frontend convenience function that backend libs can handle
either directly as is toward the rig if the rig can handle it that way, 
or the backend lib breaks it into the simpler functions shown above if 
the rig needs it that way. We dont care up the front how its done
int the back of course (apart from efficiency issues of course)!


So, 1 frontend convenience functions may cause multiple backend
calls to the rig as it iterates through the convenience functions
argumant list and  calls individual "primitives" towards the rig.

Ok, now I sleep better !!

Should be no state issues to deal with..

just trying to avoid long function names like
cmd_set_freq_mode_vfo_filter_power_this_that_whatever(....)

Comments ??

/Frank..

Re: [Hamlib-developer] frontend API function reduction

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:

> 
>   ..provided we have the specs. May be we can sumon some help
>   by sending an announce on lin...@vg...
>   and lin...@de... mailing lists.
> 

Yep, let me fix ft747 and ft847 asap, and we can announce for help
and show some partly working stuff ;-)


> > cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> > long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
> > vfo);
> >
>   Looks definitely better this way!
>   Just a question: what if the application just wants to change
>   the mode only? It might be troublesome in certain case to have
>   to remember the current frequency or having to query it.

true, I guess we have some options...


API provides
cmd_set_freq_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo ) 

and possibly 
cmd_set_mode(RIG *rig, rig_mode_t mode)
cmd_set_vfo(RIG *rig, vfo_t vfo)

and allow backend to 


if an app calls the generic function
cmd_set_freq_mode_vfo(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo ) 

then if rig later sends
cmd_set_mode(RIG *rig, rig_mode_t mode), we could..

2.  preserve last command params sent in the backend libs.
    this way a cmd_set_mode(rig_mode_t mode) can
    call a cmd_set_freq( ..freq,mode) if that rigs
    opcode command require all aparameters. Otherwise the backend just
sends the
    cmd_set_mode() change.A small overhead, but covers both cases.
    (less yuck !)
     ps: my 2 yaesu can  handle a mode change independant of other stuff

3. Pass NULL parameters into the cmd_set for those things you
    dont want to change since previos command ??

comments ?????


> serial.c
> --------
> serial_open()   open and setup a serial port, fully RIG* aware,
>                 cloned from open_port2()

great !

> write_block2() handles optional write_delay
> read_block() does passive blocking(select), and have timeout handling

> open_port2() has been busted (outdated refs to rig_caps), use serial_open()?
> 

yep, we can kill this.

> Question: What do you think of write_block2() ? Would you agree
>                 to replace write_block() by write_block2() ?
> 

yep, that way it covers all rig types, I had to start somewhere :-)


> Next stage: the linking  ;-)

ahh lovely stuff !
> 
> I'm sorry Frank, with the new API and frontend/backend, you'll have
> to modify your ft847 code. 

will update this weekend, its Olympics in vk3 land (actually vk2)
but I live and watch from texas USA.

BTW, do all the Yeasu rigs have the same
> "CAT" protocol as Icoms do with "CI-V" ? In this case, may be it will
> be easier for you to factorize some code.

so far the 2 yaesus have same 5 block cmd, but no commonality
between opcodes and freq packing into BCD etc..


/ Frank..

> 
> --
> Stephane Fillod                                 F4CFE
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> http://lists.sourceforge.net/mailman/listinfo/hamlib-developer

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] frontend API function reduction

[Stephane F. <f4...@fr...>]

On Fri, Sep 15, 2000, Frank Singleton wrote:
> 
> Well nothing compiles now (sob), so lets get the
> general API and interwork API firmed up...
> 
Sorry about that, I forgot to let you know in my previous mail...
Acutally, I was so eager to show off the new frontend/backend approach!

Usually, we don't write the software specifications after the development :-)
The same goes for an API implementation. 
So it doesn't matter much if the code is broken if the API is not yet
specified! We're still in ALPHA stage, after all. Clean compiles is yet BETA
(and considered stable for MS :).

> I am keen to get a good general (extensible) infrastructure in place.
> 
good! let's do it!

> eg: If previous co compiles, and your or my next ci is known
> to break this, we should think about tagging it in CVS.
> 
	Agree with you! To me, the hamlib-1.0.3 is the latest
  clean compile. Also about version numbers, would it be better
  to have odd numbers for development phases, and even number
  for stable code, ala Linux kernel? With 1.0.3, people
  might think that the library is already ready to use (which is not!)

>
> backend must implement all opcodes (of course)

  ..provided we have the specs. May be we can sumon some help
  by sending an announce on lin...@vg...
  and lin...@de... mailing lists.

> This creates a large function namespace, this is ok as there
> shall be wrappers for them up front anyway. Also, bakend must test
> all opcodes anyway.
> 
> However, frontend should have reduced namespace for function calls.
> 
> eg result, 2 functions up front ....
> 
> cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
> vfo);
> 
  Looks definitely better this way!
  Just a question: what if the application just wants to change
  the mode only? It might be troublesome in certain case to have
  to remember the current frequency or having to query it.

> 
> so, lets create some enums
> 

allright! more to come I'm sure.


new stuff I've checked in:

serial.c
--------
serial_open()	open and setup a serial port, fully RIG* aware,
		cloned from open_port2()
write_block2() handles optional write_delay
read_block() does passive blocking(select), and have timeout handling
open_port2() has been busted (outdated refs to rig_caps), use serial_open()?

Question: What do you think of write_block2() ? Would you agree 
		to replace write_block() by write_block2() ?

frontend:
--------
rigcaps.h has been cut and pasted into rig.h in order to fix the cyclic
forward references. Updated some data struct, added flow_control/retry/timeout
See the testrig.c example to see how to use the frontend lib.
Note: the Makefiles are still broken..

testrig.c
---------
modified to use rig_init/rig_open. Should work with an operating backend..


Conclusion:
----------
The good news is hamlib now compiles OK back again.
Next stage: the linking  ;-)

I'm sorry Frank, with the new API and frontend/backend, you'll have
to modify your ft847 code. BTW, do all the Yeasu rigs have the same
"CAT" protocol as Icoms do with "CI-V" ? In this case, may be it will
be easier for you to factorize some code.

-- 
Stephane Fillod					F4CFE

[Hamlib-developer] frontend API function reduction

[Frank S. <vk...@ix...>]

Hi,

Well nothing compiles now (sob), so lets get the
general API and interwork API firmed up...

I am keen to get a good general (extensible) infrastructure in place.

Also, just a note,, CVS checkins that impact clean compiles
(and there will be many , I am sure) during later project stages
we should flag.

eg: If previous co compiles, and your or my next ci is known
to break this, we should think about tagging it in CVS.

Comments ??


Anyway Some  API thoughts ....

<snip>

/*
 *  
 * API Notes -- FS
 *
 */


I think it is more intuitive  to code things as follows...

backend must implement all opcodes (of course)
this may infer function names like thus (at least according
to yaesu docs not passing vfo as a parameter  - aaarrrgh).


eg 6 functions in backend ..

int cmd_set_freq_main_vfo_hz(RIG *rig,freq_t freq, rig_mode_t mode);
int cmd_set_freq_sat_rx_vfo_hz(RIG *rig,freq_t freq, rig_mode_t mode);
int cmd_set_freq_sat_tx_vfo_hz(RIG *rig,freq_t freq, rig_mode_t mode);

long int cmd_get_freq_mode_status_main_vfo(RIG *rig, unsigned char
*mode);
long int cmd_get_freq_mode_status_sat_rx_vfo(RIG *rig, unsigned char
*mode);
long int cmd_get_freq_mode_status_sat_tx_vfo(RIG *rig, unsigned char
*mode);

This creates a large function namespace, this is ok as there
shall be wrappers for them up front anyway. Also, bakend must test
all opcodes anyway.

However, frontend should have reduced namespace for function calls.

eg result, 2 functions up front ....

cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
vfo);

ie: 3 to 1 reduction, and an emphasis on what parameters
you are setting on the rig, driven more by the parameter
list, than extending function names.

so, lets create some enums

enum rig_vfo_e {
	RIG_VFO_MAIN = 0,
	RIG_VFO_RX,
	RIG_VFO_TX,
	RIG_VFO_SUB,

	/* etc */

}

typedef enum rig_vfo_e rig_vfo_t;

enum rig_rptr_shift_e {
	RIG_RPT_SHIFT_NONE = 0,
	RIG_RPT_SHIFT_MINUS,
	RIG_RPT_SHIFT_PLUS,
	/* etc */

}
<snip>

/Frank.. (yawn...)

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] Re: GUI for FT-847

[Frank S. <vk...@ix...>]

Jim Jerzycke wrote:
> 
>     Hi, Frank.
>  Well.....I went and did it. I bought several books on programming on
> Tcl/Tk, and I'm amazed how easy it is. I've already started on a
> "Virtual Front Panel" for the FT-847, and I've got some functionality as
> far as turning knobs, recording the counts, and also button pushes. As
> soon as I get something presentable, I'll send you a sample!
> 73, Jim

Hi Jim,

Ok, glad to see soemone starting at the other end (GUI).

We are in a shakeup of the code at the moment, outlining
some generic frontend API for applications to use, so
latest CVS tree does not compile too well ;-(

However please feel free to play with the 1.0.3 release
to brush up on your coding  skills. Eventually we will
have wrapper functions for the frontend that will
support Java, Python, Tcl/Tk etc...

Eventually you will tie a widget or component event (eg button pressed)
to a function in our API, but try the libft847 as I know
you have a ft847.

try cmd_set_cat_on()  and cmd_set_cat_off() for fun.

Let us know how you go :-)

Cheers / Frank..



-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] cvs tree structure

[Stephane F. <f4...@fr...>]

 Frank Singleton wrote:
> 
> I was thinking of adding a new directory to the
> cvs tree eg: "generic" or "frontend" to     hold
> the generic front end code. I will place it at
> the same level as "common". ie: just under "hamlib".

	Ok, let's go for a "frontend" directory.
  You'll see on the CVS rep I started an implementation
  of the frontend/backend scheme. There's a backend
  example in ic706/ (still wip), and a simple test
  program using the frontend (testrig.c).

  The sources doesn't compile fine right now because
  of various forward references I can't fix now.
  Also, It'd be nice to define a nice generic interface
  for port management (serial, network, etc.)
  The code is not clean, and some field names are 
  not well chosen. Feel free to fix them.

  I have other questions/ideas in mind, but I'll keep
  them for tomorrow :-)

  have fun!

--
Stephane			F4CFE

[Hamlib-developer] cvs tree structure

[Frank S. <vk...@ix...>]

Hi,

I was thinking of adding a new directory to the
cvs tree eg: "generic" or "frontend" to     hold
the generic front end code. I will place it at
the same level as "common". ie: just under "hamlib".


Comments ??

/Frank
-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] hamlib design?

[Frank S. <vk...@ix...>]

Hi,


Welcome aboard, its no fun sending emails to myself ;-)

See comments below...

/Frank

Stephane Fillod wrote:
> 
> Okay, I started to code a generic rig API layer (kinf of frontend),
> based on Frank's code and ideas in the air. This will lead to a generic
> framework, making it even easier to develop rig backend seamlessly.
> However, I have a few questions:
> 
> 1) Should we assume any rig has no more than 2 VFOs ? Do you have examples?

**
should get from hardware capability structure -- see below
yaesu have at least 3 in some cases

**
Rig lib should return actual and symbolic info.

eg: no. of VFO's and their symbolic
meaning. ie: generic VFO-0 is Main or VFO-A or Sub VFO on rig xxx

eg: 3rd RX is sattelite RX ?


> 
> 2) Is a rig able to notify asynchronously the "host" any event (like a key has been depressed on the panel, main VFO freq changed, etc.) ? Examples?

**
Hmmm, rig callbacks, lets start an api for it anyway - event based, 

hmmm.. rig deamon  (server) send a IP packet to client for example 

I am not aware of yaesu doing it, but we should code for it.  


> 
> 3) Should cmd_set_freq_main_vfo_hz() set both freq and mode or should we split in two separate functions?

**
Some rigs may behave differently,  lets cover both !!


> 
> Here is a non-exhaustive list of things IMO to keep in mind when
> developping the hamlib library.
> 
> Plan:
> ----
> o develop the library as a shared/static library   * yes
> o portable (not only Linux, but UN*X, Win32 using cygwin,etc.  -> autoconf?) - * yes, gtk for GUI 
> o generic (any rig made, any model) - yes
> o wrappable (Java, perl module, Python module, etc.) - * yes java wrappers and some jni stuff ok
> o support serial ports, IrDA ports, USB ports, network ports (w/ a daemon) - * yes, and  client / server also
> o thread safe (reentrant) would be a must - * yep, posix threads here we come !!
> o support preference file (eg. /etc/hamlibrc, ~/.hamlibrc ) - * yes, read from /etc then home
> o written in C (C++ would have been more appropriate, but C is okay) - * i kind of like C and java :-)
> o support more than one rig per application (ie. generic code) - * ok
> o support more than one rig per serial port (ie. Icoms) - *ok
> o handle serial retransmission and timeouts would be nice - * yep, threaded read/writes are good
> o i18n support if applicable - ok
> o software compensation for the actual radio oscillator frequency errors
> o if avail., support events sent by the rig (eg. main freq has been changed,..) - event notifaction
> o maybe add some misc functions like PTT signaling (through serial/parallel..)
> o ...


****
A few more functions / addons

- software scanning (and huristics)
- s/w squelch
- real time spectral analysis and digital modes ( I have written some
working code for this)
  it does 40 frames / sec and no load, really cool to see time and
spectral info !!
  I have based it on generic data engine and plugins !! output also to
small gtk window.
  ie: DSP API


- doppler compensation in tracking mode
- ie: let real time signal analysis drive freq/modes/etc....
- software controlled hopping (poor mans GSM frequency hopping)
   also, must output hopping sequence to other rig to be useful

- networked rigs, provides realtime (global) spectral analysis to
  find (a common) quiet part of the band for a qso between 2 parties

- 

> 
> -> Christmas is in sight, time for whishlists!
> 
> Good inspiration:
> ----------------
> o SANE, with frontend/backend scheme, dynamic loading, autoconf, etc.
> o struct net_device (Linux kernel) for the void *priv idea
> o any rigctrl sources out there ?
> 
> Capabilities:   - ** this is definitely the challenge
> ------------
> We have to find a way to code capabilities in the hamlib in order
> to let the application know what this rig is able to do (before
> attempting to do it and crash :).
> I think some features can be coded using bit fields and masking.
> 
> Maybe we can distinguish between 3 states :
>   - Don't have this feature,
>   - Have it,
>   - Have it and can control (r/w) it remotly using the backend in hamlib
> 
> o freq ranges supported: rx/mode?, tx/modes/power ?  ->How to code this??
> o number of VFO, operations (set VFO separately, VFO A=B, switch, ..)
> o freq granularity (resolution), tuning steps
> o SCAN functions (start, stop, ..)

> o Split (cross band, duplex, ...)
> o RIT (+- KHz)
> o Memory scheme, what is stored in, quantity, call channels, scan edges
> o ATT, P.AMP, AGC, NB, TONE, TSQL, COMP, VOX, BK-IN, ...
> o Tuner control (internal, external, can control)
> o Meter indication: Squelch condition, S-meter level, ALC, SWR
> o Number of antennas (which band ?) and selection
> o available "set mode" items (ie. rig setup), and provide a way to modify them
> o DSP ? - one of my favorite areas, see comments above
> 
> any other ideas?


Many of above fall into a general "rig function capability structure"


Could be internal data structures populated inside each lib, 
and requested by the app.
Note generic <-> symbolic transforms


any app      generic  (front)       rig lib (backend)
-------      -------                -------

   ----------->
    get caps for 
     rig xxxx

                    get caps
                 -------------->    { internal data structure }


                  caps struct populated
                <--------------

apps knows rigs
capability. now
do something useful.


Also frontend can request 2 modes of commands

- acknowledged / unacknowledged mode

unack
------

eg:

set freq to xxx
--------------->
returns -1 if error
assume ok otherwise


OR

acked mode

set freq to xxx
--------------->
                 set freq
              ------------------------->
                get freq
              ------------------------->
                 freq retuerned
             <-------------------------

            compare requested 
            with actual 

  result
<--------------




I think we are forced to bite the bullet so to speak,
and start some rig capabilities stuff. I have only
scratched the surface with rig.h and rig_caps structure.


Also, each backend must provide a  rigxxx_read and rigxxx_write etc..
inside serial.c. 

frontend only sees read/write


Also, returned data must be uniform accross all rigs.


eg: TX power in dbm, not  0-15 units on yaesu and 0 - 23 units on icom


.... more to come I am sure...



> 
> --
> Stephane
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> http://lists.sourceforge.net/mailman/listinfo/hamlib-developer


Cheers / Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] hamlib design?

[Stephane F. <f4...@fr...>]

Okay, I started to code a generic rig API layer (kinf of frontend),
based on Frank's code and ideas in the air. This will lead to a generic
framework, making it even easier to develop rig backend seamlessly.
However, I have a few questions:

1) Should we assume any rig has no more than 2 VFOs ? Do you have examples?

2) Is a rig able to notify asynchronously the "host" any event (like a key has been depressed on the panel, main VFO freq changed, etc.) ? Examples?

3) Should cmd_set_freq_main_vfo_hz() set both freq and mode or should we split in two separate functions?


Here is a non-exhaustive list of things IMO to keep in mind when
developping the hamlib library.


Plan:
----
o develop the library as a shared/static library
o portable (not only Linux, but UN*X, Win32 using cygwin,etc.  -> autoconf?)
o generic (any rig made, any model)
o wrappable (Java, perl module, Python module, etc.)
o support serial ports, IrDA ports, USB ports, network ports (w/ a daemon)
o thread safe (reentrant) would be a must
o support preference file (eg. /etc/hamlibrc, ~/.hamlibrc )
o written in C (C++ would have been more appropriate, but C is okay)
o support more than one rig per application (ie. generic code)
o support more than one rig per serial port (ie. Icoms)
o handle serial retransmission and timeouts would be nice
o i18n support if applicable
o software compensation for the actual radio oscillator frequency errors
o if avail., support events sent by the rig (eg. main freq has been changed,..)
o maybe add some misc functions like PTT signaling (through serial/parallel..)
o ...

-> Christmas is in sight, time for whishlists!


Good inspiration:
----------------
o SANE, with frontend/backend scheme, dynamic loading, autoconf, etc.
o struct net_device (Linux kernel) for the void *priv idea
o any rigctrl sources out there ?

Capabilities:
------------
We have to find a way to code capabilities in the hamlib in order
to let the application know what this rig is able to do (before
attempting to do it and crash :).
I think some features can be coded using bit fields and masking.

Maybe we can distinguish between 3 states :
  - Don't have this feature,
  - Have it, 
  - Have it and can control (r/w) it remotly using the backend in hamlib

o freq ranges supported: rx/mode?, tx/modes/power ?  ->How to code this??
o number of VFO, operations (set VFO separately, VFO A=B, switch, ..)
o freq granularity (resolution), tuning steps
o SCAN functions (start, stop, ..)
o Split (cross band, duplex, ...)
o RIT (+- KHz)
o Memory scheme, what is stored in, quantity, call channels, scan edges
o ATT, P.AMP, AGC, NB, TONE, TSQL, COMP, VOX, BK-IN, ...
o Tuner control (internal, external, can control)
o Meter indication: Squelch condition, S-meter level, ALC, SWR
o Number of antennas (which band ?) and selection
o available "set mode" items (ie. rig setup), and provide a way to modify them
o DSP ?

any other ideas?


-- 
Stephane

[Hamlib-developer] hamlib 1.0.3 release

[Frank S. <vk...@ix...>]

Hi,

Well here is the first release of the hamlib libraries.

There is a lot of work to do, but I do have API's
implemeneted for FT747GX and FT847 radios  mostly
implemented. :-)

Examples of test programs to say connect to a radio
and do something usefuly (like change frequency for
example) are in the test directory for each radio
type.  

At the moment the API's are described in each
radio's header file.

eg: ft747.h of ft847.h

Basically you connect to a rig, issue commands, and
then diconnect.

A C code snippet to connect to a FT847 and set
the frequnecy of the main VFO to 439,700,000 Hz ,
using FM as the required mode, would look something 
like this.

<snip>

  int fd;
  
  fd = rig_open(SERIAL_PORT);
  printf("port %s opened ok \n",SERIAL_PORT);
  
  cmd_set_cat_on(fd);		/* cat on */
  cmd_set_freq_main_vfo_hz(fd,439700000,MODE_FM);
  cmd_set_cat_off(fd);		/* cat off */
  
  rig_close(fd);
  printf("port %s closed ok \n",SERIAL_PORT);

<snip>


There are NO GUI's yet, but I mainly wanted to
get the libraries implemented, so people can
start using them for implementing cool stuff.

Perhaps I will even add a GUI section as well if
I get enough volunteers.

If you are interested in joining the crew, let me 
know and I can arrange that.

It mainly helps if you have some type of radio and
a copy of the control docs (eg:  User Manuals).

It is hoped that the API's get documented well enough
for developers to just use this library. In fact I have
made function wrappers for some of the raw "CAT" calls
that make life a bit easier.

eg: You dont have to worry about BCD conversion and
packing data according to the Radio's manual.

Most command can use specify the freq in Hz and mode 
like MODE_FM, MODE_CW etc..

  cmd_set_freq_main_vfo_hz(fd,439700000,MODE_FM);

Any common routines should eventually live in
the "common" directory.


Anyway, take a look around. No fancy web pages yet
(volunteers ??) but the core libraries are being
developed all the time and provide useful
functionality.

If you want to help me out, contact me at the
"Open Discussion Forum" news area at
http://sourceforge.net/projects/hamlib/

-- Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com