SVN r8568
This commit is contained in:
Jordan Sherer
@@ -1,258 +0,0 @@
|
||||
subroutine mskrtd(id2,nutc0,tsec,ntol,nrxfreq,ndepth,mycall,mygrid,hiscall, &
|
||||
bshmsg,bcontest,btrain,pcoeffs,bswl,datadir,line)
|
||||
|
||||
! Real-time decoder for MSK144.
|
||||
! Analysis block size = NZ = 7168 samples, t_block = 0.597333 s
|
||||
! Called from hspec() at half-block increments, about 0.3 s
|
||||
|
||||
parameter (NZ=7168) !Block size
|
||||
parameter (NSPM=864) !Number of samples per message frame
|
||||
parameter (NFFT1=8192) !FFT size for making analytic signal
|
||||
parameter (NPATTERNS=4) !Number of frame averaging patterns to try
|
||||
parameter (NRECENT=10) !Number of recent calls to remember
|
||||
parameter (NSHMEM=50) !Number of recent SWL messages to remember
|
||||
|
||||
character*4 decsym !"&" for mskspd or "^" for long averages
|
||||
character*22 msgreceived !Decoded message
|
||||
character*22 msglast,msglastswl !Used for dupechecking
|
||||
character*80 line !Formatted line with UTC dB T Freq Msg
|
||||
character*12 mycall,hiscall
|
||||
character*6 mygrid
|
||||
character*12 recent_calls(NRECENT)
|
||||
character*22 recent_shmsgs(NSHMEM)
|
||||
character*512 datadir
|
||||
|
||||
complex cdat(NFFT1) !Analytic signal
|
||||
complex c(NSPM) !Coherently averaged complex data
|
||||
complex ct(NSPM)
|
||||
|
||||
integer*2 id2(NZ) !Raw 16-bit data
|
||||
integer iavmask(8)
|
||||
integer iavpatterns(8,NPATTERNS)
|
||||
integer npkloc(10)
|
||||
integer nhasharray(NRECENT,NRECENT)
|
||||
integer nsnrlast,nsnrlastswl
|
||||
|
||||
real d(NFFT1)
|
||||
real pow(8)
|
||||
real softbits(144)
|
||||
real xmc(NPATTERNS)
|
||||
real*8 pcoeffs(5)
|
||||
|
||||
logical*1 bshmsg,bcontest,btrain,bswl
|
||||
logical*1 first
|
||||
logical*1 bshdecode
|
||||
logical*1 seenb4
|
||||
logical*1 bflag
|
||||
logical*1 bvar
|
||||
|
||||
data first/.true./
|
||||
data iavpatterns/ &
|
||||
1,1,1,1,0,0,0,0, &
|
||||
0,0,1,1,1,1,0,0, &
|
||||
1,1,1,1,1,0,0,0, &
|
||||
1,1,1,1,1,1,1,0/
|
||||
data xmc/2.0,4.5,2.5,3.5/ !Used to set time at center of averaging mask
|
||||
save first,tsec0,nutc00,pnoise,cdat,msglast,msglastswl, &
|
||||
nsnrlast,nsnrlastswl,recent_calls,nhasharray,recent_shmsgs
|
||||
|
||||
if(first) then
|
||||
tsec0=tsec
|
||||
nutc00=nutc0
|
||||
pnoise=-1.0
|
||||
do i=1,nrecent
|
||||
recent_calls(i)(1:12)=' '
|
||||
enddo
|
||||
do i=1,nshmem
|
||||
recent_shmsgs(i)(1:22)=' '
|
||||
enddo
|
||||
msglast=' '
|
||||
msglastswl=' '
|
||||
nsnrlast=-99
|
||||
nsnrlastswl=-99
|
||||
first=.false.
|
||||
endif
|
||||
|
||||
fc=nrxfreq
|
||||
|
||||
! Dupe checking setup
|
||||
if(nutc00.ne.nutc0 .or. tsec.lt.tsec0) then ! reset dupe checker
|
||||
msglast=' '
|
||||
msglastswl=' '
|
||||
nsnrlast=-99
|
||||
nsnrlastswl=-99
|
||||
nutc00=nutc0
|
||||
endif
|
||||
|
||||
tframe=float(NSPM)/12000.0
|
||||
line=char(0)
|
||||
msgreceived=' '
|
||||
max_iterations=10
|
||||
niterations=0
|
||||
d(1:NZ)=id2
|
||||
rms=sqrt(sum(d(1:NZ)*d(1:NZ))/NZ)
|
||||
if(rms.lt.1.0) go to 999
|
||||
fac=1.0/rms
|
||||
d(1:NZ)=fac*d(1:NZ)
|
||||
d(NZ+1:NFFT1)=0.
|
||||
bvar=.true.
|
||||
if( btrain ) bvar=.false. ! if training, turn off rx eq
|
||||
call analytic(d,NZ,NFFT1,cdat,pcoeffs,bvar)
|
||||
|
||||
! Calculate average power for each frame and for the entire block.
|
||||
! If decode is successful, largest power will be taken as signal+noise.
|
||||
! If no decode, entire-block average will be used to update noise estimate.
|
||||
pmax=-99
|
||||
do i=1,8
|
||||
ib=(i-1)*NSPM+1
|
||||
ie=ib+NSPM-1
|
||||
pow(i)=real(dot_product(cdat(ib:ie),cdat(ib:ie)))*rms**2
|
||||
pmax=max(pmax,pow(i))
|
||||
enddo
|
||||
pavg=sum(pow)/8.0
|
||||
|
||||
! Short ping decoder uses squared-signal spectrum to determine where to
|
||||
! center a 3-frame analysis window and attempts to decode each of the
|
||||
! 3 frames along with 2- and 3-frame averages.
|
||||
np=8*NSPM
|
||||
call msk144spd(cdat,np,ntol,ndecodesuccess,msgreceived,fc,fest,tdec,navg,ct, &
|
||||
softbits,recent_calls,nrecent)
|
||||
if(ndecodesuccess.eq.0 .and. (bshmsg.or.bswl)) then
|
||||
call msk40spd(cdat,np,ntol,mycall(1:6),hiscall(1:6),bswl,nhasharray, &
|
||||
recent_calls,nrecent,ndecodesuccess,msgreceived,fc,fest,tdec,navg)
|
||||
endif
|
||||
if( ndecodesuccess .ge. 1 ) then
|
||||
tdec=tsec+tdec
|
||||
ipk=0
|
||||
is=0
|
||||
goto 900
|
||||
endif
|
||||
|
||||
! If short ping decoder doesn't find a decode,
|
||||
! Fast - short ping decoder only.
|
||||
! Normal - try 4-frame averages
|
||||
! Deep - try 4-, 5- and 7-frame averages.
|
||||
npat=NPATTERNS
|
||||
if( ndepth .eq. 1 ) npat=0
|
||||
if( ndepth .eq. 2 ) npat=2
|
||||
do iavg=1,npat
|
||||
iavmask=iavpatterns(1:8,iavg)
|
||||
navg=sum(iavmask)
|
||||
deltaf=10.0/real(navg) ! search increment for frequency sync
|
||||
npeaks=2
|
||||
call msk144sync(cdat(1:8*NSPM),8,ntol,deltaf,iavmask,npeaks,fc, &
|
||||
fest,npkloc,nsyncsuccess,xmax,c)
|
||||
if( nsyncsuccess .eq. 0 ) cycle
|
||||
|
||||
do ipk=1,npeaks
|
||||
do is=1,3
|
||||
ic0=npkloc(ipk)
|
||||
if(is.eq.2) ic0=max(1,ic0-1)
|
||||
if(is.eq.3) ic0=min(NSPM,ic0+1)
|
||||
ct=cshift(c,ic0-1)
|
||||
call msk144decodeframe(ct,softbits,msgreceived,ndecodesuccess, &
|
||||
recent_calls,nrecent)
|
||||
if(ndecodesuccess .gt. 0) then
|
||||
tdec=tsec+xmc(iavg)*tframe
|
||||
goto 900
|
||||
endif
|
||||
enddo !Slicer dither
|
||||
enddo !Peak loop
|
||||
enddo
|
||||
|
||||
|
||||
msgreceived=' '
|
||||
|
||||
! no decode - update noise level used for calculating displayed snr.
|
||||
if( pnoise .lt. 0 ) then ! initialize noise level
|
||||
pnoise=pavg
|
||||
elseif( pavg .gt. pnoise ) then ! noise level is slow to rise
|
||||
pnoise=0.9*pnoise+0.1*pavg
|
||||
elseif( pavg .lt. pnoise ) then ! and quick to fall
|
||||
pnoise=pavg
|
||||
endif
|
||||
go to 999
|
||||
|
||||
900 continue
|
||||
! Successful decode - estimate snr
|
||||
if( pnoise .gt. 0.0 ) then
|
||||
snr0=10.0*log10(pmax/pnoise-1.0)
|
||||
else
|
||||
snr0=0.0
|
||||
endif
|
||||
nsnr=nint(snr0)
|
||||
|
||||
bshdecode=.false.
|
||||
if( msgreceived(1:1) .eq. '<' ) bshdecode=.true.
|
||||
|
||||
if(.not. bshdecode) then
|
||||
call msk144signalquality(ct,snr0,fest,tdec,softbits,msgreceived,hiscall, &
|
||||
btrain,datadir,ncorrected,eyeopening,pcoeffs)
|
||||
endif
|
||||
|
||||
decsym=' & '
|
||||
if( btrain ) decsym=' ^ '
|
||||
if( msgreceived(1:1).eq.'<') then
|
||||
ncorrected=0
|
||||
eyeopening=0.0
|
||||
endif
|
||||
|
||||
if( nsnr .lt. -8 ) nsnr=-8
|
||||
if( nsnr .gt. 24 ) nsnr=24
|
||||
|
||||
! Dupe check.
|
||||
bflag=ndecodesuccess.eq.1 .and. &
|
||||
(msgreceived.ne.msglast .or. nsnr.gt.nsnrlast .or. tsec.lt.tsec0)
|
||||
if(bflag) then
|
||||
msglast=msgreceived
|
||||
nsnrlast=nsnr
|
||||
if(.not. bshdecode) then
|
||||
call update_hasharray(recent_calls,nrecent,nhasharray)
|
||||
! Should we call fix_contest_msg() only if bcontest is true?
|
||||
call fix_contest_msg(mygrid,msgreceived)
|
||||
endif
|
||||
write(line,1020) nutc0,nsnr,tdec,nint(fest),decsym,msgreceived, &
|
||||
navg,ncorrected,eyeopening,char(0)
|
||||
1020 format(i6.6,i4,f5.1,i5,a4,a22,i2,i3,f5.1,a1)
|
||||
elseif(bswl .and. ndecodesuccess.ge.2) then
|
||||
seenb4=.false.
|
||||
do i=1,nshmem
|
||||
if( msgreceived .eq. recent_shmsgs(i) ) then
|
||||
seenb4=.true.
|
||||
endif
|
||||
enddo
|
||||
call update_recent_shmsgs(msgreceived,recent_shmsgs,nshmem)
|
||||
bflag=seenb4 .and. &
|
||||
(msgreceived.ne.msglastswl .or. nsnr.gt.nsnrlastswl .or. tsec.lt.tsec0) &
|
||||
.and. nsnr.gt.-6
|
||||
if(bflag) then
|
||||
msglastswl=msgreceived
|
||||
nsnrlastswl=nsnr
|
||||
write(line,1020) nutc0,nsnr,tdec,nint(fest),decsym,msgreceived, &
|
||||
navg,ncorrected,eyeopening,char(0)
|
||||
endif
|
||||
endif
|
||||
999 tsec0=tsec
|
||||
|
||||
return
|
||||
end subroutine mskrtd
|
||||
|
||||
subroutine update_recent_shmsgs(message,msgs,nsize)
|
||||
character*22 msgs(nsize)
|
||||
character*22 message
|
||||
logical*1 seen
|
||||
|
||||
seen=.false.
|
||||
do i=1,nsize
|
||||
if( msgs(i) .eq. message ) seen=.true.
|
||||
enddo
|
||||
|
||||
if( .not. seen ) then
|
||||
do i=nsize,2,-1
|
||||
msgs(i)=msgs(i-1)
|
||||
enddo
|
||||
msgs(1)=message
|
||||
endif
|
||||
|
||||
return
|
||||
end subroutine update_recent_shmsgs
|
||||
@@ -1,82 +0,0 @@
|
||||
// -*- Mode: C++ -*-
|
||||
/*
|
||||
* Class to handle the formatted string as returned from the fortran decoder
|
||||
*
|
||||
* VK3ACF August 2013
|
||||
*/
|
||||
|
||||
|
||||
#ifndef DECODEDTEXT_H
|
||||
#define DECODEDTEXT_H
|
||||
|
||||
#include <QString>
|
||||
|
||||
|
||||
|
||||
/*
|
||||
0123456789012345678901234567890123456789
|
||||
^ ^ ^ ^ ^ ^
|
||||
2343 -11 0.8 1259 # YV6BFE F6GUU R-08
|
||||
2343 -19 0.3 718 # VE6WQ SQ2NIJ -14
|
||||
2343 -7 0.3 815 # KK4DSD W7VP -16
|
||||
2343 -13 0.1 3627 @ CT1FBK IK5YZT R+02
|
||||
|
||||
0605 Tx 1259 # CQ VK3ACF QF22
|
||||
*/
|
||||
|
||||
class DecodedText
|
||||
{
|
||||
public:
|
||||
explicit DecodedText (QString const&);
|
||||
|
||||
QString string() const { return string_; };
|
||||
void removeAddedInfo ();
|
||||
int indexOf(QString s) const { return string_.indexOf(s); };
|
||||
int indexOf(QString s, int i) const { return string_.indexOf(s,i); };
|
||||
QString mid(int f, int t) const { return string_.mid(f,t); };
|
||||
QString left(int i) const { return string_.left(i); };
|
||||
|
||||
void clear() { string_.clear(); };
|
||||
|
||||
QString CQersCall() const;
|
||||
|
||||
bool isJT65() const;
|
||||
bool isJT9() const;
|
||||
bool isTX() const;
|
||||
bool isStandardMessage () const {return is_standard_;}
|
||||
bool isLowConfidence () const;
|
||||
int frequencyOffset() const; // hertz offset from the tuned dial or rx frequency, aka audio frequency
|
||||
int snr() const;
|
||||
float dt() const;
|
||||
|
||||
// find and extract any report. Returns true if this is a standard message
|
||||
bool report(QString const& myBaseCall, QString const& dxBaseCall, /*mod*/QString& report) const;
|
||||
|
||||
// get the first message text word, usually the call
|
||||
QString call() const;
|
||||
|
||||
// get the second word, most likely the de call and the third word, most likely grid
|
||||
void deCallAndGrid(/*out*/QString& call, QString& grid) const;
|
||||
|
||||
int timeInSeconds() const;
|
||||
|
||||
// returns a string of the SNR field with a leading + or - followed by two digits
|
||||
QString report() const;
|
||||
|
||||
private:
|
||||
// These define the columns in the decoded text where fields are to be found.
|
||||
// We rely on these columns being the same in the fortran code (lib/decoder.f90) that formats the decoded text
|
||||
enum Columns {column_time = 0,
|
||||
column_snr = 5,
|
||||
column_dt = 9,
|
||||
column_freq = 14,
|
||||
column_mode = 19,
|
||||
column_qsoText = 22 };
|
||||
|
||||
QString string_;
|
||||
int padding_;
|
||||
QString message_;
|
||||
bool is_standard_;
|
||||
};
|
||||
|
||||
#endif // DECODEDTEXT_H
|
||||
@@ -1,321 +0,0 @@
|
||||
[[PROTOCOL_OVERVIEW]]
|
||||
=== Overview
|
||||
|
||||
All QSO modes except ISCAT use structured messages that compress
|
||||
user-readable information into fixed-length packets of exactly 72
|
||||
bits. Each message consists of two 28-bit fields normally used for
|
||||
callsigns and a 15-bit field for a grid locator, report,
|
||||
acknowledgment, or 73. An additional bit flags a message containing
|
||||
arbitrary alphanumeric text, up to 13 characters. Special cases allow
|
||||
other information such as add-on callsign prefixes (e.g., ZA/K1ABC) or
|
||||
suffixes (e.g., K1ABC/P) to be encoded. The basic aim is to compress
|
||||
the most common messages used for minimally valid QSOs into a fixed
|
||||
72-bit length.
|
||||
|
||||
A standard amateur callsign consists of a one- or two-character
|
||||
prefix, at least one of which must be a letter, followed by a digit
|
||||
and a suffix of one to three letters. Within these rules, the number
|
||||
of possible callsigns is equal to 37×36×10×27×27×27, or somewhat over
|
||||
262 million. (The numbers 27 and 37 arise because in the first and
|
||||
last three positions a character may be absent, or a letter, or
|
||||
perhaps a digit.) Since 2^28^ is more than 268 million, 28 bits are
|
||||
enough to encode any standard callsign uniquely. Similarly, the number
|
||||
of 4-digit Maidenhead grid locators on earth is 180×180 = 32,400,
|
||||
which is less than 2^15^ = 32,768; so a grid locator requires 15 bits.
|
||||
|
||||
Some 6 million of the possible 28-bit values are not needed for
|
||||
callsigns. A few of these slots have been assigned to special message
|
||||
components such as `CQ`, `DE`, and `QRZ`. `CQ` may be followed by three
|
||||
digits to indicate a desired callback frequency. (If K1ABC transmits
|
||||
on a standard calling frequency, say 50.280, and sends `CQ 290 K1ABC
|
||||
FN42`, it means that s/he will listen on 50.290 and respond there to
|
||||
any replies.) A numerical signal report of the form `–nn` or
|
||||
`R–nn` can be sent in place of a grid locator. (As originally
|
||||
defined, numerical signal reports `nn` were required to fall between -01
|
||||
and -30 dB. Recent program versions accommodate reports between
|
||||
-50 and +49 dB.) A country prefix or portable suffix may be
|
||||
attached to one of the callsigns. When this feature is used the
|
||||
additional information is sent in place of the grid locator or by
|
||||
encoding additional information into some of the 6 million available
|
||||
slots mentioned above.
|
||||
|
||||
Finally, the message compression algorithm supports messages starting
|
||||
with `CQ AA` through `CQ ZZ`. Such messages are encoded by
|
||||
sending `E9AA` through `E9ZZ` in place of the first callsign of a
|
||||
standard message. Upon reception these calls are converted back to
|
||||
the form `CQ AA` through `CQ ZZ`.
|
||||
|
||||
To be useful on channels with low signal-to-noise ratio, this kind of
|
||||
lossless message compression requires use of a strong forward error
|
||||
correcting (FEC) code. Different codes are used for each mode.
|
||||
Accurate synchronization of time and frequency is required between
|
||||
transmitting and receiving stations. As an aid to the decoders, each
|
||||
protocol includes a "`sync vector`" of known symbols interspersed with
|
||||
the information-carrying symbols. Generated waveforms for all of the
|
||||
_WSJT-X_ modes have continuous phase and constant envelope.
|
||||
|
||||
[[SLOW_MODES]]
|
||||
=== Slow Modes
|
||||
|
||||
[[JT4PRO]]
|
||||
==== JT4
|
||||
|
||||
FEC in JT4 uses a strong convolutional code with constraint length
|
||||
K=32, rate r=1/2, and a zero tail. This choice leads to an encoded
|
||||
message length of (72+31) x 2 = 206 information-carrying bits.
|
||||
Modulation is 4-tone frequency-shift keying (4-FSK) at 11025 / 2520 =
|
||||
4.375 baud. Each symbol carries one information bit (the most
|
||||
significant bit) and one synchronizing bit. The two 32-bit
|
||||
polynomials used for convolutional encoding have hexadecimal values
|
||||
0xf2d05351 and 0xe4613c47, and the ordering of encoded bits is
|
||||
scrambled by an interleaver. The pseudo-random sync vector is the
|
||||
following sequence (60 bits per line):
|
||||
|
||||
000011000110110010100000001100000000000010110110101111101000
|
||||
100100111110001010001111011001000110101010101111101010110101
|
||||
011100101101111000011011000111011101110010001101100100011111
|
||||
10011000011000101101111010
|
||||
|
||||
|
||||
[[JT9PRO]]
|
||||
==== JT9
|
||||
|
||||
FEC in JT9 uses the same strong convolutional code as JT4: constraint
|
||||
length K=32, rate r=1/2, and a zero tail, leading to an encoded
|
||||
message length of (72+31) × 2 = 206 information-carrying
|
||||
bits. Modulation is nine-tone frequency-shift keying, 9-FSK at
|
||||
12000.0/6912 = 1.736 baud. Eight tones are used for data, one for
|
||||
synchronization. Eight data tones means that three data bits are
|
||||
conveyed by each transmitted information symbol. Sixteen symbol
|
||||
intervals are devoted to synchronization, so a transmission requires a
|
||||
total of 206 / 3 + 16 = 85 (rounded up) channel symbols. The sync
|
||||
symbols are those numbered 1, 2, 5, 10, 16, 23, 33, 35, 51, 52, 55,
|
||||
60, 66, 73, 83, and 85 in the transmitted sequence. Tone spacing of
|
||||
the 9-FSK modulation for JT9A is equal to the keying rate, 1.736 Hz.
|
||||
The total occupied bandwidth is 9 × 1.736 = 15.6 Hz.
|
||||
|
||||
[[JT65PRO]]
|
||||
==== JT65
|
||||
|
||||
A detailed description of the JT65 protocol was published in
|
||||
{jt65protocol} for September-October, 2005. A Reed Solomon (63,12)
|
||||
error-control code converts 72-bit user messages into sequences of 63
|
||||
six-bit information-carrying symbols. These are interleaved with
|
||||
another 63 symbols of synchronizing information according to the
|
||||
following pseudo-random sequence:
|
||||
|
||||
100110001111110101000101100100011100111101101111000110101011001
|
||||
101010100100000011000000011010010110101010011001001000011111111
|
||||
|
||||
|
||||
The synchronizing tone is normally sent in each interval having a
|
||||
"`1`" in the sequence. Modulation is 65-FSK at 11025/4096 = 2.692
|
||||
baud. Frequency spacing between tones is equal to the keying rate for
|
||||
JT65A, and 2 and 4 times larger for JT65B and JT65C. For EME QSOs the
|
||||
signal report OOO is sometimes used instead of numerical signal
|
||||
reports. It is conveyed by reversing sync and data positions in the
|
||||
transmitted sequence. Shorthand messages for RO, RRR, and 73 dispense
|
||||
with the sync vector entirely and use time intervals of 16384/11025 =
|
||||
1.486 s for pairs of alternating tones. The lower frequency is the
|
||||
same as that of the sync tone used in long messages, and the frequency
|
||||
separation is 110250/4096 = 26.92 Hz multiplied by n for JT65A, with n
|
||||
= 2, 3, 4 used to convey the messages RO, RRR, and 73.
|
||||
|
||||
[[QRA64_PROTOCOL]]
|
||||
==== QRA64
|
||||
|
||||
QRA64 is an experimental mode intended for EME and other extreme
|
||||
weak-signal applications. Its internal code was designed by IV3NWV.
|
||||
The protocol uses a (63,12) **Q**-ary **R**epeat **A**ccumulate code
|
||||
that is inherently better than the Reed Solomon (63,12) code used in
|
||||
JT65, yielding a 1.3 dB advantage. A new synchronizing scheme is based
|
||||
on three 7 x 7 Costas arrays. This change yields another 1.9 dB
|
||||
advantage.
|
||||
|
||||
In most respects the current implementation of QRA64 is operationally
|
||||
similar to JT65. QRA64 does not use two-tone shorthand messages, and
|
||||
it makes no use of a callsign database. Rather, additional
|
||||
sensitivity is gained by making use of already known information as a
|
||||
QSO progresses -- for example, when reports are being exchanged and
|
||||
you have already decoded both callsigns in a previous transmission.
|
||||
QRA64 presently offers no message averaging capability, though that
|
||||
feature may be added. In early tests, many EME QSOs were made using
|
||||
submodes QRA64A-E on bands from 144 MHz to 24 GHz.
|
||||
|
||||
[[SLOW_SUMMARY]]
|
||||
==== Summary
|
||||
|
||||
Table 2 provides a brief summary parameters for the slow modes in
|
||||
_WSJT-X_. Parameters K and r specify the constraint length and rate
|
||||
of the convolutional codes; n and k specify the sizes of the
|
||||
(equivalent) block codes; Q is the alphabet size for the
|
||||
information-carrying channel symbols; Sync Energy is the fraction of
|
||||
transmitted energy devoted to synchronizing symbols; and S/N Threshold
|
||||
is the signal-to-noise ratio (in a 2500 Hz reference bandwidth) above
|
||||
which the probability of decoding is 50% or higher.
|
||||
|
||||
[[SLOW_TAB]]
|
||||
.Parameters of Slow Modes
|
||||
[width="90%",cols="3h,^3,^2,^1,^2,^2,^2,^2,^2,^2",frame=topbot,options="header"]
|
||||
|===============================================================================
|
||||
|Mode |FEC Type |(n,k) | Q|Modulation type|Keying rate (Baud)|Bandwidth (Hz)
|
||||
|Sync Energy|Tx Duration (s)|S/N Threshold (dB)
|
||||
|JT4A |K=32, r=1/2|(206,72)| 2| 4-FSK| 4.375| 17.5 |
|
||||
0.50| 47.1 | -23 |JT9A |K=32, r=1/2|(206,72)| 8| 9-FSK| 1.736| 15.6 |
|
||||
0.19| 49.0 | -27 |JT65A |Reed Solomon|(63,12) |64|65-FSK| 2.692| 177.6
|
||||
| 0.50| 46.8 | -25 |QRA64A|Q-ary Repeat Accumulate|(63,12) |64|64-FSK|
|
||||
1.736| 111.1 | 0.25| 48.4 | -26 | WSPR |K=32, r=1/2|(162,50)| 2|
|
||||
4-FSK| 1.465| 5.9 | 0.50|110.6 | -28
|
||||
|===============================================================================
|
||||
|
||||
Submodes of JT4, JT9, JT65, and QRA64 offer wider tone spacings for
|
||||
circumstances that may require them, such significant Doppler spread.
|
||||
Table 3 summarizes the tone spacings, bandwidths, and approximate
|
||||
threshold sensitivities of the various submodes when spreading is
|
||||
comparable to tone spacing.
|
||||
|
||||
[[SLOW_SUBMODES]]
|
||||
.Parameters of Slow Submodes
|
||||
[width="50%",cols="h,3*^",frame=topbot,options="header"]
|
||||
|=====================================
|
||||
|Mode |Tone Spacing |BW (Hz)|S/N (dB)
|
||||
|JT4A |4.375| 17.5 |-23
|
||||
|JT4B |8.75 | 30.6 |-22
|
||||
|JT4C |17.5 | 56.9 |-21
|
||||
|JT4D |39.375| 122.5 |-20
|
||||
|JT4E |78.75| 240.6 |-19
|
||||
|JT4F |157.5| 476.9 |-18
|
||||
|JT4G |315.0| 949.4 |-17
|
||||
|JT9A |1.736| 15.6 |-27
|
||||
|JT9B |3.472| 29.5 |-26
|
||||
|JT9C |6.944| 57.3 |-25
|
||||
|JT9D |13.889| 112.8 |-24
|
||||
|JT9E |27.778| 224.0 |-23
|
||||
|JT9F |55.556| 446.2 |-22
|
||||
|JT9G |111.111|890.6 |-21
|
||||
|JT9H |222.222|1779.5|-20
|
||||
|JT65A |2.692| 177.6 |-25
|
||||
|JT65B |5.383| 352.6 |-25
|
||||
|JT65C |10.767| 702.5 |-25
|
||||
|QRA64A|1.736| 111.1 |-26
|
||||
|QRA64B|3.472| 220.5 |-25
|
||||
|QRA64C|6.944| 439.2 |-24
|
||||
|QRA64D|13.889| 876.7 |-23
|
||||
|QRA64E|27.778|1751.7 |-22
|
||||
|=====================================
|
||||
|
||||
[[FAST_MODES]]
|
||||
=== Fast Modes
|
||||
|
||||
==== ISCAT
|
||||
|
||||
ISCAT messages are free-form, up to 28 characters in length.
|
||||
Modulation is 42-tone frequency-shift keying at 11025 / 512 = 21.533
|
||||
baud (ISCAT-A), or 11025 / 256 = 43.066 baud (ISCAT-B). Tone
|
||||
frequencies are spaced by an amount in Hz equal to the baud rate. The
|
||||
available character set is:
|
||||
|
||||
----
|
||||
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ /.?@-
|
||||
----
|
||||
|
||||
Transmissions consist of sequences of 24 symbols: a synchronizing
|
||||
pattern of four symbols at tone numbers 0, 1, 3, and 2, followed by
|
||||
two symbols with tone number corresponding to (message length) and
|
||||
(message length + 5), and finally 18 symbols conveying the user's
|
||||
message, sent repeatedly character by character. The message always
|
||||
starts with `@`, the beginning-of-message symbol, which is not
|
||||
displayed to the user. The sync pattern and message-length indicator
|
||||
have a fixed repetition period, recurring every 24 symbols. Message
|
||||
information occurs periodically within the 18 symbol positions set
|
||||
aside for its use, repeating at its own natural length.
|
||||
|
||||
For example, consider the user message `CQ WA9XYZ`. Including the
|
||||
beginning-of-message symbol `@`, the message is 10 characters long.
|
||||
Using the character sequence displayed above to indicate tone numbers,
|
||||
the transmitted message will therefore start out as shown in the first
|
||||
line below:
|
||||
|
||||
----
|
||||
0132AF@CQ WA9XYZ@CQ WA9X0132AFYZ@CQ WA9XYZ@CQ W0132AFA9X ...
|
||||
sync## sync## sync##
|
||||
----
|
||||
|
||||
Note that the first six symbols (four for sync, two for message
|
||||
length) repeat every 24 symbols. Within the 18 information-carrying
|
||||
symbols in each 24, the user message `@CQ WA9XYZ` repeats at its own
|
||||
natural length, 10 characters. The resulting sequence is extended as
|
||||
many times as will fit into a Tx sequence.
|
||||
|
||||
==== JT9
|
||||
|
||||
The JT9 slow modes all use keying rate 12000/6912 = 1.736 baud. By contrast, with
|
||||
the *Fast* setting submodes JT9E-H adjust the keying rate to match the
|
||||
increased tone spacings. Message durations are therefore much
|
||||
shorter, and they are sent repeatedly throughout each Tx sequence.
|
||||
For details see Table 4, below.
|
||||
|
||||
==== MSK144
|
||||
|
||||
Standard MSK144 messages are structured in the same way as those in
|
||||
the slow modes, with 72 bits of user information. Forward error
|
||||
correction is implemented by first augmenting the 72 message bits with
|
||||
an 8-bit cyclic redundancy check (CRC) calculated from the message
|
||||
bits. The CRC is used to detect and eliminate most false decodes at
|
||||
the receiver. The resulting 80-bit augmented message is mapped to a
|
||||
128-bit codeword using a (128,80) binary low-density-parity-check
|
||||
(LDPC) code designed by K9AN specifically for this purpose. Two 8-bit
|
||||
synchronizing sequences are added to make a message frame 144 bits
|
||||
long. Modulation is Offset Quadrature Phase-Shift Keying (OQPSK) at
|
||||
2000 baud. Even-numbered bits are conveyed over the in-phase channel,
|
||||
odd-numbered bits on the quadrature channel. Individual symbols are
|
||||
shaped with half-sine profiles, thereby ensuring a generated waveform
|
||||
with constant envelope, equivalent to a Minimum Shift Keying (MSK)
|
||||
waveform. Frame duration is 72 ms, so the effective character
|
||||
transmission rate for standard messages is up to 250 cps.
|
||||
|
||||
Contest Mode in MSK144 conveys an additional acknowledgment bit (the
|
||||
"`R`" in a message of the form `W9XYZ K1ABC R FN42`) by using the fact
|
||||
that meteor scatter and other propagation modes usable with MSK144 are
|
||||
generally effective only out to distances of order 2500 km. To convey
|
||||
the message fragment `R FN42`, WSJT-X encodes the locator as that of
|
||||
its antipodes. The receiving program recognizes a locator with
|
||||
distance greater than 10,000 km, does the reverse transformation, and
|
||||
inserts the implied "`R`".
|
||||
|
||||
MSK144 also supports short-form messages that can be used after QSO
|
||||
partners have exchanged both callsigns. Short messages consist of 4
|
||||
bits encoding R+report, RRR, or 73, together with a 12-bit hash code
|
||||
based on the ordered pair of "`to`" and "`from`" callsigns. Another
|
||||
specially designed LDPC (32,16) code provides error correction, and an
|
||||
8-bit synchronizing vector is appended to make up a 40-bit frame.
|
||||
Short-message duration is thus 20 ms, and short messages can be
|
||||
decoded from very short meteor pings.
|
||||
|
||||
The 72 ms or 20 ms frames of MSK144 messages are repeated without gaps
|
||||
for the full duration of a transmission cycle. For most purposes, a
|
||||
cycle duration of 15 s is suitable and recommended for MSK144.
|
||||
|
||||
The modulated MSK144 signal occupies the full bandwidth of a SSB
|
||||
transmitter, so transmissions are always centered at audio frequency
|
||||
1500 Hz. For best results, transmitter and receiver filters should be
|
||||
adjusted to provide the flattest possible response over the range
|
||||
300Hz to 2700Hz. The maximum permissible frequency offset between you
|
||||
and your QSO partner ± 200 Hz.
|
||||
|
||||
==== Summary
|
||||
|
||||
.Parameters of Fast Modes
|
||||
[width="90%",cols="3h,^3,^2,^1,^2,^2,^2,^2,^2",frame="topbot",options="header"]
|
||||
|=====================================================================
|
||||
|Mode |FEC Type |(n,k) | Q|Modulation Type|Keying rate (Baud)
|
||||
|Bandwidth (Hz)|Sync Energy|Tx Duration (s)
|
||||
|ISCAT-A | - | - |42|42-FSK| 21.5 | 905 | 0.17| 1.176
|
||||
|ISCAT-B | - | - |42|42-FSK| 43.1 | 1809 | 0.17| 0.588
|
||||
|JT9E |K=32, r=1/2|(206,72)| 8| 9-FSK| 25.0 | 225 | 0.19| 3.400
|
||||
|JT9F |K=32, r=1/2|(206,72)| 8| 9-FSK| 50.0 | 450 | 0.19| 1.700
|
||||
|JT9G |K=32, r=1/2|(206,72)| 8| 9-FSK|100.0 | 900 | 0.19| 0.850
|
||||
|JT9H |K=32, r=1/2|(206,72)| 8| 9-FSK|200.0 | 1800 | 0.19| 0.425
|
||||
|MSK144 |LDPC |(128,72)| 2| OQPSK| 2000 | 2400 | 0.11| 0.072
|
||||
|MSK144 Sh|LDPC |(32,16) | 2| OQPSK| 2000 | 2400 | 0.20| 0.020
|
||||
|=====================================================================
|
||||
Reference in New Issue
Block a user