[Lowfer] MultiPSK V4.5 @W1LE

[Stan]

Hello The Net:

Recent reception on 508.5 KHz experimental radio operations, MFSK8/MFSK16.

I turned the AFC OFF because the decoder center freq would drift off 
(wander, hunt)
when trying to copy very weak signals. When the signal of interest came up,
the decoder was tuned off enough to not be able to decode.
After turning AFC OFF, the decode center freq stayed put, exactly where 
I wanted it to be

I turned the AGC OFF so that I could control the level at which the 
SQUELCH worked.
I use the squelch to stop the random displayed data characters when 
there was no signal
of interest and some static crashes or other RFI noises.
Last night I adjusted the SQUELCH to 3 and by also adjusting the line 
input level
 I could get the no signal S/N to -30 and the S/N with signal to > +15 dB
The SQUELCH operated nicely after the FEC buffers were flushed and 
before they started to fill.

SAMPLING FREQ calibration routines:
I tried the calibration routine and first got 11,026 samples /sec where 
it should of been 11,025.
A second and third try yielded what it was supposed to get,    11,025 
Sa/sec.
I was pleasantly surprised it was so close. No calibration needed.
I use the motherboard soundcard. I also have installed a Delta-44, 4 
channel card, I will use it later.

8 bit vs. 16 bit processing on receive.  I went to 16 bit. Jay has a hot 
signal here on Cape Cod.
I will further evaluate 8 vs. 16 bit processing when Dex is testing again.
His signal is copyable, but at a much lower level than the locals, /2 
and /3.
The greater DX also has more propagation anomalies.
16 bit RX processing should give better decoding results during a deeper 
fade than with 8 bit processing.
Why, ...greater dynamic range.

I like the timestamp on each line of a transmission.
That way received and decoded data can be reviewed to determine what may 
have been dropped.
If the time stamp is place in the middle of the message, the time delay 
is about 20 seconds.
Looks like the timestamp injects time when the transmission starts vs, 
when the timestamp occurs in the message.
I would prefer the timestamp at the begining of the transmission.

I would also like a S/N # at the end of the line of transmission, to 
indicate the average S/N during that line.
(I will add to the wishlist.)

Random displayed characters after transmission begins but before the FEC 
buffers are full and
after the transmission stops but before FEC buffers are flushed out.
May have to live with this effect. Possibly carriage returns/line feeds 
at the begining and end of a transmission,
may assist in reading/sorting good data from bad.
Possibly a special character or sequence of characters could start/enable
the FEC buffers for so many characters before displaying data.
Same for the end of a transmission. The special character would disable 
the FEC buffers,
flushing their contents and stopping the random data display.
I will forward this e-mail to Mr. Lindecker in France, for review.

Possibly enabling the Reed-Solomon  decoders could assist in the time to 
syn and resync.
See IDENTIFIERS and RS ID. I have yet to fully digest that help file.
These decoders could be enabled at the start of each QSO or at the start 
of each transmission.

Stan, W1LE  Cape Cod




ZZZZz