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