[Thomson] Vidéo avec son en streaming

[F1FCO]

bonjour Daniel,
qu'as tu commandé comme analyseur logique ? un Sollae ?

un oscillo 2 ou 4 traces (comme le Rigol) n'est-il pas suffisant ?

Pierre

[Daniel]

un Sollae ?

Oui ! Comment as-tu deviné ?
[Edit] En réalité non. Je viens de vérifier, c'est un Saleae :

Pour la communication avec l'Arduino, il y a huit bits dans un sens et un bit dans l'autre. Mes oscilloscopes de collection sont tellement vieux qu'ils sont devenus inutilisables pour ce type de mesure. J'ai pris l'appareil le moins cher du marché, car quand le streaming vidéo fonctionnera je n'en aurai plus l'utilité.

@sam : oui, bien sûr, je vais tester le programme dans les heures qui viennent. Il n'y a qu'une chance sur mille, mais je vais la tenter.
Même si delayMicroseconds() est juste, je ne connais pas le temps d'exécution des autres fonctions, donc ce n'est pas facile de trouver les bonnes valeurs.

[6502man]

J'avais hésité lorsque j'ai commandé mon analyseur logique avec un modèle de ce style, mais je me suis dit que 24Mhz et 8ch ca faisait un peu juste pour ce que je pourrais avoir à analyser sur toutes mes machines et montages

En tout cas avant d'avoir essayé ce type de matériel je ne savait absolument pas comment l'utiliser et ce que ca m'apporterais, mais maintenant je le sort à toutes les occasions
Et je le trouve vraiment pratique pour trouver certaines pannes, évidemment ca ne remplace pas un oscilloscope (mais je n'en ai pas et ne sait pas m'en servir)

[yo_fr]

Il y a aussi un registre qui contient les micro secondes écoulées depuis la mise en run (micro()). Pour faire un cadencement se serait plus sûr de se baser sur l'ensemble d'une frame en attendant des valeurs d'offset.
VAL : valeur en debut de frame
VAL + T1 : temps 1
VAL + T1 + T2 : temps 2
VAL + T1 + T2 + T3 : temps 3
...
Je pense qu'il y aurait moins d'erreur de timing et plus simple à mettre en oeuvre que de mettre des tempo pour combler les trous (tempo effectivement difficile à évaluer) de plus si un timer foire, les suivants rattraperont le coup.
...c'est juste une idée...
une autre mais moins simple c'est d'utiliser les timer (TCCRxA et autre)

[Daniel]

Excellente idée ! Merci !
Je ne connaissais pas cette fonction (je débute sur Arduino), mais elle semble bien adaptée. La résolution n'est que de 4 µs, mais en calculant bien on doit y arriver : il suffit de déposer l'octet dans le PORTD avant que le programme Thomson le lise. Le délai minimum entre deux lectures est de 7 µs, on a donc une marge pour placer l'écriture au bon moment. Une petite difficulté sera de gérer l'overflow toutes les 70 minutes. Où alors il faudra se contenter de films court-métrage, ce serait dommage

micros()
Description
Returns the number of microseconds since the Arduino board began running the current program. This number will overflow (go back to zero), after approximately 70 minutes. On 16 MHz Arduino boards (e.g. Duemilanove and Nano), this function has a resolution of four microseconds (i.e. the value returned is always a multiple of four).

[__sam__]

Normalement il ne devrait pas y avoir de décalage parce qeu tous les 7 octets lus (environ 60µs), il y a resynchro via le bit b6 du port A. Bref, je ne pense pas que 7 appels à delayMicroseconds() provoque un décalage énorme, mais grace à la synchro périodique ca ne doit pas s'accumuler.

[Daniel]

Le projet a un peu traîné, mais j'ai quelques excuses :
- L'installation de Windows 10 a pris du temps
- L'analyseur logique est tombé en panne après 20 secondes d'utilisation. Diagnostic : le régulateur AMS1117 sort 0,2V au lieu des 3.3V attendus. J'ai eu peur de dégâts en aval, mais non, ce n'était que le régulateur, il s'est détruit sans aucune raison. Je n'avais jamais vu ça. Après l'avoir changé tout fonctionne bien.
- L'arduino a été détruit par une alimentation 5V de téléphone. Cette alimentation régule très bien quand elle débite au moins 1 mA (5V + ou - 0,1V), mais à vide elle sort à peu près 12V. J'ai mis une résistance de 2,2K en parallèle et remplacé l'Arduino, plus de soucis.

Et donc les tests vont commencer. Voici à quoi ressemblent les signaux en supprimant l'attente du top de synchronisation. A priori les temporisations semblent un peu trop longues. Je vais préparer un fichier de test pour l'analyser plus précisément. Dans l'image le canal du haut est le trigger, il sert à la fois à déclencher l'enregistrement de l'analyseur et à démarrer le programme Arduino. Ensuite, dans l'ordre, les bits 0 à 6 de l'octet de données. Le bit 7 n'est pas représenté car je n'ai que 8 canaux, mais il n'a pas un grand intérêt.

analyse01.png (9.25 Kio) Consulté 3531 fois

[__sam__]

Oula, oui que de problème techniques. Le sort s'acharne pour que le streaming thomson "pleine vitesse" prenne du retard.

Ca se voit où que les délais sont trop longs? La largeur cumulée de 7 créneaux qui dépasse les 60µs du player ?

Je suis sur que tu va réussir à trouver le bon tuning avec cet analyseur. Bon courage!

[Daniel]

Dans l'exemple on voit des octets au hasard (la vidéo de Dire Straits), on ne peut pas savoir où sont les échantillons de son et les octets vidéo, donc on ne peut rien conclure.

Il faut créer un fichier avec des octets bien précis, par exemple mettre les 3 bits de poids faible à zéro pour les octets son, de 1 à 6 pour les octets vidéo, et utiliser les bits de poids fort pour donner le numéro du groupe dans le bloc. On distinguera ainsi sur le graphique les octets son, les octets vidéo, les fins de bloc. Le logiciel permet de mesurer précisément les durées de chaque créneau, on pourra alors ajuster les temporisations pour obtenir les bonnes valeurs. C'est la théorie, reste à la mettre en pratique...

[Daniel]

Pour mieux visualiser les données transmises, j'ai forcé b0 à 0 pour les échantillons son et à 1 pour les octets vidéo. La durée entre l'échantillon son et le premier octet vidéo est en moyenne 6,65 µs (contre 8 µs attendu par le programme Thomson). En y ajoutant les 58,33 µs mesurées entre le premier octet vidéo et l'échantillon son suivant, la période pour un groupe de 7 octets est de 64,98 µs.

En réalité il faut 8 + 10 + 7 + 9 + 10 + 7 + 9 = 60 µs. Ce n'est pas loin. Il faut viser un peu moins de 60 µs, pour finir le cycle de 7 octets avant le prochain bit de synchronisation. En diminuant un peu les temporisations on devrait y arriver...

analyse02.png (30.25 Kio) Consulté 3520 fois

[Edit]
J'oubliais de le dire, tellement c'est évident : un analyseur logique est un outil génial. Je ne sais pas comment j'ai pu m'en passer jusqu'à maintenant. On voit tout ce qu'on ne peut pas voir à l'oeil nu. Pour 7,50 € port gratuit c'est un excellent investissement !

[yo_fr]

Question néophyte : tu ne peux pas utiliser une sortie quelconque du MO pour signaler à l'Arduino que l'octet a été lu (changement d'état d'un bit) et qu'il peut passer au suivant ?

[Daniel]

Oui, relis le fil de discussion, c'est ce qu'on fait. Dans la nouvelle version, pour gagner du temps, on ne teste pas le bit de synchronisation à chaque octet, mais uniquement pour les échantillons de son, soit un octet sur 7. C'est le programme Thomson qui impose le rythme. Entre deux échantillons de son, il reste à envoyer les 6 octets vidéo au bon moment. Le but de cette étude est d'obtenir le bon chronogramme par l'ajustement des temporisations.

Bonne nouvelle : le changement de bloc est beaucoup plus rapide que prévu : en moyenne 13,45 µs entre le dernier échantillon de son d'un bloc et le premier échantillon du bloc suivant. La marge est très confortable.

analyse03.png (24.64 Kio) Consulté 3515 fois

[__sam__]

Si le temps de 4µs entre la lecture du dernier échantillon vidéo avec le dernier octet du bloc est trop faible et nécessite une trop grosse précision du coté de l'Arduino, il est tout à fait possible de modifier le player pour retarder la lecture de 4µs supplémentaire ou plus. Il y a une marge de 60µs avant le début du bloc suivant qu'il est facile d'adapter de 2µs en 2µs sans augmenter la taille du player en jouant sur le masque des registres dans les paires pshs/puls.

Le fait que le changement de bloc est beaucoup plus rapide que les 60µs montre qu'on a trouvé un bon truc avec ce format de trame (73x7 + 1). Il n'y aura pas de retard vidéo ni aucun audio et plein de temps pour attendre le bloc suivant. Tout tombe bien au bon moment.

Je sens que tu es pas loin d'avoir un truc fonctionnel. Dans le pire des cas en rajoutant une paire de NOP dans le player on peut descendre la période à plus de 64µs, mais ca serait dommage.

[6502man]

Ca rigole pas sur le timing avec Daniel

Le player vidéo sur Thomson va frôlé la perfection

[Daniel]

Pour continuer il faut un chronogramme théorique précis, pour savoir exactement à quel moment envoyer les octets sur le port D de l'Arduino.

L'origine des temps ne se situe pas à la lecture de l'échantillon son, mais à la réception par l'Arduino du bit de synchronisation. Ce n'est pas à la frontière entre deux instructions Thomson, mais pendant l'instruction d'écriture de l'octet son : peut-être 1 µs avant la fin de l'instruction, mais je n'en suis pas sûr, il faut vérifier. Ce moment précis sera le temps 0.

Le premier octet vidéo doit être envoyé par l'Arduino dans une fourchette allant de 0 à t1, lecture de l'octet par le programme Thomson. Même remarque pour t1, ce n'est pas entre deux instructions mais au cours de l'instruction de lecture, à un instant qu'il faut déterminer précisément.

Idem pour les octets vidéo suivants (t2, t3, t4, t5, t6) et l'échantillon de son (t7).

Lorsque t1 à t7 seront déterminés, on connaîtra la fourchette de temps pour l'envoi de chaque octet par l'Arduino. Une petite marge de sécurité de 1 µs devrait suffire, ce qui donnera la table suivante :

0 à t1-1 : octet vidéo 1
t1+1 à t2-1 : octet vidéo 2
t2+1 à t3-1 : octet vidéo 3
t3+1 à t4-1 : octet vidéo 4
t4+1 à t5-1 : octet vidéo 5
t5+1 à t6-1 : octet vidéo 6
t6+1 à t7-1 : échantillon son

Une fois cette table établie, l'ajustement des temporisations sera un jeu d'enfant, grâce à l'analyseur logique. Il ne devrait pas être nécessaire de modifier le programme Thomson, car je crois que l'Arduino peut lire un octet sur la carte SD et l'écrire sur le port D en moins de 3 µs.