Mini-Racer

  • J'ai ces deux de petites voitures radio-commandées depuis plus de 20 ans qui traînaient dans un tiroir, et que j'ai eu envie de ressortir…



Ce qui est impressionnant déjà, c'est que les accu Ni−Cd sont toujours bons !
Je ne me souvenais plus cependant qu'une des deux télécommandes ne fonctionnait plus, et il me semblait bien que ces jouets étant identiques il était malheureusement impossible de les faire rouler simultanément, puisque les télécommandes pilotaient les deux voitures en même temps.

− Objectif N°1, réparer la télécommande défectueuse.
− Objectif N°2, tenter d'associer une télécommande à une voiture pour permettre le jeu simultané.


Réparation :

Après avoir ouvert les deux télécommandes et comparé à l'oscilloscope les signaux au niveau des circuits 8A977, j'ai pu constater que tout allait bien de ce côté, les codes de pilotage (pour diriger le véhicule) sont bien présent en sortie.
Idem du côté du signal d'antenne, la porteuse à 27 Mhz est présente elle aussi, sauf que pour la télécommande HS, les signaux codés étaient absents !

  • J'ai pu rapidement constater que c'était le rôle du transistor MPSH10 de mélanger les codes et la porteuse.

  • Sur l'autre télécommande c'est un KSP10, qui est un composant équivalent au MPSH10,


que j'ai donc dé-soudé pour le transplanter à la place du MPSH10 de la télécommande défectueuse. Ce qui a éliminé la panne, comme prévu.

  • Après avoir trouvé un MPSH10 de remplacement sur Ebay, j'ai pu avoir mes deux télécommandes de fonctionnelles… Objectif N°1 Ok, bien content !

Bon par contre on peut pas jouer à deux, ça c'est toujours aussi con, et le jouet ne prévoit pas de pouvoir changer les fréquences, comme c'est le cas sur le matériel de modélisme.


Bidouillage :

Voyons voir alors ce qu'on peut faire…

Nous avons donc un quartz à 27,145 Mhz sur les télécommandes, mais pas sur les récepteurs des voitures. En lieu et place pour recevoir la fréquence de la télécommande, une inductance et un condensateur.
Du côté des circuits 8A977 (émetteur) et 8A978 (récepteur), on apprend dans la doc que la fréquence d'oscillation est réglable via une résistance Rosc, intéressant…

  • Je me suis donc amusé à ajouter des résistances de valeurs identiques sur le circuit émetteur et récepteur, pour constater que la télécommande pilotait toujours la voiture.


Par contre si on retire la résistance sur le récepteur (ou bien l'émetteur), ça ne pilote plus ! Affaire gagnée ?

  • J'ai alors soudé des résistances CMS plus faciles à intégrer, directement sur les broches des circuits intégrés.


Ne vous fiez pas à la sérigraphie de la photo, c'est bien des résistances de 220 kΩ que j'ai finalement utilisé car elles donnaient un meilleur résultat. Ce qui ramène donc la valeur de la résistance d'oscillation à 121 kΩ (je n'ai pas voulu remplacer la résistances d'origine de 270 kΩ, qui en parallèle avec 220 kΩ, donne 121 kΩ).

Voilà on est prêt pour les essais avec les deux véhicules !

  • Et c'est un échec !

− Concrètement la télécommande A pilote bien le véhicule A, tandis que le véhicule modifié B reste immobile.
− La télécommande modifiée B pilote bien le véhicule modifié B, tandis que le véhicule A reste immobile. Jusqu'ici c'est bien ça qu'on veut !
− Par contre si on actionne les télécommandes A et B simultanément, les deux véhicules A et B se figent, immobiles.

Visiblement le petit hack consistant à modifier la fréquence d'oscillation des codages de directions ne suffit pas.

  • En fouillant mes petites boites de composants récupérés, je suis tombé sur un TXC 25.0v6EFC, un quartz à 25 Mhz que j'ai soudé à la place du 27,145 Mhz d'origine de la télécommande.


  • Côté récepteur, j'ignore la valeur de l'inductance, et je ne dispose pas d'autres bobines pour bricoler… On ne peut donc ici jouer que sur la valeur du condensateur soudé en parallèle à l'inductance dont on lit bien la valeur : 56 pF.

Avec la formule consacrée f=1/(2π√LC), puisqu'on connaît f=27,145 Mhz, et C=56 pF, on calcule L=0,614 µH.
Maintenant qu'on connaît L, on peut réutiliser la formule pour calculer la nouvelle valeur de C pour une fréquence de 25 Mhz ! Ce qui donne C=66 pF.
Si on laisse le condensateur d'origine de 56 pF, il faut lui adjoindre un condensateur d'environ 10 pF en parallèle pour atteindre la valeurs voulue.

  • Ne disposant que de condensateurs de 22 pF, j'ai en ai donc soudé deux en série, que j'ai ensuite soudé en parallèle de l'inductance, ce qui devrait faire l'affaire autour de 67 pF théorique.


Un condensateur ajustable aurait été idéal pour syntoniser le récepteur à l'émetteur, mais coup de chance, la bidouille à fonctionné du premier coup, youpi !

Aux essais donc, concrètement :

− La télécommande A pilote bien le véhicule A, tandis que le véhicule modifié B reste immobile.
− La télécommande modifiée B pilote bien le véhicule modifié B, tandis que le véhicule A reste immobile.
− Si on actionne les télécommandes A et B simultanément, les deux véhicule A et B continuent de rouler tranquillement !


Pour finir… :

J'ai tenté de retirer les résistances de 220 kΩ associés au circuit intégrés 8A977 (émetteur) et 8A978 (récepteur) pour déterminer si le passage à 25 Mz était suffisant.
La réponse est non. Le comportement aux essais est le même que précédemment à ceci prés que lorsque les voitures se croisent de trop prés dans un rayon de 50 cm, une des deux télécommandes se met à piloter les deux simultanément le temps que les véhicules s'éloignent l'un de l'autre. Modifier le circuit de codage permet donc bien de différentier au mieux les émetteurs/récepteurs qui travaillent dans des fréquences radio trop proches sinon.
Il faut donc bien effectuer ces deux modifications pour atteindre notre objectif N°2.

IR « Light » Gun avec Arduino - Mundo Yakara -

Pour faire suite à mes travaux précédents :

Ah wé quand même ! Presque deux ans et demi, et je n'avais pas pensé en parler ici…
J'en ai oublié comment j'ai trouvé sa première vidéo, mais toujours est−il qu'un camarade Colombien, @MundoYakara sur youtube, s'est inspiré de mon projet pour réaliser sa propre version de flingue !
Et le moins qu'on puisse en dire, c'est qu'elle est extraordinaire, autant que l'enthousiasme avec lequel il décrit, démontre et communique les détails opérationnels pour permettre à chacun·e d'obtenir un résultat similaire, si on veut bien s'en donner la peine !

C'est ça qu'on veut ! C'est une des raisons qui me pousse à partager mes travaux. Les voir repris et parfois améliorés me met en joie :)

  • Voici les vidéos qu'il a réalisé sur le sujet :

CAP1 [Camara de Wii]: https://youtu.be/K_C604FbPDc

CAP2 [Codigo arduino]: https://youtu.be/3iE0Odys9mg

CAP3 [Mod de guncon]: https://youtu.be/htQh8Hk19M8

CAP4 [Circuito solenoide]: https://youtu.be/wORQgI4LfjM

CAP5 [imprime en 3d tu propia GUNCON]: https://youtu.be/70oEejEn5gk

  • Et les pages web associées :

https://www.mundoyakara.com/2023/10/wiimote-en-camara-infraroja-para.html
https://www.mundoyakara.com/2023/10/lightgun-con-arduino-pro-micro.html
https://www.mundoyakara.com/2023/10/convierto-guncon-en-lightgun-arduino.html
https://www.mundoyakara.com/2023/11/circuito-de-solenoide-para-lightgun-cap4.html https://www.mundoyakara.com/2023/11/imprime-en-3d-tu-propia-llghtgun.html

Décapotes -04-, circuit de positionnement d'image pour écran TV

Suite de la conception précédente :

  • Pour gagner énormément de temps sur ce sujet, étant donné que je partais de zero, je me suis fait aider par un professeur particulier qui s'appelle Claude, et parfois Gemini aussi.

C'est formidable d'avoir « quelqu'un » qui t'explique les choses, et traduit des exemples de code, ce langage obscure, en Français !

J'ai ainsi pu expérimenter ces prompts et me rendre compte du danger qu'ils représentent en terme de capacités cognitives qu'on pourrait vite perdre. Face à un tel outil, le cerveau humain est particulièrement faible, et vite tenté de déléguer trop le travail, au risque de perdre en capacité de réflexions. Sans compter le temps perdu dans des culs de sacs techniques, qui n'auraient pas dû se présenter…

− Dés que je demandais quelques chose du genre « je voudrais faire ça, dit moi comment faire », ça tournait mal. Beaucoup d'hallucinations, de code testés, de ratés, et parfois de code fonctionnel, mais qui décidément ne faisaient pas exactement ce que je voulais. Ça restait pourtant très séduisant pour cette feignasse de cerveau, malgré que je devenais incapable d'ajuster ce code à mon besoin, tout étant allé trop vite, pas eu le temps d'assimiler, ni de comprendre ce qui se présente. Pris dans ces boucles d'incapacités cognitive, obligé de réitérer sans cesse pour en sortir, mélasse dans la tête… wé, pas ouf.
− Par contre dés que j'exposais une directive claire « je veux faire ça, de telle manière, avec ces paramètres, écrit le−moi », ça se passait tout de suite mieux, et « on » me gratifiait au passage d'un « bravo, vous avez raison, ça fonctionnera bien mieux ainsi ». « Oui, je sais… *soupir* ».

Cantonné à un rôle de traducteur où de prof qui m'explique la technique, c'est très bien et moins coûteux pour l'humain que la méthode autodidacte classique. Évoquer des solutions envisageables passe aussi, mais il vaut mieux ne pas en demander plus, et faire le travail d'ingénierie soit même. Pour éviter de finir abruti et de se perdre…

  • Bref, à défaut il faudrait vraiment éduquer à employer correctement cette techno, où quelle disparaisse à jamais, ça ne sera pas plus mal.

Un quatrième circuit d'essais :

Allez-allez là, l'actualité ! Trêve de blabla, passons au concret !

  • Suite aux déconvenues précédentes, et ce qu'elles m'ont permis d'apprendre, j'ai tenté un schéma en − presque − tout numérique et de me passer des circuits vidéo spécialisés :


− Nous avons donc une adaptation de signaux en entrée, car l'IGS−PGM délivre un C−Sync hors normes à 5V d'amplitude.
− Le RP2040 qui va traiter intégralement le signal d'entrée, afin de sortir un nouveau C−Sync déphasable, par action sur le switch et les potentiomètres.
− Une porte ET logique 74HC08 pour réassembler C−Sync en sortie.
− Et un switch double pour inhiber le circuit, pour le cas où on ne voudrait pas traiter le signal.

Le programme µPython est disponible ici, et en annexe du billet.[1]
J'ai aussi fait commenter le code Python afin qu'il soit accessible aux grands débutants.


  • Description rapide du principe de fonctionnement :
  1. Le signal C−Sync entre sur GP0.
  2. Il est traité par sm4 : StateMachine 0 hsync_flywheel afin « d'extraire » le signal H−Sync. En fait créer un signal respectant la norme vidéo avec une impulsions de 5 µs, calée sur les fronts de C−Sync, et continuant sur ce rythme lorsque les trous formés par V−Sync apparaissent. Le signal est disponible sur GP1 pour débug ou réutilisation opportune.
  3. C−Sync in est utilisé par sm5 : StateMachine 1 vsync_pio pour « extraire » V−Sync. Donc créer une impulsion longue de 512 µs, calée sur les fronts de C−Sync. Le signal est disponible sur GP2.
  4. Ensuite, l'action combinée de sm0 : StateMachine 4 front_montant Horizontal et sm1 : StateMachine 5 front_descendant Horizontal vont permettre, lorsqu'on appuie sur le bouton, de lire la valeur du potentiomètre horizontal et de déphaser le signal H−Sync. Ce signal est disponible sur GP3.
  5. De même avec sm2 : StateMachine 6 front_montant Vertical et sm3 : StateMachine 7 front_descendant Vertical pour déphaser le signal V−Sync. Signal dispo sur GP4.
  6. Et enfin, sm6 : StateMachine 2 and_gate effectue une opération ET logique entre les deux signaux déphasés afin de reconstruire notre C−Sync déphasé en sortie. (finalement remplacé par une porte logique physique plus fiable)
  • Voici quelques chronogrammes (avec un déphasage notable en vertical et horizontal) pour voir ce qu'il en est à chaque étapes clef du circuit :




  • Et une petite vidéo démonstrative :
  • Et de deux !
  • Conclusion de l'expérimentation,

On a donc un programme « full states machines » indépendant du CPU du microcontrôleur, ce qui permet une cadence de génération des signaux très précises.
Le CPU n'est là que pour gérer les boutons et la lecture des potentiomètres.

Tout fonctionne bien et sans gigue, pour ce programme tout à fait adapté à l'IGS−PGM, c'est je pense le montage qui constituera la carte fille que je vais donc intégrer à mon péritel multiple !

À moins que… Hum, j'ai testé le montage sur quelques consoles, Sega ou Nintendo, et ça ne fonctionne pas du tout…
J'ai regardé un peu les signaux émis par ces machines, et j'ai eu quelques surprises qui m'ont d'ailleur fait retarder la publication de ce présent article, et dont je parlerais peut-être une prochaine fois.

Note

[1] ci-dessous

Lire la suite

Décapotes -03-, circuit de positionnement d'image pour écran TV

Suite de la conception précédente :

  • Avant de tenter de résoudre le problème du trou dans H−Sync, j'ai voulu trouver une solution à la stabilité de la synchro sortante afin d'obtenir une image la plus nette possible, et ce même si le circuit à base de PLL propose une qualité d'image tout à fait correcte.

Mon côté perfectionniste doublé de curiosité m'emmena faire un tour du côté du monde merveilleux de l'Arduino et de l'ESP32. Malheureusement les quelques essais que j'ai pu réaliser n'ont pas donnés les résultats escomptés, et étaient parfois pire qu'avec mon précédent circuit.

  • Quelques temps ont passés avant que je sois poussé à m'intéresser au Raspberry Pi Pico, et plus particulièrement la carte de WaveShare RP2040-ZERO.

J'étais passé jusqu'alors complètement à côté de cette puce. Certes j'avais eu vent de son existence et de la « mode » entourant sa sortie, beaucoup de monde s'y mettait, sauf moi. Comme souvent j'ai plusieurs trains de retard sur les technos, que je sais laisser passer tranquillement avant d'en avoir réellement besoin. Idem pour tout ce qui est LLM + prompt d'intelligence simulée, pas besoin. Vous lisez un type qui lit encore sa musique classée dans des dossiers, en local sur son appareil. Pas de méta−données, rien. Pas besoin.

  • Bref. J'ai donc découvert le RP2040 et entrevu une potentielle solution pour mon problème, en comprenant ce qu'il en était des States Machines, ces machines intégrées à la puce à qui on s'adresse en assembleur et qui roulent au rythme des cycles d'horloges, indépendamment du code adressé au processeur.

Vraiment très intéressant, quand on sait la vitesse à laquelle c'est capable de monter sans sourciller.
C'est bien simple, j'ai pu coder des exemples de génération de signaux de manière classique, à travers le processeur et demander la même chose aux States Machines et le résultat à l'oscilloscope était sans équivoque tellement meilleurs avec ces dernières.
Pour plus d'info, il y a cette vidéo qui explique très bien ce qu'il en est des Machines à état et cette page aussi..
Je comprend maintenant l'engouement pour ce Raspberry Pi Pico !

Un troisième circuit d'essais :

  • J'ai donc envisagé ce schéma, avec une nouvelle fois la structure basée sur le circuit séparateur de synchro LM1881 en entrée, les portes logiques 74LS132 en sortie, mais utilisant le RPi Zero pour le traitement du signal.


  • Particularité ici très importante, le RP2040 fonctionnant en logique 0−3,3V, il faut impérativement adapter les signaux qu'on lui applique, ce que je fais ici à l'aide d'un circuit basé sur le transistor MOSFET BS170 montés ainsi en adaptateur de niveau logique.

Je dispose maintenant d'un analyseur logique, ce qui est bien pratique pour montrer facilement les signaux. J'en profite donc pour donner un relevé des signaux d'entrée/sortie du LM1881, agrémentés de diverses mesures intéressantes…



  • Après plusieurs itérations, j'ai pu écrire ce programme µ−python pour le RP2040-Zero (dispo aussi en annexe à ce billet), pour déphaser les signaux.

Il utilise quatre State Machines pour déphaser les signaux. Les potentiomètres et le bouton sont gérés par le CPU. Lorsqu'on appuie sur le bouton, on passe en mode lecture de la valeur des pots, ce qui permet donc de décaler l'image en les réglants, puis de mémoriser ces réglages en rappuyant sur le bouton.

  • Voyons ce que donnent les signaux :


− En blanc, le C−Sync d'entrée,
− En marron, le V−Sync de sortie du LM1881, qui entre dans le RP2040-Zero en GP5,
− En rouge, le C−Sync de sortie du LM1881, qui entre dans le RP2040-Zero en GP14,
− En orange, le V−Sync déphasé en sortie GP6 du RP2040-Zero, qui entre dans le 74LS132,
− En jaune, le C−Sync déphasé en sortie GP15 du RP2040-Zero, qui entre dans le 74LS132,
− En vert, la sortie du 74LS132, avec V−Sync + C−Sync réassemblés.

Lire la suite

Haut de page