En mode V.23, un contrôle de flux n’est pas forcément nécessaire au vu de la vitesse faible de 1200 bauds (sans prendre en compte le mode tuyau)
En mode V.29/V.27ter (TVR), c’est inclus dans le protocole en couche 3 (voire 2) dans les deux sens (pareil, sans prendre en compte le mode tuyau)
En prise périphérique, je crois que le contrôle de flux est activé par défaut et informe uniquement si le « buffer » de données en attente de traitement (/ transmission modem en mode tuyau, j’imagine) est bientôt rempli.
Donc dans le sens périphérique => minitel, les données en surplus sont « abandonnées », et dans le sens minitel => périphérique, le module qui gère ça informe en cas de changement d’état (bientôt rempli / prêt à recevoir)
Je découvre encore le STUM Magis Club, donc c’est sûrement pas tout juste
Alors je ne sais pas si ça peut aider, mais dans mon cas, en 9600 bauds, sur Hyperterminal, j’ai obtenu les meilleurs résultats en réglant le contrôle de flux sur aucun.
Après lecture du STUM Magis Club, en effet il est possible d’envoyer une matrice de quantification avec le fichier JPEG (il suffit d’envoyer avec les paramètres 0x01, 0x7F, 0x03) - testé sur Magis Club à l’instant.
De même, le mode de translation pour 7 bits est fonctionnel (pas encore testé avec un modem)
C’est marrant ça, mais comme le temps entre le 2100 Hz et le 1300 Hz sur minipavi est assez élevé (1 seconde), le Magis Club tente de se connecter en TVR et envoie une séquence V.29 train long (Cc @ludojoey). Néanmoins rien qui l’empêche de se connecter.
SpanDSP ne gère pas les trains courts, et il « recalcule » les coefficients à chaque fois. Il faudra le forker et modifier son code pour lui permettre de réutiliser ces coefficients (et lui permettre d’utiliser les trains courts par la même occasion).
EDIT: il possède un paramètre pour réutiliser les coefs précédents - il n’y a qu’à rajouter le train court
J’ai pu ajouter le train court dans le fork de spandsp (en considérant que les données sont en format court uniquement si il n’y a pas de porteuse — ce que semble faire le Minitel puisque si j’ajoute la porteuse avant des données courtes, plus rien ne fonctionne)
V29. Et en effet en ajoutant le 2100 Hz au début (comme indiqué dans stum magis Club), on obtient bien l’écran de Connexion.
Plus intéressant encore : on peut faire facilement un serveur qui supporte à la fois V.23 et V.29. minipavi laisse 1 seconde entre le 2100 Hz et le 1300 Hz, ce qui donne au Minitel du temps pour tenter de se connecter en V.29. On peut donc chercher à voir si le Minitel tente de se connecter en V.29 pendant ce lapse de tempsa, ou basculer en V.23 dans le cas contraire
Bon, pour résoudre mon problème d’écho, j’ai actuellement 2 approches que j’utilise en simultané :
Transmettre 3x une séquence de bits qui ne peut pas être transmise par le Minitel (à priori). Si je la reçois au moins une fois, c’est qu’il s’agissait de mes propres données (et donc de ne pas chercher à y répondre)
Calculer la latence grâce au 2100 Hz que je dois transmettre. Je mémorise le temps auquel j’arrête sa transmission, puis je détermine le temps auquel j’arrête de le recevoir. Cette méthode peut rencontrer des problèmes en cas d’annulation d’écho adaptative (je pourrais partiellement recevoir ma fréquence)
Je suis toujours preneur pour d’autres idées ou de critiques sur ces idéés
Voici de nouvelles pages que j’ai faite avec le logiciel pic2jpeg2vdt de @nathaantfm. Merci encore à lui, sans son aide je pense que je n’y serais pas arrivé.
Edit : J’ai pu afficher des images en plein écran en les envoyant directement via pic2jpeg2vdt.
Donc c’était bien la communication avec Hyperterminal qui posait problème. Dans certains cas, si on ne met pas un délais de de minimum 0.1, ça part en cacahuète.
nathaantfm a trouvé le moyen de faire tourner son logiciel sur mon PC Windows XP, qui est la machine la plus récente que je possède à avoir un port série. Merci encore à lui
Edit 2 : Les deux dernières photos ont été prises avec un Apple QuickTake 150, un des premiers numériques « Grand public » de 1995!
Beau progrès, avec le train court. Je ne comprends pas bien ton problème d’écho. J’étais justement en train de regarder SANDSP, il semble y avoir tout ce qu’il faut pour HDLC (dans la distrib issue de PhreakNet que j’utilise - vais aucune idée de la version !).
==> Peux-tu préciser la version que tu utilises ? L’auteur [steeve underwood ?] semble avoir cessé sa MAJ en 2013, en v 0.6, et il y a déjà un support pour le v42bis.
J’utilise spandsp du fork de freeswitch, qui supporte en effet HDLC mais c’est la partie la plus simple du protocole (que j’ai ré-implémenté, puisque le HDLC du X.25 est une version « réduite »).
Le problème d’écho vient de ma ligne fixe VoIP (pas sur le serveur). Doit y avoir une différence au niveau de la résistance de la ligne, ce qui fait que le serveur reçoit tout ce qu’il envoie avec un décalage de 200 ms (et en plus faible). De ce fait, puisqu’il n’y a pas de distinction dans les données envoyées par le client ou par le serveur dans le protocole (il y a un octet d’adresse, mais il ne peut pas servir à ça…), alors je peux recevoir ma propre requête ou réponse.
Le problème avec ça, c’est qu’on doit répondre à un packet dès sa réception (peu importe la réponse ou le contenu), ce qui fait que lorsque le serveur envoie un message vers ma ligne fixe (VoIP), il reçoit ensuite son propre message suivi de la réponse du Minitel. En cas d’absence de réponse du Minitel (et si le serveur n’arrive pas à identifier qu’il s’agit de son propre message), il peut partir dans une boucle où il se répond continuellement.
Le Stum Magis Club partagé dans le premier message facilite pas mal le boulot d’implémentation du protocole, mais j’ai fait une pause sur le projet pour le moment. J’ai diverses solutions côté serveur pour l’écho qui fonctionnent, mais quelque chose de plus fiable serait la bienvenue.
