Bill Weinel | 5 Oct 15:03 2011
Picon

Re: Hamlib and Kenwood ts-440

Hi Nate (and all),

I just saw this message and I take it that this problem likely got resolved... 
However I thought I'd throw out a couple of observations for the group on the 
TS-440. (This should also apply to the TS-940, TS-811 and TS-711 according to 
the documents... though I haven't tested them.)

The original TS-440 command code index pointer was written for a character 
length of 38... I can't conclusivly say there may not be a Kenwood TS-440 
radio out there somewhere that uses a 38 character command string, but if 
there is... I havn't seen one yet.  Consequently, rather than just changing it 
to 28, I dynamically adjusted the command string index using a 'null byte' 
detector <00h> routine so that it would just strip off any null bytes at the 
end of the string before terminating it with a ';' and sending it out to the 
radio. Thus, the command string indexing should work with any command length  
format as long as the last byte is non-null. So I would suspect the command 
code is not the issue here...

A couple of more likely issues to point out which may be causing problems here 
are as follows:

The radio signal format is TTL not RS-232 and uses a non standard pinout and 
connector. Going into the back of the radio the signal format is as follows:

Signals are    TTL levels  (NOT RS-232!)
Baud rate is    4800 (1200 Opt.)
Format is    ASCII Serial;  1 Start, 8 Data, 2 Stop

   The baud rate default is 4800 but may be changed to 1200 Baud by removing 
jumper W50 and installing a jumper from the left pad to the center pad as 
(Continue reading)

Scott Berry | 8 Oct 21:01 2011
Picon

the Alinco Dr635E and T series radios

Hello there,

I would be interested in having a backend that does the Alinco 635E and 
t series of mobile radios please?  I am trying to begin my endeavor in 
to computer controlled radios.  Thank you very much.
--

-- 
Scott Berry
E-mail: scottbb1973 <at> gmail.com
Call me: sip:scottbb1973 <at> ekiga.net
computer Certs: MCP and A Plus
Ham Call Sign: N7ZIB
Repeater.book Admin for these states: North and south Dakota, Wisconsin, 
Minnesota, Nebraska

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
Nate Bargmann | 9 Oct 04:31 2011
Picon

Re: the Alinco Dr635E and T series radios

* On 2011 08 Oct 21:20 -0500, Scott Berry wrote:
> Hello there,
> 
> I would be interested in having a backend that does the Alinco 635E and 
> t series of mobile radios please?  I am trying to begin my endeavor in 
> to computer controlled radios.  Thank you very much.

Hi Scott.

Looking at the DR-635 manual, it appears that only a memory clone
function is available.  Hamlib does not support that type of operation
but a similar project, Chirp, may be of use to you.  See:

http://chirp.danplanet.com/

Chirp has just been added to the Debian Unstable repository as well.

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

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
(Continue reading)

Donn Washburn | 10 Oct 03:51 2011
Picon
Picon

As requested

This is a openSuSE 121 B1 x86-64 box.  If you would like more info let 
me know.

-- 
73 de Donn Washburn
307 Savoy Street    Email:" n5xwb <at> comcast.net "
Sugar Land, TX 77478 LL# 1.281.242.3256
Ham Callsign N5XWB   HAMs : " n5xwb <at> arrl.net "
VoIP via Skype:n5xwbg  BMWMOA #:4146 Ambassador
       " http://counter.li.org " #279316
make[2]: Entering directory `/mnt/sda7/h/hamradio/hamlib-1.2.14/c++'
rig:rig_init called
rig: loading backend dummy
rig:  lt_dlopen("hamlib-dummy") failed (file not found), trying static symbols...
rig:  dlsym(initrigs2_dummy) failed (/mnt/sda7/h/hamradio/hamlib-1.2.14/c++/.libs/testcpp:
undefined symbol: initrigs2_dummy)
rig:  lt_dlopen("hamlib-dummy") failed ((null))
terminate called after throwing an instance of 'RigException'
/bin/sh: line 5: 27971 Aborted                 ${dir}$tst
FAIL: testcpp
=======================================================
1 of 1 test failed
Please report to hamlib-developer <at> lists.sourceforge.net
=======================================================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/mnt/sda7/h/hamradio/hamlib-1.2.14/c++'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/mnt/sda7/h/hamradio/hamlib-1.2.14/c++'
(Continue reading)

Nate Bargmann | 10 Oct 13:52 2011
Picon

Re: As requested

* On 2011 10 Oct 06:24 -0500, Donn Washburn wrote:
> This is a openSuSE 121 B1 x86-64 box.  If you would like more info
> let me know.

> FAIL: testcpp
> =======================================================
> 1 of 1 test failed
> Please report to hamlib-developer <at> lists.sourceforge.net
> =======================================================
> make[2]: *** [check-TESTS] Error 1
> make[2]: Leaving directory `/mnt/sda7/h/hamradio/hamlib-1.2.14/c++'
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory `/mnt/sda7/h/hamradio/hamlib-1.2.14/c++'
> make: *** [check-recursive] Error 1

Hi Donn.

The test target to make is a GNU requirement that we know is broken in
Hamlib.  As we're not a GNU project, such support is optional.

We would rather hear about how it works with your actual radio, so go
ahead and do 'make install' and then run ldconfig.  You should be able
to run rigctl.  The README.betatester and README.developer files should
answer most questions.

73, de Nate >>

--

-- 

"The optimist proclaims that we live in the best of all
(Continue reading)

Nate Bargmann | 10 Oct 17:29 2011
Picon

Re: As requested

* On 2011 10 Oct 09:25 -0500, Donn Washburn wrote:
> Thanks Nate!
> 
> However openSuSE doesn't offer a Hamlib version so I am kind of dead
> in the water. Until I  work on it.

Don't worry about the 'make test' failure.  It's harmless.

I recommend the following commands:

./configure --disable-static
make
sudo make install
sudo ldconfig

If you use 'su' or login as root instead of using sudo, that's fine as
well.  The 'ldconfig' command is needed so that the system library
loader can find the newly installed libraries.  Once installed, you can
manually test the library by just running 'rigctl' with no parameters.
It will open the "Dummy" rig and you can give it commands just like a
real radio.  See the rigcrl man page for more information.

> I also need a CAT cable for my Yeasu FT-890 before I can test it.
> Problem will be no serial port, parallel port only USB ports.

I use a USB to serial adapter.  There are plenty out there but found
that a NetGear one I bought to have less RF noise than some cheaper ones
I bought.  You will need a serial port for the FT-890 and I've used the
adapters with my '890 without issue.  The CAT interface I built is
called Tinycat but I don't know if it's available.  I also have a CT62
(Continue reading)

Nate Bargmann | 11 Oct 01:27 2011
Picon

rigctld performance enhancement

I have noticed that while running Fldigi and CQRlog with rigctld that
Fldigi will seem to get out of sync and may eventually disable rig
control.  After thinking about this a bit the past several days I'm
wondering if this could be solved by having a cache in rigctld that
would return the last read frequency/mode/ptt status, etc. while a
command is in progress to the hardware device.

With the library interface the expectation is that one program will be
using a rig at a time and that it will control the rate of rig
communication based on returns from the library, i.e. functions won't be
called in parallel.

With rigctld this process becomes complicated by the ability of more
than one program sending commands to the daemon.  At least I presume
that is where the bottle neck occurs.  Or is it possible that with both
CQRlog and Fldigi using the library interface to rig model 2 that there
is an interaction at the library level?

In other words, I presume that rigctld has its own instance of Hamlib
routines and both CQRlog and Fldigi have their own separate instances
and no interaction between them until the commands collide at rigctld.
If that is so, then I am puzzled by the fact that even if I run rigctld
with the -vvvvv switch that upon starting CQRlog the tracing output
stops, as though debugging is turned off by CQRlog and that affects 
rigctld.  If that is the case, then a cache in rigctld may not solve
any thing.

Looking for advice on this sort of stuff!

73, de Nate >>
(Continue reading)

Charles Suprin | 11 Oct 03:03 2011
Picon

Re: rigctld performance enhancement

Nate,

The caching idea would complicate matters for tracking a satellite station. Some folks want update rates on the order of twenty hertz.  That requires a query response change and response to execute quickly and accurately.

It sounds as though there needs to be a mutex on commands.going out the serial port.  It also may suggest a problem with the driver you are using.

I should dig further.

Charles
Aa1vs

On Oct 10, 2011 7:28 PM, "Nate Bargmann" <n0nb <at> n0nb.us> wrote:
I have noticed that while running Fldigi and CQRlog with rigctld that
Fldigi will seem to get out of sync and may eventually disable rig
control.  After thinking about this a bit the past several days I'm
wondering if this could be solved by having a cache in rigctld that
would return the last read frequency/mode/ptt status, etc. while a
command is in progress to the hardware device.

With the library interface the expectation is that one program will be
using a rig at a time and that it will control the rate of rig
communication based on returns from the library, i.e. functions won't be
called in parallel.

With rigctld this process becomes complicated by the ability of more
than one program sending commands to the daemon.  At least I presume
that is where the bottle neck occurs.  Or is it possible that with both
CQRlog and Fldigi using the library interface to rig model 2 that there
is an interaction at the library level?

In other words, I presume that rigctld has its own instance of Hamlib
routines and both CQRlog and Fldigi have their own separate instances
and no interaction between them until the commands collide at rigctld.
If that is so, then I am puzzled by the fact that even if I run rigctld
with the -vvvvv switch that upon starting CQRlog the tracing output
stops, as though debugging is turned off by CQRlog and that affects
rigctld.  If that is the case, then a cache in rigctld may not solve
any thing.

Looking for advice on this sort of stuff!

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

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Hamlib-developer mailing list
Hamlib-developer <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Hamlib-developer mailing list
Hamlib-developer <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
Nate Bargmann | 11 Oct 04:26 2011
Picon

Re: rigctld performance enhancement

* On 2011 10 Oct 20:04 -0500, Charles Suprin wrote:
> Nate,
> 
> The caching idea would complicate matters for tracking a satellite station.
> Some folks want update rates on the order of twenty hertz.  That requires a
> query response change and response to execute quickly and accurately.

I'm not looking to slow the actual response rate.  We can't get a query
faster than the rig's output.  In many cases that is 4800 bps!
Fortunately, newer rigs support faster rates.  Also, I'm talking
srtictly about rigctld, not the library.

> It sounds as though there needs to be a mutex on commands.going out the
> serial port.  It also may suggest a problem with the driver you are using.

That is part of a two-pronged approach I was thinking of--blocking a
request from another socket while a rig command is in progress and also
having a cache so the second socket could return *something* even if
slightly aged.  

As rigctld does use pthreads when available, perhaps using a mutex is
the easiest.  Presumably programs won't make a query until a reply is
received or some timeout value expires.  Perhaps this would render a
cache unecessary?

> I should dig further.

That would be helpful.  I am using the K3/Kenwood backend.  Tests with
other backends would be helpful.

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

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
Nate Bargmann | 12 Oct 19:26 2011
Picon

[Fwd: Re: rigctld performance enhancement]

Looks like I was the only one to receive this.

----- Forwarded message from Dave <dave <at> g8kbv.demon.co.uk> -----

Date: Tue, 11 Oct 2011 17:11:20 +0100
From: Dave <dave <at> g8kbv.demon.co.uk>
To: Nate Bargmann <n0nb <at> n0nb.us>
Subject: Re: [Hamlib-developer] rigctld performance enhancement
X-mailer: Pegasus Mail for Windows (4.61)

> * On 2011 10 Oct 20:04 -0500, Charles Suprin wrote:
> > Nate,
> > 
> > The caching idea would complicate matters for tracking a satellite station.
> > Some folks want update rates on the order of twenty hertz.  That requires a
> > query response change and response to execute quickly and accurately.
> 
> I'm not looking to slow the actual response rate.  We can't get a query
> faster than the rig's output.  In many cases that is 4800 bps!
> Fortunately, newer rigs support faster rates.  Also, I'm talking
> srtictly about rigctld, not the library.
> 
> > It sounds as though there needs to be a mutex on commands.going out the
> > serial port.  It also may suggest a problem with the driver you are using.
> 
> That is part of a two-pronged approach I was thinking of--blocking a
> request from another socket while a rig command is in progress and also
> having a cache so the second socket could return *something* even if
> slightly aged.  
> 
> As rigctld does use pthreads when available, perhaps using a mutex is
> the easiest.  Presumably programs won't make a query until a reply is
> received or some timeout value expires.  Perhaps this would render a
> cache unecessary?
> 
> > I should dig further.
> 
> That would be helpful.  I am using the K3/Kenwood backend.  Tests with
> other backends would be helpful.
> 
> 73, de Nate >>
> 

Hi Group.

As a developer of instrumentation software (winders based) where often 
more then one process needs to monitor and control a "measuring 
instrument", I've never had long term success, without some from of 
"device proxy" between the app's and the "real" instrument.

That proxy, should be the only process that communicates direct with the 
device itself, as most instruments (and all Ham rigs I've meddled with) 
are single thread/single user type souls.  It (the Proxy) should remember 
commands sent, and queries received, so as to minimise the traffic to the 
device/radio, while giving the app's the quick response they might want.

Start throwing multiple commands at them, and also asking for status, 
often out of sync, only leads to "trouble", to say the least.  Having 
higher speed remote control links, only makes things worse, for the 
radio.

If you do *Realy* need 20Hz update rates (and heaven knows, I can't think 
why, even for LEO satellite working, they don't move that fast accross 
the sky)  Then you need a dedicated radio (SDR?) for the job.  Even the 
pro's don't use that fast an update rate, except perhaps for tracking 
incoming munitions!

73.

Dave G0WBX.

----- End forwarded message -----

--

-- 

"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

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Gmane