Positionnement dans les trames de la fenêtre OSD du MAX7456

Raffou · Août 12, 2014, 3:13

Il a été évoqué ici et ici l’utilisation possible d’un circuit OSD MAX7456 pour manipuler à la volée le niveau des lignes 310 et 622 d’un signal vidéo 625 lignes standard.
Le but est de pouvoir imposer des niveaux déterminés (delui du noir ou du blanc ) sur les lignes 310/622 d’un signal vidéo en clair en amont d’un décodeur pour forcer ce dernier à se comporter comme s’il était en présence d’un signal embrouillé.
Un décodeur dont les retards 0 et 2 ont été permutés décryptera ce signal vidéo à l’inverse du décodeur qu’il était avant modification et la réciprocité fera que ce décodeur précédé du circuit OSD se comportera comme un encodeur.

L’opération consisterait à remplir toute la mémoire OSD du MAX7456 de caractères complétement transparents sauf la dernière ligne qui le serait par deux caractères particuliers presque entièrement transparents hormis une seule rangée de pixels, en principe la dernière, qui seraient soit noirs soit blancs.
La gageure étant de faire correspondre cette rangée de pixels avec les lignes 310/622 et que l’Arduino puisse en modifier dynamiquement le niveau blanc/noir à chaque nouvelle trame.

Ci-dessous, l’Illustration de ce principe basé sur un Arduino Uno équipé d’un shield OSD MAX7456 afin que le projet soit le plus « plug & play » possible :

Le shield OSD « VideoOverlayShield » de ce synoptique devrait permettre de réaliser un ensemble compact sans aucune soudure hormis les 3 ou 4 continuités nécessaires à la configuration souhaitée pour ce shield.
L’Arduino est nécessaire pour assurer :

L’initialisation à la mise sous tension de la mémoire OSD du MAX7456,
Le dialogue avec l’utilisateur : paramétrage du niveau de programme sur les lignes 622, reprogrammation du générateur de caractère…
Des tâches cycliques comme le comptage des impulsions de synchronisation ligne, le traitement des interruptions provoquées par la synchronisation trame, le rafraichissement de la dernière ligne de la mémoire OSD à chaque nouvelle trame…

Ci-dessous un « VideoOverlayShield » embroché sur un Arduino Uno, l’ensemble est inséré entre une source vidéo et un moniteur et leur alimentation est assurée par le bus USB connecté sur un PC. L’ensemble peut aussi être indépendant car l’Arduino possède un jack pour y connecter une source continue extérieure dont la tension est comprise entre 7 et 12 volts :

Toujours dans le même objectif d’une réalisation la plus « plug & play » possible, il existe une autre alternative avec la carte support « click shield » conçue pour y enficher 2 cartes filles de la collection « Click Boards » dont la carte OSD « OSD click » équipée d’un MAX7456 :

Selon son datasheet, le MAX7456 permet d’incruster 16 lignes de 30 caractères en mode 625 lignes. Le vocable PAL désigne ce dernier mode alors que le vocable NTSC désigne le mode 525 lignes.
Les caractères sont inscrits dans des blocs jointifs de 18 rangées de 12 pixels, la fenêtre de l’OSD a donc une hauteur de 18×16 lignes soit 288 lignes.
Selon la recommandation internationale UIT-R BT.1700, chaque trame comporte 287,5 lignes visibles, la fenêtre OSD déborderait donc d’une demi-ligne en hauteur.
On peut immédiatement en déduire que les caractères affichés auront une hauteur double de celle du générateur, soit 36 lignes, puisque les trames sont entrelacées.

Le signal vidéo standard tel qu’il est défini par la recommandation internationale UIT-R BT.1700 :

Synch.800.PNG.jpg

La vidéo visible véhiculée par la première trame ou trame paire débute sur la deuxième moitié de la ligne 23 et s’achève avec la ligne 310,
La vidéo visible véhiculée par la deuxième trame ou trame impaire débute avec la ligne 336 et s’achève sur la première moitié de la ligne 623.

La trame paire comporte donc ½ + 287 lignes visibles alors que la trame impaire en comporte 287 + ½.
L’affichage d’une image nécessite donc 576 lignes (2 fois 288 ) mais l’affichage réel équivaut à une image de 575 lignes (2 fois 287 + 2 demi lignes ).

Logiquement on devrait s’attendre à ce que le MAX7456 réalise l’incrustation des 288 lignes de la fenêtre OSD en se conformant au plus près de la recommandation précitée :

Trame paire : pour afficher 288 lignes au lieu des 287,5 lignes usuelles, la ligne 23 devra être complète au lieu de n’en utiliser que la seconde moitié. Cette fenêtre débuterait alors avec une ligne 23 complète et s’achèverait avec la ligne 310.
Trame impaire : La ligne 623 étant inutilisable car interrompue par une impulsion d’égalisation en son milieu, la ligne 622 devrait lui être alors substituée ce qui aurait pour conséquence de décaler la fenêtre OSD une ligne plus en avant. Cette fenêtre débuterait alors avec la ligne 335 au lieu de la ligne 336 et s’achèverait avec la ligne 622.

Mais ces suppositions, aussi logiques qu’elles soient, doivent être vérifiées car le datasheet du MAX7456 est absolument muet à ce sujet. Une divergence quelconque rendrait alors ce projet impossible.

Pour se faire la main avec l’Arduino et le MAX7456, quoi de mieux que de s’exercer avec la reprogrammation des caractères du MAX7456. Ceux prédéfinis à l’origine sont inexploitables, les emplacements du peu de caractères européens ne correspondent pas à leur code ASCII et la foultitude des autres représentent des idéogrammes extrême-orientaux dont l’intérêt est quasi nul.
Pas besoin de réinventer le fil à couper le beure, le net fourmille de sketches appropriés pour effectuer cette reprogrammation, il suffit de les importer dans l’Arduino et de les adapter à ses désidérata si nécessaire.
Afin que cette reprogrammation soit réutilisable avec profit pour d’autres projets, la table de caractères choisie est celle de l’ISO-8859-15 qui comporte tous les caractères européens y compris le sigle de l’euro :

La prise en main une fois effectuée, il est temps de se consacrer aux tests proprement dits :

La mémoire de l’OSD a été initialisée avec des caractères transparents (l’espace, code 0x20 ) sauf tous ceux de la première et de la dernière ligne qui l’ont été avec le caractère rub-out (code 0x7F ) dont la représentation est celle d’un bloc uniformément blanc.
Visuellement, il s’affiche donc deux bandes blanches épaisses sur toute la largeur de l’écran, la supérieure tout en haut et l’inférieure tout en bas de la fenêtre.

Le montage de test utilisé pour ausculter le MAX7456 :

C’est une plaquette minimOSD qui a été utilisé pour ce test, elle inclue le MAX7456 ainsi qu’une puce Arduino ATmega328P. Cependant il est nécessaire de lui adjoindre un « FTDI breakout board » comme celui-ci pour la connecter à l’IDE arduino du PC et par la même occasion alimenter l’ensemble via la connexion USB.
Cette option n’est pas vraiment « plug and play » car il a fallu sortir le fer à souder pour ajouter le connecteur ISP ainsi qu’une résistance de rappel au +5 volts sur le chip select du MAX7456. Il a été aussi nécessaire d’injecter le bootloader Arduino avec un programmateur ISP car la puce en étant dépourvue. Cela reste malgré tout l’option la plus économique.

Un détecteur de ligne blanche à base d’un sextuple inverseur 74HC14 a été connecté sur la sortiev idéo du MAX7456,
Les sorties synchro ligne et synchro trame du MAX7456 ainsi que celle du détecteur de ligne blanche ont été connectées sur un petit analyseur logique Scanalogic-2 de chez IKAlogic,
Aucune source vidéo extérieure n’est nécessaire, c’est le mode synchronisation interne du MAX7456 qui est utilisé pour le test. Une vérification ultérieure a permis de constater que le fonctionnement de l’OSD était le même lorsqu’il se synchronisait sur un signal vidéo extérieur.

Toutes les images des captures ont été réalisées après initialisation de la mémoire OSD comme décrit plus haut.
Chaque image regroupe 3 traces:* La trace supérieure bleue est celle de la synchronisation trame,

La trace centrale jaune est celle de la synchronisation ligne. Les impulsions d’égalisation ont été oblitérées par le MAX7456,
La trace inférieure rouge est celle du détecteur de niveau. Il devrait y avoir 18 paliers consécutifs au niveau haut de part et d’autre de la synchronisation trame. Ces paliers correspondent aux 18 lignes des bandes blanches épaisses programmées tout en haut et tout en bas d’écran. Chaque palier est constitué par la juxtaposition des pixels d’une même rangée des 30 pavés blancs dont chaque bande est constituée, aucun n’est crevassé puisque les pavés blancs sont tous jointifs.

Premier groupe d’images: cas standard sans aucun offset vertical.

Image supérieure:* fin de trame impaire : le 18ème palier du détecteur de niveau alias la dernière ligne de la fenêtre OSD correspond bien à la ligne 622 comme cela avait été présenti,

début de trame paire : le 1er palier du détecteur alias la première ligne de la fenêtre OSD correspond à la ligne 22, mauvaise augure pour la suite du projet, la fenêtre débuterait donc une ligne plus en avant que ce qui aurait été logique d’escompter.

Image inférieure:* fin de trame paire : le 18ème palier alias la dernière ligne de la fenêtre OSD correspond à la ligne 309, alors qu’il aurait fallu qu’elle se termine avec la ligne 310 comme on était logiquement en droit de l’espérer,

début de trace impaire : RAS, la fenêtre commence bien sur la ligne 335 comme cela avait été pressenti.

Avec un tel positionnement de la fenêtre OSD dans la trame paire aussi inattendu, car irrespectueux de la recommandation de l’UIT, la poursuite du projet devient problématique. Il ne reste plus qu’un mince espoir avec le registre d’offset du MAX7456 qui permet de déplacer la fenêtre dans la trame jusqu’à 16 lignes plus haut ou 15 lignes plus bas.

Second groupe d’images: Tentative d’inclure la ligne 310 avec un offset vertical de +1 ligne (registre VOS ):

Image supérieure:* fin de trame impaire : le 17ème palier du détecteur de niveau alias la pénultième ligne de la fenêtre OSD correspond à la ligne 622. La 18éme et dernière ligne de la fenêtre est oblitérée, ce qui est cohérent car la ligne 623 est crevassé en son milieu par une impulsion d’égalisation. La période de suppression trame du MAX7456 débuterait donc dés la ligne 623,

début de trame paire : la fenêtre OSD s’est déplacé d’une ligne vers le bas puisque la bande blanche commence maintenant à la ligne 23.

Image inférieure:* fin de trame paire : le 17ème palier alias la pénultième ligne de la fenêtre OSD correspond à la ligne 309, le 18ème et dernier palier est oblitéré et la ligne 310 reste désespérément vierge, le dernier espoir restant s’est évanoui ! La période de suppression trame du MAX7456 débute donc dés la ligne 310, une ligne beaucoup trop tôt !

début de trace impaire : la fenêtre OSD s’est déplacé d’une ligne vers le bas puisque la bande blanche commence maintenant à la ligne 336.

Affichage de la fenêtre OSD quand on lui inflige le décalage vertical maximal (+15 et -16 lignes)

Premier groupe d’images: avec offset vertical maximum de +15 lignes :

Il ne subsiste plus que 3 paliers, la bande blanche du bas est sévèrement amputée puisqu’il ne s’affiche plus que ses 3 premières lignes. Toutes les autres ont été englouties par la période de suppression trame qui s’établit définitivement pour le MAX7456 avec la ligne 310 pour la trame paire et avec la ligne 623 pour la trame impaire.
La bande blanche du haut est descendue 15 lignes plus bas, la fenêtre OSD s’ouvre maintenant avec les lignes 37 et 350.

Deuxième groupe d’images: avec offset vertical maximum de -16 lignes :

La bande blanche du bas est remontée 16 lignes plus haut, la fenêtre OSD se referme maintenant sur les lignes 293 et 606,
La bande blanche du haut s’est déplacée 16 lignes plus haut, la fenêtre OSD s’ouvre maintenant sur les lignes 6 et 319. Il n’est absolument pas garanti qu’un moniteur CRT puisse afficher les premières lignes de la fenêtre avec un tel offset qui frise la dernière impulsion d’égalisation.

Malheureusement cette idée d’utiliser qui semblait pertinente au départ a été mise à mal par la conception interne du MAX7456.
L’impulsion d’égalisation en plein milieu de la ligne 623 qui a imposé l’ouverture de la fenêtre OSD une ligne plutôt dans la trame impaire a dû aussi impacter la trame paire car la même circuiterie interne a dû être utilisée pour toutes les trames quelque soit leur parité sans que cette dernière puisse influencer quoi que ce soit.

jmespe · Août 12, 2014, 6:09

bonjour raffou
bravo pour le travail : vous avez essayé jusqu’au bout !

avez vous le schéma du circuit miniOSD ?

si c’est un arduino à la base vous pouvez essayer ma méthode

celle qui consiste à compter les top synchro
et à mettre à « un » une patte pendant 50µsec

certes, l’arduino n’est pas nativement « temps réel », mais avec un quartz de 16MHz ,
les instructions binaires sont traduites rapidement .
Reste à attendre 50µs (en assembleur, je fais des « nop »)

Au niveau matériel, il faudrait juste rajouter qques res, un condo et une diode (schottky) pour le clamp.
Le max servira juste d’extracteur de synchro

rien qui ne vous soit infaisable je pense

tenez nous au courant sur vos choix de ré-orientation pour votre projet

cordialement

PS eventuellement , je peux vous montrer mon ancienne réalisation : un inverseur vidéo PAL (avec tda2595 et pic 16f872)

Raffou · Août 12, 2014, 9:46

@jmespe

Voici le schéma de la plaquette minimOSD :

Les fichiers Eagle sont aussi téléchargeables ici.

Voici aussi le schéma de la plaquette « FTDI breakout board » sans laquelle la mise en œuvre de la plaquette minimOSD est impossible :

Les fichiers Eagle sont aussi téléchargeables ici.

Pour ma part, j’ai ajouté une résistance de rappel au +5 volts sur le chip select du MAX7456 pour éviter un conflit sur le bus SPI quand on programme la puce ATmega328P par le connecteur ICSP. J’ai récupéré une toute petite résistance CMS de 10 k? (probablement de la taille 0603 (0,8×1,6 mm)) sur une vieille carte soundblaster et je l’ai soudé non sans mal entre deux vias après avoir gratté le vernis épargne qui les recouvrait :

Voici une esquisse de ce que je compte faire pour incruster des lignes 310/622 dans un signal vidéo.

Utiliser un conditionneur MAX7450 ou un MAX7452 comme étage d’entrée :[list][*]le MAX 7450 nécessite une alimentation symétrique en ± 3,3 ou ±5 volts et le niveau du noir est fixé au 0 volt.
le MAX7452 nécessite une seule alimentation +5 volts et le niveau du noir est déterminé par l’utilisateur.
La régulation de l’amplitude du signal vidéo est souhaitable pour que le niveau du blanc soit stable et connu, ce qui évitera d’incruster des lignes blanches qui seraient plutôt grises ou surbrillantes.[/:m][]Utiliser un extracteur de synchronisation comme l’EL4583 plutôt que le sempiternel LM1881 car il délivre un signal de synchronisation horizontal exempt d’impulsion d’égalisation :* la sortie synchronisation trame sera connectée sur l’entrée interruption 0 ou 1 (INT0 ou INT1) de l’Arduino.
la sortie synchronisation ligne sera connectée sur l’entrée du timer/counter 1 (T1) car celui-ci compte sur 16 bits alors que les deux autres ne comptent que sur 8 bits.
[/:m][]Et enfin un multiplexeur/amplificateur du genre LT1204 ou MAX4311 pour ne citer que ses deux là :* La première entrée du multiplexeur sera reliée sur la sortie du conditionneur pour assurer la transparence,
la seconde au 0 volt pour le MAX7450 ou à la tension de référence du noir pour le MAX7452 afin de pouvoir incruster les lignes noires.
la troisième à la tension de référence du blanc afin de pouvoir incruster les lignes blanches.
la quatrième ne sera pas utilisée.
la sortie de l’amplificateur fournira directement le signal sortant.
l’Arduino adressera le multiplexeur pour imposer la transparence, le noir ou le blanc.
[/*:m][/list:u]
Le tout installé sur un shield prototype Arduino dans un premier temps. Et si jamais l’Arduino Uno n’était pas assez rapide, il existe l’Arduino Due et bientôt l’Arduino Zero qui vient d’être échantillonné, tous deux équipés de puces ARM 32 bits cadencée à 84 MHz pour le premier et à 48 MHz pour le second.

Domi-Niaque · Août 13, 2014, 6:57

Mine de renseignements ici:
http://wintzx.fr/blog/2014/01/codage-et-decodage-des-chaines-analogiques-en-1984-partie-1/

jmespe · Août 13, 2014, 7:34

bonjour,

sur le schéma du miniosd, le vsync n’est relié nulle part ???
auquel cas reliez le vous meme ! et dites nous sur quelle patte que l’on parle tous de la meme chose ensuite …

je connaissais le fdti c’est un convertisseur usb/rs232 pour les pc qui n’ont plus de port série
il est intégré aux vrai arduino je crois

je recupère moi aussi beaucoup de res cms sur des cartes électro de rebut …

vous nous dites ensuite :

conditionneur à max7450
quel est son intéret ??? juste clamper le noir? et au prix d’une alim négative ?
regardez plutot comment on clampe un signal vidéo dès l’entrée ici :
Inverseur video PAL 02.jpg

2 res en pont diviseur , un condo pour faire flotter le signal et une diode pour le clampage proprement dit.

Je ne connais pas le EL4583
mais je dirai que pour faire un essai au début, gardez pour l’instant le miniOSD : vous l’avez sous la main !

essayez juste de faire le programme qui compte les lignes et de mettre à « un » telle ou telle patte
que vous reliez au signal vidéo .
il s’agit de mettre une ligne blanche meme au milieu de l’écran pour VOIR si ça marche,
si les temps sont compatibles.
A mon sens, il vaut mieux avancer pas à pas que chercher un produit fini dont on a rien vu pour l’instant

cordialement

Mannix54 · Août 13, 2014, 9:37

si j’ai bien compris le but de ce projet c’est de forcer un décodeur canal+ discret11 à fonctionner comme un encodeur,

mais ne serait-il pas plus simple de modifier directement le décodeur afin d’intégrer un interrupteur permettant de sélectionner le mode désiré ? ( décodage / encodage )

BAISIN · Août 14, 2014, 7:12

Je constate que la démonstration a été faite sur les VBI d’ un signal vidéo 525 lignes( moniteur RCA, introuvable en Europe !) NTSC 3.58, ou PAL-M ou PAL-N

Raffou · Août 16, 2014, 7:55

Mal vu, car le Vsync du MAX7456 (en 17) est bien câblé sur la puce AT mega328P sur son port PD2 (en 32). Ce port correspond aussi à l’entrée de l’interruption zéro (INT0). Par contre le Hsync n’est pas connecté sur la puce ATmega :

En traits pleins : les connexion existantes.
En pointillés bleus : l’adjonction d’une résistance de rappel sur le « chip select » du MAX7456 pour éviter tout conflit sur le bus SPI lors d’une programmation par le connecteur ICSP.
En pointillés verts : la connexion projetée sur le port PD5 (T1) pour compter les impulsions ligne à l’aide du « timer/counter 1 » de l’ATmega.

Le conditionneur permet d’obtenir sur sa sortie une amplitude stable de 1 volt quelle que soit la tension d’entrée comprise dans une plage de ± 6dB, c’est à dire entre 0,5 volt et 2 volts.
Je me recite :

Le MAX7450 n’a pas forcément besoin d’une alimentation symétrique en ± 5 volts (ou ± 3,3 volts pour le MAX7451), on peut très bien l’alimenter en +10 volts et lui fournir une masse virtuelle avec un circuit « rail splitter » comme le TLE2426. Contrepartie, la masse virtuelle sera alors portée à une tension moitié de celle de l’alimentation, en l’occurrence +5 volts.
Le MAX7452 est conçu pour être alimenté avec une tension unique de +5 volts avec un niveau du noir fixé sur une référence de tension extérieure alors qu’il était aligné sur le 0 volt avec le MAX7450 et 7451. Le MAX7452 est donc bien le plus approprié des trois.

L’ébauche du schéma à base de MAX7452 et de MAX4314 :* Deux exigences à satisfaire :[list][*]Pour le MAX7452 : la référence pour le niveau du noir (BPLVL) doit être comprise entre 1,5 et 2,4 volts, le niveau correspondant en sortie est 1,5 fois plus faible. Le palier du noir, alias le niveau correspondant à incruster sera donc compris entre 1 et 1,6 volt.

Pour le MAX4314 : La tension sur l’entrée de son amplificateur ou plus exactement sur celles de son multiplexeur, ne doit pas excéder la moitié de celle de son alimentation, puisque son gain interne est de 2, sous peine de raboter par le haut le signal délivré sur sa sortie. La tension correspondante au niveau du blanc devra donc être inférieure à 2,5 volts.
Avec une amplitude du signal vidéo régulée à 1 volt, le niveau du blanc est 0,7 volt au dessus de celui du noir, ce qui peut s’écrire sous la forme de cette équation : V_blanc - V_noir = 0,7* Avec V_noir = V_BPLVL ÷ 1,5 l’équation devient V_blanc - (V_BPLVL ÷ 1,5) = 0,7.
Avec une référence commune aux deux, l’équation devient alors : V_ref - (V_ref ÷ 1,5) = 0,7.
d’où l’on déduit que V_ref = 2,1 volts,
ce qui implique que V_blanc = V_BPLVL = 2,1 volts et que V_noir = 1,4 volt.
Les deux exigences sont satisfaites puisque V_blanc < 2,5 volts et que 1,5 < V_BPLVL < 2,4 volt(s).
Un régulateur 2,1 volts LD6815TD/21 suffixe P ou H, suppléé par un pont diviseur résistif, délivrera les tensions de 2,1 et 1,4 volts sur les entrées respectives IN2 et IN3 du multiplexeur afin de réaliser l’incrustation à un niveau correct du noir et du blanc.

[/:m]
[]L’adressage du multiplexeur interne au MAX4314, ports de l’Arduino à définir :* Avec l’adresse A1, l’Arduino sélectionnera la transparence ou l’incrustation.

Avec l’adresse A0 l’Arduino sélectionnera le niveau à incruster, soit celui du noir, soit celui du blanc.
[/:m][]L’extracteur de synchronisation EL4583 pressenti à été remplacé par un EL1883 moins nécessiteux en composants périphériques.[/*:m][/list:u]

Le schéma proposé étant plutôt dessiné avec une désinvolture et un style qui ne facilite pas forcément sa compréhension immédiate, je me suis permis de le retoucher pour qu’il soit moins abscons :

Ce que je distingue au niveau de T1, ce n’est pas un clamp à proprement parler mais un alignement sur le fond des tops de synchronisation.
Par contre, il y a effectivement un clamping pour restituer le niveau du noir (¼ de CI2 + C5) et constituer une sorte de « tracking » fixant, sur l’émetteur de T5, le niveau du noir de la vidéo inversée par T6.

Oui dans le fond, on peut très bien faire l’impasse sur la ligne 310 en lui substituant la 309 qui la précède en clôturant la fenêtre OSD des trames paires. A une ligne vidéo près, le programme sera le même et cela permettra de valider le concept original à partir d’une carte MinimOSD.

Ma démarche était plutôt inverse, il vaut mieux détourner un produit de son utilisation initiale par modification de son logiciel, quitte à lui apporter des modifications matérielles mineures. C’est bien plus facile d’écrire et de mettre au point un petit bout de programme que de concevoir une carte spécialisé du début jusqu’à la fin.

Que vient faire ici cette réponse qui à priori n’a rien à voir avec le sujet ? N’y aurait-il pas eu confusion avec d’autres sujets pour lesquels vous êtes intervenu ?

jmespe · Août 17, 2014, 12:43

Bonjour raffou,

Autant pour moi, je voulais dire le « Hsync n’est relié nulle part » (et pas le Vsync)
et vous l’avez donc relié en patte 9 (pd5): ok

Je vois à votre schéma final que vous quittez le miniosd pour une vrai arduino.

Globalement , je ne vois pas de problème à ce schéma , reste à voir le programme.

Notre différence de philosophie se confirme :
vous prenez systématiquement un composant « spécialisé » pour chaque fonction
le régul LD6815 me semble superflu : dans votre pont diviseur, prenez simplement 3 res
et calculez le tout à partir du +5 (que vous avez !) pour avoir vos 2 tensions .

Mais au fait , pourquoi avoir le seuil du noir ?
Prévoyez-vous autre chose après ?

vous dites: "
Avec l’adresse A1, l’Arduino sélectionnera la transparence ou l’incrustation.
Avec l’adresse A0 l’Arduino sélectionnera le niveau à incruster, soit celui du noir, soit celui du blanc
"

hé bien moi, j’aurai commencé par juste mettre une res (ajustable) entre la cette patte A0 et le signal vidéo (après clampage)
Sauf si vous voulez le forçage au noir
quand au schéma que je vous propose : il est valable !
il clampe le bas du top synchro, oui , et alors ? cela clampe le noir à +0.3v
(meme s’il est vrai que moi, je mets plutot une diode bat42 au lieue d’une 1n4148)

bon ben, d’une façon ou de l’autre : ya plus qu’à !

tenez nous au courant

cordialement

marceljack · Août 17, 2014, 1:06

C’est LA spécialité de Baisin que de faire des remarques (le plus souvent déplacées) qui n’ont rien à voir avec le sujet. :mrgreen:
Au début, on a du mal mais on finit par s’habituer …

Raffou · Août 18, 2014, 1:09

Je ne pense pas que le remplacement de la diode de clamping par une diode schottky soit déterminante, je vous propose plutôt de remplacer cette diode par la jonction base/émetteur d’un transistor. Grâce à l’effet transistor, l’impédance de cette pseudo diode de clamping est encore plus faible que n’importe quelle autre type de diode quand elle entre en conduction pendant le fond du top de synchronisation.
Normalement il faudrait que le niveau du blanc de la vidéo directe corresponde au niveau du noir de la vidéo inversée, je doute que l’association D2/D3/DEL2 soit la plus appropriée pour obtenir cette correspondance. Le remplacement de cet empilage hétéroclite de diodes par un régulateur shunt ajustable comme le TL431 serait beaucoup plus pertinent pour parvenir à cet objectif compte tenu aussi de la disparité des caractéristiques des autres composants.

Par la même occasion, le condensateur C1 était polarisé en inverse sur le schéma d’origine…

Au temps pour moi !
Il y a controverse sur la graphie de cette expression, je vous invite à consulter ces liens : * || getexpi ||

Oui, et c’est vraiment dépité que j’ai dû renoncer à l’utilisation d’un MAX7456 car c’eût été LA SOLUTION si cette puce n’avait pas décalé la fenêtre OSD d’une ligne de trop vers le haut dans la trame paire.

Le régulateur LD6815 pourrait sembler superflu mais la tension qu’il délivre est précise à ± 2% contre 5% pour un régulateur 5 volts standard, ce qui plaide en sa faveur pour fournir une référence de tension précise d’autant plus qu’il permet de la découpler de la présence potentielle de perturbations sur un rail +5 volts commun à tous les circuits.
Plus on avance dans ce fil de discussion plus j’ai le sentiment que votre horloge n’avance pas au même rythme que la mienne, vous me proposez un schéma certes éprouvé mais qui date quand même de 20 ans… N’est-il pas plus gratifiant de prendre le risque de proposer un schéma innovant plutôt que d’adapter un existant ?

Ca me semblait pourtant trivial, l’objectif de ce projet est de remplacer à la volée les lignes 310/622 d’un signal vidéo par des lignes blanches ou noires et non pas par des lignes à un niveau quelconque ou intermédiaire.

Si seulement n’y avait qu’un interrupteur à installer pour croiser deux retards !
Avez vous ne serait ce qu’une petite idée de ce que cela implique même à minima, je dis bien à minima :1. Remplacer le microcontrôleur existant par un de la même famille, donc compatible broche à broche, un 8749 à fenêtre EPROM ou un NS87P50 avec EPROM en piggyback, après avoir passé un certain temps à développer le logiciel approprié sur un système de développement que l’on ne peut plus trouver que sur eBay qu’à de très rares occasions.
C’est aussi sans compter sur la rareté des microcontrôleurs précités car devenus vintage et objets de collection.

Greffer quelques composants pour pouvoir incruster les lignes 310/622 à un niveau correct. Tout cela à partir d’un schéma tel que celui publié sur ce forum dans autre sujet et dont la netteté est problématique.

Autant réaliser un incrusteur externe en partant de sous-ensembles existants !

jmespe · Août 18, 2014, 6:48

bonsoir raffou

-concernant le schéma du haut parleur :
mmmmm… je dirai non pour le transistor : plus la ligne est blanche, plus il va devenir passant.
il va donc clamper aussi en fonction du niveau du blanc : le contre-sens du clampage !

la diode schottky ayant un seuil de 0.2 garantie de ce fait sa conduction meme en cas d’image très sombre (dans le pire des cas seulement la synchro)
une silicium pose problème dans ce cas (très peu en pratique)

ce type de clampage est vieux de 20ans … tout comme le décodeur original
qui , si j’en crois le schéma qui m’a été donné sur ce forum, utilise exactement le meme (av 1n4148)!

"l’association D2/D3/DEL2 " …"empilage hétéroclite "
ha je vois où est le problème :
vous croyez que le niveau de la ligne blanche doit être ultra précis
(d’où votre LD à 2% au lieu de 5% !)
Je ne peux pas vous le garantir à 100% (je n’ai pas de déco !)
mais son schéma d’origine (officiel) ne fait appel que à des transistors.
de plus, mettez vous à la place du concepteur :
exigeriez-vous un signal blanc entre 99 et 100% pour une transmission terrestre ?
qu’arrivera t il alors au moindre problème de reception ?

c’est la raison pour laquelle ni le clamp, ni le niveau de blanc n’ont à être aussi précis

idem pour le découplage du LDxxx
il est tout à votre honneur de ne pas ramener les parasites du +5V,mais
un pont diviseur à 3 res peut être découplé en mettant un condo sur la première sortie
en fait , dans votre schéma, le LDxxx peut être remplacé brutalement par une resistance !
la précision sera alors celle du 78l05 (certes ±5%)
notre différence de philosophie se re-confirme
je vous précise que j’ai 41ans !

"N’est-il pas plus gratifiant de prendre le risque de proposer un schéma innovant "…
hé bien devinez quoi ? JE ne trouve pas !
je pense qu’il vaut mieux s’adapter au projet : c’est à dire forcer une ligne pour allumer le décodeur
pour moi, vos solutions posent des problèmes de cout et d’appro.

Mais encore une fois, c’est vous qui payez et qui faites !

"par des lignes blanches ou noires et non pas par des lignes à un niveau quelconque "
en HAUT de l’image (premières lignes)il est préférable de forcer les lignes au noir (télétexte …)
mais je n’ai jamais rien vu en bas !
cordialement

Raffou · Août 18, 2014, 11:01

Je pense que vous n’avez pas vraiment assimilé le fonctionnement de ce mode d’alignement.
Il y a quelques années j’avais mis la main sur un document expliquant pourquoi un composant présentant la plus faible impédance possible en conduction était préférable pour réaliser cet alignement. Malheureusement je ne l’ai pas conservé et je n’arrive pas non plus à le retrouver sur le net, sinon je vous l’aurais bien volontiers retransmis ou indiqué le lien pour le récupérer.

Quelle que soit la diode, sa conduction est toujours assurée, car déjà sans aucun signal vidéo, elle est parcourue par le faible courant soutiré par la base du transistor suiveur.

Le principe est bien plus vieux que cela !
L’amplificateur vidéo d’entrée ainsi que l’amplificateur de sortie sont effectivement alignés sur le fond du top de synchronisation car cela suffisait. Par contre le détecteur de lignes blanches, lui, est bien clampé sur le niveau du noir à l’aide d’un switch analogique CMOS 4066 pour fiabiliser son fonctionnement.

Dois je vous rappeler que le SECAM utilisé à l’époque exigeait un récepteur avec une CAG efficace pour maintenir le niveau de la luminance (retransmise en AM, donc affectée par l’amplitude du signal reçu), en adéquation avec la chrominance issue de démodulateurs FM (donc quasi indépendante de l’amplitude du signal reçu) sous peine d’altérer sévèrement les couleurs.
On était donc assuré d’avoir une amplitude de signal stable en sortie de récepteur quelque soit la propagation dans des conditions normales de réception.

Toutes mes condoléances pour être autant aussi allergique à l’innovation.

MAX7452ESA, 3,81€ TTC disponible aussi sur AliExpress
MAX4314EEE, 12,77€ TTC, MAX4314ESD sur AliExprex plus facile à souder que le boîtier EEE
EL1883ISZ, 3,64 € TTC, disponible aussi sur AliExpress
LD6815TD/21P, 0,146€ HT

Les frais de port sont gratuit chez RS particuliers si la commande est passée le week-end. Quant à AliExpress, il suffit de choisir le bon vendeur et d’être prêt à attendre au moins 15 jours !

Où diable avez vous vu écrit qu’il était question d’incruster d’autres lignes que la 310 et la 622 ?

Mannix54 · Août 19, 2014, 1:38

j’avoue que je ne suis pas doué en électronique, je suis plutôt dans le logiciel ( développeur informatique ) que dans le matériel,

d’où mon réflexe de penser à hacker le système pour neutraliser le problème, une bidouille de type on change un ou deux bits dans le programme de la rom pour qu’il se comporte différemment ( on fait sauter la boucle conditionnelle qui vérifie la présence des 2 lignes blanches, comme ça il tentera de décoder quoiqu’il arrive ), j’avais résolu de cette manière une limitation mesquine de mon vieil appareil photo numérique ( limitation à 30 secondes de toute vidéo filmée par l’appareil ) en flashant le firmware par une version patchée,

mais visiblement c’est pas adapté à ce décodeur canal+, la rareté des composants que tu as cité,

donc tu peux continuer ton projet, pas de souci, j’ai hâte de voir le résultat final

Raffou · Septembre 3, 2014, 3:18

Bien que la plaquette MinimOSD soit inexploitable pour incruster les lignes blanches ou noires d’un signal Discret 11 puisque les lignes 310 sont hors de la fenêtre OSD, il est quand même possible de simuler le fonctionnement de cet inserteur en leur substituant les lignes 309 qui elles sont bien incluses dans cette fenêtre.

Une nouvelle modification doit être apportée sur cette plaquette pour pouvoir compter les impulsions de synchronisation ligne :

En bleu, la liaison à réaliser entre la sortie HSYNC du MAX7456 (patte 18) et l’entrée T1 de l’ATmega328P (patte 9) pour que ces impulsions puissent être comptabilisées par le Counter/Timer 1 du µC.
Le logiciel de test a été scindé sur 5 onglets dans la fenêtre de l’IDE Arduino. A noter que c’est la version « enhanced » de la release 1.0.5 de l’IDE Arduino qui a été utilisée, elle est téléchargeable ici.

Le premier onglet « Test » correspond au programme principal (fichier Test.ino).
Le second onglet « Hardware.h » correspond au fichier du même nom. C’est un fichier de définitions spécifiques à 3 modèles de cartes OSD précitées, les définitions des cartes autres que celle utilisée (MinimOSD) sont traitées comme des commentaires.
Le troisième onglet « MAX7456.h » correspond au fichier du même nom. C’est un fichier de définitions des registres et des commandes propres au MAX7456.
Le quatrième onglet « MAX7456 » correspond au fichier « MAX7456.ino ». Il inclut toutes les routines nécessaires à la gestion du MAX7456 : initialisation, lecture/écriture de caractères individuels ou de lignes de 30…
La présence du cinquième et dernier onglet « enum.h » est due à une limitation du compilateur, une énumération ne pouvant être définie que dans un fichier inclus.
Le répertoire « Test » incluant ces 5 fichiers est téléchargeable ici (fichier Test.rar).
Une fois décompressé, ce répertoire « Test » doit être installé dans le répertoire « sketchbook » de l’IDE, voir les préférences (Fichier/Préférences) pour obtenir l’emplacement exact de ce dernier.
Pour accéder aux 4 onglets du programme : Fichier/Carnet de croquis/sketchbook/Test.

Le programme principal :

Il fait appel à la bibliothèque SPI standard livrée avec l’IDE Arduino pour dialoguer avec le MAX7456 ainsi qu’au moniteur série intégré pour communiquer avec l’utilisateur.
La procédure « setup » initialise le port série virtuel, le bus SPI, le MAX7456 mémoire OSD comprise, le timer/compteur 1 et pour finir le vecteur de l’interruption trame.
La procédure « loop » se limite à ausculter la liaison série virtuelle et à modifier le niveau d’audience en fonction du chiffre frappé par l’utilisateur.
La routine d’interruption, appelée par le front descendant de l’impulsion de synchronisation trame :[list][*]Récupère d’entrée le nombre de lignes compté par le timer/compteur 1 et le remet aussitôt à zéro.
Tente de déterminer la parité de la trame en fonction du nombre de lignes comptées (312 ou 313) et incrémente son numéro s’il y a lieu.
En fonction du numéro de trame, ce sera soit un bit du motif de la séquence Discret 11 (lignes 310) soit un bit du niveau d’audience (lignes 622) qui devra être inséré.
L’état du bit inséré dans la trame précédente est comparé avec celui à insérer dans la trame courante. En fonction du résultat, la 16ème et dernière ligne de 30 caractères de la fenêtre OSD :[list][*]Doit être rafraîchie avec le caractère correspondant au nouveau niveau logique à insérer s’ils sont différents.
N’a pas besoin d’être rafraîchie puisque l’état à insérer est identique à celui de la trame précédente.
Selon le principe énoncé ici, cette 16ème ligne doit être remplie de caractères spécifiques dont :* Les 17 premières rangées de pixels sont tous transparents.
La 18ème ou dernière rangée comporte soit des pixels noirs représentant l’état zéro soit des pixels blancs représentant l’état un.
En fait un seul caractère est nécessaire. Celui-ci ayant été en principe défini avec une 18ème rangée aux pixels tous blancs, il suffira de rafraîchir la ligne, c’est à dire la réécrire, après avoir positionné le bit INV du registre DMM pour que tous ses pixels blancs soient inversés en pixels noirs.[/:m][/list:u][/:m][]Et enfin le numéro de trame est forcé à zéro si la dernière trame traitée était la sixième de la séquence Discret 11.[/:m][/list:u]
Et enfin le test en réel:
La mémoire OSD a été initialisée avec des caractères transparents sauf :[list][*]Une bande supérieure correspondant à la première ligne de la fenêtre OSD qui l’a été avec le caractère 0x5F (le sous-tiret / underscore). Cette bande mince permet de mieux se repérer à l’intérieur des traces générées par l’analyseur logique.
Une bande inférieure correspondant à la dernière ligne de caractères de la fenêtre OSD. Pour plus de visibilité sur les traces, les 17 premières lignes du caractère spécifique ne seront plus transparentes mais opaques identiquement à la 18ème. Le caractère spécifique sera donc le caractère 0x7F (del / rub-out) défini comme étant un pavé de 18×12 pixels uniformément blanc.
Le positionnement du bit bit INV du registre DMM à 0 ou à 1, juste avant de rafraichir la dernière ligne en réécrivant ce même caractère, permettra respectivement de blanchir ou de de noircir la bande en agissant sur les tous les pixels qui la constitue.
[/:m][]Le résultat du test devrait être sensiblement le même quelque soit le mode de synchronisation du MAX7456. Donc autant utiliser le mode interne pour éviter de lui connecter une source vidéo externe.[/:m][]Un port (PD3) est utilisé comme indicateur pour l’analyseur logique. Son choix est dû au fait qu’il est relié à un pont de soudure de configuration inutilisé et libellé « SJ1 », ce qui facilite la soudure d’un fil pour le connecter à la dernière sonde de l’analyseur.
Cet indicateur positionné en début et en fin de la routine d’interruption trame va permettre de mesurer le temps de réponse et d’exécution de celle-ci dans les différents cas de figure :[/*:m][/list:u]

Dans l’ordre des captures d’écran:
• Début de trame paire:

Sans rafraichissement de la dernière ligne de caractères de la fenêtre OSD:

[*]Temps de prise en compte: ≈8,7µs.

Durée totale: ≈31,2µs (inférieure à ½ ligne).
[/*:m]
Avec rafraichissement des caractères de la dernière ligne:

[*]Temps de prise en compte: ≈8,7µs.

Durée totale: ≈150,9µs (inférieure aux 160 µs de l’impulsion trame).
[/*:m]
• Début de trame impaire:
Sans rafraichissement des caractères:

[*]Temps de prise en compte: ≈8,7µs.

Durée totale: ≈31,7µs (légèrement inférieur à ½ ligne).
[/*:m]
Avec rafraichissement:

[*]Temps de prise en compte: ≈8,7µs

Durée totale: ≈152,7µs (toujours inférieure aux 160 µs de l’impulsion trame).
[/*:m]
Conclusions :
Il n’y a même pas besoin « d’overclocker » la puce ATmega328P avec un quartz de 20 MHz ni de tenter de diminuer le temps de réponse aux interruptions.
Il est même possible de ralentir l’horloge du bus SPI. A 8 MHz (la valeur maximum) la durée de rafraîchissement de la dernière ligne est inférieure à celle de l’impulsion trame. La fréquence d’horloge pourrait dans ce cas être abaissée jusqu’à ce que la durée de l’interruption avoisine celle de la suppression trame.

La fenêtre du moniteur série, le petit menu succinct permet de modifier à la volée le niveau de programme (ou d’audience) transporté par les lignes 622 :

Un cycle de 6 trames au complet, niveau de programme/d’audience à 1 :

Cycles.2400.png
Les fines barres verticales rouges ne sont pas significatives. Elles correspondent à la bande supérieure mince et servent surtout à délimiter visuellement la fin de la période de suppression trame.
Seuls les pavés rouges sont porteurs d’informations :

Intervalle M0/M1 : 1ère trame du cycle, paire.
Le pavé rouge représente le 1 du motif « 100 » du Discret 11.
Intervalle M1/M2 : 2ème trame, impaire.
Le pavé rouge représente le bit 2^0 du niveau de programme/d’audience qui est à 1.
Intervalle M2/M3 : 3ème trame, paire.
Pas de pavé rouge donc 1er zéro du motif « 100 ».
Intervalle M3/M4 : 4ème trame, impaire.
Pas de pavé rouge, donc bit 2^1 du niveau de programme/d’audience à zéro.
Intervalle M4/M5 : 5ème trame, paire.
Pas de pavé rouge donc 2ème et dernier zéro du motif « 100 ».
Intervalle M5/M6 : 6ème et dernière trame du cycle, impaire.
Pas de pavé rouge, donc bit 2^2 du niveau de programme/d’audience à zéro.

dreambox59 · Octobre 20, 2014, 7:25

raffou
je reveille momentanement ce post !
je vois que tu apprecie (comme moi) scanalogic
-1 comment fait tu pour numeroter les lignes sur la synchro ligne , a tu creer un script decodeur pour ça ?
je voudrais que tu me confirme une des bases de nos reflexions :
-2 la trame dite « paire » est celle qui commence par la ligne 1 (comme l encart plus haut) ou celle qui commence par la ligne 314 ?
-3 dans la periode du top de synchro trame qui ouvre la « 1ere » trame est ce que tu compte 2 ou 3 top de synchro lignes (en sortie d un pll ou extracteur de synchro) ??
-4 dans le contexte D11 d12 est ce qu on numerote les trames en disant : trames paires = 0 2 4 6 /impaires = 1 3 5 7 et du coup on dit que le d11 travaille sur les trames 1 2 3 4 5 6 (sachant que la 6 est aussi la 0) la 1 etant une trame impaire qui commence a la ligne 314.

Raffou · Octobre 20, 2014, 1:59

Oui j’ai acheté un des tous premiers Scanalogic dés qu’il a été mis en vente sur eBay. J’ai même été à l’époque en relation avec son concepteur Ibrahim Kamal car à l’origine le soft du µC de la sonde n’était pas assez rapide. Il avait été écrit en C plutôt qu’en assembleur, Y. Kamal avait dû le réécrire pour que la sonde fonctionne correctement pour les vitesses d’échantillonnage les plus rapides.

Pour la numérotation des lignes, pas de mystère, j’ai inséré manuellement avec paint ces n° dans les images capturées, ce qui m’a pris un certain temps…

J’ai plutôt cafouillé sur la parité des trames car j’avais lu tout et son contraire sur le net, et pour ajouter à la confusion, la recommandation normalisatrice UIT-R BT.1700 n’évoque jamais la parité des trames.
Par définition, la trame paire comporterait donc les n° de ligne paire de l’image affichée et réciproquement. La 1ère ligne de l’image ou ligne 1 commençant avec la demi-ligne 23 de la 1ère trame, cette trame est donc qualifiée d’impaire.

Par principe les fronts descendants/montants de l’impulsion de synchronisation trame sont synchrones avec les fronts descendants de l’impulsion de synchronisation ligne. Si on échantillonne l’impulsion trame sur les fronts montants de l’impulsion ligne pour éviter les tangences, on compte 3 échantillons (trait mince en rouge) dans un cas et 2 (trait mince plein en bleu) dans l’autre.

Ci-dessous le bout de code de l’incrusteur n°1 utilisé pour déterminer la parité des trames .

Il fait partie intégrante de la routine d’interruption appelée sur chaque front descendant de l’impulsion de synchronisation trame,
Le compteur TCNT1 du µC Arduino est incrémenté sur les fronts montants de l’impulsion de synchronisation trame ligne. Une fois lu en tout début de la routine, il est resetté dans la foulée.

Bizarrement, selon les fichiers code/source publiés, le D11 et le D12 ne comptent pas les trames, ils les décomptent de 6 à 0 et/ou de 12 à 0, le n° 0 étant un n° transitoire qui permet de recharger le compteur à rebours avec sa valeur maximale de 6 ou 12.

OSD.PNG.jpg