ModulAM : conception, essais et mesures

Je m’aperçois que je n’ai pas répondu à votre question en ce qui concerne le loudness et le ModulAM.
J’ai déterminé le coefficient moyen, comme expliqué, par itération successive plutôt qu’en me référant à un dogme…
Car sur les différentes plateformes de diffusion, chacun fait ce que bon lui semble.
Quelques exemples :
Soundcloud : -10 LUFS
Amazon Music : -11 LUFS
Youtube : -14 LUFS
Spotify : -14 LUFS
Deezer : -15 LUFS
Apple Music : -16 LUFS

Et c’est la même chose sur les flux gérés par les stations de radiodiffusion !

De plus certains considèrent (en fonction de ce qui leur permet d’aller plus « haut ») que la méthode de mesure du LUFS n’est pas adaptée à leur style de modulation.
Alors ils privilégient soient la méthode dite « integrée » (la plus souvent employée en mastering studio) soit la méthode dite « à court terme » qui différencie par exemple les voix off de la musique, voire pour un même morceau, le refrain du couplet…

Alors, avec tout cela, allez donc afficher une valeur de référence… :thinking:

Bonjour,

ne connaissant pas les LUFS j’ai trouvé ce blog que je trouve assez pédagogue.

Bonne journée

2 « J'aime »

Bonjour Daniel et Grocrabe,

Daniel, je vais prendre le temps de lire en détail votre article. L’information est dense, alors plutôt que de revenir avec des questions sans intérêt, je préfère bien creuser tout cela au au préalable.

Ce que je souhaiterais arriver à cerner en première étape, c’est de déterminer une valeur LUFS convenable vis à vis du ModulAM pour des extraits MP3 reposant sur des fréquences discrètes (400 Hz, sweep …). J’ai lu que dans votre feuille de route, qu’il est prévu d’intégrer de tels signaux de tests. J’avoue ne pas avoir eu le temps d’installer la v1.1, et par conséquent de voir si de tels fichiers ont été intégrés.

Ensuite dans, l’hypothèse où l’on considère que la source de départ est un CD pour créer un fichier MP3, OGG ou FLAC, d’évaluer où se situerait une valeur LUFS convenable, comparativement au cas de figure des fréquences discrètes. Je suppose qu’une source CD est au départ moins triturée au plan de la dynamique et autres tortures, qu’un flux web. La compression imposée par FLAC en aval d’un CD serait également peut-être un plus. Mais je me fourvoie peut-être complètement dans mes raisonnements … Là, je vais devoir faire un break d’une bonne semaine, avant que de revenir sur ces sujets.

Merci encore pour toutes ces informations, qui au passage démontre que le ModulAM a aussi une vocation pédagogique !

Jean-Roger

1 « J'aime »

Bonjour,
Mon pauvre ami si voyiez les horreurs que les masters cd subissent de nos jours, vous seriez horrifié. Sauf peut-être en classique et Jazz.

Allez, une dernière amélioration.
Lors du changement de stations il manque le bruit de fond des parasites entre les deux émotteurs.
Oui je sais, j’abuse et j’exagère, mais qui ne demande rien n’aura rien !

Encore un grand merci à toute l’équipe de ce projet.

2 « J'aime »

Tu n’a qu’à construire un générateur de parasites, c’est pas trop compliqué …

Digression autour du ModulAM :

Pourquoi ne pas permettre à un récepteur couplé au ModulAM de recevoir aussi et simultanément, quelques stations hertziennes et donc tous les bruits de bande qui vont avec ?

En tant que « dérangé » de la radio :crazy_face: j’ai réalisé une manip qui replace le récepteur dans un contexte « hertzien » réaliste.

Le soir, en PO, avec une bonne antenne, on capte encore des stations qui arrivent avec un bon niveau (je suis sur Bordeaux et les stations espagnoles arrivent « canon » dès 17 h).

J’ai réalisé ce montage :

Même en raccordant l’antenne directement sur la ferrite de couplage (flèche verte, donc sans le préampli) la CAG du récepteur fait son travail et remonte le niveaux des stations hertziennes, avec un confort acceptable et en tout cas, des plus réalistes !

Additionné avec les 8 stations du ModulAM, mon récepteur est revenu 50 ans en arrière ! avec une bande PO très encombrée et pas mal de bruit industriel entre les stations sur les GO.

Le bonheur total :nouvelan2:

4 « J'aime »

Bonjour

Et si c’était pas une si mauvaise idée ?

Pour ne pas polluer ce fil consacré aux évolutions du projet ModulAM, j’ai rédigé une synthèse d’une manip que j’ai réalisé et qui répond à peu près à votre idée, dans le fil consacré aux tests et essais.

Essayez, c’est bluffant de réalisme !
:dino:

2 « J'aime »

Je vais essayer cela mais cela sera la semaine prochaine.
Très bonne idée. J’aurai du y penser tout seul, mais bon on ne rajeuni pas !

2 « J'aime »

@DWK @Eduard_Hontele

Bonjour Daniel, Eduard,

Vous avez peut-être aperçu ce projet d’émetteur AM conçu par Elektor :

https://www.elektor.fr/products/elektor-am-transmitter-kit

Il faut croire que le ModulAM leur a donné des idées, même si le seul tronc commun soit l’utilisation d’un Raspberry Pi Pico. Je n’ai cependant pas bien saisi comment à partir des deux sketchs arduino, la modulation AM est générée.

C’est juste pour information, mais il est toujours intéressant d’avoir un oeil sur ce qui est réalisé ailleurs !

Les pièces jointes : schéma, fichiers binaires (sketch), fichiers Kicad. Renommer l’extension pdf de ces deux derniers fichiers au format zip (non acceptés par le site) pour récupérer les données.

Elektor-am_transmitter-schema.pdf (29,2 Ko)

Elektor-am_transmitter-sketch.pdf (1,5 Mo)

Elektor-am_transmitter-kicad6.pdf (101,0 Ko)

Jean-Roger

2 « J'aime »

Mon ModulAM sera en exposition et fonctionnement lors de la bourse multi collection de Berck sur Mer (salle du Kursaal) ce dimanche de 9h à 16h.

1 « J'aime »

Bonjour Jean-Roger

Merci de l’info !
Oui, le ModulAM peut donner des idées !

Et c’est tant mieux, si ça peut créer de l’émulation et faire cogiter les neurones d’un maximum d’amateurs, c’est tout bon pour nos TSF !!! :slightly_smiling_face:

Daniel

1 « J'aime »

Bonjour Jean-Roger, bonjour à tous,

Je crois que l’essentiel du modulateur Elektor se trouve dans l’image de droite:


À mon avis le transistor de cette image se trouve à l’intérieur du puce RP2040. Au début de l’histoire ModulAM; j’ai câblé un tel prototype. Pourtant, j’ai fait cette expérience avec un transistor universel BC547. Il faut savoir que le signal mod consiste en audio + une tension de polarisation d’environ +1.6V. Le circuit que j’ai testé marche. Pourtant la sortie PAM (pulse modulated AM) n’est pas bien symmétrique. Le résultat fait des harmoniques paires. Chez les stations à la partie inférieure de la bande PO le second harmonique tombe dans la bande PO. Il vaut la peine d’ examiner le circuit Elektor afin de vérifier si ce défaut existe là aussi. Le transistor de sortie à l’intérieur du pico est prévu pour travailler les hautes fréquences. Donc il se peut qu’on puisse économiser deux diodes. Puisque ce circuit est cablé à 16 reprises, ça fait 32 diodes economisées. Sur l’image de gauche, vous trouverez le circuit qui fait la modulation chez le ModulAM.

Dans les specs du modulateur Elektor on trouvera la distance entre les porteuses fait environ 35 kHz. Donc, il est impossible de refaire la transmission de stations sur leur fréquence d’origine.

Les magazines qui pensent à construire des systèmes pour faire chanter nos anciens tsf, ça me fait plaisir.
Bien cordialement,
Eduard

5 « J'aime »

Chers amis, demain je vais faire une démo en salle public et l’accès au réseau Wifi public est souvent protégé ou inaccessible.

Pour ce faire je vais utiliser mon téléphone mobile en « Point d’accès Wifi », une option que l’on active facilement pour que le téléphone se transforme en « box internet », à partir de là je connecterai mon PC.

Ensuite le ModulAM sera relié par Ethernet au PC, voici la méthode que j’ai obtenu en travaillant avec Chat GPT pour avoir un accès Ethernet avec un IP fixe pour ne pas avoir à refaire la manip à chaque redémarrage du Module AM. J’ai ajouté des images pour que ce soit plus parlant.

Résumé méthode : accès ModulAM via Ethernet direct

:one: Préparation du PC

  • Brancher le PC au Wi-Fi du téléphone pour avoir Internet.
  • Configurer l’Ethernet du PC avec une IP fixe :
    • IP : 192.168.10.1
    • Masque : 255.255.255.0
    • Passerelle : vide
    • DNS : vide


:two: Connexion SSH au ModulAM via Wi-Fi

  • Connecter le PC et le ModulAM via Wi-Fi (ex : IP du ModulAM 192.168.1.174)
  • Ouvrir PowerShell ou cmd sur Windows :
ssh orangepi@192.168.1.174
  • Accepter la clé SSH si demandé (yes)
  • Se connecter avec le mot de passe (orangepi par défaut)

:three: Vérification des interfaces réseau

Dans le terminal SSH :

ip addr
  • wlan0 → Wi-Fi (actif)
  • eth0 → Ethernet (UP mais sans IP si non configuré)


:four: Configuration de l’Ethernet avec IP fixe

  • Lancer l’outil texte semi-graphique NetworkManager :
sudo nmtui

  • Menu : Edit a connection → eth0 → IPv4 → Manual
    • Address : 192.168.10.2/24
    • Gateway : vide
    • DNS : vide
  • Automatically connect → coché
  • (Optionnel) Renommer la connexion (ex : WIFITEL)
  • Sauvegarder (OK) → revenir (Back) → quitter (Quit)


:five: Appliquer la configuration

sudo systemctl restart NetworkManager

:six: Test de la connexion Ethernet

  • Brancher le ModulAM directement au PC via câble Ethernet
  • Depuis Windows :
ping 192.168.10.2
  • Si réponse OK → accès via SSH ou navigateur :
ssh orangepi@192.168.10.2
http://192.168.10.2

:seven: Résultat

  • Ethernet actif au démarrage avec IP fixe
  • Wi-Fi du téléphone reste disponible pour Internet
  • SSH et interface web fonctionnent sans dépendre du Wi-Fi

Et voilà , accessible depuis l’adresse 192.168.10.2 pour toujours par Ethernet

6 « J'aime »



4 « J'aime »

Beau stand !!!

Et belle promo pour Rétrotechnique !

4 « J'aime »

@DWK

Bonjour Daniel et à toute l’équipe de conception du ModulAM,

J’ai quelques questions en relation avec le comportement des lignes d’état L2 et L3 correspondant aux sorties IO4 (PC14) et IO5 (PC15) de la carte Orange Pi (connecteur 26 points).

J’ai remarqué pendant la première étape d’initialisation (environ 18 s depuis la mise sous tension) que les LED L2 et L3 étaient légèrement allumées, dénotant le fait qu’elles étaient traversées par un faible courant. J’ai raccordé les deux voies de mon oscilloscope aux pins IO4 et IO5 du connecteur 26 points correspondant aux sorties L2 et L3. Le chronogramme obtenu (jaune = L2, magenta = L3) est le suivant :

Durant les 18 premières secondes ces deux pins sont à environ 2 V (valeur dépendante de la charge imposée par les caractéristiques de LED et de la résistance de limitation de courant à 220 ohms). A quoi correspond cet état qui ne s’apparente pas à un état logique 0 ou 1 ? Cela donne l’impression d’être lié à un état indéterminé de certains composants internes, car cette même tension d’environ 2 V grimpe à 3 V en l’absence de charge. Dans la documentation Orange Pi, en examinant les informations autour du GPIO je n’ai pas trouvé de réponse à cette question. Ces lignes IO4 et IO5 semblent également en prise directe avec l’eMMC/Nand intégrée au H616. Y-a-t’il un lien ?

Au-delà de ces 18 s, on obtient des état logiques normaux. Dans cet exemple, j’appuie sur le bouton poussoir à 52 s et non 60 s comme indiqué sur le chronogramme. Le phénomène sur les 18 premières secondes n’est pas gênant en soit, c’est juste pour comprendre, et je suppose qu’il ne peut pas être maîtrisé au travers de la programmation.

Toujours concernant l’existence de ces contrôles d’état L2 et L3, il n’y est pas fait référence dans la notice générale en v2.1 (montage et instructions). Il faut se reporter au document concernant le boîtier d’accueil (intégration et câblage des modules) pour découvrir l’existence de L2 et L3. Je pense que cela aurait également toute sa place dans la notice générale au chapitre IV.3, en page 24 par exemple.

Edit ce mardi 21 Octobre :

Je complète ce message par quelques mesures supplémentaires. J’ai caractérisé les générateurs équivalents de Thévenin pour les configurations pré (t < 18s) et post (t > 18s) initialisation.

En régime établi, je n’ai pas trouvé d’information (ou bien je n’ai pas su interpréter) ce qui est communiqué par le fabricant du H616 (extrait en pièce jointe).
H616_Datasheet_extrait.pdf (872,5 Ko)

Pour un processeur de type H2+, une information sur une valeur maximale de courant à 40 mA est communiquée, valeur pour l’ensemble GPIO je pense. C’est peut-être transposable au H616. Quant au comportement en phase de pré-initialisation, c’est peut-être la conséquence d’un état « tri-state » (?)

Jean-Roger

Bonjour Jean-Roger,

Lors du démarrage, les leds sont dans un état indéterminé tant qu’un ordre d’allumage ou d’extinction n’est pas explicitement lancé par l’OPZ. Les concepteurs du modulam ont choisi de lancer ces ordres au début du programme qui pilote le micro-contrôleur pico (voir ligne 91 du fichier automate.c). Ceci est logique car ces leds indiquent que le système est prêt à répondre aux demandes de l’utilisateur.

Ce que vous constatez c’est ce qui se passe entre le boot de l’opz et le lancement des ordres par le programme (18 s). Cette durée correspond au montage du disque, au chargement du système Linux, au lancement des divers services. Pendant ce temps, l’état des ports est indéterminé.

Vous pouvez faire en sorte de forcer l’extinction de ces leds avant le lancement du programme en activant un service de gestion des ports gpio et en utilisant un script d’extinction des leds en amont du programme. Vous aurez tout de même un état indéterminé à la mise sous tension jusqu’au lancement du service mais ça ne durera pas 18 s. Ce sera plus bref. Les leds s’éteindront puis la L2 s’allumera au lancement du programme ensuite la L3 au début de la diffusion.

Si vous souhaitez vous lancer dans cette manip, je peux vous donner les scripts et les commandes Linux à lancer. Il faudra se connecter à l’OPZ par ssh.

Bonne soirée

1 « J'aime »

Bonjour Stockfish,

Merci beaucoup pour votre réponse détaillée, c’est très clair. Je veux bien effectuer cet essai, si vous disposez d’un script adapté. Je découvre à la ligne 124 et suivantes du fichier automate.c que vous avez déjà contribué à l’évolution du firmware !

Je suppose qu’en dehors du script supplémentaire à verser dans « scripts », une édition du fichier automate.c va être nécessaire pour appeler une ou plusieurs commandes supplémentaires ? Une compilation sera probablement nécessaire, mais je ne sais pas comment il faudra procéder …

Comme je ne voyais pas de réponse à cette (légère) problématique, je l’ai en l’état contournée de manière hardware et externe, vu qu’il me restait des BC547, cf. ci-après. C’est un peu radical, je l’avoue !

R77 fixe un potentiel stable suivant l’état du port (0, 1 ou indéterminé). R2et R3 polarise le transistor en régime bloqué ou saturé pour les états 0 et 1. Le petit bonus de ce circuit (en double exemplaire L2/L3) est de lever la limite en courant pour la LED, comparativement à ce qui est fourni par les ports de l’Orange PI.

Du reste dans la description de la notice générale, il est mentionné que le courant traversant L2 ou L3 est de 15 mA, mais en réalité c’est inexact. Ce courant a été calculé comme le rapport de la tension de 3,3 V à la résistance série de 220 ohms, c’est à dire en ne tenant pas compte de la chute de tension imposée par la LED. En pratique le courant qui traverse une des deux LED (L2 ou L3) est de l’ordre de 5 mA. Comme mentionné dans mon précédent message, on ne sait pas vraiment la valeur de courant cumulée que peut suppporter le H616.

Je reste en attente de vos fichiers et instructions, qui intéresseront sans aucun doute d’autres utilisateurs du ModulAM. Ici j’adresse le modulAM en SSH à l’aide de FileZilla.

Bonne journée.

Jean-Roger

1 « J'aime »

Bonjour Jean-Roger

Merci de votre contribution à ce projet d’équipe !
C’est ainsi que l’on progresse, en regroupant les idées, les compétences et les énergies de chacun.

Même si ces 18 secondes d’indécision faisant apparaître des leds demi allumées lors de la mise sous tension du ModulAM ne perturbe en rien le fonctionnement, réduire notablement ce temps ne peut qu’améliorer le produit !
Car, sur le fond, il est bien certain que ces demi-teintes peuvent désorientées l’amateur non averti.

Avec notre ami @Stockfish, qui fait partie de l’équipe de développement, vous serez bien assisté et documenté pour mettre les mains dans le cambouis et chercher à améliorer encore le logiciel du ModulAM, même si votre solution matérielle est effectivement radicale pour régler cette question.
Mais si on peut éviter de modifier le matériel…

Au plaisir de suivre cette évolution à vos côtés.

Daniel