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.


> 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:
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

> 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?  

> 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.

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 256 times bigger fft2 than fft1, the amplitude 
in fft2 will become 16 times bigger than the amplitude in fft1
if the antenna noise level is placed at the same level in
both cases. Saturation is at 32768 in fft1, but anything
above 2048 in fft1 could saturate fft2. If the noise floor 
is placed at 10, a signal that is 200 times (46 dB) above the
noise floor has to be considered strong and be routed outside the 
noise blanker (with reduced amplitude.) If the fft1 bandwidth 
is 100 Hz, a signal that is 32 dB above the noise floor in
SSB bandwidth would be considered strong. (And there has to be 
some safety margin on top of this.) 

In the early phases of what is now Linrad, there was only the 16 bit 
processing. On a Pentium MMX the limited processing power makes 
it absolutely necessary to use the 16 bit multimedia instructions
because of the limited CPU power. 

With 16 bit processing there are more chances to make mistakes, 
but there should be no differences in how well weak signals
can be copied. For strong signals there are some differences,
but nothing that affects real operation (I think):

> MAP65 with Windows, Linux, FreeBSD, Winrad, SDRxxx ... ?
> ------------------------------------------------------------
> Like WSJT, MAP65 runs on both Windows and Linux.  (It should 
> also run on FreeBSD and Macintosh, but I can't test those 
> here.)  In my station I will probably run Linrad under Linux 
>   and MAP65 on Windows, on a second computer.

> In response to questions I have been getting: MAP65 could 
> run with Winrad or with various SDR's if their software is 
> modified to provide the necessary multicasting capability. 
> In itself, this would not be too difficult.
> However, one of the most important MAP65 features is its 
> automatic Rx-polarization-matching capability.  That 
> requires a receiver with full xpol processing, which (as far 
> as I know) is not now provided by Winrad, SDR-1000, SDR-14, 
> or SDR-IQ.

Hopefully we will soon see modifications that allow two 
SDR-1000 receivers to run from the same LO:-) This should 
be quite straightforward.

With SDR-14 and SDR-IQ it will be more difficult because the
data decimation chip needs several sync lines. Presumably
there is also a need for modified drive routines as well.


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]>

Reply via email to