Thread: [Hamlib-developer] Here is kenwood_set_level
Library to control radio transceivers and receivers
Brought to you by:
n0nb
|
From: Joop S. <pa...@de...> - 2002-01-18 19:17:29
Attachments:
hamlib.patch4
|
This patch will add rig_set_level for kenwood. I have only added RIG_LEVEL_AF,RF and SQL. More later. I have tested it with Gnome RIG, part of the groundstation software suite, see http://groundstation.sourceforge.net/?grig, code is available through CVS. Grig is a great tool for testing some basic functions. You get a cool LCD display (better looking than on my TS870) and settable audio, RF level, modes and more. You can tune the rig by clicking with either left or right mouse button on the LCD display. Tuning is digit based. Stephane, you might want to update kenwood/README.kenwood, since we now have some basic kenwood stuff working... Regards, Joop PA4TU |
|
From: Alexandru C. <al...@if...> - 2002-01-19 15:00:32
|
I'm glad to hear that Gnome RIG also works for others than me... We were very close to make an early release, then a deadline on my thesis prevented me from doing any coding for the last ten days or so. But I'll be back during the next week. Alex, OZ9AEC PS: the LCD digits are stolen from the IC-746. On Fri, 2002-01-18 at 20:17, Joop Stakenborg wrote: > This patch will add rig_set_level for kenwood. > I have only added RIG_LEVEL_AF,RF and SQL. More later. > > I have tested it with Gnome RIG, part of the groundstation software > suite, see http://groundstation.sourceforge.net/?grig, > code is available through CVS. > > Grig is a great tool for testing some basic functions. You get a > cool LCD display (better looking than on my TS870) and settable audio, > RF level, modes and more. You can tune the rig by clicking with either > left or right mouse button on the LCD display. Tuning is digit based. > > Stephane, you might want to update kenwood/README.kenwood, > since we now have some basic kenwood stuff working... > > Regards, > > Joop PA4TU -- ------------------------------------------------------------------------ Alexandru Csete <al...@if...> Office : 520-332 Institute of Physics and Astronomy Web : www.ifa.au.dk/~alexc Ny Munkegade, Building 520 Phone : (+45) 8942 3622 University of Aarhus Cell. : (+45) 2962 4317 Denmark HF-CW : 7010kHz +/- QRM ------------------------------------------------------------------------ |
|
From: Joop S. <jo...@ya...> - 2002-01-19 23:49:04
|
On 19 Jan 2002 16:00:16 +0100 Alexandru Csete <al...@if...> wrote: > I'm glad to hear that Gnome RIG also works for others than me... We were > very close to make an early release, then a deadline on my thesis > prevented me from doing any coding for the last ten days or so. But I'll > be back during the next week. > > Hi Alex, the CVS version is quite suited as an alpha or even beta release. I like the work you have done so far! > Alex, OZ9AEC > > > PS: the LCD digits are stolen from the IC-746. > Must be a cool looking rig.... Joop PA4TU |
|
From: Stephane F. <f4...@fr...> - 2002-01-19 19:02:34
|
On Fri, Jan 18, 2002, Joop Stakenborg wrote: > This patch will add rig_set_level for kenwood. > I have only added RIG_LEVEL_AF,RF and SQL. More later. Good stuff. commited. Btw Joop, I know you're not very fond of cvs over a modem, but would you like a cvs write access to the repository? > I have tested it with Gnome RIG, part of the groundstation software > suite, see http://groundstation.sourceforge.net/?grig, > code is available through CVS. I got to give it a shot. Last time I checked it out, nothing was told to work. It's going to be interessting. Alex, please let me know before releasing grig, we may release hamlib-1.1.3 first to ease testing. > Stephane, you might want to update kenwood/README.kenwood, > since we now have some basic kenwood stuff working... Oops. Yep, will add to the TODO list, as well as doc/NOTES, and virtually all the README's and such ... (patch welcome :) ... Cheers, Stephane F8CFE |
|
From: Joop S. <pa...@de...> - 2002-01-19 23:46:46
|
On Sat, 19 Jan 2002 20:01:40 +0100 Stephane Fillod <f4...@fr...> wrote: > On Fri, Jan 18, 2002, Joop Stakenborg wrote: > > This patch will add rig_set_level for kenwood. > > I have only added RIG_LEVEL_AF,RF and SQL. More later. > > Good stuff. commited. > Btw Joop, I know you're not very fond of cvs over a modem, > but would you like a cvs write access to the repository? > Okay, since it's only small changes every time, cvs write access would be do-able. I am about 2 months away from a high speed internet connection anyway, at last they have decided to offer ADSL in the small town I live. > > > Stephane, you might want to update kenwood/README.kenwood, > > since we now have some basic kenwood stuff working... > > Oops. Yep, will add to the TODO list, as well as doc/NOTES, and virtually > all the README's and such ... (patch welcome :) ... > I'll have a look at the kenwood stuff. > > Cheers, > Stephane F8CFE > Regards, Joop PA4TU |
|
From: Alexandru C. <al...@if...> - 2002-01-20 11:27:59
|
On Sat, 2002-01-19 at 20:01, Stephane Fillod wrote: > Alex, please let me know before releasing grig, we may release > hamlib-1.1.3 first to ease testing. Sure, no problem. I think it is a good idea and it is my impression that hamlib-1.1.3 is very close, am I right? Alex OZ9AEC -- ------------------------------------------------------------------------ Alexandru Csete <al...@if...> Office : 520-332 Institute of Physics and Astronomy Web : www.ifa.au.dk/~alexc Ny Munkegade, Building 520 Phone : (+45) 8942 3622 University of Aarhus Cell. : (+45) 2962 4317 Denmark HF-CW : 7010kHz +/- QRM ------------------------------------------------------------------------ |
|
From: Stephane F. <f4...@fr...> - 2002-01-28 19:29:32
|
On Sun, Jan 20, 2002, Alexandru Csete wrote:
> Sure, no problem. I think it is a good idea and it is my impression that
> hamlib-1.1.3 is very close, am I right?
You're right Alex. I think we need a 1.1.3 release soon.
However, there's no release date yet. Let's just say the coming weeks.
Nate is working on the documentation, and on my side I'd like
to do the following:
- add new calls: rig_srch_ctcss, rig_srch_dcs, rig_get_bandscope,..
- add new rotator caps and calls (can I have your feedback Francois?)
- update hamlib.m4 (which can then be used by grig and kontakt)
- test kenwood/th backend on my TH-F7E, provided my level converter works
- merge ft-100 support from Alex KC2IVL and/or Kenenth
- define new capability to advertise what can be stored/restored in a
memory channel.
- update README,TODO,etc.
- ...
Any wishes for 1.1.3?
Note: rigctl is now able to display the content of a memory channel
('h' command). Let me know how it works for you!
Cheers,
Stephane F8CFE
|
|
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 |