Hamlib for OS X?

Hi there,

I am wondering if you have any intention of releasing an OS X port of
Hamlib.

Or if you know if anyone is porting it to OS X.

thanks
73s de
Bernard
EI8FDB

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Bandpass semantics

Re: Bandpass semantics

Hi Martin,

On 4/6/06, Martin, AA6E <martin.ewing <at> gmail.com> wrote:
> Looks like I need to extend the TenTec Orion backend a little. I am trying
> to understand the meaning of the bandwidth adjustment options - as they
> would apply to the Orion, but probably other rigs, too.
>
> The Orion provides two passband adjustments "BW" and "PBT".  BW is the
> overall bandpass width.  This is now implemented through the set_mode()
> function.   PBT is a passband offset.  Both of these are adjustable in 10 Hz
> increments.  (DSP is nice.) PBT is not currently implemented for the Orion,
> as far as I tell.

If PBT is simply the passband offset, then it is practically the same
as IF shift (RIG_LEVEL_IF?). If I understand it correctly, twin PBT
shifts separately the inside and outside passbands (whatever they may
be), thus allowing to narrow or widen the effective passband. Only
when you shift both PBT_IN and PBT_OUT simultaneously are you shifting
the entire IF.

> I want to know how to deal with the Orion PBT.  The only piece of the API
> that seems to possibly apply is RIG_LEVEL_PBT_IN and RIG_LEVEL_PBT_OUT, but
> they range from 0 --> 1.0.

If the Orion PBT simply shifts the passband I would use RIG_LEVEL_IF
(unless it is meant for something else than IF shift, I can't tell).
PBT_IN and PBT_OUT I would only use for rigs with twin PBT.
As for the range, well, you can imagine that different rigs have very
different ranges for their level settings. Therefore, I think it was a
very good idea to introduce this uniform range in the hamlib API and
leaving it for the backend  to scale the values properly.
If you want to go all the way, there is the possibility to define
granularity tables in the rig_caps for all supported levels. That can
help the frontends to convert the 0..1 range to human readable ranges


> I could make a guess what to do, but could we have an authoritative
> statement of what the relationship of set_mode and these two levels is
> supposed to be?

I leave to authoritative statement to someone else, but I can give you
my understanding.
The passband width is what would correspond to a specific crystal
filter in a non-dsp rig.  Usually, the rig has different set of
filters for different modes and that is why mode and passband go
together in the same API call. In DSP rigs, you may have variable
passband width regardless of mode and so this link between mode and
passband width may not make much sense.
PBT and IF shift, on the other hand, have always been independent of
the mode (except that they may not be available in modes like FM) and
so there is no particular link between the mode and the PBT setting.

>
> And then there are passband_{narrow|normal|wide}.  What are these supposed
> to mean in a DSP rig?  We can just pick some good values, I suppose.

For a DSP rig with variable pass band width you can just pick some
good values, depending on the mode, for example 250Hz, 500Hz and
2.3kHz would be apropriate for CW.

> Thanks!
>
> 73 Martin AA6E
>
> --
>  martin.ewing <at> gmail.com - AA6E <at> arrl.net
> President, Yale University Amateur Radio Club - W1YU
> http://blog.aa6e.net

73
Alex OZ9AEC

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642

Re: Bandpass semantics

Re: Bandpass semantics

Alinco dx 77t test

Re: Bandpass semantics

On 4/6/06, Martin, AA6E <martin.ewing <at> gmail.com> wrote:
> Alex,
>
> Thanks for bringing RIG_LEVEL_IF to my attention.  I had skipped over this,
> thinking it should mean "IF gain"!  Maybe this is the logical parameter to

Well, this is to be confirmed, since it may well be intended to be IF
gain, I'm not sure. On the other hand, I don't see any other way to
modify IF shift.

> use.  Is it correct that the mode bandpass and Level_IF (if available)
> includes all the functionality of PBT_IN and PBT_OUT plus
> narrow/normal/wide?

Probably so, although there may be some difference seen from an
engineering point of view.

> It seems to me there might be a problem in the Hamlib model.  If the API
> permits multiple ways to specify the same information (bandpass), and if not
> all the backends support all the methods, what is the Hamlib user to do?

Yes, heh, good question... The source to this confusion is the way
rigs have evolved. On one hand we have the traditional analogue radios
with expensive crystal filters with fixed narrow/normal/wide band
widths. Some of them may have additional passband tuning options
and/or IF shift.
On the other hand we have the new radios with 32bit IF DSP where the
band width is just a simple parameter in the firmware and the
traditional narrow/normal/wide concepts are no longer well defined (I
don't even dare to mention software defined radios). Hamlib tries to
support all of these radios equally well. At the end, the user should
be able to choose the apropriate controls having knowledge of his/her
radio.

> In an ideal world, we would define a virtual machine with its virtual (and
> non-overlapping, i.e. "orthogonal") bandpass controls, and have each backend
> implement the the VM as completely as possible.  Having these competing
> bandpass semantics seems to make this harder.

I agree that there is room for improvements. Keep the ideas around for
hamlib 2.0 

> Or maybe I'm missing something?  It would help if I had the time to analyze
> how all the other backends have handled these issues.  On the other hand,
> it's not fair to ask each backend person to have to know what all the others
> are doing.  We need a firm spec that we can all work toward.  Maybe I'm
> still displaying my ignorance!
>
> I note that the Orion itself is schizophrenic about bandpass settings.  On
> the front panel, you have a choice of setting "BW" and "PBT" *and* "Low cut"
> and "Hi cut".  Either set of adjustments results in the appropriate changes
> in bandwidth and IF shift, which are the numbers shown on the LCD display.
> (The ASCII interface has only one way to set the parameters, fortunately.)
>
> 73 Martin AA6E
>

73
Alex OZ9AEC

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642

Re: [BSD-Ham] Hamlib on amd64

On Thu, Apr 06, 2006 at 08:37:51PM +0100, Matt Dawson wrote:
> On Thursday 06 April 2006 14:51, Matt Dawson wrote:
> > OK, I'll give your port a go and then report back.
>
> So far, here's where I'm up to. I've installed 1.2.4 from Diane's tarball and
> tried a bit of tweaking. I still get a bus error and a core dump.

We finally tracked it down.

about line 137 of kenwood.c in ..../hamlib/work/hamlib-1.2.4/kenwood

int
kenwood_transaction (RIG *rig, const char *cmdstr, int cmd_len,
                                char *data, size_t *datasize)
{

Note size_t *datasize
...
transaction_read:
    memset(data,0,*datasize);
...

int kenwood_get_vfo(RIG *rig, vfo_t *vfo)
{
                unsigned char infobuf[50];
                int info_len, retval;

                info_len = 50;
                retval = kenwood_transaction (rig, "IF;", 3, infobuf, &info_len)
;
...
note int info_len;

sizeof(int) != sizeof(size_t) on amd64

sizeof(int) is 4
sizeof(size_t) is 8
This caused the core.

It's throughout the code, so I will be filing a bug report on sourceforge.
I've cc'ed hamlib-developers as well, hoping it goes through.

73 Diane VA3DB

--
- db <at> db.net http://www.db.net/~db

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Alinco dx 77t test

John,

You can download the latest release of hamlib from the SourceForge project page
http://sourceforge.net/projects/hamlib/
(there is the big green button)

73
Alex OZ9AEC

On 4/7/06, John C Jones <john.jones <at> louisville.edu> wrote:
>
> Hi
>
> I have an Alinco DX 77T and I would like to test your software. Can you send
> me a copy or tell me where I can download it.
>
>
>             Thanks
>
>
>                            John C. Jones
>
>                          KE4-MWL
>

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642

int to size_t transitions

Hello guys,

the current hamlib version has serious issues when using 'int', while we
should be using size_t. Quoting from a mail by Matt Dawson:

sizeof(size_t) != sizeof(int) on amd64. The former is eight bytes and
the latter is four. On i386 they're both four bytes, which is why it
worked on that arch.

This will cause rig communication to fail on some architectures. So if
you maintain any of the rigs, please start fixing those lines. If you
are using a recent gcc version, the warning seen is for example:

warning: pointer targets in passing argument 4 of 'icom_transaction'
differ in signedness

Regards,
Joop PG4I

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642