hamlib-developer — hamlib developers forum

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

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

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

Hello.

I'm trying to get rigctl to talk to my IC-736 but I can't get it to work
so I wonder: is it really supported?

~From reading the sources of 1.1.3 I think it is, but I can't find out
how to tell hamlib/rigctrl to toggle RTS always-on to supply power to my
homemade converter, not even in the ml archives.

TIA to anyone who can help me,
73 de Andrea IZ4FHT.

- --
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+Uk5MKhgqEyuO+p4RAimIAKCaWk2yrIVSe3ZrgBels/lfUzRwIQCgl4jA
+VRbZpOPK0tqVxD8TGCqqo0=
=AYx8
-----END PGP SIGNATURE-----

[Hamlib-developer] Rotator API

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

Hi,

I am currently adding rotator support to grig and I have a couple of
questions to the rotator API. First, the rot_reset function needs an
integer parameter besides the usual *rot structure. What is the purpose
of this integer? The API says it's "The reset operation to perform" but
what are the choices? Is there a "safe, universal value"?
Second, the rot_move function needs to know the speed, which can be
between 1..100. Does the speed have a physical unit, or is the value
specific to the back end?

Alex, OZ9AEC

Re: [Hamlib-developer] Fun with RotorEZ

[Orv B. <or...@or...>]

Thanks, Alex!  I promise to beat all the bugs out of it for you  ;-)

73 - Orv - W6BI


On Fri, 2003-02-14 at 03:34, Alexandru Csete wrote:
> On Thu, 2003-02-13 at 01:36, Orv Beach wrote:
> >
> > Are there any GUI front ends extant for rotor control?
> >
> 
> I started to add rotator support to Gnome RIG a couple of months ago,
> but I had to stop then. I've got a prototype for a rotator widget (see
> attached screen shot), but it is not functional yet. I will try to
> finish it as soon as possible and get back to you when it's done.
> 
> 73,
> Alex, OZ9AEC
-- 
Orv Beach <or...@or...>

Re: [Hamlib-developer] Fun with RotorEZ

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

On Thu, 2003-02-13 at 01:36, Orv Beach wrote:
>
> Are there any GUI front ends extant for rotor control?
>

I started to add rotator support to Gnome RIG a couple of months ago,
but I had to stop then. I've got a prototype for a rotator widget (see
attached screen shot), but it is not functional yet. I will try to
finish it as soon as possible and get back to you when it's done.

73,
Alex, OZ9AEC

[Hamlib-developer] CVS RotorEZ results

[Orv B. <or...@or...>]

Nate, Stephane - thanks for the pointers on working with CVS code.  My
excuse for not reading the README.developers is that in no way do I
consider myself a developer  :-)   But I read it, followed it, and got a
successful compile.

Nate, here's some results from the latest RotorEZ code.

You'll note that while most things are looking pretty good now, there's a 
offset between what's sent to the rotor, and what's received back.  I
don't know if that's just conversion error or what.  It does seem to get
larger as the azimuth gets larger.  That could just be linear error in the
direction resistance coming down from the rotor, though..

I'll do a little more investigation when I get into the shack, probably
tomorrow.  (I'm doing this from work - putty is your friend  :-D  )

73 - Orv - W6BI

---------------------

[obeach@jake tests]$ ./rotctl -m 401 -r /dev/ttyS0 -s 4800 -vvvv
rot:rot_init called
rot: loading backend rotorez
initrots_rotorez called
rot_register (401)
rot_register (402)
rot_register (403)
rotorez_rot_init called
rot:rot_open called
Opened rot model 401, 'Rotor-EZ'

Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 30 34 33    ;043
rotorez_rot_get_position: "043" after conversion = 43.0
rotorez_rot_get_position: azimuth = 43.0 deg; elevation = 0.0 deg
Azimuth: 43.000000
Elevation: 0.000000
Rot command: P
Azimuth: 0000
Elevation: 000
rotorez_rot_set_position called
rotorez_send_priv_cmd called
TX 7 bytes
0000     41 50 31 30 30 30 3b   AP1000;
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 4d 31 3b    AM1;

Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 33 36 30    ;360
rotorez_rot_get_position: "360" after conversion = 360.0
get_pos: error = Invalid parameter  <---  'cause I sent 4 digits??

Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 30 30 30    ;000
rotorez_rot_get_position: "000" after conversion = 0.0
rotorez_rot_get_position: azimuth = 0.0 deg; elevation = 0.0 deg
Azimuth: 0.000000
Elevation: 0.000000
Rot command: P
Azimuth: 090
Elevation: 000
rotorez_rot_set_position called
rotorez_send_priv_cmd called
TX 7 bytes
0000     41 50 31 30 39 30 3b   AP1090;
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 4d 31 3b    AM1;

Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 30 38 39    ;089
rotorez_rot_get_position: "089" after conversion = 89.0
rotorez_rot_get_position: azimuth = 89.0 deg; elevation = 0.0 deg
Azimuth: 89.000000
Elevation: 0.000000
Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 30 38 39    ;089
rotorez_rot_get_position: "089" after conversion = 89.0
rotorez_rot_get_position: azimuth = 89.0 deg; elevation = 0.0 deg
Azimuth: 89.000000
Elevation: 0.000000
Rot command: P
Azimuth: 090
Elevation: 000
rotorez_rot_set_position called
rotorez_send_priv_cmd called
TX 7 bytes
0000     41 50 31 30 39 30 3b   AP1090;
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 4d 31 3b    AM1;

Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 30 38 39    ;089
rotorez_rot_get_position: "089" after conversion = 89.0
rotorez_rot_get_position: azimuth = 89.0 deg; elevation = 0.0 deg
Azimuth: 89.000000
Elevation: 0.000000
Rot command: P
Azimuth: 100
Elevation: 000
rotorez_rot_set_position called
rotorez_send_priv_cmd called
TX 7 bytes
0000     41 50 31 31 30 30 3b   AP1100;
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 4d 31 3b    AM1;

Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 30 39 39    ;099
rotorez_rot_get_position: "099" after conversion = 99.0
rotorez_rot_get_position: azimuth = 99.0 deg; elevation = 0.0 deg
Azimuth: 99.000000
Elevation: 0.000000

Rot command: P
Azimuth: 270
Elevation: 000
rotorez_rot_set_position called
rotorez_send_priv_cmd called
TX 7 bytes
0000     41 50 31 32 37 30 3b   AP1270;
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 4d 31 3b    AM1;

Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 32 37 33    ;273
rotorez_rot_get_position: "273" after conversion = 273.0
rotorez_rot_get_position: azimuth = 273.0 deg; elevation = 0.0 deg
Azimuth: 273.000000
Elevation: 0.000000
Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 32 37 33    ;273
rotorez_rot_get_position: "273" after conversion = 273.0
rotorez_rot_get_position: azimuth = 273.0 deg; elevation = 0.0 deg
Azimuth: 273.000000
Elevation: 0.000000
Rot command: p
rotorez_rot_get_position called
rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 32 37 33    ;273
rotorez_rot_get_position: "273" after conversion = 273.0
rotorez_rot_get_position: azimuth = 273.0 deg; elevation = 0.0 deg
Azimuth: 273.000000
Elevation: 0.000000

Re: [Hamlib-developer] CVS make problem.

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

On Thu, Feb 13, 2003, Orv Beach wrote:
> I checked out the latest hamlib CVS files (thanks for the guidance,
> Nate!), ran autogen.sh, then ran make.  I got the following error:
> 
> make[1]: Entering directory `/tmp/hamlib/lib'
> make[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'.
>  Stop.
> make[1]: Leaving directory `/tmp/hamlib/lib'
> make: *** [all-recursive] Error 1

your cvs checkout looks fine. I would bet the wrong autoconf/automake version
has been used. Make sure you have at least the following versions:

* autoconf               2.54                   # autoconf --version
* automake               1.5                    # automake --version

and update them/modify autogen.sh accordingly. 
All that is explained in the README.developer file.


Note about GUI for rotators: you can write your own in C or C++ using
gtk, kde, ... Or easier, a simple tcl/tk script would do the trick!


Cheers,
Stephane

Re: [Hamlib-developer] CVS make problem.

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

* Orv Beach <or...@or...> [2003 Feb 13 16:14 -0600]:
> I checked out the latest hamlib CVS files (thanks for the guidance,
> Nate!), ran autogen.sh, then ran make.  I got the following error:
> 
> make[1]: Entering directory `/tmp/hamlib/lib'
> make[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'.
>  Stop.
> make[1]: Leaving directory `/tmp/hamlib/lib'
> make: *** [all-recursive] Error 1
> 
> 
> Did I do something wrong?  (I'm a CVS rookie, I'm afraid).

Probably not.  Look at README.developer and compare the versions
recommended in section 1.2 of that document with the versions installed
on your system.  This happened to me as well and I had to make some
updates.  Also, I run autogen.sh with the options listed in section 1.3.

After doing this, try running 'make distclean' and that should remove
all of the auto generated files.  Then run autogen.sh per
README.developer.

By being careful to match the recommended versions, I have no problem.
In fact, after I check in a new or updated piece of code I rebuild the
entire project again just to be sure my changes didn't break anything.

I've heard a number of horror stories over the years about the
instability of CVS checkout code.  I suppose this could happen here, but
so far the Hamlib developers have been very careful to avoid breaking
the CVS repository code.  I'm pleased to have been involved with this
project for about two years now.

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] CVS make problem.

[Orv B. <or...@or...>]

I checked out the latest hamlib CVS files (thanks for the guidance,
Nate!), ran autogen.sh, then ran make.  I got the following error:

make[1]: Entering directory `/tmp/hamlib/lib'
make[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'.
 Stop.
make[1]: Leaving directory `/tmp/hamlib/lib'
make: *** [all-recursive] Error 1


Did I do something wrong?  (I'm a CVS rookie, I'm afraid).

Thanks.

Orv - W6BI
or...@or...

Re: [Hamlib-developer] FBSD try Compiling

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

On Wed, Feb 12, 2003, Sebastian Yepes [ESN] wrote:
> uname -a
> 
> FreeBSD wire.x123.info 4.7-STABLE FreeBSD 4.7-STABLE #2: Sun Feb  9 22:27:49 
> GMT 2003     ro...@wi...:/usr/obj/usr/src/sys/MYK4.7  i386
> 
> 
> 
> sh autogen.sh --disable-static --with-tcl=/usr/local/lib/tcl8.3
> 
> /usr/local/bin/gm4: configure.in: No such file or directory
                      ^^^^^^^^^^^^
You must be running the wrong version of automake.
Please, make sure to read the README.developer, esp. the section on
required versions:
* autoconf               2.54                   # autoconf --version
* automake               1.5                    # automake --version

then update your package/modify your autogen.sh accordingly.

Otherwise, if you don't want to bother about these tools, 
just download an out-of-the-shelf snapshot at
http://hamlib.org/bleeding-edge/hamlib-1.1.4cvs-030210.tar.gz
and let us know.

Cheers,
Stephane

Re: [Hamlib-developer] RotorEZ 'p' command results

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

Hi Orv.

Please grab the latest CVS code if you can.  Hopefully the fixes are
correct.  Without units to test and ambiguous documentation...

Please run it through the wringer.

Oh well, that's why ham radio coding is such a blast, right?  Right?

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] RotorEZ 'p' command results

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

Thanks for that output, Orv.  That will help very much.  It's obvious
that I should also make sure that the reported elevation is 0 degrees as
it appears rotorez only supports azimuth.  Also, while the code is
ignoring the semi-colon, it's presence as part of the string is sure to
cause a bug at some point.  Then again, the atof function that converts
the string to a floating point value probably strips it, but...

Thanks Orv!

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] Compile in FreeBSD

[Sebastian Y. [ESN] <es...@x1...>]

Hi all can any 1 plz help me out i really need to compile the HamLib in my 
FreeBSD.. i have sent my compile errors to this list..

ThanX

-- 


/*
 @@@@@@@   @@@@@@ @@@@@@@ 
 @@!  @@@ !@@     @@!  @@@
 @!@!@!@   !@@!!  @!@  !@!
 !!:  !!!     !:! !!:  !!!
 :: : ::  ::.: :  :: :  : 
 The Power To Kill LinuX
*/

Re: [Hamlib-developer] RotorEZ 'p' command results

[Orv B. <or...@or...>]

On Wed, 2003-02-12 at 14:44, Nate Bargmann wrote:
[SNIP]
> 
> Very interesting, Orv!
> 
> So, it appears the semi-colon is the first character of the returned
> string.  Of course it moves to the right on each successive read as
> there are always characters left in the buffer from previous commands
> (1, then 2, then 3, and so on).
> 
> Can you edit rotorez/rotorez.h, line 34 and change the line:
> 
> #define AZ_READ_LEN 3
> 
> to
> 
> #define AZ_READ_LEN 4
> 
> for me?
> 
> Then you should see consistent strings reported on the line below RX 4
> bytes.  It will do no harm to set it higher, say 5 or 6 as the read
> function will merely have wait the time out time.
> 
> Please post that output and I should be able to fix it tonight.
> 
> 73, de Nate >>

DONE.  I changed it to 4, and it looks like that fixed it.   The azimuth
readout is now correct and consistent.

Notice that I read it out several times and it showed 333 degrees on all
tries.

I then commanded the rotor to turn to 0 degrees.  The readbacks after
that consistently show it at 0 degrees (well, 359 degrees, which is
rounded to 0).

Nice work, Nate!

73 - Orv W6BI -

[obeach@jake hamlib-1.1.4cvs-030210]$ cd tests
[obeach@jake tests]$ ./rotctl -m 401 -s 4800 -r /dev/ttyS0 -vvvv
rot:rot_init called
rot: loading backend rotorez
rotorez: initrots_rotorez called
rot_register (401)
rot_register (402)
rot_register (403)
rotorez: rotorez_rot_init called
rot:rot_open called
Opened rot model 401, 'Rotor-EZ'

Rot command: p
rotorez: rotorez_rot_get_position called
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 33 33 33    ;333
rotorez: azimuth = 0.0 degrees
Azimuth: 0.000000
Elevation: 33.519203
Rot command: p
rotorez: rotorez_rot_get_position called
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 33 33 33    ;333
rotorez: azimuth = 0.0 degrees
Azimuth: 0.000000
Elevation: 33.519203
Rot command: p
rotorez: rotorez_rot_get_position called
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 33 33 33    ;333
rotorez: azimuth = 0.0 degrees
Azimuth: 0.000000
Elevation: 33.519203
Rot command: P 000
Azimuth: Elevation: 000
rotorez: rotorez_rot_set_position called
rotorez: rotorez_send_priv_cmd called
TX 7 bytes
0000     41 50 31 30 30 30 3b   AP1000;
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 4d 31 3b    AM1;

Rot command: p
rotorez: rotorez_rot_get_position called
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 33 35 39    ;359
rotorez: azimuth = 0.0 degrees
Azimuth: 0.000000
Elevation: 33.519203
Rot command: p
rotorez: rotorez_rot_get_position called
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 33 35 39    ;359
rotorez: azimuth = 0.0 degrees
Azimuth: 0.000000
Elevation: 33.519203
Rot command: p
rotorez: rotorez_rot_get_position called
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 4 bytes
0000     3b 33 35 39    ;359
rotorez: azimuth = 0.0 degrees
Azimuth: 0.000000
Elevation: 33.519203
Rot command:

-- 
Orv Beach <or...@or...>

Re: [Hamlib-developer] RotorEZ 'p' command results

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

* Orv Beach <or...@or...> [2003 Feb 12 16:28 -0600]:
> TX 4 bytes
> 0000     41 49 31 3b    AI1;
> RX 3 bytes
> 0000     3b 33 33       ;33
> TX 4 bytes
> 0000     41 49 31 3b    AI1;
> RX 3 bytes
> 0000     33 3b 33       3;3
> TX 4 bytes
> 0000     41 49 31 3b    AI1;
> RX 3 bytes
> 0000     33 33 3b       33;

Very interesting, Orv!

So, it appears the semi-colon is the first character of the returned
string.  Of course it moves to the right on each successive read as
there are always characters left in the buffer from previous commands
(1, then 2, then 3, and so on).

Can you edit rotorez/rotorez.h, line 34 and change the line:

#define AZ_READ_LEN 3

to

#define AZ_READ_LEN 4

for me?

Then you should see consistent strings reported on the line below RX 4
bytes.  It will do no harm to set it higher, say 5 or 6 as the read
function will merely have wait the time out time.

Please post that output and I should be able to fix it tonight.

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] RotorEZ 'p' command results

[Orv B. <or...@or...>]

Here's the output from rotctl, against type 401 (rotorEZ)

73 - Orv - W6BI


[obeach@jake tests]$ ./rotctl -m 401 -s 4800 -r /dev/ttyS0 -vvvvv
rot:rot_init called
rot: loading backend rotorez
rotorez: initrots_rotorez called
rot_register (401)
rot_register (402)
rot_register (403)
rotorez: rotorez_rot_init called
rot:rot_open called
Opened rot model 401, 'Rotor-EZ'

Rot command: p
rotorez: rotorez_rot_get_position called
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 3 bytes
0000     3b 33 33       ;33
rotorez: azimuth = 0.0 degrees
Azimuth: 0.000000
Elevation: 33.519203
Rot command: p
rotorez: rotorez_rot_get_position called
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 3 bytes
0000     33 3b 33       3;3
rotorez: azimuth = 3.0 degrees
Azimuth: 3.000000
Elevation: 33.519203
Rot command: p
rotorez: rotorez_rot_get_position called
rotorez: rotorez_send_priv_cmd called
TX 4 bytes
0000     41 49 31 3b    AI1;
RX 3 bytes
0000     33 33 3b       33;
rotorez: azimuth = 33.0 degrees
Azimuth: 33.000000
Elevation: 33.519203
Rot command:

-- 
Orv Beach <or...@or...>

[Hamlib-developer] FBSD try Compiling

[Sebastian Y. [ESN] <es...@x1...>]

ok this is my result in trying to compile it in FreeBSD

sorry for all the msg flood


uname -a

FreeBSD wire.x123.info 4.7-STABLE FreeBSD 4.7-STABLE #2: Sun Feb  9 22:27:49 
GMT 2003     ro...@wi...:/usr/obj/usr/src/sys/MYK4.7  i386



sh autogen.sh --disable-static --with-tcl=/usr/local/lib/tcl8.3

/usr/local/bin/gm4: configure.in: No such file or directory
microtune/Makefile.am:29: invalid unused variable name: `GRIO_SOURCES'
autoconf: configure.in: No such file or directory
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for g++... g++
checking for C++ compiler default output... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc
checking for gawk... (cached) nawk
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking dependency style of gcc... gcc
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets ${MAKE}... (cached) yes
checking for rpmbuild... no
checking for AIX... no
checking for strerror in -lcposix... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... no
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking for gcc option to accept ANSI C... none needed
checking whether gcc needs -traditional... no
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for ANSI C header files... (cached) yes
checking alloca.h usability... no
checking alloca.h presence... no
checking for alloca.h... no
checking argz.h usability... no
checking argz.h presence... no
checking for argz.h... no
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking for memory.h... (cached) yes
checking for string.h... (cached) yes
checking for strings.h... (cached) yes
checking for stdlib.h... (cached) yes
checking values.h usability... no
checking values.h presence... no
checking for values.h... no
checking rpc/rpc.h usability... yes
checking rpc/rpc.h presence... yes
checking for rpc/rpc.h... yes
checking rpc/rpcent.h usability... no
checking rpc/rpcent.h presence... no
checking for rpc/rpcent.h... no
checking net/errno.h usability... no
checking net/errno.h presence... no
checking for net/errno.h... no
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking for unistd.h... (cached) yes
checking getopt.h usability... no
checking getopt.h presence... no
checking for getopt.h... no
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking sys/ioccom.h usability... yes
checking sys/ioccom.h presence... yes
checking for sys/ioccom.h... yes
checking linux/ppdev.h usability... no
checking linux/ppdev.h presence... no
checking for linux/ppdev.h... no
checking sgtty.h usability... yes
checking sgtty.h presence... yes
checking for sgtty.h... yes
checking term.h usability... yes
checking term.h presence... yes
checking for term.h... yes
checking termio.h usability... no
checking termio.h presence... no
checking for termio.h... no
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking winioctl.h usability... no
checking winioctl.h presence... no
checking for winioctl.h... no
checking winbase.h usability... no
checking winbase.h presence... no
checking for winbase.h... no
checking POSIX termios... yes
checking for gcc option to accept ANSI C... none needed
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking return type of signal handlers... void
checking for siginfo_t... yes
checking for sin... no
checking for main in -lieee... no
checking for main in -linet... no
checking for connect... yes
checking for gethostbyname... yes
checking for syslog in -lsyslog... no
checking for atexit... yes
checking for snprintf... yes
checking for select... yes
checking for gettimeofday... yes
checking for memmove... yes
checking for memset... yes
checking for strcasecmp... yes
checking for strchr... yes
checking for strdup... yes
checking for strerror... yes
checking for strrchr... yes
checking for strstr... yes
checking for strtol... yes
checking for cfmakeraw... yes
checking for getopt_long... no
checking for usleep... yes
checking for working alloca.h... no
checking for alloca... yes
checking for vprintf... yes
checking for _doprnt... no
checking build system type... i386-unknown-freebsd4.7
checking host system type... i386-unknown-freebsd4.7
checking for ld used by GCC... /usr/libexec/elf/ld
checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes
checking for /usr/libexec/elf/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking for a sed that does not truncate output... /usr/bin/sed
checking how to recognise dependent libraries... pass_all
checking command to parse /usr/bin/nm -B output... ok
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/libexec/elf/ld) supports shared libraries... 
yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... freebsd4.7 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether -lc should be explicitly linked in... yes
creating libtool
checking whether C99 struct/array initializers are supported... yes
checking whether to build rigmatrix... no
checking whether to build C++ binding and demo... yes
checking for perl headers... found /usr/libdata/perl/5.00503/mach/CORE
checking whether to build perl binding and demo... yes
checking whether to build Kylix binding and demo... no
checking for Tcl configuration... found /usr/local/lib/tcl8.3/tclConfig.sh
checking for existence of /usr/local/lib/tcl8.3/tclConfig.sh... loading
checking whether to build tcl binding and demo... yes
checking whether to build gnuradio backend... no
checking whether to build microtune backend... no
checking for rpcgen... yes
checking whether to build rpc backends... yes
checking for swig... no
checking whether to build bindings... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating macros/Makefile
config.status: creating include/Makefile
config.status: creating lib/Makefile
config.status: creating dummy/Makefile
config.status: creating yaesu/Makefile
config.status: creating icom/Makefile
config.status: creating aor/Makefile
config.status: creating kenwood/Makefile
config.status: creating winradio/Makefile
config.status: creating pcr/Makefile
config.status: creating alinco/Makefile
config.status: creating uniden/Makefile
config.status: creating tentec/Makefile
config.status: creating kachina/Makefile
config.status: creating jrc/Makefile
config.status: creating drake/Makefile
config.status: creating gnuradio/Makefile
config.status: creating easycomm/Makefile
config.status: creating fodtrack/Makefile
config.status: creating rpcrig/Makefile
config.status: creating rpcrot/Makefile
config.status: creating src/Makefile
config.status: creating c++/Makefile
config.status: creating kylix/Makefile
config.status: creating bindings/Makefile
config.status: creating tests/Makefile
config.status: creating doc/Makefile
config.status: creating rotorez/Makefile
config.status: creating microtune/Makefile
config.status: creating hamlib.pc
config.status: creating hamlib.spec
config.status: creating include/config.h
config.status: include/config.h is unchanged
config.status: executing default-1 commands
configure: configuring in libltdl
configure: running /usr/local/bin/bash './configure' --prefix=/usr/local  
'--enable-maintainer-mode' '--disable-static' 
'--with-tcl=/usr/local/lib/tcl8.3' --enable-ltdl-convenience 
--cache-file=/dev/null --srcdir=.
loading cache /dev/null
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for working const... yes
checking for inline... inline
checking for Cygwin environment... no
checking for mingw32 environment... no
checking how to run the C preprocessor... gcc -E
checking host system type... i386-unknown-freebsd4.7
checking build system type... i386-unknown-freebsd4.7
checking for ld used by GCC... /usr/libexec/elf/ld
checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes
checking for /usr/libexec/elf/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking for a sed that does not truncate output... /usr/bin/sed
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking for object suffix... o
checking for executable suffix... no
checking command to parse /usr/bin/nm -B output... ok
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/libexec/elf/ld) supports shared libraries... 
yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... freebsd4.7 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether -lc should be explicitly linked in... yes
creating libtool
checking for ANSI C header files... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking whether gcc supports assert without backlinking...
checking which extension is used for shared libraries... .so
checking which variable specifies run-time library path... LD_LIBRARY_PATH
checking for the default library search path... /lib /usr/lib
checking for objdir... .libs
checking whether libtool supports -dlopen/-dlpreopen... yes
checking for shl_load... no
checking for shl_load in -ldld... no
checking for dlopen in -ldl... no
checking for _ prefix in compiled symbols... no
checking whether deplibs are loaded by dlopen... unknown
checking for argz.h... no
checking for error_t... no
checking for argz_append... no
checking for argz_create_sep... no
checking for argz_insert... no
checking for argz_next... no
checking for argz_stringify... no
checking for errno.h... yes
checking for malloc.h... no
checking for memory.h... yes
checking for stdlib.h... yes
checking for stdio.h... yes
checking for ctype.h... yes
checking for unistd.h... yes
checking for dl.h... no
checking for sys/dl.h... no
checking for dld.h... no
checking for string.h... yes
checking for strchr... yes
checking for strrchr... yes
checking for memcpy... yes
checking for memmove... yes
checking for strcmp... yes
updating cache /dev/null
creating ./config.status
creating Makefile
creating config.h
config.h is unchanged



make
Making all in macros
Making all in include
make  all-am
Making all in lib
make: don't know how to make @LTLIBOBJS@. Stop
*** Error code 1

Stop in /home/powe-users/esn/src/ham/hamlib.m.


or

gmake

cd . && \
  CONFIG_HEADERS= CONFIG_LINKS= \
  CONFIG_FILES=Makefile /usr/local/bin/bash ./config.status
config.status: creating Makefile
config.status: executing default-1 commands
Making all in macros
gmake[1]: Entering directory `/home/powe-users/esn/src/ham/hamlib.m/macros'
cd .. && \
  CONFIG_HEADERS= CONFIG_LINKS= \
  CONFIG_FILES=macros/Makefile /usr/local/bin/bash ./config.status
config.status: creating macros/Makefile
config.status: executing default-1 commands
gmake[1]: Leaving directory `/home/powe-users/esn/src/ham/hamlib.m/macros'
gmake[1]: Entering directory `/home/powe-users/esn/src/ham/hamlib.m/macros'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/home/powe-users/esn/src/ham/hamlib.m/macros'
Making all in include
gmake[1]: Entering directory `/home/powe-users/esn/src/ham/hamlib.m/include'
cd .. && \
  CONFIG_HEADERS= CONFIG_LINKS= \
  CONFIG_FILES=include/Makefile /usr/local/bin/bash ./config.status
config.status: creating include/Makefile
config.status: executing default-1 commands
gmake[1]: Leaving directory `/home/powe-users/esn/src/ham/hamlib.m/include'
gmake[1]: Entering directory `/home/powe-users/esn/src/ham/hamlib.m/include'
cd .. \
  && CONFIG_FILES= CONFIG_HEADERS=include/config.h \
     /bin/sh ./config.status
config.status: creating include/config.h
config.status: include/config.h is unchanged
config.status: executing default-1 commands
gmake  all-am
gmake[2]: Entering directory `/home/powe-users/esn/src/ham/hamlib.m/include'
gmake[2]: Leaving directory `/home/powe-users/esn/src/ham/hamlib.m/include'
gmake[1]: Leaving directory `/home/powe-users/esn/src/ham/hamlib.m/include'
Making all in lib
gmake[1]: Entering directory `/home/powe-users/esn/src/ham/hamlib.m/lib'
cd .. && \
  CONFIG_HEADERS= CONFIG_LINKS= \
  CONFIG_FILES=lib/Makefile /usr/local/bin/bash ./config.status
config.status: creating lib/Makefile
config.status: executing default-1 commands
gmake[1]: Leaving directory `/home/powe-users/esn/src/ham/hamlib.m/lib'
gmake[1]: Entering directory `/home/powe-users/esn/src/ham/hamlib.m/lib'
gmake[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'.  
Stop.
gmake[1]: Leaving directory `/home/powe-users/esn/src/ham/hamlib.m/lib'
gmake: *** [all-recursive] Error 1








-- 


/*
 @@@@@@@   @@@@@@ @@@@@@@ 
 @@!  @@@ !@@     @@!  @@@
 @!@!@!@   !@@!!  @!@  !@!
 !!:  !!!     !:! !!:  !!!
 :: : ::  ::.: :  :: :  : 
 The Power To Kill LinuX
*/

Re: [Hamlib-developer] Fun with RotorEZ

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

Thanks, Orv, for testing things out.

* Orv Beach <w6...@pa...> [2003 Feb 12 06:06 -0600]:
> I got my RotorEZ card assembled into my Ham IV this evening, and
> exercised Nate's virgin code.  Some observations:
> 
> The P <az> <el> command appears to work properly.  Giving rotctl the P
> command results in
> 
> Azimuth?  (type in 3 digits here)
> Elevation? (000) <Enter>
> 
> And the rotor obediently turns to 030 degrees.
> 
> That's the good news.

Fortunately, half of it works!

> The bad news is that the p command doesn't return consistent azimuth
> results.  
> 
> With the rotor at 030 degrees, successive 'p's returned the following
> byte strings:
> 
> String     Rotctl interpretation
> =======    =======================
> 33 33 3b   33; degrees
> 30 32 39   29.0 degrees (? might have the degrees wrong)
> 3b 30 32   ;02 degrees
> 39 3b 30   9;0 degrees
> 
> Rotating the rotor to 330 degrees, and typing 'p' four times resulted
> in:
> 
> 31 35 3b   15;
> 33 33 33   333
> 3b 33 33   ;33
> 33 3b 33   3;3
> 
> So, there's an offset or a typo someplace, I suspect.  Hope this
> debugging helps.  Let me know if there's other tests you'd like me to
> do.

Are these strings copied verbatim from the output of running rotctl
-vvvvv?  Just do a copy and paste of the screen output from an XTerm
as that would be the most helpful. 

Without looking at the code, my guess is that the code is only looking
for 3 characters and the Idiom card is sending 4.  So I need to compare
the raw sequences against the RX code.  If so, one byte is still in the
serial buffer.  Fortunately this shouldn't break the DCU-1 as it doesn't
have position query support. 

I won't be able to get to looking at things until this evening after
work.

> 
> Good start, though!  I'm excited!   

Thanks!

> One wish - on a rotor with no elevation, can we suppress the query and
> printout on rotctl?   It's distracting and a bit annoying..

rotctl is a test program, but I suppose it can be written to obey the
backend rotor caps.  That would be good for general use, but for a
simple test interface, it may just get in the way and hinder debugging.
Such a feature would probably be best enabled by an option rather than
by default.

> Are there any GUI front ends extant for rotor control?

Look on the apps page of http://hamlib.sourceforge.net I think there is
a gnome front-end to Predict that may incorporate rotor control.  Joop
has a better idea of this than I do as he's also authoring a general
purpose logging program.

Thanks again, Orv.

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] Fun with RotorEZ

[Orv B. <w6...@pa...>]

I got my RotorEZ card assembled into my Ham IV this evening, and
exercised Nate's virgin code.  Some observations:

The P <az> <el> command appears to work properly.  Giving rotctl the P
command results in

Azimuth?  (type in 3 digits here)
Elevation? (000) <Enter>

And the rotor obediently turns to 030 degrees.

That's the good news.

The bad news is that the p command doesn't return consistent azimuth
results.  

With the rotor at 030 degrees, successive 'p's returned the following
byte strings:

String     Rotctl interpretation
=======    =======================
33 33 3b   33; degrees
30 32 39   29.0 degrees (? might have the degrees wrong)
3b 30 32   ;02 degrees
39 3b 30   9;0 degrees

Rotating the rotor to 330 degrees, and typing 'p' four times resulted
in:

31 35 3b   15;
33 33 33   333
3b 33 33   ;33
33 3b 33   3;3

So, there's an offset or a typo someplace, I suspect.  Hope this
debugging helps.  Let me know if there's other tests you'd like me to
do.

Good start, though!  I'm excited!   

One wish - on a rotor with no elevation, can we suppress the query and
printout on rotctl?   It's distracting and a bit annoying..

Are there any GUI front ends extant for rotor control?

73 - Orv - W6BI
-- 
Orv Beach <w6...@pa...>

Re: [Hamlib-developer] serial ports and hamlib

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

Op di 11-02-2003, om 09:09 schreef Stephane Fillod:
> Hi Orv,
> 
> 
> On Mon, Feb 10, 2003, Orv Beach wrote:
> > Can someone take a look at the code, and let me know if hamlib will
> > handle /dev/usb/ttyUSBnn?  If not, it really ought to be put on the
> > to-do list.  A ham can never have too many serial ports on his ham shack
> > box  ;-)
> 
> Hamlib should be okay, just pass the "-r /dev/usb/ttyUSBn" option to
> rigctl and friends, or rig_set_conf("rig_pathname", "/dev/usb/ttyUSBn")
> from your code.
> 

What about the default timeout for the serial port?
Is it supported?

> 
> Note: your email or...@or... does not seem to be in the list of
> subscribers of this list, and I had to manually approve your post.
> 
> 
> Cheers,
> Stephane
> 
> 

Bye,
Joop

Re: [Hamlib-developer] serial ports and hamlib

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

Hi Orv,


On Mon, Feb 10, 2003, Orv Beach wrote:
> Can someone take a look at the code, and let me know if hamlib will
> handle /dev/usb/ttyUSBnn?  If not, it really ought to be put on the
> to-do list.  A ham can never have too many serial ports on his ham shack
> box  ;-)

Hamlib should be okay, just pass the "-r /dev/usb/ttyUSBn" option to
rigctl and friends, or rig_set_conf("rig_pathname", "/dev/usb/ttyUSBn")
from your code.


Note: your email or...@or... does not seem to be in the list of
subscribers of this list, and I had to manually approve your post.


Cheers,
Stephane

[Hamlib-developer] serial ports and hamlib

[Orv B. <or...@or...>]

I've purchased and built the RotorEz kit, which besides adding
intelligence to a Ham IV rotor, adds (optionally) a serial port for
remote control.   Nate was nice enough to add the RotorEz protocol to
hamlib recently, so soon I'll provide some feedback on how well/poorly
the hardware and the software interact.

But that brings me to a minor dilemma.  I'm out of serial ports on that
box and need to add more.  If I had my druthers, I'd druther add a USB
serial port box.

Can someone take a look at the code, and let me know if hamlib will
handle /dev/usb/ttyUSBnn?  If not, it really ought to be put on the
to-do list.  A ham can never have too many serial ports on his ham shack
box  ;-)

Thanks.

Orv - W6BI -

-- 
Orv Beach <or...@or...>

Re: [Hamlib-developer] Hamlib supported radios

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

Hi Stephen,

Here's a site about PCR1000 I stumbled across lately. The link about Ghetto's
Team is broken, but I have a copy to their command list and their
software. Let me know if you want the files, I can send them directly to
you.

	http://geophysics.ou.edu/ahern/home/pcr1000/

Of course, you're welcome if you want to give a hand to Darren for
developing further the Hamlib PCR backend.

Cheers,
Stephane - F8CFE

On Mon, Jan 20, Stephen Hawkins wrote:
> /.,
> 
> I see listed under Icom Pcr1000 and pcr100 some folks called Ghetto's Team.
> This link appears to be broken.  I have a pcr100 that I like but I use Linux
> almost exclusivly and would love to be able to use the radio without having
> to boot W98.  Do you have any idea where these folks are/or if they had
> anything working.  I would even be happy with some info on the protocol or
> commands to talk to the radio.
> 
> Thanks,
> Stephen Hawkins WV6U
> wv...@at...

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

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

Stephane,

Thanks for "curing" the e-mail!  I've been deleting a lof of hamlib
stuff just for that reason.

I've got my rig and computer up at the new QTH and am starting
work on branch_ts2k.

I was on the radio last week on a local 2m repeater an met two
guys with TS-2000's.  Not only are they hams but we've started
a ts2k programming group.  We've just gotten a sourceforge
project and maillist.  I'm promoting hamlib as the core for our
work and it has been tentatively accepted for the non-
standalone programs.

We hope to be "The TS-2000 software resource", of which the
hamlib project is likely to play a very important part.  It is called
the ts2k-interface project.

73's
Dale
kd7eni

RE: [Hamlib-developer] close list

[<dar...@bt...>]

Stephane,

Thanks for sorting this out. 

Regards,

Darren - G0WCW

-----Original Message-----
From: Stephane Fillod [mailto:f8...@fr...]
Sent: 06 February 2003 07:24
To: Hamlib developers
Subject: [Hamlib-developer] close list



Here we are, I finally managed to get the close list to cut spam. Only 
subscribed user may post to hamlib-developer list. Let me know if you
encounter any problem because of this.

73
Stephane


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] close list

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

Here we are, I finally managed to get the close list to cut spam. Only 
subscribed user may post to hamlib-developer list. Let me know if you
encounter any problem because of this.

73
Stephane