hamlib-developer — hamlib developers forum

[Hamlib-developer] rpcrig (howto)

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

Hi again,

Just a quick question.  My laptop is connected to my rig and is slower
than my main computer.  The two computers are connected via
ethernet and allows me to do anything on one the other won't do.

I believe rpcrig is for control via this type of link.  It'd be
convienient
(and really cool) if I could run rigctl remotely via rpcrig.  I'm sure
that the development status is not what it wants to be but I'd give
it a go if someone would give the clues I need to run this way.  if
it is 100% broken, I won't worry about and just copy stuff over and
use only the laptop.  Much has to be done this way regardless.

Thanks.

(Is it just me or is it pretty quiet in here?)

Dale
kd7eni

[Hamlib-developer] ./configure

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

Hi,

I dowloaded all of the latest and greatest tools(libtool, autoconf,
automake) and
they compiled perfectly.  After they were installed, hamlib finally
compiled on
my Athalon (now dev work at 1GHz!).  I had all the tools in the
README.developer
but hamlib wouldn't compile on the Athalon, and only grudgingly on the
300MHz
laptop.

I still had the problem with it halting with the stamp-h permission
error (I suspect
this is CVS related) but was easily corrected.  The install worked
great.  I just
tried a 'make distclean' and still get an error.  This makes me have to
clean stuff
up by hand.

I added the second freq to *_[sg]et_split_freq().  Nothing major broke
that wasn't
easily fixed except rpcrig/setsplitfreq().  So far I've had no luck with
any change
whatsoever.  Any clues on how to add this or easily remove rpcrig from
my build
would be greatly appreciated.

Dale
kd7eni

[Hamlib-developer] Becoming a Hamlib Developer

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

Stephane,

I shoud have asked before now, but how do I become a hamlib developer?
Maintaining the kenwood ts2k
would be my primary interest of course.  The changes that are being made
my kenwood/ts2k.[ch] are
becoming more extensive.  Naturally, its easy to get out of sync with
the CVS especially if you are developing
without your changes going back in.

I already have a sourceforge user account:
de...@us....  If you think I can help out it
would simplify things.  I removed ssh from my system quite some time
back, but can get it back easily enough.

The following functions are the current additions I've made to ts2k.c:
                                ts2k_set_ctrl(), ts2k_get_ctrl(),
                                ts2k_get_int,
                                ts2k_get_rit(), ts2k_set_rit(),
                                ts2k_get_ts(), ts2k_set_ts),
                                ts2k_get_xit(), ts2k_set_xit(),
                                ts2k_get_rptr_offs(),
ts2k_set_rptr_offs(),
                                ts2k_get_rptr_shift(),
ts2k_set_rptr_shift(),
                                ts2k_get_split(), ts2k_set_split()
{and it works!}
                                ts2k_get_split_freq(),
ts2k_set_split_freq(),
                                ts2k_set_channel(),
ts2k_get_channel()    {_get works; _set in progress}

I can send you a tarball with all the relavent files if you'd like:
                                kenwood/                ts2k.c, ts2k.h,
ts2000.c
                                include/hamlib       rig.h, rigclass.h
                                c++/
rigclass.cc
                                src/                           rig.c,
misc.c
                                tests/                        rigctl.c
                                icom/                        icom.c

The rigclass change adds the vfo_t parameter to the rig_*_channel()
functions and methods.  Any file
referring to these was affected.  The change should probably *not* be
checked directly into CVS.

New bug found (my code, not CVS):
                                rigctl    'f' freq doesn't work if
entered on command line/batch file.

[Hamlib-developer] kenwood_transaction()

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

I have been having a lot of trouble with the kenwood_transaction() in
kenwood/kenwood.c.  Since this is
a pretty important function it is slowing any work I do tremendously.
I've been hacking at it but only have
it semi-functional.  The section where read_string() is sent is the most
problematic.  Any help, fixes, or
suggestions would be appreciated.

I've attached a two rigctl scripts showing the errors in 1) kenwood.c
and 2) in my developmental ts2k.c.
I've compressed them with gzip this time.  :)

Each was ran after a make install, and 1) was done on hamlib-1.1.3-rc1
with clean sources.
The errors are different but fixing them has been a different story.

Thanks.

Dale E. Edmons
KD7ENI

[Hamlib-developer] [Fwd: Hamlib-cvs-digest digest, Vol 1 #308 - 1 msg]

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

----- Forwarded message from ham...@li... -----

Date: Mon, 10 Jun 2002 12:04:32 -0700
From: ham...@li...
To: ham...@li...
Reply-to: ham...@li...
Subject: Hamlib-cvs-digest digest, Vol 1 #308 - 1 msg
X-Mailer: Mailman v2.0.9-sf.net

Send Hamlib-cvs-digest mailing list submissions to
	ham...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/hamlib-cvs-digest
or, via email, send a message with subject or body 'help' to
	ham...@li...

You can reach the person managing the list at
	ham...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Hamlib-cvs-digest digest..."


Today's Topics:

   1. Testing hamlib-cvs-digest + introduction (Dale E. Edmons)

--__--__--

Message: 1
Date: Mon, 10 Jun 2002 00:25:39 -0700
From: "Dale E. Edmons" <de...@w-...>
Reply-To: de...@w-...
Organization: Ham Station KD7ENI
To: hamlib-cvs-digest <ham...@li...>
Subject: [Hamlib-cvs-digest] Testing hamlib-cvs-digest + introduction

Hi all,

I'm Dale--KD7ENI--and I've been working with the Kenwood TS-2000.  I
have a memory save and
restore utility for the TS-2000 (I often just refer to it as ts2k).
I've also got a utility to send command to the
ts2k.  These allow me to do a full reset and restore for my rig.  They
are simple and commandline only.

My hope is to use hamlib to perform the same tasks more generically for
any rig.  It'll take a lot of work.
I've talked to Stephane on numerous occasions but my e-mail is
marginal.  E-mail's not my thing so I only
fix what I have to when its completely broken.   ;)  Works for me.

I have a sourceforge mail address for hamlib stuff under  "dedmons" for
those who prefer that route.

73's

Dale E. Edmons
KD7ENI




--__--__--

_______________________________________________
Hamlib-cvs-digest mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-cvs-digest


End of Hamlib-cvs-digest Digest


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

-- 
 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 Yamomoto

[Hamlib-developer] Re: Network Interface

[Matt E. <ma...@et...>]

I lost the original reply, so quoting may be difficult...


>Geeez, I can't believe it. Couple of months ago, when I saw gnuradio
> poping up on gnu.org, I thought, these guys will need a User Interface,
> and Hamlib would fit very well with their approach.

Great minds think alike :)

> All you need to do for gnuradio, is to create a new backend (let's call
> it "gnuradio"), and provide set_freq/get_freq, set_mode/get_mode methods
> and so on. In the set_freq method for example, just call the appropriate
> function of gnuradio and link the backend plugin against your library.

Maybe I can write a backend to send commands over IP.

> I guess gnuradio is a little more complex to run, like you need to have the
> control over a main loop to do the DSP stuff. But this can be worked out.
> Practically, you may end up with running gnuradio from rpc.rigd,
> to make it persistant and simplify threads, but the gnuradio *backend*
> won't have to know about RPC.

Like you say, gnuradio can't be a normal backend.  It needs to control its own
main loop.  I'll take a look at the WinRadio backend, maybe there are some ideas
there.

> Sorry I won't be able to play with gnuradio because I don't have a computer
> with PCI slots (laptop), but I'll give a look at the source code anyway
> so we can speak the same language, and help you writting the gnuradio backend.

A common misconception.  GNURadio works with many different ADC and DAC devices.
 Some of us are using those $1200 PCI cards, but this would never take off at
that price.  You can do a lot of interesting stuff with any old sound card which
is supported under linux (ALSA or OSS).  You can also just input from and output
to files.  No hardware necessary at all.

> It's going to be fun!

Yes it is.

Matt
N2MJI

Re: [Hamlib-developer] Network interface

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

Hi Matt,

Quoting Matt Ettus <ma...@et...>:
> Hi.  I'm a developer on GNURadio (
> http://www.gnu.org/software/gnuradio/gnuradio.html ), which is a free software
> defined radio project.  I'd like to use hamlib (and grig with it) for the user
> interface to one of the radios I've designed with GNURadio.

Geeez, I can't believe it. Couple of months ago, when I saw gnuradio
poping up on gnu.org, I thought, these guys will need a User Interface,
and Hamlib would fit very well with their approach.
At that time I was busy, I didn't even bother to send you a mail to let you know
about Hamlib. That's why I'm very pleased you too got the idea.
Excellent, I like it.
And IMHO, SDR is really an exciting area of innovation for ham's, 
with a bright future yet to invent.

> Since there is no serial connection, I was hoping to use a network 
connection. 
> After going through the code, all I see is an RPC backend.  Is there a 
straight
> IP connection available, or is that my only choice?

Hamlib is not dedicated to serial connections. For example, it supports some 
Winradio receiver ISA cards. Software radio will do as well!

> 
> If I read correctly, rpc.rigd creates a daemon which talks to one of the 
regular
> backends.  This is how I picture it --
> 
> 
> frontend (i.e. GRig) --> hamlib RPC backend ---INTERNET
> 
> and on another machine
> 
> INTERNET---> rpc.rigd ---> hamlib radio-specific backend
> 
> Is this correct?

Yes, this is absolutely correct.

>  Is rpc.rigd the best place to look for info on writing
> an RPC driver?

Well, yes, rpc.rigd is the best place to look for info on writing
an *RPC* driver.
However, if I understand your need correctly, then there's no reason to bother 
with RPC at all. RPC is just an indirect (remote) procedure calling machanism.
You have to understand where the Hamlib's layers are. The RPC "backend" is a 
pseudo backend, a kind of trick that adds remote access to any real backend 
as a bonus.
All you need to do for gnuradio, is to create a new backend (let's call 
it "gnuradio"), and provide set_freq/get_freq, set_mode/get_mode methods 
and so on. In the set_freq method for example, just call the appropriate
function of gnuradio and link the backend plugin against your library.

I guess gnuradio is a little more complex to run, like you need to have the
control over a main loop to do the DSP stuff. But this can be worked out.
Practically, you may end up with running gnuradio from rpc.rigd,
to make it persistant and simplify threads, but the gnuradio *backend* 
won't have to know about RPC.

Sorry I won't be able to play with gnuradio because I don't have a computer 
with PCI slots (laptop), but I'll give a look at the source code anyway 
so we can speak the same language, and help you writting the gnuradio backend.

It's going to be fun!


Cheers,
Stephane - F8CFE

[Hamlib-developer] Network interface

[Matt E. <ma...@et...>]

Hi.  I'm a developer on GNURadio (
http://www.gnu.org/software/gnuradio/gnuradio.html ), which is a free software
defined radio project.  I'd like to use hamlib (and grig with it) for the user
interface to one of the radios I've designed with GNURadio.

Since there is no serial connection, I was hoping to use a network connection. 
After going through the code, all I see is an RPC backend.  Is there a straight
IP connection available, or is that my only choice?

If I read correctly, rpc.rigd creates a daemon which talks to one of the regular
backends.  This is how I picture it --


frontend (i.e. GRig) --> hamlib RPC backend ---INTERNET

and on another machine

INTERNET---> rpc.rigd ---> hamlib radio-specific backend

Is this correct?  Is rpc.rigd the best place to look for info on writing an RPC
driver?

Thanks
Matt
N2MJI

Re: [Hamlib-developer] Wasn't 1.1.3 supposed to be frozen last week?

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

On Wednesday 29 May 2002 00:37, Stephane Fillod wrote:

> Please test as much as you can and report. It's the last chance to get
> things included in the 1.1.3 release. But don't worry, 1.1.4 can come o=
ut
> much quicker than 1.1.3 will.
>

Works fine with xlog. Power, S-meter, frequency and mode tested.....

> Cheers,
> Stephane - F8CFE
>

Regards,
Joop PA4TU

Re: [Hamlib-developer] Wasn't 1.1.3 supposed to be frozen last week?

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

On Tue, May 21, 2002, David HM Spector wrote:
> 
> Wasn't there going to bew a 1.1.3 release last week?
> 

Sorry guys, I've been late on this one. Sometimes, you really need to kick me
to get things going :)

So there it is, http://f8cfe.free.fr/ham/hamlib/hamlib-1.1.3-rc1.tar.gz
and rig table at http://f8cfe.free.fr/ham/hamlib/rigmatrix.html

Known problems:
- locator and units conversion
- .spec file to be completed and tested
- perl binding installation
- missing documentation here and there
- certainly more..

Please test as much as you can and report. It's the last chance to get things
included in the 1.1.3 release. But don't worry, 1.1.4 can come out much quicker
than 1.1.3 will.

Cheers,
Stephane - F8CFE

[Hamlib-developer] Wasn't 1.1.3 supposed to be frozen last week?

[David HM S. <sp...@ze...>]

Wasn't there going to bew a 1.1.3 release last week?


David

--------------------------------------------------------------------------------
David HM Spector                        Network Design & Infrastructure Security
sp...@ze...               -or-                     sp...@sp...
voice: +1 631.261.5013                                       Fax: +1 631.262.7497
Amateur Radio: W2DHM (ARRL life member) GridSquare: FN30hv (40.52'45"N 73.21'21"W) 
-.-. --- -. -. . -.-. -  .-- .. - ....  .- -- .- - . ..- .-.  .-. .- -.. .. ---

Re: [Hamlib-developer] hamlib configure

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

Hi Dale,

On Wed, May 01, 2002, Dale E. Edmons wrote:
> I was in Montreal Canada for a month and am back.  I'm trying to pick up
> where I left off.  First, is to check that e-mail has been fixed.

Sorry for the late reply. I was out /P in EU-068 (not so many QSO, mainly because
of local "humidity". hi). I'm now back from my short vacation.

Okay, hamlib 1.1.3 definitely needs to be released. I would propose to upload
a release candidate, and if everyone is fine with it, after say a week, 
finaly make it happen :)

> I checked out the current anonymous CVS and the ./configure still hangs
> when trying to build the Makefile.

Could you include some traces of the failure?


Cheers,
Stephane - F8CFE

[Hamlib-developer] Call for developers (hamradio distribution)

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

Hi,

I am looking for people who want to help setting up a hamradio distributi=
on.=20
It will start as a tiny distro for contesting, with more packages added=20
later-on. A description is on:

http://debianham.sunsite.dk/


A mailing list has been created to get development started, you can join =
in by=20
sending a mail to: deb...@su...

Regards,

Joop PA4TU

[Hamlib-developer] hamlib configure

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

Hi,

I was in Montreal Canada for a month and am back.  I'm trying to pick up
where I left off.  First, is to check that e-mail has been fixed.

I checked out the current anonymous CVS and the ./configure still hangs
when trying to build the Makefile.

Just reply with anything simple and I'll sort out the rest or what ever.

Thanks.

Dale E. Edmons
KD7ENI

Re: [Hamlib-developer] hamlib

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

Hi Colin,

First of all, thanks for your interest in Hamlib. The idea behind this
library is to serve as an abstraction layer, kind of "driver", and not
having to reinvent the wheel each time someone write some Amateur
software.

So far, Hamlib is rather POSIX oriented, mainly from the developpers
culture (hence the unfamiliar downloaded file format you downloaded :). 
However, we are very willing to see Hamlib in use on Win32 systems, 
as well as Mac OS. All in all, the protocol handling code is quite
portable, the build environment isn't.

Actually, I've started some porting work with cygwin (POSIX environment
under windows), and Mac OS X. The sourceforge compile farm helps a lot
on the Mac OS X front, and provided libltdl has the right patch, this
should be okay for this platform. 
Talking about Windows, the port is not complete. The problem is I don't need
myself Hamlib under Windows, and also I don't use VC/VB, just cygwin. 
That's why there's no DLL in the download section. But I'm still ready
to work on this port, as long as there's some beta testers for this
platform. And it looks like you're the one (with the good number of
users world-wide). So let's do it.

I have a question. What are OCX used for? To my (limited) understanding,
this is VB only stuff. Am I wrong? Would a DLL be enough for what you
need?
As you can see, I don't know anything of VB. I guess the DLL file is not
enough. Do you need anything else like header files? or some API entry
list as XBasic do?

So far, using cygwin, I've been able to generate a DLL. Having applications
be able to use it is another story. DLL is such a mess. Why everything
has to be so much complicated under this platform?
My test program can access the frontend, not the backend.
Anyway, Hamlib is a bit tricky too. This is a shared library, the frontend, 
that should be able to load "plugins" (again shared libraries, the backends).
Imagine the nightmare it can be when you want to support multiple
platforms. Trust me, C code portability is nothing compared to compile 
and linking issues. Anyway, thanks to autoconf/automake/libtool, we
should be able to get away with it.
To make it simpler on win32, we may choose to obtain a single DLL,
embedding all the backends (> 1MB). This DLL would be generated by
cygwin tools. However, I'm wondering if VC++/VB will be able to grok it.
If it's not working okay (and you will tell me), I think we'll have to 
not use the autotools for generating the DLL, and use VC to compile it
instead. This will have to be sorted out.

And don't worry, even though you have no rig to test Winlog32 with,
there's a dummy backend that just logs traces of calls, which is very useful
for debugging.


As a conclusion, I would say Hamlib is not yet usable on Win32, 
but if you're willing to, we can do the last mile together to get it working.

Are you interested in?


Regards
Stephane - F8CFE

[Hamlib-developer] hamlib

[<wi...@bt...>]

hi Stephane

I have been looking for something which your project may prove suitable.

As an Amateur Software developer using VB5/6, I am looking for a rig CAT
interface for my software "Winlog32", this is a general purpose free logging
program with quite a good number of users world-wide.

Many of these users have asked me for a simple rig interface to swap
frequency/mode data with the program.

I have looked at the possibility of doing this myself directly but it is a
large undertaking with so many rigs all using different protocol, with no
rigs to test on myself and I really do not have the time to do it anyway.

Does your project use a DLL or OCX that could be used by VB?

If so how may I obtain it?  From your web site the downloaded file formats
are unfamiliar to me!

Can you help.

regards Colin

G0CUZ
wi...@bt...

www.winlog.co.uk

[Hamlib-developer] =?ks_c_5601-1987?B?W7GksO1dIL7GuKe02b/uIL3DwP2/oyDA2r3FwLsgvvex17e5wMy15SDHz7y8v+QuLg==?=

[<ma...@mb...>]

VW50aXRsZWQgRG9jdW1lbnQgICAgICAgICC+yLPnx8+8vL/kLg0KILmruvHA17HbuK69rCDA
1LTPtNkuDQoguau68cDXsdu4rr2stMIgvLyw6MD7wM4gv/nGrrXwwe60z7vnv80gu+e+98Gm
yN63ziAguNbGvLnMtfC+7iDF68fVseK8+sC7IMDMv+vH0Q0KIMPWw7e03CC18MH2xdAgsbPA
57fOILWlwMzFzSC+0MPguea9xMDOIE1QRUe4piCxuMf2x8+/qSC4uLXpvvq9wLTPtNkuIL+p
seK/obTCIMS4vMex4rTJwMwgw7ewoQ0KILXHvu4ov7W5rsDauLcsIMfRsdjA2ri3LCC5q8Da
uLcpvLHFw7D6IERJQ1RBVElPTiCx4rTJwMwgw7ewobXHvu4gwe+8rr+hvK0gILXoseK0ybfC
IMbysKG4pg0KCSDH0iC89iDA1rW1t88gseLIubXHvvq9wLTPtNkuIA0Kv6m3r7rQsrIgwOe5
zMDWtMIgv7W+7rD4us64piDH0iC89iDA1rTCILHiyLi4piC15biztM+02S4NCgkgICAgICAg
ICAgICAgCSAJIAkgIAkgCSAgCSAJIAkgICAgCQkgCSAgCQkgCSAJIAkgICAgCQkgCSAJIAkg
CSAJIAkgCQkJICAgICAgILmruvHA17HbuK69rCDBpsewwLsgucy4riC757/rx9ggILq4vce8
9iDA1r3AtM+02S4gvcXDu8fYwda9w7jpILmrt+FjZLimILnfvNvH2LXluK6w2r3AtM+02S4N
CiDIqMbkwMzB9iA6IHd3dy5tb3ZpZW5nbGlzaC5jby5rcg0KICAgICAgICAgICAgICC43sDP
wLsgv/jEob7KwLi9w7jpILz2vcWwxbrOuKYgILStt6/B1ry8v+QuDQogKMHWKSC+xsDMuMsg
VEVMIDogMDIpNzY2LTA1NzkgRkFYIDogMDIpNzQ3LTM5OTcNCiC8rb/vIMavurC9wyDBvrfO
sbggv6zB9rW/IDEzNi01NiCx4rW2sbPIuLD8IDTD/iA0MDHIow0KIHdlYm1hc3RlckBtb3Zp
ZW5nbGlzaC5jby5rcg0KICA=

[Hamlib-developer] IC-R7000 baud rate

[Chuck H. <n2...@am...>]

Well, I haven't gotten a hold of a service manual for the Icom R7000 which seems
to be the only place this is documented.  However, I had to open up the radio
for other reasons.

On the processor board there is a set of jumpers:
2 labeled baud
1 labeled TR
5 labeled address.

I switched the baud jumper from the position it was in to the other one and the
radio is now talking at 9600 baud on the ci-v interface just fine.

From this, I think I can assume:
There are two baud rates: 1200 (factory default) and 9600
There is a tranceive jumper: on or off
There are five ci-v address for the radio: 08h is the factory default, the
      others are currently unknown.

If someone needs a list of the other ci-v addresses, I'll open it up, set it to
each position, and turn the knob and see what it says.
This will only really be needed if someone wants to put multiple R7000's on the
same CI-V bus.  And if they do that with tranceive enabled and turn the knob on
one, it looks like it will copy the frequency to the others.  (Bug or feature?)

Feel free to let me know if you need any other information.

[Hamlib-developer] Improved Icom error checking

[Chuck H. <n2...@am...>]

As promised, here is my ideas for improved error checking for icom_transaction
and icom_decode.

To make it easier for the user to distinguish between problems, I added two new
error codes (Do you have any better ideas?):

RIG_BUSERROR
  This means something is wrong talking on the CI-V bus.
  (such as transmitted characters did not echo)
  If this is received at program startup, it probably means the computer is not
  talking on the CI-V bus.  (wrong serial port, problems with CI-V interface)

RIG_BUSBUSY
  Detected collision on CI-V bus.

I also used existing error codes:

RIG_ETIMEOUT
  Timeout talking to the radio.
  If this is received at program startup, it probably means there is a problem
  talking to the radio.  (wrong speed, no power to radio, radio not on CI-V,
                          radio did not recognize the command)

RIG_EPROTO
  Something else unexpected happened

In doing my quick testing:
1. With the radio off, I got a RIG_ETIMEOUT
2. With the power removed from the CI-V interface, I got a RIG_BUSERROR
3. I caused some collisions and got a RIG_BUSBUSY, see attached traces

Due to the number of changes to icom_transaction, I included a the entire
replacement routine.  If you want a patch instead, let me know.

I also included a patch that includes the changes to icom_decode, and adding
of the error codes.

Take a look at them and see what you think.

I also noticed my C formating is a bit different then is currently in hamlib,
I fix that if you want.

Also attached are a couple of traces I got while trying to cause collisions:

1. A collision and the stuff around it.
2. A protocol error that didn't get flagged as a collision.  (Extra character
   got stuck in the received frame)  Not sure if we care right now.

Things I noted looking at these and other traces:

1. SA_sigioaction gets called for each received character in icom_transaction
   and is ignored due to hold_decode.  I assume this won't cause too much
   of a performance problem.
2. sa_sigioaction is getting called once after each icom_transaction with no
   characters in the input buffer and icom_decode then times out.
   (Maybe icom_decode needs to pass a flag to read_string to set the timeout
    to zero for the first character?)
3. The collision character gets sent quite a few times when a collision occurs.
4. The radio attempts to resend the frame that caused the collision, but
   sometimes another character ends up in the input buffer before it.
   (Maybe we should ignore characters before the FE in the frame?)
5. If I turn the dial even fairly slowly, you get stuck in icom_decode enough
   that the main program doesn't run at all.  
   This may be partially caused by the fact that my CI-V bus is currently at
   1200 bps.  At 1200 bps, a frequency change tranceive frame takes about a
   1/10th of a second to be received.
   Maybe getting individual characters and processing them with a state
   machine would help.
   Since it's not really bothering me right now, I'll leave it alone for now.
   But I'll take a look at it if someone else is interested.
   (My main program is just dealing with this one radio right now, and it
    recovers fairly quickly after you stop turning the knob)

---

This trace got a collision:


Processing command 3: 'set_freq' '435.177068'
TX 12 bytes
0000     ff fe fe 08 e0 05 68 70 17 35 04 fd    ......hp.5..
sa_sigioaction: activity detected
RX 1 characters
0000     fc     .
problems with rig_set_freq
x = -14
ERROR: rig_set_freq 'Communication bus collision'

Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 1 characters
0000     fc     .
icom: icom_decode saw a collision
pn = -1
Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 10 characters
0000     f8 08 e0 05 68 70 17 35 04 fd  ....hp.5..
icom_decode: CI-V 0x8 called for 0x5!
icom_decode: tranceive cmd unsupported 0x68
sa_sigioaction: activity detected
icom: icom_decode called
RX 1 characters
0000     fc     .
icom: icom_decode saw a collision
sa_sigioaction: activity detected
icom: icom_decode called
RX 1 characters
0000     fc     .
icom: icom_decode saw a collision
pn = -1
Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 1 characters
0000     fc     .
icom: icom_decode saw a collision
pn = -1
Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 11 characters
0000     fe fe 00 08 00 00 52 17 35 04 fd       ......R.5..
Rig 0x8050a78 changed freq to 435175200 Hz
passed xslot = 0
On slot 1: 'radio_freq_event 435.175200

---

This trace got a RIG_EPROTO:


Processing command 3: 'set_freq' '145.941951'
TX 12 bytes
0000     ff fe fe 08 e0 05 50 19 94 45 01 fd    ......P..E..
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
RX 13 characters
0000     fe f9 fe fe 08 e0 05 50 19 94 45 01 fd .......P..E..
problems with rig_set_freq
x = -8
ERROR: rig_set_freq 'Protocol error'

Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 6 characters
0000     fe fe e0 08 fb fd      ......
icom_decode: tranceive cmd unsupported 0xfb
sa_sigioaction: activity detected
icom: icom_decode called
RX 11 characters
0000     fe fe 00 08 00 00 15 94 45 01 fd       ........E..
Rig 0x8050a78 changed freq to 145941500 Hz
passed xslot = 0
On slot 1: 'radio_freq_event 145.941500
'

Re: [Hamlib-developer] failures with latest kenwood.c in CVS

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

On Fri, 15 Mar 2002 20:40:10 +0100
Stephane Fillod <f4...@fr...> wrote:

> Let me know how it goes.

Works! There was a small error in kenwood.c, which I have
fixed in CVS.

> 
> 73's
> Stephane
> 

Thanks,
Joop PA4TU

Re: [Hamlib-developer] failures with latest kenwood.c in CVS

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

On Fri, 15 Mar 2002 20:40:10 +0100
Stephane Fillod <f4...@fr...> wrote:

> 
> AHA!
> 

AHA!!!

> On Fri, Mar 15, 2002, Joop Stakenborg wrote:
> > Just a quick report with the latest hamlib CVS. I noticed
> > changes to the kenwood_transaction function, which causes failures
> > with xlog. The first few commands are OK, then a get rejects and
> 
> okay, kenwood_transaction changed a bit. It checks now for max received
> bytes. The kenwood_* funcs were not setting this limit. Should be fixed
> now.
> 

Thanks for the prompt reply Stephane. Will test it right away and
let you know later.

> Also commited a fix to rig_get_strengh. It is supposed to return 0
> for S9 (and -54 for S0). Joop, I've attached a fix for xlog-0.6rc1. 
> Works okay with my IC706. Status bar is cute :)
> 

Thanks again...

> Let me know how it goes.
> 

Yup, just got fr.po from jean-luc, so will upload rc2 soon....

> 73's
> Stephane
> 

Joop PA4TU

Re: [Hamlib-developer] failures with latest kenwood.c in CVS

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

AHA!

On Fri, Mar 15, 2002, Joop Stakenborg wrote:
> Just a quick report with the latest hamlib CVS. I noticed
> changes to the kenwood_transaction function, which causes failures
> with xlog. The first few commands are OK, then a get rejects and

okay, kenwood_transaction changed a bit. It checks now for max received
bytes. The kenwood_* funcs were not setting this limit. Should be fixed
now.

Also commited a fix to rig_get_strengh. It is supposed to return 0
for S9 (and -54 for S0). Joop, I've attached a fix for xlog-0.6rc1. 
Works okay with my IC706. Status bar is cute :)

Let me know how it goes.

73's
Stephane

[Hamlib-developer] failures with latest kenwood.c in CVS

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

Hello hamlib lovers,

Just a quick report with the latest hamlib CVS. I noticed
changes to the kenwood_transaction function, which causes failures
with xlog. The first few commands are OK, then a get rejects and
timeouts. Xlog polls the rig every 350 ms for information on
frequency, mode, ptt and s-meter (darn, wanted to test and commit
get_level(RFPOWER) for those extra xlog fields). 

Failure starts with a reply to the second 'IF;' command 
(used for get_ptt). Here is the trace, starting from the beginning:

TX 3 bytes
0000     46 52 3b       FR;
RX 4 characters
0000     46 52 30 3b    FR0;
TX 3 bytes
0000     46 52 3b       FR;
RX 4 characters
0000     46 52 30 3b    FR0;
TX 3 bytes
0000     46 41 3b       FA;
RX 14 characters
0000     46 41 30 30 30 31 30 31 31 32 37 37 30 3b      FA00010112770;
TX 3 bytes
0000     4d 44 3b       MD;
RX 4 characters
0000     4d 44 33 3b    MD3;
TX 3 bytes
0000     49 46 3b       IF;
RX 38 characters
0000     49 46 30 30 30 31 30 31 31 32 37 37 30 20 20 20        IF00010112770   
0010     20 20 2d 30 30 31 36 30 30 20 39 39 30 33 30 30          -001600 990300
0020     30 30 30 38 20 3b                                      0008 ;
TX 3 bytes
0000     53 4d 3b       SM;
RX 7 characters
0000     53 4d 30 30 30 36 3b   SM0006;
TX 3 bytes
0000     46 52 3b       FR;
RX 4 characters
0000     46 52 30 3b    FR0;
TX 3 bytes
0000     46 41 3b       FA;
RX 14 characters
0000     46 41 30 30 30 31 30 31 31 32 37 37 30 3b      FA00010112770;
TX 3 bytes
0000     4d 44 3b       MD;
RX 4 characters
0000     4d 44 33 3b    MD3;
TX 3 bytes
0000     49 46 3b       IF;
RX 3 characters
0000     49 46 30       IF0
kenwood_get_ptt: wrong answer len=3
TX 3 bytes
0000     53 4d 3b       SM;
RX 2 characters
0000     53 4d  SM
RX 1 characters
0000     30     0
read_string: timedout without reading a character
TX 3 bytes
0000     46 52 3b       FR;
RX 4 characters
0000     46 52 30 3b    FR0;
TX 3 bytes
0000     46 41 3b       FA;
RX 14 characters
0000     46 41 30 30 30 31 30 31 31 32 37 37 30 3b      FA00010112770;
TX 3 bytes
0000     4d 44 3b       MD;
RX 4 characters
0000     4d 44 33 3b    MD3;
TX 3 bytes
0000     49 46 3b       IF;
RX 3 characters
0000     49 46 30       IF0
kenwood_get_ptt: wrong answer len=3

[...]

As you can see, response from the rig is incomplete in 2 out of 4 commands.
Maybe Stephane says "AHA!" here, but I sure don't, at least not after
I have studied the code more thorougly.

I will be happy to do more tests.
Regards,

Joop PA4TU

Re: [Hamlib-developer] IC735 - first test run

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

On Tue, Mar 12, 2002, dar...@bt... wrote:
> I'm going to be adding to this radio at some point, but will drop a note
> when I get going. 

Sorry, what are you going to add to this radio?
Feature wise, this rig is rather limited.

check with "tests/dumpcaps 319"  to see what it can do and is implemented.

> -------------- List of Functions -------------- 
> 
> F: set_freq        (Frequency)		OK!
> f: get_freq        (Frequency)		OK!
> M: set_mode        (Mode,Passband)      	OK! - USB, LSB, AM, CW
> m: get_mode        (Mode,Passband)		OK!
> V: set_vfo         (VFO)        		??

	MEM, VFO, VFOA, VFOA

> U: set_func        (Func,Func status)   	??
> u: get_func        (Func,Func status)	??

	NB (Noise blanker), COMP, etc.  anything that can be set on/off
	This rig does not support set_func/get_func

> E: set_mem         (Memory#)    		??

	a memory number. For the IC735, the range should be 1..10, 
	and 11-12 for the scan edge. Can you confirm?

> h: get_channel     (Channel)			OK!

	well, a bit bugged. Should be fixed now.

G: vfo_op          (Mem/VFO op)

	FROM_VFO:  i.e. 'MW' on the rig
	TO_VFO:	   i.e. 'M>V' on the rig

> [root@g0wcw tests]# ./rigctl -s 9600 -vvvvv -m 319
[snip]
> Rig command: m
> TX 7 bytes
> 0000     ff fe fe 04 e0 04 fd   .......
> RX 7 bytes
> 0000     ff fe fe 04 e0 04 fd   .......
> RX 6 bytes
> 0000     fe fe e0 04 04 00      ......
> RX 1 bytes
> 0000     fd     .
> icom: Unsupported Icom mode width 0xff00
> Mode: LSB
> Passband: 0

0xff00 should be fixed now. TBC again.

> Rig command: M
> Mode: AM
> Passband: 2400
> TX 9 bytes
> 0000     ff fe fe 04 e0 06 02 02 fd     .........
> RX 9 bytes
> 0000     ff fe fe 04 e0 06 02 02 fd     .........
> RX 6 bytes
> 0000     fe fe e0 04 fa fd      ......
> icom_set_mode: ack NG (0xfa), len=1
> set_mode: error = Command rejected by the rig

Passband data now allowed. Should be fixed now.

> Rig command: h
> Channel: 1
> TX 7 bytes
> 0000     ff fe fe 04 e0 08 fd   .......
> sa_sigioaction: activity detected
> RX 7 bytes
> 0000     ff fe fe 04 e0 08 fd   .......
> sa_sigioaction: activity detected
> RX 6 bytes
> 0000     fe fe e0 04 fb fd      ......
> TX 9 bytes
> 0000     ff fe fe 04 e0 08 00 01 fd     .........
> sa_sigioaction: activity detected
> sa_sigioaction: activity detected
> RX 9 bytes
> 0000     ff fe fe 04 e0 08 00 01 fd     .........
> sa_sigioaction: activity detected
> RX 6 bytes
> 0000     fe fe e0 04 fa fd      ......
> icom_set_mem: ack NG (0xfa), len=1
> TX 7 bytes
> 0000     ff fe fe 04 e0 03 fd   .......
> sa_sigioaction: activity detected
> RX 7 bytes
> 0000     ff fe fe 04 e0 03 fd   .......
> sa_sigioaction: activity detected
> RX 6 bytes
> 0000     fe fe e0 04 03 20      .....
> RX 1 bytes
> 0000     11     .
> RX 1 bytes
> 0000     38     8
> sa_sigioaction: activity detected
> RX 1 bytes
> 0000     21     !
> RX 1 bytes
> 0000     fd     .
> TX 7 bytes
> 0000     ff fe fe 04 e0 04 fd   .......
> sa_sigioaction: activity detected
> RX 7 bytes
> 0000     ff fe fe 04 e0 04 fd   .......
> sa_sigioaction: activity detected
> RX 6 bytes
> 0000     fe fe e0 04 04 01      ......
> RX 1 bytes
> 0000     fd     .
> Channel: 1, Name: ''
> VFO: currVFO, Antenna: 0, Split OFF
> Freq:   21.3811MHz      Mode:   USB     Width:   0Hz
> txFreq: 0Hz     txMode:         txWidth: 0Hz
> Shift: None, Offset: 0Hz, Step: 0Hz, RIT: 0Hz, XIT: 0Hz
> CTCSS: 0.0Hz, CTCSSsql: 0.0Hz, DCS: 0.0, DCSsql: 0.0
> Functions: FAGC NB COMP VOX TONE TSQL SBKIN FBKIN ANF NR AIP APF MON MN RNF ARO L
> OCK MUTE VSC REV SQL BC MBC LMP
> Levels:
>  

About set_mem:
> Rig command: E
> Memory#: 1
> TX 9 bytes
> 0000     ff fe fe 04 e0 08 00 01 fd     .........
                             ^^
set_mem: this extra byte is confusing the rig. This is the case with rigs
that have less than 100 channels. Should be fixed now.

Thanks for the treaces. The CVS has a new version that should work better.

Cheers,
 Stephane F8CFE

Re: [Hamlib-developer] Proposed patch for tranceive hanging

[Bob P. A. <pa...@me...>]

In programming the ICOM IC-R8500 (using Tcl/Tk, not hamlib),
most (but not all) bus collisions I've seen produce 3 hex FC bytes.

The FC byte code is not useful for any other purpose in
the IC-R8500 command set.  Therefore, my tk8500 software interprets
any FC character as indicia of a collision and discards
the remaining bytes in the message.

On Tuesday 12 March 2002 02:39 am, Chuck Hemker wrote:
> 1. In the pdf file (note 1) I have (sections 5-4 and 1-6) it says the r=
adio
> =A0 =A0when seeing a collision:
> =A0 =A0 a. waits till the bus is idle
> =A0 =A0 b. sends the jammer code (FC) 5 times
> =A0 =A0 c. waits till the bus is idle
> =A0 =A0 d. retransmits the frame

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bob Parnass, AJ9S  pa...@me...  http://members.core.com/~parnass
                           Linux user