Thread: [Hamlib-developer] Filter list
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Ken K. <n7...@al...> - 2002-11-06 23:15:25
|
OK, whats the magic incantation that determines the correct order for=20 filters listed in the filter list? I know that the first one mentioned f= or a given mode determines what is considered 'normal' but what determines what is used for narrow and wide? The documentation is anything but helpful here. The comment in the code reads "remember, order matters" but no where is this explained in detail. Also, the Ten-Tec Pegasus 550 has 34 different filters, all available for= a any mode, but rig.h has an upper limit of 16 for FLTLSTSIZ. Can anyone s= ee any reason why this shouldn't be increased? =20 Ken, N7IPB |
|
From: Stephane F. <f8...@fr...> - 2002-11-06 23:44:16
|
On Wed, Nov 06, 2002, Ken Koster wrote: > OK, whats the magic incantation that determines the correct order for > filters listed in the filter list? I know that the first one mentioned for a > given mode determines what is considered 'normal' but what determines > what is used for narrow and wide? The same goes for narrow and wide. So the first one in the list is the normal filter (as returned by rig_passband_normal), then the first filter that is below the normal filter if the narrow filter (as returned by rig_passband_narrow) and you guessed already for the wide filter. Have a look at src/rig.c to understand how normal/narrow/wide are used. > The documentation is anything but helpful here. The comment in the code > reads "remember, order matters" but no where is this explained in detail. This is one task to complete before 1.1.4: document rig.h data structures using doxygen. > Also, the Ten-Tec Pegasus 550 has 34 different filters, all available for a > any mode, but rig.h has an upper limit of 16 for FLTLSTSIZ. Can anyone see > any reason why this shouldn't be increased? Pretty simple: memory consumption. 8 bytes per element (even on non-used), multiplied by number of models. Now, it's still acceptable to bump FLTLSTSIZ to 34. But what if the MoonMelter YZZ.1 has 38? Maybe would it be better to use some list pointer, like the ctcss_list. We keep source compatibility, and make it flexible for big list. What do you think? While we're at it, what about chan_list, rx/tx_range_list, tuning_steps..? Note: some rigs have free form bandwidth, i.e. near Hertz resolution. For these ones, we may have to rely on a new RIG_LEVEL or put a special value in the filter_list (for example tuning_steps.width = 0) to tell that the bandwidth can be set from the minimal bandwidth in the list to the highest bw in the list for the given mode. The same should go also for the struct tuning_step_list. This is all about API definition, so everyone has to be heard. Comments welcome. Stephane |
|
From: Alexandru C. <al...@ph...> - 2002-11-08 12:28:46
|
Greetings, On Thu, 2002-11-07 at 00:44, Stephane Fillod wrote: > > The documentation is anything but helpful here. The comment in the code > > reads "remember, order matters" but no where is this explained in detail. > > This is one task to complete before 1.1.4: document rig.h data > structures using doxygen. > I've ben playing a little with doxygen to see how it works with data structures. I could begin with the smaller files, like rotator.h and rotlist.h, and, if everything goes well, go on with rig.h. What do you think? Alex, OZ9AEC |
|
From: Stephane F. <f8...@fr...> - 2002-11-08 21:40:09
|
On Fri, Nov 08, 2002, Alexandru Csete wrote: > I've ben playing a little with doxygen to see how it works with data > structures. I could begin with the smaller files, like rotator.h and > rotlist.h, and, if everything goes well, go on with rig.h. > > What do you think? Oh yes! please go ahead! Actually, I have already some notes for rig.h, but not in doxygen format. I'll see how you proceed for rotator.h, and do the same for rig.h. Some data struct can be tricky (but common sense), we have to explain how to use them, from a lib user point of view, and also from a backend implementer point of view. 73 Stephane |
|
From: Alexandru C. <al...@ph...> - 2002-11-09 13:25:48
|
Greetings, I have now added some doxygen comments to rotator.h and rotlist.h. It basically doubled the file sizes, but I guess there's not much to do about that. For me it looks quite all right, except that structure members are denoted as class members, ie. rot_caps::cfgparams. I hope there is a sensible way to change that at some point. I also hope, that someone who has written the code, will check the contents to make sure, that I have not misunderstood or missed anything. Alex On Fri, 2002-11-08 at 22:32, Stephane Fillod wrote: > > On Fri, Nov 08, 2002, Alexandru Csete wrote: > > I've ben playing a little with doxygen to see how it works with data > > structures. I could begin with the smaller files, like rotator.h and > > rotlist.h, and, if everything goes well, go on with rig.h. > > > > What do you think? > > Oh yes! please go ahead! Actually, I have already some notes for rig.h, > but not in doxygen format. I'll see how you proceed for rotator.h, and > do the same for rig.h. Some data struct can be tricky (but common sense), > we have to explain how to use them, from a lib user point of view, > and also from a backend implementer point of view. > > 73 > Stephane > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer > |
|
From: Stephane F. <f8...@fr...> - 2002-11-12 22:30:17
|
On Sat, Nov 09, 2002, Alexandru Csete wrote: > I have now added some doxygen comments to rotator.h and rotlist.h. It > basically doubled the file sizes, but I guess there's not much to do > about that. For me it looks quite all right, except that structure > members are denoted as class members, ie. rot_caps::cfgparams. I hope > there is a sensible way to change that at some point. I also hope, that > someone who has written the code, will check the contents to make sure, > that I have not misunderstood or missed anything. Good job Alex. I've copy pasted what you've done to document the rig API. It's not complete yet, but it's a start. I still have to sort out the grouping, because browsing by file is not the better approach. If something is not in the documentation, it's time to ask for it! Cheers, Stephane |
|
From: Nate B. <n0...@ne...> - 2002-11-13 02:18:12
|
Thanks for the documentation updates guys!
You don't know how much the new docs ease my finding things like the
proper constants to pass back to the frontend functions.
Keep up the great work!
73, de Nate >>
P.S. my ft920 backend work continues and I'm making good progress.
--
Wireless | Amateur Radio Station N0NB | "We have awakened a
Internet | n0...@ne... | sleeping giant and
Location | Bremen, Kansas USA EM19ov | have instilled in him
Amateur radio exams; ham radio; Linux info @ | a terrible resolve".
http://www.qsl.net/n0nb/ | - Admiral Yamomoto
|
Thanks for helping keep SourceForge clean.
X