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 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): http://www.sm5bsz.com/linuxdsp/blanker/fp/fpblank.htm > 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. OK:-) > 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. 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]>
