[Elecraft] K3 and recording SSB & CW

[David Woolley]

David Cutter wrote:
> Is there an 
> optimum setting for digital recording (bit rate?) that will maximise 
> memory capacity?  I presume that ssb and cw being narrow audio need 
> <<than hi fi.   Has anyone done the sums to record a 48 hour contest?  
> This would be brilliant for training.

Real optimum recording depends on defining exactly what nuances of the 
signal that you want to preserve.  However, for simple, PCM, storage, 
which gives a pretty faithful reproduction, other than quantisation 
noise, you want to sample at approximately twice the bandwidth at 
halfway down the receiver filter skirts.

Ideally, you should do this based on the true lower bound frequency, but 
  you will need special software to both record and play this, and you 
will need to oversample in the sound card, as sound card anti-aliasing 
filters assume that the lower limit is zero.

The PSTN used to use SSB on its carrier systems, with a nose bandwidth 
of 3.1kHz and an lower nose frequency of 300Hz,  Amateur SSB (as against 
ESSB) is rather narrower than this.  Digital PSTN converts this to 8kHz 
sampling, so you will never need more than 8kHz sampling and 6kHz would 
probably work quite well.

As for bits per sample, you should, at least, be using the same systems 
as the telephone network uses, i.e. A or mu-law companding into 8 bit 
codes.    Anything except the original 8 bit Sound Blaster will have 
provision for generating A and mu-law files.  I'm not sure how well CVSD 
(continuous variable slope delta) (4 bits per sample) works with noisy 
signals.

Given that communications voice tends to have a fairly constant 
amplitude, at the audio output, even 8 bit linear would have an 
acceptable SNR, but there is really no reason not to use A or mu-law, 
these days.

With signal type aware encoding, and clean signals, as one might get in 
an FM ragchew environment, you should be able to get acceptable archive 
quality at 2.4kb/s, using linear predictive coding.  Algorithms for this 
sort of bit rate are published on the internet, and were, I think 
devised by the military to allow the use of digital encryption, some 
twenty to thirty years ago.

For noisy signals, one would need to experiment.  For speech, another 
LPC based codec, that runs a bit faster, GSM full rate might be worth 
trying, at 13.6 kb/s. This is the typical codec used for voice recording 
in the Asterisk open source PABX.  There is a half rate GSM algorithm, 
but I haven't seen publicly available implementations of this.

Low bit rate versions of MP3 might be worth trying as well, e.g. the 
8kb/s and 16kb/s.  Although MP3 is designed for music, rather than 
speech, the 16kb/s certainly works well for communications quality 
speech, at least in the absence of noise.

The ideal encoding for morse is, of course, to decode it, although I 
imagine one could get some quite compact coding that didn't go that far.

On the other hand, if you intend to do any detailed analysis for 
harmonic distortion or any other detailed technical analysis, you want 
at least 16 bit linear, simple PCM.  You should never use MP3 for 
reference samples.

All the above would be mono.

> 
> Even better to record a segment of the band that can be replayed using 
> LP PAN etc.  What memory capacity would be needed for that and is it 
> practical to do?

If you sample before the roofing filters, you need as fast as you get by 
as many bits as you can get.  In practice that means 96kHz and 16 bits, 
although 24 bits would be better.  You need to do this in stereo, to get 
both I and Q components.  We are therefore talking about 384kB/s or 375KB/s.

If you do it after a roofing filter, you need to sample at a rate 
equivalent to the bandwidth about half way down the filter skirts.  In 
practice, the K3 roofing filters are all too narrow to get useful 
panning post filter.


-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.