Hi Leif, It is perhaps possible to turn the process around on the zooming business.
Instead of having the user select a full random zoom window and executing this in a framework of allowed or possible combinations, it is perhaps possible to develop from the parameters in use, to inform the user of possible zoom windows and let him or her select on from a lis allowed or provided numbers. In the waterfall:, let the user select the window center and provide standard selectable window widths around this center, for example and so on. >From the sound card sampling rate to the horizon display pixel numbers, there are likely simple fast relationships of possible ( powers of 2 or 10 ) which can be calculated and used for the suggestion of possible and/or only allowed zoom windows. I hate to suggest this There has to be a relative simple process scheme where it can be shown how the a selection of a parameter effects or limits the possibilities of other parameters. >From these combinations, one could possibly show a scheme how the selection effect the processing and the results. As the designer you clearly know what is possible and what effects what were. I think without real serious work it is hard for an user to figure this and understand it or be able to use is in the measurement or analytical processor what Linrad is in the end. While I sit and write all this here, I realize that all I am doing is is just suggesting the standards used in instrumentation! Nothing original but it happens to be the standard.. Hz / scale division V / sd Hours / cm windom width in Hz etc etc. The user can only select 1 -3 - 10 - 30 of whatever. It is a given. ( Philips numbers ) And I think form a design point of few it makes things simpler One could then say : Yes but by doing this it limits my flexibility" what might be true in a very limited number of cases. Just a thought 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 >
