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: