gmane.linux.hams.hamlib.devel

Windows builds now have threads!

Nate Bargmann — 2013-05-18T17:19:03

I noted that a recent update to Debian Unstable's MinGW had the
libpthread-mingw package.  This is the Pthreads-win32 package integrated
into Mingw W64.  I've pushed a recent set of patches fixing a few build
issues with enabling pthreads in MinGW.  Enabling threading exposed
another bug where an additional header file must be included for W2k
support.  This means that rigctld and rotctld may now accept multiple
concurrent connections just as on POSIX systems.  I was able to connect
with three instances of rigctl in my tests on W2k, Windows XP, and Windows 7.

As a result, I think that our custom getaddrinfo and freeaddrinfo
implementation may now be obsolete as MinGW is providing that support.

Also, I pushed patches this week that corrected some build issues in
Cygwin when building Hamlib as a Cygwin hosted executable (not compiled
with MinGW in Cygwin, that I've yet to try).  One thing that does not
work when compiling in Cygwin is the '--with-included-ltdl' option to
configure.  It even fails with the sa

[TS-590S] Hamlib command functionality with theTS-590S

Ian Wade G3NRW — 2013-05-13T21:41:02

As a learning experience I have spent a little time checking out the
functionality of hamlib when communicating with the TS-590S.

Environment:
   hamlib v 1.2.15.3
   Windows XP

Tested with rigctl

A summary of the results is at:

<http://homepage.ntlworld.com/wadei/hamlib/130509-g3nrw-hamlib590-rigctl-
blackbox.pdf>

I have discovered a few minor bugs, highlighted in red. Fixing these
should not be a big problem.

Comments welcome.

Re: [Joe Taylor] [Wsjt-devel] Blocking calls to hamlib

Ladislav Vaiz — 2013-05-13T06:31:49

Hi Stephane

I have tested it on linux machine on empty port:

$  rigctl -vvvvv -m 214 -r /dev/ttyS0 -s 4800 -C data_bits=8 -C 
stop_bits=2 -C serial_handshake=Hardware -C timeout=1000
rigctl, Hamlib 1.2.11
Report bugs to <hamlib-developer< at >lists.sourceforge.net>

rig:rig_init called
rig: loading backend kenwood
kenwood: _init called
rig_register (213)
...
rig_register (228)
kenwood_init
kenwood_init: if_len = 38
rig_set_conf: data_bits='8'
rig_set_conf: stop_bits='2'
rig_set_conf: serial_handshake='Hardware'
rig_set_conf: timeout='1000'
rig:rig_open called
kenwood_transaction: IF
TX 3 bytes
0000    49 46 3b                                           IF;
read_string: timedout without reading a character
TX 3 bytes
0000    49 46 3b                                           IF;
read_string: timedout without reading a character
TX 3 bytes
0000    49 46 3b                                           IF;
read_string: timedout without reading a character
TX 3 bytes
0000    49 46 3b

Successful compilation on Cygwin

Nate Bargmann — 2013-05-10T13:18:48

Last night I committed a set of patches as a result of my getting Hamlib
to compile on Cygwin, a POSIX environment that installs and runs on
Windows.  As I forgot a '#else' statement, I added one additional patch
this morning that fixed the build on mingw32msvc used to generate the
daily Windows snapshots.

So, for anyone interested in Cygwin, this should be some welcome news.

73, de Nate >>

Re: get_kenwood_level

Patrick Ouellette — 2013-05-09T16:49:41

This is the approach in the TS2000 backend (and others).  For calls that
can it hands off to the kenwood_get_level() but when necessary it
does the lifting.  This is how hamlib is designed to function.  In the
individual backend you control which functions are used in the rig_caps
structure.


This could be done, and the other backends could migrate to it or not.
Adding the functions to the generic backend is OK (with approval of the
archive maintainers) but changing the functionality of things in the 
generic backends to suit a specific subset of rigs would be bad.


Form or function, pick one :-).


kenwood_[g|s]et_level() is NOT broken.  It functions as intended.  The
newer radios need people to write and maintain the code specific to the
newer radios (thanks for looking into this, btw).

73,

Pat NE4PO

get_kenwood_level

Jerry Kaidor — 2013-05-09T16:43:42

OK,

   Changing get_kenwood_level is out.  Who knows what it'll break?  I can
add a ts590_get_level or somesuch to ts590s.c.   But wait!  Are there
other Kenwood transceivers that have this "feature" of different length
level results?

   Sure enough, the TS-990 also returns 4 characters for AF gain.  So does
the TS-2000.  My guess is that every Kenwood transceiver newer than
XXXX will have it.

   So it might make sense to add a second get_level routine to kenwood.c. 
Maybe get_kenwood_level_variable?   Then I would stuff that routine
into
the command tables for the TS590S, the TS990S, and the TS2000.

   Actually, it would be two new routines. Also repeated would be
kenwood_get_level().  That's a monster, it has a big switch statement
with
cases for each sort of level.  I really hate to duplicate it.  Would be
inelegant.

   So right now we have kenwood_get_level() with the monster switch
statement, calling get_kenwood_level() which is broken for newer radios
because it assumes that all responses have thr

Re: [TS-590S} TS-590S archives?

Patrick Ouellette — 2013-05-08T20:36:25

This is exactly the right way to do it, and why I responded in the first
place.



If you review the documentation about how to add a rig to the system
there is information there (see the README.developer file).  It does not
explicitly state "modify rig model specific things in my_rig_model.c"
but in sections 2 and 3 (especially 3.2 and 3.3) it does seem to come 
pretty close. 

73,

Pat NE4PO

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: [TS-590S} TS-590S archives?

Jerry Kaidor — 2013-05-08T21:15:06

*** This is hard to guarantee.  I don't have an extensive collection of
recent Kenwood radios.  In fact, I have exactly one :).  I imagine this is
typical.

    get_kenwood_level is directly used by ts2000.c and also ts870s.c. 
HOWEVER, there is also some sort of indirection system ( rig_caps ) ,
and the string "get_kenwood_level" is inside config files for other
radios.  Without going in to really understand the indirection system,
I can only guess that those other radios are also using the routine. 
So yeah, changing get_kenwood_level is probably not a good idea.

   Of course, I can simply copy and paste the appropriate code into
ts590s.c, and that should pretty well guarantee that no other rigs will
be impacted.

   When a project gets large enough so it is not knowable by a single
developer, then this kind of thing tends to happen - people copy and
paste because they're afraid to break.  Then the code starts to grow
exponentially, and become even less knowable.  Been there, done that.

Re: [TS-590S} TS-590S archives?

Nate Bargmann — 2013-05-08T17:25:30

Exactly!

If a generic Kenwood function doesn't support a given model, then
another function can be implemented in the backend file.  There are
a number of examples, I'm familiar the k2.c and k3.c files myself.

Even the kenwood.c file does have alternate functions for some models
where a revised command or response format became shared among several
newer models.

I'll commit supplied patches but do ask that existing functionality not
be broken.  :-)

73, de Nate >>

Re: [TS-590S} TS-590S archives?

Patrick Ouellette — 2013-05-08T15:45:52

It was my understanding (way back when) that the proper place to make such 
changes was in a rig specific module, not the generic kenwood file.
I had to deal with this and a similar issue with some TS2K functions.
If you change the generic kenwood functions, you may break other rigs....

73,

Pat NE4PO

Re: [TS-590S} TS-590S archives?

Ian Wade G3NRW — 2013-05-08T15:19:27

___Original Message_________________________________________
From: Jerry Kaidor <jerry< at >tr2.com>
Date: Wed, 8 May 2013   Time: 06:50:52

Jerry

I am very new to hamlib (but not to software in general), so please 
forgive me if I am speaking out of turn.

I am leery about what you said:

a. You cannot make that assumption. By default the apps programmer 
doesn't know if the user feeds the audio through the USB port or via an 
interface unit connected to the mic socket.

[A case in point. Joe recently added a user option to WSJT-X, asking the 
user to select whether the TX audio is supplied via the "data" input or 
the "mic". There is no way of second-guessing this or making assumptions

Re: [TS-590S} TS-590S archives?

Thomas Beierlein — 2013-05-08T14:38:54

Am Wed, 8 May 2013 06:50:52 -0700
schrieb "Jerry Kaidor" <jerry< at >tr2.com>:


I would suggest to make that decision configurable, maybe by a
'--set-conf=xxx' parameter. 

You yourself needs the PTT for data inputs, other people may have other
needs. 

73, de Tom DL1JE

P.S. Having a TS-590S myself I would be glad to help testing as time
permits.

Re: [TS-590S} TS-590S archives?

Nate Bargmann — 2013-05-08T14:52:29

I presume that with Ubuntu that you're using Pulse Audio.  My solution
is to use pavucontrol (Pulse Audio Volume Control) which is a GUI that
allows directing the audio from/to a given application to an audio
device.  Once the application is running, it should be listed in the
Playback tab and then a drop-down with all known PA sources and sinks
will be in the application section.

In this manner I can direct the motherboard sound device for Fldigi and
the PCI board connected to my speakers for other sounds.  A bonus is
using this utility to direct 'Net audio streams to my Mythbuntu PC to
play through my stereo amp (yup, I still don't have surround sound).

There is probably some way to do this programmatically from the Fldigi
dialog, but I gave up when pavucontrol was upgraded to support per-app
direction of the sound stream about a year and a half ago.

73, de Nate >>

Re: [TS-590S} TS-590S archives?

Jerry Kaidor — 2013-05-08T14:48:55

Hi all,

   Right now, the main issue with my Linux/fldigi/hamlib/TS590
installation is not hamlib at all, but audio.  Ubuntu has a notion of
"the main sound device", which you choose with the sound setup.  fldigi
is using the "main sound device".  What I want is for fldigi to use the
usb, independant of
what the computer is using for beeps and youtube videos.  I am not the
only person with this problem - once in a while I hear "You have Mail" or
Windows
USB device bongs on the PSK31 band segments.

  This is of course not a Hamlib issue at all.  Does anybody know an
appropriate forum to talk about it?

                      - Jerry KF6VB





------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! htt

Re: [TS-590S} TS-590S archives?

Nate Bargmann — 2013-05-08T13:37:50

 

You can just send your patch file(s) as an attachment to the mailing
list.  If you're working from a Git repository, Git has a command to
create a patch, otherwise a unified diff (diff -u path/to/oldfile
path/to/newfile) works just as well.

73, de Nate >>

Re: [TS-590S} TS-590S archives?

Jerry Kaidor — 2013-05-08T13:50:52

*** OK, I have it (fldigi/hamlib) working ( on my Ubuntu Linux/TS590
environment ).  It's not perfect; there are still errors in the grig
traces.  But I can make QSO's.

   There are a few small changes I made in hamlib that are probably worth
merging into the code base.

  1.  Making the default PTT "data" instead of "voice".  If we're
controlling the radio with our PC, we are usually supplying audio from
the PC also.

 2.  I updated get_kenwood_level() with an input parameter that tells it
how many characters to expect back from the radio.  This puts the
decision - as to how much data to expect - in the switch block that is
already doing specific things for each kind of level.   This change
caused changes in a couple other Kenwood transceivers that were directly
using get_kenwood_level().

  I've never submitted code to a sourceforge project - how's it done?

                      - Jerry KF6VB



------------------------------------------------------------------------------
Learn Graph Databases - Downloa

Re: [TS-590S} TS-590S archives?

Ian Wade G3NRW — 2013-05-08T12:57:07

___Original Message_________________________________________
From: Nate Bargmann <n0nb< at >n0nb.us>
Date: Wed, 8 May 2013   Time: 05:52:42



Whoa there, steady on! I haven't cracked the TS-590S hamlib backend 
yet.... But I expect the TS-990S version will be almost identical.

Re: [TS-590S} TS-590S archives?

Ian Wade G3NRW — 2013-05-08T12:58:59

___Original Message_________________________________________
From: Jerry Kaidor <jerry< at >tr2.com>
Date: Wed, 8 May 2013   Time: 06:36:06



Yes. Fully described in my TechNote.



... and via CAT commands.

Re: [TS-590S} TS-590S archives?

Jerry Kaidor — 2013-05-08T13:36:06


** And this has nothing to do with PTT.  The PTT situation is:

   There are two kinds of PTT - "voice" and "data".  The difference
between them is where the transmit audio comes from.  For "voice", it's
from the
microphone connector on the radio front panel.  For "data", it's either
the USB interface OR the back panel accessory socket.  Which of the two
data inputs -  is selected bya front panel menu setting.

   The transceiver menu "data" setting is, as Ian mentioned, a red herring.

                        - Jerry KF6VB





 This has nothing



------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: [TS-590S} TS-590S archives?

Nate Bargmann — 2013-05-08T10:52:42

Very well, Ian, thanks for the additional explanation.

I see you're also maintaining a TS-990 resource page.  As we currently
have no backend expressly for the TS-990, your help with it would be
greatly appreciated.

73, de Nate >>

Re: [TS-590S} TS-590S archives?

Ian Wade G3NRW — 2013-05-08T07:59:21

___Original Message_________________________________________
From: Nate Bargmann <n0nb< at >n0nb.us>
Date: Tue, 7 May 2013   Time: 16:30:43

Nate

The TS-590S PTT situation is way more complicated than that. The big 
problem is in the Kenwood documentation, which talks about "data" as if 
it meant "digital". These two terms are quite different and independent.

Specifically, "data" does not mean "data" -- when you select "DATA", all 
you do is select a different set of DSP audio filters. This has nothing 
to do with "digital" transmission -- you can use either set of these 
filters (DATA and non-DATA) for either voice or digital modes.

Also with the TS-590S there are *two* independent menu sets (Menu A and 
Menu B) where you can set up totally different operating environments; 
typically, Menu A handles voice, and Menu B handles digital. Hamlib 
needs to recognize this.

For details of TX keying, "data" and Menu A/B in the TS-590S, go to the 
"TS-590S Resources Page":

   http://homepage.ntlworld.com/wadei/ts-