Thread: [Hamlib-developer] Re: Kenwood TH-D7A(G) patch
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Francois R. <fgr...@su...> - 2002-01-04 18:29:02
Attachments:
hamlib.kenwood_thd7.20020103.patch
|
Hello Stephane, > Great! I love patches! And yours is now commited to cvs. > You're right, the TH-D7 is using a protocol similar to the Kenwood table > top rigs, but with some changes. It turns out I own a TH-F7E, and even > though I don't have the protocol specs, it looks like the commands are the > same as the TH-D7, hence the kenwood/th.c file. Here is some more. ;-) Should I add the commands to the th.c or thd7.c file? Do you know how similar the TH-F7E/TH-D7 are? > > It seems that some duplication can be avoided if the > > kenwood_transaction is responsible for adding the terminating > > character (either, ';' for older radios and <CR> for TH) > > based on the radio being used. > > sure! Actualy, I don't like at all kenwood_transaction(). > So feel free to crush it and rewrite it correctly, in the light of the > different Kenwood protocol variants. If not sure how to do it, we can > discuss about it. That'd be neat if kenwood_transaction could handle > rigs error codes without having to pass an ack_buf. Thus when no response > is expected, ack_buf = NULL would be better than ack_len = 0. I agree. I have an idea or two. I will start looking into a better transaction routine. I aspect that still bother me is how async messages should be handled. How does the callback infrastructure of hamlib work? I don't quite follow the Icom implementation. > > Also, it seems that the *data_len parameter is not returning > > any value. I always get zero length, but the buffer contain > > the correct string. > > okay, time to take a closer look. Almost all the Kenwood command are string based. Thus we can work with strings instead of buffer/length. See the read_string function I added with the Easycomm patch. It is basically a replacement for the port_transaction function. btw. Why the difference between read_block and fread_block? 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 |
|
From: Stephane F. <f4...@fr...> - 2002-01-06 17:44:33
|
Hi Francois!
On Fri, Jan 04, 2002, Francois Retief wrote:
> Here is some more. ;-) Should I add the commands to the th.c or thd7.c
> file? Do you know how similar the TH-F7E/TH-D7 are?
If I know? It's very simple. I have absolutly no documentation
whatsoever on the TH-F7E protocol. Google is dumb on the subject.
So when I tried the table top Kenwood protocol and firgured out it wasn't
the right one, it turned out the TH-D7 worked. So as long as it works,
I'll assume TH-F7E/TH-D7 are similar :) So go ahead, add the commands to
the th.c file, and I'll test them on my TH-F7E.
I guess to right solution would be to ask a Kenwood representative to
disclose the procotol specifications..
> I aspect that still bother me is how async messages should be handled.
> How does the callback infrastructure of hamlib work? I don't quite
> follow the Icom implementation.
The async messages works in Hamlib using SIGIO. aoi would be better but
it's not yet mature for Linux (wip).
Have a look in src/event.c
* add_trn_rig() installs a sig handler dispatcher and setup the file
descriptor to send SIGIO whenever data arrived.
* sigiohandler, unfortunately the O_ASYNC/SIGINFO is unable to report the
associated fd, which is really too bad. So sigiohandler
has to find it out.
* search_rig_and_decode() checks if the rig sent async messages and
then calls the decode_event method associated to the
backend.
* decode_event then in turn decode the message and calls any appropriate
setup rig_callbacks.
In order to support async messages, all a backend needs to have is the
decode_event function, and eventually set_trn/get_trn if available.
Note: there's a race hazard because of the async nature. Async IO has to
be disabled during normal backend transactions, hence the
state.hold_decode field. This acts as a mutex, however, right now, it's
not completly safe because the operation may not be atomic. To be fix one
day, when event decoding becomes more mature (read tested :).
There's a sample user program tests/testtrn.c, and it works with my Ic706.
I know Kenwood protocol is able to report async events. Do you have
the format of the "AI" async message?
> Almost all the Kenwood command are string based. Thus we can work
> with strings instead of buffer/length. See the read_string
> function I added with the Easycomm patch. It is basically a
> replacement for the port_transaction function.
Hmmm, the attached patch in your mail is the same one you sent me already
last week (hamlib.kenwood_thd7.20020103.patch).
BTW, what is your sourceforge login name so I add you to the developer
list. It'll be easier for you to commit directly to the cvs rep.
> btw. Why the difference between read_block and fread_block?
read_block is using read and fread_block is using fread.
The difference is read is non-buffered whereas fread is.
This means fread tries to read more than you requested, so any subsequent
call to fread will save for system calls.
IOW, this is a performance improvement, esp. when reading bytes one by
one.
Cheers,
Stephane
> diff -u3 -rP --exclude=CVS --exclude='*.in' --exclude=configure --exclude=aclocal.m4 --exclude=autom4te.cache --exclude='*~' hamlib-cvs/kenwood/th.c hamlib-20020103/kenwood/th.c
> --- hamlib-cvs/kenwood/th.c Fri Dec 21 10:48:40 2001
> +++ hamlib-20020103/kenwood/th.c Thu Jan 3 19:35:53 2002
> @@ -62,7 +62,7 @@
> int th_set_vfo(RIG *rig, vfo_t vfo)
> {
|
|
From: Stephane F. <f4...@fr...> - 2002-01-07 12:46:31
|
Quoting Francois Retief <fgr...@su...>: > Yes. The Kenwood THD7 has a very extensive async reporting system (more > than the current callbacks in hamlib.) I succeded in getting some of the > async callbacks to work for THD7. Great! We'll have to add the new callbacks to the frontend. However, if I remember well, the "AI" command does not send what has changed but the complete status of the rig right after the event happened. Is it what you noticed on the THD7? So the backend would have to remember the previous state, and from the delta, find and call only the appropriate callbacks. Is it worth the trouble? > In the process I created the th_transaction function, replacing the > kenwood_transaction. It supports error checking, can do retries and > is tolerant to async messages. It might also be possible to extend > it to handle the other kenwood radios. Yep, and maybe some other ASCII oriented backends may want to clone it.. > > BTW, what is your sourceforge login name so I add you to the developer > > list. It'll be easier for you to commit directly to the cvs rep. > > I created an account today. login name: fgretief > Once created I'll commit my latest changes. okay, you're in. happy hacking! There's no written down rules, just common sense. Adding stuff is no problem. Just ask for discussion on the list if you plan to do major or heavy changes on the API/frontend. > I have been playing with a Hamlib binding for Borland's Kylix. > Should I contribute it to Hamlib? Oh yes, sure! please! We have already c++, tcl, and I can see perl and python bindings which stand out in the horizon. You can create a separate directory, much like c++ and tcl, coming along with a simple sample program illustrating the new binding. This will give others (starting from me :) envy and a quick start in Borland's Kylix. Cheers, Stephane |
|
From: Francois R. <fgr...@su...> - 2002-01-07 14:04:09
|
Hello Stephane Stephane Fillod wrote: > > Great! We'll have to add the new callbacks to the frontend. > However, if I remember well, the "AI" command does not send what has changed > but the complete status of the rig right after the event happened. > Is it what you noticed on the THD7? > So the backend would have to remember the previous state, and from the delta, > find and call only the appropriate callbacks. Is it worth the trouble? The AI command is only used the switch transceive mode on or off. The actual async events is exactly the same as normal commands, ie. When the band A/B button is pressed, an 'BC 0' or 'BC 1' is sent, or when a signal measurement is given, 'SM 0,03', etc. But when a frequency changed, the complete vfo status is sent, ie 'BUF 0,00145830000,0,0,0,0,,05,,03,00060000,0' which include among others include the Frequency, VFO, Mode, Split, Tone, CTCSS and a few more. At the moment I only generate an callback event for the VFO, Frequency and Mode. The other data is currently ignored. Do we include an callback for all possible async events? I counted almost 30 events that can be send async. I was thinking of adding callbacks for the most popular/useful/frequently used events, ie. Frequency, signal strength, VFO, etc. and a general purpose callback that handle all the rest/unhandled events. Thus a GUI app can hook into the frequency callback for fast display updates and hook into a general-purpose callback that signal stuff like keyboard-lock, lamp on/off, etc. I think Hamlib should not store the state of the radio. It should serve as a control instrument and an event notifier. > > I created an account today. login name: fgretief > > Once created I'll commit my latest changes. > > okay, you're in. happy hacking! > There's no written down rules, just common sense. Adding stuff is no problem. > Just ask for discussion on the list if you plan to do major or heavy > changes on the API/frontend. Thanks. > > I have been playing with a Hamlib binding for Borland's Kylix. > > Should I contribute it to Hamlib? > > Oh yes, sure! please! We have already c++, tcl, and I can see perl > and python bindings which stand out in the horizon. > You can create a separate directory, much like c++ and tcl, coming along > with a simple sample program illustrating the new binding. This will give > others (starting from me :) envy and a quick start in Borland's Kylix. Will do. 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 |
Thanks for helping keep SourceForge clean.
X