Enregistrement audio des essais du chauffe plat Thomson sur les différents serveurs avec le Chauffe Plat Thomson⁹

Bonjour,

J’ai fait des enregistrements audio de mes connexion aux différents micro-serveurs avec mon Chauffe Plat Thomson sur ma ligne VOIP Freebox.

Ceux pour qui ça fonctionne :

-HACKER

-IUT D’AUXERRE et sa démo (Ça a coupé brusquement sur la première tentative serveur après quelques minutes, mais pas à la deuxième. On peut donc considérer que c’est bon) :

-MINIPAVI (Sans PCE)

Une petite spécificité par contre, c’est l’utilisation de la touche connexion/fin.

À savoir que lorsque j’ai fait le code « SNCF »+Envoi, puis connexion/fin, pour revenir au sommaire, j’ai pu alterner entre guide et sommaire sans soucis. Je suis donc bien revenu au sommaire.

Mais lorsque j’étais au sommaire, au moment de faire connexion/fin pour me déconnecter une bonne fois pour toute, le serveur n’a pas raccroché, mais plus aucune touche ne faisait quoi que ce soit. Impossible d’alterner entre sommaire et guide, et obligation de raccrocher manuellement en rappuyant sur connexion fin.
Cela s’entend à la fin des enregistrements 1 et 2

En revanche, si je me contente d’alterner entre sommaire et guide, la touche connexion/fin fait bien raccrocher le serveur. Cela s’entend sur l’enregistrement 3

Est-ce une spécificité du Chauffe Plat Thomson, ou est-ce le fonctionnement normal de MINIPAVI (En tout cas sans PCE)?

NOTEL :

Ceux pour qui ça ne fonctionne pas :

HYTREL :

Le chauffe plat perd la porteuse à 42 secondes sur l’enregistrement.

JELORA :

Il prend et tient la porteuse mais impossible de naviguer. Le son de la porteuse est vraiment bizarre d’ailleurs. On dirait que le serveur attend un signal émis par le Minitel pour envoyer les pages, comme pour la PCE de MINIPAVI

MINIPAVI avec PCE :

Là le serveur attend clairement la réponse à la demande de PCE avant d’envoyer les pages

Désolé pour la qualité médiocre des enregistrements, mais n’ayant pas de matériel pour enregistrer depuis une source téléphonique, j’ai simplement utilisé mon smartphone en mode dictaphone, en posant le micro contre l’écouteur d’un téléphone décroché branché sur la prise en T « gigogne » du chauffe plat. Cela permet aussi la numérotation depuis une box qui ne prendpasen charge les impulsions.

Pour l’instant je navigue à l’aveugle, j’attends le câble vidéo qu’un ami doit me fabriquer.
Ce sera sympa de voir comment rendent les pages!

Cordialement.

Que soit activée la PCE ou pas n’a pas d’impact sur la gestion de tout cela. La PCE est gérée à un autre niveau.
J’ai fait le même test que toi avec mon M12, et le comportement est normal : un appui sur connexion/fin à l’accueil interrompt la connexion, que l’utilisateur ai été sur un service ou non préalablement.
D’ailleurs, je ne vois pas d’un point de vue de mon dev comment cela pourrait avoir un impact.
Le mieux sera de refaire un test avec image.
En attendant, tu peux refaire ton test, et me dire rapidement la date/heure de ton test afin que je regarde dans mes logs.

Bonjour, merci pour ta réponse,

Alors tests sans PCE et navigation SNCF, puis blocage connexion fin, c’était

-Le 08/12/2024 à 18h19, connexion environ 3 minutes.

-Le 08/12/2024 à 18h27, là aussi connexion environ 3 minutes.

Test Sans code SNCF juste sommaire et guide :

-Le 08/12/2024 à 18h30/31 environ 1 minute

Je me fie à la date de création des fichiers son complets qui je pense ont été créé une fois l’enregistrement et donc la navigation terminée. Cela pourra te donner une fourchette pour les logs.

-Fichier connexion code SNCF puis allez retour sommaire/guide et blocage connexion fin numéro 1 Date de création : 08/12/2024 18h22

-Fichier connexion code SNCF, puis allez retour sommaire/guide et blocage connexion fin numéro 2 Date de création : 08/12/2024 18h30

-Fichier connexion sans code juste allez-retour entre Guide et Sommaire. Touche Connexion Fin qui fait bien raccrocher le serveur Date de création 08/12/2024 18h32

Pour refaire des tests, c’est quand même un setup compliqué, il vaut mieux attendre d’avoir le câble vidéo pour voir ce qui s’affiche.

Cordialement.

Je n’ai plus les enregistrements de cette date.
Si tu veux, tu peux refaire un test et me dire date et heure.
Après, cela pourrait être plus utile d’attendre ton câble video !

C’était hier pourtant, tu effaces vite.

On va attendre le câble vidéo

Cordialement.

@ludojoey Salut, j’ai maintenant un câble vidéo pour mon Chauffe Plat Thomson.

J’ai refait le même test que la dernière fois, et la déconnexion s’est passé normalement.

J’ai fait le test le 28/12/2024 à 18h31 pendant 3 minutes si tu veux regarder les logs.

Cordialement.

1 « J'aime »

Super!

Oui j’ai vu, tu as fais plusieurs fois SNCF.
Si ca marche, tant mieux !

Pour info, ce minitel ne renvoi pas d’identification il semble !

En principe, si … Il devrait même avoir RAM1 et RAM2

Bah je sais pas… Lors de sa connexion, j’ai rien reçu…peut être un soucis de transmission…

C’est un « prototype », pas sûr qu’il ait cette fonction

Ayant maintenant un câble vidéo, je peux ajouter des images de ce que le chauffe plat affiche lors des échecs

Pour Jelora :


@ludojoey Pour Minipavi avec PCE


Au passage pour Minipavi, il y a des petits soucis:

-La touche # donne un & sur le sommaire Minipavi. En revanche sur les serveurs externe comme HACKER, elle donne bien un #.

-Lorsque je tape, lors de la saisie, certains caractères ne sont pas affichés à l’écran, et ce de façon aléatoire. Exemple, je tape le mot « GATEAU » ça va m’afficher « GAEAU ».
C’est problématique, surtout pour les serveurs externes RTC. Là où c’est bizarre, c’est qu’ils ont l’air d’être pris en compte, en tout cas par les serveurs externes. Le problème vient peut-être de la transmission en VOIP, surtout avec son modem 100% discrets

Edit : @ludojoey @hwarin D’après ce document :

Sur les chauffe plats, il y a bien je cite : « Un dispositif permettant l’identification automatique du terminal à distance ». Cependant, c’est assez vague comme description. On ne sait pas si ça identifie le modèle du terminal, l’exemplaire (Par le numéro de série), ou autre. Ni comment ça fonctionne réellement. Peut-être que ça fait référence aux fameux « Mouchards »

Cordialement.

1 « J'aime »

Merci pour le retour. Oui ces problèmes de caractères viennent de problèmes de transmission via la VoIP. Surtout pour les appels sortants vers d’autres serveurs. En plus, toi tu n’utilises pas la PCE, donc il peut aussi y avoir plus de soucis sur la liaison minipavi->toi.

Merci pour ta réponse. En revanche, pour la # qui donne &, là ce ne sont pas des erreurs de transmission je pense. C’est dû à quoi d’après toi?

Cordialement.

Différence # (émis) et & (reçu) …

‹ # = 00100011 ›
‹ & = 00100110 ›

En vrai, en incluant les start et stop, la transmission est :
‹ # = 1001000111 ›
’ & = 1001001101’

  1. Même parité (nombre impair de bits placés => 0 - l’inverse serait aussi vrai) ==> Erreur de parité non détectable (avec ou sans PCE (*) ni autre méthode complémentaire)
  2. 2 bits sont permutés
  3. L’hypothèse ‹ mauvaise horloge › (un zéro manquant/perdu) serait invalidée (puisque le stop serait bien détecté) ==> C’est du « Jitter » (de la Gigue (électronique) — Wikipédia - voir aussi et surtout https://fr.wikipedia.org/wiki/Gigue_(informatique) (**))

(*) La PCE n’existe que sur le flux descendant (1200 Bps) et non pas montant (75 Bps). Elle n’aurait aucun sens d’ailleurs à 75 Bps. Eventuellement, vérifier si ‹ # › ou ‹ & › a initialement été reçu par MiniPavi pour déterminer où (sur quel lien) l’erreur est apparue.

(**)

  • En TCP, les paquets arrivent dans l’ordre et intègres, au prix d’une latence pouvant être plus ou moins grande
  • En UDP, les paquets arrivent ‹ au mieux › et ‹ au plus vite › mais sans garantie d’intégrité, de livraison, ni même de latence (2 paquets peuvent prendre 2 routes différentes)
  • Dans le monde de la modulation audio (la voix), lorsqu’une liaison [radio, téléphonique, etc] est établie, la bande passante peut être faible (entrainant une limitation du débit possible), l’intégrité n’est pas totalement nécessaire (entrainant la production de parasites qui peuvent être filtrés), mais il ne devrait pas pouvoir y avoir de notion de latence - au pire, du silence mais jamais de décalage temporel dans un flux, à moins que l’émetteur et le récepteur ne s’éloignent/se rapprochent à des vitesses très élevées. (Et même dans un tel cas, ce décalage serait prévisible)

La VoIP n’est pas adaptée pour transporter la donnée modulée par des modems, point ! (T38 et V150 n’ont pas été ‹ inventés › pour rien)

Comme Wikipedia est mon ami (et que j’y contribue, au moins financièrement), un peu de lecture pour cette fin d’année quelque peu désastreuse (mais probablement moins pire que celles qui s’annoncent)

« The Cisco V.150.1 Minimum Essential Requirements (MER) feature complies with the requirements of the National Security Agency (NSA) SCIP-216 Minimum Essential Requirements for V.150.1 recommendation, which provides for four states: audio, voice-band data (VBD), modem relay, and T.38. This feature is added in CUBE (IP-IP gateway) for V.150.1 calls to traverse a CUBE in SDP passthrough flow-through mode. »

D’ailleurs, quelques recherches sur « SCIP-215 » et « SCIP-216 » montrent à quel point les grandes oreilles se sont penchées sur la question.

1 « J'aime »

Voila une réponse bien complète !

Ceci dit, @Polo (si j’ai bien interprété son message) semblait dire que symptôme « # » transformé en « & » n’arrivait que sur l’accueil Minipavi, et était systématique (tous les # transformé en &).

Si tel est le cas (@Polo peut confirmer ou pas), ben, je n’ai aucune explication sachant que je ne fait pas de « transformation » sur les caractères qui sont reçus. Donc, cela resterait un mystère !

J’aurais tendance à croire que @Polo voulait dire que cela était plutôt aléatoire, et je rejoindrait donc l’explication de @hwarin

@Polo: si tu veux refaire un essai : si tu tapes # + GUIDE tu dois arriver sur la page plus d’infos.
Si quand tu tapes ca t affiche & et que tu vas quand même sur la page « plus d’infos », c’est que le # a bien été reçu, et c’est l’echo qui est mal transmis.

Bonjour Ludojoey,

Alors sur ton serveur, ce n’est pas aléatoire, la touche # donne systématiquement des & sur la page d’accueil.

En revanche, sur les serveurs externes elle donne bien des # .

Cordialement.

Et quand tu vas sur un service minpavi (meteo, prog tv etc…), pareil ?

Je testerais demain, là je ne suis pas chez moi

Bonjour @ludojoey et bonne année :slight_smile:

Voici mon rapport d’essai :

Essais effectué le 01/01/2025, à partir de 20h17 durant 55 minutes.

Deuxième essais effectué le 01/01/2025 à partir de 21h17 durant 10 minutes pour des vérifications supplémentaires sur NOTEL

20 appuis sur la touche # = 19 & à l’écran sur la page d’accueil

Problème présent sur le service météo.
Problème présent sur SNCF
Problème présent sur TV6
Parfois, la touche annulation ou connexion fin donne un « S »

Sur HACKER 10 appuis sur # = 9 # et un s au quatrième appuis. En revanche, la touche correction ne fonctionne pas alors qu’elle fonctionne sur la page d’accueil.

IUT AUXERRE : Même Problème, les # donnent toujours des &, mais la touche correction fonctionne.

Hytrel : La touche # donne bien des #, et la touche correction fonctionne. À un moment, la touche # a activé le mode graphique.

En revanche gros problèmes de saisie. Impossible de saisir correctement mon pseudo. Même si il s’affiche correctement à l’écran, il n’est jamais correctement pris en compte. Il y a des erreurs de communication entre ton serveur et moi, et entre ton serveur et Hytrel. Donc erreurs+erreurs, ça empire les choses.

Notel : La touche # donne systématiquement des & aussi. Pas de curseur affiché. À un moment, la touche Envoi a aussi fait un &. À un moment, la touche # a mis le chauffe plat en mode caractères graphique. La touche répétition ne fonctionne pas dans le chat.

Cordialement.

Edit : En connexion direct, Notel a le même problème de # qui donne des & pas de curseur et la touche répétition ne fonctionne pas dans le chat.

Edit : Même Problème sur IUT AUXERRE en connexion direct

Edit : En passant par IUT AUXERRE, sur HACKER, la touche # donne bien un # . Pareille lorsqu’on on se connecte à Hytrel via IUT Auxerre+Mini Pavi. Par contre, connexion très mauvaise, la saisie se remplit toute seule de parasites (Carrés blancs ou « ? » L’envers) Décidément, les modems en composants discrets sont extrêmement sensibles à la VOIP…

Edit @hwarin @jhr : J’ai utilisé la fonction « lire RAMS&ROM » de HACKER avec le chauffe-plat Thomson, et j’ai obtenu le résultat suivant :

Ce code vous dit quelque chose ?
Comme avec mon Minitel 2, il est impossible d’écrire dans la RAM. Même si le serveur dit que le mot a été enregistré, quand on utilise à nouveau la fonction « lire RAMS&ROM », on constate que rien n’a été enregistré. En revanche, sur mon Minitel 2, il n’y a rien de marqué à la ligne « ROM »

1 « J'aime »

Merci pour l’ensemble de tes essais.

Pour les erreurs de transmission en général lors de la connexion à un serveur « RTC » via MiniPavi, cela est « normal ». Malgré un réglage fin et différent des volumes et niveau de sensibilité pour chaque serveur, je ne peux obtenir hélas mieux.

Cela dit, j’ai parfois moi-même des transmissions un peu brouillées en me connectant directement depuis mon M12 (Hytrel, ou impossible, comme Jelora). En règle générale, il semble que les meilleurs connexions se font quand le serveur utilise un Minitel retourné comme modem.

Pour en revenir au « & », franchement je n’ai aucune idée.

De mon côté je ne fais pas de traitement de telle sorte (remplacer un caractère par un autre).

J’ai pu vérifier que je reçoit un « & ». Donc ce n’est pas un soucis de l’echo.

Le fait que le problème arrive également sur d’autres serveurs en connexion directe me laisse penser que le soucis proviendrait plus du chauffe-plat, mais quel soucis exactement, je n’en sais rien ! (une séquence inconnue qui le mettrai dans un mode spécial qui envoi & au lieu de # ?
Bizarre et peu probable, mais bon, pourquoi pas ?!)

Peut-être @hwarin a t-il une idée ?!

Pour l’identification , je n’ai rien reçu…