MAP65 and 16 bit data.The program MAP65 by K1JT was originally designed for use with a cross yagi antenna, the WSE converters and a Delta 44 soundcard. There is also a version MAP65-IQ that works with a single polarisation, SDR-IQ, SDR-14, Perseus and probably other direct sampling SDR hardware. The programs were written to receive data from Linrad in the 16 bit TIMF2 format. That is the full bandwidth data after Linrad has applied a correction filter as specified by the user calibration data and after Linrad has applied noise blankers as specified by the operator.
The 16 bit data format in Linrad saves a substantial amount of CPU time because it allows the usage of 16 bit multimedia instructions that run FFT about 3 times faster than normal floating point arithmetics. That was an essential feature on Pentium MMX which did not have the CPU horsepower to do the Linrad noise blanking with floating point arithmetics. The 16 bit MMX is no longer needed at modest sampling speeds like 96 kHz but the option is still important in Linrad because today (year 2012) it is needed on e.g. a dual core computer to allow the Linrad noise blanker when sampling at 2 MHz.
The 16 bit data does not allow much dynamic range. It is essential that the digital levels are set properly because otherwise S/N may become degraded due to quantization noise. Here is an old page (year 2001) on the subject: set digital signal levels correctly.
Fig 1. The relevant part of the Linrad block diagram
when used to send data to MAP65.
There is an option to disable the strong signals,
the blue traces that go directly from timf2 to the output
There are three places where the digital signal level has to be high enough when 16 bit data are sent to MAP65.
This link The timf2 level. shows examples of quantization noise in the TIMF2 data sent to MAP65 due to incorrect level settings.
MAP65 and data quality.A digital mode like MAP65 depends on precise timing. In case there are errors in the computer system causing occasional loss of data, the effective data rate would become lower and the data arriving after the lost buffer(s) will not arrive at the correct time and could therefore cause loss of detection.
Loss of data can happen in the device driver due to excessive DPM latency or due to software bugs. Loss of data can also happen within Linrad itself due to errors in the Linrad code. Versions Linrad-03.28 to 03-31 suffered from such errors caused by the adaption of Linrad to work on Mac OS X.
Bugs in drive routines (Delta 44 under Windows 7) as well as bugs in Linrad can cause buffers containing non-valid data to be sent. As long as the total number of data points is correct, the damage is not too serious. It will behave like an artificial noise spike and would degrade S/N slightly. In case it would happen often it would of course degrade S/N significantly.
Linrad-03.33 has a test facility that allows a second instance of Linrad to receive and analyze the data that is sent to the network. By sending a very strong carrier into Linrad one can make sure that all the data points are correct. When a near saturating signal is present a single missing data point would cause a significant phase jump that would be visible in the waterfall display. A single point from an incorrect point in time is likely to have a value that is incorrect by nearly the full A/D range and it would also be well visible.
This link Checking the signal sent to MAP65 for glitches. shows how a Linrad/MAP65 operator can certify that the data sent to MAP65 is correct.
To SM 5 BSZ Main Page