J’ai déjà traité des afficheurs LCD, sur une interface parallèle (les plus répandus) ou I2C (plus rares, mais bien pratiques car peu consommateurs en fils).
Sans revenir sur la description succincte du protocole que j’ai déjà donnée, cet article décrit le montage à base de microcontrôleur PIC, ainsi que le programme utilisés pour mes essais. Notons que le programme et le montage sont spécifiques à un modèle donné d’afficheur, mais peuvent être adaptés, notamment au niveau du brochage, des timings et de la table de caractères utilisée.
Fin août dernier, je rentrais de la conférence INTERACT 2009 sur l’interaction homme-machine, lorsque j’ai été justement confronté à un problème ergonomique criant à l’aéroport de Stockholm-Arlanda.
Ce problème porte sur certaines bornes d’auto-enregistrement d’Air France. Certaines bornes ont été conçues spécifiquement à leurs conditions d’utilisation (debout, dans un aéroport), mais celles qui m’intéressent ici ne sont rien d’autre qu’un PC avec Internet Explorer et une version intranet du site web d’Air France, ce qui conduit notamment aux horreurs suivantes :
- Un site web est fait pour être lu et parcouru confortablement installé à un bureau. La taille des textes, la taille des liens à cliquer ne sont en aucun cas adaptées à une utilisation dans les conditions inconfortables d’un comptoir d’enregistrement.
- Le site présenté est exactement identique au site diffusé sur Internet, ce qui fait qu’il faut répondre à des questions du type : « Imprimer la carte d’embarquement maintenant, ou bien la retirer à l’aéroport ? ». Juste stupide.
- À la fin, lors de l’impression de la carte, le PC lance tranquillement Acrobat Reader, et vous devez à la main aller choisir la commande Print, sélectionner l’imprimante et lancer l’impression. Une feuille A4 tombe alors à vos pieds (!). Après l’avoir ramassée, il vaut mieux penser à effacer manuellement le fichier PDF temporaire si vous tenez à votre vie privée.
Autant dire que les concepteurs de cette machine ne se sont pas foulés. On a ici un exemple typique d’un objet qui n’a été conçu ni pour la tâche à effectuer (choix non pertinents), ni pour l’environnement d’utilisation (on est dans un aéroport, pas dans son bureau), ni pour les utilisateurs (un voyageur n’a pas à être préoccupé de fichiers, de commande imprimer, ou d’Acrobat Reader). Il s’agit juste d’un ratage complet. Bravo.
Alors que l’on assiste à une quasi-généralisation en Europe du RDS-PS dynamique (détournement de la fonctionnalité d’affichage des stations du RDS pour faire passer des textes dynamiques), et alors que l’autorisation d’expérimentation en France continue jusqu’au 31 décembre, le RDS Forum vient de publier un nouveau document précisant sa position. Ses arguments contre les détournements actuels sont les suivants :
- La fonctionnalité PS est cruciale dans le RDS, car elle permet à l’auditeur d’identifier rapidement les stations (transmission du nom en moins d’une demi-seconde). Le PS dynamique casse cette fonctionnalité.
- La majorité des récepteurs RDS stockent en mémoire le nom PS. Si le PS contient autre chose que le nom des stations, les mémoires sont étiquetées n’importe-comment, ce qui rend l’utilisation des récepteurs pénible.
- De plus certains autoradios effectuent une recherche automatique, et affectent les noms des stations trouvées (PS) à des touches d’accès rapide. Encore une fois, ces touches sont étiquetées n’importe-comment avec le PS dynamique.
- Le PS dynamique dans une voiture peut distraire le conducteur, ce qui pose d’importants problèmes de sécurité. En particulier, c’est contradictoire avec une recommandation de l’UE datant de 2007, qui porte sur la sécurité des affichages dans une voiture. D’après le RDS Forum, certains constructeurs ont d’ailleurs déjà sorti des autoradios qui coupent l’affichage en cas de réception de PS dynamique…
Le RDS Forum enjoint donc les autorités de régulation de s’assurer qu’aucune station n’utilise plus le PS dynamique. Les stations sont bien entendu incitées à cesser ces activités dès que possible et à utiliser le radiotexte (RT) en remplacement, mais une période de transition est envisagée, au cours de laquelle on recommande aux stations de ne faire varier le PS que moins de 30 secondes par minute (en moyenne). Notons cependant que si cela améliore certains points ci-dessus, cela ne résout pas fondamentalement les problèmes soulevés…
Il sera intéressant d’analyser la position du CSA suite à l’expérimentation française. Car si la solution de transition proposée par le RDS Forum correspond à peu près aux lignes directrices suivies pour l’expérimentation de 2009, il y a tout de même une différence majeure : alors que le RDS Forum propose cette solution en tant que transition vers un arrêt au plus tôt du PS dynamique, le CSA envisage éventuellement d’autoriser le PS dynamique à démarrer en France…
J’ai eu récemment l’occasion de passer quelques jours à Denver. Ce billet présente une sélection de quelques activités à faire à Denver et dans la région.
Echo Lake, dans les Rocheuses.
Je viens de concrétiser un projet de longue date : réaliser un décodeur RDS. J’avais travaillé sur ce projet en 2001, sans aboutir, et je l’avais ensuite remis à plus tard. Voyons en quoi cela consiste, et ce qui m’a enfin permis d’avancer.
➜ Accéder directement à RDS Surveyor, mon projet open source de décodeur RDS
Le RDS, pour Radio Data System, permet aux émetteurs de radiodiffusion en bande FM de transmettre des informations telles que le nom de la station, des fréquences alternatives, des signaux horaires, des textes, ou encore des informations plus complexes qui permettent le basculement sur d’autres réseaux lors de la diffusion d’informations routières. D’un point de vue technique, le RDS ajoute une porteuse à 57 kHz au signal multiplexe des stations (le signal multiplexe de base est constitué du signal mono non modulé et d’un signal stéréo « différentiel » modulé en AM sur une porteuse à 38 kHz, supprimée), laquelle est modulée en amplitude, porteuse supprimée, par des symboles biphase correspondant aux bits, au débit de 1187,5 bits par seconde. Les données binaires sont structurées en « groupes » de 104 bits, composés de 4 blocs de 26 bits. Un bloc contient lui-même 16 bits de données et 10 bits qui servent à la synchronisation et à la détection/correction des erreurs. Il est possible d’acquérir la synchronisation au niveau bloc.
J’ai récemment utilisé mon récepteur GPS en avion, à l’occasion d’un trajet vers Stockholm. Tout se passait bien, jusqu’à ce qu’arrivé au-dessus de la Belgique, et alors que l’avion continuait de façon rectiligne sur sa trajectoire nord-nord-est, le GPS se figure que nous avions fait un large quart de tour sud-est. On voit bien ce quart de tour, en forme de bel arrondi, sur les captures d’écran ci-dessous (trace en noir, parfois recouverte par des noms de villes). À gauche, on voit également que le GPS était complètement perdu quant à la vitesse, nous croyant à plus de Mach 3… Il a fini par retrouver le bon positionnement, sautant brusquement à un nouvel endroit (à droite).
Cela incite quand-même à regarder d’un œil critique les informations issues de son GPS…
 |  |
J’utilise de temps en temps la téléphonie SIP de Free (Freephonie), via le logiciel X-Lite (version 3). Je l’avais depuis longtemps configuré en suivant un des tutoriels disponibles.
Or, cela ne fonctionne plus avec cette configuration ! L’enregistrement sur le serveur SIP se passe bien, mais les appels n’aboutissent pas : je tombe sur un message vocal « the person you are calling is not available »…
Voici les modifications que j’ai apportées à la configuration de base du compte SIP pour que cela fonctionne à nouveau :
- onglet Account :
- cocher Register with domain and receive incoming calls
- sélectionner Proxy et indiquer freephonie.net
- onglet Topology :
- IP address : use local IP address
- STUN server : use specified server, et indiquer freephonie.net
- Enable ICE
Je ne sais pas bien pourquoi le comportement a changé, tout n’est peut-être pas nécessaire, mais ça marche comme ça, donc je partage. J’ai essayé cette configuration à partir d’un message trouvé sur un forum, pour un problème a priori différent.
Lorsque l’on met au point un programme, il est souvent pratique d’effectuer des affichages de diagnostic. Ah, le bon vieux débogage à la printf… Pour faire des affichages à partir d’un montage à microcontrôleur, le plus simple est d’utiliser une liaison série RS-232. Les microcontrôleurs disposent généralement de ports UART, mais aux niveaux TTL (0 / +5 V), pas aux niveaux prévus par la norme RS-232 (–12 V / +12 V). On doit donc utiliser un circuit d’adaptation des niveaux, en général un MAX232 ou équivalent, accompagné de sa noria de capas au tantale. Ajoutons à cela la nécessité sur les PC récents d’utiliser un adaptateur série/USB, et on obtient une installation bien complexe pour un petit débogage.
J’ai déjà parlé de la nouvelle fonction analyseur logique du PICkit 2. Sur le même principe, le PICkit 2 dispose d’une fonction UART (aux niveaux logiques TTL), bien utile pour permettre à un programme d’effectuer des affichages de débogage. Et comme pour l’analyseur logique, les fils TX et RX se trouvent sur les broches PGC et PGD du PICkit, toujours connectées sur un circuit qui prévoit la programmation sur place (ICSP). On peut donc rajouter ce type de débogage sans modification matérielle sur des montages existants, et on n’aura même pas à débrancher/rebrancher le PICkit entre les phases de programmation et d’exécution.
Depuis quelque temps, le logiciel de programmation du PICkit 2 dispose d’une fonction analyseur logique et UART, extrêmement pratique. Intéressons-nous tout d’abord à l’analyseur logique. Il peut analyser trois canaux en parallèle, sur les broches PGC, PGD et AUX du PICkit 2. Ce qui est génial, c’est que les broches PGD et PGC sont déjà connectées sur tous les montages qui supportent la programmation sur place (ICSP), et qu’elles sont à ma connaissance multiplexées sur tous les PIC avec des I/O numériques. De plus, on essaie en général de ne pas utiliser les I/O multiplexées avec PGD et PGC, donc il y a de fortes chances que ces pins soient inutilisées dans le montage, et qu’on puisse donc les réquisitionner pour faire du débug sur les signaux ! Sans modifier un montage existant, sans déplacer le PICkit entre la phase de programmation et la phase d’exécution du programme, on peut donc analyser des signaux émis par le programme. Pratique, non ?
Non ce billet ne parle pas de politique. Quoique.
PS, pour Program Service, est le nom de la fonctionnalité du Radio data system (RDS), qui vise à permettre l’affichage sur un récepteur radio du nom de la station reçue, sur huit caractères. Il s’agit donc de l’une des fonctionnalités les plus connues du RDS, avec le basculement automatique entre émetteurs lors des déplacements.
Selon la norme RDS, la fonctionnalité PS est expressément réservée à l’affichage statique du nom de la station. Des informations plus dynamiques telles que les références de l’émission ou du morceau de musique en cours peuvent être fournies via la fonctionnalité RT (radiotexte), qui permet la transmission d’un texte de 64 caractères, avec un système de gestion de la dynamicité (alternat d’un bit pour ne pas confondre deux messages successifs).
L’UER proscrit donc explicitement le détournement de la fonction PS pour la transmission d’informations dynamiques. Parmi les arguments pertinents, on peut évoquer les suivants :
- Par défaut, un autoradio affiche le code PS, statique. Des informations dynamiques sont de nature à perturber le conducteur d’une voiture, voilà pourquoi le RT s’obtient (si disponible) en pressant sur un bouton, donc d’une façon volontaire. Si on détourne le PS, on risque de perturber les automobilistes à des moments où ils ne s’y attendent pas.
- Le code PS est sur huit caractères. Y faire passer de longs messages nécessite de tout découper en tranches de 8 caractères, avec le risque que certaines tranches ne soient pas reçues. Par opposition, les messages RT sont longs de 64 caractères, avec défilement géré par le récepteur.
- Si le code PS représente autre chose que le nom de la station, cela rend la recherche des stations beaucoup plus difficile. En gros, on perd l’apport du RDS pour l’identification des stations… De plus, les systèmes de mémorisation automatique vont mémoriser n’importe-quoi, par exemple des bribes de phrases ou de numéros de téléphone en lieu et place du nom des stations.
Il semble donc évident que l’utilisation du PS pour la diffusion d’informations dynamiques soit une vraie perversion du standard. Pourquoi donc s’embêter alors que le RT est là, avec toutes les fonctionnalités souhaitées[1] ? Et bien il existe un inconvénient majeur au RT : tous les récepteurs n’en disposent pas ! Cela a donc poussé de nombreuses stations à faire du PS dynamique. En Allemagne, Radio Regenbogen le fait depuis 1996. En Suisse et en Autriche, c’est actuellement monnaie courante, même sur des réseaux publics.
Qu’en est-il en France ? En 2008, le CSA a donné une autorisation d’expérimentation pour Radio Classique et Sun FM. Cette expérimentation est étendue : toutes les stations peuvent faire une demande d’expérimentation jusqu’au 31 décembre 2009. Le fait est que le PS dynamique s’est répandu comme une traînée de poudre, aussi bien en Île-de-France qu’en province. Chacun y va de ses références de morceau, de son slogan, de son numéro de téléphone, de son cours de bourse, etc.
On ne peut pas pour le moment juger ce qu’il en adviendra, même si on trouve déjà quelques commentaires des opérateurs. On peut néanmoins regretter qu’un défaut d’implémentation d’une fonctionnalité bien conçue pousse à pervertir (et donc partiellement endommager) une autre fonctionnalité d’une norme par ailleurs très bien pensée.
Pour référence : codes PI (identification de programme) et codes PS canoniques des radios françaises (tous les codes PI français sont entre 0xF000 et 0xFFFF car… F comme France…)
Notes
[1] Et même plus, avec le RT+, qui permet d’associer des métadonnées aux textes RT. Le RT+ vient d’être normalisé.