[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