w3sz | 1 Apr 04:17
Picon

Debian Etch and Linrad

Hi, All,

More on Linrad and Debian Etch.  This is just "for your information".   
Since I have 02.03 working I am OK and don't need 'help' with things at  
this point.

1.  The fatal error I get compiling linrad-01.35 with Etch [and gcc-4.0.3]  
is due to the fact that in the Makefile for linrad 01.35 on line 27 it  
says "--cref\" but it needs to say "--cref \".  When I make that change,  
then things compile with no errors.  OF course, everytime you type  
"./configure" it creates a new Makefile, and then you need to make this  
correction again.

2.  When I then run linrad-01.35, compiled as above, it locks up on the  
second parameter-setting screen for wcw or ssb with the error message:
Using VESA driver, 8000KB. VBE3
svgalib 1.9.24
svgalib:Signal 11: Segmentation fault received.
I can escape from this with cntl-alt-F7 and get back to my terminal window.

It is interesting that Linrad-02.03 produces no such errors with identical  
settings of the display parameters from within Linrad.

3.  Linrad-02.03 runs OK except for the 'clicking' I mentioned last night,  
and it won't let me pull [using the mouse] some of the boxes [e.g.  
polarization angle] around consistently.  Sometimes they will move,  
othertimes the mouse cursor disappears when I place it on an edge and  
nothing happens when I pull.  If I click things too fast Linrad gets upset  
and stops working properly.  That is, it locks up and won't accept further  
commands.  I can 'escape' with escape and restart Linrad again and all is  
(Continue reading)

w3sz | 1 Apr 20:48
Picon

Brief correction

Hi, All,

I said in an email yesterday that I had my c addon to Linrad working fine with Etch and Linrad-02.03.  That was
not quite correct.  

The addon worked fine with Linrad in mode "D" or SSB mode.  But today I was on the air and went to use it in mode "A"
or WCW mode, and it sent incorrect results to the FT1000.

As my addon just takes frequency data generated by Linrad with no regard to the mode Linrad is in this was
quite a surprise.  It suggests to me that there is something that has changed in an unanticipated  way in the
WCW coding in version 02.03 of Linrad.

I used to derive my frequency data like this:

/*
freqpre=fg.passband_center;
freqpre=freqpre*10E6;
freq=(mix1_fq_mid[fftx_nx]);
freq=freq*10;
freq=freq+freqpre-480000;
freq=freq*100;
*/
where fg.passband_center and mix1...are linrad variables.  This now gives erroneous results when in WCW mode.

I now derive my frequency data like this:

freqpre= hwfreq*1000000.0 ;
freq=freqpre;

where hwfreq is a linrad variable.
(Continue reading)

w3sz | 3 Apr 07:53
Picon

users_hardware.c correction

Hi, All,

It is late but I thought I would post this so I don't forget to do so.

For 'quite a while' I have put my addon routines directly in hwaredriver.c  
or more recently in users_extras.c because everytime I put anything in  
users.c renamed to users_hwaredriver.c I got error messages and a failure  
to compile.

I REALLY needed to implement Leif's nice window/parameter protype routines  
for an extra parameter window in Linrad, and these are in users.c, so this  
evening I got off my lazy butt and looked for the answer to the problem  
instead of just working around it.

The problem is solved with just a little change of the code.  It is due to  
a single misplaced "}", which needs to be removed from one line and added  
a few lines higher in the code.  I hope that I have placed the bracket  
correctly.  It compiles fine and so far the code seems to work reasonably  
well with the bracket placed as I have shown it.  The missing bracket was  
added at [or about] line 335.

Immediately below is a fragment of the corrected code, and below that the  
original code which needed correction:

corrected code:

if(mouse_x > ug.xleft+2*text_width && mouse_x<ug.xright-2*text_width)
   {
   if(mouse_y > (ug.ytop+ug.ybottom)/2)
     {
(Continue reading)

Robert McGwier | 3 Apr 16:38
Picon

Re: users_hardware.c correction

Man!

We are going to turn you into a software pro yet.  Watch out!  Linux 
tools provide you with an excellent way of distributing these kinds of 
changes:

diff tells the differences and these are supplied to patch and the code 
is immediately fixed up.

Bob
N4HY

w3sz wrote:
> Hi, All,
>
> It is late but I thought I would post this so I don't forget to do so.
>
> Immediately below is a fragment of the corrected code, and below that 
> the original code which needed correction:
>
> corrected code:
>
>
-----------   snip  --------------------------
>
> old [needed correction]:
>
>
-----  snip ---------------
>
(Continue reading)

w3sz | 3 Apr 19:16
Picon

Re: users_hardware.c correction

HI, Bob,

Cool!

Thanks very much for the note.  Very interesting, diff and patch.  I will check them out.  The funny thing is
that as I was preparing the email in the wee hours I thought to myself "there MUST be an easier way to document
and distribute 'fixes' like this".  And now you have shown me that there is! 

Thanks again.  I will check out diff and patch as soon as I get home from my day job ;)

Have a great week, and

73,

Roger
W3SZ

 -------------- Original message ----------------------
From: Robert McGwier <rwmcgwier@...>
> Man!
> 
> We are going to turn you into a software pro yet.  Watch out!  Linux 
> tools provide you with an excellent way of distributing these kinds of 
> changes:
> 
> diff tells the differences and these are supplied to patch and the code 
> is immediately fixed up.
> 
> Bob
> N4HY
(Continue reading)

Leif Asbrink | 8 Apr 13:12

Linrad-01.35 Makefile

Hi All,

The missing blank after --cref in Makefile is corrected in
Makefile.in now so a proper Makefile will be produced by
the ./configure command. I have replaced the lir01-35.tbz 
file with the corrected one. There is no change in the
code and the linrad executable becomes identical to what 
it was before.

73

Leif / SM5BSZ

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@...>.
To unsubscribe, E-mail to: <linrad-off@...>
To switch to the DIGEST mode, E-mail to <linrad-digest@...>
To switch to the INDEX mode, E-mail to <linrad-index@...>
Send administrative queries to  <linrad-request@...>

Leif Asbrink | 8 Apr 15:54

Re: Brief correction

Hi Roger,

> I used to derive my frequency data like this:
> 
> /*
> freqpre=fg.passband_center;
> freqpre=freqpre*10E6;
> freq=(mix1_fq_mid[fftx_nx]);
> freq=freq*10;
> freq=freq+freqpre-480000;
> freq=freq*100;
> */
> where fg.passband_center and mix1...are linrad variables.  This now
> gives erroneous results when in WCW mode.
The info in mix1_fq_mid[fftx_nx] is only valid when the AFC has
locked to a signal. In case AFC is deselected or the AFC failed
the data may be incorrect. The number 480000 is ui.sampling_speed/2
and it should be applied only in I/Q mode. 

> I now derive my frequency data like this:
> 
> freqpre= hwfreq*1000000.0 ;
> freq=freqpre;

This should be correct always. Linrad looks at the flags and selects
the frequency actually in use for conversion to the baseband and adds
the bfo offset 'bg.bfo_freq' in ssb mode.

Look at the routine 'frequency_readout' in baseb_graph.c. for
details.
(Continue reading)

w3sz | 8 Apr 23:34
Picon

users_hwaredriver.c added features

Hi, All,

I put a zip file and a tar file containing my Linrad users_hwaredriver.c  
file and some support files on my website at
http://www.nitehawk.com/w3sz/Lin-2-1000MP.htm

The page supplies some explanation.  To download, just go to the bottom of  
the page and click on 'zip.file' or 'tar file'.

Each archive file contains a copy of users_hwaredriver.c that includes:

1.  Leif's routines to control the WSE hardware

2.  my routine to take frequency data from Linrad and send it out the  
serial port to FT1000MP.

3.  Leif's routines for putting a user_window on the screen to allow entry  
of user_parameters while Linrad is running

4.  my modifications / additions to #3

These modifications are so that one can enter a frequency shift parameter  
[par2 in the program, labeled SH(Hz) in the user_window] using the  
user_window on the Linrad screen to fine tune the frequency sent to the  
FT1000 by #2, so that the FT1000 is brought to exactly the same frequency  
as the Linrad hardware [whatever that happens to be] so that should the  
Linrad hardware and the FT1000 and its transverter drift apart over time  
the resulting delta-f can be brought back to zero without having to  
recompile Linrad [which is what I had to do before adding this routine].

(Continue reading)

Leif Asbrink | 12 Apr 01:19

Linrad-01.36

Hi All,

Linrad-01.35 may crash when run under Debian Etch and ALSA. This
happens if the soundcards are set up incorrectly so ALSA reads
zero for every single sample. It is the zero noiselevel that
causes the crashes. This is fixed in Linrad-01.36 so reading
zero will just cause a zero spectrum.

 73

Leif / SM5BSZ

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@...>.
To unsubscribe, E-mail to: <linrad-off@...>
To switch to the DIGEST mode, E-mail to <linrad-digest@...>
To switch to the INDEX mode, E-mail to <linrad-index@...>
Send administrative queries to  <linrad-request@...>

Leif Asbrink | 12 Apr 01:40

Linrad-02.04

Hi All,

Linrad-02.04 is now uploaded. The multi-threaded version might still be
a bit unreliable, but I think it has reached a level where it could be
used on a regular basis.

This version can be compiled for X11 as well as for svgalib and
Windows. It also has support for the SDR-14 hardware under both 2.4.xx
and 2.6.xx kernels.

73

Leif

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@...>.
To unsubscribe, E-mail to: <linrad-off@...>
To switch to the DIGEST mode, E-mail to <linrad-digest@...>
To switch to the INDEX mode, E-mail to <linrad-index@...>
Send administrative queries to  <linrad-request@...>


Gmane