Thread: [Hamlib-developer] Orion questions
Library to control radio transceivers and receivers
Brought to you by:
n0nb
|
From: Martin, A. <mar...@gm...> - 2005-03-28 16:04:11
|
The Orion (tt565) doesn't behave very well on its serial port. The error rate is fairly high, depending on what else its uP is being asked to do. Also, its responses are not all fixed length. I now see that the TenTec interaction is set up for fixed-length read operations, and it times out if you ask for a higher byte count. At present, the Orion module seems to time out on all read operations! However, the responses are correct as far as I know. To do better for the Orion (verification, error retry, etc.), I may want to bring in much of the serial I/O into orion.c. The question I have is whether this is going to break anything significant -- especially, portability. I don't claim to understand all the subleties. Any thoughts? (Of course portability is not much help if the code is broken...) If I do this, I will be ignoring some parts of the rig capabilities mechanism, like I/O delays. How important is it to refer everything to the official capabilities structure instead of building into Orion backend? Seems to me these are equivalent locations for logic of any particular rig. The main advantage may be that it helps the cross-rig maintainers to find the peculiarities of each rig in one data object, and it helps many backends to look the same. That philosophy may break down if one rig has too much "personality". If there are other Ten-Tec developer/maintainers out there -- do the other TT backends have similar problems? I hesitate to program for platforms I do not have in house. (Not that that stops some folks around here! :-) I would appreciate some Group Think on these questions. 73 -- mar...@gm... http://blog.aa6e.net |
|
From: Mike M. <mm...@UD...> - 2005-03-28 16:21:42
|
Martin, I've been adding code to jupiter.c (and have another update I need to add). And I've also noticed that the Jupiter has a high error rate. I actually wrote a hack of a subroutine that tries up to 3 times for each request, just in case, and it still doesn't take care of the problem all of the time. There is a very good chance I'll be selling my Jupiter shortly, though, so my jupiter.c contributions will be coming to an end if that happens. Mike AB3AP Martin, AA6E wrote on 03/28/05 11:04 ET: > The Orion (tt565) doesn't behave very well on its serial port. The > error rate is fairly high, depending on what else its uP is being > asked to do. Also, its responses are not all fixed length. I now see > that the TenTec interaction is set up for fixed-length read > operations, and it times out if you ask for a higher byte count. At > present, the Orion module seems to time out on all read operations! > However, the responses are correct as far as I know. > > To do better for the Orion (verification, error retry, etc.), I may > want to bring in much of the serial I/O into orion.c. The question I > have is whether this is going to break anything significant -- > especially, portability. I don't claim to understand all the > subleties. Any thoughts? (Of course portability is not much help if > the code is broken...) > > If I do this, I will be ignoring some parts of the rig capabilities > mechanism, like I/O delays. How important is it to refer everything > to the official capabilities structure instead of building into Orion > backend? Seems to me these are equivalent locations for logic of any > particular rig. The main advantage may be that it helps the cross-rig > maintainers to find the peculiarities of each rig in one data object, > and it helps many backends to look the same. That philosophy may > break down if one rig has too much "personality". > > If there are other Ten-Tec developer/maintainers out there -- do the > other TT backends have similar problems? I hesitate to program for > platforms I do not have in house. (Not that that stops some folks > around here! :-) > > I would appreciate some Group Think on these questions. > > 73 |
|
From: Martin, A. <mar...@gm...> - 2005-03-28 16:43:08
|
Mike, I guess that's the hamlib quandry -- too many rigs and too few programmers! If someone wants to send me rigs, ... Seriously (sadly), it's interesting to hear you have similar troubles with the Jupiter. 73, Martin |
|
From: Stephane F. <f8...@fr...> - 2005-03-28 17:23:34
|
On Mon, Mar 28, 2005 at 11:04:02AM -0500, Martin, AA6E wrote: > The Orion (tt565) doesn't behave very well on its serial port. The > error rate is fairly high, depending on what else its uP is being > asked to do. Also, its responses are not all fixed length. I now see > that the TenTec interaction is set up for fixed-length read > operations, and it times out if you ask for a higher byte count. At > present, the Orion module seems to time out on all read operations! > However, the responses are correct as far as I know. Have a look at kenwood/kenwood.c:kenwood_transaction() for an example of variable length return. Basically, it makes use of src/iofunc:read_string(). > To do better for the Orion (verification, error retry, etc.), I may > want to bring in much of the serial I/O into orion.c. The question I > have is whether this is going to break anything significant -- > especially, portability. I don't claim to understand all the > subleties. Any thoughts? (Of course portability is not much help if > the code is broken...) There's no need to bring special serial I/O code. Anyway, you can't do much but retry, and insert some pauses to not overwhelm the uP. Have a look at tt538_transaction() in jupiter.c, or icom_transaction() in icom/frame.c for an example. If you do need to have some kind of new I/O function, try to not bring non portable code in backends. Either use existing functions from frontend, or create a new one, that is generic. > If I do this, I will be ignoring some parts of the rig capabilities > mechanism, like I/O delays. How important is it to refer everything > to the official capabilities structure instead of building into Orion > backend? Seems to me these are equivalent locations for logic of any > particular rig. The main advantage may be that it helps the cross-rig > maintainers to find the peculiarities of each rig in one data object, > and it helps many backends to look the same. That philosophy may > break down if one rig has too much "personality". It helps the application developper and the final user. Some backends simply ignore the settings if they are no applicable. Backends with too much "personality" have it implemented with set_conf settings (TOKEN_BACKEND). -- Stephane PS: don't forget to complain against Ten-Tec about buggy firmwares |
|
From: Martin, A. <mar...@gm...> - 2005-03-29 02:27:09
|
The variable length reading was easier than I expected, but I still need to work on error recovery. Give me a little warning before you go gold with the new release, and I'll be sure CVS is updated. The rigctl and other tests look pretty good now, but I have some application trouble: gMFSK - works fine (but very simple interaction) grig 0.4.2 - reads rig info originally, but no control working sgcontrol 0.3 - reads info, can control some parameters, but can't set freq, AF, etc. Maybe the latter two are just early versions, but I'd be interested in anyone else's experience. Is there a mature app. that is good for verifying a new backend? Cheers, Martin |