FW: Re: rxhfa gain setting etc

[comcast.net; w3sz@xxxxxxxxxxxxxxxx>]

lets give this email another try [#3]
-------------- Forwarded Message: --------------
From: w3sz@xxxxxxxxxxx
To: Leif Asbrink <leif@xxxxxxxxxx>
Subject: Re: rxhfa gain setting etc
Date: Sat, 6 May 2006 16:53:22 +0000
> HI Leif, 
> 
> Thanks for the note!
> 
> 
> > > The gain control issue remains for both windows and linux versions with  
> > > the sdr14...i need to x out of the receive screen and then type b to get  
> > > back to the receive screen to get the gain adjustment to occur.  I believe  
> > > your note indicates that this will be fixed in 02-12.
> > Line 135 and thereabout in sdr14.c should look like this:
> > 
> > if(fg.gain > -10)
> >   {
> >   sdr14cmd[5]=0;
> >   }
> > else
> >   {
> >   sdr14cmd[5]=0xec;   // 0 for no att, 0xec for -20dB
> >   }
> > 
> > I hope that the number changes in the on screen control box
> > but that the gain is actually not changed.
> 
> Yes, this is exactly what happens.  THe number changes, but I have to leave the 
> screen and come back via 'x' and 'b' for the gain to actually change.
> 
> I understand the problems you describe in terms of programming that occur with 
> saving some of the parameters.  I don't want to suggest anything that will be a 
> programming problem for you or potentially 'break' things.
> 
> Could you solve this by saving parameters as you do now, but ALSO saving just 
> what the user enters on these screens, in the same form as he enters the 
> parameters, to some new par_file so that the values can be pulled from there and 
> displayed when the user goes to change these parameters, so that the user will 
> at least know what he entered before?  
> 
> This shouldn't interfere with the program or what you have already done in any 
> way.  You could still get the parameters for actual program use from the places 
> you are saving them to now.  One could argue that it would be nice to have a 
> file that would have in readable format a list of all of the operating 
> parameters the user chose in a single list so that when there are problems, it 
> could be reviewed.  It would be like an expanded par_user_int file.  This would 
> not replace or interfere with any of the other parameter files or parameter 
> saving that you have already implemented in Linrad.  It would just be a 
> repository of all of the par values that the user had chosen.  
> 
> It is no problem to me to have to re-enter the values on these screens again if 
> I know what I entered last time;  the problem is just not remembering how it was 
> set before. ;)
> 
> Those are just my thoughts.  I will be happy with whatever you do, Leif.  I am 
> very pleased that you fixed the polarization angle screen.  Thank you very 
> much!!
> 
> I agree very much that it would be great if there were a 'manual' on the use of 
> the AD6620.  I will see if I can find anything on the web.  Thanks for the 
> explanation of the decimator function choices and their consequences, too!
> 
> Well, I would say that you are a programming guru who refuses to learn their 
> lingo.  Which just makes you even more enlightened than the average guru ;)
> 
> And you not just 'a' DSP guru; you are definitely THE DSP guru!!
> 
> Have a great weekend, and
> 
> 73,
> 
> ROger
> W3SZ
> 
> 
> 
> 
> > 
> > > I have a few thoughts on making things easier to use:
> > > 
> > > 1.  in the page for setting receive polarity angle, sign, etc.  it would  
> > > be really nice if the program saved the previously selected values and  
> > > displayed them on the selection page when it is entered instead of  
> > > defaulting back to defaults each time the page is entered.  this is true  
> > > especially since it is possible to accidentlly enter the page, and some of  
> > > us have poor memories and even poorer documentation.  it can take quite a  
> > > few tries to get all of the parameters right ;)  i like the way the old  
> > > choices are displayed on the 'p' parameter setting pages.
> > OK. Not quite trivial because the actual parameters are computed
> > from the ones you set on screen. I could change what parameters
> > to save (look in par_wcw_pg) or compute backwards.
> > I do see your point and decided to leave parameter files as they
> > have always been.
> > 
> > A general hint: In case you suddenly find yourself somewhere where
> > proceeding will change parameters and it was not intentional, press
> > ESC!
> > 
> > > 2.  i have the same sort of comment with the sdr decimation parameter  
> > > page.  it would be nice if linrad remembered and displayed the previously  
> > > selected parameters, for similar reasons.  the magic sum of decimation  
> > > factors is about 417 as you know, but their order matters in terms of how  
> > > wide and flat the spectrum is, and if one doesn't touch things for quite a  
> > > while its easy to forget.  i find for example that 14-8-4 looks the best  
> > > for me whereas 4-8-14 has far too narrow a flat center zone and far too  
> > > large a slope-zone on either side.
> > Hmmm, it is a bit complicated because the spurs and their suppressions
> > become quite different. If the first stage decimates by 14 and you want a 
> > bandwidth of 150 kHz the spurs are suppressed by 60 dB while the decimation
> > by 4 gives a suppression by 80 dB. More important is that there are 3.5 
> > times as many spurs in the first case - and that they therefore are closer 
> > spaced.
> > 
> > The way the last filter is computed in Linrad gives the same spur suppression
> > in the last stage - and therefore the flat bandwidth becomes smaller
> > when that stage is used to decimate more.
> > 
> > Spurs are introduced from all three decimation stages and I do not know 
> > what is optimum in different situations.
> > 
> > Always use the calibration procedure to flatten the passband.
> > Particularly important if the last decimation number is large.
> > 
> > For microwaves where spurs is no problem you might try something
> > like 15,10,2 to get a really wide spectrum:-) 
> > 
> > > will i remember this in a week? [do Ii  
> > > have it correct even now or have i forgotten the best combination  
> > > already?  :) ] 
> > NO;-)
> > 
> > > having the parameters saved and displayed on the selection  
> > > screens would be a help.  again, i like the way the old choices are  
> > > displayed on the 'p' parameter setting pages.
> > There is a need for a little book on "how to set up the AD6620 for
> > use in amateur radio" There are hundreds of units out there;-)
> > 
> > SpectraVue does not allow any choice. For each total decimation 
> > there is only one option.... 
> > 
> >  
> > > 3.  similar comments could be made for all of the screens that, unlike the  
> > > 'p' parameter screens, don't have their parameters saved and displayed for  
> > > the user when he re-enters the routine to set those parameters.  that  
> > > would include [by my poor memory] the video mode selection screen, the  
> > > mouse speed reduction selection screen, the sound card selections etc from  
> > > the 'u' routine, the swap-to-disk screens, etc.  i think a beginner will  
> > > quickly get confused if he finds that no record is made of his last  
> > > selection when he is trying to find the 'best' combination of these  
> > > parameters for his system.
> > > 
> > > since linrad already saves all of these [which it must since they don't  
> > > need to be re-entered each time linrad is restarted], it would be nice if  
> > > they were displayed for the user when he goes to change them.
> > I see the point - but I do not think it is trivial to change. These are 
> > old routines... Maybe I can just display the old value if there is one
> > but the user will have to enter it.
> > 
> >   
> > > the receive polarity one caused me major grief for a long time, because i  
> > > didn't realize that when i entered it, it was setting things back to the  
> > > default values.  i would occasionally 'accidentally' enter the screen and  
> > > things would go back to default and i couldn't figure out why.  or i would  
> > > enter the screen to change one parameter and not notice that all of the  
> > > others went back to default.  then i couldn't figure out why behaviour  
> > > wasn't as expected.
> > This thing fixed now:-)
> >  
> > > those are just my thoughts.  feel free to ignore them ;)  the common theme  
> > > is to display previously selected parameter choices on all 'selection  
> > > screens' for the user like you do on the 'p' pages, so that the user can  
> > > make better use of past experience in making new choices.  and don't set  
> > > the parameters back to default upon entering the screen, as happens with  
> > > the receive polarity selection screen.  if one is 'learning' the program  
> > > and still not sure of what each parameter is or the effect it has on  
> > > system/program operation, setting everything back to default makes it much  
> > > less likely that the new user will ever find the 'right' combination of  
> > > parameters for his system to work properly.
> > Well, the other side is that non-optimal settings will be preserved.
> > What is really needed is some tool that asks what the user wants to achieve
> > and then suggests the optimum parameters an what performance will be
> > associated with them. Means for SDR-14:
> > 
> > Set total decimation by output sampling speed range. e.g. 180-220
> > set level and frequency separation of spurs. 
> > For 144 MHz listening on 28 with good 144 selectivity:
> >    < 1MHz 120dB
> > 1 to 2 MHz 100dB
> > 2 to 4 MHz 80dB
> > 4 to 33 MHz 40 dB                                             
> > 
> > For 7 MHz without any roofing filter:
> >   < 10 MHz 80 dB
> >   < 33 MHz 70 dB
> > 
> > It would be possible to compute some alternatives and give the user
> > a choice between them as an alternative to the direct setting
> > of decimation numbers (which has to be an option for those
> > technically oriented guys...)
> > 
> > > ps you certainly cannot claim not to be a programming guru anymore.  you  
> > > are a major guru now ;)
> > 
> > Hmmm, programming is a profession and the professionals use
> > methods and a language that I can not comprehend. I do not
> > see what it is good for in the kind of computing where I have
> > an interest (dsp, antenna optimisation etc) so I do not
> > want to spend years to learn their language. I think 
> > programmers today are so focused on object oriented 
> > programming that they have forgotten that non-administrative
> > tasks may be better treated by task oriented programming.
> > (And programmers refuse to use such old-fashioned methods....)
> > 
> > So, I do not deserve the label programmer and particularly
> > not programming guru. Maybe dsp guru;-)
> > 
> > 73
> > 
> > Leif
> > 
> > 
> 
> 



LINRADDARNIL