hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] IC-821H patch

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

Hi Francois,

What a good surprise! Finally, it seems like Hamlib may eventually be useful
to some people.

Quoting Francois Retief <fgr...@su...>:
> I have been following the list for some time.  I would like to submit 
> a patch for the Icom IC-821H radio.  It is not thoroughly tested, 
> there is some things I don't understand.  I don't know to much about
> radios.  I would appreciate it if you can correct it.  The patch
> is against the current CVS (2001-12-19).

okay, the patch looks fine, I'll commit it tonight, plus some misc fixes.
If you plan to be a regular contributor to Hamlib, you can be added
to the developper team, with cvs write access.

> We have two IC-821Hs on a CIV box.  I can also help with testing 
> the IC-475H radio.  Please supply details on how I can help test.

Right now, you'd have to write your own program if you want to test
both IC-821Hs at the same time (concurrent access is not tested, and 
most probably not very robust: to be fixed).
Anyway, testing only one rig at a time is a lot easier, esp. with rigctl.

    rigctl -m <your model id> --civaddr <the CI-V addr in *decimal*>

Then, you are presented with a somewhat interactive menu. From there,
test what you need. If you want to do a little bit more, test every single
command the rig has, error cases, plus the unsupported commands (hidden 
commands?).
When something goes wrong, please report traces with -vvv arg passed to rigctl.

You might also want to give kontakt a try if you're looking for a GUI.

> The part I am really interested in is the RPC rig.  Is it usable/
> testable?  We are working towards a ground station system

Your project looks cool, and it reminds me a similar project (groundstation
project on sf).
RPC rig is not usable in every day life yet (AFAICR, only set_freq works), 
because it's in the early proof-of-concept phase. However, the RPC rig 
is just waiting for someone to write a decent .x file, and implement 
all the calls.
Any takers? (It's on my TODO list though)

> that uses RPC to control different hardware (wel, XML-RPC in the 
> current alpha design). Hamlib would fit in nicely in the 

As far as I can tell, the gory details of the RPC rig is totaly hidden
in Hamlib frontend/backend. I don't know how it would fit with XML-RPC, 
may be it's because I don't know XML-RPC at all :)

> architecture.  My work have been primarily on antenna control
> (a 4.5m dish antenna and a Yaesu G-5400B rotator)

Ha! I'd love to integrate rotator control in Hamlib (even though I don't own
any yet). Are you interrested in ? I can help with the frontend work at least.
We would have to discuss the rotator capabilities too, and as for the radios,
there could be a RPC rotator backend.

Anyway, thank you very much for the patch.
If you have a ham license on HF, we can arrange for a sked during vacations
if needed.

Cheers,

Stephane F8CFE



From your attached patch:

+#define IC821H_ALL_RX_MODES (RIG_MODE_SSB|RIG_MODE_CW|RIG_MODE_FM)
+/* FIXME: Is this all the modes? What does RTTY mean? */

RTTY is also known as FSK mode on Kenwood rigs. Mostly used on HF bands.

+#define IC821H_VFO_ALL (RIG_VFO_A|RIG_VFO_B)
+/* FIXME: What about MAIN/SUB mode? And satellite mode? */

Well, I'm not very satisfied with the current design of Hamlib concerning
MAIN/SUB handling. It's not that easy. Comments, advices and proposals
on that subject are very welcome. We have to deal with API calls and
also with rig capability description (i.e. what is can do).

Right now, RIG_VFO_A and RIG_VFO_B are on MAIN, while RIG_VFO_C are on SUB.
See include/hamlib/rig.h definitions. There's also a post on this list, 
maybe 6 months ago discussing of the topic

The antenna caps description structures in Hamlib are in the same state: not 
finished.

Back to the IC821H, is it 2 independant and full duplex VFO's? Or just one
full duplex VFO in "split" mode ?

That reminds me there's nowhere in the caps we can say that VFO's are
half or full duplex with respect with themselve or with others.

+#define IC821H_SCAN_OPS (RIG_SCAN_MEM)
+/* FIXME: Manual talks about 3 modes: Programmed scan, Memory scan and
+ * Mode select memory scan operation. How do i encode these?
+ */

Just find the associated RIG_SCAN_ with your function. Not very well tested
with icom backend.

+serial_rate_min: 9600, //300,	Force 9600baud for debugging... 
+serial_rate_max: 9600, //19200,  

can be changed at run time, cf rigctl.

+max_rit: kHz(5),     /* SSB,CW: +-1.0kHz  FM: +-5.0kHz */
+max_ifshift: kHz(1.2),

can it be changed through CI-V protocol? 

+transceive: RIG_TRN_OFF,    /* ?? */

i.e. is the rig able to automatically send an "update" when you tune 
the VFO knob. Most icom do.

+bank_qty:  0,               /* ?? */

number of banks

+chan_desc_sz: 0,            /* ?? */

length of memory channel name

+chan_list: {
+                   {   1,  80, RIG_MTYPE_MEM,   0 },    /* FIXME: Each band 
has 80 channels (2*80) */

is it like 2 banks?

+                   {  81,  82, RIG_MTYPE_EDGE,  0 },
+				   RIG_CHAN_END,
+		},
+
+rx_range_list1:  { RIG_FRNG_END, }, /* ?? FIXME: enter region 1 setting */
+tx_range_list1:  { RIG_FRNG_END, }, /* <stupid question> What is region 1? 
</stupid question> */

Region 1 is ITU region. For example, among others, USA are in region 2, 
Europe in region 1.
It helps allocating frequency band plan among users.

+rx_range_list2:  {
+    {MHz(144.0),MHz(148.0),IC821H_ALL_RX_MODES,-1,-1,IC821H_VFO_ALL},
+    {MHz(430.0),MHz(450.0),IC821H_ALL_RX_MODES,-1,-1,IC821H_VFO_ALL},
+	RIG_FRNG_END, },
+    /* FIXME:
+     *   From manual:    VHF                UHF
+     * USA           144.0-148.0 MHz    430.0-450.0 MHz
+     * Europe        144.0-146.0 MHz    430.0-440.0 MHz
+     * Australia     144.0-148.0 MHz    430.0-450.0 MHz
+     * Sweden        144.0-146.0 MHz    432.0-438.0 MHz
+     */

USA,Australia: region 2
Europe,Sweden: region 1 (Sweden version will need a rig_set_conf override)

[Hamlib-developer] IC-821H patch

[Francois R. <fgr...@su...>]

Hello Stephane Fillod,

I have been following the list for some time.  I would like to submit 
a patch for the Icom IC-821H radio.  It is not thoroughly tested, 
there is some things I don't understand.  I don't know to much about
radios.  I would appreciate it if you can correct it.  The patch
is against the current CVS (2001-12-19).

We have two IC-821Hs on a CIV box.  I can also help with testing 
the IC-475H radio.  Please supply details on how I can help test.

The part I am really interested in is the RPC rig.  Is it usable/
testable?  We are working towards a ground station system
that uses RPC to control different hardware (wel, XML-RPC in the 
current alpha design). Hamlib would fit in nicely in the 
architecture.  My work have been primarily on antenna control
(a 4.5m dish antenna and a Yaesu G-5400B rotator)

Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

Re: [Hamlib-developer] Hi

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

On Wed, Dec 19, 2001, John Ronan wrote:
> I just came across hamlib, if I get time over xmas I'll try and test the Aor 8200 support. I may be able to help with FT1000 support after that.
 
Great! the AR-8200 as never been tested. Anyway, let me know how it works
for you, I can help if you need, and please report with rigtctl -vvvv
traces so I can fix it.
Patches or CVS commits welcome too!

Cheers,
Stephane F8CFE 

[Hamlib-developer] Hi

[John R. <j0...@ts...>]

Hi,
I just came across hamlib, if I get time over xmas I'll try and test the Aor 8200 support. I may be able to help with FT1000 support after that.

Regards
John


-- 
John Ronan <j0...@ts...>, +353-51-302938
Telecommunications Software Systems Group - WIT, http://www.tssg.org

Re: [Hamlib-developer] Re: NRD-545 commands, cvs

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

* Stephane Fillod <f4...@fr...> [2001 Dec 18 05:37 -0600]:
> I would say orange first since it's still untested, but you can make it
> green right now to save you an update in the next days.
> 
> BTW, the Kenwood status can be turned to green, and the yaesu also.

I completed that this evening and uploaded the new pages to the site.

> I cloned it from http://www.buzzard.org.uk/jonathan/scanners-usb.html
> Hence the note at the top of the supported.html file.

Okay, I left the comment in the page source.

> It seems Jonathan has introduced new colors. That'd be a good idea to
> do so, and add brown and blue status.
> The Yaesu VR-5000 can then be classified as blue (?).

Looking over Jonathan's page, it seems that the red category may have
been split into brown and blue.  We could take this track, but right now
the table shows no red slots (yipee!)

> Your proposal of adding a note that the Hamlib Group is an "alias" for all
> the people in the AUTHORS should be an acceptable workaround.
> Any comments? advice?

I added a notice in each source file and some visible text at the bottom
as a copyright notice.

Look things over and let me know of any changes.

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 Yamomoto

Re: [Hamlib-developer] Re: NRD-545 commands, cvs

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

Quoting Nate Bargmann <n0...@ne...>:

> * Stephane Fillod <f4...@fr...> [2001 Dec 17 17:11 -0600]:
> > 
> > > I'm hoping you can remove the red mark next
> > > to the JRC entry on your web page:
> > > 
> > >  http://hamlib.sourceforge.net/support.html
> > 
> > Sure, I'll ask Nate (N0NB) to do so.
> 
> Not a problem, I updated it last night for the FT-817 per Chris'
> request.  What color should it be, orange or green?

I would say orange first since it's still untested, but you can make it
green right now to save you an update in the next days.

BTW, the Kenwood status can be turned to green, and the yaesu also.

> BTW, Stephane, is there a tool you used to create support.html, or was
> it created as a static page based on your knowledge of the support?

I cloned it from http://www.buzzard.org.uk/jonathan/scanners-usb.html
Hence the note at the top of the supported.html file.

It seems Jonathan has introduced new colors. That'd be a good idea to
do so, and add brown and blue status.
The Yaesu VR-5000 can then be classified as blue (?).

> Also, if I may do so with your permission, I'd like to take over
> maintenance of support.html and build it with Wsmake.  How can I modify
> your copyright if I continue to modify it?

oh yes please, go ahead. It makes much sense to has everything under wsmake.
About the copyright, I don't care very much as long as it respects
the original note from the USB SANE page, and the information stays free.
To make it easier, you can turn the copyright to the Hamlib Group,
even though there's no such *legal* entity (and I am definitely NOT a lawyer
either!).
Your proposal of adding a note that the Hamlib Group is an "alias" for all
the people in the AUTHORS should be an acceptable workaround.
Any comments? advice?

Thanks,

73,
Stephane F8CFE

Re: [Hamlib-developer] Re: NRD-545 commands, cvs

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

* Stephane Fillod <f4...@fr...> [2001 Dec 17 17:11 -0600]:
> 
> > I'm hoping you can remove the red mark next
> > to the JRC entry on your web page:
> > 
> >  http://hamlib.sourceforge.net/support.html
> 
> Sure, I'll ask Nate (N0NB) to do so.

Not a problem, I updated it last night for the FT-817 per Chris'
request.  What color should it be, orange or green?

BTW, Stephane, is there a tool you used to create support.html, or was
it created as a static page based on your knowledge of the support?

Also, if I may do so with your permission, I'd like to take over
maintenance of support.html and build it with Wsmake.  How can I modify
your copyright if I continue to modify it?

Right now the pages I created are listed as copyright N0NB, however,
could this be changed to the Hamlib Group with contributing authors of
docs and/or code listed in the AUTHORS files.  I realize that Hamlib
Group is not a legal entity (and I am definitely NOT a lawyer!), but
doing something like this is better than trying to keep track of
individual contributions.

I'm not sure how other project handle this, and hopefully I'm bringing up
a non-issue.  It just seems like the GPL has a strict attribution policy
and I'm a bit lazy when it comes to documenting a bunch of HTML!

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 Yamomoto

[Hamlib-developer] Re: NRD-545 commands, cvs

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

Hey Bob!

> I have not used CVS before.

Okay, CVS is a powerful tool, a little bit cumbersome at the first glance,
but proves to be very helpful in the long run.
Anyway, I'll roll you a tar ball so it's easier for you to test.

> I'm hoping you can remove the red mark next
> to the JRC entry on your web page:
> 
>  http://hamlib.sourceforge.net/support.html

Sure, I'll ask Nate (N0NB) to do so.

> It's very good of JRC to document the protocol
> in the user manual.  

Well, I've been enable to find the protocol specs on the web.
On the other side, the user manual is not quite good.

> The protocol for
> other company equipment (e.g., Yaesu VR-500)
> is kept "secret," therefore owners are stuck using
> only vendor-approved software, which is
> mediocre quality and never runs on Linux :-(
> [C'est une domage (?)]

Yep, "c'est domage" (hey, do you mean I can continue this mail in
french? :)
It's too bad some protocol are kept closed. Maybe under "fair use",
it should be possible to reverse engineer the protocol. 
There's nothing easier to do with a serial link!

I have couple of questions about the JRC backend and esp. the NRD-545:

* What is the Attenuator level in dB?
* In the manual, there's a WFM mode. What is the selectivity at -6dB of
  WFM. Is it broadcast WFM (230kHz) ?
* How many number of VFO are there ? just one ?
* What are ECSS mode ? Is synchronous LSB/USB/AMS?
  Should it be considered as a different mode like AM/AMS or just a
  function?
* What is the S-meter conversion table: "M" 000-255 -> dB  (with S9 = 0dB)
* What is BWC?  some kind of Band Width Control?
* Is it possible to get mode and IF bandwidth "D"CR and "B"CR ?
	and "T" power supply mode?
* What is the "O" Turn timer relay ON/OFF?
* What is the "Y" command used for?


Okay, enough for today. Tomorrow, if time permits, I'll code the most
important function: the "AA" command to set dimmer. hi.


Cheers,
Stephane

Re: [Hamlib-developer] Japan Radio NRD-545 commands

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

Hi Bob!

On Sun, Dec 16, 2001, Bob Parnass, AJ9S wrote:
> This is my first posting.  I have no experience with
> using the hamlib API, but I can provide interface
> information for the Japan Radio NRD-545 receiver.
 
Oh yes, please!

> I'm nearly finished writing a control program for the
> JRC NRD-535D receiver.  The software is written in
> Tcl/Tk so it runs on either Linux or Windows 98.  Haven't
> tested it on Macs, Solaris, or operating systems due to
> a lack of resources.

Hamlib too has Tcl/Tk wrapper (well uncomplete), in case your are
interrested in. Win32 is also supported thanks to cygwin.
 
> I can provide a copy of the NRD-545 computer command documentation
> which consists of 6 or 7 pages.  I can
> send a scanned copy or (more easily) mail a paper copy
> to a hamlib developer located in the USA if there's a demand.

I'd be very happy if you can send a scanned copy to f4...@fr...
A paper copy would better, but I live in France.
As soon as the backend is written, you'll be the first one to test it!!
Anyway, thank you very much for your help in the project.

73,

Stephane F8CFE

[Hamlib-developer] Japan Radio NRD-545 commands

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

Hello hamlib,

This is my first posting.  I have no experience with
using the hamlib API, but I can provide interface
information for the Japan Radio NRD-545 receiver.

I'm nearly finished writing a control program for the
JRC NRD-535D receiver.  The software is written in
Tcl/Tk so it runs on either Linux or Windows 98.  Haven't
tested it on Macs, Solaris, or operating systems due to
a lack of resources.

I learned the NRD-545 commands by studying the documentation
in the NRD-545's instruction manual.  So far, JRC's documentation
has been accurate.  I've used most, but not all, of their
commands.

The NRD-545 serial port receives and sends simple ASCII
character sequences and I've found it easy to use.  Looks
a lot "cleaner" than the commands to control an ICOM IC-R8500.

I can provide a copy of the NRD-545 computer command documentation
which consists of 6 or 7 pages.  I can
send a scanned copy or (more easily) mail a paper copy
to a hamlib developer located in the USA if there's a demand.
-- 
=======================================================================
Bob Parnass, AJ9S                                  pa...@me...
                           Linux user

Re: [Hamlib-developer] TS-870: test 1

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

Thank you Joop, this is a very high quality report!
As you catched it, it turns out I left couple of bugs in the Kenwood
backend. For example, the get_mode "MD" which is not sending the ";".

About the get_vfo function, I still have to transform them to meaningful
strings in rigctl. Right now, the numbers are internal representation of
Hamlib (see include/hamlib/rig.h if you want). And yes, the ones you got
seems to be correct.

set_vfo: this is fine, It works. Now, I though I fixed the timeout
annoying message. I didn't. Or at the wrong place. This will be done
tomorrow (some low level function to be rework: fread_block).

set_freq: actually, error messages from the rig are ignored. will be
fixed with the rest.

set_mode: passband is mode pass band width. Most of the time, this
is narrow/normal/wide. Within Hamlib, this parameter is the width
in Hz, as found in the caps. Some macros exists.
I'll change rigctl so it can accept some aliases (narrow, normal, etc.).
BTW, 0 is default, i.e. normal passband.

You have tested the first level of support: set_vfo/get_vfo,
set_freq/get_freq and set_mode/get_mode.
Second level is memory support: set_mem/get_mem, set_channel/get_channel
(not supported in rigctl yet), etc.
Third level: get/set func/level/parms, whatever.

Thanks very much for your detailed report. I hope to provide you with a
new version before the end of the week.

Cheers,

Stephane F8CFE

[Hamlib-developer] TS-870: test 1

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

Hi Folks,

I have played around with minicom (works now), rigctl and some
of the kenwood commands, for setting and reading frequency, mode
and VFO. Reading frequency works flawless, so it is not included.

Attached is test1. I hope it can give Stephane something to hold
on to. Most common problem is still the timeouts when trying to
set something.

The tests are quite hard to automate, because there are so many 
different commands and return strings. Maybe if I get to know
the rig better, things will go a bit quicker. Anyway, here is
the first try. A full test is harder than I thought.....

(version is 1.1.3-pre1-pa4tu)

Regards,

Joop PA4TU

Re: [Hamlib-developer] First results with TS-870

[Joop S. <jo...@ri...>]

On Tue, 11 Dec 2001 22:52:52 +0100
Stephane Fillod <f4...@fr...> wrote:

> On Tue, Dec 11, 2001, Joop Stakenborg wrote:
> > Here are result for reading f (with the frequency set to 21010.01 kHz)
> > and setting the frequency to 14000.00 kHz.
> 
> Did it set the 14000.00 kHz frequency alright? I guess so..
> 

Yes.

> 
> The Kenwood protocol has provision for returning error message when
> something goes wrong. However, most commands don't take an acknowledgment.
> Hence the kenwood backend has to wait for the error message till timeout,
> but should not report a timeout error if not reply expected.
> I've made a fix. Please let me know if it worked out the problems.
> 
> Just to make it easier for you, I've uploaded a snapshot you can download
> from http://f8cfe.free.fr/ham/hamlib/hamlib-1.1.3-pre1-pa4tu.tar.gz
> 

Thanks!

> > I am interested in setting up some kind of test program for this rig.
> 
> Me too :-)  You can write it in C, C++. Also it should be possible to use
> rigctl non-interactively from the command line, or in a shell
> script.

Ok, I will try and test every rigctl command and wil get
back to you with a full report.

> 
> Cheers,
> 
> Stephane F8CFE
> 

Joop PA4TU

Re: [Hamlib-developer] [Fwd: hamlib, radios]

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

Alright, TS-2000 has just been added to the CVS tree. Ready to be tested!

Cheers,
Stephane F8CFE

On Mon, Dec 10, 2001, Nate Bargmann wrote:
> Here's a message I received.  I think much of this information is more
> useful to Stephane than I, since he's doing the bulk of the coding right
> now.  I'll reply and invite him to the list.
> 
> 73, de Nate >>
> 
> ----- Forwarded message from Dale Edmons <de...@go...> -----
> 
> Date: Mon, 10 Dec 2001 13:11:56 -0800 (PST)
> From: Dale Edmons (Main Dialup) <de...@go...>
> To: n0...@ar...
> Subject: hamlib, radios
> X-Mailer: ELM [version 2.4 PL25]
> 
> Hi,
> 
> I'm KD7ENI/AG.  :) {as of Saturday}   I currently own the following radios:
> 
> 	Handheld:
> 		HTX-245		Radio Shack
> 		IC-W32A		ICOM
> 
> 	Mobile / Base:
> 		TS-2000
> 
> All these presumeably support ascii protocols, however, I only have the
> cable for the TS-2000 since it is simply a DB-9 straight through cable.
> 
> I have downloaded hamlib and will be checking things out.  If I get
> good results or bugfixes I'll let you know.  The hardcopy of the
> TS-2000 manual has several errors.  I haven't cross checked with their
> pdf version yet but some of the programming stuff does not jive with
> actual responses.  Again, I'll let you know when I've confirmed the pdf
> file.
> 
> If you have time setup template definitions for the above radios and I'll
> do what I can to get at least backup/restore type operations to function
> for them.  This assumes I can find enough info on the handhelds.  Kenwood's
> serial stuff works great so far despite the errors.  I don't have cables
> for the handhelds yet and am loath to purchase them if they may be easily
> built.
> 
> Any data/pointers will be appreciated.
> 
> I hope to help out on the project (Linux side only).  My aim is to build a
> backup restore function for the above radios.  The radio shack is very
> much a pain to program, so I want the backup to be and editable text file.
> 
> We'll see how it goes.  I'm not well known for being able to complete one
> project before another captures my interest (like my "Poor Man's Spectrum
> analyzer" from Science Workshop).
> 
> My e-mail sometimes goes a week or so without getting checked so don't
> be concerned if you don't get an instant response.  I get very little
> e-mail and generally like to keep it that way.   :)
> 
> Thank you for making hamlib available.
> 
> 73's
> 
> Dale E. Edmons
> KD7ENi
> 
> 
> 
> ----- 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 mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
> 

Re: [Hamlib-developer] First results with TS-870

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

On Tue, Dec 11, 2001, Joop Stakenborg wrote:
> Here are result for reading f (with the frequency set to 21010.01 kHz)
> and setting the frequency to 14000.00 kHz.

Did it set the 14000.00 kHz frequency alright? I guess so..

[...]
> 0000     30     0
> RX 1 bytes
> 0000     30     0
> RX 1 bytes
> 0000     31     1
> RX 1 bytes
> 0000     30     0
> RX 1 bytes
> 0000     3b     ;
> Frequency: 4611874313014867927
             ^^^^^^^^^^^^^^^^^^^
Stupid bug (as always they tend to be), and stupid me (ahem ...)
the sscanf in kenwood_get_freq() was scaning from the "FA..." and not the 
digits. This is fixed now in the CVS tree.

> TX 14 bytes
> 0000     46 41 30 30 30 31 34 30 30 30 30 30 30 3b      FA00014000000;
> fread_block: timedout after 0 chars
> set_freq: error = Communication timed out

Pretty obvious when reading the (untested) code. 
The problem is I just have some piece of manual, no harware to test with.

The Kenwood protocol has provision for returning error message when
something goes wrong. However, most commands don't take an acknowledgment.
Hence the kenwood backend has to wait for the error message till timeout,
but should not report a timeout error if not reply expected.
I've made a fix. Please let me know if it worked out the problems.

Just to make it easier for you, I've uploaded a snapshot you can download
from http://f8cfe.free.fr/ham/hamlib/hamlib-1.1.3-pre1-pa4tu.tar.gz

> I am interested in setting up some kind of test program for this rig.

Me too :-)  You can write it in C, C++. Also it should be possible to use
rigctl non-interactively from the command line, or in a shell
script.

Cheers,

Stephane F8CFE

[Hamlib-developer] First results with TS-870

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

Hi Stephane and others,

Setting the communication parameters to 57600 bps has done the trick!
This is the maximum speed that the rig can handle.
Here are result for reading f (with the frequency set to 21010.01 kHz)
and setting the frequency to 14000.00 kHz.
The frequency is not displayed correctly, even though the received characters
are OK. Also, note the timeout when setting the frequency:

aba@pc3:~$ rigctl -vvvvv -m 210
rig:rig_init called 
rig: loading backend kenwood
kenwood: _init called
rig_register (203)
rig_register (204)
rig_register (216)
rig_register (210)
rig:rig_open called 
TX 3 bytes
0000     46 52 3b       FR;
RX 1 bytes
0000     46     F
RX 1 bytes
0000     52     R
RX 1 bytes
0000     30     0
RX 1 bytes
0000     3b     ;
Opened rig model 210, 'TS-870S'

Rig command: f
TX 3 bytes
0000     46 52 3b       FR;
RX 1 bytes
0000     46     F
RX 1 bytes
0000     52     R
RX 1 bytes
0000     30     0
RX 1 bytes
0000     3b     ;
TX 3 bytes
0000     46 41 3b       FA;
RX 1 bytes
0000     46     F
RX 1 bytes
0000     41     A
RX 1 bytes
0000     30     0
RX 1 bytes
0000     30     0
RX 1 bytes
0000     30     0
RX 1 bytes
0000     32     2
RX 1 bytes
0000     31     1
RX 1 bytes
0000     30     0
RX 1 bytes
0000     31     1
RX 1 bytes
0000     30     0
RX 1 bytes
0000     30     0
RX 1 bytes
0000     31     1
RX 1 bytes
0000     30     0
RX 1 bytes
0000     3b     ;
Frequency: 4611874313014867927
Rig command: F 14000000
TX 3 bytes
0000     46 52 3b       FR;
Frequency: RX 1 bytes
0000     46     F
RX 1 bytes
0000     52     R
RX 1 bytes
0000     30     0
RX 1 bytes
0000     3b     ;
TX 14 bytes
0000     46 41 30 30 30 31 34 30 30 30 30 30 30 3b      FA00014000000;
fread_block: timedout after 0 chars
set_freq: error = Communication timed out

Rig command: q
rig:rig_close called 
rig:rig_cleanup called 
aba@pc3:~$ 


I am interested in setting up some kind of test program for this rig.
Regards,

Joop PA4TU

[Hamlib-developer] [Fwd: hamlib, radios]

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

Here's a message I received.  I think much of this information is more
useful to Stephane than I, since he's doing the bulk of the coding right
now.  I'll reply and invite him to the list.

73, de Nate >>

----- Forwarded message from Dale Edmons <de...@go...> -----

Date: Mon, 10 Dec 2001 13:11:56 -0800 (PST)
From: Dale Edmons (Main Dialup) <de...@go...>
To: n0...@ar...
Subject: hamlib, radios
X-Mailer: ELM [version 2.4 PL25]

Hi,

I'm KD7ENI/AG.  :) {as of Saturday}   I currently own the following radios:

	Handheld:
		HTX-245		Radio Shack
		IC-W32A		ICOM

	Mobile / Base:
		TS-2000

All these presumeably support ascii protocols, however, I only have the
cable for the TS-2000 since it is simply a DB-9 straight through cable.

I have downloaded hamlib and will be checking things out.  If I get
good results or bugfixes I'll let you know.  The hardcopy of the
TS-2000 manual has several errors.  I haven't cross checked with their
pdf version yet but some of the programming stuff does not jive with
actual responses.  Again, I'll let you know when I've confirmed the pdf
file.

If you have time setup template definitions for the above radios and I'll
do what I can to get at least backup/restore type operations to function
for them.  This assumes I can find enough info on the handhelds.  Kenwood's
serial stuff works great so far despite the errors.  I don't have cables
for the handhelds yet and am loath to purchase them if they may be easily
built.

Any data/pointers will be appreciated.

I hope to help out on the project (Linux side only).  My aim is to build a
backup restore function for the above radios.  The radio shack is very
much a pain to program, so I want the backup to be and editable text file.

We'll see how it goes.  I'm not well known for being able to complete one
project before another captures my interest (like my "Poor Man's Spectrum
analyzer" from Science Workshop).

My e-mail sometimes goes a week or so without getting checked so don't
be concerned if you don't get an instant response.  I get very little
e-mail and generally like to keep it that way.   :)

Thank you for making hamlib available.

73's

Dale E. Edmons
KD7ENi



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

Re: [Hamlib-developer] hamlib and TS870

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

On Sun, Dec 09, 2001, Joop Stakenborg wrote:
> aba@pc3:~$ rigctl -vvvvv -m 210 
> TX 3 bytes
> 0000	 46 52 3b	FR;
> RX 1 bytes
> 0000	 d2	.
> RX 1 bytes
> 0000	 fb	.
> fread_block: timedout after 0 chars
> Opened rig model 210, 'TS-870S'
> 

FR; command should retrieve current VFO (kenwood/kenwood.c:kenwood_get_vfo)
However, the kenwood protocol does not use 8 bits characters, which
is rather suspect. Anyway, it seems to receive something since it tries
to reply (certainly an error code, but with wrong speed?).

> I have tried to talk to my transceiver with minicom, but I never get
> anything back, whatever communication parameter I try.

Maybe trying with some other known-to-work CAT program would help.
Easy to find under DOS/win32, not so easy under Linux...

> >From the tests I get the impression that serial line speeds do not match
> the communication paramaters of the transceiver.
> is this correct?

This could be the most reasonable explanation. Have you tried playing
with speed/handshake/parity/number of data and stop bits/ etc. ?
Reading kenwood/ts870s.c, it looks like Hamlib is setting up the serial
port to 57600bps, 8N1, no parity.
Maybe the TS-870 cannot cope with too high speed?

Note: whatever speed value you setup the port, Hamlib reconfigures it.
So the TS-870 should be setup to 57600bps.

> Maybe I should give kontakt a try.....

I'm afraid you won't have more luck since kontakt is based on Hamlib.
However, I'm almost sure Robert would be happy to have some feedback
on his development.

Please, let me know if the speed setup can help in solving your problem.

73, 
Stephane F8CFE

Re: [Hamlib-developer] hamlib and TS870

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

On Sun, 9 Dec 2001 14:58:55 +0100
Stephane Fillod <f4...@fr...> wrote:

> On Sun, Dec 09, 2001, Joop Stakenborg wrote:
> 
> Can you run rigctl with "-vvvvv" option and report the traces please?
> This will tell us what's Hamlib is doing, and what characters are
> exchanged on the serial line. 
> 

aba@pc3:~$ rigctl -vvvvv -m 210 
rig:rig_init called 
rig: loading backend kenwood
kenwood: _init called
rig_register (203)
rig_register (204)
rig_register (216)
rig_register (210)
rig:rig_open called 
TX 3 bytes
0000	 46 52 3b	FR;
RX 1 bytes
0000	 d2	.
RX 1 bytes
0000	 fb	.
fread_block: timedout after 0 chars
Opened rig model 210, 'TS-870S'

Rig command: f
TX 3 bytes
0000	 46 52 3b	FR;
RX 1 bytes
0000	 d3	.
RX 1 bytes
0000	 fb	.
fread_block: timedout after 0 chars
Frequency: 4611874313014867991get_freq: error = Communication timed out

Rig command: F 14.000
TX 3 bytes
0000	 46 52 3b	FR;
Frequency: RX 1 bytes
0000	 92	.
RX 1 bytes
0000	 fb	.
fread_block: timedout after 0 chars
set_freq: error = Communication timed out

Rig command: q
rig:rig_close called 
rig:rig_cleanup called 
aba@pc3:~$


> Eventually, if you suspect a problem with the serial cable, you may try to
> talk directly to the rig with minicom, and issue simple commands like 
> 'ID'.
> 

The serial line is OK, I have tested it with a modem. It is a 9 wire
cable to a 9 pin connector at both ends.
I have tried to talk to my transceiver with minicom, but I never get
anything back, whatever communication parameter I try.
From the tests I get the impression that serial line speeds do not match
the communication paramaters of the transceiver.
is this correct?

Maybe I should give kontakt a try.....

Joop

Re: [Hamlib-developer] hamlib and TS870

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

On Sun, Dec 09, 2001, Joop Stakenborg wrote:
> Hello Stephane and others,
> 

Hi Joop,

> I have tried to use rigctl with my TS-870. According to the menu on
> the TS-870, communication is set to 9600 bps with 1 stopbit. I have
> tried with the default com-port settings on my linux-box and with
> 'setserial /dev/ttyS0 baud_base 9600'. Both with the same results:
> 
> aba@pc3:~$ rigctl -m 210
> fread_block: timedout after 0 chars
> 

Can you run rigctl with "-vvvvv" option and report the traces please?
This will tell us what's Hamlib is doing, and what characters are
exchanged on the serial line. 

Eventually, if you suspect a problem with the serial cable, you may try to
talk directly to the rig with minicom, and issue simple commands like 
'ID'.

> [ctrl led on the rig switches on]
> 
This is a goood sign anyway.

> Do I need to dive into the source code? Did I overlook something?

Not necessarily. This is just this backend has never been tested :-)

Cheers,

Stephane F8CFE

[Hamlib-developer] hamlib and TS870

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

Hello Stephane and others,

I have tried to use rigctl with my TS-870. According to the menu on
the TS-870, communication is set to 9600 bps with 1 stopbit. I have
tried with the default com-port settings on my linux-box and with
'setserial /dev/ttyS0 baud_base 9600'. Both with the same results:

aba@pc3:~$ rigctl -m 210
fread_block: timedout after 0 chars

[ctrl led on the rig switches on]

Rig command: f
fread_block: timedout after 0 chars
Frequency: 4611874313014867991get_freq: error = Communication timed out

Rig command: F 14.023
Frequency: fread_block: timedout after 0 chars
set_freq: error = Communication timed out

Rig command: q
aba@pc3:~$


Do I need to dive into the source code? Did I overlook something?
Thanks,

Joop PA4TU

Re: [Hamlib-developer] How to link in binary

[<rs...@su...>]

On Wed, 28 Nov 2001, Stephane Fillod wrote:

> Let's consider the IC-275/475 are now supported... well yet to be tested!

Whoa, that was fast. Now I have to find out what hardware I need for the
interface.

> Any taker for the FT990?

After I've had a look why the FT847 get_* stuff doesn't work here, I might
as well get into the rest ;-) But no promise yet. I'll have to check for
the interface, too.

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

Re: [Hamlib-developer] How to link in binary

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

On Tue, Nov 27, 2001, Robert Steinhäußer wrote:
> Also, I don't have an FT-847 at home, and the IC-275/475 and FT990 aren't
> supported yet. But we'll manage that ;-)

Let's consider the IC-275/475 are now supported... well yet to be tested!
Any taker for the FT990?

73 de Stephane

Re: [Hamlib-developer] How to link in binary

[John R. <js...@ho...>]

Stephane,

Thanks! That worked.

I did a configure with --prefix as you suggested, then a make install.

I shouldn't have been trying to avoid doing that.

John

rm -f testrig testrig.o

export HAMLIB=/usr/local/hamlib/
export LD_LIBRARY_PATH=${HAMLIB}/lib:.

gcc -DHAVE_CONFIG_H -I${HAMLIB}/include -D_GNU_SOURCE -g -O2 -Wall -c 
testrig.c
gcc -g -O2 -Wall -o testrig testrig.o -L${HAMLIB}/lib -lhamlib

./testrig


>From: Stephane Fillod <f4...@fr...>
>To: Ham...@li...
>Subject: Re: [Hamlib-developer] How to link in binary
>Date: Tue, 27 Nov 2001 19:12:27 +0100 (MET)
>
>John Roberts wrote:
> >
> > Here is the script I'm using to compile:
> >
> > rm -f testrig testrig.o
> >
> > export HAMLIB=../hamlib-1.1.2/
> > export LD_LIBRARY_PATH=${HAMLIB}/.libs/:${HAMLIB}/icom/.libs:.
> >
> > gcc -DHAVE_CONFIG_H -I${HAMLIB}/tests -I${HAMLIB}/include 
>-I${HAMLIB}/src
> > -D_GNU_SOURCE  -g -O2 -Wall -c testrig.c
> > gcc -g -O2 -Wall -o testrig testrig.o -L${HAMLIB}/src -lhamlib
>                                         ^^^^^^^^^^^^^^^^
>If you're not using hamlib-devel RPM, then use "-L${HAMLIB}/.libs"
>instead of -L${HAMLIB}/src. This is what libtool would do for rigctl.
>
>Anyway, I strongly recommends using the hamlib-devel RPM in your case,
>unless you want to help in bleeding edge Hamlib development. Nevertheless,
>with the cvs version, it's still better to configure hamlib with
>--prefix=/usr/local or whatever (and set -L/usr/local/lib accordingly)
>and then "make install".
>
>Let me know how it goes. If bands are still open, we can have a sked.
>
>73, Stephane
>
>_______________________________________________
>Hamlib-developer mailing list
>Ham...@li...
>https://lists.sourceforge.net/lists/listinfo/hamlib-developer


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: [Hamlib-developer] How to link in binary

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

John Roberts wrote:
>
> Here is the script I'm using to compile:
> 
> rm -f testrig testrig.o
> 
> export HAMLIB=../hamlib-1.1.2/
> export LD_LIBRARY_PATH=${HAMLIB}/.libs/:${HAMLIB}/icom/.libs:.
> 
> gcc -DHAVE_CONFIG_H -I${HAMLIB}/tests -I${HAMLIB}/include -I${HAMLIB}/src  
> -D_GNU_SOURCE  -g -O2 -Wall -c testrig.c
> gcc -g -O2 -Wall -o testrig testrig.o -L${HAMLIB}/src -lhamlib
                                        ^^^^^^^^^^^^^^^^
If you're not using hamlib-devel RPM, then use "-L${HAMLIB}/.libs"
instead of -L${HAMLIB}/src. This is what libtool would do for rigctl.

Anyway, I strongly recommends using the hamlib-devel RPM in your case,
unless you want to help in bleeding edge Hamlib development. Nevertheless,
with the cvs version, it's still better to configure hamlib with 
--prefix=/usr/local or whatever (and set -L/usr/local/lib accordingly) 
and then "make install".

Let me know how it goes. If bands are still open, we can have a sked.

73, Stephane