Re: [softrock40] Re: of soundcards !
- On 2/10/2013 5:13 PM, warrenallgyer wrote:
Hi Warren, Alan, Mike, et al,
Agreed Milt There is an interesting post here: http://wsprnet.org/drupal/node/890 with comments directly from Joe that shed some light on the subject. Over the last couple of days I have experimented using external attenuators to match the antenna noise floor exactly to the card noise floor, both for 16 and 24 bit cards. I attenuated the incoming signal to the point where adding one more dB of pad does not decrease the noise. Interestingly, this point seems to coincide with the "-30, -30" SNR indication on the WSPR panel. Taking that datapoint along with Joe's answers in his post above, I inferred that WSPR could detect signals below not just the antenna noise floor, but also below the card noise floor. And that, in fact, seems to be the case. My decodes with the antenna noise and the card noise set the same seemed unaffected, with plenty coming in at the normal -22, -25, -28 levels. If I added 10 dB more of pad the number of spots dropped dramatically, indicating to me that the card noise level, which was now 10 dB higher than antenna noise, was now the determining factor. For WSPR I am not sure the software can average across the entire transmission period. The transmission consists of 162 symbols over the transmission interval which include the information and forward error correction. For each symbol he must be able to pull it out of the noise and detect its' frequency within about 700 milliseconds to get the symbol value. I am not smart enough to analyze source code so I will be very interested to learn what you find. Warren Allgyer - W8TOD
I downloaded the source code for WSPR yesterday. I spent some time on reviewing it this morning and have come to the conclusion that WSPR was probably written for use with built-in sound cards. Here is an excerpt from one of the files that relates to the sound-- (the specific file is "sound.c")
/* #define DITHER_FLAG (paDitherOff) */
#define DITHER_FLAG (0) /**/
#define PA_SAMPLE_TYPE paInt16
typedef short SAMPLE;
Elsewhere in the code there are options listed for the data type used with sound samples. They include 8, 16, 24, and 32 bit integers and 32 bit floating point data types.
In the above lines of code, PA_SAMPLE_TYPE refers to PORT_AUDIO data and 16 bit is chosen. SAMPLE refers to the data sample type used within WSPR. The "short" data type is usually 16 bit integer.
In light of the above information, I would have to conclude that using a 24 bit sound card with the current versions of WSPR will provide no theoretical or practical advantage over 16 bit cards. This was probably done to allow the program to run on older systems that have only 16 bit built-in audio. However, it would appear that the code could be modified to take advantage of the 24 bit audio systems. This would require that additional data storage be provided, but should not be a problem with the amount of memory in newer computers.
- On 11/02/13 19:15, Milt Cram wrote:
> In light of the above information, I would have to conclude that using aI'll let you into a secret.
> 24 bit sound card with the current versions of WSPR will provide no
> theoretical or practical advantage over 16 bit cards. This was probably
> done to allow the program to run on older systems that have only 16 bit
> built-in audio. However, it would appear that the code could be
> modified to take advantage of the 24 bit audio systems. This would
> require that additional data storage be provided, but should not be a
> problem with the amount of memory in newer computers.
24-bit sound cards are a marketing gimmick.
At best, about 20 bits of the capture are significant - with a very,
very low noise signal chain and an excellent ADC, the sort of thing you
get in Alesis ADATs. Most "24-bit" cards are producing something
between 16 and 18 bits of proper audio, with the rest being just noise.
Forget 24-bit capture and concentrate on getting your analogue noise
floor down and signal levels up.