Cryptage "maison"

et j’ai enfin … enfin … enfin pu lire le 4014
ce simple circuit présente cependant une particularité ou 2

  • il faut activer la patte Parrallèle / Série comme il se doit
  • il faut un front d’horloge PENDANT l’activation du Parralèle / Série !!

suffit de la savoir ! :confused:
4014.jpg

Bon, je vais donc commencer à mettre un code dans mon programme …

à suivre …

C’était déjà le cas des premiers mini-ordinateurs des années 60, par exemple la série des PDP-8 de DEC (Digital Equipment Corporation).
Ces ordinateurs utilisaient des interrupteurs entre autres pour initialiser les registres et ils étaient regroupés par 3 car ces machines travaillaient en base 8 (code octal).
C’est sur un PDP-8/S (sorti en 1966) que j’ai fait mes premières armes à l’INSA de Lyon …

(origine de l’image: dustyoldcomputers.com)

Cette machine était connectée à un terminal Teletype (ASR-33) qui servait à rentrer les programmes sur un lecteur de bande perforée et sortait les résultats sur l’imprimante du Teletype).

mmm que voulez-vous dire par :
« ils étaient regroupés par 3 car ces machines travaillaient en base 8 (code octal). » ??

ceci dit, j’ai appris à programmer sur un 6809 en tapant sur un clavier hexa avec des afficheur 7 segments …

et enfin, je ne vous ai pas encore montré mon clavier :
Photo0982.jpg

le schéma est celui du message plus haut .
Je peux lire le code , il s’affiche sur l’écran .
Mais hélas, je n’ai pas encore réussi à faire correspondre les codes …
il semble qu’il y ait un problème dans mon programme
seule la première trame est bien décodée (si le bon code est là :smiley: )

je vais aussi m’acheter un second 4014 et un second dip switch pour un code à 16 bits
ils sont très facilement chainables …

à suivre donc …

haaaaaaa !! ça maaaarche !

j’ai trouvé où était mon erreur dans le prog et hop, ça a marché tout de suite !

voici donc le cryptage AVEC code (8 bits)
la vidéo est en lien plus bas, voici ce qu’elle montre :
Video1113-1937(avec code 8 bits).jpg

une image décryptée seulement si le code est bon ;
pour l’instant, il est fixé dans le crypteur à : 0000 0011 (c’est à dire 3 en décimal)
j’ai affiché en bas de l’écran 4 octets (séparés par des tirets verticaux que j’ai repéré en jaune);
celui de gauche est le code .(les octets suivants sont 10101010 ; ? ; et à droite un compteur de trame)
vous voyez que l’image est correcte seulement s’il est égal à 00000011

voici donc la vidéo

dl.free.fr/hXmZvH5ZF

vous voyez quand je manipule les inter dip switch , que l’affichage change de suite (il est lu à chaque trame)
mais que le code , lui, ne se synchronise que toutes les 24 trames (le bit X à un sur la première ligne)

vraiment pas mal tout ça, bravo,

si vous voulez vous attaquer à un autre projet de décodeur : il y a le projet intéressant de reconstituer à l’identique le décodeur « radio-plans » pour le discret11, qui était le tout premier décodeur pirate à avoir vu le jour en France, un forumeur était bien parti pour le faire mais il ne poste plus et il a peut-être abandonné le projet,

des scans de l’article de radio-plan détaillant le montage ont été posté sur le sujet « décodeur canal+ 1984 »,

le but du projet est de numériser la sortie vidéo du décodeur ( ou de filmer l’écran avec un caméscope numérique ), afin de se rendre compte du rendu visuel que ce décodeur pirate pouvait donner à l’époque, on sait que l’image était médiocre, mais il n’existe aucune photo, aucun enregistrement VHS permettant d’évaluer la qualité de l’image,

avec les vidéos discret11 générées par cryptimage il y aurait moyen de tester ce décodeur pirate, et même de le mettre KO si on coche la case « masquer la bordure » au moment de crypter le fichier vidéo :mrgreen:

hé oui, mais le problème sera toujours le même : quid des lignes à retard ?

personnellement, j’ai un déco à 68705 avec les 4 cubes verts
je peux les récupérer, et, soit faire de celui de RP (euh si vous voulez m’envoyez les schémas, je suis un peu fainéant de parcourir les dizaines de pages dudit sujet ),
soit en faire un avec pic (qui serait compatible avec la norme, donc av cryptimage)

mais le problème est toujours le même : qui a des cubes verts aujourd’hui ?

Bon, ce soir, j’ai reçu mon deuxième 4014 (avec son dip switch)
je passe au code à 16 bits; photos et vidéo …bientôt

j’en profite pour rappeler que mon cryptage (Navragon) , s’il n’a pas le vécu historique du discret11,
est quand à lui 100% reproductible , et même assez simplement !

je vous ai envoyé le lien pour télécharger l’article radio-plan ( un fichier zip contenant plusieurs fichiers pdf ),

apparemment dans le plan il y a des TDA 4560 et des TBA 970 ( pas de « cubes verts » ), on peut les trouver sur ebay :
ebay.fr/itm/TDA4560-COLOR-TR … dLQW8xce0A
ebay.fr/itm/TBA970-TBA970-TE … SwFNZWt21Z

wintzx.fr/blog/2014/02/codage-et … -partie-2/

bonsoir,
ça y est, le code fait maintenant 16 bits

voici le clavier :
Mais , j’ai fait un peu trop simple:
le code 1 est un décalage de la table, : un seul bit faux et toute l’image est cryptée
le code 2 est un ou exclusif avec la valeur (pseudo aléatoire) fournie par la table

mais c’est trop facile : si le code 1 est bon, le cryptage devient fixe et le code 2 se cherche bit à bit

il faut que je trouve comment combiner 2 octets (code1 et code 2) vers une seule table de 256 octets …
NOTA BENE : ça y est aussi, ça recommence, je ne peux plus faire « insérer dans le message » pour la photo
ça plante : page blanche avec le message :
ben regardez l’image « presse papier1.jpg » qui ne s’affiche même pas ???..
Presse Papier1.jpg
Photo0984.jpg

bonsoir à tous !

j’ai enfin eu un peu de temps à moi (je suis noyé sous l’électroménager en panne , l’ordi d’un collègue, le truc d’un copain)

bref, j’ai fait qques modif sur navragon, rien de fondamental …

je tatoue la ligne sur 7 bits et non plus 5 (je pense de plus en plus à transmettre un message)
navragon-code 16 bits-tatouage 7 bits.jpg
la ligne est dorénavant dupliquée en ligne 20 (invisible) , je peux transmettre des vidéos sans me préoccuper de la ligne noire du début)
j’ai corrigé quelques bugs
j’ai changé la table de cryptage (il n’y a plus de valeurs comme 10101010 , mais uniquement des bits
qui se suivent au minimum par trois ) cela réduit un peu le léger effet papillotement

j’ai mis à jour la page de mon site :
jmespe.free.fr/electro/realisati … index.html

et j’espère retourner au discret 11 sur pic pendant les vacances de Noël !!!

Bonjour,
Je prends connaissance de ce post à l’instant. Du beau boulot en vérité, félicitations !

@jmespe : dans votre message du Lun 14 Nov 2016 20h42

Je crois que dans mon fourbi, je dois avoir quelques uns de ces petits cubes verts, si cela vous intéresse n’hésitez pas à me demander je vous les ferai parvenir sans problème; ce sera trop tard pour Noël, mais pour le 1er de l’an, pourquoi pas ? :slight_smile:

En attendant bonnes fêtes à tous

JL²P

bonjour, merci du compliment

pour les cubes verts, j’ai commencé un déco discret11 à base de pic16f872
et de 4 cubes verts
je suis un peu planté pour l’instant à cause du manque de temps et de la complexité de la chose

De ce que j’en ai vu, les cubes verts ont l’air « limite » en bande passante
pour une vidéo PAL (la seule possible aujourd’hui)
En sécam, ça allait mieux (je n’ai pas de souvenir d’image médiocre, mais plutôt passable)

il faudra donc voir à faire des lignes à retard « à la main » (cellules LC multiples)

Pour navragon (que je maitrise mieux !) j’avance doucement : j’ai de plus en plus l’intention d’ajouter un OSD .
En effet, après l’abandon (sniff) des mes magnéto video8 gv-200 , je me retrouve avec des circuits OSD type D6451 (µPD6451 de NEC)
mais je n’ai plus une patte de dispo, il faut que je passe à un pic à 28 pattes

Tout cela est en cours pour cette semaine de vacances …

à suivre donc …

c’est en effet complexe, mais ce projet est intéressant, je suis ça avec intérêt,

il est un peu concurrent du projet « clone à 100% de l’original » du sujet « décodeur canal+ 1984 » de Raffou, mais de ce que j’ai compris vous allez utiliser des composants différents de l’original,

je me demande aussi si vous pouvez faire un objet « 2 en 1 », c’est à dire un boîtier qui fait à la fois « décodeur » et « codeur », c’est peut-être jouable s’il y a de la place dans le pic16f872 pour stocker le code nécessaire à la fonction « décodage », et celui pour la fonction « codage », un interrupteur en façade permettant de basculer d’un mode à l’autre

bonjour mannix
pour l’instant le projet est un peu planté : je suis encore débordé par l’électro-manager de ici ou là (grrr)

il faut que je m’y remette (j’essaie aussi un OSD pour navragon qui sera le upd6450)

Pour le déco discret11, je prévois plutôt un décodeur seul
2 raisons à cela :
1- votre programme fait un excellent codeur
2- le passage à travers les LAR n’est pas anodin en analogique ,
votre programme de dégrade pas l’image ,
mais un codeur analogique + un déco analogique, cela va faire beaucoup pour le pal (en tout cas, surtout pas avec les cubes verts)

et vous meme, pensez vous toujours à des plug-in pour cryptimage ??

Bonjour jmespe,

je suis débordé aussi par d’autres choses, mais j’espère avoir le temps en 2017 pour « pluginiser » cryptimage, et ensuite créer un plugin « discret12 »

bonsoir à tous,

Mon crypteur est à base de ne592 (schéma issu du cadinot) et me donnait satisfaction
Mon décrypteur est à base de transistor sur lequel il ne reste qu’un très léger papillotement
j’ai donc décidé ces vacances de refaire un décodeur à 16f876 (plus de pattes pour commander l’osd à upd6450)
et , tant qu’à faire, avec le meme schéma à ne592

Et là , je me suis rendu compte que le montage à ne592 a un problème …
Le ne592 a une res ajustable entre 2 et 7 (–gain « 1 » dans le datasheet-- )

mais ce réglage pose problème: il fini par « avaler » les top synchro !!

si je monte le gain , les top disparaissent…
si je le descend, ils ré-apparaissent et ensuite on voit que l’amplitude diminue pour l’ensemble,
mais on est alors << 1V pour le signal vidéo

L’équilibre est autour de 0.8V càc pour la vidéo

le crypteur seul a ce défaut, donc je travaillais jusqu’à présent à 0.8 V
le décrypteur à transistor s’en accommodait,
mais, avec le décrypteur à ne592 enchainé, on tombe à 0.6 V , ce n’est plus acceptable et l’image décroche
En fait, j’ai augmenté l’effet papillotement !!!

Je suis donc preneur de conseils sur le ne592, particulièrement si vous avez des SM de récepteurs satellite des années 90

Je suis aussi preneur de conseils et d’explications sur ce genre d’ampli à transistor :
ampli vidéo transistor issu de amstrad srd540.jpg

quel est son gain théorique ?

Bon, ceci dit, j’ai eu mes premières inscriptions en OSD sur l’image décodée !!!
Photo1006.jpg
Photo1007.jpg

Bonjour et meilleurs vœux à tous pour l’année 2017.

Je pense que tous vos déboires au sujet du NE592 proviennent de la polarisation de ses entrées, vous êtes trop proche des limites de son domaine de fonctionnement et il sature et écrête dés que les signaux vidéo excèdent une certaine amplitude.
Difficile de vous conseiller sans avoir votre schéma sous les yeux, cependant vous devriez vous rapprocher du schéma éprouvé de H. Cadinot en envisageant une alimentation symétrique du NE592.
L’alimentation négative nécessaire pourrait être simplement produite à partir de la positive existante grâce à un convertisseur du genre ICL7660, LMC7660 ou MAX1044 disponible chez la plupart des vendeurs VPC.

Ce gain à vide, sortie non chargée, dans la bande passante du filtre passe-bas (R173, C105, L14 et C106) en faisant abstraction de sa perte d’insertion, est très proche de ce rapport de valeurs de résistances : (R121 + R123) / R123 soit en l’occurrence un gain théorique de 2.
Sortie chargée sur 75?, le gain global devient unitaire à cause de la chute de tension dans la résistance R04.

bonsoir, je poursuis mon chemin
et après maints essais , j’ai trouvé qques défauts majeurs

1- le défaut de papillotage est largement visible sur une mire de barre: l’escalier est tronqué .
L’information ainsi perdue l’est définitivement ; quand on re-inverse: le papillotement est toujours là

Le problème, c’est le NE592 qui sature (sur sa sortie négative que je n’utilise pas !!!)
La solution , c’est une polarisation correcte des entrées
Sur tous les schémas que j’ai vu , le ne592 en vidéo est polarisé à Vcc/2 (il est toujours alimenté en 0/+12V)
j’ai vu un schéma sur lequel il est polarisé avec une diode zener de 6.2V

j’ai donc revu mon clamp à la hausse : 5V , car le premier transistor chute de 0.6
on est donc à 4.5 pour un ne592 alimenté en +9

2- j’avais un peu hâtivement commandé les portes du 4066 par le pic
Dans ma tete un mos se commande en Vcc/2
Erreur !!!
les portes analogiques (4053 , 4066) précisent un seuil bien plus élevé
sur le datasheet , en alim 10V (je suis en 9V) doit être commandé en mini 7 V !!!
Mes inter analogiques étaient donc « à moitié » fermés …
j’ai donc mis des transistors en commutation pour translater le signal de commande

3- à ce niveau de clamp, le pic ne peut plus tatouer directement la vidéo : ça décrochait
j’ai donc utilisé un petit montage à condo et diodes

C’est bien mieux maintenant question papillotement
il me reste à finaliser l’OSD et à voir un problème d’image un peu tremblotante

Les schémas(sur mon site) sont donc faux : je les corrigerai tantôt !!!

bonsoir,je reviens un peu sur ce montage
Je reprends tout ce que j’ai dit dans le dernier message

voici ce qu’est devenu le schéma du crypteur :
schema_crypteur_NE592-2.jpg

Le clamp a été relevé à 5V (4.4V après le transistor)
l’alimentation est augmentée de 8 à 9V

Exit les transistors en commutation dont j’avais parlé : et voici un cd4011
(qui LUI a de vrais seuils de commutation à VCC/2 exactement )

j’ai aussi mis un ampli de gain 3.3 en sortie
et enfin, le tatouage est « sur-élevé » avec un condo et 2 diodes…

j’ai fait une deuxième maquette en décrypteur (avec un OSD à µPD6450) sur ce principe et l’ensemble marche très bien maintenant , on discerne à peine un problème sur les couleurs (la chroma du PAL semble bien fragile !!)

Il ne me reste que 2 problèmes sur le décodeur :
PRIMO :la lecture du tatouage pose problème sur certaines images (claires)
j’utilise le montage issu du déco à base de 68705, à savoir :
lecture luminance1.jpg
de mémoire, c’était aussi le cas sur le décodeur à cubes verts …
cela avait il été solutionné ?, amélioré ?
comment fonctionne le vrai déco pour la lecture du blanc ???

SECUNDO : l’osd est un peu « vibrant » , il semble que le tda2595 fournisse des signaux de synchro H pollués par la gigue …

bonjour, j’ai un peu avancé

1 : j’ai mis le code du décodeur en EEPROM
(ouf , j’ai réussi après des jours perdus sur un simple « goto » mal fait)
Un appui sur une touche , et le code est programmé en eeprom (le clavier peut être retiré).

Le code peut être aussi programmé depuis l’interface de programmation du pic
(les zones « prog » et « eeprom » y sont séparées et bien visibles) (si vous ne voulez pas faire le clavier)

2 : le clavier a meilleure allure (merci bricolou !) avec des codeurs héxa :
Photo1015.jpg
(ici , le code est : 03 C3)

on a l’impression de jouer au coffre-fort : si le bon chiffre est trouvé, l’image est claire !
le schéma est tout simple:
schema_clavier_hexa_4014.jpg

Il me reste peu de choses à faire

  • un petit bug d’affichage sur l’OSD qui est permanent (alors que l’affichage est supposé être momentané)
  • un petit papillotement ( problème analogique)
  • mise à jour de mon site à ce sujet