[Hamlib-developer] Future developments
Library to control radio transceivers and receivers
Brought to you by:
n0nb
|
From: Francois R. <fgr...@su...> - 2002-02-07 06:32:55
|
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 |