[linrad] Re: MAP65 compiling
Hi Alberto and all, Alberto E. Zagni (I2KBD) wrote: I have just a couple of questions about current MAP65 compiling status: - Is MAP65 currently only working on Windows platform? MAP65 runs under Windows and Linux. A packaged executable (version 0.8, r502) is available on the WSJT Home Page for Windows. You must compile it yourself for Linux, from the source code. - Did you cross compile MAP65.EXE under Linux or directly on Win? I compile the Windows executable under Windows. My development setup uses the Microsoft VC6 and Compaq Visual Fortran compilers on Windows. These compilers are somewhat dated and not widely available, and it would be good to convert to using the GNU compilers, either directly on Windows or cross-compiling under Linux. I have not yet done this. - What's your plan for a (beta) release of source code to play with? The MAP65 source code has been freely available for nearly a year, as the program develops. It is located in the same Berlios repository as WSJT. The easiest was to download the full source code for MAP65 is to install the program Subversion and then type svn co https://svn.berlios.de/svnroot/repos/wsjt/branches/map65 at a command prompt. After some work, with help from Roger W3SZ I have been successful to compile WSJT598 on Ubuntu 7.10 and I would like to do the same for MAP65, since I am planning to make some experiments on 6m JT65a. You should know that the present MAP65 code uses only the JT65B mode. Just for your knowledge, next month the Ciao Radio H102 direct sampling receiver with dual parallel input should be available, and I am curious to see if it can be used for dual polarization EME work. This sounds interesting! -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: MAP65 progress
Hi Alex and all, You ask about Linux I 'converted' to 100% linux many years ago now. The basic advantage I see is that once I get something working it stays working. With windows each new version meant I had to learn lots of stuff all over again. With Linux most commands are the same from version to version. Of far more importance is that I have yet to have a non-hardware related crash in which I lost major stuff. When one hard drive gets flaky, I mount it on another Linux machine and copy all the stuff to it and keep going :). I spend MUCH less time spent fighting the operating system. I almost forgot to mention, there are NO linux viruses of any consequence. When I do on-line shopping I boot a linux version from a live CD. Then there is not even a remote chance that my computer can get hacked and cause me any problem. DSL (DamnSmallLinux.org) usually just works with older wireless cards. If you are within open 802.11 WIFI range, you just boot DSL and you are on the web. If one live linux doesn't work, you just download another and try it. No $$, just a few CDs. I use several versions. My preferred version is Knoppix 5.0.1 DVD. I buy a new 100-200GB hard drive and put various versions of Linux on it and one huge 'user' partition. I put almost all of my stuff in the user partition. In that way I can 'mount' my stuff in whatever version of linux I happen to find useful at the time. A typical hard drive layout is: hda1 - DSL 0.8.3 or Knoppix 3.6 - used mostly to recover and get and keep things up and running. - DSL needs 300-500MB and knoppix 3.6 3.5-4 GB. hda2 - HUGE user partition - ext2 - 1/2 of hard drive hda3 - swap - about twice the size of main memory hda4 - extended various linux OSs such as hda5 - Ubuntu 7.04 - 4-5GB hda6 - Knoppix 3.6 - 3.5-5GB - I frequently put two copies of the same OS. If I have trouble I can just switch and figure out whatever problem later. hda7 - Knoppix 5.0.1-DVD 17-20GB - This version is HUGE, but it is ALL there and it just works :))). PCB layout, Schematic, etc. hda8 - DSL latest version - 1GB hda9 - another DSL or two hda10 - another interesting linux version ... hda14 - One of my hard drives has 14 partitions on it!!! I tend to prefer Debian based linux versions. Lots of fun All the above said, it took be about a year before I noticed that I just wasn't even turning on Windows anymore. Which lead me to dump Microsoft almost totally. I do use DOS on an occasional machine, but it is networked into my Linux computers. So far, I have been too lazy to convert to FreeDOS. I have not bought a new computer for some time. I wait 'til someone puts a old computer out in the trash or gives one to me. I install Linux in it and I have a new computer that works fine. I network it with my others and once I power it up, I talk to it VIA the network. One recent gift computer has not even had the cover opened. I just put a DSL CD in the drive, plugged in the network and it just worked. XLinrad works great talking to a 2nd Xwindows display box. I run Xlinrad on a 1GHZ pentium and talk to it using X windows from a box running DSL. In that way I can easily change resolutions. I just change DSL to match whatever screen resolution I wish, ssh into the remote linrad box and start xlinrad. My computer cluster at work has a whole bunch of different computer. All networked together with 10base2 (50 ohm coax). Works great!! I have probably gone on long enough. I hope you enjoy learning linux as much as I have :)). I think linrad is GREAT. I use it on HF all the time. warm regards, john, ni1b On Tue, 25 Sep 2007, [EMAIL PROTECTED] wrote: Hi Joe, Leif and all Well not to much happens regarding our progress testing MAP65, in HB9Q we finish the feeder installation on our 15m dish but until now I can not put the WSE converters to work, main problem is to control the LO on the WSE, simple doesn't work. But our main problem was time, i just back from a complicate knee surgery and I'm recovery now at home. HB9Q is 100 km far way from my QTH means i need to wait some weeks and back to work on the WSE converters. I did some test in my network and I find the configuration very simple but until know I have no chance to test over the Air, I try to use MAP65 on HF (14.076 Mhz) at home I have not EME antennas but MAP65 is fix on JT65B and on HF mode is JT65A, maybe some can Joe fix on the next versions to test the decoding Based on the extra time I have now at home I start to build a poor man WSE converters, for sure the core will be linrad and the use of some softrock lite v6.2 receptors to produce 4 audio channels (having adaptative polarization is my goal). I'm close to finish the front end part, 2 receptors down from 144 Mhz to 14 Mhz using for both receptors a 130 Mhz LO (same amplitud and phase) and a +17dbm mixer, the second part are 2 softrock
[linrad] Re: MAP65 Experiment
Hi Joe and all, Sorry to be a bit slow in responding. I have been traveling since last week, and it seems that you have largely answered your own question. The polarization-matching capabilities of the Linrad-MAP65 combination depend on having a two-channel receiver. Any mixing in the Rx chain must be done using the same local oscillator in both channels, so as to maintain phase properly. Single-channel systems like the SDR-1000, SDR-14, and SDR-IQ can't satisfy this requirement. (Of course, they still make excellent single-channel receivers, and can provide all of the MAP65 capabilities except polarization-matching.) Leif has some examples of relatively simple and inexpensive down-converters on his web site. Something like a pair of Soft-Rock boards would also do the job well, if modified so that the mixers on two boards are driven by the same LO. -- 73, Joe, K1JT Joe Barger wrote: After reading the Polarization question thread that Joe started, reviewing the WSE architecture, and thinking about the problem more, my quick and dirty approach to getting linrad/MAP65 with polarization probably won't work. Calibration using Dphi may compensate for initial phase errors between the two RX channels, but the phase errors introduced by the SDR-1000 (and transverter) LOs drifting at different rates would quickly degrade performance. Using the same (low phase noise, etc.) clock for each conversion stage appears necessary to preserve phase information. Probably obvious to those who have thought about this for more than a microsecond, but ... WSE is really nice solution, but with one kid in college and another close behind, it's a bit out of my price range at the moment. There's an external 10 MHz frequency input for the SDR-1000 so both SDR-1000s can be run from the same frequency reference, but I'll have to investigate potential transverter/down-converter solutions. What hardware are others using to solve the problem? joe n6kk - Original Message - From: Joe Barger [EMAIL PROTECTED] To: Linrad mailinglist linrad@antennspecialisten.se Sent: Thursday, July 26, 2007 3:51 PM Subject: [linrad] MAP65 Experiment I'm thinking about how to easily adapt my EME station to take advantage of MAP65, initially receive only. The receive side my station consists of two phased yagis, preamp, Elecraft 144 transverter, and SDR-1000. I'm considering removing the power splitter, rotating one of the yagis 90 degrees and duplicating the receive components to have duplicate H and V RX paths. My main questions involve how closely the two RX paths must match in amplitude, phase and frequency. Amplitude I can probably adjust reasonably well in the SDR-1000, and I can probably adjust the RX frequency in both SDR-1000s to initially be pretty close, but the SDR-1000s are not locked to the same LO so they will drift apart after some period of time. In addition, the relative phasing will be unknown and probably also change over time. Hopefully amplitude will remain fairly stable. I think Dphi will compensate for initial phase errors between the channels, but how sensitive is the system to drift between the two SDR-1000 LOs (and corresponding phase and frequency errors)? I think the SDR-1000s (and transverters) will stay within a couple hundred hertz of each other for a reasonable period of time, but if the relative frequency and phase in the two channels must stay locked to within a few hertz/degrees then I think there is no hope with this approach. I'll probably just have to wait for a couple of the HPSDR Mercury boards ... or buy another SDR-IQ (if the LOs can be locked ... I don't remember if they can). If this hardware approach works, the next issue will be how to get two instances of PowerSDR, one linrad and one MAP65 all working happily on the computer resources I have ... Thanks joe n6kk # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the
[linrad] Re: MAP65 Beta Testing
Hi Joe, I am not an expert in networking either but enlarging the packet buffersize could solve your problem: After Leif increased the packet buffersize in the window version of watzo (win-wtz01-01) , I got rid of a lost packet problem that was present in win-wtz01-00. This change was based on the recommendation of Dirk Claessens who wrote: I heard from Pierre that Linrad for Windows is experiencing sporadic packet loss. It appears that there exists no magic registry key to enlarge the packet buffersize on a global basis. However, the buffersize can be set on a per socket basis: To get the current size: int skt, int sndsize; err = setsockopt(skt, SOL_SOCKET, SO_RCVBUF, (char *)sndsize, (int)sizeof(sndsize)); To set the new size: int sockbufsize = 0; int size = sizeof(int); err = getsockopt(skt, SOL_SOCKET, SO_RCVBUF, (char *)sockbufsize, size); ( to set the send buffer size: use SO_SNDBUF ) A word of caution: enlarging the buffer is not a magical solution. If - for whatever reason - a client cannot cope with the datarate of the server, the input buffers will overflow anyway, it will just take some more time. It will only help to cure occasional overload. ** From what you describe, it looks indeed that the bottleneck is not related to the speed of your network connection but rather to the processing of the incoming packets. Hope it helps 73, Pierre/ON5GN On Friday 06 July 2007 14:55, Joe Taylor wrote: I am anything but an expert in networking; in fact, I have some network-related questions of my own, as you will see below. For reasons I have not yet identified, my system works better with the network speed set at 10 Mb/s. If I set it to 100 Mb/s things still work, but the percentage of dropped packets increases to about 2.6% in steady state. Moreover, these numbers stay essentially the same (0.6% lost data at 10 Mb/s, 2.6% lost data at 100 Mb/s) if I disconnect both computers from the network hub and simply connect the two through a crossover cable. Probably I am doing something stupid in the recvpkt() routine in MAP65; or perhaps I need to set some parameter differently in the Linux and/or Windows computers. If anyone can shed light on the situation, or suggest some suitable diagnostics, I would be grateful. I use a completely different pair of computers for development work. One runs Debian Linux (installed from Knoppix) and the other runs Win XP/Pro. Between these machines the number of dropped packets is smaller but still not necessarily zero. With the network supposedly running at 100 Mb/s, I fairly often see a few (0-20, say) dropped packets (out of a total 33103) in a minute. Loss of 1% of the data is arguably not very important. It does not degrade JT65 decoding noticeably. Nevertheless, i would like to understand what I am doing wrong. # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Map65 de W5UN
Hi Joe, Well, I could help, but I do not have Xpol antennas. I do have SDR-IQ and am running Linrad with it (working nicely now). I'm, not sure how to inject two receiving antennas into the SDR-IQ though. It is possible that I could rig antennas here to receive both polarities. Let me know if you think I might be useful. Dave, W5UN At 03:01 7/4/2007, you wrote: This morning I made the first QSOs using the new program MAP65: ZL2DX, VK4JMC, and VK4CDI were worked on 2m EME. # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: MAP65 and Linrad Network
Hi Joe, Yes, it should be possible to run everything on a single fast computer with plenty of memory. I have not yet established that the necessary CPU-sharing during time-critical parts of each program is handled adequately for this to work without glitches. Neither Linrad nor Windows is a very good real-time O/S, and one must work around their limitations in this area. I do not think there would be any problems:-) Moreover, one will almost certainly want separate screens for Linrad and MAP65 -- both of which generally use most or all of a normal-size screen. Yes, I agree - but those who have only one standard computer should know it is possible - if it really is;-) For testing MAP65 when real signals are not available, and anyway so that I can get 100% repeatable results, I solved this problem in a slightly different way. I saved some data by using the Linrad S command during the ARRL EME contest last November. With a slightly modified Linrad I converted the data to 16-bit TIMF2 format, and wrote it to a file. A simple program that I call plrs (for pseudo-Linrad send) can read this file and multicast it in the same way that Linrad would do, so that MAP65 can receive it. The data file, 11 minutes of original data, amounts to 507 MB. After compression with bzip2 it is 228 MB. I will make the data file available soon, together with plrs and MAP65, to anyone who wants to participate in testing MAP65. Hmmm, I would have liked a file that allows me to play with Linrad on the data that are sent to MAP65. Presumably you have a couple of spurs and perhaps other interesting interference that MAP65 (or at least the waterfall graph) would benefit from not getting. Surely, for MAP65 testing and development I agree that your strategy is more convenient - but from my point of view the original file is far more interesting 73 Leif / SM5BSZ # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: MAP65 and Linrad Network
Hi Leif, Moreover, one will almost certainly want separate screens for Linrad and MAP65 -- both of which generally use most or all of a normal-size screen. Yes, I agree - but those who have only one standard computer should know it is possible - if it really is;-) When MAP65 is available, I will be sure to document how it can best be used, and what the hardware requirements will be. Hmmm, I would have liked a file that allows me to play with Linrad on the data that are sent to MAP65. Presumably you have a couple of spurs and perhaps other interesting interference that MAP65 (or at least the waterfall graph) would benefit from not getting. This will not be a problem. I have the original raw data file and have placed it at http://physics.princeton.edu/pulsar/K1JT/06_0744.raw.bz2 It is 263 MB in size. One of the nuisances of using the original data file is that Linrad's raw data are not time-stamped. As you know, JT65 transmissions must start at the top of a UTC minute. To use the raw data file effectively with MAP65 you will need to do something to ensure that the multicast packets contain times that are close to being correct with respect to the original time (modulo 60 seconds). Surely, for MAP65 testing and development I agree that your strategy is more convenient - but from my point of view the original file is far more interesting Yes. It probably will be far more interesting, for you especially. You will find plenty of birdies and other junk in the test file!! See http://physics.princeton.edu/pulsar/K1JT/MAP65_1.JPG . -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: MAP65 and Linrad Network
Hi Joe,
I have the original raw data file and have placed it at
http://physics.princeton.edu/pulsar/K1JT/06_0744.raw.bz2
Excellent:-)
One of the nuisances of using the original data file is that
Linrad's raw data are not time-stamped.
Oooh! But they are:-) Your file is stamped 1163231107.413487 which
was the output of the routine current_time() at the start of
the recording.
double current_time(void)
{
struct timeval t;
gettimeofday(t,NULL);
return 0.01*t.tv_usec+t.tv_sec;
}
This is the time in seconds with six decimals since Epoch
and if you run Linrad on the file with a fast waterfall
you will see the time on the waterfall starting at 07.45.08
Unfortunately I have missed to put the correct time in the
time variable of the network packets. Currently the time
is the time when data was read from the hard disk and not
when it was stored there. I will correct for the next version:-)
The 'S' file only has a single time stamp for when write was
started. With Delta 44 soundcards, the sampling rate is
pretty accurately 96 kHz (96014 Hz with the card in this
particular computer.) I think one can safely assume that
the error is well below 0.05% so in a 1 hour recording
the time error at the end should stay well below 2 seconds.
As you know, JT65
transmissions must start at the top of a UTC minute. To use
the raw data file effectively with MAP65 you will need to do
something to ensure that the multicast packets contain times
that are close to being correct with respect to the
original time (modulo 60 seconds).
OK. I hope that you have found the time to be correct when
receiving timf2 data from Linrad in real time.
Surely, for MAP65 testing and development I agree that your
strategy is more convenient - but from my point of view the
original file is far more interesting
Yes. It probably will be far more interesting, for you
especially. You will find plenty of birdies and other junk
in the test file!! See
http://physics.princeton.edu/pulsar/K1JT/MAP65_1.JPG .
Fine!
I do not know how to interpret the MAP65 screen. The polarisation
data of AA1YN seems odd to me. They change very rapidly:
0746: 90
0748: 135
0750: 135
0752: 135
0754: 0
0756: 45
Which signal on the screen that has this behaviour is not obvious to me.
The processing screen says Freq 128 and DF=0 (or very close.)
When I look at the file, I find the weak signal at the center of the
lower waterfall to start at 144.129823 and drift down to 144.129814.
That is a 1.818 Hz frequency shift as compared to the MAP65 screen???
There is some info Options in the upper waterfall, but that does not
fit. The signal at 144.12982 is right hand circular in Linrad and it
does not change polarisation during the 10 minutes.
The strong signal at -880 Hz in the lower waterfall is at 144.12894
in Linrad. This signal is elliptic, about 50% left hand. Polarisation
does not change with time on this signal either.
How do I compute the true frequency of the sync tone from the data
in the MAP65 screen?
73
Leif / SM5BSZ
#
This message is sent to you because you are subscribed to
the mailing list linrad@antennspecialisten.se.
To unsubscribe, E-mail to: [EMAIL PROTECTED]
To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED]
To switch to the INDEX mode, E-mail to [EMAIL PROTECTED]
Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: MAP65 and Linrad Network
Hi Leif, The combination works OK, and but a significant number of packets (around 400 in each minute, or slightly more than 1% of the data) are dropped during MAP65's most compute-intensive parts of each minute. Since plrs does no significant computing, I imagine that the problem may be worse when running Linrad + MAP65. It could also be the other way around. Indeed, it could. In that case I will be surprised, but it will hardly be the first time I have been similarly surprised. It may be necessary to add a call to Sleep(0) under Windows or to sched_yield() under Linux at regular intervals in all routines that might lock up the CPU for a too long time. Those calls are effected by lir_sched_yield() in the OS independent code of Linrad and I found it necessary to place about 45 such calls within Linrad. Hmmm, I may have trouble doing the equivalent. For example, MAP65 does some very long FFTs using tthe FFFTW3 library. I can't very well put calls to relinquish CPU control inside these tasks. On the other hand, there is a threads version of FFTW3, which might be what's needed. Right now such issues are not a top priority, though. -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: MAP65 and Linrad Network
Hello Joe, I have now established the necessary network connection between Linrad and MAP65. So far, I have found nothing to prevent a happy marriage! MAP65 receives a full 90 kHz of xpol signal from Linrad, finds all the JT65 signals in that bandwidth, matches the linear polarization angle of each one, decodes the messages, and provides the operator with a band map showing callsigns, operating frequencies, polarization angles, and message contents over the past 15 minutes or so. The program provides a full-width waterfall display and another one zoomed in on the frequency of the station currently being worked. Excellent!! Questions about Linrad's TIMF2 Multicast Data - Header information accompanying Linrad's multicast TIMF2 data includes two single-byte parameters, userx_no and passband_direction, about which I have questions. I understand that userx_no should correspond to the number of RF channels, with negative sign indicating floating format. I would have expected the value -4 for my system using xpol antennas and the WSE converters (I and Q for each of two polarizations), but in fact I see -2. Is this as it should be? Yes. You have two RF channels only. You might have used the hardware described here: http://www.sm5bsz.com/pcdsp/hware.htm This uses two audio channels to receive two RF channels but the output from timf2 would have the same format as you have with the WSE units. The difference is that the sampling speed of timf2 is the same as the audio sampling speed with WSE units, but half the audio sampling speed for the other solution. There is no need for MAP65 to know whether the 96kHz timf2 data originates in a hardware using two audio channels with a sampling rate of 192 kHz or four channels sampling at 96 kHz. Similarly, I would have expected passband_direction=1 as I have no LO's on the high side and the spectrum is not inverted. However, Linrad sends passband_direction=-1. Is this correct? You have the RX10700 with LO=13.175, 13.200, 13.225 or 13.250 MHz which is above 10.7. All the other LOs are below so -1 is correct. Linrad FFT Versions --- I have been using FFT Version 0 for the first forward, first backward, and second forward FFTs. This produces floating-point TIMF2 data on the multicast network. On a modern computer you can use version 5 for the first forward fft. It uses the SIMD instructions (single instruction multiple data, now called sse I think) and computes the floating point fft quite a bit faster. To save on memory usage in MAP65 it may be desirable to use 16-bit data for TIMF2. I have effected this by setting first forward FFT to version 5, The first fft is always floating point. It must be because the dynamic range of 16 bits is by far not adequate for the unprocessed A/D input. Version 5 is always a good choice on a computer that will allow it. Pentium II and older do not have the SIMD instructions so they have to use another version and it differs a little which one will run fastest depending on architecture. On old machines it might be desireable to actually try all versions and pick the one that runs fastest since old machines may be CPU limited. first backward FFT to version 1, and second forward FFT to version 2. Are these good choices? Yes. Is there any downside to their use that I might not have thought about? Also, with these settings I notice that the signal in the high resolution graph (red dB lines) is higher than it was with FFT versions 0. Should I adjust some other parameter to bring this level down be several dB? When the floating point data from fft1 is truncated to 16 bits there will be quantization noise. You should place the system noise floor at least 20 dB above this extra source of noise to make the loss of NF smaller than 0.043 dB. Press A on the keyboard to see the amplitude margins. In case you place the noise floor too high you might find that there is saturation somewhere. The shift parameters for the FFTs will allow you to set the noise floor at the correct level. http://www.sm5bsz.com/linuxdsp/install/dlevel.htm There are many possible sources of rounding errors (quantization noise) and Linrad does not set levels automatically since the criteria for what will be optimum are non-trivial. I hope the above link will be helpful. Under normal circumstances you will not need the maximum dynamic range in the second FFT. Only if you have a carefully calibrated system and want to use the smart blanker saturation on noise pulses will be a problem. Narrowband signals are automatically attenuated to fit within the dynamic range of 16 bits. In case you want a very large size for the second fft and a small size for the first fft, the narrowband signals have to be attenuated to a pretty low level. A perfect sinewave may put nearly all its energy in a single FFT bin.With a
