Le contexte
L'idée n'a rien de nouveau, puisqu'il s'agit de faire jouer ensemble plusieurs orgues
de barbarie. De concert pourrait-on dire.
La technique habituellement utilisée consiste à diffuser la totalité des
messages midi générés par un instrument maître. Dans le flux reçu, les
récepteurs choisissent ensuite les messages qui les concernent. D'un strict
point de vue technique il s'agit plutôt d'une diffusion de données que d'un
processus de synchronisation. Les données reçues sont synchrones par définition...
à condition qu'elles arrivent.
Les principales difficultés posées à l'amateur par cette technique sont au moins de deux
ordres :
1. La bande passante radio nécessaire est assez conséquente car le signal midi
requiert tout de même un débit de 32500 bauds. Il faut donc utiliser des
équipements capables d'assumer cette contrainte.
2. La continuité et l'intégralité du flux des messages reçus doivent être garantis, faute de quoi on
aura des interruptions dans la musique. Une liaison bidirectionnelle avec
processus d'acquittement et de réémission est donc souhaitable.
Pas si simple en fait...
Et si on faisait autrement ?
Les deux idées de base sont les suivants :
1. On trouve sur le marché des modules radio en 433 MHz pour un prix dérisoire
(de l'ordre 1€ la paire). Hélas leur bande passante est assez faible, mais quand-même
hein... ils ne sont pas chers.
2. Par principe, chaque module PPCaP dispose de ses propres données concernant
le morceau à jouer dans une carte à puce. Il n'est donc nullement besoin de les
diffuser puisqu'elles sont déjà là. Il faudrait "juste" les synchroniser.

Le principe
Il peut s'énoncer de manière très simple : Chaque instrument exécute son
propre morceau de musique sous le contrôle d'un instrument maître qui impose son
rythme. Ce dernier est le chef d'orchestre en somme. Et nous voilà revenus à la notion de concert. :o)
Les contraintes
1. La bande des 433 MHz est très encombrée par des dispositifs de toutes sortes
(télécommandes de portes et portails, jouets, sondes des stations météo
domestiques etc...). Il faut donc sécuriser les messages radio au maximum et
concevoir un système qui soit robuste vis à vis des aléas de transmission.
2. Ces modules radio autorisent un débit maximum de l'ordre de 2 kbits/s. Il est
donc hors de question de transmettre une grande quantité d'information.
3. L'intégration dans l'existant doit être quasi-transparente. Un minimum de
matériel additionnel et une mise à jour soft seraient l'idéal.
La solution retenue
Oui retenue, car plusieurs autres solutions ont été envisagées et testées.
En premier lieu, on se rend compte qu'il ne suffit pas de synchroniser le
départ des morceaux. La disparité des quartz des cartes arduino est telle que
l'on se retrouve assez facilement avec des décalages de l'ordre de la seconde en
fin de morceau et
ce n'est guère acceptable.
L'idée du calibrage des cartes a été tentée, mais selon la
température, la tension de la batterie et que sais-je encore, la dérive finit
par se faire sentir.
Une sélection de cartes arduino qui seraient de meilleure
qualité a été par principe écartée. Comment apprécier cette qualité à priori et sur quels critères
puisqu'aucune spécification de ce genre n'est mentionnée à leur cahier des
charges.
Des
techniques de recalage sur des informations de référence insérées dans les
morceaux ont également été essayées avec plus ou moins de succès quant aux
effets sur le déroulé musical et sa fluidité. Et puis les contraintes en amont
étaient trop lourdes.
La technique retenue consiste à remonter à la source des signaux musicaux et
à ce qui les génère, plus précisément à leurs horloges et à comparer le
comportement de celles-ci sur des périodes fixes. Autrement dit, on va mettre en
place une dispositif d'asservissement de ces horloges. Entre autres avantages, aucun travail particulier préalable
ne sera requis sur les fichiers de musique,
autre que celui de l'arrangement bien sûr.
Alors ça fonctionne comment ?
 | Toutes les 1024 occurrences de son horloge, l'émetteur envoie un message
de synchronisation. Ce message est bref et dure environ 40 ms toutes les
4.267 secondes. |
 | Le récepteur compte également les coups d'horloge qu'il génère entre
deux réceptions successives du message de l'émetteur et compare à 1024. La
différence observée en positif ou en négatif, donne alors lieu à deux
actions :
1. De manière immédiate : Rattrapage du retard ou correction de l'avance en
agissant sur les temps d'attente des événements suivants et en appliquant
un processus de lissage.
2. On tente d'établir la tendance de l'horloge locale par rapport à celle de
l'émetteur et on procède à son ajustage. En résumé, si on
est souvent en retard, on diminue la période de l'horloge locale pour
accélérer et vice versa (tout est dans le "souvent" :o)). |
 | De cette manière on assure que le nombre de coups d'horloge exécutés des
deux côtés sera en moyenne le même à l'issue de chaque séquence de 1024 et
en conséquence les morceaux s'exécuteront de manière synchrone. |

Principe de la synchronisation
A noter :
Tout ceci est mis en œuvre dans le contexte de l'excellente bibliothèque VirtualWire de Mike McCauley.
Les messages transmis comportent 80 bits : 36 bits de préambule + 12 bits de
start + longueur utile + le message lui-même + un CRC. Avec la modulation utilisée et pour un débit de 2
kbit/s, leur durée d'émission est donc de 40 ms. Celle-ci s'effectue
selon un processus d'interruptions sous le contrôle du timer1 de
l'Atmega cadencé ici à 62.5 microsecondes et elle est quasi-transparente
pour le programme principal. La réception s'effectue exactement de la
même manière et sous le contrôle de ce même timer1.
La précision du positionnement temporel de la réception des
messages est donc fonction de la période de ce timer. Il s'ensuit que la
part "radio" de l'erreur de synchronisation est au maximum de 2 x 62.5
microsecondes (émission + réception). Je vous laisse faire le calcul de
ce que cela représente musicalement. Ca existe des 1/4000
de croche ? ;o)
Mise en œuvre
Des résistances de 3.3 K sont mises en parallèle sur l'entrée du module
émetteur ainsi que sur la sortie du récepteur. Leur présence ne perturbe en rien
le fonctionnement de ces derniers et elle permet au programme de détecter lequel des deux est
en service en marquant un '0' logique sur la broche correspondante lorsqu'un pullup interne à l'Atmega est momentanément activé pendant la phase de setup.
La mise en service d'un des modules s'effectuera donc simplement au moyen d'un
commutateur raccordant sa connexion de données à la broche de l'arduino qui lui
est dédiée.
Il n'est pas nécessaire de couper l'alimentation des modules
inutilisés. Leur consommation est assez négligeable par rapport à l'ensemble du
montage. Du reste, l'émetteur étant de type ASK, il n'émet strictement rien lorsque son
entrée est à 0. Mais bon, pourquoi pas. Dans ce cas il faut des commutateurs à
double-circuits.
Pour plusieurs raisons, le connecteur RF qui était présent en prévision sur
les cartes PPCaP ne peut être utilisé en l'état. Difficile de penser à tout 4
années en avance. Selon le cas on procèdera donc aux mini-corrections
suivantes :
1. Carton électronique ou commande électronique intégrée avec connecteur
RF pré-câblé :
- Couper les deux liaisons existantes du connecteur RF vers les broches D0 et D1
de l'arduino.
- Relier la connexion émetteur à D9 et la connexion récepteur à D13.

Exemple de modification de câblage du
connecteur RF sur une carte 29-32 notes
2. E-serinettes :
- Couper la liaison de la sortie midi vers D9 et la relier à D1.
- Créer un connecteur RF à 4 broches selon le schéma ci-dessous (5V, D13, D9,
masse).
En résumé on doit avoir :
- Sortie midi : Broche Tx de l'arduino (D1)
- Données vers l'émetteur radio : Broche D9 (ex-midi sur les e-serinettes)
- Sortie du récepteur radio : Broche D13
I
Implantation des modules RF et exemple de carte
d'adaptation
IMPORTANT :
Si vous avez réalisé l'implantation de ces modules dans une e.serinette, ne pas
oublier de rediriger la sortie midi sur TX (fenêtre "Paramètres" du soft version
5.2).
Utilisation
Il suffit de positionner les commutateurs des différents instruments en fonction
du rôle que l'on veut leur faire jouer avec pour règle : Un seul émetteur et autant de
récepteurs que l'on veut. S'il a plusieurs "chefs"... là non plus ça ne va pas.
 | Côté récepteurs on introduit une carte tout en pressant le bouton. La
led rouge s'allume, puis s'éteint au bout d'une seconde. On peut alors
relâcher le bouton. Un clignotement rouge atteste que le module est en mode
réception, puis la led verte s'allume. On peut tourner la manivelle pour produire de l'air, mais
musicalement il ne se passe rien. On est en attente de déclenchement. |
 | On procède de la même manière côté émetteur, à ceci près qu'au lâcher de
bouton la led rouge clignotera 2 fois avant l'allumage de la led verte, signifiant le fonctionnement en mode
émission. Le morceau débutera alors immédiatement avec l'envoi simultané d'un
signal de démarrage à tous les récepteurs. |
 | Et c'est tout ;o) |
On pourra alors constater tout au long du morceau, que la led rouge de
l'émetteur clignote brièvement environ toutes les 4 secondes, signifiant l'envoi
d'un signal de synchronisation.
Parallèlement, la led rouge côté récepteur clignote également de manière
synchrone, attestant de la réception du signal. Le système est plutôt robuste vis à vis des échecs de transmission et si le récepteur manque quelques
synchros cela ne s'entendra vraisemblablement pas.
Particularités
 | Il est préférable d'utiliser une version des logiciels à partir de 5.0 pour programmer les cartes si les
morceaux contiennent des délais d'attente supérieurs à 8 secondes, ce qui
sera souvent le cas dans un jeu à plusieurs instruments dans lequel ils se
répondent. |
 | Ne pas utiliser le mode 32 notes pour de la synchro radio ! La précision de
la représentation du temps y est insuffisante pour obtenir un calage précis
entre des morceaux différents. Si on souhaite placer des marques dans les
morceaux, passer en 42 notes. |
 | Si un des morceaux doit débuter en retard, il est nécessaire d'y insérer
une note hors gamme en début de morceau. Elle ne sera pas jouée et ne
doit pas non plus être déclarée dans les notes additionnelles. L'algo d'écriture sur
cartes a été conçu pour économiser la mémoire et la présence de cette note
l'oblige à passer outre et à insérer des blancs.
|
 | La pénurie de broches dans le montage m'a amené à utiliser D13 pour les
données du récepteur. Or, traditionnellement dans le monde arduino cette broche pilote
une led. Selon les implantations des cartes Nano en particulier, cette led
peut être précédée d'un ampli mais parfois seulement d'une simple résistance. Dans
ce dernier cas et si on souhaite jouer au tempo midi, il
est possible que l'on obtienne une fausse détection d'un récepteur
alors que celui-ci est hors service ou même absent. Le module se retrouve
alors bloqué en attente d'un signal de l'émetteur qui n'arrivera pas.
Une simple pression sur le poussoir pendant que l'on tourne permet de démarrer
le morceau et de retrouver le fonctionnement des versions antérieures. |

Exemple d'implantation externe sur le carton
électronique (Un peu à l'arrache je l'admets :o))
Choix des modules radio
Parmi toutes les offres de modules de ce genre, il est de loin préférable de
commander la version superhétérodyne présentée en début de page. Si les
émetteurs se valent, la sensibilités de ces récepteurs est bien meilleure que
celle de celui qui est présenté ci-dessus dans ma version carton électronique et
qui n'est rien d'autre qu'un montage à amplification directe.
De plus l'absence de réglage et la génération de la FI sous contrôle d'un quartz
augurent d'une plus grande stabilité. Quoique hein... c'est sans doute aussi un quartz bas
coût.
Logiciel
L'indispensable mise à jour logicielle est ici :
PPCaP_V70
Test des modules radio
Après installation du soft sur un système PPCaP, il suffit d'observer la led
rouge tant côté émetteur que récepteur pour s'assurer du bon fonctionnement du
lien radio. Cependant, la période de clignotement est un peu longue pour
procéder à des ajustages d'antennes, tester la portée etc.
Voici un petit programme qui effectue une émission toutes les 500 ms ou moins...
C'est du code source et donc une occasion de bidouiller à votre convenance
sous l'IDE arduino. A téléverser dans toutes les cartes
concernées.
C'est ici : Software\Test_modules_RF.zip
Amusez-vous bien !
|