[WIP 33%] Normaliser un signal vidéo

Page 1 sur 2 1, 2  Suivant

Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Jeu 25 Juil 2019 - 23:24

On parle de quoi?:
Préambule

Comme discuté précédemment, j'ai des soucis de réglage de mon écran (une télévision, en l'occurrence) quand je passe de mon slot MVS à ma Pandora Box (et à mon PC, accessoirement, mais on verra plus tard (480i)).

Mes problèmes

Le souci est classique: l'image ne fait pas la même taille, et n'est pas centrée de la même manière. Il faut donc passer par le menu de service de la télé pour régler la position de l'image. Et il ne s'agit pas simplement de toucher des potars sur un moniteur arcade (déjà bien casse bonbons), mais bel et bien d'entrer dans cet horrible menu prévu pour les réparateurs en entrant un Konami code sur la télécommande de la télé.

Problème similaire: j'ai une carte 60in1 sur une autre borne, qui tourne sur une petite télé que j'ai récupérée
gratuitement sur un vide grenier sans sa télécommande (donc pas d'accès au menu service).

Le but de la manoeuvre

Ce que je cherche à faire, c'est un système qui me permettrait de paramétrer rapidement le centrage de l'image sur mon écran (ou sur celui de quiconque serait intéressé) en appuyant juste sur un bouton.

Généralités - ce que j'ai compris

Concrètement: le fait que l'image varie d'une machine à l'autre est lié à plusieurs facteurs:
- Le balayage d'une ligne affichable est plus ou moins long, potentiellement à cause d'une résolution différente, mais potentiellement aussi simplement pour une raison de timing => l'image est plus ou moins large à l'écran
- Le timing entre la synchro et le signal vidéo est différent: l'image commence à s'afficher plus ou moins tôt lors du balayage => l'image est décalée horizontalement ou verticalement (ou très probablement les deux)

Warning, Will Robinson

Attention, avertissements:
- je ne suis pas spécialiste du signal vidéo. J'ai fait un supergun minimaliste en appliquant des résistances adaptées pour mettre les signaux au bon niveau de tension pour un téléviseur.
- je vais m'occuper uniquement du signal 240p, qui est utilisé par tout le matériel que j'ai en JAMMA, et qui me semble plus simple à comprendre
- il est très probable que je n'arrive à rien à la sortie, mais au pire, j'aurai appris 2 ou 3 trucs au passage ;-)
- il est probable aussi qu'il existe des appareils tout prêts qui font déjà ça très bien et pour pas cher

En théorie:
La doc que j'ai pu trouver

Je vais tenter d'expliquer ce que j'ai compris, en me concentrant dans un premier temps sur la problématique horizontale. J'imagine que la verticale se comporte à peu près pareil, mais je n'ai pas encore pu le constater. Si vous avez des infos ou compléments ou corrections à apporter, n'hésitez pas à intervenir!

D'un point de vue documentation, je n'ai pas trouvé grand chose sur Internet. Quand on parle de synchro et de balayage, on trouve beaucoup de doc sur la configuration des émulateurs. En creusant un peu, on finit par trouver des infos sur les signaux composites (synchro et couleurs sur le même fil). Or le JAMMA, c'est un fil par couleur et un pour la synchro.

Un affichage par balayage, comment ça marche (à mon avis) => On s'accroche!

J'imagine que tout le monde connait à peu près le fonctionnement d'un écran CRT, avec ses 3 canons à électrons, chacun dédié à une couleur, et qui parcourent l'écran ed gauche à droite et de haut en bas.
Je vais tenter de schématiser les différentes zones de l'écran d'après ce que je comprends...

[WIP 33%] Normaliser un signal vidéo Ecran10

On distingue 4 zones de balayage:
1 - La zone de synchro (canons éteints). Je ne sais pas vraiment où la caser sur le dessin, parce que j'imagine que ça correspond aussi à peu près au temps que mettent les canons pour traverser l'écran. Je le montre quand même parce que ça pourrait rendre la suite plus simple.
2 - La marge à gauche (et en haut) ou "Back Porch": les canons affichent la couleur de fond (noir en général, mais certains ordinateurs savent afficher une couleur ici, qui change potentiellement à chaque ligne)
3 - L'image (le plus facile, finalement)
4 - La marche à droite (et en bas) ou "Front Porch"
Pour la dénomination Front et Back, j'aurais utilisé la dénomination inverse, mais qui suis-je pour exprimer un avis? :-)

On peut rapprocher ces 4 zones des signaux qui transitent sur les fils Rouge, Vert, Bleu, Synchro (RVBS, ou RGBS en anglais).
Ca donne ça (je suis dessinateur professionnel):

[WIP 33%] Normaliser un signal vidéo Signau11

On retrouve nos 4 zones sur 2 graphiques.
Le premier montre ce qui transite sur les fils rouge, vert et bleu (il y a 3 fils, mais comme il se passe la même chose sur les 3, j'ai superposé les signaux).
Le second montre ce qui transite sur le fil de synchro.

Le principe de réglage de la position de l'image

Si on met en relation des deux dessins (l'écran et les graphiques), on serait tenté de se dire qu'il serait éventuellement envisageable peut-être... de décaler le signal de synchro dans le temps sans toucher au signal video:
- On avance le signal de synchro: il bouge vers la gauche sur le graphique, ça diminue le Front porch (4) et ça augmente le back porch (2) => ça diminue la marge à droite et ça augmente la marge à gauche => ça décale l'image vers la droite.
- On retarde le signal de synchro: il bouge vers la droite sur le graphique et l'image se décale vers la gauche.

Ca, c'est mon interprétation. Ca doit pouvoir s'appliquer aux marges verticales également.
L'idée serait donc ce jouer sur le centrage de l'image simplement en jouant sur le timing des signaux de synchro.

Les avantages

- On ne touche pas aux signaux R, V, B. Du coup, pas de perte de qualité
- On ne touche qu'à la synchro: elle est beaucoup moins complexe à gérer, parce qu'elle véhicule seulement une donnée binaire à une fréquence de 15kHz, ce qu'un microcontrôleur devrait pouvoir gérer sans le moindre problème.
- Si un microcontrôleur peut le gérer, alors on peut assez facilement proposer une interface de réglage intuitive et rapide, avec des pré-configurations par carte JAMMA à raccorder.

Les inconvénients

- On ne touche pas aux signaux R, V, B. Du coup, on n'a pas la main sur la longueur de la phase de balayage n°3 (l'image) => on ne peut pas régler la largeur de l'image
- On ne pourra donc pas avoir une image plein écran pour toutes les cartes JAMMA, et il faudra faire des compromis.

Les interrogations

- Est-ce que mon écran ne va pas me péter à la figure si je modifie les timings? Il doit y avoir un minimum de standard à respecter, mais je n'en ai pas la moindre idée. Mais c'est comme ça qu'on innove :-). Au pire, je pense que j'aurai de la perte de synchro et une image qui saute. Rien de grave.
- Je crois que les timings des signaux VGA, eux, sont super normés. On s'en fout, on ne produit pas du VGA :-)

Les observations:
L'analyse du signal sur une carte JAMMA

La première étape concrète est de souder des fils sur l'adaptateur JAMMA de ma carte MVS 138in1 (dont je n'ai plus l'utilité), et de regarder ce qui passe sur les canaux couleur (jai pris le vert) et synchro quand elle affiche son menu. J'arriverai peut-être ainsi à comprendre comment fonctionne la synchro verticale (comment on distingue le retour à la ligne du retour en haut de l'écran).

J'ai choisi l'option soudure parce que mes connecteurs JAMMA sont occupés à des tâches plus nobles, et je ne compte pas en acheter un juste pour ça. Je soude donc les fils directement sur le connecteur, et j'ajoute au bout des connecteurs Dupont pour pouvoir facilement brancher des fils dessus.
Voilà ce que donne l'installation. La carte est alimentée en +5V et +12V par un bloc d'alim de PC. Les sondes d'oscilloscope sont reliées sur le fil de la synchro et sur le fil du vert.

[WIP 33%] Normaliser un signal vidéo 20190714

Une fois que tout est branché, vient le moment de faire plein de réglages passionnants de l'oscilloscope pour attraper un balayage complet de l'écran...
Ouf, voilà globalement ce que donne un balayage (entre les deux lignes verticales en pointillés).

[WIP 33%] Normaliser un signal vidéo Vueglo10

La courbe bleue montre le signal de synchro, qui fait une impulsion par ligne de balayage. La courbe rouge montre le signal du vert (tiens, j'aurais peut-être mieux fait de changer la couleur sur le graphique). Nous avons donc sous les yeux une série de lignes d'affichage avec des signaux de vert (en rouge).
Comme on pouvait s'y attendre, le signal couleur est analogique.
Pour ce qui est de la synchro, je pense qu'il est purement logique. Il plafonne à 4.42V, ce qui est la tension d'alimentation (j'ai des câbles pourris, je perds 0,45V entre l'alim et la carte!), mais qu'il est distordu parce pas généré proprement par la carte. Après, pour prouver ça, ça va être compliqué Smile.
La mesure de fréquence du signal de synchro (en bas) indique une monenne de 15.67kHz. C'est rassurant, ça correspond à peu près à la norme pour du 240p.
Par contre, la mesure entre les barres me donne approximativement le temps de balayage de l'écran. Et 17.48ms, ça nous fait 57Hz. Pas tout à fait ce que je voulais, mais après tout, il ne s'agit que de la carte JAMMA de menu, et non du slot MVS. Je en m'attends donc pas à tomber pile dans des choses connues. Me voilà en tout cas rassuré sur le fait qu'une télé n'est pas très regardante sur le timing...

On zoome et on regarde d'un peu plus près ce qui se passe pendant le balayage d'une ligne:

[WIP 33%] Normaliser un signal vidéo Unelig10

Point important: les impulsions de synchro sont sur les fronts descendants et pas sur les fronts montants comme je le pensais. La synchro est donc active à 0V, et on obtient presque exactement ce que j'avais dessiné, mais avec la synchro à l'envers et en moins joli.
On voit qu'on a du signal video jusqu'à très près du signal de synchro, et repart plus loin (mais peut-être qu'il y avait du noir à gauche de l'écran, qui sait?). L'image doit être pas mal à droite de l'écran, d'après ma théorie. On a donc un front porch court et un back porch long.
On voit aussi que le signal de synchro est tout pourri. Peut-être à cause de la carte qui n'est pas de top qualité, peut-être à cause de mon alimentation qui n'est pas de top qualité. En tout cas, on dirait bien qu'il ne faudra pas trop se fier aux niveaux de synchro.

A présent, on se rapproche de la zone de vertical blanking (ou VBL, ça vous parle?), donc quand les canons à électrons repartent viser le haut de l'écran:

[WIP 33%] Normaliser un signal vidéo Retour10

On distingue un signal de synchro bizarre, que j'assimile à un signal de VBL: on compte 6 impulsions dont la durée est proche de celle du balayage d'une ligne (il faudra que je creuse ça pour mesurer le timing exact).
On compte à peu près 22 lignes vides avant le signal de VBL, et à peu près 21 lignes après. Vous les avez reconnues, il s'agit du front porch et du back porch verticaux.

Premiers essais - Pas assez rapide:
Qu'est-ce qu'on fait avec ça?

Maintenant qu'on sait à peu près à quoi ressemble le signal de synchro, il va falloir apprendre à la mesurer avec un microcontrôleur, de manière à pouvoir le reproduire avec un timing différent.
L'idée serait de faire grossièrement ça:

[WIP 33%] Normaliser un signal vidéo Schzom10

En gros, les signux vidéo sortent du connecteur JAMMA et partent sur l'écran, mais on intercepte le signal de synchro et on en produit un légrement déphasé.

La prochaine étape se passera donc au niveau soft. Il va falloir que je programme:
- la détection des différents timings
- le code de production d'impulsions courtes (changement de ligne) et longues (VBL).
- la génération d'un signal identique à celui d'origine
- la génération du signal décalé horitontalement
- la génération du signal décalé verticalement

Pour la production des impulsions, il me faudra peut-être passer par des circuits externes pour plus de précision, je ne sais pas encore.
Après génération du signal d'origine, je devrais être en mesure de brancher mon montage sur un écran et d'observer une image identique à l'image d'origine. Il m'aura fallu des heures pour ne rien faire à la sortie Wink

Mise en place du microcontrôleur et premiers tests de kecture de synchro

Je branche donc un Arduino sur le signal de synchro, et j'attaque le code...
Les sondes de l'oscilloscope sont branchées sur le signal de synchro produit par la carte JAMMA, et sur le signal produit par le microcontrôleur:

[WIP 33%] Normaliser un signal vidéo Jammae10

Premiers essais... étant donnée la fréquence du microcontrôleur (un Arduino Uno à 16MHz), on a une résolution de l'ordre de la micro-seconde. C'est également l'ordre de grandeur des largeurs d'impulsion de synchro, alors j'appréhende un peu les résultats quand il va falloir produire la synchro.
Je commence par essayer de détecter et mesurer les signaux produits par la carte JAMMA.
Pour gagner au maximum en précision, j'utilise une interruption matérielle pour compter les impulsions et mesurer l'écart entre les impulsions. L'écart entre impulsions doit correspondre à la durée de balayage d'une ligne.
Pour faire le calcul, j'attends une impulsion de référence, je prends une référence de temps, puis je compte 10 impulsions et je calcule le temps écoulé depuis le temps de référence et je le divise par 10.
Et ça donne ça:

[WIP 33%] Normaliser un signal vidéo Dureel10

Le nombre d'impulsions indiqué correspond au nombre d'impulsions comptées sur une période de 2ms.
Les résultats sont cohérents et surprenants à la fois (tout est en micro-secondes):
- La durée de scan d'une ligne est très variable, entre 60 et 67 µs. Ce qui donne une fréquence horizontale de 14,9kHz à 16,7kHz. C'est à peu près ça, mais ça devrait être constant! D'autant qu'on est sur u microcontrôleur, ça devrait être du temps réel, donc toujours le même comportement.

[WIP 33%] Normaliser un signal vidéo Durzoz10

- Cependant, le nombre d'impulsions sur 2ms est stable entre 31 et 32 impulsions.
- La durée d'impulsion est aussi assez bizarre... 8µs, c'est ce qu'on trouve quand on mesure avec l'oscillo. 64µs, c'est ce qu'on droit trouver quand on est sur les pulsations de VBL. Ca correspond avec les 31 impulsions ci-dessus, ça tombe bien. Par contre, d'où sortent les 16µs?!

Premiers essais de génération de signal de synchro

J'ai de sérieux doutes sur la précision de tout ça. On va devoir décaler le signal d'une fraction de microseconde. Ca doit pouvoir se faire avec un peu d'assembleur, mais je n'en ai pas fait depuis une vingtaine d'années.
Pour éprouver le temps de réaction du microcontrôleur, je vais tenter de faire un "suiveur": à chaque fois que je vois qu'une impulsion démarre, je démarra la mienne. Quand je la vois se terminer, je termine la mienne.

Voilà ce que ça donne à l'oscilloscope. En bleu le signal de synchro, et en rouge celui que je génère:

[WIP 33%] Normaliser un signal vidéo Follow10


On observe un décalage de 8µs entre le début du signal de synchro et le début du signal généré, soit la durée d'une impulsion de synchro. Sans la mesurer, l'impulsion générée est quand même aussi sensiblement plus longue que l'impulsion de synchro.

Et donc?

... et donc je me tâte à continuer l'expérience avec ce microcontrôleur.
Il me reste 3 macro-solutions:
- m'aider de composants externes (PLL, oscillateur, compteurs, portes logiques, ...) pour produire un signal de synchro qui ressemble à quelque chose. Ca peut être intéressant et enrichissant, mais ça va être une usine à gaz!
- utiliser un microcontrôleur plus rapide
- lâcher l'affaire

Dans l'ordre, on va tenter les options 2, 1 et 3.

Nouvel essai avec un nouveau micro-contrôleur:
Quel microcontrôleur choisir?

Voilà en gros ce que j'ai sous la main:
- Cartes Arduino Uno ou Pro Mini ou Pro Micro: toutes à base de microcontrôleur Atmel 8 bits cadensés à 16MHz => Ca a l'air un peu léger en termes de vitesse. Dommage, parce que c'est facile à utiliser
- Circuit intégré ATtiny84: microcontrôleur similaire à ceux embarqués sur les cartes ci-dessus, avec moins de RAM et moins de mémoire flash, mais qui peut monter à 20MHz => Ca risque de ne pas être beaucoup mieux, et ce n'est pas vraiment pratique de prototyper dessus.
- Carte STM32 "Blue Pill", on change de gamme avec un microcontrôleur 32 bits cadensé à 32MHz => Ca devient sensiblement plus rapide, mais pas énormément, et on passe à 3.3V, donc on ne pourra pas produire directement le signal de synchro.
- Carte ESP32, on change de monde avec un microcontrôleur 32 bits dual core à 240MHz => Fini la rigolade. Par contre, on est toujours en 3.3V.

Vu comme ça, mon choix s'oriente vers l'ESP32. Niveau prix, on est à environ 5€ pour ce modèle, c'est plutôt raisonnable.

Ce qui me gène pour le moment, c'est que les API de l'environnement de développement de l'Arduino, que j'utilise habituellement pour programmer tout ce petit monde, ne semblent pas supporter de timings en-dessous de la micro-seconde. Je vais creuser un peu, mais il va probablement falloir que j'installe (et que je découvre) l'environnement de développement de l'ESP32...

En creusant un peu plus, il semble que le SDK ESP32 sous environnement Arduino fournisse un jeu d'API complémentaire, qui permet entre autres choses de connaître le nombre de cycles d'horloge entre deux opérations. Et étant donnée la fréquence d'horloge de 240MHz, ça nous ramène à 4ns de précision. Là, on commence à parler!

Bon, dans les faits, j'ai remplacé l'Arduino Uno par un ESP32 et adapté le code... L'installation ressemble à peu près à la précédente, avec en plus un "level shifter" pour faire parler le monde 5V et e monde 3.3V :

[WIP 33%] Normaliser un signal vidéo Esp3210

La résolution est bien meilleure, on tombe à 2.6µs de retard entre le signal détecté et le signal produit. La conversion de niveau de tension n'occasionne aucun retard significatif.

[WIP 33%] Normaliser un signal vidéo Floolw10

On va voir si je peux faire plus rapide en utilisant directement l'environnement du constructeur. Au pire, j'aurai appris un truc!
=> tout est installé, et les premiers tests sont faits. La réactivité n'est pas fulgurante, mais c'est quand même un peu mieux parce qu'un nouveau monde d'API, avec notamment de nouveaux timers de précision, est à portée.

J'ai passé pas mal de temps à réfléchir à la manière de générer une synchro qui ne se déphase jamais par rapport à la source (sinon, c'est les vagues verticales assurées). Le plus simple me semble de réagir systématiquement aux impulsions de la source, puis de temporiser avant de les reproduire (décalage horizontal) et de jouer sur leur largeur (pour placer le VBL où je veux, et donc jouer sur le décalage vertical).

Je viens de trouver un super article qui explique ça super bien, et qui me fait réaliser que les pulsations de VBL sont en fait décalées d'une demi-période par rapport aux pulsations de HSYNC! => Fausse frayeur. Les demi-pulsations, c'est pour le 480i. En fait, j'avais tout bon, ouf.
Ca se passe ici:
HDRetrovision - Engineering CSYNC

A l'attaque
Je commence à me familiariser avec l'environnement de développement.
Je crée mon premier bout de code concret: je configure un gestionnaire d'interruption pour compter les impulsions de synchro de ma source vidéo.
Le calcul est simple: je mesure le temps qu'il faut pour compter 5000 impulsions.
Après ça, une division me donne la fréquence horizontale.

Et ça marche, je suis tout chose bounce

[WIP 33%] Normaliser un signal vidéo Mesure10

Pour la fréquence verticale, ça va être plus compliqué, parce qu'il va falloir mesurer les largeur d'impulsions pour détecter le VBL.
Mais la structure est là et ça marche, c'est déjà bon pour le moral.  fete

A force de prise de tête, j'ai fini par produire du code à peu près optimisé pour reproduire le signal d'origine avec un décalage temporel réglable.
Le principe est de faire deux choses à la fois: scruter les impulsions produites par la carte JAMMA, attendre un certain temps en fonction du décalage horizontal ou vertical qu'on veut, et reproduite les mêmes impulsions.
Pour faire deux choses en même temps, le secret, c'est d'utiliser les interruptions matérielles...
En gros, on dit au microcontrôleur d'arrêter tout ce qu'il est en train de faire dès qu'il reçoit un événement sur l'une de ses broches. Ici, on va lui dire de scruter les débuts et les fins d'impulsions.
Quand une impulsion a lieu, on exécute donc du code spécifique pour détecter le type d'impulsion (courte ou longue, en fonction du temps écoulé entre le début et la fin), et détecter la ligne en cours de balayage.
On peut voir ça comme ça:

[WIP 33%] Normaliser un signal vidéo Lesint10

Pour faire des tests tranquille dans mon salon, j'ai reproduit un signal de référence dans le générateur de fonctions intégré à mon oscilloscope. Le signal correspond à 8 lignes d'image et 2 lignes de synchro, émises à un fréquence équivalente aux 15,67kHz de la carte JAMMA de test.
Le signal généré ressemble donc à ça:

[WIP 33%] Normaliser un signal vidéo Genera10

Là, je commence à penser que je m'en suis bien sorti, ça a l'air de fonctionner...
Voilà ce que je peux observer à l'oscillo. En bleu, la pulsation de référence, et en rouge celle que je produis en retour:

[WIP 33%] Normaliser un signal vidéo Signal10

Et puis il m'arrive de détecter un décalage. On dirait qu'il m'arrive de perdre des signaux d'entrée, et du coup de me décaler dans mon comptage de lignes... et donc de produire un signal de synchro décalé d'une ligne, puis 2, puis 3...
Je me dis qu'à la vitesse où ont les choses, ça ne devrait pas trop se voir à l'écran, mais ce n'est pas très satisfaisant.
J'essaie donc d'en savoir plus, et j'observe des kilomètres de courbes à la recherche d'un départ de décalage qui me mettrait sur une piste.
Et là, horreur, voilà sur quoi je tombe:

[WIP 33%] Normaliser un signal vidéo Signal11

Grosse lassitude... Je ne perds pas un signal de temps en temps, j'en perds carrément une caisse... Je relis mon code dans tous les sens, et je finis par en conclure que le problème vient de l'OS du microcontrôleur ESP32 pour gérer les deux coeurs et le matériel embarqué (Wifi, Bluetooth). Il s'appelle FreeRTOS, avec RT qui signifie Real Time. Et sur le coup, j'ai bien l'impression que le côté RT est un peu usurpé. J'ai beau faire en sorte d'avoir l'exclusivité du coeur 1 du microcontrôleur, on dirait bien que je me prends une préhension de 10ms qui me met dedans.

Ne nous laissons pas démonter. Après tout, j'ai quand même appris à utiliser l'environnement de ce microcontrôleur, ça servira un jour ou l'autre!

Encore un autre essai avec encore un autre micro-contrôleur:
On passe donc au nième plan B... Les plateformes du genre Arduino à base de microcontrôleur 8 bits ont montré leurs limites (pour faire ça, en tout cas). Je passe donc au dernier modèle que je n'ai pas encore testé: le STM32. Par contre, l'architecture n'a rien à voir, on ne fait pas les choses de la même manière, et je dois reprendre tout le code.
Un STM32 Blue Pill (comme dans Matrix), ça ressemble à ça:

[WIP 33%] Normaliser un signal vidéo Bluepi10

Une fois le code repris, j'arrive assez bien à suivre le signal...

[WIP 33%] Normaliser un signal vidéo Bluepi10

Je n'ai pas encore récupéré le code qui permet de retomber sur ses pattes quand le signal de désynchronise. Je laisse tout ça tourner un moment pour voir si je tiens enfin ma solution! Et là, j'observe un truc auquel je ne m'attendais pas. OK, je ne perds pas de pulsations, mais curieusement, j'ai des pulsations en trop!!! En remontant un peu le temps, je trouve ça:

[WIP 33%] Normaliser un signal vidéo Anomal10

Je relis mon code pour la 27ème fois pour voir où je me suis raté. Et là, je me dis que je n'ai pas pu me rater à ce point, et je cherche une cause externe. Illumination, je réduis la résolution verticale de l'oscilloscope, qui produit une sortie 12 bits à partir d'informations 8 bits, induisant un lissage du signal invisible quand on ne travaille pas en hautes fréquences (ce n'est pourtant pas le cas ici).
Voilà ce que ça donne quand je passe la voie d'entrée en 8 bits:

[WIP 33%] Normaliser un signal vidéo Anomal11

Et voilà donc l'explication! Les débuts et fins d'impulsions générées par le microcontrôleur produisent des parasites sur l'entrée, qui sont interprêtés comme des pulsations par le gestionnaire d'interruption, qui me détecte un changement de ligne!

Si j'affiche tout en 8 bits, ça donne un bon aperçu du carnage. Voilà donc ce qui se passe dans les tuyaux, et pourquoi les gens utilisent des condensateurs de découplage!

[WIP 33%] Normaliser un signal vidéo Anomal12

Je fais des essais avec plusieurs valeurs de condensateurs sur l'alimentation et sur la sortie, sans résultats magiques. Les plaques lab, où je fais le montage, sont réputées pour la mauvaise qualité des connexions et leurs inductances parasites On est en plein dedans!
Je fais un essai en décollant la plaquette du microcontrôleur de la plaque lab. Les résultats déjà meilleurs, mais je fais les connexions en tenant les fils en place, donc ce n'est pas très propice à l'expérimentation.

Après un test en version soudée, j'ai à peu près les mêmes résultats pas terribles. Le passe donc au 27ème plan B, et je teste l'option buffer: c'est un circuit intégré qui prend un signal numérique d'un côté, et qui sort le même de l'autre. En gros, c'est comme une porte logique qui renvoie toujours le signal d'entrée (une porte "OK"?).
L'avantage de ce circuit est qu'il peut nettoyer un signal d'entrée pas beau, et le sortir à niveau de tension de son alimentation. Ici, je rentre du 3.3V crado, et j'en fais un joli 5V. J'en profite pour augmenter l'impédence d'entrée et de sortie pour calmer un peu les pics quand même (j'ajoute des résistances en série, quoi).

[WIP 33%] Normaliser un signal vidéo Soudzo10

Et là, comme par magie, j'obtiens un signal tout beau, tout propre:

[WIP 33%] Normaliser un signal vidéo Aveccd10

Du coup, je me sens en veine, et je fais un essai sur le vrai matériel, la carte JAMMA 138in1.
Et là, ça ne marche pas terrible, la fréquence, est fausse, c'est n'importe quoi. En même temps, ça aurait été dommage, on s'amuse tellement.

Visiblement, le signal de sortie de la carte n'est pas le même que celui que j'avais trouvé sur Internet. On m'avait prévenu qu'il pouvait y avoir des variations, mais là, j'en suis à me demander comment la télé arrive à s'en sortir...

Les différents signaux vidéo de mes différentes cartes JAMMA:
Voilà les différentes techniques de synchro VLB sur les différentes cartes que j'ai à la maison. Il faut garder en tête qu'une ligne dure un peu plus de 63µs...

- 138in1 (Carte JAMMA qui pilote la carte multi MVS): la synchro se fait sur les fronts descendants. Puis, pendant le VBL, la synchro se fait sur le front montant (pourquoi faire simple?):
[WIP 33%] Normaliser un signal vidéo Synchr10

- 60in1 (Carte JAMMA avec 60 jeux des années 80, super bien quoi qu'en disent certains). La synchro se fait sur les fronts montants, puis plus de synchro pendant le VBL (débrouille-toi avec ça):
[WIP 33%] Normaliser un signal vidéo Synchr11

- Pandora Box X (hardware de la Pandora Box 3): la synchro se fait sur les fronts descendants, puis le VBL arrive et un front descendant disparait et tout se décale, mais à la fin, ouf, tout revient dans l'ordre (et on perd aussi un front descendant à la sortie):

[WIP 33%] Normaliser un signal vidéo Synchr12

- Slot MVS (c'est pour ça qu'on est là): enfin quelqu'un qui fait les choses bien! on a bien des fronts descendants réguliers, la vie est belle. Par contre, on a un record de nombre de pulsations de VBL (8!):

[WIP 33%] Normaliser un signal vidéo Synchr13

Si je me restreins au slot MVS, mon montage devrait fonctionner. Mais le but de la manoeuvre est de régler les marges en fonction de la carte branchée (hors 60in1 qui est dans une borne qui lui est dédiée). Il va donc falloir gérer tous ces cas, et potentiellement d'autres!

Essais en électronique discrète - le PLL:
En faisant le point au calme, je me dis que la plus pourrie des télés trouvée dans la rue s'en sort très bien pour afficher une image. La différence entre elle et mon système est qu'elle se pose beaucoup moins de questions, et qu'elle n'a pas un programme qui tourne et qui essaie de comprendre ce que le constructeur du périphérique d'entrée a essayé de faire.
La piste qu'elle choisit est celle de l'électronique, et plus précisément d'un composant que j'ai découvert il y a peu, le PLL (ou Phase-Locked Loop, ou boucle à verrouillage de phase).
Il s'agit en gros d'un oscillateur, et qui prend pour référence un signal d'entrée et qui essaie de vibrer à la même fréquence. Il met un certain temps avant de s'accorder sur le signal qu'il imite, ce qui fait qu'il ne verra pas trop passer les signaux de VBL bizarres.
Ici, on va s'en servir pour suivre le signal de synchro aussi bien que possible. Et c'est son signal de sortie qui nous servira à produire le nôtre!

Curieusement, on se rapproche un peu du scénario usine à gaz du départ. On va avoir de la porte logique et du PLL, il ne manque que le compteur et la panoplie du cauchemar est complète :-).

Premiers tests avec un PLL et le générateur de fonctions de mon oscilloscope. Il y a un paquet de composants à ajuster pour paramétrer la boucle de verrouillage. Il faut trouver les bonnes valeurs de résistances (il y en a 3) et de consendateurs (il y en a 2) pour que la boucle verrouille sur du 15kHz et pour qu'elle lisse correctement les signaux VBL moisis.
L'installation fait un peu flipper...

[WIP 33%] Normaliser un signal vidéo Montag10

Voilà ce que fait un PLL bien réglé sur un signal 15kHz (en bleu l'originaml, en rouge le signal de sortie du PLL):

[WIP 33%] Normaliser un signal vidéo Pllgen10

Sur un signal qui sort de la carte JAMMA, c'est pareil, sauf quand arrive le signal VBL. On voit qu'il y a un créneau plus long que les autres, utilisé pour raccrocher les wagons avec la fréquence de base:

[WIP 33%] Normaliser un signal vidéo Pll13810

C'est donc reparti pour les essais de valeurs de résistances pour que la rétroaction soit moins violente. Et j'arrive à ça... la pulsation est plus régulière, et je rattrape les bizarreries du signal d'entrée (ici la durée horitontale change carrément pendant le VBL). On voit le déphasage pendant le VBL, puis le PLL raccroche délicatement les wagons et se recale tranquillement sur le signal de synchro:

[WIP 33%] Normaliser un signal vidéo Plless10

Je vais me caler sur ce signal pour produire mes pulsations. Le PLL fait pour moi tout le travail d'intégration du signal en entrée pour me produite un signal tout propre pour produire mon signal déphasé en sortie (oui, c'est le but).

... et le code est refait pour s'adapter à ce nouveau signal, issu du PLL.
Sur le papier et de loin, tout fonctionne impec.
En observant les signaux original/copie, je m'aperçois de variations temporelles: les fronts descendants ne sont pas toujours parfaitement alignés. La conséquence, prévisible sur l'écran, c'est une ondulation de l'image. C'est rigolo, mais ce n'est vraiment pas le but recherché.
Deux explications:
- Le PLL ne synchronise pas parfaitement, il lui faut un peu de temps pour se remettre des fluctuations du signal d'entrée pendant les VBL. Pour ça, en bricolant encore un peu avec les résistances et condensateurs, je devrais arriver à trouver un réglage un peu plus stable (peut-être?)
- Le microcontrôleur met un temps qui n'est pas constant pour traîter les interruptions. Et pour cause... Les calculs ci-dessous.

En 15kHz, une ligne s'affiche en environ 63µs. Pour donner une idée, une machine comme la NeoGeo a une résolution de 320x224 pixels. On affiche donc 320 pixels en 63µs, soit environ 5 pixels par µs.
Quand j'affiche une version rémanente de l'écart entre le front descendant issu du PLL et celui issu du microcontrôleur, je visualise une instabilité qui s'étale sur à peu près 800ns (nano secondes, oui):

[WIP 33%] Normaliser un signal vidéo Erreur10

En faisant le calcul, on peut compter que, même sans compter l'erreur du PLL, on a déjà une erreur équivalente à 4 pixels. Le résultat doit donc être carrément flou.

Je ne m'explique pas totalement cette erreur. Le microcontrôleur travaille en temps constant, et dispose d'une horloge de 72MHz, donc environ une instruction (machine) tous les 13ns avec 1 MIPS/MHz (c'est le cas pour l'Arduino, pas forcémént pour le STM32, mais ça donne une idée). Avec ça, je ne vois pas comment je peux me retrouver avec une variation de 800ns, sachant que je réagis directement à l'impulsion, sans consultation de l'horloge (ça, par contre, ça induit de sacrés décalages, l'API d'horloge fournit seulement de micro secondes).

Bref, je vais réfléchir à tout ça, et je devrai peut-être partir sur ue piste un peu plus hard (c'est le cas de le dire) et jouer du compteur et de la porte logique.

Nouvelle idée à base de composants discrets. Ca promet d'être amusant !

Ce n'est pas forcément clair, mais la grosse difficulté de l'entreprise n'est pas le calage vertical. Pour celui-là, il suffit de produire des impulsions de VBL au même rythme que le signal original, mais décalés d'un nombre entier de cycles en avant ou en arrière.
La craie difficulté, c'est de parvenir à décaler finement l'impulsions à l'intérieur d'une période de 63µs (une ligne de balayage) pour décaler l'image horizontalement de quelques pixels.

Dans un premier temps, j'ai pensé utiliser un second PLL pour découper le signal de synchro en rondelles (donc un signal de fréquence plus élevée), pour piloter un registre à décalage qui me permettrait de décaler dans le temps le démarrage de la synchro.
Cette option m'a paru plutôt chouette, avec encore quelques inconnues sur la possibilité de multiplier mes 15kHz de départ par un nombre suffiant pour une bonne résolution de réglage horizontal, tout en restant gérable. En partant sur un découpage de la ligne en 20 crans de réglage, il faut multiplier mes 15kHz par 20 et je produis déjà 300kHz. Etant donnée la précision de mon matériel, je crais d'induire de nouvelles "vibrations" horizontales, qui pourrissent l'image rendue.

Et là, il y a 2 jours, je tombe sur une vidéo de présentation des PLL très bien fichue et dans les 2 dernières minutes, le gars présente une astuce l'air de rien: en injectant une tension à l'entrée du générateur de fréquence, on peut déphaser le signal de sortie. Ca n'a l'air de rien, mais c'est EXACTEMENT CE QUE JE CHERCHAIS A FAIRE pour mon décalage horizontal!
Je viens de faire le test, ça marche impec. Je peux décaler le signal d'au moins une période complète (une ligne de balayage) sans perdre la syynchro du PLL!

Du coup, je suis passé à l'expérimentation, et je commencer à tester l'enchaînement de PLL:
- le premier récupère un signal de synchro propre, sans ces cochonneries d'impulsions de VBL toutes plates
- Le second gère le décalage horizontal.

J'ai encore un peu de boulot pour le réglage de ces deux PLL.
Par contre, niveau matériel, je n'ai qu'un oscilloscope à 2 voies, qui ne me permet pas d'afficher à la fois le signal d'entrée, et celui de sortie des deux PLL qui suivent. Or il est essentiel que je puisse observer ces trois signaux pour détecter et mesurer leurs décalages respectifs.
Et c'est ici qu'intervient mon nouveau jouet chinois à 5,51€: un analyseur de protocoles 8 bits. C'est un petit boitier USB avec 8 fils qu'on branche où on veut, et le PC engegistre les signaux logiques envoyés sur ces fils et fait de jolis graphiques interactifs.
Je viens de faire le test, c'est carrément chouette (et pour le prix, c'est hallucinant)!

L'installation à 5,51€:
[WIP 33%] Normaliser un signal vidéo Logiqu10

Le rendu, avec seulement 3 voies sur les 8 utilisées:
[WIP 33%] Normaliser un signal vidéo Logic10

La suite: régler les PLL correctement, essyer de virer les impulsions de VBL avec des filtres pour perturber un peu moins les PLL. Tout un programme, mais au moins j'aurai les outils pour le suivre!

Les PLL commençant à me donner des boutons, je commence à me dire qu'il faudrait que je fasse disparaître toute la zone de VBL du signal, pour ne conserver qu'un signal régulier synchronisé sur le signal de synchro original. C'est à partir de ce signal que je pourrai câbler un PLL qui me fera un offset horizontal.
En gros, signal de synchro:
- En entrée: une suite de HSYNC avec entre 4 et 10 signaux VSYNC
- Bricolage du signal pour récupérer une suite de HSYNC, avec d'autres HSYNC qui remplacent les VSYNC
- Un PLL se calque sur ce signal
- On introduit un offset d'entrée sur le PLL pour déphaser le signal (et donc décalage) horizontal de l'image)
- On génère des signaux VSYNC quand on veut, en décalage par rapport aux signaux VSYNC d'origine (et donc décalage vertical de l'image)

Je vais effacer le signal HSYNC en produisant un signal carré de à 15,6kHz, que je synchronise sur les fronts descendants du signal de référence. Quand je ne détecte pas de front descendant, c'est que je suis sur un VSYNC. Mais ce n'est pas grave, mon signal carré continue sa vie et me génère les créneaux manquants.

Pour générer le signal carré, j'utilise un composant à 1€ les 20 circuits intégrés: le timer 555. On peut faire plein de choses basées sur le temps avec ce circuit. Je l'utilise en multivibrateur astable (en oscillateur, quoi).

Voilà donc la dernière installation en date, qui fonctionne plutôt bien à l'exception du PLL. Je crois que je vais finir par chercher une autre solution pour faire le décalage horizontal parce qu'il commence à me gonfler.
J'ai ajouté des potars un peu partout. Dans l'ordre: réglage de la fréquence d'oscillation et du rapport cyclique, et durée de l'impulsion de reset pour l'oscillateur astable.
C'est blindé de câbles parce que j'ai mis des sondes dans tous les sens...

[WIP 33%] Normaliser un signal vidéo 20190913

Le fonctionnement est donc gorssièrement le suivant:
- Un oscillateur (astable) oscille à 15kHz. Il me servira de signal pour produire mon signal de synchro décalé
- Cet oscillateur doit être synchronisé sur le signal de synchro de référence, issu du connecteur JAMMA. On le synchronise sur les fronts descendants (ce sont eux qui font foi)
- Pour ça, on envoie une impulsion pour faire un reset sur l'astable lors de chaque front descendants
- L'impulsion doit avoir une durée minimum et l'impulsion HSYNC standard n'est pas assez longue. Du coup, on utilise un monostable, qui sait produire des impulsions de durée réglable suite à une impulsion d'entrée
- Le monostable doit recevoir une impulsion plus courte que celle qu'il produit lui-même. Conclusion: il va faire n'importe quoi quand un VSYNC va passer
- On utilise une bascule, en gros une variable booléenne, qui est pilotée par de la logique. On l'appelle "Ready for pulse" parce que c'est cool
- L'impulsion ne démarre que si Ready est vrai, et s'arrête si Ready est faux
- Le vrai et le faux sont basculés (d'où le terme) en fonction de l'état du signal, première couche de logique
- L'impulsion est un mélange entre la valeur de la bascule et celle du signal d'entrée, deuxième couche de logique

Ce qui est cool, c'est que mon analyseur 8 bits à 4€ me permet de visualiser en parallèle 8 signaux de mon montage:

0 - Entrée (signal synchro vidéo JAMMA, ici le générateur de fonctions de mon oscilloscope). Les phases plates sont les signaux de VSYNC qu'on essaie d'éliminer
1 - Set de la bascule "Ready for pulse" (passe la valeur à 1 quand le signal passe à 0)
2 - Reset de la bascule "Ready for pulse" (passe la valeur à 0 quand le signal passe à 0)
3 - Etat de la bascule "Ready for pulse" => Peut-on générer une impulsion en direction du monostable?
4 - Pulsation en direction du monostable, mélange de la valeur de la bascule et de celle du signal, on voit qu'il n'y a pas de pulsation pendant les phases de VSYNC
5 - Sortie du monostable = signal de reset de l'astable. Il n'y en a pas pendant les phases de VSYNC. L'astable continuera donc à osciller tout seul
6 - Oscillateur astable. Descent en même temps que les HSYNC du signal d'origine, et continue sur sa lancée pendant les VSYNC. Passe à 0 à chaque impulsion du monostable
7 - Oscillateur PLL qui n'arrive pas à se synchroniser sur le signal de l'oscillateur astable et qui commence à me gonfler sérieusement.

[WIP 33%] Normaliser un signal vidéo Sequen10

J'ai appris plein de choses hier en essayant de déphaser le signal de sortie. Notamment à générer une impulsion à partir d'un créneau sans passer par de la logique compliquée et une bascule.
J'ai eu une révélation en rentrant du boulot ce soir. Résultat, j'arrive exactement au même résultat qu'avant avec le circuit suivant:

[WIP 33%] Normaliser un signal vidéo 20190914


On peut observer le signal d'entrée en haut, tout moisi, et le signal de sortie, en bas, généré, qui est synchronisé sur le signal d'entrée:

[WIP 33%] Normaliser un signal vidéo Plussi10


Dernière édition par Bouz le Lun 9 Sep 2019 - 21:49, édité 22 fois (Raison : Avancement)
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Joker le Ven 26 Juil 2019 - 8:21

Super intéressant et beau projet ,effectivement pour moi le plus compliqué ce sera de ne pas perdre les synchros . mrgreen

_________________
"Il est indispensable d'avoir une euro dans un setup arcade" :Raditz 2/02/2018.


[WIP 33%] Normaliser un signal vidéo Sign_m10

John Caffe le 25/09/2018:"Je comprends mieux ta remarque. Toi, t'es au moins ingénieur, et probablement inscrit à Mensa "
Joker
Joker
Scellé
Scellé

Messages : 3361
Date d'inscription : 01/10/2016
Age : 42
Localisation : Bordeaux

https://youtu.be/6u-tp2f_Pt8

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Sam 27 Juil 2019 - 0:58

Semaine de boulot terminée, en route pour le bricolage!
Ce soir, analyse du trafic sur les fils des signaux Vert et Synchro d'une carte Jamma.
Prochaine étape, connecter un micro-contrôleur là-dessus. La bonne nouvelle, c'est que la tension de synchro est la même que celle des entrées-sorties logiques du microcontrôleur. On va gagner du temps et ce sera bien plus simple!
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Sam 27 Juil 2019 - 22:59

Edit: premiers essais de détection et génération d'impulsions de synchro avec un microcontrôleurs, et premières interrogations.
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Dim 28 Juil 2019 - 14:41

Edit: on essaie avec un ESP32.
Promis, quand j'arrive à quelque chose de concret, je fais du ménage et je garde 2 images et 3 paragraphes ;-)
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par cypher le Lun 29 Juil 2019 - 7:47

T'es un sacré bidouilleur! tu devrais bien t'entendre avec Bernamaphrodite ^^

_________________
"amoureux des vieilles fentes" I love you

[WIP 33%] Normaliser un signal vidéo 943190OD9MGVj [WIP 33%] Normaliser un signal vidéo 514500kof94photo32 [WIP 33%] Normaliser un signal vidéo Sign_a10
cypher
cypher
Scellé
Scellé

Messages : 3198
Date d'inscription : 25/10/2015
Age : 42
Localisation : 62

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Lun 29 Juil 2019 - 13:22

@cypher a écrit:T'es un sacré bidouilleur! tu devrais bien t'entendre avec Bernamaphrodite ^^

C'est gentil, mais on ne joue pas dans la même cour! bave
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Jeu 1 Aoû 2019 - 13:29

Edit: découverte d'une super page qui décrit le fonctionnement du signal de synchro. Je n'ai pas dit que des bêtises, c'est rassurant ;-)
HDRetrovision - Engineering CSYNC
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Jeu 1 Aoû 2019 - 23:56

Edit: maintenant que je sais que je suis sur la bonne voie, je commence le code, et je parviens à calculer la fréquence horizontale. Je suis tout excité.
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Mar 6 Aoû 2019 - 18:08

J'arrive à produire un signal avec un microcontrôleur ESP32. Problèmes, changement de plan.
J'alterne les problèmes et les soucis, mais je pense que je tiens la solution cible.
Nous voilà donc avec un microcontrôleur STM32 et un nouveau lot de problèmes à régler.
Vraiment sur la bonne voie, cette fois-ci?
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Mer 7 Aoû 2019 - 16:54

Aujourd'hui, prise de conscience du fait qu'il y a autant d'interprétations du standard 240p qu'il y a d'outils pas rangés sur mon bureau.
Présentation des 4 cas que j'ai sous la main, et on part dans une nouvelle direction. Destination le PLL...
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Mer 7 Aoû 2019 - 22:37

Edit: le PLL est dans la place! Ca y est, j'ai un signal propre pour travailler. Plus qu'à reprendre tout le code bat
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Jeu 8 Aoû 2019 - 0:54

Edit: code repris, analyse du résultat: le résultat n'est pas assez stable, ça va onduler combat
Projet en pause le temps de trouver une solution alternative! scratch
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Mer 14 Aoû 2019 - 21:04

Je suis certain que ça va bouleverser votre potentiellement long week-end (moi je bosse vendredi), mais je vous annonce quand même que j'ai trouvé de nouvelles pistes à explorer...
Ce sera à base de:
- micro-contrôleur pour compter les lignes, gérer le décalage vertical, et piloter le reste
- PLL pour générer des pulsations régulières pendant le VBL
- portes logiques pour utiliser les pulsations d'origine tout le temps et celles du PLL pendant le VBL d'origine (c'est ça le coeur de l'astuce n°1).
- un autre PLL et deux compteurs décimaux pour multiplier par 20 la fréquence du signal de synchro et générer les crans de décalage horizontal.
- des registres à décalage en chaîne, pilotés par le signal ci-dessus, pour générer des impulsions décalées dans le temps qui permettront de gérer le décalage horizontal
Des multiplexeurs câblés sur les registres à décalage, et configurés par le micro-contrôleur pour laisser passer la pulsation décalée choisie.
Voilà, avec tout ça, le micro-contrôleur n'est plus responsable du calage temporel des pulsations, et je ne devrais plus rien perdre.
C'est presque trop facile.
Je vais commencer par tester la génération 15x20=300kHz à partir d'un signal de référence à 15kHz.
Puis direction les tests de registres à décakage pour voir s'ils supportent des commandes à 300kHz. Je devrai peut-être revoir la finesse du réglage horizontal si ça ne passe pas.
Un nouvel espoir, donc!
J'espère avoir été clair (j'en doute).
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Joker le Mer 14 Aoû 2019 - 22:38

C'est bien tu gardes le moral ! yesss

_________________
"Il est indispensable d'avoir une euro dans un setup arcade" :Raditz 2/02/2018.


[WIP 33%] Normaliser un signal vidéo Sign_m10

John Caffe le 25/09/2018:"Je comprends mieux ta remarque. Toi, t'es au moins ingénieur, et probablement inscrit à Mensa "
Joker
Joker
Scellé
Scellé

Messages : 3361
Date d'inscription : 01/10/2016
Age : 42
Localisation : Bordeaux

https://youtu.be/6u-tp2f_Pt8

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Dim 18 Aoû 2019 - 14:27

Je ne lâche rien, même si je sais pas forcément dans quoi je mets les pieds au départ. C'est un poil chronophage mais très enrichissant.
Mais du coup, il ne faut pas être pressé!
Cette rubrique est parfaite pour moi: ça me pousse un peu plus à aller jusqu'au bout et à structurer ma pensée, même si ça ne passionne pas les foules ;-)
Merci de me suivre!
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Mar 20 Aoû 2019 - 23:24

Aujourd'hui (enfin avant-hier), découverte d'une nouvelle possibilité avec un PLL: lui injecter une tension qui déphase le signal de sortie: l'idéal pour produire un décalage de l'image horizontal tout en douceur et en prévision!
Et aussi, j'utilise pour le première fois mon analyseur logique à 5€ pour contrôler le déphasage de mes signaux dérivés de la synchro. Et c'est trop la classe!
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Mar 3 Sep 2019 - 22:35

Bon, vu que ça commence à être franchement chargé, et que je vais attaquer le 37ème plan B (il n'y a plus assez de lettres dans l'alphabet), j'ai rassemblé tout ça en spoilers. Je ne laisserai en clair que la tentative en cours :-)
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Mar 3 Sep 2019 - 22:54

Et donc le 37ème plan B à base de portes logiques et d'un oscillateur. L'air de rien, je commence à voir pas mal de composants intéressants. Si ça continue, il est possible que je parvienne à quelque chose.
J'obtiens le signal le plus propre que j'aie pu voir jusqu'ici. Pourvu que j'arrive à en faire quelque chose!
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par theWave le Mer 4 Sep 2019 - 8:21

Ou tu trouves tes composants ? Tu as un shop d'électronique par chez toi ?

_________________
Sanjuro a écrit:en Special Guest Star, WRC dans le rôle de theWave
ancien directeur du service de renseignements NGS, il a le bras long comme un anaconda sous stéroïdes, si un gros bonnet doit se coucher, c'est qu'il en a donné l'ordre.
theWave
theWave
Pièce unique
Pièce unique

Messages : 7122
Date d'inscription : 25/10/2015

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Mer 4 Sep 2019 - 8:36

Si seulement... j'habite à la campagne. J'ai deux boulangeries et une boucherie pas loin.
Pour les composants, je commande des lots de 20 circuits intégrés à 1€ sur eBay et je les reçois 2 mois plus tard. Ca demande pas mal d'anticipation :-)
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par theWave le Jeu 5 Sep 2019 - 11:42

OK un peu comme nous dans le 47...
Pour les condos et autres capkits ou composants on a Conrad...

_________________
Sanjuro a écrit:en Special Guest Star, WRC dans le rôle de theWave
ancien directeur du service de renseignements NGS, il a le bras long comme un anaconda sous stéroïdes, si un gros bonnet doit se coucher, c'est qu'il en a donné l'ordre.
theWave
theWave
Pièce unique
Pièce unique

Messages : 7122
Date d'inscription : 25/10/2015

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Jeu 5 Sep 2019 - 13:52

J'ai fait un capkit sur une télé, je suis passé par Farnell. Pas de frais de port au-delà d'un prix pas très élevé que j'ai oublié, et composants de qualité. Mais forcément plus cher que les lots douteux à 1€ chinois.
Je n'acheterais pas de condos en vrac sur eBay pour un cap kit!
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Bouz le Jeu 5 Sep 2019 - 23:20

Edit: j'ai enfin un signal d'horloge calé sur le signal de synchro, et qui poursuit son chemin indépendamment des cochonneries de VBL.
Je suis donc, a priori, en mesure d'introduire un décalage vertical de l'image sur les 3 cartes JAMMA dont je dispose.
Maintenant, il va falloir trouver un moyen d'introduire un décalage horizontal. Soit avec un PLL, soit avec un autre timer 555. En tout cas, la base est stable et c'est très cool.
cheers
Bouz
Bouz
Used
Used

Messages : 332
Date d'inscription : 11/06/2019
Age : 41
Localisation : Saint Bauzille de Putois

https://www.youtube.com/user/openio

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par theWave le Ven 6 Sep 2019 - 20:43

@Bouz a écrit:J'ai fait un capkit sur une télé, je suis passé par Farnell. Pas de frais de port au-delà d'un prix pas très élevé que j'ai oublié, et composants de qualité. Mais forcément plus cher que les lots douteux à 1€ chinois.
Je n'acheterais pas de condos en vrac sur eBay pour un cap kit!

Intéressant pour Farnell car sur Conrad il y a tjs du port même pour des sommes élevées.

_________________
Sanjuro a écrit:en Special Guest Star, WRC dans le rôle de theWave
ancien directeur du service de renseignements NGS, il a le bras long comme un anaconda sous stéroïdes, si un gros bonnet doit se coucher, c'est qu'il en a donné l'ordre.
theWave
theWave
Pièce unique
Pièce unique

Messages : 7122
Date d'inscription : 25/10/2015

Revenir en haut Aller en bas

[WIP 33%] Normaliser un signal vidéo Empty Re: [WIP 33%] Normaliser un signal vidéo

Message par Contenu sponsorisé


Contenu sponsorisé


Revenir en haut Aller en bas

Page 1 sur 2 1, 2  Suivant

Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum