Next version.
Leif Asbrink
As it turns out, Linrad-03-34 suffers from some serious errors
altghough not quite as bad as some other versions after
03-27.
Before I upload linrad-03.35 I would like to know if there is any
other thing that I should correct. These are the current
issues:
1) Latency when second FFT is in use.
2) Spur removal.
3) Nice behaviour when ExtIO is selected and hardware is not present.
Is there something else?
73
Leif / SM5BSZ
stan...@aol.com
I have noticed this behavior for the second time this morning.
I just start linrad, having come back from the parameters menu== X-P and scroll through options but not changing any.
The Main waterfall appears and I see a signal at 144.206. Left click on the signal but do not hear it.
Looking in the High resolution spectrum I see the signal 5 kc lower than what I am seeing it in the waterfall?
I hit X to go back to par options and B to go back to SSB without changes
Now the Main spectrum That was showing a 20Kc band has changed to 5 khz
Linrad now receives the Main Spectrum==High resolution
Another Clue:
The T delay time chart was reading
D/A 0.032 Min .928
baseb 0.545 buf 0.992
Timf3 0.043 fft3 0.000
Tim2 0.213 fft2 0.000
Raw 0.021 fft1 0.000
Tot 1.982
The normal T delay time looks like this:
D/A 0.032 Min 0.007
baseb 0.004 buf 0.112
Timf3 0.043 fft3 0.000
Tim2 0.213 fft2 0.000
Raw 0.021 fft1 0.000
Tot 0.471
ESC and restart the program brought everything back to normal.
73, Stan
stan...@aol.com
The problem repeated again. This time the Delay times were normal.
esc out of program and start program gives me the reduced main spectrum window.
The signal matched in main spectrum and hi resolution.
I expand the main waterfall to 20 khz. esc out and go back in to linrad;
All is well now.
Stan
Leif Asbrink
The high resolution spectrum and the waterfall both display
the power spectrum of the second fft. Something seems to have
gone wrong when Linrad computed one or the other frequency
scales.
The fact that X followed by B changed the graph shows that
something was not right.
Maybe you could make a .bat file like this:
copy par*.* [a suitable directory]
linrad.exe
Then, next time you see this kind of error you can save the
saved parameters permanently and then start Linrad again
with the saved parameters. It might be possible that you
can repeat exactly what you did and thus make the error
happen again. Once that is possible I should be able
to find out what goes wrong.
73
Leif / SM5BSZ
stan...@aol.com
would you like to see my par_ssb ??
Stan
From: Leif Asbrink <le...@sm5bsz.com>
To: linrad <lin...@googlegroups.com>
Subject: Re: [Linrad] Next version.
stan...@aol.com
There is a problem with main spectrum frequency expand, shrink and right click to change center frequency.
Narrowing the box (10khz) and right click many times eventually make the display spectrum get very narrow. (2-3khz)
After moving center and expand contracting..............the right in arrow no longer moves the frequency range.... the left in arrow functions but the right in arrow does nothing..
after depressing the left out arrow ...the right in arrow functions again.
I don't know what par you want me to save?
I have been using Linrad all day and I have not changed any parameters..
I esc out and back in to program. The Main spectrum starts at only 4khz
Stan
Leif Asbrink
> Leif I do not understand... I have not changed any settings in par.
Yes, you have. The parameters in par_ssb_wg have been changed as a
consequence of some mouse operation on screen. Once it has happened,
the original file which caused the error is overwritten.
> would you like to see my par_ssb ??
No, I would need all the files as they were before Linrad started
and subsequently showed this error.
There are a couple of complications hidden in the main spectrum.
The waterfall is from fft2 but the spectrum is from fft1.
You could zoom in for fft1 to have say 5 pixels between two sucessive
points in the power spectrum. Linrad would place pixels on a straight line.
In case you have fft2 16 times longer you would have 16 data points
for those 5 pixels. 16 does not go even in 5.
In this case the spectrum has to have a width that is a multiple of 80
pixels. Both 5 and 16 go even in 80:-)
The spectra are characterized by "pixels per point" or "points per pixel"
whichever is 1 or above. That is to avoid any rounding errors.
Today I would have written the code differently, using double precision,
but the code is very old.
It is very odd that I have never seen this and that nobody has reported
it before. It could be a new bug that I have introduced by mistake.
With some luck it would not be present in 03-45.
73
Leif / SM5BSZ
Leif Asbrink
> There is a problem with main spectrum frequency expand,
> shrink and right click to change center frequency.
>
> Narrowing the box (10khz) and right click many times
> eventually make the display spectrum get very narrow. (2-3khz)
This is by far not precise enough for me.
I guess you have 96 kHz sampling rate and 50 Hz bw for fft1
and second fft bw factor in powers of 2 set to 4.
Narrowing the box, do you grab one side and make the horizontal
size of the box smaller? How many pixels do you set it to?
Exit Linrad and look in par_ssb_wg
xleft [0]
xright [781]
The numbers are the positions of the vertical lines.
In this case the width is 781 pixels.
> After moving center and expand contracting..............
????????
How does your par_ssb_wg look like after this?
the right in arrow no longer moves the frequency range.... the left in arrow functions but the right in arrow does nothing..
>
> after depressing the left out arrow ...the right in arrow functions again.
>
> I don't know what par you want me to save?
>
> I have been using Linrad all day and I have not changed any parameters..
Yes, you have. Each time you click an arrow box or resize something you
change a parameter file:-)
Something that you do creates an illegal parameter combination.
That should not happen (of course)
> I esc out and back in to program. The Main spectrum starts at only 4khz
If the screen looks different after you did esc and restart, the restart
changed some parameter because it had an illegal value. There must be
something I forgot to test for that can go wrong when you click the boxes.
If you can repeat this last thing.
ESC
save par_ssb_wg
restart (and do not click anything)
save par_ssb_wg again.
In case the screen has changed due to the restart the explanation
should be visible in the difference between the files.
73
Leif
stan...@aol.com
I changed the Arrows Right side IN and OUT + Left side IN and OUT + RIGHT CLICK (to change waterfall center) until the Right side IN arrow no longer functioned.
I ESC program and this is file:
ytop [0]
ybottom [122]
xleft [0]
xright [777]
yborder [40]
xpoints per pixel [0]
pixels per xpoint [8]
first xpoint [50]
xpoints [146]
avg1num [1]
spek avgnum [45]
waterfall avgnum [100]
spur_inhibit [0]
check [6660024]
yzero [6.498019218444824]
yrange [32768.000000000000000]
wat. db zero [19.000000000000000]
wat. db gain [0.500000000000000]
I restart program select D and ESC program now file looks like this:
ytop [0]
ybottom [122]
xleft [0]
xright [767]
yborder [40]
xpoints per pixel [0]
pixels per xpoint [16]
first xpoint [50]
xpoints [45]
avg1num [1]
spek avgnum [45]
waterfall avgnum [100]
spur_inhibit [0]
check [6660024]
yzero [6.498019218444824]
yrange [32768.000000000000000]
wat. db zero [19.000000000000000]
wat. db gain [0.500000000000000]
From: Leif Asbrink <le...@sm5bsz.com>
To: linrad <lin...@googlegroups.com>
Russ K2TXB
versions of Linrad. I always figured I just did not learn how to use it
properly and did not bother to report it. But I was interested in your
comment:
> The spectra are characterized by "pixels per point" or
> "points per pixel"
> whichever is 1 or above. That is to avoid any rounding errors.
Yes, I remember fighting with that issue when I was working on my windows
version of Linrad (converted to use regular Windows windows). My problem
was that I did not understand the requirements well enough to make any
significant changes, so I had to try to duplicate your functions - but I was
writing object orientated code so it was difficult to make it fit well.
Somehow I eventually managed to screw it up to the point where the displays
did not work well anymore. I was unable to understand what I did, and did
not have an interim copy to revert to, so I kind of gave up at that point.
> Today I would have written the code differently, using double
> precision, but the code is very old.
Maybe that would be a good thing to do anyway???
73, Russ K2TXB
> -----Original Message-----
> From: lin...@googlegroups.com
> [mailto:lin...@googlegroups.com] On Behalf Of Leif Asbrink
> Sent: Saturday, February 11, 2012 11:38 PM
> To: lin...@googlegroups.com
> Subject: [Linrad] Re: Next version.
>
Leif Asbrink
The first file is in error.
I can not reproduce it here, it may depend on a lot of things
that determine how the screen is organized.
Please make sure that you have a copy of your setup so you
will be able to do the same thing again. I will add write
statements to make Linrad produce a debug file that hopefully
will tell me what goes wrong.
This error could disappear if you change the percentage of the
screen width to use or have another box at the side or use
a different font size.
When you saved the file the error had already happened.
Linrad tries to rescue the situation and produces something
that is acceptable - but not quite what you want...
73
Leif / SM5BSZ
w6sz
Hi Leif,
On the next version issue.
In addition to existing display modes and routines selection.
I wonder whether you could add an option where the user could, during
setup, define
a variable DW, such as number of frequency units / pixel ( could be Hz
of KHz )
This, plus some test control structure based upon standard screens and
integer values for DW.
After the user selects this number the variable will become a constant
until user
changes the value.
This selected display variable would be used strictly for final
displaying results.
Zooming could be limited to simple factors around selected center
frequencies
in the primary display. Window center frequency selection by mouse,
and if possible
zooming also by mouse.
It would not have be as complicated as here I think:
http://en.wikipedia.org/wiki/Display_resolution
example:
96 KHz / 1024 pixels -> 96 Hz / pixel
48 Hz
24 Hz
12 Hz
6 Hz
etc if required.
Center of measured window could be selected up front also and it would
take care of frequency displays.
If required, standard sampling rates could be also be selected at
start up ( is already in place )
All this would only effect displaying results and would remain fixed
during other actions by the user.
Without going into more details, I am sure you know what the issue is
here and I do not think
it is not the computer any more. It would make LINRAD appear in the
list of SDR programs more often.
Avoiding statements about installing MAP65 for a FunCube Dongle, like
"You can keep the Linrad program or
throw it away, we don't use it"
75 Rein W6SZ
Leif Asbrink
> On the next version issue.
>
> In addition to existing display modes and routines selection.
>
> I wonder whether you could add an option where the user could, during
> setup, define
> a variable DW, such as number of frequency units / pixel ( could be Hz
> of KHz )
> This, plus some test control structure based upon standard screens and
> integer values for DW.
?????????????
I do not understand.
> After the user selects this number the variable will become a constant
> until user
> changes the value.
>
> This selected display variable would be used strictly for final
> displaying results.
>
> Zooming could be limited to simple factors around selected center
> frequencies
> in the primary display. Window center frequency selection by mouse,
> and if possible
> zooming also by mouse.
I do not understand what you want to achieve with this parameter.
> It would not have be as complicated as here I think:
>
> http://en.wikipedia.org/wiki/Display_resolution
??????????????
> example:
>
>
> 96 KHz / 1024 pixels -> 96 Hz / pixel
> 48 Hz
> 24 Hz
> 12 Hz
> 6 Hz
>
> etc if required.
Can you tell me what problem you have with the
current user interface. What is it you want to do
that you find problematic with the current interface?
> Center of measured window could be selected up front also and it would
> take care of frequency displays.
Well, Linrad can be used for great many different purposes.
It is unclear to me what you want to do.
> If required, standard sampling rates could be also be selected at
> start up ( is already in place )
Linrad doer NOT assume that you are limited to "standard" sampling rates.
On the contrary. Linrad assumes that you, the operator, know what sampling
rates your hardware can supply.
> All this would only effect displaying results and would remain fixed
> during other actions by the user.
?????????????
That depends. I have no idea what you want to do and whgy so I can
not be very specific.
> Without going into more details, I am sure you know what the issue is
> here and I do not think it is not the computer any more.
No. I do not know what the issue might be.
I am fully aware that many radio amateurs think an SDR software
must be configured to meet their particular personal interest.
I can not respond to such demands without detailed info and
possibly recorded wideband files.
> It would make LINRAD appear in the
> list of SDR programs more often.
> Avoiding statements about installing MAP65 for a FunCube Dongle, like
> "You can keep the Linrad program or
> throw it away, we don't use it"
Well, someone who has a good RF environment without QRN
does not need Linrad. There are other softwares that can
supply data to MAP65 via the network.
Those who have problems can use Linrad. There is a requirement
that they have to accuire some understanding about what the
software is doing and why.
I am of course interested in making Linrad more widely used.
I just do not understand what you suggest me to do and why.
73
Leif / SM5BSZ
Leif Asbrink
> Hi Leif. I have seen the problems Stan is reporting on some very older
> versions of Linrad. I always figured I just did not learn how to use it
> properly and did not bother to report it. But I was interested in your
> comment:
>
> > The spectra are characterized by "pixels per point" or
> > "points per pixel"
> > whichever is 1 or above. That is to avoid any rounding errors.
.
.
.
> > Today I would have written the code differently, using double
> > precision, but the code is very old.
>
> Maybe that would be a good thing to do anyway???
Sure, but it would be a fairly time-consuming thing.
I do not feel like doing it myself. There are many
interesting problems with SDR algorithms in interference
fighting that I think I better spend my time on.
The spectrum display is uninteresting to me.
Actually it would have been better if I had not allowed for
any zoom. The graph should always show the full bandwidth.
That is: Anyone using Linrad as a receiver should set the main
window to show the entire spectrum. The reason is that the user
needs to be aware of what strong signals he has in his passband.
The information (red vs white pixels) should be used to set
the noise blanker controls properly.
I have allowed people to zoom in on the main spectrum/waterfall.
That was undwer the assumption that they would know why they
would want to do that.....
73
Leif / SM5BSZ
Earl Shaffer
Leif Asbrink
A few things only:
> As he suggest's, I simply keep it full width now.
> (the main sperctrum and waterfall)
> Personally, I would like a
> restore button that I could push in case I ruin Linrad during a session and
> can not fix it. The
> restore button would return Linrad parameters to what they were during the
> start of the session.
Make a .bat file:
copy C:\whatever\par*.*
linrad.exe
(in your linrad directory)
This way you will start with the same parameters until you are
happy with something better. Once that happens you should type
copy par*.* C:\whatever
(in your linrad directory)
> I'll bet a separate program that would launch Linrad could be made to do
> that. The
> thing I don't like is that if I ruin Linrad and restart it, Linrad
> remembers my error :(
Linrad is old-fashioned and it assumes that you are aware
of the basics of the command window...
> I would prefer that it start the same way every time. I would
> also prefer that if I find a setup
> that I especially like, then I could save the parameters under a new name
> that relates to my
> purpose.
As a user you can easily do that. With .bat files:-)
> I think what might be useful to people (especially novices) would be a
> library of parameters
> that could be downloaded and used. Each set of parameters would have a
> unique name
> and a few paragraphs explaining the purpose and unique hardware it is used
> with.
This is a good point, but I do not have all those hardwares
and I do not know what those new users might want to do.
> Much can
> be done by trial and error, but when understanding is lacking and variables
> are numerous,
> trial and error can be ineffective. The good thing about Linrad is that it
> can be used for nearly
> any purpose. The bad thing about Linrad is that it can be used for nearly
> any purpose.
This is the reason why many radio amateurs find other SDR softwares
better (=easier to use)
There is not much I can do about this. I try to make it easier to understand
what Linrad is doing and why. Those who are happy with a simple receiver
should use something else. Winrad, HDSDR or whatever.
I develop Linrad to allow amateurs to experiment with new DSP algorithms.
Those who have interference problems that Linrad does not have algorithms
for could use some other (=more user friendly) SDR package.
Linrad is free code. In case something that I do turns out to be
really useful you will find it incorporated in other SDR packages
(presumably much more user-friendly) in the near future.
"when understanding is lacking and variables are numerous trial
and error can be ineffective"
This may be true, but those operators who have a basic understanding
of the physics may find trial and error reasonably efficient....
73
Leif / SM5BSZ
'
VK2KU
I have enjoyed playing with Linrad settings over some years.
Each time I learn a little more, but not too quickly to absorb it.
I like being able to optimize it for my setup,
even if that is sometimes difficult to grasp.
However we have all had difficulty with the main spectrum window,
and it is sometimes possible to box yourself into a seemingly
impossible situation from which it is difficult to recover.
I for one would have no problem with the main window always
displaying the full spectrum width - I always use it that way anyway.
Currently running v3.34 with no issues so far.
73 Guy VK2KU
Russ K2TXB
the spectrum display in a regular window that one could grab and drag to
anywhere on the screen, or even onto the screen of a second monitor. It
also could be resized to any size the user wanted. Since the class for that
window contained all of the code for displaying the spectrum, the code would
automatically recalculate the parameters needed to show the same, selected,
bandwidth for whatever size the user resized to. I actually had this
working. I could grab the corner of the window and 'spin' around with the
mouse, fast, constantly resizing the display and it would keep up with me
and change the display as I 'spun'. In fact that was the test I used to
eliminate some bugs that could cause the program to lock up when resizing.
I thought that was a pretty good way, but then later I changed something
else and the display got all 'spiky', instead of rounded edges, and the
decoded audio was also distorted. I never could figure out how to fix it,
and I would have had to go so far back to get a working version that I just
could not justify the time to start over. So I gave up. It was mostly an
academic exercise anyway,
And I know you are not interested in providing such UI features yourself. I
had it in mind that if I got it all working well, I could provide the code
to you in a DLL or OCX file that could be plugged in to your program. But I
never got that far.
However your comment about not allowing bandwidth narrowing made me think
about people like Stan and Roger who want to view very weak signals. Don't
they need to narrow the spectrum for best results?
73, Russ K2TXB
> -----Original Message-----
> From: lin...@googlegroups.com
> [mailto:lin...@googlegroups.com] On Behalf Of Leif Asbrink
> Sent: Sunday, February 12, 2012 8:00 PM
> To: lin...@googlegroups.com
> Subject: [Linrad] Re: Next version.
>
stan...@aol.com
I prefer a window that has 10-20khz;
My Hi resolution display is not wide enough
73 Stan
w6sz
Let me try to address some of the points.
- I do not Understand -
-- I am sorry seeing you making this statement:
"There are other softwares that can > supply data to MAP65 via the
network."
precise than I did.
It is about the what is being called, the GUI, Graphics User
Interface.
From the very beginning of Linrad, years ago I have felt not to be in
control
of the displays. Not only that, if I do something , call it stupid,
there is often,
as far as I know, no way back, often just remove the software, and
reload a
fresh copy in the hope to avoid the the wrong action or find a way
around it
and avoiding the previous mistake.
From what I have seen on the Linrad reflector(s) over many years, I
know I am
certainly not the only one, experiencing this.
It has little or nothing to do with the processing of signals,
physics, radio, or
anything Linrad is about, It might have to do with a certain lack of
understanding,
So be it.
I do not want to talk for others, but it seems we understand that for
reasons I
appreciate and other do as well that fixing this is not high on the
list.
Again, I understand and appreciate that point of view.
Just for the fun of it, I like to go back to the old days were people
used pen recorders with ink.
Most of these had a span control, perhaps a calibrated gain control, a
paper speed control,
A way to set the base line, and so on. If something real interesting
happened on a trace, one could
perhaps cut out "the event" and use some other tool to study it more
closely.
You are a physicist and I do not have to go further on this track.
It is like the scientist in the lab, who is totally interested in the
ongoing experiment and
thinks I don't care at this point whether the pen is without ink and
long as it flows when the
event happens and I can take note of it.
Enough of this. I was trying to suggest some simple changes in the the
existing GUI to fix
some of the problems or better weak points.
No continuous changing of windows, just limited selections, very
limited windowing for limited
frequency bands. simple frequency calibration, signal strength or S/N
axis, base line shifting
with slider, Basic window seize selected as fixed and a few other
improvements.
I don't expect fancy windows, SDR and spectrum analysis is at a point
now where the appearance
of the software has reached a competitive level and users or customers
make buying decisions
on the looks of the program.
This is not what I am talking and asking about. I am just asking about
really basic functionality
of the display(s) and that errors made with the display mess up the
operation.
This is not criticizing or complaining. I have the fullest respect for
what you are doing and always
have. It is just trying to help make your work more available to users
( and myself )
The point is is there a way to do something about improving the
situation
,
The question was really what are the limitations of frequency /
pixel in Linrad .
The point is is there a way to do something about improving the
situation
Where do you stand on this?
Perhaps in this group people could find time to help out with this. I
believe Roger
has made changes in his versions, Russ K2TXB, obviously has worked
quite a bit in this
direction. There are others as well.
I could make time available, ( Not sure I am the right guy though ) if
you could help with
the software development tools. I am sure there would be others.
If nothing else, I could compose a start up page with questions about
display variables that
were to be used during the session. Many of these variables are in
use already, but are
hard to find and/or change or to set as a constant for that session.
Are these variables global, what are the consequences if one starts
changing things. What
about rounding off, etc etc.
I have asked you before as I would like to avoid bad feelings and
misunderstandings, to have
a talk as an exchange,
For instance: http://www.skype.com/intl/en-us/get-skype/on-your-computer/linux/
( Having talks with my former boss in Ekero every couple of days via
Skype. )
73 Rein W6SZ
Leif Asbrink
> Hi Again Leif. Ok, I understand your sentiment. What I had done was make
> the spectrum display in a regular window that one could grab and drag to
> anywhere on the screen, or even onto the screen of a second monitor. It
> also could be resized to any size the user wanted.
Well, I skipped all development in that direction for performance
reasons. The hardware I had access to could not do anything
useful through the Windows API. It was horribly slow.
The simple fix I adopted was to emulate svgalib in Windows as well
as Linux X11. For many years the only way to get decent performance
was to use svgalib in terminal mode. In recent years hardwares have
become faster and Windows as well as X11 much better so today
it is different.
> Since the class for that
> window contained all of the code for displaying the spectrum, the code would
> automatically recalculate the parameters needed to show the same, selected,
> bandwidth for whatever size the user resized to. I actually had this
> working. I could grab the corner of the window and 'spin' around with the
> mouse, fast, constantly resizing the display and it would keep up with me
> and change the display as I 'spun'. In fact that was the test I used to
> eliminate some bugs that could cause the program to lock up when resizing.
> I thought that was a pretty good way, but then later I changed something
> else and the display got all 'spiky', instead of rounded edges, and the
> decoded audio was also distorted. I never could figure out how to fix it,
> and I would have had to go so far back to get a working version that I just
> could not justify the time to start over. So I gave up. It was mostly an
> academic exercise anyway,
>
> And I know you are not interested in providing such UI features yourself. I
> had it in mind that if I got it all working well, I could provide the code
> to you in a DLL or OCX file that could be plugged in to your program. But I
> never got that far.
It should not be difficult at all to add a routine in users_hwaredriver.c
that could send pointers to the appropriate linrad data to a dll each time
the data has been changed. In case someone supplies such things it would be
easy to disable the corresponding window in Linrad. It would be possible
to have several windows zoomed on different frequencies etc.
> However your comment about not allowing bandwidth narrowing made me think
> about people like Stan and Roger who want to view very weak signals. Don't
> they need to narrow the spectrum for best results?
"best results"???
That depends on what they want to do. There are too many scenarios
for me to try to outline them all here. Just a couple of things:
1) Display the full bandwidth in the main spectrum. That is necessary
to know what goes on with the noise blanker. Zooming the main
spectrum is intended for test and measurement and not for signals
arriving from an antenna. (Those who know that they never have
any strong signals or who do not need any noise blanker can of
course run Linrad with a zoomed main window.)
2) If you want to see really weak signals in the full bandwidth it
is necessary to use very big FFTs that cause a very long delay.
In such cases, use a master instance of Linrad to do noise
blanking and to produce loudspeaker output. Use another instance
of Linrad to produce the full spectrum with slow processing.
(There are several different ways of doing this. Send raw, fft1
or timf2 data.)
3) If you want to zoom to some particular frequency range, click
whatever center frequency you like and set the baseband parameters
for optimum visibility of the signal(s) you are interested in.
It is possible to use watzo on big waterfalls to get immediate
zoom and a possibillity to look at the waterfall with all different
polarizations in case a X-yagi is used.
watzo is a small program. It only receives fourier transforms and
stores on the hard disk. Data is also stored as averages so
the user can scroll left/right for frequency and up/down for
time and also change the polarization. All with immediate response.
Also zooming in frequency is fast but zooming in time is slow.
All averages would then have to be recomputed.
In case you or someone else could make a more user-friendly
version of watzo I think it could be a nice dll that could
be linked into all the SDR softwares fairly easily:-)
73
Leif
Leif Asbrink
> Let me try to address some of the points.
>
> - I do not Understand -
>
> -- I am sorry seeing you making this statement:
>
> "There are other softwares that can > supply data to MAP65 via the
> network."
Those who do not want to understand how to use the Linrad blanker
do not need the Linrad blanker. They could use SDR Radio or something
else.
> It are basically the same concerns others have expressed, perhaps more
> precise than I did.
>
> It is about the what is being called, the GUI, Graphics User
> Interface.
>
> From the very beginning of Linrad, years ago I have felt not to be in
> control
> of the displays. Not only that, if I do something , call it stupid,
> there is often,
> as far as I know, no way back, often just remove the software, and
> reload a
> fresh copy in the hope to avoid the the wrong action or find a way
> around it
> and avoiding the previous mistake.
But that is horrible. I have written hundreds of times the following
simple thing:
Save the files par*.* to some separate directory.
Then go on and play with parameters and do whatever things
that could be of interest. If you do not like the result
of your changes, just copy back the par*.* files from
where you saved them.
There is always a way back unless you found a bug. Linrad is
surely not bug-free but the number of bugs is slowly decreasing.
If you would report the ones you find you would help making
things better:-)
Now to the real thing, what is it you ask for? I do not understand
the DW thing you refer to. Changing the x-axis is not a trivial thing.
First priority is to retain the best possible visibility. Make a
screen dump and then use standard resizing of the image and you will
find that weak signals disappear if you resize with standard tools.
Resize is not a continuous thing, the X scale is not something we can
change arbitrarily.
> From what I have seen on the Linrad reflector(s) over many years, I
> know I am certainly not the only one, experiencing this.
>
> It has little or nothing to do with the processing of signals,
> physics, radio, or
> anything Linrad is about, It might have to do with a certain lack of
> understanding,
> So be it.
I appreciate feedback. Linrad is quite a bit more user-friendly
today than it was 5 or 10 years ago. The way you decide to just reinstall
everything when you find yourself in a situation that seems
impossible to recover from does not help anyone. You could
post a description of what you did and why. Maybe you have
detected a bug, maybe there is a trivial misunderstanding that I
could eliminate by changing something in the user interface.
> I was trying to suggest some simple changes in the the
> existing GUI to fix some of the problems or better weak points.
>
You have to be much more verbose. I do not understand what you are
after and why.
> No continuous changing of windows, just limited selections, very
> limited windowing for limited
> frequency bands.
This seems to me to be a very complicated thing.
There would have to be some setup facility that defines what windows
a particular user might want. I do not understand the idea
behind this suggestion - what would be the purpose of this
change?
> simple frequency calibration,
Hmmm, there are many types of hardwares. They have to be calibrated
in different ways. I do not want to build that complexity into
Linrad. As new hardware platforms become available with different
calibration requirements I would run into a problem keeping the
software up to date.
> signal strength or S/N axis,
????
Do you want something beyond the S-meter graph? What and why?
> base line shifting with slider,
Well, this would be nice, but I feel it is not worth the time.
There are the up/down arrow boxes. In Linrad I use another
terminology. It is the zero-point of the dB scale that could
be changed in a more user-friendly fashion. Also the gain,
pixels/dB.
> Basic window seize selected as fixed and a few other
> improvements.
The way the user can rearrange the screen is clumsy. The idea
is however that the screen should not be changed. The user should
set parameters to fit his hardware and some mode of operation.
Then he should leave the windows as they are.
> I don't expect fancy windows, SDR and spectrum analysis is at a point
> now where the appearance
> of the software has reached a competitive level and users or customers
> make buying decisions on the looks of the program.
Well, I am not going to try to compete. Surely other programs
look "more professional" with an image of a radio on the screen etc.
The big failure is that I have not been able to get SDR owners
send me raw data files from difficult situations that they have
on the bands. Files I could use as examples of what can be done with
Linrad.
The purpose is not to make everyone use Linrad. I think there are still
situations where performance (ability to copy weak signals) differs
significantly between Linrad and other SDR alternatives. I am pretty
sure such differences would disappear when the developers of other
and more user-friendly softwares become aware of it.
> This is not what I am talking and asking about. I am just asking about
> really basic functionality
> of the display(s) and that errors made with the display mess up the
> operation.
The problem is that Linrad has its own graphics. svgalib ported to
windows and X11. It is non-trivial to change things. (I think)
One would have to use something that is supported under Linux as well
as under Windows and that does not destroy performance.
> This is not criticizing or complaining. I have the fullest respect for
> what you are doing and always
> have. It is just trying to help make your work more available to users
> ( and myself )
>
> The point is is there a way to do something about improving the
> situation
> ,
> The question was really what are the limitations of frequency /
> pixel in Linrad .
Practically there is no such limitation.
The fundamental limitations are:
Frequency range maximum is the bandwidth that the hardware supplies.
The narrowest window would be 128 pixels wide so you can
have up to about 15 kHz per pixel (with a Perseus at 2 MHz.)
Frequency range minimum is given by the longest time a transform
can be allowed to span. Something like 0.003 Hz per frequency
bin. You can display the bins with straight lines, 16 pixels
per bin for a minimum of about 0.0002 Hz per pixel.
It would be trivial to allow wider limits, nobody ever asked for that.
> The point is is there a way to do something about improving the
> situation
>
> Where do you stand on this?
Well, I think Linrad is misunderstood by most users. I have
designed it to leave all possibillities open and that makes
it possible to do stupid things. The user may have very
good reasons to do things that would not be sensible if I had
made the assumption that Linrad should be used as a radio
receiver.
I have introduced a newcomer mode that should be helpful
in order to get an understanding of the basic functionality.
> Perhaps in this group people could find time to help out with this. I
> believe Roger
> has made changes in his versions, Russ K2TXB, obviously has worked
> quite a bit in this
> direction. There are others as well.
Yes. I am generally happy to incorporate everything in Linrad.
Some things in the standard package, other things via the
(w)users_xxxx modules.
> I could make time available, ( Not sure I am the right guy though ) if
> you could help with
> the software development tools. I am sure there would be others.
It is extremely easy to install the Linrad development environment
and to compile from source. You can add a module wusers_hwaredriver.c
and run configure, then make. That is all.
Prototypes in users.c, users_tr.c and users_w3sz.c You can
of course install dll files and call other programs from your code.
> If nothing else, I could compose a start up page with questions about
> display variables that
> were to be used during the session. Many of these variables are in
> use already, but are
> hard to find and/or change or to set as a constant for that session.
??????????????
> Are these variables global, what are the consequences if one starts
> changing things. What
> about rounding off, etc etc.
Well, I do not understand what you would want to do. It would be
an easy thing to write a little program that would set all the parameters.
Everything is in plain text files named par_*. There are rules within
Linrad that make certain parameter combinations forbidden. You are not
allowed to tell Linrad to use more than 100% of the screen size and
a bandwidth must not be negative etc.
I know Gaëtan ON4KHG is writing a Linrad manual. I think it would be a very
good idea if you read that first.
I get a feeling that you have clicked the arrow boxes at the top
of the main waterfall without using the F1 help for the boxes first.
> I have asked you before as I would like to avoid bad feelings and
> misunderstandings, to have a talk as an exchange,
>
> For instance: http://www.skype.com/intl/en-us/get-skype/on-your-computer/linux/
>
> ( Having talks with my former boss in Ekero every couple of days via
> Skype. )
I am now in Puerto Plata with very poor Internet access.
I have a feeling it will not be possible to talk in a meaningful way.
Back home, in the beginning of April, I will be happy to discuss
anything that you would find relevant.
I have registred with Skype, but I do not know how to use it
and whether my Internet connection would make it meaningful.
It seems bad, my connection (WLAN) crasched when i tried to
enable it. Typically it takes 12 to 18 hours before
they reset things here so now I am delayed until tomorrow:-(
I can not say for sure it was because of Skype, it happens
now and then...
73
Leif
w6sz
Let me start to thank you for your effort to get certain details to my
head. I really appreciate it and in addition to that, I like to
apologize
for a few remarks I made in the first email.
There is in particular one very bad oversight on my site and that
is the creation of all those par*.* files during the first run after
with " W "save..
I was aware of a few, it came up in the networking and indeed I have
seen many a time your request to send one or more of those
files, But here again I had the wrong impression that those were
specific
for the processing part and the mode definitions. Never made the
connection
the display details ( other than % screen and so on )
By looking into a installed directory I saw how many there are!.
So If I done more home work before asking the question, you know the
rest.
I also have nor really kept up with a lot of the new information that
you have
added. ( Again, why don't you read the manual? Sorry.)
So over the next couple of days,I am going to the new text from the
start and see
what will happen.
May be mentioning the approach with the the parameter files and the
extent of it,
could be valuable for some. It is an excellent approach for debugging
and
problem solving,
So once more, thanks for the e-maill and I hope to return to the
subject.
When it comes to Skype, I don't think the network requirements are
extreme
but they are most likely not present where you are at the moment, And
a bad network
connection is enough to to turn one off on Skyping for the rest of
one's life.
Have experience with this for relatives!
But I hope to be able comes April, to do it and clear up a few points.
73 Rein W6SZ
Leif Asbrink
> So over the next couple of days,I am going to the new text from the
> start and see what will happen.
Beware that the information is mostly out-dated. I try to focus
on principles when describing things because the details are
changing contnuosly.
There has been a somewhat turbulent time with Linrad in versions
03-27 to 03-44 with old errors that did not cause problems
suddenly popped up and became fatal as I made some small changes
to allow Linrad to run on Macintosch.
I am still collecting feedback on the errors in 03.44 and at the
moment there is a single unresolved problem that manifests itself
as different timing in SSB mode depending on what mode was used
before. Such a thing is an obvious bug, but I have not yet
reproduced it.
> When it comes to Skype, I don't think the network requirements are
> extreme
> but they are most likely not present where you are at the moment, And
> a bad network
> connection is enough to to turn one off on Skyping for the rest of
> one's life.
> Have experience with this for relatives!
Well, I tried Skype from home - and it seems to work reasonably well.
I will try it again from here but I do not have much hope. I will do it
some time when it would not matter if I loose Internet connection
for 12 hours:-)
> But I hope to be able comes April, to do it and clear up a few points.
There are many things that could be done more conventional and
user friendly under Windows. One could open new windows and set
parameters from them. I do not know how to write such code, but
I know it would not be difficult to someone who is familiar to
the windows programming style. In principle, let the user set
frequencies spans, scales, whatever, by rulers or boxes with number
(or both) and call the make_window function for the appropriate window.
From my perspective nothing would be gained by that, but it
might be more explicit and help users understand the relation
between different parameters and perhaps it would make it easier to
get used to Linrad.
Opening a set of superfluous windows that the user could use
or minimize would not affect performance at all so I would
be happy to add it if someone would supply the code:-)
73
leif / SM5BSZ
w6sz
Thanks again and I am all with you. Great!
Understood that the program's capacities should not be
effected with the user interface changes. And given the fact that
there are only so many hours in a day etc. No problem.
I will have a hard look at the parameter files and try to correlate
the named parameters with the real functions and so on in the program.
I personally would not mind making all changes direct via parameter
file interaction. Of course not using any of the present controls
would go
quite a way towards that. But in order to get a good understanding
what
the effect is of a given change is one would not want to change the
basic processing, just interrupting it.
I would like to see ( and wished could program that ) a way to stop
the program temporary like an interrupt. The interrupt leading
to a new parameter controlling program. I think if you could
add that, then others inclined to do that, could work on the
parameter control / settings function.
Parameter interrupt allows for changes to made stops and saves
all vital stuff , when parameters changed, Linrad returns to the
signal
programming of course there would be a price to pay, the loss of
processing
during the parameter changing.
Or perhaps this could be kept to bare minimum
When in real use, parameter changing would be virtually non existent
of course and Linrad's operation not effected.
A lot of this is already in place I think, with the callable help and
information pages.
Does this make any sense?
73 Rein W6SZ
Leif Asbrink
> I would like to see ( and wished could program that ) a way to stop
> the program temporary like an interrupt. The interrupt leading
> to a new parameter controlling program. I think if you could
> add that, then others inclined to do that, could work on the
> parameter control / settings function.
I do not really understand what you want to do and why.
Some parameters affect the memory organization and others
determine which processes to involve or skip. A simple interrupt
will not work for those. That is why the user has to stop
processing by pressing "X" and then he can change such parameters
either by another "X" and then through the "U" menu from
where the interface to the hardware is controlled or by
pressing "P" to set the fixed mode parameters that control
memory allocation and program flow.
> Parameter interrupt allows for changes to made stops and saves
> all vital stuff , when parameters changed, Linrad returns to the
> signal
> programming of course there would be a price to pay, the loss of
> processing
> during the parameter changing.
> Or perhaps this could be kept to bare minimum
If you could specify what you want to do and why I wold be able to
tell you what options there are.
Some parameters can be changed without stopping any processing.
Others require a call to pause_thread(THREAD_XXXXXXXXXX) with
a resume_thread(THREAD_XXXXXXXXX) once you are finished.
You could add a routine in which you reorganize the screen
by specifying screen coordinates. Your program could make all
consistency checks necessary. Then when you would press
"Apply," your program could pause the screen, erase the screen,
and replace all parameters with your new set.
There are a couple of not very difficult things needed
to redraw all the windows with the new parameters.
then your program would have to call resume on the screen
thread.
My problem is that I do not understand what you want to
do and why.
> When in real use, parameter changing would be virtually non existent
> of course and Linrad's operation not effected.
>
> A lot of this is already in place I think, with the callable help and
> information pages.
>
> Does this make any sense?
Not really;-)
If you make a fresh Linrad install and select "Newcomer" you get
a conventional SDR program with a limited number of extensions
but with a non-conventional user interface. I would be very
interested to know where you find the first obstacle.
You would have started Linrad with some specific idea about
what you want. There is a much wider range of possible such
ideas than you can imagine. If you can describe what you want to
do and how far you have reached before you encounter something
that does not seem logical and obvious you might point me
to some problem I never thought about.
73
Leif