hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] Re: RIG_SCAN_RESUME_ON/OFF

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

On Sat, Mar 02, 2002, Francois Retief wrote:
> > 
> > Francois, don't you think it should be RIG_FUNC_RESUME instead ?
> > 
> 
> I am not sure. The routine that uses this constant is rig_scan(..)
> But this routine has no extra variable to switch on/off the resume
> function.  That is why I added the constants as it is above.
> 
> Maybe we should change it to a function, ie. RIG_FUNC_SCAN_RESUME.
> Then we can use rig_set_func(..) to enable/disable the scan resume
> function.

RIG_FUNC_SCAN_RESUME or RIG_FUNC_RESUME is fine with me.

> Quote from the manual:
> 
>   "Scan resume ON/OFF
>   You can select the scan to resume or cancel when re-
>   ceiving a signal, in the scan set mode. Scan resume
>   ON/OFF must be set before operating a scan."
> 
> What do you think?

I'm asking myself the following question: Is it a setting or is it an
action? If it's a setting, then it should be set through rig_set_func.
If it's an action, it pertains to rig_scan.

So I think rig_set_func/rig_get_func looks more appropriate.


Cheers,
 Stephane

Re: [Hamlib-developer] Icom R7000 report

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

On Sat, Mar 02, 2002, Chuck Hemker wrote:
> First, I wish to apologize.  My friend has an Icom 970, not a 910.  If someone
> would be kind enough to create an entry for a 970, I'll happily test it when I
> get over there.

done. However, I'm not sure about what feature this rig has. To be tested.

> Just think of it as being nice to the future users of the 910.  :)

Sure, and Francois will use it I guess.

> Now for the Icom R-7000:
> 
> > Chuck, could you confirm this is 0x08 for the R-7000?
> 
> Yes it is.

good.

> other people.  If you want any help implementing any of this let me know.  I'm
> getting better at my understanding the internals to hamlib and I could probably
> figure out how to do a bunch of this.

The internal of Hamlib are not very well documented to say the least. We
try to use common sense, so it's self documented :)  However, feel
free to ask questions, it sometimes help showing off errors in API design,
etc.

> 2. The default for the speed of the CI-V bus seems wrong.  The hamlib default
>    serial speed is the max speed of the radio.  According to the CI-V docs
>    that I have, the factory default serial speed for CI-V is 1200 bps.  My
>    radio also happens to be 1200.  I'll try to find out if it is settable and if
>    so to what values.

okay, fixed. Let me know if it can be set higher.

>    What I'm wondering is if there should be some sort of default speed for a
>    radio which could be set to the factory default rather then defaulting to
>    the max speed.  Or maybe this should just be rolled into the future
>    preferences file mentioned in the TODO file.

yep. The min and max are there to check bounds. The preference file should
be pretty easy to implement, but I reserve that for 1.1.4.

>    Because of this, I couldn't run either testtrn or dumpmem to test them.

testtrn and dumpmem are developer's limited test programs. rigctl can dump
a single channel using 'h' aka get_channel command. And maybe I should add
support for trn in rigctl. Good idea (not done yet).

> 3. With tranceive enabled on the radio, rigctl gets confused if you do things on
>    the front panel of the radio.  This is because the radio sends things and the
>    input buffer isn't flushed or processed before the responses from the
>    commands are looked for.  I ended up quiting and restarting rigctl most of
>    the times I touched the radio.

A serial_flush was missing in icom_transaction. This is fixed.

> 5. In looking through riglist.h the other day, I noticed that a couple of the
>    Icom radios and the Optoelectronics had duplicate numbers.  This is
>    probably because the Optoelectronics rigs are also CI-V controlled and
>    someone added Icom rigs without noticing that the numbers were being used:

Ouch, darn copy-paste. fixed.

> 6. When installing the CVS version the other day after configuring it with a
>    --prefix, I noticed that it tried to install some of the perl files in
>    /usr/lib/perl5/...  Not knowing the perl directory structure, I don't know if
>    this is a feature or a bug.  
>    Work around: ./configure --without-perl-binding

Yeah, I know. There're currently 2 problems left to be fixed for the perl
binding. First one is install somewhere else than default location.
Second is support for VPATH. I'll try to come out with something.
In the mean time, --without-perl-binding is your friend.


> Now some testing with rigctl:
> 
> 
> set and get frequency 25-999 MHz: good
> Note: it ignores the last 2 digits on set and returns 00 on get

yep, this is the expect behaviour: truncating.

> ---
> 
> set and get frequency 1025-1999 MHz: not quite right
> Note: there is a separate 1ghz switch on the front panel.  When it's on, a
> "1GHz" lights up in the display and the radio tunes 1025-1999.9999. It looks
> like the computer interface doesn't know it exists. It always returns 0 in the
> ghz digit on get and errors if the ghz digit is 1 on set.  I don't know if
> hamlib should care.  Since I'm already supporting downconverters in my software
> for 2.4 GHz I'll probably implement it as a manually controlled downconverter
> that happens to be installed in the radio.  The only thing I could see hamlib
> MIGHT want to do is to mask out the 1ghz digit so the program could ask for 1234
> MHz and hamlib sends 234 MHz to the radio.  And leave it up to the user to push
> the button. 

I like the idea. Will do that for set_freq in the coming days.
However, the get_freq won't have any clue to whichever position the switch
is set.

> ---
> 
> Checking getting modes:
> This radio is a bit weird in that rather than computer controllable USB and
> LSB, it has a computer controllable "SSB" mode.  In the US version there is a
> mechanical USB/LSB switch on the back of the radio.  I believe the international
> version is USB only.  (I guess they assumed very few people use LSB above 25
> MHz.)
> 
> It reports the SSB mode as 0500.  Not to be confused with FM(wide) 05 (and maybe
> 0501), and FMnarrow 0502.
> 
> Not sure how much special case code you want for the r7000 because it's
> different from every other icom rig.

This could be implemented as r7000_[sg]et_mode in icom/icr7000.c
But it turns out it's simpler as workaround in frame.c, because the
IC-R7000 seems to be the only exception.

> If you do want to have special code for the R7000, but don't want to create a
> separate "SSB" mode, get_mode could return USB, and set for either USB or LSB
> could set the radio to SSB.  And leave it up to the controlling software to care
> if it wants to.

good compromise

> ssb: bad
> 
should be fixed now

> ---
> 
> Checking setting modes:
> Looks like if you set it to what you got with get it works for AM, FM wide, and
> FM
> narrow.  Not sure how it's supposed to work.
> For SSB, I couldn't figure out how to send a 0500.
> 

> Rig command: M
> Mode: FM
> Passband: 02
            ^^
Arg! Passband is the real passband width in Hz!!
i.e. 6kHz for narrow AM on the IC-R7000. You're lucky the code uses <
operator to check narrow or wide :)

> SSB: bad (or at least I couldn't figure out a way)

Let me know if the fix helped a little bit.

> Let try USB/LSB:
> Note: 06 01 and 06 02 do not work on this radio.  See above.

should be fixed now.

> ---
> 
> Tuning steps are not computer controlable (set via a mechanical switch)

okay, removed set_ts/get_ts.

> ---
> 
> Memory:
> There are 99 memories.  

added to caps
 
> It looks like to reading and writing to memories without going through the vfo
> is not supported.
> 
> Selecting a memory (08 xx) is supposed to work.
> 
> It looks like you need to do thing like this:
> To read a memory: select it with 08xx then get_freq.
> To write a memory: select channel with 08xx, set_freq, then write with 09.
> To clear a memory: select channel with 08xx, then clear with 0b.
> (I got this from the ci-v docs.  I havn't tested it yet)

may make sense since there's no MEM->VFO function, and the VFO->MEM looks
suspicious without 07 cmd to select VFO mode.
 
> I'm not sure how many radios do things like this.  Therefore I'm not sure if
> hamlib should support this directly, or through a higher level routine that
> looks at the rig capabilities and does this if need be, or leave it up to the
> user software.

The user software will have to comply with a defined behaviour.
However, every rig should look the same, and memory handling should be
seamless. I'll try to come up with something.

> ---
> 
> Select blank memory from front panel and attempt to get_freq: bad
> Note: CI-V docs say frequency FF is a blank memory.

bug of mine. should be fixed.

> Select memory channel 01: bad
> Note: This radio has 99 memories.  The CI-V docs I have say to select memories
> less than 100, use only 1 byte (two digits).  Should this be 08 01 fd?

No idea. Could this be verified from the rig manual?

> Attempt to read channel 01: bad
> Note: Command 1a not supported by this rig.  Don't know if this should just be
> unavailable or implemented as described above.

oops, the IC-R7000 should use generic get_channel and set_channel.
Let me know if it's better now.

> ---
> 
> Setting Mode to memory: bad
> Docs say it should work.  There is also a M-SET momentary button on the front
> panel that when depressed selects the freq from the current memory channel
> rather
> than the vfo.  When released it switches back.  I'll have to read the manual on
> this one. :)

Dang, this rig is really, ahem, fun?  :)

> Rig command: V
> VFO: MEM
> TX 7 bytes
> 0000     ff fe fe 08 e0 08 fd   .......
> RX 7 bytes
> 0000     ff fe fe 08 e0 08 fd   .......
> RX 6 bytes
> 0000     fe fe e0 08 fa fd      ......
> icom_set_vfo: ack NG (0xfa), len=1
> set_vfo: error = Command rejected by the rig

The "selects MEMORY mode" should work according to the CI-V manual.
I'm wondering if it needs to be in some special condition to work.

> Setting mode to vfo: not supposed to be supported
> Doc's say this isn't supported.
> 
> Rig command: V
> VFO: VFO
> TX 7 bytes
> 0000     ff fe fe 08 e0 07 fd   .......
> RX 7 bytes
> 0000     ff fe fe 08 e0 07 fd   .......
> RX 6 bytes
> 0000     fe fe e0 08 fa fd      ......
> icom_set_vfo: ack NG (0xfa), len=1
> set_vfo: error = Command rejected by the rig

Alright, at least this is what was expectable, even if a pity.

> ---
> 
> I guess there isn't anything to report.
> 
> Rig command: _
> Info: None

right.

> ---
> 
> Dumpcaps:
> A few notes on the right.
> 
> [kmh@swami tests]$ ./dumpcaps 340
> rig: loading backend icom
> icom: _init called
> rig_register (309)
> rig_register (310)
> rig_register (311)
> rig_register (319)
> rig_register (330)
> rig_register (326)
> rig_register (327)
> rig_register (334)
> rig_register (344)
> rig_register (340)
> rig_register (342)
> rig_register (304)
> rig_register (307)
> rig_register (300)
> Rig dump for model 340
> Model name:     ICR-7000
> Mfg name:       Icom
> Backend version:        0.2
> Backend copyright:      LGPL
> Backend status: Untested
> Rig type:       Receiver
> PTT type:       None
> DCD type:       None
> Port type:      RS-232
> Serial speed: 300..19200 bauds, 8N1      I'll have to check the manual for the
>                                          specs.
>                                          Factory default is 1200
> Write delay 0ms, timeout 200ms, 3 retry
> Post Write delay 0ms
> Has targetable VFO: no
> Has transceive: yes
> Announce: 0x0
> Max RIT: -9.999kHz/+9.999kHz             Don't see this, I'll have to check the
>                                          manual in a few days.

forget about it. This was a copy-paste from the icr-8500.

> Max XIT: -0.0kHz/+0.0kHz
> Max IF-SHIFT: -0.0kHz/+0.0kHz
> Preamp: 10dB                             Don't think it has one
> Attenuator: 20dB
> Get functions:                           Don't think it has any functions/levels
> Set functions: FAGC NB TSQL APF 
> Get level: PREAMP ATT SQL APF AGC SQLSTAT STRENGTH 
> Set level: PREAMP ATT SQL APF AGC 

ditto

> Get parameters: 
> Set parameters: 
> Number of banks:        12               Looks like it has 1 bank of 99
>                                          memories.

ditto

> Memory name desc size:  0                
> Memories: none
> TX ranges status, region 1:     OK (0)
> RX ranges status, region 1:     OK (0)
> TX ranges status, region 2:     OK (0)
> RX ranges status, region 2:     OK (0)
> Tuning steps:
>         100Hz:          AM USB LSB FM WFM 
>         1kHz:           AM USB LSB FM WFM 
>         5kHz:           AM USB LSB FM WFM 
>         10kHz:          AM USB LSB FM WFM 
>         12.5kHz:        AM USB LSB FM WFM 
>         25kHz:          AM USB LSB FM WFM 
> Tuning steps status:    OK (0)
> Filters:                                  Have to check on filters
>         2kHz:           USB LSB 
>         15kHz:          AM FM 
>         6kHz:           AM FM 
>         150kHz:         WFM 

got them from the specs:
http://www.icomamerica.com/support/archive/receivers/ic-r7000a.html

> Has priv data:  Y                         Not sure what these are

This is internal stuff of the backend, like 4 chars for freq dat, etc.

> Has init:       Y
> Has cleanup:    Y
> Has open:       N
> Has close:      N
> Can set conf:   Y                         Not sure what these are
> Can get conf:   Y

backend stuff to change the CI-V address when talking to the rig, etc.

> Can set frequency:      Y
> Can get frequency:      Y
> Can set mode:   Y
> Can get mode:   Y
> Can set vfo:    Y                         
> Can get vfo:    N
> Can set ptt:    N
> Can get ptt:    N
> Can get dcd:    N
> Can set repeater duplex:        N
> Can get repeater duplex:        N
> Can set repeater offset:        N
> Can get repeater offset:        N
> Can set split freq:     N
> Can get split freq:     N
> Can set split mode:     N
> Can get split mode:     N
> Can set split:  N
> Can get split:  N
> Can set tuning step:    Y                     Not computer settable
> Can get tuning step:    Y                     Not computer settable

ok, removed.

> Can set RIT:    N
> Can get RIT:    N
> Can set XIT:    N
> Can get XIT:    N
> Can set CTCSS:  N
> Can get CTCSS:  N
> Can set DCS:    N
> Can get DCS:    N
> Can set CTCSS squelch:  N
> Can get CTCSS squelch:  N
> Can set DCS squelch:    N
> Can get DCS squelch:    N
> Can set power stat:     N
> Can get power stat:     N
> Can get reset:  N
> Can get ant:    N
> Can set ant:    N
> Can set transceive:     N
> Can get transceive:     N
> Can set func:   Y                          Don't think it has any
>                                             functions/levels
> Can get func:   N
> Can set level:  Y                          Don't think it has any
>                                             functions/levels
> Can get level:  Y                          Don't think it has any
>                                             functions/levels

ok, removed.

> Can set param:  N
> Can get param:  N
> Can send DTMF:  N
> Can recv DTMF:  N
> Can send Morse: N
> Can decode events:      Y
> Can set bank:   N
> Can set mem:    Y                          
> Can get mem:    N
> Can set channel:        Y                  See notes on memory above
> Can get channel:        Y                  See notes on memory above
> Can ctl mem/vfo:        Y                  See notes on mem/vfo above

removed icr8500 specific set_channel/get_channel. 
mem/vfo can do : RIG_OP_FROM_VFO and RIG_OP_MCL

> Can scan:       N
> Can get info:   N
> 
> Overall backend warnings: 0
> 

Thank you very much Chuck for this high quality testing. Let me know how
the new cvs version works on your rig.

Phew, that was a good report!

cu agn
Stephane F8CFE

[Hamlib-developer] yaesu ft100 support

[A V F. <avf...@at...>]

I uploaded some initial support for the yaesu ft100 earlier today. 

-- 
Alex
KC2IVL
Linux 2.4.18 #1 Tue Feb 26 14:57:18 EST 2002 i686
  5:00pm  up 3 days,  6:28,  2 users,  load average: 1.81, 1.27, 1.09

[Hamlib-developer] IC-718 support, was Re: Hamlib-cvs-digest digest, Vol 1 #283 - 1 msg

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

Hi Chuck,

You've posted to hamlib-cvs, which is merely a mailing list where
only the cvs robot posts check in reports. hamlib-developer is for
human, and we welcome you as well in this list :-)

> Message: 1
> Date: Sun, 03 Mar 2002 18:01:17 -0500
> From: Chuck Gilkes <ch...@we...>
> To: ham...@li...
> Subject: [Hamlib-cvs-digest] Icom:  returned values for rig_get_level
> 
> Hi all,
> I've been tring to include the ic-718 in the library.  I may have
> something to show for my efforts in a week or two.  (just started
> putzing with it this weekend)

Great! Another missing rig that'll be supported and tested!
BTW, what sources are you using for your hacking? Is it
official hamlib-1.1.2 or the latest cvs checkout?

If you'd like to, you can send me your current patch of icom/ic718.c, and
I'll commit that for you. Then, it'll be easier to test and report.

> I've playing around with testrig.c.  When I call rig_get_level(my_rig,
> RIG_VFO_CURR, RIG_LEVEL_RFPOWER, &rfpower), the following is returned:
> 
> 	get_level: 2 64 1048608897 0.250980
> 	rig_get_rfpower: rfpower = 1048608897
> 
> I can ascertain what the value 64 is and the float, but I'm at lost
> concerning the value 2 and 1048608897.

hmmm, you'd better use rigctl for testing your backend, it's much more
flexible. Have you read the README.betatester ? The link is here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hamlib/hamlib/README.betatester?rev=1.1&content-type=text/vnd.viewcvs-markup

The "-vvvvv" option to rigctl will give also CI-V traces, quite helpful.

Concerning your problem, I not sure if RIG_LEVEL_RFPOWER has ever been
tested... Traces needed I would say.

73's
Stephane, F8CFE

PS: I can be QRV right now til 2200 UTC if needed.

[Hamlib-developer] RE: MHz macro problem,

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

On 03-Mar-02 Stephane Fillod wrote:
> Chuck, can you give it a try?  tests/testfreq looks okay

Just checked and testfreq fails here (look at the last 3 entries):

[kmh@wanderer2 tests]$ ./testfreq 
Hamlib version 1.1.3
caps size: 5888
state size: 3596
RIG size: 3640
freq_t size: 8
shortfreq_t size: 4
GHz(2) = 2000000000
GHz(4) = 4000000000
GHz(5) = 5000000000
GHz(1.3) = 1000000000
GHz(1.234567890) = 1000000000
GHz(123.456789012) = 123000000000
[kmh@wanderer2 tests]$ 

---

I Tried:

#define MHz(f)  ((freq_t)((f)*1000000UL))

and it looks like it works here.  

> is things sent to my server
< is responses from my server

[kmh@swami kmh]$ telnet wanderer2 yatrk_radio
Trying 192.168.92.14...
Connected to wanderer2.swamiland.invalid (192.168.92.14).
Escape character is '^]'.

> radio ic-r7000

> set_freq 123.4567890
< radio_freq_set 123.456700
  (this is out of rig_get_freq after the rig_set_freq)
  (radio has a 100hz resolution)

> set_freq 3456.7890
< ERROR: rig_get_freq 'Command rejected by the rig'
  (of course my radio doesn't support that freq)

And the debug output of radio_server on the last command: 

Processing command 3: 'set_freq' '3456.7890'
TX 12 bytes
0000     ff fe fe 08 e0 05 00 90 78 56 34 fd

---

Actually, in testing, I did notice some rounding errors because my radio
truncates the frequency rather than rounding it.  But that probably should
be left up to the user if they want to call it with floating point numbers.

With my software, I've been dealing with the rounding errors myself in the
controlling software.  With the r7000 that has a 100hz resolution, I've been
adding 50hz when I set the freq, and checking to see if the error is greater
than 51hz before I do an update.  (to keep down the number of updates)

---

On 03-Mar-02 Stephane Fillod wrote:
> Actually, I've made the change because the macro GHz
> would not work with freq > 2GHz (problem with 31bit representation).

I guess everyone who is dealing with frequencies greater than 4 GHz is
probably using a down converter anyways so I guess you don't need support for
more than 4 GHz now.  I added support for down converters in my software since
AO-40's downlink is on 2.4 GHz, most people are down converting it before
sending it to the receiver.  Then I've just been calling hamlib with the
frequency for the radio.

I don't know if doing something like this would make it easier to change
freq_t later if it's needed.  I also don't remember my C rules on types and
constants (a very quick test looks like it works):

#define MHz(f)  ((freq_t)((f)*(freq_t)1000000))

---

> Just curious, I see socket args in your function. What the socket is used
> for? Is it some specific stuff in your application, or have you
> reimplemented the RPCrig ?

First, I didn't look that closely at RPCrig.
Second, my package is set up using several daemons and client programs all
talking to each other over network sockets.  When I originally designed my
radio_server, it was going to do the doppler correction itself.  That way
it could get called from several different clients (a GUI client for a human
to use, possibly a curses client, and other daemons to do automatic talking
to pacsats and to get telemetry beacons).  However, when I started implementing
it I realized that the code was going to be fairly complicated and/or messy, so
right now my GUI client (which had to do the doppler calcs anyways to display
them to the user) is currently doing most of the work and talking to a fairly
simple radio_server.
I have noticed some delays though in what I'm doing, so I may try to implement
the doppler correction in the radio_server soon anyways.

My current radio_server commands:
(This is very preliminary)

radio ic-r7000:
 reads from hardware.db file for the radio type, serial speed, ... and
 opens the radio.

get_freq
 calls rig_get_freq to get the freq

set_freq 123.456
 calls rig_set_freq to set the freq, then calls rig_get_freq to send back the
 what the freq really is.

update_freq 123.456 456.789
 does a rig_get_freq to see if the current freq is 456.789.  
 If not, sends a radio_freq_event with the current_freq
 If it is, it sets the freq like set_freq
 (this is to make sure I don't miss someone turning the dial)
 (either the tranceive packet hasn't made in yet, or the radio doesn't support
  tranceive and it hasn't polled it to check for changes yet)

And the tranceive frequency update callback sends a "radio_freq_event 123.456"
every time it gets called.

MHz macro problem, was Re: [Hamlib-developer] RE: [Hamlib-cvs-digest] CVS: hamlib/include/hamlib rig.h,1.59,1.

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

On Sat, Mar 02, 2002, Chuck Hemker wrote:
> Am I supposed to be using the MHz macro?  This change broke my code:

Yes, MHz is for use by applications. Obviously, my change broke something.

> On 27-Feb-02 Stephane Fillod wrote:
> > diff -C2 -r1.59 -r1.60
> > *** rig.h     27 Jan 2002 23:46:01 -0000      1.59
> > --- rig.h     27 Feb 2002 23:22:31 -0000      1.60
> > ***************
> > *** 211,217 ****
> >   
> >   #define Hz(f)       ((freq_t)(f))
> > ! #define kHz(f)      ((freq_t)((f)*1000))
> > ! #define MHz(f)      ((freq_t)((f)*1000000L))
> > ! #define GHz(f)      ((freq_t)((f)*1000000000LL))
> >   
> >   #define RIG_FREQ_NONE Hz(0)
> > --- 211,217 ----
> >   
> >   #define Hz(f)       ((freq_t)(f))
> > ! #define kHz(f)      (((freq_t)(f))*1000UL)
> > ! #define MHz(f)      (((freq_t)(f))*1000000UL)
> > ! #define GHz(f)      (((freq_t)(f))*1000000000UL)
> >   
> >   #define RIG_FREQ_NONE Hz(0)
> 
> It forces the frequency to a freq_t before it does the muliplication.  Because
> I was calling it with a double, I lost the digits after the decimal point.

Oops, a lot of backend must have been broken by the change (anything like
MHz(10.150) etc.). Actually, I've made the change because the macro GHz
would not work with freq > 2GHz (problem with 31bit representation).
Here is a possible fix:

	#define Hz(f)   ((freq_t)(f))
	#define kHz(f)  ((freq_t)((f)*1000UL))
	#define MHz(f)  ((freq_t)((f)*1000000UL))
	#define GHz(f)  ((freq_t)((f)*1000000000UL))

Now, thanks to the UL (unsigned), this would push the new limit to 4GHz 
(2^32). Or maybe the following is even better:

        #define Hz(f)   ((freq_t)(f))
        #define kHz(f)  ((freq_t)(1000ULL*(f)))
        #define MHz(f)  ((freq_t)(1000000ULL*(f)))
        #define GHz(f)  ((freq_t)(1000000000ULL*(f)))

Chuck, can you give it a try?  tests/testfreq looks okay.

> If I'm not supposed be using it let me know.  I just figured it was handy.

And it *was* meant to handy, not flawed. hi. 

> Relevent parts of my code:
> 
> void command_set_freq(int xkey,struct socket_list_struct *psocket_list,struct
> socket_line_struct *psockline,struct radio_connection_struct
> *pradio_connection,char *prest)
> {
>   int x;
>   double freq;
> 
> ...
> 
>   freq = atof(prest);
> 
>   x = rig_set_freq(pradio_connection->rig,RIG_VFO_CURR,MHz(freq));

Just curious, I see socket args in your function. What the socket is used
for? Is it some specific stuff in your application, or have you
reimplemented the RPCrig ?


Cheers,
 Stephane F8CFE

[Hamlib-developer] Info for Kenwood ts-440 & tmd-700

[Brett S. <ug...@ih...>]

Hi
 I have devolped code for controling many radios by my repeater controller.

Radios tested are:
Alinco DX-77, Kenwood TS-440 ( and others ), Kenwood TMD-700(A/E), Tait
T20xx radios in CTMM & ICOM CI-V, both 4 & 5 byte frequency data.

All the code is written in C for the 68HC11 single chip micro and also for
the PIC16F84 & 805x chips.

Something I have worked on is a single chip "universal" interafce that has
RS-232 to the PC with ASCII based commands translated to the appropriate
radio.

If any of this is usefull let me know.
Live long and prosper.
Brett.
ug...@ih...
ICQ: 2671341
http://welcome.to/zl1ux

[Hamlib-developer] Re: RIG_SCAN_RESUME_ON/OFF

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

Hello Stephane,

Stephane Fillod wrote:
> 
> On Thu, Feb 28, 2002, ham...@li... wrote:
> >
> >    1. CVS: hamlib/include/hamlib rig.h,1.60,1.61 (Francois Retief)
> 
> [...]
> 
> > ***************
> > *** 360,363 ****
> > --- 360,365 ----
> >   #define RIG_SCAN_PROG       (1L<<3)         /* Programmed(edge) scan */
> >   #define RIG_SCAN_DELTA      (1L<<4)         /* delta-f scan */
> > + #define RIG_SCAN_RESUME_ON  (1L<<5) /* Scan resume ON (IC-910H) */
> > + #define RIG_SCAN_RESUME_OFF (1L<<6) /* Scan resume OFF (IC-910H) */
> >
> 
> Francois, don't you think it should be RIG_FUNC_RESUME instead ?
> 

I am not sure. The routine that uses this constant is rig_scan(..)
But this routine has no extra variable to switch on/off the resume
function.  That is why I added the constants as it is above.

Maybe we should change it to a function, ie. RIG_FUNC_SCAN_RESUME.
Then we can use rig_set_func(..) to enable/disable the scan resume
function.

Quote from the manual:

  "Scan resume ON/OFF
  You can select the scan to resume or cancel when re-
  ceiving a signal, in the scan set mode. Scan resume
  ON/OFF must be set before operating a scan."

What do you think?

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

[Hamlib-developer] Icom R7000 report

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

Thanks for creating the entries for the Icom R7000, 910, and the AOR 5000.

First, I wish to apologize.  My friend has an Icom 970, not a 910.  If someone
would be kind enough to create an entry for a 970, I'll happily test it when I
get over there.

Just think of it as being nice to the future users of the 910.  :)

Now for the Icom R-7000:

On 27-Feb-02 Stephane Fillod wrote:
>> Now to set the CIV address to 0x42, issue:   
>>      rig_set_conf(rig, TOK_CIVADDR, 0x42);
> 
> Chuck, could you confirm this is 0x08 for the R-7000?

Yes it is.
 
> In order to ease Hamlib hacking, there are some guidelines to test the cvs
> version, available at the following URL:

You said you wanted beta testers.  Here it is. :)

I did some testing of the Icom r7000.  I have a few notes, then some stuff out
of rigctl, and a then a dumpcaps with some notes.  Hopefully I havn't
overloaded you with too much information.

Feel free to let me know if you have any questions, comments, things you want
me to check or anything else.  Also, I don't mean to cause alot of work for
other people.  If you want any help implementing any of this let me know.  I'm
getting better at my understanding the internals to hamlib and I could probably
figure out how to do a bunch of this.

---

A few things to start with:

1. This is an early computer controlled rig so many of the features of the radio
   are set using mechanical switches and are not computer controllable.  This
   makes it a bit strange.  And it's also a bit different from the other
   Icom rigs.  This probably makes this report a lot longer then it would be for
   most radios.  There are also several things in here that I've noted, but I'm
   not sure that hamlib should care about.  
   Just figured I'd warn you.  :)

2. The default for the speed of the CI-V bus seems wrong.  The hamlib default
   serial speed is the max speed of the radio.  According to the CI-V docs
   that I have, the factory default serial speed for CI-V is 1200 bps.  My
   radio also happens to be 1200.  I'll try to find out if it is settable and if
   so to what values.
   What I'm wondering is if there should be some sort of default speed for a
   radio which could be set to the factory default rather then defaulting to
   the max speed.  Or maybe this should just be rolled into the future
   preferences file mentioned in the TODO file.
   Because of this, I couldn't run either testtrn or dumpmem to test them.

3. With tranceive enabled on the radio, rigctl gets confused if you do things on
   the front panel of the radio.  This is because the radio sends things and the
   input buffer isn't flushed or processed before the responses from the
   commands are looked for.  I ended up quiting and restarting rigctl most of
   the times I touched the radio.

4. I currently don't have a copy of the owners and/or service manual for this
   radio.  I should be able to get a copy of the owners manual in a few days.
   That will hopefully answer some of my questions about a few things.  For the
   CI-V items (which aren't in the owners manual anyways) I've been using the
   pdf file I mentioned the other day.

5. In looking through riglist.h the other day, I noticed that a couple of the
   Icom radios and the Optoelectronics had duplicate numbers.  This is
   probably because the Optoelectronics rigs are also CI-V controlled and
   someone added Icom rigs without noticing that the numbers were being used:

   #define RIG_MODEL_IC910 RIG_MAKE_MODEL(RIG_ICOM, 44)
   #define RIG_MODEL_ICR78 RIG_MAKE_MODEL(RIG_ICOM, 45)
           /*
            * Optoelectronics (CI-V)
            */
   #define RIG_MODEL_MINISCOUT RIG_MAKE_MODEL(RIG_ICOM, 44)
   #define RIG_MODEL_XPLORER RIG_MAKE_MODEL(RIG_ICOM, 45)

6. When installing the CVS version the other day after configuring it with a
   --prefix, I noticed that it tried to install some of the perl files in
   /usr/lib/perl5/...  Not knowing the perl directory structure, I don't know if
   this is a feature or a bug.  
   Work around: ./configure --without-perl-binding

   This is out of "make install" with prefix set to /opt/hamlib, installing as
   myself rather than root.  (Sorry about the line wraps.  Hopefully you can
   understand it.)

   Warning: You do not have permissions to install into
          /usr/lib/perl5/site_perl/5.6.0/i386-linux at
          /usr/lib/perl5/5.6.0/ExtUtils/Install.pm line 62.
   mkdir /usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Hamlib: Permission
          denied at /usr/lib/perl5/5.6.0/ExtUtils/Install.pm line 112
   make[2]: *** [pure_site_install] Error 255
   make[2]: Leaving directory `/export/swami/kmh/hamlib/cvs/hamlib/perl/Hamlib'

--------------

Now some testing with rigctl:


set and get frequency 25-999 MHz: good
Note: it ignores the last 2 digits on set and returns 00 on get

Rig command: F
Frequency: 123456789
TX 12 bytes
0000     ff fe fe 08 e0 05 89 67 45 23 01 fd    .......gE#..
RX 12 bytes
0000     ff fe fe 08 e0 05 89 67 45 23 01 fd    .......gE#..
RX 6 bytes
0000     fe fe e0 08 fb fd      ......

Rig command: f
TX 7 bytes
0000     ff fe fe 08 e0 03 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 03 fd   .......
RX 6 bytes
0000     fe fe e0 08 03 00      ......
RX 1 bytes
0000     67     g
RX 1 bytes
0000     45     E
RX 1 bytes
0000     23     #
RX 1 bytes
0000     01     .
RX 1 bytes
0000     fd     .
Frequency: 123456700

---

set and get frequency 1025-1999 MHz: not quite right
Note: there is a separate 1ghz switch on the front panel.  When it's on, a
"1GHz" lights up in the display and the radio tunes 1025-1999.9999. It looks
like the computer interface doesn't know it exists. It always returns 0 in the
ghz digit on get and errors if the ghz digit is 1 on set.  I don't know if
hamlib should care.  Since I'm already supporting downconverters in my software
for 2.4 GHz I'll probably implement it as a manually controlled downconverter
that happens to be installed in the radio.  The only thing I could see hamlib
MIGHT want to do is to mask out the 1ghz digit so the program could ask for 1234
MHz and hamlib sends 234 MHz to the radio.  And leave it up to the user to push
the button. 

With 1ghz switch on:

Rig command: F
Frequency: 1123456789
TX 12 bytes
0000     ff fe fe 08 e0 05 89 67 45 23 11 fd    .......gE#..
RX 12 bytes
0000     ff fe fe 08 e0 05 89 67 45 23 11 fd    .......gE#..
RX 6 bytes
0000     fe fe e0 08 fa fd      ......
icom_set_freq: ack NG (0xfa), len=1
set_freq: error = Command rejected by the rig

Rig command: F
Frequency: 123456789
TX 12 bytes
0000     ff fe fe 08 e0 05 89 67 45 23 01 fd    .......gE#..
RX 12 bytes
0000     ff fe fe 08 e0 05 89 67 45 23 01 fd    .......gE#..
RX 6 bytes
0000     fe fe e0 08 fb fd      ......

Rig command: f
TX 7 bytes
0000     ff fe fe 08 e0 03 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 03 fd   .......
RX 6 bytes
0000     fe fe e0 08 03 00      ......
RX 1 bytes
0000     67     g
RX 1 bytes
0000     45     E
RX 1 bytes
0000     23     #
RX 1 bytes
0000     01     .
RX 1 bytes
0000     fd     .
Frequency: 123456700

---

Checking getting modes:
This radio is a bit weird in that rather than computer controllable USB and
LSB, it has a computer controllable "SSB" mode.  In the US version there is a
mechanical USB/LSB switch on the back of the radio.  I believe the international
version is USB only.  (I guess they assumed very few people use LSB above 25
MHz.)

It reports the SSB mode as 0500.  Not to be confused with FM(wide) 05 (and maybe
0501), and FMnarrow 0502.

Not sure how much special case code you want for the r7000 because it's
different from every other icom rig.

If you do want to have special code for the R7000, but don't want to create a
separate "SSB" mode, get_mode could return USB, and set for either USB or LSB
could set the radio to SSB.  And leave it up to the controlling software to care
if it wants to.

(there is also a mechanical switch on the back that switches both FM modes to
 even wider.  That should probably be ignored)

AM: good

Rig command: m
TX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 6 bytes
0000     fe fe e0 08 04 02      ......
RX 1 bytes
0000     fd     .
Mode: AM
Passband: 6000

FM: (FM wide) good

Rig command: m
TX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 6 bytes
0000     fe fe e0 08 04 05      ......
RX 1 bytes
0000     fd     .
Mode: FM
Passband: 6000

FMn: (FM narrow) good

Rig command: m
TX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 6 bytes
0000     fe fe e0 08 04 05      ......
RX 1 bytes
0000     02     .
RX 1 bytes
0000     fd     .
Mode: FM
Passband: 0

ssb: bad

Rig command: m
TX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 6 bytes
0000     fe fe e0 08 04 05      ......
RX 1 bytes
0000     00     .
RX 1 bytes
0000     fd     .
Mode: FM
Passband: 6000

---

Checking setting modes:
Looks like if you set it to what you got with get it works for AM, FM wide, and
FM
narrow.  Not sure how it's supposed to work.
For SSB, I couldn't figure out how to send a 0500.

AM: good

Rig command: M
Mode: AM
Passband: 0
TX 8 bytes
0000     ff fe fe 08 e0 06 02 fd        ........
RX 8 bytes
0000     ff fe fe 08 e0 06 02 fd        ........
RX 6 bytes
0000     fe fe e0 08 fb fd      ......

Rig command: m
TX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 6 bytes
0000     fe fe e0 08 04 02      ......
RX 1 bytes
0000     fd     .
Mode: AM
Passband: 6000

FM wide: good

Rig command: M
Mode: FM
Passband: 0
TX 8 bytes
0000     ff fe fe 08 e0 06 05 fd        ........
RX 8 bytes
0000     ff fe fe 08 e0 06 05 fd        ........
RX 6 bytes
0000     fe fe e0 08 fb fd      ......

Rig command: m
TX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 6 bytes
0000     fe fe e0 08 04 05      ......
RX 1 bytes
0000     fd     .
Mode: FM
Passband: 6000

FM narrow: good

Rig command: M
Mode: FM
Passband: 02
TX 9 bytes
0000     ff fe fe 08 e0 06 05 02 fd     .........
RX 9 bytes
0000     ff fe fe 08 e0 06 05 02 fd     .........
RX 6 bytes
0000     fe fe e0 08 fb fd      ......

Rig command: m
TX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 6 bytes
0000     fe fe e0 08 04 05      ......
RX 1 bytes
0000     02     .
RX 1 bytes
0000     fd     .
Mode: FM
Passband: 0

SSB: bad (or at least I couldn't figure out a way)

Rig command: M
Mode: FM
Passband: 00
TX 8 bytes
0000     ff fe fe 08 e0 06 05 fd        ........
RX 8 bytes
0000     ff fe fe 08 e0 06 05 fd        ........
RX 6 bytes
0000     fe fe e0 08 fb fd      ......

Radio was set to FM wide rather than SSB.

Rig command: m
TX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 04 fd   .......
RX 6 bytes
0000     fe fe e0 08 04 05      ......
RX 1 bytes
0000     fd     .
Mode: FM
Passband: 6000

Let try USB/LSB:
Note: 06 01 and 06 02 do not work on this radio.  See above.

Rig command: M
Mode: USB
Passband: 
0
TX 8 bytes
0000     ff fe fe 08 e0 06 01 fd        ........
RX 8 bytes
0000     ff fe fe 08 e0 06 01 fd        ........
RX 6 bytes
0000     fe fe e0 08 fa fd      ......
icom_set_mode: ack NG (0xfa), len=1
set_mode: error = Command rejected by the rig

Rig command: M
Mode: LSB
Passband: 0
TX 8 bytes
0000     ff fe fe 08 e0 06 00 fd        ........
RX 8 bytes
0000     ff fe fe 08 e0 06 00 fd        ........
RX 6 bytes
0000     fe fe e0 08 fa fd      ......
icom_set_mode: ack NG (0xfa), len=1
set_mode: error = Command rejected by the rig

---

Tuning steps are not computer controlable (set via a mechanical switch)

Rig command: n
TX 7 bytes
0000     ff fe fe 08 e0 10 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 10 fd   .......
RX 6 bytes
0000     fe fe e0 08 fa fd      ......
icom_get_ts: wrong frame len=0
get_ts: error = Command rejected by the rig

---

Memory:
There are 99 memories.  

It looks like to reading and writing to memories without going through the vfo
is not supported.

Selecting a memory (08 xx) is supposed to work.

It looks like you need to do thing like this:
To read a memory: select it with 08xx then get_freq.
To write a memory: select channel with 08xx, set_freq, then write with 09.
To clear a memory: select channel with 08xx, then clear with 0b.
(I got this from the ci-v docs.  I havn't tested it yet)

I'm not sure how many radios do things like this.  Therefore I'm not sure if
hamlib should support this directly, or through a higher level routine that
looks at the rig capabilities and does this if need be, or leave it up to the
user software.

---

Select blank memory from front panel and attempt to get_freq: bad
Note: CI-V docs say frequency FF is a blank memory.

Rig command: f
TX 7 bytes
0000     ff fe fe 08 e0 03 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 03 fd   .......
RX 6 bytes
0000     fe fe e0 08 03 ff      ......
RX 1 bytes
0000     fd     .
icom_get_freq: wrong frame len=1
get_freq: error = Command rejected by the rig

Select memory channel 01: bad
Note: This radio has 99 memories.  The CI-V docs I have say to select memories
less than 100, use only 1 byte (two digits).  Should this be 08 01 fd?

Rig command: E
Memory#: 01
TX 9 bytes
0000     ff fe fe 08 e0 08 00 01 fd     .........
RX 9 bytes
0000     ff fe fe 08 e0 08 00 01 fd     .........
RX 6 bytes
0000     fe fe e0 08 fa fd      ......
icom_set_mem: ack NG (0xfa), len=1
set_mem: error = Command rejected by the rig

Attempt to read channel 01: bad
Note: Command 1a not supported by this rig.  Don't know if this should just be
unavailable or implemented as described above.

Rig command: h
Channel: 01
TX 10 bytes
0000     ff fe fe 08 e0 1a 00 00 01 fd  ..........
RX 10 bytes
0000     ff fe fe 08 e0 1a 00 00 01 fd  ..........
RX 6 bytes
0000     fe fe e0 08 fa fd      ......
icom_get_channel: wrong frame len=0
get_channel: error = Command rejected by the rig

---

Setting Mode to memory: bad
Docs say it should work.  There is also a M-SET momentary button on the front
panel that when depressed selects the freq from the current memory channel
rather
than the vfo.  When released it switches back.  I'll have to read the manual on
this one. :)

Rig command: V
VFO: MEM
TX 7 bytes
0000     ff fe fe 08 e0 08 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 08 fd   .......
RX 6 bytes
0000     fe fe e0 08 fa fd      ......
icom_set_vfo: ack NG (0xfa), len=1
set_vfo: error = Command rejected by the rig

Setting mode to vfo: not supposed to be supported
Doc's say this isn't supported.

Rig command: V
VFO: VFO
TX 7 bytes
0000     ff fe fe 08 e0 07 fd   .......
RX 7 bytes
0000     ff fe fe 08 e0 07 fd   .......
RX 6 bytes
0000     fe fe e0 08 fa fd      ......
icom_set_vfo: ack NG (0xfa), len=1
set_vfo: error = Command rejected by the rig

---

I guess there isn't anything to report.

Rig command: _
Info: None

---

Dumpcaps:
A few notes on the right.

[kmh@swami tests]$ ./dumpcaps 340
rig: loading backend icom
icom: _init called
rig_register (309)
rig_register (310)
rig_register (311)
rig_register (319)
rig_register (330)
rig_register (326)
rig_register (327)
rig_register (334)
rig_register (344)
rig_register (340)
rig_register (342)
rig_register (304)
rig_register (307)
rig_register (300)
Rig dump for model 340
Model name:     ICR-7000
Mfg name:       Icom
Backend version:        0.2
Backend copyright:      LGPL
Backend status: Untested
Rig type:       Receiver
PTT type:       None
DCD type:       None
Port type:      RS-232
Serial speed: 300..19200 bauds, 8N1      I'll have to check the manual for the
                                         specs.
                                         Factory default is 1200
Write delay 0ms, timeout 200ms, 3 retry
Post Write delay 0ms
Has targetable VFO: no
Has transceive: yes
Announce: 0x0
Max RIT: -9.999kHz/+9.999kHz             Don't see this, I'll have to check the
                                         manual in a few days.
Max XIT: -0.0kHz/+0.0kHz
Max IF-SHIFT: -0.0kHz/+0.0kHz
Preamp: 10dB                             Don't think it has one
Attenuator: 20dB
Get functions:                           Don't think it has any functions/levels
Set functions: FAGC NB TSQL APF 
Get level: PREAMP ATT SQL APF AGC SQLSTAT STRENGTH 
Set level: PREAMP ATT SQL APF AGC 
Get parameters: 
Set parameters: 
Number of banks:        12               Looks like it has 1 bank of 99
                                         memories.
Memory name desc size:  0                
Memories: none
TX ranges status, region 1:     OK (0)
RX ranges status, region 1:     OK (0)
TX ranges status, region 2:     OK (0)
RX ranges status, region 2:     OK (0)
Tuning steps:
        100Hz:          AM USB LSB FM WFM 
        1kHz:           AM USB LSB FM WFM 
        5kHz:           AM USB LSB FM WFM 
        10kHz:          AM USB LSB FM WFM 
        12.5kHz:        AM USB LSB FM WFM 
        25kHz:          AM USB LSB FM WFM 
Tuning steps status:    OK (0)
Filters:                                  Have to check on filters
        2kHz:           USB LSB 
        15kHz:          AM FM 
        6kHz:           AM FM 
        150kHz:         WFM 
Has priv data:  Y                         Not sure what these are
Has init:       Y
Has cleanup:    Y
Has open:       N
Has close:      N
Can set conf:   Y                         Not sure what these are
Can get conf:   Y
Can set frequency:      Y
Can get frequency:      Y
Can set mode:   Y
Can get mode:   Y
Can set vfo:    Y                         
Can get vfo:    N
Can set ptt:    N
Can get ptt:    N
Can get dcd:    N
Can set repeater duplex:        N
Can get repeater duplex:        N
Can set repeater offset:        N
Can get repeater offset:        N
Can set split freq:     N
Can get split freq:     N
Can set split mode:     N
Can get split mode:     N
Can set split:  N
Can get split:  N
Can set tuning step:    Y                     Not computer settable
Can get tuning step:    Y                     Not computer settable
Can set RIT:    N
Can get RIT:    N
Can set XIT:    N
Can get XIT:    N
Can set CTCSS:  N
Can get CTCSS:  N
Can set DCS:    N
Can get DCS:    N
Can set CTCSS squelch:  N
Can get CTCSS squelch:  N
Can set DCS squelch:    N
Can get DCS squelch:    N
Can set power stat:     N
Can get power stat:     N
Can get reset:  N
Can get ant:    N
Can set ant:    N
Can set transceive:     N
Can get transceive:     N
Can set func:   Y                          Don't think it has any
                                            functions/levels
Can get func:   N
Can set level:  Y                          Don't think it has any
                                            functions/levels
Can get level:  Y                          Don't think it has any
                                            functions/levels
Can set param:  N
Can get param:  N
Can send DTMF:  N
Can recv DTMF:  N
Can send Morse: N
Can decode events:      Y
Can set bank:   N
Can set mem:    Y                          
Can get mem:    N
Can set channel:        Y                  See notes on memory above
Can get channel:        Y                  See notes on memory above
Can ctl mem/vfo:        Y                  See notes on mem/vfo above
Can scan:       N
Can get info:   N

Overall backend warnings: 0

[Hamlib-developer] RE: [Hamlib-cvs-digest] CVS: hamlib/include/hamlib rig.h,1.59,1.

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

Am I supposed to be using the MHz macro?  This change broke my code:

On 27-Feb-02 Stephane Fillod wrote:
> diff -C2 -r1.59 -r1.60
> *** rig.h     27 Jan 2002 23:46:01 -0000      1.59
> --- rig.h     27 Feb 2002 23:22:31 -0000      1.60
> ***************
> *** 211,217 ****
>   
>   #define Hz(f)       ((freq_t)(f))
> ! #define kHz(f)      ((freq_t)((f)*1000))
> ! #define MHz(f)      ((freq_t)((f)*1000000L))
> ! #define GHz(f)      ((freq_t)((f)*1000000000LL))
>   
>   #define RIG_FREQ_NONE Hz(0)
> --- 211,217 ----
>   
>   #define Hz(f)       ((freq_t)(f))
> ! #define kHz(f)      (((freq_t)(f))*1000UL)
> ! #define MHz(f)      (((freq_t)(f))*1000000UL)
> ! #define GHz(f)      (((freq_t)(f))*1000000000UL)
>   
>   #define RIG_FREQ_NONE Hz(0)

It forces the frequency to a freq_t before it does the muliplication.  Because
I was calling it with a double, I lost the digits after the decimal point.

If I'm not supposed be using it let me know.  I just figured it was handy.

Relevent parts of my code:

void command_set_freq(int xkey,struct socket_list_struct *psocket_list,struct
socket_line_struct *psockline,struct radio_connection_struct
*pradio_connection,char *prest)
{
  int x;
  double freq;

...

  freq = atof(prest);

  x = rig_set_freq(pradio_connection->rig,RIG_VFO_CURR,MHz(freq));

[Hamlib-developer] RIG_SCAN_RESUME_ON/OFF was Re: Hamlib-cvs-digest digest, Vol 1 #282 - 1 msg

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

On Thu, Feb 28, 2002, ham...@li... wrote:
>
>    1. CVS: hamlib/include/hamlib rig.h,1.60,1.61 (Francois Retief)

[...]

> ***************
> *** 360,363 ****
> --- 360,365 ----
>   #define RIG_SCAN_PROG	(1L<<3)		/* Programmed(edge) scan */
>   #define RIG_SCAN_DELTA	(1L<<4)		/* delta-f scan */
> + #define RIG_SCAN_RESUME_ON  (1L<<5) /* Scan resume ON (IC-910H) */
> + #define RIG_SCAN_RESUME_OFF (1L<<6) /* Scan resume OFF (IC-910H) */
>   

Francois, don't you think it should be RIG_FUNC_RESUME instead ?


s.

[Hamlib-developer] IC-910

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

Hello all,

I committed the Icom IC-910 rig.  At this point it is untested, 
so send me a trace of any bugs you find.  Enjoy..

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] Icom transceive feature and poll

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

On Wed, Feb 27, 2002, Chuck Hemker wrote:
> (One of the modes I wanted to support was the ability to have the user tune
> the radio with the dial, stop when the user hears something interesting, and
> then do doppler updates after that point (sort of like InstantTune))

Should be possible with Hamlib and a yet to be written user application.

> I also was writing this as a network daemon using a poll loop and I didn't want
> to use signals.  I couldn't find any documentation for doing this.  So after
> looking through testtrn.c, and some of the other routines I came up with 
> something like this:

Do you have any reason for not using signals? Hamlib is using SIGIO, for
asynchronous event notification. Fortunately, there's no need for the user
application to know anything about signals. The freq_event just get called
when the event arrives.

> When opening the rig, set up callback for freq event:
> 
>  rig->callbacks.freq_event = process_freq_event;
> 
> Add rig rig->state.rigport.fd to my list of fd's to poll.
> 
> And when I see input on that fd, I call:
> 
>  void check_rig_for_input(int xkey,RIG *rig)
>  {
>    if(!rig)
>      return;
>    /*
>     * Do not disturb, the backend is currently receiving data
>     */
>    if (rig->state.hold_decode)
>      return;
>   
>    if (rig->caps->decode_event)
>      rig->caps->decode_event(rig);
>  }

Please, don't use decode_event() and state.hold_decode. These are internal
to Hamlib, and such implementation may change without notice. The
freq_event won't.

>  int process_freq_event(RIG *xrig, vfo_t xvfo, freq_t xfreq)
>  {
>    int slot;
>    char message_buf[1024];
> 
>    printf("Rig %p changed freq to %l Hz\n",xrig,xfreq);
> 
>    ...
> 
>    return(0);
>  }
> 

> This seemed to work reasonably well, but it seemed to have a few problems:
> a. It seems to me to be not as clean as it could be.

check_rig_for_input is unnecessary.

> b. I'm not sure how I would handle multiple radios on the same serial/ci-v bus.

The low-level CI-V code is not very robust. It may work. But I have only
one IC-706 to test with. This code has to be rewritten most likely.

> c. I'm not sure if I'm using routines that I'm not supposed be using.

I've create new calls for installing call backs: rig_set_freq_callback.
See testtrn for an example. To do InstantTune, you may replace the
sleep() by your doppler compensation code, and doing rig_set_freq() only
if freq_event has not been called for xx seconds (i.e. the user is not
tuning with the VFO dial any more)

> d. I'm not sure if there is anywhere I can store any user data so I don't have
>    to do a search to find which rig this came from. 
>    Either the ability to set something that comes back as an additional
>    argument to the callback routine, or a user_data pointer in RIG.

The freq_event callback already has the rig handle as a parameter, so you
can do rig_set_freq within the callback (even though it's not
recommanded to do it synchronously).
However, you're damn right, there's missing a private data pointer.
Okay, this is fixed and commited (not tested though).
Let me know if it looks better this way.

> e. I'm not a big fan of callbacks (they tend to cause large numbers of global
>    variables) but I'll live with them if need be.

There's no need of global variables if you have a private data pointer.
BTW, do you know any better replacement for callback routines?

> e. There doesn't seem to be any docs for it.

Hmmm, at least there's some code :-)   Yeah, I know, documentation is
sparse. To be honest, the design of Hamlib is not complete. See the
private data pointer that was missing. The event notification was more an
alpha state of a proof-of-concept. Now if you're interrested in, I can
help you implement it to a more usable state.
Patchs are welcome too :)

> Since in both network (poll) based programming and gtk (callback if input
> available on fd) could use an api to be able to poll the radio I was wondering
> if there was a plan?

Do you mean we need something like rig_get_fd() ?
Might be a good idea. This may be tricky since asynchronous event
notification get mixed with regular protocol answers. 
rig_get_dcd_fd may be useful too.

> Also was wondering if someone had played with multiple radios on a CI-V bus.
> Just looking at the design of the transceive feature, it looks like if you
> turn it on on a radio, it wants to both send and receive the frames and
> because of this if you have two radios that can tune the same frequency, then
> it automatically sets the second radio to the same frequency as the first.  It
> looks like an interesting misfeature that you can't separately turn on and off
> the send and receive parts.

Too bad there's not an option on the rig to select the destination
address: either 0x00 (i.e. broadcast) or 0xe0 (the controller = the PC).
And there's not easy way to do it using diodes and transistors.
The only solution I can see would involve a PIC.

> Also just wondering what I want to do with radios that don't support this
> feature.  It looks like you would have to poll the radio every so often to
> see if the frequency has changed.  I was just wondering if hamlib should worry
> about that, or leave that up to the calling software.

That's the reason why there's a RIG_TRN_POLL define in rig.h. However,
this feature is not implemented yet.

> BTW When doing this, it seems that occasionally it seems that hamlib gets
> confused and doesn't send out all the updates.  (it seems to keep calling
> the icom_decode routine but doesn't always call the callback routine.  I haven't
> had a chance to track this down further.  I don't know if this is caused by a
> collision, something getting in the wrong state, or something else.

The code is not robust at all, is not asynch safe, and it can even work.
Some traces would help to debug the problem you're reporting, or maybe
just a closer look at the source code.


Cheers,
Stephane

Re: [Hamlib-developer] Re: Fun with Hamlib

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

Hi Chuck,

First of all, Thanks for your interrest in Hamlib.
We do appreciate feedback!

On Wed, Feb 27, 2002, Francois Retief wrote:
> > 2. In my testing of the ic-r7000, I noticed that the radios using the new icom
> > routines didn't support setting the CI-V address.  I was using this to play
> > with the ic-r7000 with rigctl to talk to the ic-r7000 before I created the
> > entry for it.  Just wondering if anyone noticed.  If I get a chance, I'll try
> > to figure out what needs to be done and send in a patch.
> 
> The set_conf()/get_conf() functions is what you need.  Add the 
> following lines to the rig structure:
> 
> cfgparams: icom_cfg_params,
> set_conf: icom_set_conf,
> get_conf: icom_get_conf,

Dang, the icr8500 was the only one missing these lines. Thanks Francois
for noticing it. This is commited with an initial ic-r7000 support.
Some functions may not be there, I have yet to dig through the manual to
see which one are available.

> Now to set the CIV address to 0x42, issue:   
> 	rig_set_conf(rig, TOK_CIVADDR, 0x42);

Chuck, could you confirm this is 0x08 for the R-7000?

> Please note, that these two functions is not added to all the 
> Icom rigs. Still have to be done ;-)

Besides icr8500, is there any other?

> > 3. One of these days I was going to try testing my software over at a friend's
> > house who has an Icom 910 and an AOR 5000 which are also not currently
> > supported.  If anyone wants me to try something, I'll be happy to.  Otherwise
> > I'll have to try to come up with descriptions of the radios myself.
> > 
> I have partially completed support for the Icom 910.  Our radio is 
> currently in use, so I cannot test the code.  Will finish the IC-910 
> code and commit it some time tonight or tomorrow.

Alright Francois, good stuff. I've forked an AR5000, should be commited by
the time your read this. Please note that the aor backend has never been
fully tested, so your report is more than welcome.
In order to ease Hamlib hacking, there are some guidelines to test the cvs
version, available at the following URL:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hamlib/hamlib/README.betatester?rev=1.1&content-type=text/vnd.viewcvs-markup


Thanks,
Stephane F8CFE

[Hamlib-developer] Re: Fun with Hamlib

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

Hello Chuck,

Chuck Hemker wrote:
> 
> I've been writing a satellite track program and using hamlib for doing the
> frequency setting and doppler correction for the radios.  In doing this I've
> run across a few things with hamlib that I was wondering about:
> 
> 1. I've been using an Icom R7000 receiver for testing.  It's a fairly simple
> radio to computer control because it allows the computer to control so few
> things. :)   It was not supported yet so I quickly copied and modified the
> entry for the icr8500.  It works for set_freq and get_freq, but I haven't
> tested it for anything else.  Either I'll look into it further and clean it
> up, or if someone who understands the structures better wants to do something,
> I'll be happy to test it.
> 
> Also, I ran across a pdf file that explained CI-V for the older radios:
> http://www.chasque.net/franky/ci5.pdf

Cool
 
> 2. In my testing of the ic-r7000, I noticed that the radios using the new icom
> routines didn't support setting the CI-V address.  I was using this to play
> with the ic-r7000 with rigctl to talk to the ic-r7000 before I created the
> entry for it.  Just wondering if anyone noticed.  If I get a chance, I'll try
> to figure out what needs to be done and send in a patch.

The set_conf()/get_conf() functions is what you need.  Add the 
following lines to the rig structure:

cfgparams: icom_cfg_params,
set_conf: icom_set_conf,
get_conf: icom_get_conf,

Now to set the CIV address to 0x42, issue:   
	rig_set_conf(rig, TOK_CIVADDR, 0x42);

Please note, that these two functions is not added to all the 
Icom rigs. Still have to be done ;-)

> 3. One of these days I was going to try testing my software over at a friend's
> house who has an Icom 910 and an AOR 5000 which are also not currently
> supported.  If anyone wants me to try something, I'll be happy to.  Otherwise
> I'll have to try to come up with descriptions of the radios myself.
> 
I have partially completed support for the Icom 910.  Our radio is 
currently in use, so I cannot test the code.  Will finish the IC-910 
code and commit it some time tonight or tomorrow.
 
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

[Hamlib-developer] Icom transceive feature and poll

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

When working on my software, I wanted to use the "transceive function" (have 
radio send a ci-v frame when the dial is changed) so I could tell if someone
was turning the dial on the radio.  

(One of the modes I wanted to support was the ability to have the user tune
the radio with the dial, stop when the user hears something interesting, and
then do doppler updates after that point (sort of like InstantTune))

I also was writing this as a network daemon using a poll loop and I didn't want
to use signals.  I couldn't find any documentation for doing this.  So after
looking through testtrn.c, and some of the other routines I came up with 
something like this:

When opening the rig, set up callback for freq event:

 rig->callbacks.freq_event = process_freq_event;

Add rig rig->state.rigport.fd to my list of fd's to poll.

And when I see input on that fd, I call:

 void check_rig_for_input(int xkey,RIG *rig)
 {
   if(!rig)
     return;
   /*
    * Do not disturb, the backend is currently receiving data
    */
   if (rig->state.hold_decode)
     return;
  
   if (rig->caps->decode_event)
     rig->caps->decode_event(rig);
 }

 int process_freq_event(RIG *xrig, vfo_t xvfo, freq_t xfreq)
 {
   int slot;
   char message_buf[1024];

   printf("Rig %p changed freq to %l Hz\n",xrig,xfreq);

   ...

   return(0);
 }

This seemed to work reasonably well, but it seemed to have a few problems:
a. It seems to me to be not as clean as it could be.
b. I'm not sure how I would handle multiple radios on the same serial/ci-v bus.
c. I'm not sure if I'm using routines that I'm not supposed be using.
d. I'm not sure if there is anywhere I can store any user data so I don't have
   to do a search to find which rig this came from. 
   Either the ability to set something that comes back as an additional
   argument to the callback routine, or a user_data pointer in RIG.
e. I'm not a big fan of callbacks (they tend to cause large numbers of global
   variables) but I'll live with them if need be.
e. There doesn't seem to be any docs for it.

Since in both network (poll) based programming and gtk (callback if input
available on fd) could use an api to be able to poll the radio I was wondering
if there was a plan?

Also was wondering if someone had played with multiple radios on a CI-V bus.
Just looking at the design of the transceive feature, it looks like if you
turn it on on a radio, it wants to both send and receive the frames and
because of this if you have two radios that can tune the same frequency, then
it automatically sets the second radio to the same frequency as the first.  It
looks like an interesting misfeature that you can't separately turn on and off
the send and receive parts.

Also just wondering what I want to do with radios that don't support this
feature.  It looks like you would have to poll the radio every so often to
see if the frequency has changed.  I was just wondering if hamlib should worry
about that, or leave that up to the calling software.

BTW When doing this, it seems that occasionally it seems that hamlib gets
confused and doesn't send out all the updates.  (it seems to keep calling
the icom_decode routine but doesn't always call the callback routine.  I haven't
had a chance to track this down further.  I don't know if this is caused by a
collision, something getting in the wrong state, or something else.

[Hamlib-developer] Fun with Hamlib

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

I've been writing a satellite track program and using hamlib for doing the
frequency setting and doppler correction for the radios.  In doing this I've
run across a few things with hamlib that I was wondering about:

1. I've been using an Icom R7000 receiver for testing.  It's a fairly simple
radio to computer control because it allows the computer to control so few
things. :)   It was not supported yet so I quickly copied and modified the
entry for the icr8500.  It works for set_freq and get_freq, but I haven't
tested it for anything else.  Either I'll look into it further and clean it
up, or if someone who understands the structures better wants to do something,
I'll be happy to test it.

Also, I ran across a pdf file that explained CI-V for the older radios:
http://www.chasque.net/franky/ci5.pdf

2. In my testing of the ic-r7000, I noticed that the radios using the new icom
routines didn't support setting the CI-V address.  I was using this to play
with the ic-r7000 with rigctl to talk to the ic-r7000 before I created the
entry for it.  Just wondering if anyone noticed.  If I get a chance, I'll try
to figure out what needs to be done and send in a patch.

3. One of these days I was going to try testing my software over at a friend's
house who has an Icom 910 and an AOR 5000 which are also not currently
supported.  If anyone wants me to try something, I'll be happy to.  Otherwise
I'll have to try to come up with descriptions of the radios myself.

Re: [Hamlib-developer] Alinco question

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

Hi Robin,


First of all, thanks for your interrest in Hamlib.

On Fri, Feb 15, 2002, RFi...@ao... wrote:
> I notice that your group has included the Alinco DX-77 in the project.  I 
> have an Alinco DX-70, and notice in the schematic there is a jack in the head 
> unit that is not visible.  I am guessing that it is hidden under the head 
> unit cover.  The labels on this jack are exdat and exin.  This sounds 
> intrigueingly like it might be capable of controlling the unit.  Is there 
> someone in your group who is knowlegeable about the DX-77?  I would like to 
> talk the him or her to find out more about the rig control hardware and 
> firmware that is used in the DX-77. 

I did the development of the Alinco backend. Sorry, I don't have a DX-77,
so the backend is totally untested. Actually, I wrote the code from the
protocol specification at the following URL:
  http://www.alinco.com/pdf.files/DX77-77_SOFTWARE_MANUAL.pdf

IOW, I have no idea whether the DX-70 can be controlled remotely.
Maybe someone else on the list may know. You can ask also your Alinco
local rep, or write and e-mail to their site's webmaster.
In the case the remote control needs a mod to work, there's an excellent 
site you should check out: http://www.mods.dk, and let us know.


Cheers, 
 Stephane F8CFE

[Hamlib-developer] Alinco question

[<RFi...@ao...>]

I notice that your group has included the Alinco DX-77 in the project.  I 
have an Alinco DX-70, and notice in the schematic there is a jack in the head 
unit that is not visible.  I am guessing that it is hidden under the head 
unit cover.  The labels on this jack are exdat and exin.  This sounds 
intrigueingly like it might be capable of controlling the unit.  Is there 
someone in your group who is knowlegeable about the DX-77?  I would like to 
talk the him or her to find out more about the rig control hardware and 
firmware that is used in the DX-77. 

Sincerely,
Robin Finesmith, AA3NJ

Re: [Hamlib-developer] hamlib slackware packages

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

On Thu, Feb 07, 2002, Joop Stakenborg wrote:
> Hamlib slackware packages are available from
> 
> http://sharon.esrac.ele.tue.nl/pub/slackware/pre-current/contrib/ham/rigcontrol
> 
> Packaged by Arno, PE1ICQ <pe1icq at amsat dot org>

Thank you Joop for the pointer, I'll add it tomorrow to the download
section on sourceforge, and let Arno know about it if he's not on the
mailing list already.

Cheers,
  Stephane F8CFE

[Hamlib-developer] hamlib slackware packages

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

Hamlib slackware packages are available from

http://sharon.esrac.ele.tue.nl/pub/slackware/pre-current/contrib/ham/rigcontrol

Packaged by Arno, PE1ICQ <pe1icq at amsat dot org>
Regards,

Joop PA4TU

[Hamlib-developer] Future developments

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

Hello Stephane,

Stephane Fillod wrote:
>
> > I don't intend to add more caps/calls before 1.1.3.  I am working on
> > a backend with a control system, but is struggling a bit with the
> > threading.  So it will take a while to be complete.   When I finish
> 
> What do you mean by "control system" ? a new backend? or a more
> intelligent way of controlling rotators?
> Also concerning threading, this is obvious Hamlib is NOT thread safe,
> and not even reetrant in some parts (static data). The problem is then
> how to make it thread safe? at which level? having 2 libraries or ala
> libltdl? I'm sure you have some ideas on the topic, and this can be
> discussed for 1.1.4.

Ok, maybe I should explain my plan. (for 1.1.4 or later)

There can be two types of rotator control systems.

1) Where the "control system" sits in a black box outside of the PC 
   and the PC just issue commands to the box.  As the easycomm backend
   is doing now.  This is the type of setup we have here at our lab.

2) The PC implements the "control system". (read: pc does more work).
   Antenna position is normally given as a voltage level that has to be
   digitized with an Analog-to-Digital converter (ADC).  The PC uses 
   this value to determine in which direction a particular motor must 
   turn (and also in some cases, the speed of the motor).  The PC then 
   commands the motor to move the antennas.

At the moment I don't have hardware specs for any commercial/amateur
rotator products out there, so I was thinking of creating a sample 
backend (for type 2) so that it would be easier to implement such a 
controller in the future.

To do this I need to make a control loop that runs at a fixed time 
interval. The control loop is responsible for reading the ADC value, 
calculating the motor control values (direction/speed) and sending 
that values to the motors.  

My current idea is the create a new thread for the control loop 
when a rot is opened.  The thread will only share one data structure 
with the rest of hamlib. The data structure will contain info like 
the azimuth and elevation set-points for the antenna.  Hamlib will 
update this and only this structure.

This thread will be considered the black box of the type 1 controller.
When the rot is closed, the thread will be terminated.
With this idea, I don't foresee a re-entrant problems.

I know this sound like a grand scheme, but when finished, I believe 
we can control 99% of rotators out there.  Unfortunately due to 
personal time constraints I think this might take a couple of 
months to finish.
 
> > Also working on a Java binding.  Asked a colleague to help me here.
> > Most of our new projects is being done in Java.  Anyway this is
> > at an early stage and will not be ready for 1.1.3.
> 
> Groovy! I'm no Java expert, but I guess you are working on a JNI/CNI Java
> binding. No pure Java implementation.
> Maybe you could drop a note on the mailing list, someone else may be
> interrested.

Yes. We constructed a frame work and at the moment is sorting out
how to implement the callbacks with Java's event handling. But again,
still early days. ;-)
 
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] compile problems (hope this does not get mangled)

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

On Tue, 05 Feb 2002 22:17:04 -0500
John Simmons <w9...@ch...> wrote:

> 
> Hello All
>  I have been trying to compile  hamlib version 1.1.3 from the CVS
> sources without much success.
> System is Mandrake 8.1 run  on 1.7 gig Athlon xp with 512 meg of ram.
> The following text files are include :
> rigctl_test.txt
> errors.txt
> rigctl_test is the output from running :  rigctl -vvvv --list
> errors.txt is the capture of the output from: make, make install
>  I realize that most of the warnings are trivial.    What concerns me is
> that "libtool: install: warning: relinking" at the end of the file.
> These files seem to be the same files that I am having trouble with when
> I try to run  rigctl --list.
>  I  hope that someone can tell what I am doing wrong as this is the same
> error that I had on my old machine.

Hi John,

put the following line in your ~/.xsession or the startup script of your 
favourite shell (~/.bashrc for bash):

export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib"

Joop PA4TU

[Hamlib-developer] compile problems (hope this does not get mangled)

[John S. <w9...@ch...>]

Hello All
 I have been trying to compile  hamlib version 1.1.3 from the CVS
sources without much success.
System is Mandrake 8.1 run  on 1.7 gig Athlon xp with 512 meg of ram.
The following text files are include :
rigctl_test.txt
errors.txt
rigctl_test is the output from running :  rigctl -vvvv --list
errors.txt is the capture of the output from: make, make install
 I realize that most of the warnings are trivial.    What concerns me is
that "libtool: install: warning: relinking" at the end of the file.
These files seem to be the same files that I am having trouble with when
I try to run  rigctl --list.
 I  hope that someone can tell what I am doing wrong as this is the same
error that I had on my old machine.

[Hamlib-developer] compile problems

[John S. <w9...@ch...>]

Hello All
 I have been trying to compile  hamlib version 1.1.3 from the CVS
sources without much success.
System is Mandrake 8.1 run  on 1.7 gig Athlon xp with 512 meg of ram.
The following text files are include :
rigctl_test.txt
errors.txt
rigctl_test is the output from running :  rigctl -vvvv --list
errors.txt is the capture of the output from: make, make install
 I realize that most of the warnings are trivial.    What concerns me is
that "libtool: install: warning: relinking" at the end of the file.
These files seem to be the same files that I am having trouble with when
I try to run  rigctl --list.
 I  hope that someone can tell what I am doing wrong as this is the same
error that I had on my old machine.