Hartinger Roland | 21 Jul 20:22 2014
Picon

Kenwood TS-590S fix

Hi all,

I fixed a problem with I found while controlling my Kenwood TS-590S when using 'rigctld' with the 'send_cmd' command.
The code in 'rigctld.c' use '\r' to terminate the 'send_cmd' command. This results in an error message from the rig resp. from the backend.

Therefore, I made the following change in 'rigctld.c' as shown in the following code-snippet:

// char send_cmd_term = '\r';  /* send_cmd termination char */
// DF1GR modification:
char send_cmd_term = ';';  /* send_cmd termination char */

The change works well and so I'm able to use the whole TS-590S command set.
Can somebody from you verify my change and iff it is correct, bring this in one of the next hamlib release, please!?

Thanks in advance,
vy73 de Roland (DF1GR)






------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Hamlib-developer mailing list
Hamlib-developer <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
John Ronan | 20 Jul 18:52 2014
Picon

UBC785XLT (and probably others)

Hi Folks,

I got a UBC-785XLT not aso long ago, today I had a quick look at getting 
the frequency out of it with hamlib when the squelch is open (detecting 
that with another program)

There is no VFO in it so get_freq doesn't appear to ever work.

What does work though is get_mem.  See the example below when I manually 
opened the squelch.

Rig command: f
rigctl_parse: input_line: f
write_block(): TX 4 bytes
0000    52 46 3f 0d RF?.
read_string(): RX 4 characters
0000    45 52 52 0d ERR.
get_freq: error = Protocol error

Rig command: e
rigctl_parse: input_line: e
write_block(): TX 3 bytes
0000    4d 41 0d MA.
read_string(): RX 35 characters
0000    43 36 30 33 20 46 30 34 35 36 36 35 30 30 20 54     C603 F04566500 T
0010    46 20 44 4e 20 4c 46 20 41 46 20 52 4e 20 4e 30     F DN LF AF RN N0
0020    30 30 0d 00.
Memory#: 603

Rig command:

In my head given that there is no VFO get_freq should return whatever 
frequency the radio is on 'now', i.e. it is the frequency contained 
within the "MA" response.

Any thoughts before I go mucking with it? Or have I overlooked something 
completely obvious.

Regards
John
EI7IG

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
Jaroslav Skarvada | 3 Jul 14:12 2014
Picon

Correct location for python bindings

Hi,

it seems that python bindings are arch specific thus it should
be probably installed to pyexecdir instead of pythondir which is
noarch. Attached patch is what we used in Fedora. We do not
bootstrap, so that's why we also patch the Makefile.in file

thanks & regards

Jaroslav
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Hamlib-developer mailing list
Hamlib-developer <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
David McClain | 30 Jun 23:54 2014

Icom 7600 split mode

Hi

I'm using WSJT-X 1.3 with an Icom IC-7600. WSJT-X wants to use split mode on the transceiver so that
modulation tones can be kept between 1500-2000 Hz regardless of actual frequency of transmission.
Presumably, in conjunction with typical transmitter SSB filters, this will cut down on harmonic
distortion products in the outgoing transmission. 

However, this feature does not work properly. WSJT-X 1.3 is using hamlib DLLs. I wrote a Lisp interceptor
program to watch what was being sent to the IC-7600. When WSJT-X starts up, it sends a sequence 0xfefe 7ae0
0701 fd. 

That middle 0x0701 is a nonsense command for the IC-7600. I have no idea what was being attempted, but a first
guess is that you are probing the rig to determine if it can be put into split mode. In that case my
interceptor substitutes 0x0f01 for that 0x0701, which places the IC-7600 into Split mode. 

Doing this makes WSJT-X perform as expected. 

I waded into your Hamlib code for Icom radios, and found where the likely culprits are, but I can't be sure,
and WSJT-X is using Hamlib in DLL form, making it difficult to see just how it is using Hamlib. 

So the problem might be in Hamlib, or it might be in WSJT-X. I suspect Hamlib has the problem, since the 0x0701
is a nonsense code for the IC-7600. 

Offhand, and with my Lisp bias, it seems that Hamlib has taken a rather rigid approach in defining radio
control sequences by hardcoding things into C. Contrast with the Omnirig and Rigcat approaches where
human editable personality files are used, and can more easily be corrected by end users. These other two
both have issues of their own, and frankly, nothing beats a fully dynamic and interactive Lisp approach. :-)

73 de Dave, N7AIG

Dr. David McClain
CTO & Co-Founder
Acudora, Inc.
e-mail: david <at> acudora.com
Tel: (+1) 520-529-2437

Sent from my iPad

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
Kevin Zheng | 30 Jun 21:37 2014
Picon

[patch] Fix write-only transactions for the GS-232B

Hi there,

Hamlib is having some trouble working with my Yaesu GS-232B. I can send
it commands, but I receive a timeout error and see several (failed)
retry attempts. It turns out that the GS-232B does not give a 'success'
message for many commands, including rotation, move, and stop [1].

My second patch adds a write-only transaction function (actually, a
duplicate of the same from 'gs232.c') and uses it for several commands
that don't actually return a success message.

I noticed that there is no 'Create Ticket' button for me on the patch
tracker, and I decided that a merge request would be overkill.

Thanks,
Kevin Zheng

[1] http://gatorradio.org/Manuals/Yaesu_GS-232B_Manual.pdf
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Hamlib-developer mailing list
Hamlib-developer <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
Ladislav Vaiz | 26 Jun 22:20 2014
Picon

HIDAPI for FUNcube

Hi all,
I was disgusted with experiments with FUNcube under Windows. 
Libusb-win32 is working, but installation of drivers is not easy. After 
install, other applications stop working because libusb-win32 grabs 
device and disallows access for non-libusb apps.

I've found HIDAPI library, which use native win32 API under Windows and 
libusb (unfortunately 1.0) on *nixes. Also modified FUNcube backend to 
use HIDAPI.

Nothing is perfect so here are some limitations. HIDAPI is supporting 
two backends under *nixes. Hidraw needs libudev so there is additional 
dependency for hamlib and udev rules are written in new form.

Second backend uses libusb 1.0. Its possible to link hamlib together 
with 0.1 and 1.0 :-)
In future, I think hamlib must upgrade to 1.0 so I think 1.0 is not big 
problem and I'm going not to downgrade HIDAPI to 0.1.

I don't use MAC OS X, I would like to ask users to test this patch.

I've tested the patch under Debian Wheezy with all combination of 
libudev-dev and libusb-1.0-0.dev. Mingw32 build on same system also 
works. So I hope incidental issues will be fixed easy.

73 Lada, OK1ZIA
Attachment (hidapi.diff): text/x-patch, 193 KiB
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Hamlib-developer mailing list
Hamlib-developer <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
Hartinger Roland | 24 Jun 11:10 2014
Picon

send_cmd doesn't work

Hi,

using Hamlib to control my Kenwood TS-590S from my own program.

To be able to send raw commands to the rig not directly supported by Hamlib I'm using 'send_cmd' resp. 'w', but I do not get 
any results back, instead a timeout accour, for examle:

//send via my bash
echo "w FA;" | nc -w 5 127.0.0.1 4532

// result from rigctld with -vvvvv given:
Connection opened from 127.0.0.1:49515
rigctl(d): w 'currVFO' 'FA;' '' ''
write_block(): TX 4 bytes
0000    46 41 3b 0d                                         FA;.            
read_string(): RX 2 characters
0000    3f 3b                                               ?;              
read_string(): Timed out 0.500766 seconds without reading a character.
fscanf: Undefined error: 0
Connection closed from 127.0.0.1:49515

Can you please give me a hint why this is wrong usage or maybe a bug in the Kenwood backend!?

Thank you in advance for your help!

vy73 de DF1GR (Roland)





------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Hamlib-developer mailing list
Hamlib-developer <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
Richard Shaw | 18 Jun 22:42 2014
Picon

Patch for python bindings install location

I have a small patch to correct the install location of the python bindings.

Since it's not a pure python extension is belongs in pyexecdir instead of pythondir, which for multilib systems like Fedora will get installed into /usr/lib64/python{ver}/site-packages on 64bit systems.

This is consistent with the automake documentation:


Patch posted below.

Thanks,
Richard

diff -Naur hamlib-1.2.15.3.orig/bindings/Makefile.am hamlib-1.2.15.3/bindings/Makefile.am
--- hamlib-1.2.15.3.orig/bindings/Makefile.am   2012-11-01 16:27:27.000000000 -0500
+++ hamlib-1.2.15.3/bindings/Makefile.am        2014-06-18 15:06:39.006305823 -0500
<at> <at> -107,20 +107,20 <at> <at>

 python_ltlib = _Hamlib.la

-#pythondir = <at> pythondir <at>
+#pyexecdir = <at> pyexecdir <at>

 nodist__Hamlib_la_SOURCES = hamlibpy_wrap.c
 _Hamlib_la_LDFLAGS = -no-undefined -module -avoid-version
 _Hamlib_la_LIBADD = $(top_builddir)/src/libhamlib.la

-_Hamlib_ladir = $(pythondir)
+_Hamlib_ladir = $(pyexecdir)

 all-py: $(python_ltlib)

 check-py: all-py
        $(srcdir)/pytest.py || echo "Python test failed" 1>&2

-python_PYTHON = Hamlib.py
+pyexec_PYTHON = Hamlib.py

 _Hamlib_la_LTLIBRARIES = $(python_ltlib)
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Hamlib-developer mailing list
Hamlib-developer <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
Dave Edwards | 7 Jun 10:51 2014
Picon

ICOM M802 marine SSB

Hi all.

As far as I can tell (including testing hamlib using the perl test
script) the IC-M802 marine set is not supported.

Is that correct?

If so, is there anything I can do to help get it supported?

Thanks
dave

--

-- 
Dave Edwards
Living the Dream :-)
http://www.sailblogs.com/member/ourventure/
----

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
Nate Bargmann | 6 Jun 05:06 2014
Picon

Re: Back end function specifications.

* On 2014 24 May 05:37 -0500, Bill Somerville wrote:
> Hi All,
> 
> I am progressing well with a more comprehensive implementation of the 
> FT-817/FT-857/FT-897 backends but I am having some difficulty resolving 
> ambiguities in the rig control API. Is there some documentation 
> available about what each API function is supposed to do. I can 
> understand the basic requirements but when it comes down to the detailed 
> implementation I am often finding myself having to make choices that 
> could be made differently in other backends. I could trawl through all 
> the others and try and form a consensus but it would so much easier if 
> there were a declaration of intent.

Welcome to the club, Bill.  ;-)

To my knowledge, other than current implementation, no design document
has ever existed to shine a light on these dark corners.  The closest
thing we have to documentation are the Doxygen generated pages at:

http://hamlib.sourceforge.net/manuals/1.2.15/index.html

There are other notes on the Wiki, although not many:

http://sourceforge.net/apps/mediawiki/hamlib/?source=navbar

> A few examples (there are many more):
> 
> 1) What does RIG_VFO_TX mean? Is it the vfo that will be used for TX 
> given the current rig state (split setting dependent) or is it the vfo 
> that will be used if split were enabled?

>From the comments in include/hamlib/rig.h:

"TX -- alias for split tx or uplink, of VFO_CURR"

> 2) Should all back ends do something sensible for all vfos?

All VFOs in the radio, or in the Hamlib API?

> 3) Do the {get,set}_split_freq functions respect repeater offsets?

I will say that I doubt it.  These functions seem to me to be intended
for the classic "HE'S WORKING SPLIT YOU LID!" (yes, heard tonight and
yes, my K3 was properly in split!).

> I view a lot of these decision points from the standpoint of a user of 
> the library looking for a generic interface to rigs. I would like to 
> think there is a subset of the API that is guaranteed to work for all 
> rigs of a certain type (e.g. all transceivers or all transceivers that 
> can support dual frequency operation i.e. split of some sort).
> 
> With (2) above and the paragraph above I find that a an API user I have 
> to constantly decide whether to use VFOA/VFOB or VFO_MAIN/VFO_SUB. It 
> would be so much easier if all back ends had a more generic approach to 
> basic facilities.

I don't disagree, Bill.  There are times when it is more obvious to use
MAIN and SUB than A, B, C, etc.  I did use MAIN and SUB in the ft920
backend.  That is some of my earliest code, so don't laugh too hard...

IMO, Hamlib suffers from being a bit too grand of an idea.  By trying to
forge a generic rig API, some compromises needed to be made.  Also,
Stephane, F8CFE, authored most of this well over a decade ago and the
modern rigs are passing Hamlib by.  My advice is to not over think this
too much.  I tried to do that with the ft920 backend and wound up
figuring out that supporting the basics is generally adequate and
planned to fill in the holes later.  My FT-920 is gone and no one seems
to be needing any extra functionality, so that code is left alone.

73, de Nate >>

--

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
Nate Bargmann | 6 Jun 04:44 2014
Picon

Re: SourceForge project wiki

* On 2014 20 May 10:14 -0500, Martin wrote:
>  
> 
> I'm getting a message that SF is withdrawing its "Hosted Apps" -- in
> particular, our MediaWiki instance. (At least that's what I *think*
> they're saying - I found the announcement to be rather confusing.) 

Ugh!  I much prefer Media Wiki.  So far I've not seen that but I may
have missed it.

> There may be a way to migrate our current wiki info --
> https://sourceforge.net/apps/mediawiki/hamlib into their new wiki
> system. But the wiki is 5 years old, for the most part. Maybe it's time
> for a rewrite? 

Parts of it have not been touched in some time while I know I have
updated other parts.  Do I need to enable the new Wiki and do some other
administrative things for you to have a go at it, Martin?

73, de Nate >>

--

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

Gmane