12 réponses à ce sujet

[Black Templar]

Bonjour à tous !

Après avec mis en stand-by mon précédent projet (ma centrale inertielle) jusque la rentrée (je me casse les dents sur un problème d'I2C sans arriver à savoir si ça ne marche pas à cause de l'interface entre les 2 I2C (l'un en 5V l'autre en 3.3V) ou à cause de mon code sur le PIC33F...), j'ai décidé de commencer un autre projet qui me trotte en tête depuis plusieurs années.
J'aimerais réaliser mon propre oscilloscope numérique.

En effet, j'ai souvent été bloqué dans mes projets parce que je n'ai pas les moyens de me payer un oscilloscope qui pourtant, est un outils très pratique pour étudier les signaux de tout types. Plutôt que d'en acheter un, je pense pouvoir le fabriquer à moindre coût !

Pour commencer, jusque la rentrée, je vais me consacrer sur le logiciel informatique ! Je compte le coder en C++ avec Qt.
Le logiciel permettra de :

• gérer l'affichage de deux voies simultanément
• modifier l'échelle temporelle
• modifier les échelles Y des deux voies
• choisir un offset en X et Y pour chacune des voies
• sélectionner un mode de représentation standart en choisissant ou non de moyenner les valeurs
• sélectionner un mode de représentation XY, pour avoir la voie une en fonction de la voie 2
• sélectionner un mode déclencheur. L'acquisition des voies se déclenchera lorsque la tension de l'une des deux voies au choix aura bougé d'un certain seuil
• sélectionner un mode "écoulement du temps" où les tensions des deux voies défilent en fonction du temps
• sélectionner un mode de représentation spectrale d'une des deux voies (en utilisant un périodogramme modifié (estimateur de Welch) où les paramètres seront customisable par l'utilisateur)

Ensuite, une interface graphique pourra configurer la carte d'acquisition. Les paramètres modifiables de la carte d'acquisition seront :

• La fréquence d'échantillonnage (choix entre 2000, 4000, 8000 ou 16000 Hz)
• Le domaine d'acquisition (choix entre [0V;5V], [0, 12V], [-5, 5V], [-12, 12V]

Pour la carte d'acquisition en elle même, je ne la commencerais pas avant la rentrée. Je préfère finir le logiciel avant. Sinon, je pense que j'utiliserais un PIC alimenté en 5V par le PC avec un convertisseur analogique numérique de 12 bits. Le dialogue entre la carte et le PC se fera par un RS232 émulé. (donc connection USB)
Avec 4 octets par couple de valeurs (12 bits par valeur + 8 bits pour d'éventuels tests) et une fréquence d'échantillonnage de 16kHZ, je n'aurais que 64Ko de données par seconde, ce qui est largement supportable par de l'UART.

Voila. J'espère que je n'abandonnerais pas encore une fois un projet...
Pour le moment, je me consacre à ce que je sais faire de mieux : la partie logicielle !

[Leon]

Avec 4 octets par couple de valeurs (12 bits par valeur + 8 bits pour d'éventuels tests) et une fréquence d'échantillonnage de 16kHZ, je n'aurais que 64Ko de données par seconde, ce qui est largement supportable par de l'UART.

16kHz? Ca n'est pas beaucoup! Dans mes montages, les bus I2C sont à 200kHz...

Pour des fréquences aussi faibles, tu peux aussi utiliser l'entrée audio de ta carte son. L'échantillonnage d'une carte son, c'est de l'ordre de 60kHz si mes souvenirs sont bons. Il y a plein de softs "transforment" ta carte son en oscillo. Par contre, les cartes son possèdent un filtre passe bas, donc tu ne pourras pas mesurer précisément les tensions. Mais pour voir quand un créneau apparait, pour dépanner, ça peut servir!

Autre chose: si tes montages sont centrés sur l'électronique numérique, et que tu ne manipules quasiment jamais de l'analogique, tu peux aussi acheter ou te construire un analyseur logique. J'ai investi dans un analyseur pas trop mauvais, et je ne le regrète pas. Je vais bidouiller de l'électronique numérique encore pendant pas mal d'années!

Après avec mis en stand-by mon précédent projet (ma centrale inertielle) jusque la rentrée (je me casse les dents sur un problème d'I2C sans arriver à savoir si ça ne marche pas à cause de l'interface entre les 2 I2C (l'un en 5V l'autre en 3.3V) ou à cause de mon code sur le PIC33F...), j'ai décidé de commencer un autre projet qui me trotte en tête depuis plusieurs années.

Pour ton problème de bus I2C, tu peux m'en dire plus? J'ai déjà été confronté à ce genre de difficultés de niveaux de tensions, alors je peux peut-être t'aider!
Tu avais peut-être un post qui en parlait? Je n'ai rien trouvé dans tes posts récents.


Leon.

[Black Templar]

16kHz? Ca n'est pas beaucoup! Dans mes montages, les bus I2C sont à 200kHz...

Oui, c'est ce qui m'avait refroidit il y a quelque temps. (Echantillonné à 400kHz, ça voudrait dire mettre en place un protocole de communication type USB, mais je me suis cassé les dents à essayer de programmer les drivers qui vont bien...)
Mais finalement, je me rend compte que je ne manipule jamais des signaux analogiques de très hautes fréquences ! Donc 16KHz me parait correcte pour l'application que je veux en faire. (ça fait que mes signaux ne pourront pas dépasser 8KHz, mais bon, c'est pas très grave, ça devrait être utile pour pas mal d'applications, y compris pour mesurer des signaux PWM qui commandent un moteur).

Pour des fréquences aussi faibles, tu peux aussi utiliser l'entrée audio de ta carte son. L'échantillonnage d'une carte son, c'est de l'ordre de 60kHz si mes souvenirs sont bons. Il y a plein de softs "transforment" ta carte son en oscillo. Par contre, les cartes son possèdent un filtre passe bas, donc tu ne pourras pas mesurer précisément les tensions. Mais pour voir quand un créneau apparait, pour dépanner, ça peut servir!

Tiens, je ne savais pas qu'on pouvait récupérer les échantillons en passant par la carte son ! Je vais me renseigner (même si le filtre passe bas est embêtant en effet...)

Autre chose: si tes montages sont centrés sur l'électronique numérique, et que tu ne manipules quasiment jamais de l'analogique, tu peux aussi acheter ou te construire un analyseur logique. J'ai investi dans un analyseur pas trop mauvais, et je ne le regrète pas. Je vais bidouiller de l'électronique numérique encore pendant pas mal d'années!

Oui, j'en ai vu des pas trop cher ! Je pense que je vais invertir dans un analyseur logique d'ici peu car c'est bien utile, mais le but de l'oscillo que je veux faire, c'est d'analyser des signaux analogiques.

Pour ton problème de bus I2C, tu peux m'en dire plus? J'ai déjà été confronté à ce genre de difficultés de niveaux de tensions, alors je peux peut-être t'aider!
Tu avais peut-être un post qui en parlait? Je n'ai rien trouvé dans tes posts récents.

J'ai exposé mon problème il y a quelque temps sur le sujet concernant la centrale inertielle : http://www.robot-mak...dpost__p__28253

Depuis, j'ai essayé de faire marcher la communication sans pour autant convertir les signaux logiques de 3.3 en 5V, mais ça ne marche pas. Du coup, comme c'est la première fois que j'utilise l'I2C, je ne sais pas si c'est un problème de code ou un problème d'interface.... et ça me bloque


Merci pour tes réponses et tes suggestions.
++
Black Templar

[Black Templar]

Faute de temps à ma disposition pour coder et faire des tests, j'ai réfléchi à la conception de mon programme d'oscilloscope et j'ai eu quelques idées pour en faire un programme générique et modulable !


Tout d'abord, je vais implémenter un système de "driver" pour dialoguer avec la carte d'acquisition. Le "driver" sera un simple fichier texte spécifiant le moyen de communiquer avec la carte d'acquisition. Ainsi, il sera facile de créer plusieurs cartes d'acquisitions qui pourront être utiliser avec le même logiciel !!
Les données du driver sont (en gros) :

• Le nom de la carte
• Une liste des fréquences d'échantillonnages supporté par la carte
• Une liste de plage d'acquisition supporté par la carte
• Le nombre de voies de la carte
• La taille d'une acquisition en bits
• La taille du numéro de l'acquisition en bits
• La taille de la séquence de bits de début de message
• Le nom du plugin de communication avec la carte (RS232, USB, fichier, éthernet, autre)
• Une liste d'options pour le plugin (vitesse de transfert, chemin du driver usb, nom du fichier, etc.)

Ensuite, je me suis dit pourquoi si limiter à du RS232 pour la communication. J'aimerais que mon programme puisse communiquer avec tout types de cartes (USB, éthernet, carte son ou autre). J'ai donc décidé de créer un système de plugin qui se chargerait de récupérer les données de la carte et de fournir ces données au programme.

Avec ces deux idées, chaque personne désirant créer un oscilloscope pourra designer sa propre carte d'acquisition avec son protocole de communication préférer et l'utiliser avec mon programme. Tout ce qu'il aura à faire, c'est écrire le driver pour la carte d'acquisition qu'il souhaite réaliser (ça prend 2 minutes) et écrire le plugin de dialogue avec la carte d'acquisition si celui-ci n'existe pas déjà ! (ça prend un peu plus de temps, mais moins que de réécrire tout le programme)

Pour commencer, j'écrirais un plugin pour dialoguer avec du RS232 et ainsi, par la suite, je pourrais rajouter d'autre protocoles sans recompiler le programme
Maintenant, il n'y a plus qu'a faire une architecture solide pour le programme ...

++
Black Templar


EDIT : J'ai aussi pensé à rajouter une option anti-recouvrement qui permettrait d'activer ou non un filtre passe-bas en fonction de la fréquence d'échantillonnage afin d'éviter le recouvrement au niveau du spectre de fréquence du signal

[Black Templar]

Bonjour à tous !

Quelques nouvelles du projet qui avance tout doucement !

J'ai fini le cahier des charges et j'ai dressé les grandes lignes de l'architecture du soft.
J'ai aussi décidé de coder un "updater" qui mettrait à jour automatiquement le programme lorsqu'une nouvelle version du soft ou des plugins/drivers est disponible.
J'ai fini de le codé et ça marche plutôt bien ! Je passe à l'interface graphique de l'updater puis je nettoierais/commenterais le code.

C'est la première fois que je code un updateur pour un soft et j'ai lis en pratique pas mal de nouvelles notions (qui sont assez facile à prendre en main grâce à Qt !) :

• Parsage XML
• Manipulation de base de données locale SQLite en C++
• Téléchargement de fichiers distants

Une fois l'utilitaire fini, je posterais le début de code avant de m'attaquer à la vrai partie du problème : le logiciel oscilloscope !!

++
Black Templar

[miky-mike]

Très beau projet qui je l'espère aura une belle réussite.

[Black Templar]

Très beau projet qui je l'espère aura une belle réussite.

Merci pour les encouragements !
J'espère bien que ça sera une réussite ^^
Pour le moment, ça s'annonce bien. J'avance doucement, mais je suis motivé et je sens que je mènerais le projet jusqu'au bout.

Sinon, après le logiciel, j'ai pensé créer le driver/plugin qui va bien pour transformer une Arduino en oscilloscope.
Puis je me pencherai sur la création d'un shield pour Arduino (histoire de pouvoir étendre la plage d'acquisition au delà de 0-5V)
Et enfin, j'écrirai surement un plugin pour faire l'acquisition d'un signal via la carte son (ça me tente beaucoup depuis que Léon m'en a parlé !)


Pour le moment, j'ai un peu bloqué au niveau de l'interface graphique de l'updater (je n’arrivais pas à intégrer un Widget dans un tableau). Finalement j'ai trouvé comment faire, mais je ne risque pas d'avancer avant le WE prochain car cette semaine, c'est la semaine des soutenances et rapports de stage :/:/

++
Black Templar

[Black Templar]

Bon, j'ai fini d'écrire l'utilitaire de mise à jour ! Il est fonctionnel (même s'il est encore améliorable)



Principe :

L'utilitaire se charge de télécharger un fichier XML sur le serveur. Ce fichier contient la liste des dernières versions des fichiers du logiciel.
Une fois le fichier téléchargé et parsé, l'utilitaire ira comparé la liste de ces fichiers serveurs avec la liste des fichiers présent sur le PC (cette liste est stocké dans une base de donnée SQLite).
En fonction des nouveaux fichiers ou des nouvelles version, l'utilitaire construit la liste des fichiers à télécharger.
Il lance l'interface graphique permettant de visualiser la progression du téléchargement.
Quand le téléchargement est terminé, l'utilitaire demande de redémarrer l'application pour appliquer les mises à jours.



Architecture :

L'utilitaire de mise à jour est composé de trois classes :

La classe Downloader permet de gérer le téléchargement d'un fichier

La classe Updater gère le protocole de téléchargement des fichiers de mise à jour :
• téléchargement du fichier XML serveur
• comparaison avec la base de données
• construction de la liste des fichiers à télécharger
• mise à jour de la base de données
• remplacement des fichiers

La classe UpdaterGui permet de déclencher le téléchargement et d'afficher la liste des fichiers téléchargés.



Détail des classes :

La classe Downloader

Cette classe possède deux slots :
• downlaodFile(QUrl) : permet de déclencher le téléchargement d'un fichier
• saveFile(QString) : permet de sauvegarder le fichier téléchargé sur le disque

Deux signaux permettent de surveiller la progression du téléchargement :
• downloadDone() : est déclenché lorsque le fichier a été téléchargé
• downloadInProgress(int) : est déclenché lorsque le pourcentage du téléchargement à progressé


La classe Updater

Cette classe ne possède qu'une méthode publique start() qui permet de déclencher le processus de mise à jour.


La classe UpdaterGui

Cette classe permet d'afficher dans une interface graphique les informations sur le téléchargement. UpdaterGui possède une méthodes publiques loadFileList(QVector< QMap<QString, QString> >) qui permet de charger les informations concernant les téléchargements dans l'interface graphique.
De plus, deux slots sont disponibles :
• downloadFinished() : permet de déclencher un message indiquant que le téléchargement est fini
• setValue(int, int) : permet de spécifier le pourcentage de progression du téléchargement d'un fichier

Enfin, le signal start() permet de spécifier à la classe Updater que le téléchargement peut être lancé.



Code source :

Le code source de l'utilitaire de mise à jour (ainsi que de tout le projet) sera hébergé sur un gestionnaire de version à l'adresse suivante :
https://code.google....source/checkout




Maintenant, je peux passer aux choses sérieuses : la réalisation du logiciel en question
++
Black Templar

[miky-mike]

Bonjour
je vais te donner mon point de vue (c'est toujours bien d'avoir des retours).

Principe :
Le principe est correcte, mais personnellement je trouve qu'utilisé sqlite est vraiment gâcher de la mémoire pour pas grand chose).
Un fichier xml aurait été vraiment plus intéressant, d'un point de vue taille, mais également de performance.

Architecture :
J'ai rien a redire pour le moment ça semble correcte.

Je n'ai pas encore regarder le code par contre.

J'ai pas le temps de compilé, peut on avoir un aperçu de la GUI ?

Que comptes tu codé maintenant ?

[Black Templar]

Principe :
Le principe est correcte, mais personnellement je trouve qu'utilisé sqlite est vraiment gâcher de la mémoire pour pas grand chose).
Un fichier xml aurait été vraiment plus intéressant, d'un point de vue taille, mais également de performance.

Oui, j'avais pensé enregistrer les données des fichiers locaux dans un fichier XML, mais comme j'avais déjà essayé, sans succès, d'utiliser le module SQL de Qt il y a quelques temps, j'ai voulu réessayé.
Finalement, ça ne prend pas énormément de place ! Le driver fait 337Ko et le fichier base de donnée en question ne dépassera pas les 10ko.

Architecture :
J'ai rien a redire pour le moment ça semble correcte.

Je n'ai pas encore regarder le code par contre.

Le code est grandement améliorable ! (surtout au niveau de la gestion de la base de donnée )
Mais pour le moment, je met l'updater en stand-by ! Je l'optimiserais quand j'en aurais marre de coder le programme en question ^^

J'ai pas le temps de compilé, peut on avoir un aperçu de la GUI ?

Rien de transcendant pour le moment... Juste un truc fonctionnel !

Que comptes tu codé maintenant ?

Je compte coder l'application elle même.
Je vais m'attarder d'abord sur la partie la plus chiante, c'est à dire l'interface graphique...
Ensuite j'écrirais un petit plugin tout bidon pour récupérer un signal dans un fichier (histoire de faire des tests sans développer l'électronique d'acquisition tout de suite )
En enfin, je passerais au plus amusant : le rendu graphique du signal en fonction de l'option choisie

L'architecture du programme est plutôt simple : une classe GUI gérant l'interface graphique, une classe EcranOscillo (pour afficher le signal), une interface Communication pour lier le programme oscillo au plugin de communication avec la carte d'acquisition.
Par contre, je me demande encore si je ne rajouterais pas un système de plugin supplémentaire pour pouvoir ajouter des "rendu graphique" supplémentaires à l'écran et gérer les options de ces rendus... (exemple : un plugin pour la représentation spectrale, un plugin pour le mode déclencheur, un plugin, pour le mode normal, un autre pour le mode XY, etc...)



++
Black Templar

[Otatiaro]

Salut,

Ou sinon, tu arretes de couper les cheveux en 4, tu t'achetes un Saleae Logic, et tu gagnes des jours de capillotractage en règle.
Ce truc est juste un cadeau du ciel, ca m'a sauve des heures et des heures et des heures de "mais p**ain pourquoi ca marche pas !".

Pour en revenir à ton projet, j'ai peut etre quelque chose à te proposer ... selon tes besoins. Si tu fais uniquement du numérique (ton problème d'origine portait sur de l'I2C), j'avais commencé a concevoir un "Saleae Logic like" sur base de FT2232H, maintenant le FT232H est disponible.

Le principe est tout con, on utilise le bit bang mode pour échantillonner à une fréquence donnée.

J'ai déjà un logiciel plus ou moins fonctionnel (en C#), tout est dispo sur mon blog en abondonware. Si tu veux le reprendre et le faire évoluer, ca serait avec plaisir.

Mais honnetement, un Logic, et ca roule ...

Thomas.

[EDIT] Par contre je te pique l'idée de la mise à jour soft pour un projet, j'espere que tu ne m'en voudras pas, ca fait longtemps que j'y pensais, et de voir le tiens m'a donné la motivation pour l'implémenter.

[Black Templar]

Salut,

Ou sinon, tu arretes de couper les cheveux en 4, tu t'achetes un Saleae Logic, et tu gagnes des jours de capillotractage en règle.
Ce truc est juste un cadeau du ciel, ca m'a sauve des heures et des heures et des heures de "mais p**ain pourquoi ca marche pas !".

Certes, mais ce n'est plus marrant du coup ! Je préfère réinventer le fil à couper le beurre
Et puis, si je fais ça (outre le fait d'avoir un oscillo), c'est de pouvoir apprendre des choses que je n'ai jamais eu le courage d'étudier (téléchargement de fichier, parsage XML, gestion d'une base de donnée avec Qt, gestion de plugins, etc.)

Pour en revenir à ton projet, j'ai peut etre quelque chose à te proposer ... selon tes besoins. Si tu fais uniquement du numérique (ton problème d'origine portait sur de l'I2C), j'avais commencé a concevoir un "Saleae Logic like" sur base de FT2232H, maintenant le FT232H est disponible.

Le principe est tout con, on utilise le bit bang mode pour échantillonner à une fréquence donnée.

J'ai déjà un logiciel plus ou moins fonctionnel (en C#), tout est dispo sur mon blog en abondonware. Si tu veux le reprendre et le faire évoluer, ca serait avec plaisir.

Mais honnetement, un Logic, et ca roule ...

Attention, mon projet n'a pas pour origine des difficultés avec l'I2C ! Je fais cet oscillo pour bel et bien analyser des signaux analogiques ! (rien à voir avec mon problème d'I2C sur mon projet de centrale inertielle)
Le titre peut en effet porter à confusion... oscilloscope numérique, c'était juste pour dire que je ne voulais pas réaliser un oscillo analogique avec un canon à électron ou écran de phosphore mais plutôt un logiciel qui traiterait informatiquement le signal...

[EDIT] Par contre je te pique l'idée de la mise à jour soft pour un projet, j'espere que tu ne m'en voudras pas, ca fait longtemps que j'y pensais, et de voir le tiens m'a donné la motivation pour l'implémenter.

Bien sûr, c'est pour ça que je distribue le code source !!
J'ai déjà prévu dans le XML des champs de hachage pour vérifier que le téléchargement s'est bien passé. J'aimerais aussi à terme compresser les fichiers téléchargés (en gz ou autre) afin de limiter la taille des fichier à télécharger.
Enfin, j'ai pensé (après avoir réalisé le logiciel) faire un utilitaire pour que quelqu'un qui souhaite développer un plugin ou des drivers pour le logiciel puisse automatiquement fournir les nouvelles versions du plugin sur mon site directement (et donc, j'ai pensé à crypte les fichiers avec un RSA like afin que n'importe qui ne puisse pas fournir une nouvelle version du plugin s'il n'est pas identifié en tant qu'auteur de celui-ci)


++
Black Templar

[Otatiaro]

Salut,

Ok alors ton besoin est un peu différent, mais commences par regarder, il y a d'autres projets du même genre en open source.

Sinon pour la gestion de mise à jour, je n'ai jamais utilisé et n'utiliserais certainement jamais Qt. En fait j'ai déjà un framework qui va chercher des fichiers (cryptés mais je ne peux pas donner le nom de l'algo, dsl ...) et les télécharges via WFC (Windows Communication Foundation).

Avec .NET tout est beaucoup plus simple ...
- Entity Framework me permet de faire ma base de données en 5min,
- Ensuite un coup de LightSwitch et en 1 heure j'ai mon appli pour gérer entièrement la base de données,
- De là, un service WCF qui expose des méthodes de téléchargement de fichiers via HTTP ou HTTPS pour la sécurité,
- Et je me contente de charger mes assemblies téléchargées à la volée.

Thomas.