Re: [Hamlib-developer] Why hamlib is not really suited for satellite radias

[<lx...@gm...>]

Hi Stephane,
> 
> Hi Luc!
> 
> 
> > case of the ic910 there is another problem. I want to set a frequency of
> 145.950
> > - but the transceiver has currently 70cm on the main band. I have to
> > retrieve the current frequency - look if I need to swap the bands - and
> swap them if
> > needed. This is very IC910 specific - why does I have to do it?
> 
> Well, it looks like the IC910 backend needs some changes. And it's not
> impossible to extend the frontend API if justified.
> Okay, I'd like to understand your needs.
> 
> Your goal is to operate in "split" mode, on a full-duplex rig, with a
> "follow-me" mode (rx and tx stay consistent).
> In satellite mode, you want to be able to control independently the
> receive 
> and the transmit frequencies (and associated modes,etc.). From an API
> point of
> view, this would be done first by entering rig_set_split_mode, and then
> using rig_set_freq (receive) and rig_set_split_freq (transmit).
> REM: tell me if this is enough or not for your application.
>      If not, feel free to express what kind of call you would like to
>      have, with a prototype and an idea of the semantic.
> 
In my application I need to read the current downlink frequency (MAIN band
of the IC910 if it is in the satellite mode), setting the modes on main and
sub bands, and setting the frequency on the main and sub bands.

My suggestion is to have 2 more VFO's in the API. VFO_DOWNLINK and
VFO_UPLINK. So the application does not need to worry about using the right VFO's. 

The IC910 uses the sub band VFO as transmit band if it is in satellite mode.
Another rig could use other VFO's. I think it would be the easiest to simply
let the DOWNLINK / UPLINK VFO point to the real one - dependent of the radio
in use.

> Now, let's talk about the IC910. I never operated a rig with a sub band,
> I don't have the IC910 manual, so you'll have to walk me. 
> Please correct me if I'm wrong on what's following.
> The main and sub bands can be seen as 2 independant VFO's when not in
> "split" (or satellite?) mode. But in "split" mode, one band is the
> receive "channel" and the other one is the "transmit". If I read
> correctly between the lines, on the IC910 in this setup, the main and sub
> can not be both in the same freq "range" (VHF - VHF, UHF - UHF, SHF -
> SHF), 
> so one has to be VHF and the other one UHF for example.
> Question: how do you decide which band is receive, and wich one is
> transmit?

The IC910 has 2 receivers and one Transmitter. The MAIN VFO is receive and
transmit, and the SUB is only receive. The frequencys on both have to be on
different bands. But they can both be any band!

The satellite mode is different. SUB Receive and Transmit / MAIN only
receive. Additionally tuning manually affects both Bands.


> Talking about your example (setting freq of 145.950, and main band on
> 70cm), do you know if you want to change the transmit or the receive
> frequency or change the frequency of the 2m link?
> In other words, how works you application?

The rig control part of my program does work this way:

The user changed manually the frequency (downlink) on the rig. The program
gets the new frequency, calculates reverse doppler for this frequency,
calculates the coresponding uplink and sets the uplink on the rig. 

As the doppler changes, it will store the uplink and downlinkfrequency
internally, and compare with the doppler shift. It this is more than 25Hz for one
frequency it will set a new uplink / downlink frequency on the rig.

It will be able to do this with 2 rigs (one for uplink / one for downlink -
no problem here) or only one rig (full duplex uhf/vhf rig).

What I have not yet decided if I want du support only one simplex rig as in
this case you cannot hear your downlink. But in the case of the ISS it would
make sense.

> 
> 
> > Note... these 2 examples are only for the IC910 - not for the other
> > satellite radios. So, for every satellite radio I still need my
> satellite dependent
> > code? I even don't know if the sub band is uplink or downlink on the
> different
> > radios.
> 
> The goal of Hamlib is to hide the radio depdendant code in a library, 
> such a way that the application has only to support only one ideal
> (somewhat
> virtual) radio. An abstraction layer if you prefer.
> 
> My idea is that an application developer should concentrate on his
> *application*, and not on writing code to support every remote control
> protocol on earth.

That is defenitly the right direction!

> 
> > Note, this is not meant flaming about hamlib. Hamlib is a neat project,
> and
> > the right direction for rig control - but in it's current state not
> really
> > useable for satellite radios.
> 
> alright, let's make it useable!
> 
> BTW, do you plan to also use the rotator control piece in Hamlib?
> There's much to do, but it'd be nice to identify some potential users
> first :)
> 

Yes I do. But rig control first ;-) I have code to control an fodtrack
device, which is really easy, as it is an one-direction interface (Computer -->
interface) using the parallel port.

>  
> 73,
> Stephane
> 
> 

73, Luc

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net