Hello Simon,
Glad you are interested (and very widely in advance).
I knew Python only as a snake, nice to learn something...
For instance, I have written some own specifications in French (see hereafter
but I'm not very sure of them).
About the source code, I have:
* a file which name is WSJT-5[1].9.2-r115.tgz (I don't remember how I get it)
with many files and
* a file which name is JT65code.gz which seems to be the source code of a soft
called SimJT, used to only transmit JT65 frames.
Do you have the same or different sources?
73
Patrick
JT65
Créateur : Joe Taylor (K1JT) en 2004
Description :
Vitesse en bauds: 2,69 (11025/4096) soit 0,372 seconde par symbole de 6 bits
Messages : un message d'une durée de 46.8 secondes qui commence à t=1 sec après
le début de la minute UTC et se termine à t=47,8 sec (il faut que le PC soit
synchronisé sur le WEB...). Il est composé de 126 symboles de 6 bits, chacun
ayant une longueur de 4096 échantillons audio (0,372 seconde). 63 portent une
tonalité de synchronisation à 1270,5 Hz. 63 symboles portent les 72 bits du
message.
Les 72 bits comprennent:
* call1 (28 bits) + call2 (28 bits) + Locator 4 caractères (15 bits) plus le
bit 72 permettant de dire s'il s'agit d'un texte libre ou d'un texte
pré-formatté,
* call 1 + call 2 (+ pre ou postfixe exemple: G4ABC/P ou ZA/PA2CHR) + plus le
bit 72
* call 1 (+ pre ou postfixe exemple: G4ABC/P ou ZA/PA2CHR) + call 2 plus le bit
72
* CQ décalage (113 p.e) call Locator bit 72, R-NN ou -NN (-25 dB p.e) peut
remplacer le Locator,
* du texte libre 13 caractères (71 / log2(43)) avec 72 bits et 43 caractères
possibles
IMPORTANT: le décodage se fait à l'issue de l'émission
Vitesse : 72 bits (soit 13 caractères max en texte libre) par période de 60
sec (avec un message par période) soit 2,2 mpm
Modulation : FSK 65 tonalités (64 tonalités pour les 6 bits plus une tonalité
de synchronisation) avec un écart entre tonalités de 2,69 Hz (1x vitesse en
bauds) en mode A, 5,4 Hz (x2) en mode B, 10.7 Hz (x4) en mode C, sauf entre la
tonalité de synchronisation (1270,5 Hz) et le caractère " 0 " (écart de 5,4 Hz
=2 x vitesse en bauds en mode A, 4 x en mode B et 8 x en mode C).
Les fréquences du JT44 sont fixées entre 1270,5 Hz (tonalité de
synchronisation) et 1270,5 + 2.6917 (N+2) m Hz avec N valeur entre 0 et 63 du
caractère et m pour 1 2 ou 4 pour les sous-modes A, B et C. La tolérance sur la
fréquence de synchronisation est de +/- 600 Hz,
La tonalité de synchronisation (détectée avec une précision de +/- 1,5 Hz (+/-
3 Hz d'après WSJT 4.7 en français) et 0,03 sec pour la récupération de rythme)
est émise suivant une séquence pseudo-aléatoire (fonction d'auto-corrélation en
forme de pic autour du retard nul).
Le pseudo-bit "OOO" (pour les 2 calls reçus mais message recu par
intermittence") est envoyé en inversant la séquence pseudo-aléatoire (un peu
comme en Olivia avec la transformation Hadamard), les "1" passant en "0" et
inversement.
WSJT cherche la fréquence de synchronisation sur +/- 600 Hz car les QSO's EME
peuvent avoir des décalages en fréquence (Doppler) importants.
Démodulation : décimation /2 pour aller de Fe=11025 à Fe=5512. FFT glissant
sur 2048 points (delta f=2,69 Hz donc une précision de +/- 1,4 Hz en se basant
sur la raie la plus puissante.
0,03 sec indique que la distance temporelle entre FFT est de 0.06 s soit
5512*0.06=330 échantillons.
Mode de réception: USB par convention (?). Chaque période de 60 sec d'émission
et de réception doit commencer sur une minute + 1 sec (t=1) avec une tolérance
sur l'horloge de -2 à 4 secondes (? non vu), le décalage en temps pour les QSO
EME est d'environ 2,5 secondes (aller-retour Terre/Lune + temps de commutation
des XCVR).
Jeu de caractères : ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.,/#?$ <ESPACE> (pas
de caractère de correction d'erreur) (?)
Bande passante: 175 Hz en mode A, 350 Hz en mode B, 700 Hz en mode C,
Synchronisation: automatique en utilisant la tonalité de synchronisation
Code correcteur: Reed Solomon (63, 12) soit 63 symboles de 6 bits pour 12
symboles de 6 bits d'information (soit un rendement de 0,19.
IMPORTANT: la démodulation Reed Solomon de type soft-decision est basée sur un
algorithme original (cf p10 "The JT65 communications protocol " )
Code de convolution: non
Entrelacement : après le Reed-Solomon, les 63 symboles sont entrelaçés
(écriture ligne par ligne dans une matrice 7x9 et lecture colonne par colonne,
pas clair). Les bits finaux passent à travers un codage Gray avant d'être émis.
Plus bas S/B pour une copie à 96 %: -23 dB (pour un bruit blanc de 2,5 KHz de
bande passante). Il est possible de moyenner le même message grâce au signal de
synchronisation qui permet d'être sûr que l'on a affaire à un message JT65B.
(-1 en JT65A et +1 en JT65C)
Note: si l'on envoie des messages connus à l'avance (indicatifs connus à
l'avance) on cherche plus loin ("Deep search") et on atteint -27 dB (en JT65B,
-1 en JT65A et +1 en JT65C)
----- Original Message -----
From: Simon Brown
To: digitalradio@yahoogroups.com
Sent: Thursday, December 27, 2007 2:50 PM
Subject: Re: [digitalradio] JT65 - work in team
No only am I interested, I am ahead of you - I hope to have this working with
a C++ engine under Windows by about the end of March 2008. Originally I was
targeting end of 2007 but decided to add SSTV support before finishing WSJT.
The WSJT code is Fortran, Python and C (I think) which is very easy to
understand.
The encoding / decoding will be in a Windows DLL with all source available.
Simon Brown, HB9DRV
----- Original Message -----
From: Patrick Lindecker
I think the only solution (at least for me) would be to work in team. The
goal would be:
