QtZenOscillo
Hardware
Ce logiciel s'adresse à ceux qui possède, comme moi, un oscilloscope USB numérique HANTEK ou VOLTCRAFT DSO-2020, et qui veulent le faire fonctionner sous linux.
Firmwares : getFirmFromDriver
Comme je n'ai sans doute pas le droit de mettre les firmwares du fabriquant dans le pack logiciel, j'ai codé un logiciel qui permet de récupérer ceux-ci depuis les drivers fournis par le fabriquant. Il se peut toutefois que suite à une mise à jour de ces derniers, ce logiciel traducteur ne soit plus en mesure de fonctionner. Dans ce cas, ne pas hésiter à m'envoyer un mail à code@zener.fr
Le logiciel traducteur fabriquera deux firmwares. En effet, le premier appelé 'loader' permet juste de charger le second 'firmware'. Le même fonctionnement est utilisé sous windows, et est une conséquence du composant utilisé dans le périphérique.
Une règle udev est fournie pour charger automatiquement ces firmwares lorsque l'on connecte le matériel.
Logiciel graphique : qtZenOscillo
Le logiciel graphique est basé sur Qt, et permet une utilisation de base de l'oscilloscope.
On retrouve les réglages classiques d'un oscillo, avec cependant quelques ajouts :
Le logiciel est conçu de manière à ce que la plupart des fonctions puissent fonctionner offline. Cela veut dire que l'utilisateur peut, par exemple, changer la valeur du Trigger après coup, lorsque le logiciel est en mode Stop. Par contre, pour des raisons évidentes, le changement du Range que chaque canal ne peut être appliqué offline.
Il s'agit de la toute première version, que je distribue car je pense qu'il est désormais utilisable (et je l'utilise). Il est toutefois clair qu'il manque encore de maturité !
Téléchargement
V1.0
Les sources 1.0 sont téléchargeables ici : qtZenOscillo_1_0.tar.gz
V1.1
Ajout du scroll et du oneshot : qtZenOscillo_1_1.tar.gz
Reverse Engineering sur le DSO2020
Pour pouvoir coder un logiciel qui exploite le DSO-2020 sous linux, il a fallu d'abord faire un peu de reverse-engineering par rapport à la version windows (pas de désassemblage pour celui-ci, je vous rassure).
Cette fois, j'ai mis le reverse sur le site, car ça n'arrive pas souvent d'avoir autant de surprises. Lisez la suite, vous comprendrez :-)
Firmwares
Les premiers éléments à récupérer étaient les firmwares. Il était évident qu'ils se situaient dans le driver, il fallait juste trouver où et comment étaient stockées ces données.
Un premier problème s'est posé : les symboles ont été strippés (ça arrive qu'ils ne le soient pas, et ça aide bien !).
En sniffant ce qui se passe sur l'usb lorsqu'on connecte le périphérique sous windows, j'ai récupéré les deux firmwares. Seul problème : je ne pouvais pas les distribuer. Cependant, ceci va me servir pour trouver où se trouvent les données dans le driver fabriquant.
Maintenant que je sait où trouver les données, je sais aussi les décoder, et il ne me reste plus qu'à chercher un méthode 'propre' qui puisse s'adapter à de futures versions du driver.
Pour que le tout soit plus 'standard' et propre, j'utilise la bibliothèque bfd qui permet d'avoir déjà l'adresse de la section data.
Il ne reste plus qu'à exporter le tout au format intel hex et le tour est joué!
Pour ceux que ça interresse, tout est dans le source, dans le repertoire utils...
Commandes Oscilloscope
Maintenant que le matériel est prêt, il faut trouver les commandes vendor usb qui permettront de commander le matériel.
Pour cela, il suffit de sniffer l'usb (sous windows : usbcap et wireshark par exemple), et pour chaque modification sur l'ihm, examiner les données qui sont envoyées à l'oscilloscope.
C'est à ce moment là que je m'apperçois que le matériel ne fait vraiment pas grand chose, et que finalement, il ne suffira pas de juste recevoir un bulk et de l'afficher !
Pour que vous puissiez en Juger par vous même, voici le tableau :
ET C'EST TOUT !!!
Déjà, quelque chose nous choque : les fréquences d'échantillonnage. Comment arrivent-ils à avoir une courbe à 1ns/div avec une fréquence d'échantillonnage de 48MHz (ça fait 21ns par échantillon) ?!
Vu le faible nombre de fréquences d'échantillonnage différentes, ça semble prometteur pour le logiciel (va y avoir du garbage, mon gars) !
Quand aux ranges de 5000s/div, sincèrement, je ne vois vraiment pas à quoi ça peut servir (autant prendre un multimètre). Puis il faut être plutôt patient avant d'avoir un affichage (5000s*10=>50000s, soit presque 14h ! )
Autre chose : les ranges 20mV et 100mV sont les mêmes : sur du 8 bits, ça va piquer les yeux...
Et puis la question ultime : IL EST OU LE TRIGGER ? (je comprends mieux pourquoi le logiciel fourni par le fabriquant n'arrivait jamais à trigger...)
OK, le trigger, il sera dans le soft alors...
Finalement, il ne reste plus qu'à analyser le bulk pour savoir ce que le matériel nous envoie : la taille du bulk est variable, j'utiliserais les mêmes tailles que celles utilisées dans le soft du fabriquant pour ne pas avoir de soucis. (pour ceux qui veulent connaître les tailles, voir les sources...)
Les données reçues depuis le bulk sont entrelacées (logique, là, j'aurais fait pareil), et ne sont pas signées (0->minimum, 255->maximum).
Une fois tout ce bazar maîtrisé, il ne reste plus qu'à coder !
Lenteurs dues aux grosses tailles des bulks
Comme les tailles de données sont assez conséquentes, l'affichage ne s'effectue pas rapidement (100ms d'échantillonnage, ça se sent).
Pour cela, j'ai ajouté le mode Fast, qui permet la reception d'un minimum d'échantillons necessaire à l'affichage.
Par contre, du coup, on perd le Trigger, car il faut plus d'échantillons que l'affichage pour que celui-ci soit efficace.
Problèmes de buffers
Autre problème, il s'avère que les courbes ne sont pas correctes à partir de le vitesse de 2us/div sur mon ordinateur.
En regardant de plus près, il semble de des bouts de courbes viennent écraser les données dans ce cas.
En ajoutant expérimentalement un délai entre le lancement de l'échantillonage et la réception du bulk, ce phénomène se produit sur des vitesses moins rapides...
On peut donc en déduire que l'échantillonnage écrase les données lorsqu'on ne les lit pas assez rapidement !
Je suis donc actuellement à la recherche d'une solution palliative (un workaround) à ce problème, que je n'ai toujours pas réussi à régler (surtout que rien n'indique apparemment que ces données sont invalides).
VOILA, THAT'S ALL, FOLKS !
Pour ceux qui voudraient avoir plus de précisions, n'hésitez pas à m'envoyer un mail à code@zener.fr