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)