hamlib-developer — hamlib developers forum

RE: [Hamlib-developer] vfo_t rewrite

[Chuck H. <n2...@am...>]

Looks interesting, but I'm slightly confused about how this would work with a
satellite rig.
And you asked for comments. :)
I hope this makes sense and I didn't give you too many. :)
And if it just looks like I'm not reading you message correctly, just let me
know. :)
And if it doesn't make sense feel free to let me know. :)

I'm a little fuzzy about the IC-970's transmit offset/split feature because I
have not used it yet (I will soon) and I don't have the radio and/or the user
manual handy.

-

With a radio like the IC-970:

The radio has two radio modules that can each be tied to any of the band
modules (but with the IC-970 not the same band)

main transceiver with optional transmit offset (or is it a split)
sub receiver

Common uses:
cross band satellite (full duplex):
main is the transmitter
sub is the receiver

other uses (half duplex):
main is the transceiver with optional transmit offset

-

Now from my reading of your description:

RIG_VFO_MAIN and RIG_VFO_SUB don't necessarily have anything to do with the
vfo's the radio calls main and sub.

RIG_VFO_TX for the sub receiver would the the main

RIG_VFO_TX for the main would be the main transmit offset?
or would this be a split which is set with rig_set_split_vfo?
Is RIG_VFO_TX_VFO part of the radio description or settable by the user?
What happens when you turn split on and off?

I don't think it matters that much to me because my software has a config file
that you set up ahead of time that has lists of transmitter and receiver pairs
that you can select between.
I can deal with transmit on radio 1 on RIG_VFO_1 and receive on radio 2 on
RIG_VFO_2.

However, I figured I would ask just in case.

---

For the medium/long term, I'm thinking it would be nice to have some sort of
searchable extended capabilities database (I'm not sure if it should be a hard
coded in a structure, stored in a file, or something else) with things like:
name radio calls vfo (left, right, main, sub, vhf, uhf, ...)
transmit range
receive range
various other info

so I could do a query something like:
what vfos should I use to transmit on vhf, receive on uhf, preferably full
 duplex?  And does the radio need to be in a special mode and/or setup?

If you had enough info in there, then someone could write a piece of software
that could do fairly complicated things to the radio without a lot of special
configuration.  On the other hand, a lot of software probably only has to worry
about RIG_VFO_CURR because alot of things that you can do with the front panel
can just as easily be done with software using hamlib.  (eg. for memories, the
things I can think of you would want to do to them are backup, restore, and
editing.  You don't really need to use them in hamlib)

However, this would take alot of thinking to try to come up because it seems
they are adding all sorts of different modes to the new high end radios for
different uses.  And how what modes share hardware and/or software vfo's with
other modes.  
And then with the software defined radios you could have multiple receivers
active in the dsp up to the speed of the dsp.  (Either different modes or
different frequencies inside of the IF passband)  (vfo1 is spectrum display
across the IF passband, vfo2 is one frequency in USB, vfo3 is a slightly
different frequency in PSK31, ...)






On 10-Mar-03 Stephane Fillod wrote:
> 
> Hi everyone,
> 
> Here's a rewrite of the vfo_t can of worms (special brand).
> The former control band paradigm is gone, mainly because putting too much
> capabilities in one data field makes code totaly messed up.
> 
> Please comment heavily, the vfo_t rewrite is the only reason holding the
> hamlib-1.1.4 release.
> 
> I hope the new vfo_t will be saner. It can designate 2 kinds of "VFO"
> (ie. control channel): real VFO, and aliases.
> - what I call real VFO's are not exactly "Variable Frequency Oscillator",
>   but control channels like VFO A, VFO B, VFO C.
> - what I call aliases are conceptual channels like "Transmit VFO" and
>   "Receive VFO".
> 
> Here are the macros that can be used:
> 
> aliases:
> -------
> RIG_VFO_NONE  used in caps, not to be used as a target
> RIG_VFO_CURR  the almighty
> RIG_VFO_MEM   Memory mode (last selected channel), used by set_vfo, 
>               as opposed to VFO mode
> RIG_VFO_VFO   VFO mode (last selected VFO), used by set_vfo, 
>               as opposed to Memory mode
> 
> RIG_VFO_RX    maps to RIG_VFO_CURR
> RIG_VFO_TX    maps to the transmit channel associated with RIG_VFO_CURR.
>               Therefore, the following 2 calls are equivalent:
>                       rig_set_split_freq(RIG_VFO_CURR, ..)
>                       rig_set_freq(RIG_VFO_TX, ..)
> 
> RIG_VFO_MAIN  set_vfo switch convenience, not to be used as a target
> RIG_VFO_SUB   set_vfo switch convenience, not to be used as a target
> 
> "real" VFO's:
> ------------
> RIG_VFO_N(n)  starts from 0, allows at least 20 VFO's for now
> 
> RIG_VFO_A     VFO 0
> RIG_VFO_B     VFO 1
> RIG_VFO_C     VFO 2
> 
> Special macro:
> RIG_VFO_TX_VFO(v)     Designate the transmit channel of VFO.
>                       e.g. RIG_VFO_TX_VFO(RIG_VFO_C) is the transmit
>                       channel associated with VFO C.
>                       Sometimes, RIG_VFO_TX_VFO(RIG_VFO_C) may
>                       designate the same VFO as VFO C.
> 
> Why the RIG_VFO_TX_VFO? 
> ----------------------
> Because some calls do not have a rig_set_split_xxx to target the
> transmit channel, eg. rig_set_ant().
> 
> 
> Remarks:
> -------
> * Some rigs use 2 VFO's to handle the transmit and receive channels.
>   However, other models may use only one for both directions (in a half-
>   duplex manner). This should be transparent for the application.
> 
> * Split combinations are not to be handled here. We need to
>   create (or modify) an API call like the following:
>   rig_set_plit_vfo(RIG*, vfo_t rx_vfo, split_t split, vfo_t tx_vfo);
>   What do you think?
> 
> * Call channels should be accessed through a forged memory channel,
>   unless they are truly plain VFO. I would recommand to go the memory way
>   anyway, because memory channels are saved by application whereas 
>   VFO channels aren't (they're kind of temprorary working area).
> 
> * For now, only rig.h has been modified. If everyone agrees upon this
>   rewrite, all the backend will have to be adaptated to honor this new
>   semantic.
> 
> * It is already possible to know which VFO has support for which
>   frequency band. However, a new field will have to be created 
>   in the caps to describe what frequency band is exclusive to which one,
>   determining if full-duplex is possible or not.
> 
> 
> Here's the relevant part of rig.h:
> ---------------------------------
> /**
>  * \brief VFO definition
>  *
>  * There's several way of using a vfo_t. For most cases, using RIG_VFO_A,
>  * RIG_VFO_B, RIG_VFO_CURR, etc., as opaque macros should suffice.
>  *
>  * Strictly speaking a VFO is Variable Frequency Oscillator.
>  * Here, it is referred as a tunable channel, from the radio operator
>  * point of view. The channel can be designated individualy by its real 
>  * number, or using an alias.
>  * Aliases may, or may not be honored by backend, and are defined using
>  * high significant bits, like RIG_VFO_MEM, RIG_VFO_MAIN, etc.
>  *
>  */
> typedef int vfo_t;
> 
> /** \brief used in caps */
>#define RIG_VFO_NONE    0
> 
>#define RIG_VFO_TX_FLAG    ((vfo_t)(1<<30))
> 
> /** \brief current "tunable channel"/VFO */
>#define RIG_VFO_CURR    ((vfo_t)(1<<29))
> 
> /** \brief means Memory mode, to be used with set_vfo */
>#define RIG_VFO_MEM    ((vfo_t)(1<<28))
> 
> /** \brief means (last or any)VFO mode, with set_vfo */
>#define RIG_VFO_VFO    ((vfo_t)(1<<27))
> 
>#define RIG_VFO_TX_VFO(v)      ((v)|RIG_VFO_TX_FLAG)
> 
> /** \brief alias for split tx or uplink, of VFO_CURR  */
>#define RIG_VFO_TX     RIG_VFO_TX_VFO(RIG_VFO_CURR)
> 
> /** \brief alias for split rx or downlink */
>#define RIG_VFO_RX     RIG_VFO_CURR
> 
> /** \brief alias for MAIN */
>#define RIG_VFO_MAIN   ((vfo_t)(1<<26))
> /** \brief alias for SUB */
>#define RIG_VFO_SUB    ((vfo_t)(1<<25))
> 
>#define RIG_VFO_N(n) ((vfo_t)(1<<(n)))
> 
> /** \brief VFO A */
>#define RIG_VFO_A RIG_VFO_N(0)
> /** \brief VFO B */
>#define RIG_VFO_B RIG_VFO_N(1)
> /** \brief VFO C */
>#define RIG_VFO_C RIG_VFO_N(2)
> 
> 
> If something is not clear, please ask questions. If documentation is too
> vague, please complain, or better, propose your own comments!
> 
> Application developers, please let me know if this new design does not let
> you do what you want.
> 
> Backend developers, please let me know if this new design does not let
> you describe what your rig can do.
> 
> 
> Cheers,
> Stephane
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

----------------------------------
E-Mail: Chuck Hemker <n2...@am...>
Date: 11-Mar-03
Time: 04:40:00

This message was sent by XFMail
----------------------------------

Re: [Hamlib-developer] vfo_t rewrite

[Nate B. <n0...@ne...>]

* Stephane Fillod <f8...@fr...> [2003 Mar 10 17:11 -0600]:

> * Split combinations are not to be handled here. We need to
>   create (or modify) an API call like the following:
>   rig_set_plit_vfo(RIG*, vfo_t rx_vfo, split_t split, vfo_t tx_vfo);
>   What do you think?

I like this, Stephane.  As I've been thinking about implementing
set_split_freq and friends for the FT-890, I've been conjuring up all
manner of nasty hacks.  I like this API.

Reading the rest of your message I gather that set_vfo is to be used to
set the rig into memory mode.  This does make sense, but I haven't
implemented that in either ft890 or ft920, yet.  Scanning further into
the API than I have in some time I see set/get_mem which appears to be
for setting/getting a specific memory channel.  So, I need to correct
set_vfo in each backend (what else is new?).

> Backend developers, please let me know if this new design does not let
> you describe what your rig can do.

I just wish the FT-920 could do through the CAT what it can do on the
front panel.  This isn't the fault of Hamlib, though.  :-(

Add to the wishlist some policy documentation, much like you're doing
with vfo_t.  In other words, the answers to most of my questions!

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

[Hamlib-developer] vfo_t rewrite

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

Hi everyone,

Here's a rewrite of the vfo_t can of worms (special brand).
The former control band paradigm is gone, mainly because putting too much
capabilities in one data field makes code totaly messed up.

Please comment heavily, the vfo_t rewrite is the only reason holding the
hamlib-1.1.4 release.

I hope the new vfo_t will be saner. It can designate 2 kinds of "VFO"
(ie. control channel): real VFO, and aliases.
- what I call real VFO's are not exactly "Variable Frequency Oscillator",
  but control channels like VFO A, VFO B, VFO C.
- what I call aliases are conceptual channels like "Transmit VFO" and
  "Receive VFO".

Here are the macros that can be used:

aliases:
-------
RIG_VFO_NONE	used in caps, not to be used as a target
RIG_VFO_CURR	the almighty
RIG_VFO_MEM	Memory mode (last selected channel), used by set_vfo, 
		as opposed to VFO mode
RIG_VFO_VFO	VFO mode (last selected VFO), used by set_vfo, 
		as opposed to Memory mode

RIG_VFO_RX	maps to RIG_VFO_CURR
RIG_VFO_TX	maps to the transmit channel associated with RIG_VFO_CURR.
		Therefore, the following 2 calls are equivalent:
			rig_set_split_freq(RIG_VFO_CURR, ..)
			rig_set_freq(RIG_VFO_TX, ..)

RIG_VFO_MAIN	set_vfo switch convenience, not to be used as a target
RIG_VFO_SUB	set_vfo switch convenience, not to be used as a target

"real" VFO's:
------------
RIG_VFO_N(n)	starts from 0, allows at least 20 VFO's for now

RIG_VFO_A 	VFO 0
RIG_VFO_B 	VFO 1
RIG_VFO_C 	VFO 2

Special macro:
RIG_VFO_TX_VFO(v)	Designate the transmit channel of VFO.
			e.g. RIG_VFO_TX_VFO(RIG_VFO_C) is the transmit
			channel associated with VFO C.
			Sometimes, RIG_VFO_TX_VFO(RIG_VFO_C) may
			designate the same VFO as VFO C.

Why the RIG_VFO_TX_VFO? 
----------------------
Because some calls do not have a rig_set_split_xxx to target the
transmit channel, eg. rig_set_ant().


Remarks:
-------
* Some rigs use 2 VFO's to handle the transmit and receive channels.
  However, other models may use only one for both directions (in a half-
  duplex manner). This should be transparent for the application.

* Split combinations are not to be handled here. We need to
  create (or modify) an API call like the following:
  rig_set_plit_vfo(RIG*, vfo_t rx_vfo, split_t split, vfo_t tx_vfo);
  What do you think?

* Call channels should be accessed through a forged memory channel,
  unless they are truly plain VFO. I would recommand to go the memory way
  anyway, because memory channels are saved by application whereas 
  VFO channels aren't (they're kind of temprorary working area).

* For now, only rig.h has been modified. If everyone agrees upon this
  rewrite, all the backend will have to be adaptated to honor this new
  semantic.

* It is already possible to know which VFO has support for which
  frequency band. However, a new field will have to be created 
  in the caps to describe what frequency band is exclusive to which one,
  determining if full-duplex is possible or not.


Here's the relevant part of rig.h:
---------------------------------
/**
 * \brief VFO definition
 *
 * There's several way of using a vfo_t. For most cases, using RIG_VFO_A,
 * RIG_VFO_B, RIG_VFO_CURR, etc., as opaque macros should suffice.
 *
 * Strictly speaking a VFO is Variable Frequency Oscillator.
 * Here, it is referred as a tunable channel, from the radio operator
 * point of view. The channel can be designated individualy by its real 
 * number, or using an alias.
 * Aliases may, or may not be honored by backend, and are defined using
 * high significant bits, like RIG_VFO_MEM, RIG_VFO_MAIN, etc.
 *
 */
typedef int vfo_t;

/** \brief used in caps */
#define RIG_VFO_NONE    0

#define RIG_VFO_TX_FLAG    ((vfo_t)(1<<30))

/** \brief current "tunable channel"/VFO */
#define RIG_VFO_CURR    ((vfo_t)(1<<29))

/** \brief means Memory mode, to be used with set_vfo */
#define RIG_VFO_MEM	((vfo_t)(1<<28))

/** \brief means (last or any)VFO mode, with set_vfo */
#define RIG_VFO_VFO	((vfo_t)(1<<27))

#define RIG_VFO_TX_VFO(v)	((v)|RIG_VFO_TX_FLAG)

/** \brief alias for split tx or uplink, of VFO_CURR  */
#define RIG_VFO_TX	RIG_VFO_TX_VFO(RIG_VFO_CURR)

/** \brief alias for split rx or downlink */
#define RIG_VFO_RX	RIG_VFO_CURR

/** \brief alias for MAIN */
#define RIG_VFO_MAIN	((vfo_t)(1<<26))
/** \brief alias for SUB */
#define RIG_VFO_SUB	((vfo_t)(1<<25))

#define RIG_VFO_N(n) ((vfo_t)(1<<(n)))

/** \brief VFO A */
#define RIG_VFO_A RIG_VFO_N(0)
/** \brief VFO B */
#define RIG_VFO_B RIG_VFO_N(1)
/** \brief VFO C */
#define RIG_VFO_C RIG_VFO_N(2)


If something is not clear, please ask questions. If documentation is too
vague, please complain, or better, propose your own comments!

Application developers, please let me know if this new design does not let
you do what you want.

Backend developers, please let me know if this new design does not let
you describe what your rig can do.


Cheers,
Stephane

[Hamlib-developer] New FT-890 backend

[Nate B. <n0...@ne...>]

Hi All.

I just added a backend for the Yaesu FT-890/FT-890AT.  While the basis
for this is the FT-920 backend I've been working on, darned little code
sharing seems to be possible as too many things are different.  Perhaps 
in the future I can merge some things into the yaesu.c/h, but for now it
appears things will stay seperate.

Supported front end functions in this release are:

rig_set_freq
rig_get_freq
rig_set_mode
rig_get_mode
rig_set_vfo
rig_get_vfo
rig_set_split
rig_get_split

As usual testing for my hidden bugs would be nice.  :-)

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

Re: [Hamlib-developer] Hamlib-1.13 install doesn't work

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

On Thu, Mar 06, 2003, N9...@ao... wrote:
> I downloaded Hamlib-1.13 from the TLF (PA0RCT) installation page.  My system 
> is RedHat Linux 7.3, 2.4.18.3 kernel.
[..]
> Typing in 'rigctl --list' returns the following:
> freq = 5778699387438942  (or some other meaningless integer)

I saw on TLF mailing list you solved the problem by trying one of 
the bleeding-edge version of Hamlib.
Anyway, next time when reporting problems, please include all the traces 
with -vvvvvv, this helps to help you.

73
Stephane

[Hamlib-developer] Hamlib-1.13 install doesn't work

[<N9...@ao...>]

Greetings,

I downloaded Hamlib-1.13 from the TLF (PA0RCT) installation page.  My system 
is RedHat Linux 7.3, 2.4.18.3 kernel.

I verified that the versions of "autoconf" and "automake" were at the 
revision level mentioned in the README file.

I followed the instructions in the INSTALL file.  The installation appeared 
to go smoothly, that is, it completed and didn't have any errors that I could 
see.

However, when I followed the suggestions in the Hamlib FAQ about using 
'rigctl', that's when I discovered that something is amiss.

Typing in 'rigctl --list' returns the following:
freq = 5778699387438942  (or some other meaningless integer)

In fact, no matter what switches I throw with 'rigctl' results in the same 
message.

Clearly, something is not right here.

Any ideas?

Vy 73,
Charlie  N9CO

[Hamlib-developer] Re: Hamlib-developer digest, Vol 1 #338 - 1 msg

[Dale E. E. <de...@w-...>]

Just a little more info in response to Nate's.

> At the moment the FT-920 has both VFO-A/B.  Unfortunately, it's not a
> true dual VFO radio even though it has a sub display similar to other
> dual display rigs.  Thus I added some support for RIG_VFO_MAIN/SUB where
> it made sense to me.
>

My rig has three VFO's.  VFOa, VFOb are on Main, and VFOc is on SUB.
When in Satellite mode its a little different.  My subreceiver is kind of like
an HT with access to the Main memory and antenna ports.  The controls
and TX control which are active have <PTT>/<CTRL> on the LCD .
These are independent so you can Transmit on one and control the other
or just have both on one.  It makes things dicey knowing what to do.

>
> So it would be handy to return a set of flags that indicate VFO/MEM/MEM
> TUNE and SUB/MAIN (by simple definition VFO A = MAIN and VFO B = SUB) to
> rig_get_vfo.

My definitions will support this but it appears that Main/Sub will have to be
independent of VFOa, VFOb, etc...  This will have to be in the backend or
in Caps as Stephane suggested.

I can force PTT/CTRL to always match.  This will work until things get worked
out, but users (me) will quickly get irritated when CTRL or worse PTT gets
moved
somewhere it isn't supposed to be.  Interesting issues.


Thanks.

Dale, kd7eni

vfo_t (Was: Re: [Hamlib-developer] branch_ts2k)

[Nate B. <n0...@ne...>]

Hmmm.

I've been using the RIG_VFO_x macros, but I'm still dense on the
intention.  I wonder if my confusion is with the documentation in rig.h
where a diagram of a byte is shown, but the text uses the term byte
where I suspect bit was meant.

* Stephane Fillod <f8...@fr...> [2003 Mar 03 17:08 -0600]:
 
>   My goal is to kill the band field in vfo_t. To do this, a new field
>   in rig_caps will be created to describe each VFO#, and if it is
>   exclusive with another VFO.
>   Anything else would be done using other API calls (split, weird
>   channel setup), maybe creating new ones.

I'm not opposed to this.  I don't understand the current system, so I'll
try to make sense of any new effort.

> * Anything that's not a VFO is something else, most probably a kind of
>   memory channel. Memory channel numbers can be forged, using negative
>   value for instance.

At the moment the FT-920 has both VFO-A/B.  Unfortunately, it's not a
true dual VFO radio even though it has a sub display similar to other
dual display rigs.  Thus I added some support for RIG_VFO_MAIN/SUB where
it made sense to me.

So it would be handy to return a set of flags that indicate VFO/MEM/MEM
TUNE and SUB/MAIN (by simple definition VFO A = MAIN and VFO B = SUB) to
rig_get_vfo.  Perhaps an unsigned int with the MSB (0x03) could be the
flags byte and the lower three bytes could be used by the backend to 
number the available VFOs.

On the other hand, Dale's idea of making it into a structure may be more
versatile in the long run.  New capability could be added to the struct
as the need arises and this might not break old backends too badly.

>   Please, everyone, comment heavily on this vfo_t design. I'll try to come
>   up with a real patch this week. The vfo_t redesign is the only thing
>   holding me to release hamlib-1.1.4.

Well, there's my short comment.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

[Hamlib-developer] Re: Hamlib-developer digest, Vol 1 #336 - 2 msgs

[Dale E. E. <de...@w-...>]

> Stephane,

Thanks for the quick reply as always.

>
> About your style: fix your code
> * Make it gcc-3.x friendly. Compilation should report NO warning.
>   . Especially printf(__FUNCTION__ " has been called\n"); is not accepted.
>   write instead  printf("%s has been called\n", __FUNCTION__ );
>   . Use C99 intializer
>         instead of    struct { int a; char *b } = { a: 5, b: "bad" };
>         write         struct { int a; char *b } = { .a = 5, .b = "good" };
> * Use doxygen style comments    /*<!  */
>

Most of the initializers were taken from the original kenwood.c and have
been unchanged.  I had just noticed the difference last week, but that
can be changed along with kenwood.c.

> About rig.h changes:
> * anything that has ts2k in a struct name in rig.h has no chance
>   to be merged.  (eg. ts2k_menu_t, ts2k_pm_t, etc.)
> * talking about RIG_RPT_SHIFT_1750, read my past posts

I don't know of any repeaters using the 1750 stuff around here.
It does nothing for me so I'll just drop it.  I just haven't done it yet.

>
> * ts2k menu's are ext_parms, please convert your code to ext_parms interface

When I wrote the ts2k menu's, there were no provisions.  Now there are and
I just haven't updated any of the menu stuff.

> * I dislike the "next" field in you struct channel, but I may agree on
>   some "void *priv" generic purpose field.

The reason I called it "next" is I'd like to add a function to src/rig.c.
It would be something like:
        rig_to_rig(RIG * r_dst, channel_t c_dst, RIG * r_src, channel_t c_src);

The function rig_to_rig() would call rig_get_chan(r_src, c_src)
and then rig_set_chan(r_src, c_src).

I haven't worked out any details yet but it has the potential to solve
several problems.

> * don't rename defines to your liking, you're breaking compatibility.
>   I admit some names were not choosen correctly, but stick with it.

I thought "menu" was much more appropriate than "ext", but point taken.

> * You're messing too much with RIG_VFO's.
>   I'll give you an example: RIG_VFO_AB, it's not gonna work.
>   The gnuradio backend can have many VFO, and real ones, ie. not just
>   "glorified" memories. So how would you define RIG_VFO_BF for
>   VFO_B/VFO_F?  This is broken design.

Actuall, I thought it'd be simple:

   #define     RIG_VFO_BF    RIG_CTRL_SPLIT | RIG_VFO_B | RIG_VFO_F;

but, maybe we don't care to define a zillion "uncommon" vfos so then its

        vfo_t vfo_bf;

        vfo_bf = RIG_CTRL_SPLIT | RIG_VFO_B | RIG_VFO_F;
        vfo_fb = RIG_CTRL_REV | vfo_bf;

>   What I would propose instead is something like this:
>
>   #define RIG_VFO_n(x) (1<<(x))
>   #define RIG_VFO_A RIG_VFO_n(0)
>   #define RIG_VFO_B RIG_VFO_n(1)
>   #define RIG_VFO_C RIG_VFO_n(2)

This is similar to what I've been calling the VFO Minor.
Hey, it even uses the same definition.  I like it!

>   /* the following defines as just aliases */
>   #define RIG_VFO_NONE    0
>   #define RIG_VFO_CURR    -6
>   #define RIG_VFO_MEM     -2
>   #define RIG_VFO_VFO     -3
>   #define RIG_VFO_TX      -4    /* applies to RIG_VFO_CURR */
>   #define RIG_VFO_RX      -5    /* applies to RIG_VFO_CURR */
>   #define RIG_CTRL_MAIN   -7
>   #define RIG_CTRL_SUB    -8

This is what I've been calling VFO Major.

To quote somebody that knows software better than me:
    "It's ugly, it's horrible. I want good quality."

>   My goal is to kill the band field in vfo_t. To do this, a new field
>   in rig_caps will be created to describe each VFO#, and if it is
>   exclusive with another VFO.
>   Anything else would be done using other API calls (split, weird
>   channel setup), maybe creating new ones.

This might work.  Especially if it helps understand what "state" the
rig is supposed to be in when, say, the frequency is changed.  If we
only allow RIG_VFO_CURR the function should *not* have a vfo_t
as a parameter.  What's the point?


>   Please, everyone, comment heavily on this vfo_t design. I'll try to come
>   up with a real patch this week. The vfo_t redesign is the only thing
>   holding me to release hamlib-1.1.4.
>

What about a struct with two fields:
       1) The lower order field would define the applicable VFO's (real or
fake)
             This would be the definition described above for RIG_VFO_A etc...
               and would be the bitmask (a << N);
                I refer to this as VFO minor.
        2)The higher order field would define what state the rig must be in
             for the operation being requested.  Memory, Call, Split, Rev,
etc...
              I refer to this as VFO major.

Having bitmasks available solves many questions.  "How do we specify
Reverse?"  I think this should be tied in with the vfo, not because it tells
us which PLL/VCO is being manipulated, but  tells us what is needed to set the
state external to the PLL/VCO for the proper desired operation.
VFOa (= First PLL) is used for Split, Crossband, Memory, and simplex.
If we have both pairs of data (VFOa,b, or c) and (Split, Sat, Mem, simplex)
we can move the rig from any state to any state and back again without any
loss of information or operator intent!

If we only have VFOa,b,c then we can do nothing but simplex effectively.

Functions will *not* answer this need for information.  If I want to reverse
the function of two VFOs operating as an Rx/Tx pair we say:
        vfo = RIG_CTRL_REV | RIG_SAT_UPLOAD;
        vfo = RIG_CTRL_REV | RIG_VFO_AB;
Should I write:
            rig_set_sat();
            rig_get_sat();
            rig_set_sat_rev();
            rig_get_sat_rev();
            rig_set_split();
             rig_get_split();
            rig_get_mem_split();
            rig_set_mem_split()
            rig_set_split_rev()
            rig_get_split_rev()
            rig_get_crossband()
            rig_set_crossband()
            rig_set_mem_split_rev()
            rig_get_mem_split_rev()

            and the list goes on....

We need the information even if we call rig_set_split();
Is it A/B or B/A?  Having the bitmask answers every
 question we may have.

int mmelter_set_split(RIG *rig, vfo_t vfo)
{
    ...
   if( vfo & RIG_CTRL_REV) {
            // do B/A or C/A or ... or Z/F or ...
    else
            // do A/B or A/C or ... or F/Z or ...
    ...
    return RIG_OK;
}

Yes, we'll almost certainly want to call a few functions
for special modes.  Having called that special function and
mode, we need to know what to do with it!

> Note about CVS repository:
> * please, no autogenerated file (eg Makefile.in, ..) in the CVS base.
> * also, if you're not modifying a HEAD file, do NOT duplicate and
>   check it in your branch! Otherwise, you drift from HEAD, and don't
>   get updated in case of new changes (which was the case).

Somethings wrong with the branch then.  It's probably linked back
to real early releases because from the start I've never gotten the current
hamlib.  It becomes more stagnant all the time.

> > 2) Also, I'm working on a command-line.  You can glance at it and see
> > if you think its going the right direction.  I'd eventually like to have
> [..]
>
> Sorry, I haven't had time to look at it. Fix the 1) first, you have a
> lot to do.

This is just a hobby I do because I really enjoy it.  I'm interested mostly
in the command line.  However, it will have to take the backburner for
a little while.


73's

Dale, kd7eni

Re: [Hamlib-developer] IC-736 backend status and converter power

[Andrea B. <bo...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck Hemker wrote:


| ci-v interfaces have the transmit and receive are tied together on the
ci-v
| side.  Because of this they echo the commands sent to it back to the
computer
| (with or without a radio connected)


Hold it, timeout! ;-)

I forgot to mention one important thing: my circuit and my radio are
working perfectly fine under W2K with the DXLab suite
(http://www.qsl.net/dxlab/download.htm)

The circuit I am using is available online at:
http://www.students.cs.unibo.it/~borgia/Ham

That's why I'm puzzled, because I've already tested the hardware
separetely from hamlib.

Andrea.

- --
Undergraduate student of Computer Science @ University of Bologna
Key fingerprint: 4037 9711 85C6 F9F9 A505  FA0A BB62 3A3C F7BA 9B13
ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE+ZGmOKhgqEyuO+p4RAol1AKDauZTeUbUQUZ1qbu91EyZJrC7s2gCfS+la
d5JcupsxBfuVDfl9YyGQebE=
=1c/9
-----END PGP SIGNATURE-----

Re: [Hamlib-developer] IC-736 backend status and converter power

[Chuck H. <n2...@am...>]

ci-v interfaces have the transmit and receive are tied together on the ci-v
side.  Because of this they echo the commands sent to it back to the computer
(with or without a radio connected)

The reason your getting a RIG_BUSERROR is because hamlib is not seeing the
echo.

That can be caused by several things
1. wrong serial port
2. wrong interrupt
3. problems with ci-v interface
4. radio causing problems on ci-v bus
   (shorted, constant voltage, constant collisions)

One way to check these might be to disconnect the radio from the ci-v bus, and 
either check for a different hamlib error, or see if characters echo in your
favorite serial program.  You might also try disconnecting the radio to see if
there are any changes.

For some reason I couldn't view the URL you gave http://www.g3vgr.co.uk/civ.htm
so I'm not sure if the circuit your using is using a serial driver chip or
something else.

However, if your trying to drive the chip using power from the serial port I
would check the voltages your getting and make sure enough is making it to the
chip.

I started off trying to power my interface from the serial port and decided
after a little checking to power it externally since at least one of my
serial ports was putting out +5 volts and after a diode (in case the pin went
negative) and a voltage regulator (in case the pin was a +12 volts) I wasn't
going to have enough power to drive the chip (because it wasn't a low voltage
chip, it wanted about +5 volts)

I also had a problem where it would work on one computer but not the other and
I finally traced it down to the fact that I mis-read the chip docs and put caps
where this chip wanted jumpers so it was putting out about +-.6 volts.

The RS-232 spec says that:
+3 to +15 is mark
-3 to -15 is space (or is the other way around)
+3 to -3 is undefined

back in the old days things tended to use +12 and -12 to drive the lines and
you could run cables all over the place.  These days many things use +5 and -5
to drive the lines because they assume the things connected are going to be
close by and because it's cheaper.  However this gives you less power to work
with if your trying to power something from the serial port.

I've also included part of an email I sent when I was working on cleaning up
some of the icom error handling.  It probably should end up as part of the
documentation sometime.  However right now it is sort of icom specific.  I'm
not sure where it would go.

Feel free to ask if you have any more questions or problems.

---

As promised, here is my ideas for improved error checking for icom_transaction
and icom_decode.

To make it easier for the user to distinguish between problems, I added two new
error codes (Do you have any better ideas?):

RIG_BUSERROR
  This means something is wrong talking on the CI-V bus.
  (such as transmitted characters did not echo)
  If this is received at program startup, it probably means the computer is not
  talking on the CI-V bus.  (wrong serial port, problems with CI-V interface)

RIG_BUSBUSY
  Detected collision on CI-V bus.

I also used existing error codes:

RIG_ETIMEOUT
  Timeout talking to the radio.
  If this is received at program startup, it probably means there is a problem
  talking to the radio.  (wrong speed, no power to radio, radio not on CI-V)

RIG_EPROTO
  Something else unexpected happened

In doing my quick testing:
1. With the radio off, I got a RIG_ETIMEOUT
2. With the power removed from the CI-V interface, I got a RIG_BUSERROR
3. I caused some collisions and got a RIG_BUSBUSY

Re: [Hamlib-developer] branch_ts2k

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

On Sat, Mar 01, 2003, Dale E. Edmons wrote:
> 1) If you have some time in the near future could you check-out and
> look at  branch_ts2k?  Especially the include/hamlib/rig.h and how
> I added #define's with hooks into rig_newvfo.h.  This would allow
> minimal changes to rig.h and prevents the ts2k stuff from interfering.

The rig_newvfo.h has stricly no chance to be merged with the HEAD.
It's ugly, it's horrible. I want good quality.

Everything that belongs to rig.h should be in rig.h.
I want patches, not a rewrite of the API.
Also keep in mind that it has to be source level compatible, 
if not binary level compatible.

About your style: fix your code
* Make it gcc-3.x friendly. Compilation should report NO warning. 
  . Especially printf(__FUNCTION__ " has been called\n"); is not accepted.
  write instead  printf("%s has been called\n", __FUNCTION__ );
  . Use C99 intializer
  	instead of    struct { int a; char *b } = { a: 5, b: "bad" };
  	write         struct { int a; char *b } = { .a = 5, .b = "good" };
* Use doxygen style comments	/*<!  */

About rig.h changes:
* anything that has ts2k in a struct name in rig.h has no chance 
  to be merged.  (eg. ts2k_menu_t, ts2k_pm_t, etc.)
* talking about RIG_RPT_SHIFT_1750, read my past posts
* ts2k menu's are ext_parms, please convert your code to ext_parms interface
* RIG_FUNC_TSQL and rig_set_ctcss_sql are NOT duplicate! read pas posts
* I dislike the "next" field in you struct channel, but I may agree on
  some "void *priv" generic purpose field.
* don't rename defines to your liking, you're breaking compatibility.
  I admit some names were not choosen correctly, but stick with it.
  Example are: RIG_MODE_WIDE, RIG_MODE_NARROW, tone, dcs, etc.
* You're messing too much with RIG_VFO's. 
  I'll give you an example: RIG_VFO_AB, it's not gonna work.
  The gnuradio backend can have many VFO, and real ones, ie. not just
  "glorified" memories. So how would you define RIG_VFO_BF for
  VFO_B/VFO_F?  This is broken design.
  What I would propose instead is something like this:

  #define RIG_VFO_n(x) (1<<(x))
  #define RIG_VFO_A RIG_VFO_n(0)
  #define RIG_VFO_B RIG_VFO_n(1)
  #define RIG_VFO_C RIG_VFO_n(2)
  /* the following defines as just aliases */
  #define RIG_VFO_NONE    0
  #define RIG_VFO_CURR    -6
  #define RIG_VFO_MEM     -2
  #define RIG_VFO_VFO     -3
  #define RIG_VFO_TX      -4	/* applies to RIG_VFO_CURR */
  #define RIG_VFO_RX      -5	/* applies to RIG_VFO_CURR */
  #define RIG_CTRL_MAIN	  -7
  #define RIG_CTRL_SUB    -8

  My goal is to kill the band field in vfo_t. To do this, a new field
  in rig_caps will be created to describe each VFO#, and if it is
  exclusive with another VFO.
  Anything else would be done using other API calls (split, weird
  channel setup), maybe creating new ones.
* Anything that's not a VFO is something else, most probably a kind of
  memory channel. Memory channel numbers can be forged, using negative
  value for instance.
  Please, everyone, comment heavily on this vfo_t design. I'll try to come
  up with a real patch this week. The vfo_t redesign is the only thing
  holding me to release hamlib-1.1.4.

Note about CVS repository:
* please, no autogenerated file (eg Makefile.in, ..) in the CVS base. 
* also, if you're not modifying a HEAD file, do NOT duplicate and 
  check it in your branch! Otherwise, you drift from HEAD, and don't
  get updated in case of new changes (which was the case).

> 2) Also, I'm working on a command-line.  You can glance at it and see
> if you think its going the right direction.  I'd eventually like to have
[..]

Sorry, I haven't had time to look at it. Fix the 1) first, you have a
lot to do.


Stephane

Re: [Hamlib-developer] IC-736 backend status and converter power

[Andrea B. <bo...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephane Fillod wrote:


| 	rigctl -vvvvvv -Crts_state=ON -m 320
| There's also a config 'dtr_state' param. You can check them all with
| the -L option. Let me know if this solves your powering problem.

Funny thing is, minicom does read some garbage when turning the VFO
knob, so apparently it is not a hw problem, but rigctl doesn't work,
this is what I get:


- -cut-cut-
[andrea@deunan]/local/hamlib-1.1.4cvs-030227/tests$ ./rigctl -vvvvvv -r
/dev/rig -Crts_state=ON -m 320 -L -s 9600
rigctl, Hamlib version 1.1.4cvs-030227
Report bugs to <ham...@li...>

rig:rig_init called
rig: loading backend icom
icom: _init called
rig_register (309)
rig_register (310)
rig_register (311)
rig_register (313)
rig_register (314)
rig_register (319)
rig_register (320)
rig_register (321)
rig_register (330)
rig_register (326)
rig_register (327)
rig_register (347)
rig_register (334)
rig_register (344)
rig_register (335)
rig_register (340)
rig_register (342)
rig_register (304)
rig_register (307)
rig_register (352)
rig_register (353)
rig_register (351)
civaddr: "Transceiver's CI-V address"
~        Default: 0, Value: 64
~        Range: 0.0..255.0, step 1.0
mode731: "CI-V operating frequency data length, needed for IC731 and IC735"
~        Default: 0, Value: 0
rig_pathname: "Path name to the device file of the rig"
~        Default: /dev/rig, Value: /dev/rig
write_delay: "Delay in ms between each byte sent out"
~        Default: 0, Value: 0
~        Range: 0.0..1000.0, step 1.0
post_write_delay: "Delay in ms between each command sent out"
~        Default: 0, Value: 0
~        Range: 0.0..1000.0, step 1.0
timeout: "Timeout in ms"
~        Default: 0, Value: 200
~        Range: 0.0..10000.0, step 1.0
retry: "Max number of retry"
~        Default: 0, Value: 3
~        Range: 0.0..10.0, step 1.0
itu_region: "ITU region this rig has been manufactured for (freq. band
plan)"
~        Default: 0, Value: 2
~        Range: 1.0..3.0, step 1.0
serial_speed: "Serial port baud rate"
~        Default: 0, Value: 9600
~        Range: 300.0..115200.0, step 1.0
data_bits: "Serial port data bits"
~        Default: 8, Value: 8
~        Range: 5.0..8.0, step 1.0
stop_bits: "Serial port stop bits"
~        Default: 1, Value: 1
~        Range: 0.0..3.0, step 1.0
serial_parity: "Serial port parity"
~        Default: None, Value: None
~        Combo: None, Odd, Even
serial_handshake: "Serial port handshake"
~        Default: None, Value: None
~        Combo: None, XONXOFF, Hardware
vfo_comp: "VFO compensation in ppm"
~        Default: 0, Value: 0.000000
~        Range: 0.0..1000.0, step 0.0
rts_state: "Serial port set state of RTS signal for external powering"
~        Default: Unset, Value: ON
~        Combo: Unset, ON, OFF
dtr_state: "Serial port set state of DTR signal for external powering"
~        Default: Unset, Value: Unset
~        Combo: Unset, ON, OFF
rig:rig_open called
Opened rig model 320, 'IC-736'
Backend version: 0.2, Status: New

Rig command: f
TX 6 bytes
0000     fe fe 40 e0 03 fd      ..@...
read_string: timedout without reading a character
get_freq: error = Communication bus error
- -cut-cut-


Where should I look to get a clue of what's going on? I gather you do
not have a 736 so I'll do the tests.

Andrea.

- --
Undergraduate student of Computer Science @ University of Bologna
Key fingerprint: 4037 9711 85C6 F9F9 A505  FA0A BB62 3A3C F7BA 9B13
ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE+Yn1jKhgqEyuO+p4RArI7AJ9SVaIgxNFfOaEJ0Mz8uyYLNxmfiACgjpM+
kGvIx4ixPRPZAPerouWkYQw=
=iPvl
-----END PGP SIGNATURE-----

[Hamlib-developer] branch_ts2k

[Dale E. E. <de...@w-...>]

Stephane,

1) If you have some time in the near future could you check-out and
look at  branch_ts2k?  Especially the include/hamlib/rig.h and how
I added #define's with hooks into rig_newvfo.h.  This would allow
minimal changes to rig.h and prevents the ts2k stuff from interfering.

2) Also, I'm working on a command-line.  You can glance at it and see
if you think its going the right direction.  I'd eventually like to have
it
be called during startup to process .hamlibrc or some such.  It should
also be callable by user routines.  I haven't tried the 'pure-parser'
for re-entrant routines yet.  Also, the flex scanner is set as 'always-
interactive' for use as a command-line parser.  This conflicts with
its use as start-up command processor.  The files live in tests/rc.

I don't know if you can use scanner.l (flex) for rigctl.  If you look at

the code (very bleeding edge, with lots of sharp edges!) you can tell
me things that you'll need or would like to have.  I'll be working on
it as soon as I get my ts2k.c re-write finished.

3)  Last but not least, I've written ts2k_cmds.[ch] which implement
all of the commands available for the TS-2000 except the 'ex;'
command for setting menu options.  These are very nice to use
so that you only worry about parameters (p1, p2,...) and not about
the exact implementation and quirks.  When a bug is fixed it fixes
all code and saves alot of duplication.   I presume others backends
can use them.  The only thing they know about hamlib is:
    a) ts2k_transaction() which can easily be replaced.
    b) RIG * required for the ts2k_transaction.
They simply read/write rig commands and place them in a
parameter struct.  Any ideas or comments will be welcome.

73's
Dale, KD7ENI

[Hamlib-developer] [Fwd: Re: GUI blocking]

[Joop S. <pa...@de...>]

Here is Wilbert's reply. I think he got nuked by the no-subscribe
filters on the mailing lists because of his reply address.

[Hamlib-developer] Re: GUI blocking

[Wilbert K. <zl...@zl...>]

Hi Joop(and others)

> Do you happen to know the baud rate of the USB hub? 


The notebook I use has a built-in OHCI root hub.
Plugged into that is the Keyspan USB 4-port serial adapter.

Having studied the proc_usb_info.txt file, I reckon the root hub talks to
the kernel at 12 Mbd, and the 4-port serial adapter also runs at 12 Mbd.

Here is the low-down on the root hub:

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB OHCI Root Hub
S:  SerialNumber=c4a7b000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

Funnily enough, the B: tag shows 0% bandwidth.
The E: tag shows a max packet size of 2, and interval time of 255 ms,
which seems a bit slow.

Anyway, hanging off the root hub is the 4-port serial adapter:

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs=  4
P:  Vendor=06cd ProdID=010a Rev= 0.00
S:  Manufacturer=Keyspan, a division of InnoSys Inc.
S:  Product=USB 4-port Serial Adapter
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs=14 Cls=ff(vend.) Sub=00 Prot=00 Driver=serial
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=  1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=  1ms
E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=  1ms
E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=  1ms
E:  Ad=85(I) Atr=02(Bulk) MxPS=  64 Ivl=  1ms
E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=  1ms
E:  Ad=87(I) Atr=02(Bulk) MxPS=  64 Ivl=  1ms

Not sure what the 14 'end points' refer to, there are only 4 ports in
the device. Perhaps they are DCD, RTS etc etc, for one port.

It may be easier to grab a scope from work next week and to take a look
at the rig's bus (the CAT CI-V bus) whilst I fiddle with the code.

>It would also be
> interesting to know what kind of rig you are using, so we can check you
> rig's timeout setting.

The radio is an IC-725 (#314) and runs at 1200 bd

> The only reason for collisions I can think of, is the rig still sending
> information while xlog already demands for the next information. So this
> would mean the timing is still too fast. But I might be wrong here....

Yes, I am pretty sure that's what is happening. XLOG polls the rig just
as I tune it, resulting in a bus collision. Anyway, with your new
parameters, XLOG recovers from that, after a second or so.

Come to think of it, you should not have to poll the rig at all. When I
tune around, it will broadcast the new QRG.

I am not sure how you would deal with this. It is really a hamlib issue
:-)

> Thanks for trying. I have to think about finding a neat way to avoid GUI
> blocking in future versions of xlog.

OK...aside from the error messages in the status bar, it's working pretty
well now!


73,

Wilbert, ZL2BSJ

[Hamlib-developer] Re: GUI blocking

[Joop S. <pa...@de...>]

Op vr 28-02-2003, om 12:55 schreef Wilbert Knol:
> Hi Joop,
> 
> Sorry for the delay in testing your XLOG mods. I have just installed
> Stephane's latest hamlib CVS snapshot, and I am back in business with
> hamlib.
> 
> I made the code changes you suggested, increasing the times to 1000 ms,
> and it seems to have worked: no more frozen GUI!
> 
> I am using a Keyspan USB<>RS232 hub for rig control, and I can see the
> LED double-blink once a second (the XLOG query and the rig reply, I guess)
> so that's OK.
> 

Do you happen to know the baud rate of the USB hub? It would also be
interesting to know what kind of rig you are using, so we can check you
rig's timeout setting.

> However, when I turn the dial on the rig, XLOG reports 'bus collisions'
> and 'protocol errors' (hamlib errors 14 and 8, respectively). I know that
> the rig sends out the new QRG when I tune it, and maybe that causes a bus
> collision.
> 

The only reason for collisions I can think of, is the rig still sending
information while xlog already demands for the next information. So this
would mean the timing is still too fast. But I might be wrong here....

> In any case, it is not fatal, and XLOG correctly displays the new QRG
> after a few seconds, so it's looking much better now!
> 

Thanks for trying. I have to think about finding a neat way to avoid GUI
blocking in future versions of xlog.

> 73,
> 
> 
> Wilbert.
> 
> 
> 
> 

Regards,
Joop, PA4TU

Re: [Hamlib-developer] serial ports and hamlib

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

On Tue, Feb 25, 2003, Wilbert Knol wrote:
> Yes, if you have time, I would appreciate a CVS snapshot . The office 
> fire-wall stops me from using CVS.

I know what it is.
There you are, http://hamlib.org/bleeding-edge/hamlib-1.1.4cvs-030227.tar.gz

> > sure, very nice idea. Easier to say than to do. Maybe we should borrow
> > some configure.ac magic from alsa or other project.
> 
> I suspected it would not be too easy. But it is one of the features I really 
> like in ALSA. It certainly cuts down compilation time.

yep, one day, when more important API design will be firmed up first.
(contribution welcome anyway ;)

73
Stephane

Re: [Hamlib-developer] serial ports and hamlib

[Joop S. <pa...@de...>]

Op do 27-02-2003, om 00:36 schreef Stephane Fillod:

> The other solution, more common, is to make the application
> multi-threaded (or at least multi-programmed). This way, the GUI main
> loop is not blocked by the delayed reponse. However, the developer has to
> pay attention to proper locking within shared data structures...
> 

Without using multi-threading, you could fork a copy of the main program
and have data transactions take place in the background. The main
program listens on a pipe. Should not be too difficult....

> Now, I cannot see Hamlib to be asynchronous wrt transaction type
> commands in the forseable future...
> 
> Comments?
> 
> 
> Cheers,
> Stephane
> 
> 

Regards,
Joop

Re: [Hamlib-developer] New RPMs for hamlib 1.1.3

[Alexandru C. <al...@ph...>]

Done. I have also included the source RPM.

Alex.

On Thu, 2003-02-27 at 00:47, Stephane Fillod wrote:
> On Wed, Feb 26, 2003, Alexandru Csete wrote:
> > I have built new RPMs for Red Hat using the spec file from Joop. I could
> > not build the hamlib++ RPM though (I had to disable the C++ bindings). I
> > think that's an old bug, which has been fixed since.
> > Should I upload the RPMs to the SF upload server?
> 
> yes please, go ahead since you're release tech.
> 
> 
> Stephane
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Proper API implementation for Rotor-EZ

[Nate B. <n0...@ne...>]

* Stephane Fillod <f8...@fr...> [2003 Feb 26 18:05 -0600]:
> If a protocol has no provision for rot_move, well the backend is not
> obliged to implement it. I would say, rot_move is for rotators who cannot
> implement rig_set_position.

Ahhh, so they are complimentary.  Why didn't I think of that?  :-\

> easycomm has both. Just implement what the protocol can do and
> that should do it.

It's working, so I won't change rotorez.

> Sure, you'd be very welcome!

I'll do that.  I'm hacking rotorez again now that some spare time has
returned.  

When I get this done I can get back to the ft920.  Sometime, hopefully 
by the next century or so, I'll have the '920 mostly complete.  I did 
what I thought were a bunch of code cleanups in ft920.c and hopefully 
caught a few bugs that were in earlier revisions.  So far no one has 
complained. :-)

I have not yet had a chance to test the code since you made the change
to RIG_VFO_CURR, but I don't think it should be a problem...

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

Re: [Hamlib-developer] Proper API implementation for Rotor-EZ

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

On Tue, Feb 25, 2003, Nate Bargmann wrote:
[..]
> However, the Rotor-EZ and DCU-1 (Hy-Gain) interfaces do not support what
> I gather to be the rot_move function's idea of direction (CW, CCW, Up or
> Down) nor a rotational speed.  So, to use rot_move any passed values
> would be ignored and a static command sent to the interface.

If a protocol has no provision for rot_move, well the backend is not
obliged to implement it. I would say, rot_move is for rotators who cannot
implement rig_set_position.

> So, what is the intent of the API?  Is the application code expected to 
> call rot_set_position and then rot_move for positioning to actually occur?

no, rot_set_position is all what an application can need.
Applications are supposed to use either one exclusively, depending
on what they need to do.
Actually, the rot_move tries to mimic the manual CW and CCW paddles.
That comes handy when you want to sweep the horizon, hear a signal and
come back on it by "interpolation", i.e. you don't knwo the az/el in
advance.

> I see that fodtrack uses just rot_set_position while easycomm uses
> rot_move.  So, whichever why I go will set a 2 to 1 preference.

easycomm has both. Just implement what the protocol can do and
that should do it.

> I'd be happy to add comments to rotator.c to make this more clear.  :-)

Sure, you'd be very welcome!


Cheers,
Stephane

Re: [Hamlib-developer] New RPMs for hamlib 1.1.3

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

On Wed, Feb 26, 2003, Alexandru Csete wrote:
> I have built new RPMs for Red Hat using the spec file from Joop. I could
> not build the hamlib++ RPM though (I had to disable the C++ bindings). I
> think that's an old bug, which has been fixed since.
> Should I upload the RPMs to the SF upload server?

yes please, go ahead since you're release tech.


Stephane

Re: [Hamlib-developer] serial ports and hamlib

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

On Tue, Feb 25, 2003 at 11:13:53AM +0100, Alexandru Csete wrote:
> Yes, exactly. I was thinking of solving this problem by having ONLY ONE
> "main loop" interacting with Hamlib continuously, waiting politely for
> slow connections and timeouts, and storing the read/set values in shared
> memory which can be accessed by the rest of the application. This will
> probably introduce some delay between the set and get values, but it's
> still better than having a blocked GUI.

kind of poll in main loop?

> As long as we have a direct link between Hamlib and a GUI, there will
> always be the possibility of this to-way struggle: An aggressive GUI
> might easily overload Hamlib, which in turn will block the GUI. 
> If we want to avoid such things in the long run, we should work toward
> the client/server scheme, where we have a well designed server daemon
> talking to Hamlib in one end, and accepting requests from clients
> through pipes and/or sockets in the other end. The rpc.rigd may already
> fulfill some of this.

nope, the RPC backend won't be better either. The problem here is
latency of synchronous protocols in general (command ... delay ... response).

One solution is to make Hamlib asynchronous wrt to protocol handling,
using either signal handler or poll in a main loop.
This way you don't block waiting for the response. Event driven application
is a nice concept, but not so easy to implement because the need of a state
machine, and your main loop is nothing else but a degenerated "scheduler".

The other solution, more common, is to make the application
multi-threaded (or at least multi-programmed). This way, the GUI main
loop is not blocked by the delayed reponse. However, the developer has to
pay attention to proper locking within shared data structures...

Now, I cannot see Hamlib to be asynchronous wrt transaction type
commands in the forseable future...

Comments?


Cheers,
Stephane

[Hamlib-developer] New RPMs for hamlib 1.1.3

[Alexandru C. <al...@ph...>]

Hi,

I have built new RPMs for Red Hat using the spec file from Joop. I could
not build the hamlib++ RPM though (I had to disable the C++ bindings). I
think that's an old bug, which has been fixed since.
Should I upload the RPMs to the SF upload server?

Alex, OZ9AEC