Hi Leif,
Thanks much for your very detailed reply. I am going to get a piece of paper and try to figure the math. What I was trying to say is that it is more complex to transfer from floating point math with a large number of possiblities depending on the way one has selected the parameters, ( in LINRAD use ) to integer numbers representing numbers of pixels that can be really written to, due to the hardware in use, Perhaps even you could make to some of these simplifications only in the beginners version where you do not have to worry too much about possible limitations being introduced by different display routines. So to keep the flexibilies required to all the full capabilities of LINRAD in the standard version. In the end, one ends up with a number of points on the x-axis representing a frequency range. ( I imagine at this point ) My suggestion is not to interfere with the linrad basics but ONLY with what is being represented on the display with limitations to limit how much extra computing could be introduced by doing this. In the end there are perhaps 800 pixels representing an array of many frequencies. call it N , the end result of the FFT. I imagine in the end you have this array somewhere in the program integers representing amplitudes Y-axis vs integers representing freq's. ( X-axis ) to display the results. Now allow to set a X1 and a X2 where in the final result ( X2 - X1) = display width ( as assumed to be 800 ) Then do away with some of the processing that was in place to get from the original N to the 800, call that display reduction Process Proc1 Reverse the process to "connect sufficient dots" ) go back to the full array N and instead of N -> 800 look for X2 - X1 values to fill the graph to ( X2 - X1 ) points. Process Proc2 Or may be just simpler , change Proc1 to reduce from a new Nnew to 800 where Nnew = N2new - N1new. N2new = ( X2/800 * N ) N1new = (X1/800 *N ) This all with the proper and smart rounding off. of course All this with tight limitations on the allowed selection of [ X2 - X1 ] to control added calculations in the display function(s) If one doesn't have a starting point of an array of n1 hor pixel coordinates vs n2 vertical pixel coordinates it could be become quite complicated in a hurry. With the present system I manage to get to zoom on the left ( the begin ) and the right ( the end ) "into" the display but never to zoom around a particular point away form the ends. Then I experience an additional problem : The width of the display, likes to jumping from perhaps 800 pixels ( full width ) to a partial width 400 or even 200 pixels. Again it could very well be my error but I have tried over the years going back ( many ) to prevent this and never been successful, Then, I REALLY hope and wish that you do not abandon LINRAD because of wrong and misdirected critisim. There is no negative intent here whatsoever.with this message or others. I have indicated in the past at several occasions that all your work going back years deserves many more users and much more use. Also I think it is very unfair to tread efforts and work in amateur radio as if a massive company was behind this and users were charged money as. in commercial exchange. Getting a piece of paper and try to find out whether it is all nonsense I write here or not....... 73 Rein W6SZ -----Original Message----- >From: Leif Asbrink <[email protected]> >Sent: Sep 27, 2009 1:54 PM >To: [email protected] >Subject: [soft_radio] Re: Wish List for SDR software > >Hi Rein, > >> You are asking for more feedback to improve the user interface. >> So here is one, granted it might be more difficult to do than I >> understand at this moment: >OK. Good:-) > >> I suppose once you select the certain sampling frequency, one has >> selected the range of the available frequency spectrum ( bandwidth ) >Yes, the total frequency span is the bandwidth of the digital signal >that enters from the hardware. It is the Nyquist frequency (half the >sampling frequency) for real-valued signals and twice as much for >complex input signals (I and Q from direct conversion or VHF-sampling >units) > >> bin seize of FFT, for waterfall calculations. >No. The bin size is another thing. The user has to tell Linrad what >bin bandwidth he wants for the main spectrum (fft1). From that Linrad >computes the appropriate FFT size that is a power of two. The size >must not be larger than 32768 which means that the minimum bin width >is about 5 Hz at 96 kHz sampling. > >The waterfall uses the second FFT in case you have enabled it. The >size of the second FFT can be set to a power of two (0 to 10) so the >bin width in the waterfall can be made really narrow. > >> I have always found it very difficult to select a part of that spectrum >> and never really be able to use the arrows as you are using them. >> and never asked you or anybody else how they are handling this. >> Reason is that I think why am I so stupid that I can not do that? >This is not the right place to explain how to do. It is actually >not difficult but it takes several mouse clicks. > >> OK an example >> >> Soind card sampling selected 96 kHz -> 96 kHz not processed band cover. >OK. Transform spans 96 kHz. The main spectrum bin width may be anything >from 2.9 Hz to 1.5 kHz with a resolution between 2.9 Hz and 7.5 kHz >depending on what window you have selected. The lower bin bandwidth limit >for the waterfall would be 0.02 Hz. > >> Suppose one wants to select lets say 16 or 8 or 4 kHz spread out over the >> full screen ( as in the 96 kHz width ) in real numbers from 32 kHz to 40 >> kHz. >Assume a 1024x768 screen with a main spectrum window of 900 pixels. >In case you have selected a resolution of 200 Hz for the first FFT, the >transform size would be 1024 (with a normal window) with a bin bandwidth of >93.75 Hz. To cover 8 kHz one would need 85.333 bins. 11 pixels per bin would >be too wide so 10 pixels per bin would be adopted The window would become 860 >pixels wide. > >> I dont now how one would do that in the present version without >> lots of clicking and quite frankly I have never been able to do that. >hint: make the window narrow to move fewer points in or out when >clicking. Or use a text editor on the file par_xxx_wg > >Rein, you are right in that it is not user friendly at all. >I will do something about it. > >> But one solution could be to select some pop up window asking >> the user about zooming in/zooming out > >> Pop up widow: >> Note: Allowed zoom ranges only in multiples of whatever ( 4 - 8 - 16- 32 >> Khz ) >> ( To put a limit on the calculations involved ) >> Low freq limit? Answer 32 >> High freq limit? Answer 48 >> Ask confirmation >> You want to zoom 32 to 48 ( Yes/No ) >> >> Enter ......... >OK. The zoom range depends on what window size is available and the bandwidth >of the hardware. There is no limit on the zoom range, Linrad will just pick >whatever zoom range that gives room for the desired range within the screen >space available. Surely, if you would try to ask for 32.000000 to 32.000001 >Linrad would not accept such a narrow range so it would not be possible >to type in something like that. > >> You now know how to start the display, where to stop the display and >> that the freq scale need to be multiplied by 6 ( 96/16 ) and everything in >> the >> waterfall needs to be scales along x-axis by this factor ) >> >> And frequency selections in the waterfall need to be scaled back to the >> original display or >> this might perhaps not even be needed. >> By now you know certainly where I am going. >> >> It looks from here not such a difficult thing to do and I think it would make >> the user interface so much more friendly. > >Thank you Rein. I will make some changes for the next version:-) > >73 > >Leif / SM5BSZ >
