Circuit de contrôle de l'allumage d'un laser à partir d'une piste audio?

Bonjour à tous!

Vous vous souvenez peut-être qu'il y a quelques mois, j'étais venu vous embêter avec des histoires de contrôle de flux et de gros volumes de données via liaison série? C'était là.
Et bien, ça a avancé, puisque j'ai maintenant un protocole de communication qui fonctionne. Enfin presque, pour une raison que je n'ai pas encore pu éclaircir, les valeurs int envoyées depuis un linux en 32 bits ne passent pas, alors qu'en 64bits c'est ok. Je pense que c'est ma somme de contrôle qui bloque, mais c'est un détail.

Voilà ce qui m'amène: mon projet (pour mémoire un projecteur laser permettant d'insoler des supports sensibles, tels que papier photo, cyanotype, gomme bichromatée, etc) expédie donc de gros volumes de données, à une Arduino Due, via liaison série. le post goulet est clairement la liaison série. Bien que j'ai mis en place, sur les conseils d'un membre du forum de bon conseil (voir l'autre fil) un protocole de communication qui me permette d'économiser des octets, je reste terriblement bridé: une coordonnée étant composée d'au minimum quatre octets (octet d'en-tête, deux octets de valeur (ce sont des int coupés en deux), et une somme de contrôle), je ne peux techniquement pas aller plus vite que 2880 coordonnées par seconde. (à 115200 bauds, on peut transmettre 11520 octets par seconde, soit 2880 chaînes de quatre octets).

La solution à mon problème existe, et elle est assez simple: se passer d'Arduino. Je m'explique. Puisque j'ai écris un programme coté PC qui analyse une image, et que les miroirs qui commandent le laser en position sont commandés analogiquement par une valeur qui oscille entre ±5v, je pourrais utiliser tout simplement la carte son de l'ordinateur qui exécute le programme. Au lieu d'envoyer les données via sérial, je génère une forme d'onde en mappant la direction X vers la voie droite, et la direction Y vers la voie gauche. Les premiers essais que j'ai fait dans ce sens sont concluants, j'aurais d'ailleurs dû y penser plus tôt! Ainsi j'utilise la totalité de la course du laser (avec l'Arduino je ne le commande qu'entre 0 et 5V, ce qui limite le débattement utile et induit des effets indésirables aux positions extrêmes), et je peux utiliser une fréquence d'échantillonage bien supérieure, soit 44100Hz, voir plus en fonction de l'ordinateur utilisé.

Le problème qui se pose est le suivant: une carte son gère une sortie stéréo, or j'ai besoin de trois voies: deux pour la position, et une pour l'intensité du laser. Je peux jouer sur la vitesse de balayage pour compenser l'absence de PWM et gérer l'intensité de l'insolation, mais il faut quand même que je puisse allumer et éteindre le laser au début et à la fin du mouvement.

Je pense qu'il doit exister une solution simple pour faire ça avec des composants simples, mais comme je suis une bille en électronique, je n'ai aucune idée de la manière d'y parvenir/ L'idée serait de faire un petit circuit avec quelques composants, qui allume le laser dès qu'il y a des variations de position (c'est à dire un "son" qui provient du PC), et l'éteint dès que les dernières coordonnées ont été envoyées...

Quelqu'un saurait comment je peux réaliser ça?

PS: j'ai bien conscience que ma question ne relève pas directement de l'environnement Arduino puisque je prévois de ne plus en utiliser dans ce projet, mais puisque j'ai initié le projet avec et que je sais que certains parmi vous pourront m'aider, je crois que ça reste le meilleur endroit pour demander!

Bonjour,

Et pourquoi ne pas utiliser une carte qui puisse communiquer en Ethernet ? Ta carte génèrerait tes PWM et tout ce que tu veux en terme de commande et recevrait les infos depuis le PC avec un débit beaucoup plus grand que la liaison série.

il faut quand même que je puisse allumer et éteindre le laser au début et à la fin du mouvement

Bonjour,
est-ce que le délai entre l'apparition du son et sa détection risque de poser problème ?

je ne peux techniquement pas aller plus vite

as-tu essayé à 250kb/s ?

3Sigma:
Bonjour,

Et pourquoi ne pas utiliser une carte qui puisse communiquer en Ethernet ? Ta carte génèrerait tes PWM et tout ce que tu veux en terme de commande et recevrait les infos depuis le PC avec un débit beaucoup plus grand que la liaison série.

Ca ne m'arrange pas: je veux garder le projet le plus économique possible, et dans mon cas j'ai déjà une arduino Due et un module DAC 16bits. Je sais que ça ne fait pas grand chose, mais la solution via la carte audio me permettrait de me passer des deux, de toute la partie programmation coté laser, tout en ayant un débit supérieur à ce que peuvent supporter le couple carte de contrôle + galvanomètres et miroirs (qui plafonnent à environ 20000Hz).
J'ai réalisé ce projet à la demande d'un ami, et me suis rendu compte que même si je l'ai fait pour être assez simple, il est déjà un peu largue sur certains aspects du fonctionnement qui découlent des contraintes rencontrées. Pour cette raison, avoir juste à brancher une prise jack et lancer un programme serait bénéfique également.

trimarco232:
est-ce que le délai entre l'apparition du son et sa détection risque de poser problème ?

Cela dépend de la taille du délai. Si c'est un délai court compte tenu de la fréquence d'échantillonage, ça peut aller: quelques pixels d'une image manquants dans un coin, ce sera quasiment invisible sur une image de plusieurs Mp.
Si c'est un délai long, c'est plus problématique. Cela tronquera des lignes dans l'image. Et je suppose qu'à la fin de l'insolation il y aura la même latence, avec le risque d'avoir une surexposition localisée au dernier point.
Si le délai est fixe et connu, je peux éventuellement en tenir compte lors de la génération de mes coordonnées. Par exemple en insérant un mouvement de taille et forme arbitraire destiné à déclencher l'allumage hors image.

trimarco232:
as-tu essayé à 250kb/s ?

Oui, ainsi que 500000 et 1000000. Quoi que ce ne soit pas des valeurs standards des enum fournies par la bibliothèque QSerialPort, elles semblent être acceptée. J'obtiens bien la valeur que j'ai spécifié dans le paramétrage, une fois que le port a effectivement été ouvert.
Mais quoique la Due utilise USBSerial (qui en théorie utilise la vitesse maxi de la liaison USB), la vitesse de transfert semble rester la même. Mais je me rends compte en l'écrivant que j'ai peut-être oublié un détail quand j'ai fait le test.

J'ai aussi pensé à une autre solution qui pourrait être simple: utiliser à la fois la sortie audio pour gérer la position, et une petite Arduino (nano ou pro-mini) via sérial pour gérer l'allumage du laser, et éventuellement l'intensité via PWM. Mais se posera alors le problème de la synchronisation entre les deux.
Je pourrais aussi peut-être utiliser cette même petite Arduino pour lire en continu les deux lignes audio et détecter des changements, mais je ne suis pas sûr qu'il soit possible de le faire, puisque ce sera un signal sur ±5v. A moins de mettre un pont redresseur?

troisiemetype:

trimarco232:
as-tu essayé à 250kb/s ?

Oui, ainsi que 500000 et 1000000. Quoi que ce ne soit pas des valeurs standards des enum fournies par la bibliothèque QSerialPort, elles semblent être acceptée. J'obtiens bien la valeur que j'ai spécifié dans le paramétrage, une fois que le port a effectivement été ouvert.
Mais quoique la Due utilise USBSerial (qui en théorie utilise la vitesse maxi de la liaison USB), la vitesse de transfert semble rester la même. Mais je me rends compte en l'écrivant que j'ai peut-être oublié un détail quand j'ai fait le test.

J'ai refait le test à l'instant, en modifiant le détail que j'avais oublié hier: J'avais changé le baudrate de la liaison, mais oublié de changer la fréquance de rafraichissement des positions. Donc les coordonnées pouvaient bien arriver plus vite, elles étaient affichées à la même vitesse.
Donc test plus complet: Avec le même fichier de 944x944 px, j'obtiens:
Configuration "d'origine": baudrate 115200, frequence de rafraichissement 4000Hz: 4 minutes et 50 secondes.
Configuration test: baudrate 500000, fréquence de rafraichissement 12000Hz: 4 minutes et 25 secondes.

Il y a donc bien une différence, mais elle ne correspond pas à ce que j'aurais pu espérer... Et montre de toutes façon que d'une manière ou d'une autre, j'ai encore un plafonnement avec les choix faits.

Personne d'autre n'aurait une idée, alors?
Je vais donc probablement me rabattre sur la solution de lire les entrée audio sur une arduino dédiée, qui allumera et éteindra le laser en fonction du mouvement ou de l'absence de mouvements des miroirs... Ca me semble un peu surdimensionné, mais ça devrait marcher facilement.

Bon, après une semaine assez intense marquée d'avancées franches, j'ai quelque chose qui fonctionne vraiment bien.
L'image est donc encodé en fichier son, j'ai assez peu d'artefacts, une précision de positionnement et une répétabilité largement supérieure à ce que j'obtenais avec les Arduino.

Je reste donc sur cette solution de l'image transformée en son.

Par contre il devient nécessaire, pour passer de la phase d'essais à une phase où l'on puisse utiliser le système de manière simple, de gérer l'allumage du laser.

L'idée de prélever les voies droite et gauches du flux audio et de les lire en analogique pour détecter quand le flux s'arrête me parait satisfaisante, mais comme je vous l'expliquais plus haut je suis une bille en électronique. Je ne sais donc pas comment, d'une part, lire les valeurs négative (et ne pas risquer de cramer la carte), et d'autre part cette lecture des valeurs analogique ne doit en aucun cas modifier la valeur du signal qui arrive aux pilotes des deux galvanomètres: si ça devait arriver je perdrais en précision de positionnement.

J'ai fait tout à l'heure un essai avec une diode (pour ne récupérer que la tension positive) (d'ailleurs pas vraiment une diode, puisque je n'en ai pas sous la main: j'ai pris une led à la place, avec une petite résistance série), connectée à une entrée analogique d'un coté et à une de mes voies audio de l'autre, avec une résistance pull down. Je suppose donc qu'il faudrait une autre solution, mais je ne vois pas laquelle.

Quelqu'un a une idée?

Je suppose donc qu'il faudrait une autre solution

Bonjour,

je dirais : redresseur parfait -> comparateur (de l'arduino) -> entrée capture (avec filtre) de l'arduino

il y a peut-être plus simple ...

Personne d'autre n'aurait une idée, alors?

une petite question concernant le flux en rs232 : on en est à combien de % de ce qu'il te faudrait, on peut peut-être rattraper en optimisant le protocole ?

troisiemetype:
L'idée de prélever les voies droite et gauches du flux audio et de les lire en analogique pour détecter quand le flux s'arrête me parait satisfaisante, mais comme je vous l'expliquais plus haut je suis une bille en électronique.
...
Quelqu'un a une idée?

Bonsoir
Je ... resume ma compréhension 8)
Tu veux "juste là contrôler un laser en ON/OFF" selon l'activité détectée sur une des voies G/D "niveau casque" issue d'un PC ?

Ah, du grain à moudre et des idées pour avancer!

trimarco232:
Je dirais : redresseur parfait -> comparateur (de l'arduino) -> entrée capture (avec filtre) de l'arduino
[...]
une petite question concernant le flux en rs232 : on en est à combien de % de ce qu'il te faudrait, on peut peut-être rattraper en optimisant le protocole ?

Redresseur parfait, ça ne me parle pas du tout. Je vais regarder demain et je te dirai ce qu'il en est!
Pour répondre à la question du flux en RS232, je n'ai pas de réponse précise à donner. Un pixel d'image correspond à une coordonnée en X (16 bits, 2 cotets), une en Y (2 octets), une valeur d'intensité (1 octet).
Une valeur qui ne change pas peut ne pas être envoyée, puisque que le programme coté Arduino copie dans ce cas la précédente. On ajoute à ça un octet de début de chaîne, et une somme de contrôle, et il n'y a plus qu'à multiplier par les dimensions d'une image!
J'avais déjà pas mal optimisé le protocole sur tes conseils avisés, voir ce fil.

J'ai fait mon deuil de cette idée d'envoyer les données par liaison série: utiliser l'audio a un certain nombre d'avantage:
Le taux de transfert. 44100Hz c'est déjà bien mieux que ce que peut proposer l'arduino, mais à 48000 on gagne encore un peu, et à 96000, même si l'inertie des galvanomètres commence à être handicapante, sur des mouvements progressifs c'est encore très honnête.
La précision en positionnement. Le module DAC 16 bits que j'avais trouvé faisait sûrement bien son travail, mais il avait du mal à tenir la cadence et manquait de répétabilité. Le signal analogique généré par ma carte son a une répétabilité exemplaire, ce qui présente deux intérêts: le premier, évident, est que l'image est conforme à l'originale. Le second, c'est que la précision et la répétabilité est telle que je peux passer plusieurs fois sur la même image, sans pouvoir jamais discerner un écart d'un passage à l'autre. Et puis, cerise sur le gâteau, je peux coder les coordonnées sur 24 ou 32 bits! Bien que je n'en ai pas vu la différence de manière flagrante sur mes petits essais, je pense que sur de grands tirages ça peut changer quelque chose.

Artouste:
Bonsoir
Je ... resume ma compréhension 8)
Tu veux "juste là contrôler un laser en ON/OFF" selon l'activité détectée sur une des voies G/D "niveau casque" issue d'un PC ?

C'est exactement ça. En fait je veux lire les deux voies, parce que l'une peut être immobile pendant que l'autre varie (balayage horizontal, ou vertical). Mais c'est exactement ça: éteindre le laser quand rien ne varie, et l'allumer dès qu'il y a un changement notable.

Il a été ouvert un groupe privé sur facebook, sur lequel je publie régulièrement, notamment des images réalisées avec le système. Envoyez-moi un MP si vous voulez que je vous invite! depuis le temps que vous m'aidez tous les deux, je vous doit au-moins ça! :wink:

Encore merci pour votre aide!

et ta carte son n'a que 2 voies, ne peut-on pas envoyer le signal on/off sur une troisième voie ?

C'est bien ça mon drame! Je sais qu'un carte son peut gérer plusieurs voies (celle de mon thinkpad peut en gérer 1, 2, 6 ou 8), mais par la prise Jack, ne sortent qu'une voie droite et une voie gauche... Dans l'idéal c'est ce que je ferais, ce serait le plus simple, et la certitude d'avoir des signaux parfaitement synchronisés.

Comme j'ai développé ce système à la demande d'un ami qui avait vu passer quelque chose de similaire sur Internet, Je veux faire en sorte que ce soit un genre de système plug&play, qu'il n'y ait pas besoin d'autre chose que du programme à faire tourner, et du laser lui-même. Et puis de toutes façon, investir dans une carte son externe, vu mes finances actuelles... :slight_smile:

L'autre avantage qu'il y a à rester sur deux voies, c'est qu'on peut imaginer exporter le fichier son généré sur n'importe quel système audio, et se passer du programme. Ca pourrait être un baladeur, mais aussi une cassette, une bande, une DAT, un minidisc... Avec bien entendu les imperfections qui peuvent en résulter, mais comme le but recherché est artistique, introduire l'irrégularité analogique dans un système numérique n'est pas forcément inintéressant.

bonjour
Je testerais l'utilisation de 2 detecteur de son "cheap" avec les sorties cablées en OU , en remplaçant la capsule electret par une liaison vers les voies casque G et D.
peut etre prevoir un attenuateur à resistance en entrée.

C'est une idée qui me plaît, ça! Par cablée en ou, tu entends un montage logique avec des transistors? On ne peut pas simplement utiliser deux entrées de l'Arduino? (analogiques ou digitales, je ne sas pas ce qui sort de ces modules. je vais jeter un coup d'œil)

troisiemetype:
C'est une idée qui me plaît, ça! Par cablée en ou, tu entends un montage logique avec des transistors? On ne peut pas simplement utiliser deux entrées de l'Arduino? (analogiques ou digitales, je ne sas pas ce qui sort de ces modules. je vais jeter un coup d'œil)

Cablage OU = une diode en serie sur chaque sortie vers un pin input digital arduino :grin:
J'en ai de ces modules , mais je manque de temps pour tester/verfier l'idée
Poste un de tes fichiers audio , si j'ai un peu de temps , je ne suis pas à l'abri de "monter une petite manip"

Hop-là!
Je ne peux pas mettre en pièce jointe le fichier audio, qui est trop volumineux, du coup je l'ai mis sur mon drop box. Il faut suivre ce lien.
Par contre je mets en pièce jointe une numérisation de l'image correspondant au fichier en question. Parce que c'est chouette de parler de trucs très abstraits, mais ça vous plaira peut-être de voir à quoi ça correspond! Bon, c'est la toute première image que j'ai fait avec cette version du projet, donc le papier n'est pas génial, et l'image sur-exposée. Mais l'idée est là.

Je te remercie par avance des essais que tu pourras faire, en espérant qu'ils s'avèrent positif. Je vais essayer cette idée de câblage en direct en passant par une diode. Peut-être qu'en fait, si ça ne marchait pas avec les entrées analogiques, les entrées numériques pourraient effectivement faire l'affaire!

Encore merci du temps que vous consacrez à mes interrogations.

je n'ai pas trouvé (mal cherché ?) de schéma fiable du module ...

  • si la sortie se fait par lm393 (collecteur ouvert) avec pull-up, la mise en parallèle peut se faire sans autre forme de procès [édit:] à condition aussi qu'il soit actif au niveau bas

  • ce qui m'inquiète un peu, c'est l'orientation audio du module : il y a un condensateur après le micro, comment cela réagira-t-il à ces signaux très particuliers ? -> est-il possible d'envoyer un signal bf "bidon" en début d'impression, juste dédié à l'allumage du laser ?

trimarco232:
je n'ai pas trouvé (mal cherché ?) de schéma fiable du module ...

  • si la sortie se fait par lm393 (collecteur ouvert) avec pull-up, la mise en parallèle peut se faire sans autre forme de procès [édit:] à condition aussi qu'il soit actif au niveau bas

  • ce qui m'inquiète un peu, c'est l'orientation audio du module : il y a un condensateur après le micro, comment cela réagira-t-il à ces signaux très particuliers ? -> est-il possible d'envoyer un signal bf "bidon" en début d'impression, juste dédié à l'allumage du laser ?

Bonsoir
Il faut "voir" où et comment faire l'injection "casque"
l'etage d'entrée d'origine (micro) est prevu d'origine pour un electret (et donc son alimentation)