La société britannique Pico Technology produit des oscilloscopes numériques, data logger et autres accessoires de mesure. Dans leur catalogue d'entrée de gamme, on trouve quelques petits oscilloscopes alimentés par USB à des tarifs très abordables et aux performances suffisantes pour le passionné.
Ce qui les distingue de la concurrence est que cette société annonce le support de Linux pour leur produit. C'était d'ailleurs ce qui avait guidé mon choix il a quelques années de cela. Mais j'avais vite déchanté, car en guise de support je n'avais eu que les drivers et un fichier d’entête h !
Leur logiciel de visualisation PicoScope n'était disponible que pour les plate-formes Windows et Mac OS. Certes, cela aurait pu être le début d'un projet de développement logiciel, mais c'est un peu contrariant pour un usage immédiat du produit.
Je viens de refaire un tour sur le site et, ô surprise, sur la page des téléchargements pour Linux on trouve désormais un lien vers les versions Linux de PicoScope.
Et on peut y lire :
Demand for Linux applications is growing steadily in the networking and scientific communities. Linux offers powerful networking and internet facilities, is very robust and there are no licence fees.
Certes ce n'est pas du logiciel libre et encore moins du matériel libre, mais c'est une bonne nouvelle pour la communauté.
PicoScope pour Linux est distribué sous forme de dépot deb, zypper et yum. Le logiciel est encore en version en version Bêta, et j'ai pu constaté quelques régressions par rapport à la versions Windows. Gageons que tout n'a pas encore été porté. Mais l'essentiel y est. Vous pouvez vous faire une idée des fonctionnalités en installant le logiciel (gratuit) sur votre machine. Il simulera l'oscilloscope en son absence.
# bitscope
Posté par Richard Genoud . Évalué à 5.
de mémoire, il y a aussi bitscope qui fait des oscillos et analyseurs logiques avec des softs pour GNU/Linux (et même raspbian)
[^] # Re: bitscope
Posté par binoyte . Évalué à 1.
Intéressant. Je ne connaissais pas.
J'ai rapidement regardé leur catalogue, ça n' a pas l'air de faire un doublon trop frontal avec les picoscopes en terme de prix et de fonctionnalités. Pour le raspberry pi, effectivement là, ça peut faire une différence vu le succès ce petit ordi. Chez pico il n'y a que certains data logger à avoir la chance d'être supportés pour le Pi.
# DSO Nano
Posté par Gauthier Monserand (site web personnel) . Évalué à 4.
J'ai pour ma part un DSO v2, c'est tout simplement génial pour le reverse "grand public", je l'avais utilisé pour la télécommande de mes volets. Cela sort un fichier XML sur une carte SD, donc très facile à utiliser sous linux.
http://www.seeedstudio.com/depot/DSO-Nano-v3-p-1358.html?cPath=63_65
Ah, j'oubliai , accessoirement ;), c'est libre !
Il existe aussi ça mais je n'ai pas testé :
http://www.seeedstudio.com/depot/DSCope-p-2424.html?cPath=63_65
[^] # Re: DSO Nano
Posté par Gauthier Monserand (site web personnel) . Évalué à 3.
Ça va tellement vite qu'on en oublie les nouveautés :
http://www.seeedstudio.com/depot/Xminilab-Portable-p-2469.html?ref=newInBazaar
Libre et Linux aussi
# EEVblog
Posté par max22 . Évalué à 10.
Dave Jones a dit Buy a real Analog Oscilloscope PLEASE!.
Pour ceux qui connaissent pas, Dave Jones c'est le youtubeur de l'électronique. Pour résumer, il dit que les oscillos USB c'est des "piece of shit", qu'on peut avoir pour le même prix un oscilloscope analogique qui ne sera pas un jouet.
Il n'est pas complètement faché avec ce genre d'oscillo quand même. Par exemple : une autre vidéo qui date un peu : EEVblog #13 Part 2 of 2 - Comparison of PC Based Oscilloscopes
voilà voilà, c'était juste histoire de parler de Dave Jones car il fait des vidéos intéressantes, en particulier une sur les ampli op qui m'a permis de bien comprendre comment ça marche.
Sinon, si vous voulez acheter un oscilloscope et que vous êtes mariés, j'ai la vidéo qu'il vous faut, idéale pour un vendredi :
NEW TOOLS - How to buy even AFTER you're married.
[^] # Re: EEVblog
Posté par zurvan . Évalué à 2.
On peut faire des trucs sympa avec un oscilloscope quand on y pense, comme dessiner des images avec de la musique !
https://www.youtube.com/watch?v=rtR63-ecUNo
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Plein d'autres alternatives
Posté par freejeff . Évalué à 10.
Salut,
j'ai passé pas mal de temps à regarder ce qui se fait en solution de mesure de signaux, je vais donc en profiter pour te donner mon opinion.
Tout d'abord, rien n'est ouvert dans PicoScope, c'est dommage sachant que des alternatives libre existent dans tous les domaines.
Pour moi il faut discriminer deux usages :
* la mesure de signaux analogiques,
* la mesure de signaux numériques,
Je ne suis pas un spécialiste de mesures numériques donc je laisse cela à d'autres. Pour la mesure de signaux analogiques il faut savoir quelle est la fréquence que tu vises mais également la résolution que tu souhaites avoir.
Dans notre cas au boulot, nous n'avons que rarement besoin de dépasser les 2kHz, donc il est possible de tout traiter à la volée sans buffers internes sur la carte. Si tu es dans ce cas de figure alors le moyen OpenSource le plus simple est d'utiliser les usbdux car elles sont basées sur les drivers comedi que l'on trouve facilement dans les dépôts de la plupart des distributions. Il existe une interface pour la visualisation sommaire et l'enregistrement appelée comedirecord, maintenu par Bernd Porr (qui a conçu les usbdux). La version sigma de l'usbdux permet de mesure 16 voix en 24 bits à 1kHz ou 8 voix à 2kHz ou 1 voix à 4kHz. Ça commence à être raisonnable pour une carte à 500€. Il est par contre nécessaire de faire un montage adaptateur de tension pour se mettre dans les gammes qui t'intéressent.
Si tu veux aller plus vite il existe la usbdux fast qui permet d'aller en 12 bits jusqu'à 1MHz en continu et prendre 256 échantillons à 30MHz ce qui commence à être très correct. Elle coûte le même prix. Si on accepte le fait de devoir faire une adaptation de tension alors c'est clairement ce qu'il y a de mieux sous linux.
Il existe aussi les labjacks
qui ne sont pas trop chères et permettent de faire pas mal de choses, j'en avais utilisées en 2009 et franchement c'était pas mal mais une latence de 10 ms pour l'envoie des commandes m'avait découragée. Je n'ai pas réessayé depuis. Ils ont des drivers python pour l'usb et l'ethernet (pas essayé le wifi) mais ce n'est plus comedi
Un kickstarter complètement hallucinant a réussi. Je n'ai pas encore essayé (commandes publique toussa …) le budget est bien plus élevé mais les performances annoncées sont proprement géniales. API en java pas compatible avec comedi.
Les gens du CERN ont aussi fait pas mal avancé les choses avec des cartes PCIe avec des FPGA ou des firmwares pour différentes cartes filles sont disponibles. Devant géré des parcs de cartes énormes ils ont trouvé des défaut majeurs par rapport à leur problématiques dans comedi ils ont développé ZIO mais ça ne bouge plus trop depuis 2013 et c'est un module noyau à compiler donc plus complexe …
Tu peux aussi te diriger si tu n'as pas besoin de vitesse vers des solutions de type multimètre de labo de chez agilent, l'intérêt réside dans le fait que quelque soit l'interface : GPIB, usb, ethernet tu peux leru parler via des commandes ascii en SCPI ou via une interface de plus haut niveau telle que VISA. Il existe d'ailleurs une très bonne lib en python pour faire ça PyVisa qui peut être utilisée depuis peu sans le backend de National Instrument. On a essayé et on en est très content, on a réussi à refaire fonctionner un générateur de tension/courant grâce à ce protocole.
Récemment, National Instrument à mis en place un système avec un linux temps réel CompactRio Mais là faut vraiment être très riche, de plus ce n'est pas une debian-like mais plutôt un OpenWRT ce qui ne facilite pas l'installation d'outils de type numpy,matplotlib ou scilab pour une acquisition simple sans labview …
Si tu es complètement fauché tu peux arriver à de très bons résultats avec des micro-contrôleur, le plus sympa de part ces 16 bits est son faible prix est Teensy. Cela peut demander de coder un peu et de souder mais tu peux te simplifier la vie en installant un code qui te permettra de communiquer avec la carte depuis un PC sans avoir à trop faire de code.
Sans compter tout ce que tu peux trouver sur seeedstudio qui sont pour la plupart compatible linux.
Donc franchement, je ne vois pas pourquoi aller chez pico et leur code proprio qui semble bien bogué de ce que l'on peut en lire sur les forums !
[^] # Re: Plein d'autres alternatives
Posté par briaeros007 . Évalué à 7.
500€ pour un truc qui monte jusqu'à 4khz maxi , ou 2khz sur 2 canaux?
Le moindre bus un peu courant (i2c, spi, …) le rend inutile.
open logic sniffer (bus pirate étant plus spécialisé sur la lecture des bus courant) ou alors "sump project" pour une solution "a bas cout" , me semble bien plus raisonnable.
(On est dans l'ordre du Mhz, voir au dessus, pour un cout de 60-70€. - 100€ pour sump
Demande aussi une adaptation du voltage si pas compatible avec la carte)
[^] # Re: Plein d'autres alternatives
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
… mais on est en numérique.
Pour un signal analogique sur 24 bits, il faut de l'électronique propre pour ne pas avoir d'interférences sur le signal. Composants de qualité, une carte conçue pour pas avoir d'interférences, en particulier des signaux USB qui sont juste à côté, etc.
Effectivement, en numérique on peut utiliser un analyseur logique (pas un oscilloscope), et là on peut monter en fréquence sans trop de problèmes.
[^] # Re: Plein d'autres alternatives
Posté par Fabien PRORIOL . Évalué à 5.
Plutôt que Teensy, pensez a regarder les ST Nucleo…
Pour une dizaine d'euro on a du 32bit jusqu'a 84MHz (pour les F4), autour de 50 GPIOs, possibilité d'avoir environ 20 PWM sur les F401, et 16 voix sur un ADC 16bit de bonne qualité… y'a même un DAC sur certaine…
Je quoi qu'il y aurait de quoi faire un jolie petit oscillo avec
De quoi mettre les Arduino et Teensy au placard…
[^] # Re: Plein d'autres alternatives
Posté par freejeff . Évalué à 2.
C'est vrai que ça à l'air sympa mais il n'ont pas fait l'effort d'avoir une interface arduino-like non ?
C'est pour cela que la teensy est sympa, il n'y a presque rien à changer sur l'énorme base de Code disponible !
[^] # Re: Plein d'autres alternatives
Posté par flagos . Évalué à 2.
Pour la nucleo, il est possible de programmer depuis l'IDE en ligne mbed. J'ai pas testé si derrière il fallait forcément avoir du windows mais sinon ça marche vraiment de manière très simple.
En te promenant sur le site, il devrait y avoir moyen de trouver des exemples de codes qui répondent au besoin.
[^] # Re: Plein d'autres alternatives
Posté par briaeros007 . Évalué à 2.
Il y a stm32duino, mais pour être franc, la dernière fois que j'ai essayé ce n'était pas super stables sur mes deux trois examples.
# Super !
Posté par Philippe GRAILLE . Évalué à 3.
petit retour d'expérience :
J’utilise depuis plusieurs années la gamme Picoscope 3000 et j'en suis très satisfait !
Le matériel est stable, le calibrage bon, le logiciel excellent et en perpétuelle évolution.
Version Linux, Windows et API qui permet même de programmer des outils de tests.
Il y a aussi un logiciel de capture de mesures (enregistreur) pour des mesures de phénomènes lents.
Je m'en sert par exemple pour monitorer des courbes de charges décharges de batteries.
J'ai eu une fois un problème hard sur un modèle hors garantie (> 3ans) et ils me l'on quand même réparé gratuitement. Super service.
Et depuis peu il y a même une version Raspberry (je n'ai pas pris le temps de l'essayer mais cela peut être intéressant pour ne pas mobiliser un PC par exemple)
Personnellement je recommande.
Je préfère l'utiliser avec mon PC plutôt que d'utiliser le Fluke Scopemeter
En plus les captures d'écrans pour le coup deviennent triviales et cela permet de faire des dossiers bétons :)
# Sigrok?
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
Est-ce supporte par Sigrok?
# Picoscope ou pas ?
Posté par colonel . Évalué à 1.
Bonjour à tous,
je suis dans l'electronique depuis 10 ans , j'ai pu utiliser pas mal d'oscillos, par exemple les vieux Hameg sans mémoire, les HP 54600 mixtes, les metrix OX8042 (mixte) le HP54622A etc…
Effectivement pour l'analogique pas besoin d'une grande bande passante, 100 K ça suffit, mais on est vite "bloqué" : horloges etc, dès qu'il y a du numérique … et il y en a partout !
J'ai fait pas mal d'amplis à tubes, et du coup mes vieux tromblons du style HP54600 c'était top pour voir les montées d'alim etc !
Ce qui est important aussi c'est de voir l'historique des signaux !
J'ai bossé sur un grand nombre de scopes, en voici un résumé :
Ce qui me semble important (très important) c'est la mémoire ! je distingue 3 niveaux :
1 - aucune genre les vieux hamegs, et on se rends vite compte qu'on est bloqué. On peut aussi voir les philips PM3200, (je compte ici les mémoires à persistance aussi genre TDS 2445)
2 - mémoire d'affichage : c'est à dire qu'on mémorise juste l'affichage et non les datas -> pas de zoom possible. Genre HP54600, 0X8042 … TDS340 … bien ! ça permet de voir les glitches et de "comparer" mais sans plus.
3 - mémoire data : ultime ! par ex HP54622A : on fait une acqui pendant 1 s et on met stop, puis par magie on zoom et on voit tout, les fronts montants, les parasites etc.. extrêmement partique pour les liaisons numériques. Agilent appelait ça le "méga zoom".
Autre point : glitch detect : sur les bon scopes l'acqui est à pleine balle, et la data collectée est le min et le max de la période, exemple : si on fait une acqui à 1Ks/ seconde le scope fait l'acqui à 10Ms/ sec puis enregistre tous les 1000 / seconde le min et le max qui devient l'échantillon.
La ou c'est utile : prennons le tektronix 1012 avec un signal en entrée qui a une impulsion de 10ns toutes les 100ms -> si on veut voir sur 500ms ce qui se passe on verra rien -> il faut diminuer la base de temps pour triger et la on voit que 100ns à l'écran. Si un signal lent est perturbé par ce glitch on voit rien.
C'est pas le cas sur le Hp54622A et le HP54600 et le picoscope.
Impact : les glitch qui perturbent les amplis, les datas et les horloges…
J'avais testé le bitscope, c'est un bon produit si on ne veut pas trop pousser, si on veut juste voir les formes d'ondes.
Le DSO nano semble pas mal ! et surtout il est portable ce qui peut être très pratique ! par contre mémoire de 4K points alors que le picoscope pour le meme prix c'est 8 k points.
Pour un prix presque identique on a l'entrée de gamme chez picoscope : le 2204A pour 100€ et on a accès au soft Picoscope.
Je m'explique : avec ce modèle d'entrée de gamme on peut quand meme faire l'acquisition et zoomer, puis utiliser la "puissance" du sw piscope (cf plus bas). On peut aussi décoder les protocoles (sur windows)
Pour info j'avait acheté celui la pour voir puis j'ai pris le 3403 (qui m'a couté un bras mais qui en vaut vraiment le coup)
Sur le soft pico : je veux pas faire de la pub, mais les boites qui font des softs linux ben … dans la mesure ça court pas les rues !
Il est pourtant très bien fait, on peut sauvegarder les acqui, zoomer, faire des fft, plusieurs fenetres en meme temps, fonctions mathématiques … bref… on conserve les acquis de validation et au besoin on les rouvre et on peut zommer etc comme si on venait de la faire !
et sur windows (snif seulement) décodage de quasi tous les protocoles : I2C, SPI, CAN etc !
Si vous souhaitez télécharger le soft et il vous mettra un scope virtuel (donc pas besoin d'acheter pour voir)
Note : sur un protocole I2C par ex sans oscillo avec le niveau 3 on est quasi mort pour trouver la source des pbs de com…
Cas pratiques :
1 - problème de com avec un MRF49XA : la com plantait rarement, et lorsqu'elle le faisait le chip émettait non stop, et ne répondait plus (vu sur un analyzeur de spectre). Du coup vérification des fronts d'horloge : on trig sur des temps bas qui ne sont pas dans les bornes '(trop courts ou trop rapides) → rien. On check la data de la même manière (est-ce qu'il y a kk1 qui met la broche à 1?) rien. Puis on refait la meme chose avec les temps entre les chip select → et la on trouve rien.
Puis on se place devant l'analyseur de spectre, picoscope en mode acqui lente (période de 2 s) et on attends que ça plante → on mets stop et on zoom pour analysez tous les échanges → on trouve qu'on a pas assez attendu entre deux échanges (bug sw embarqué), et ça fait planter le chip.
Sans oscillo de niveau 3 c'était mort.
Note : meme un reset brutal du chip avec la broche RST ne le remettait pas sur pied !!
Dans la même série on voit une data qui remonte trop tôt, la broche a été pilotée par kk1 d'autre et causait des problèmes d'affichage !
Conclusion : les triggers avancés on s'en occupe pas, mais lorsqu'il y a un problème ça sert vraiment !
Sur le HP54622A on peut triger sur des valeurs I2C, CAN, SPI, sur des séquences de bits, sur le picoscope aussi, même avec l'entrée de gamme !
Autre chose : générateur de fréquence, sur l'entrée de gamme il est aussi dispo, on peut générer les créneaux, sinus, rampes, ou une forme capturée d'une voie, ou une forme issue d'un CSV… bref c'est … bluffant ! Sur les DSO nano il y a aussi les générateurs de signaux !
Encore, je ne suis pas maqué avec pico, mais ils ont fait du super taf et vivement qu'ils fassent débarquer les décodages de protocole sur la version linux !
autre note : bien sur on a toutes les mesures automatiques sur le soft, c'était bien pratique sur les HP54600, 54622 et sur le Tektronix 2445 !!
Encore une note : je suis pas trop partisant des scopes comme le DSO nano, mais faut dire que pour la bête les prestations semblent être intéressantes (même si il y a des manques comme la mémoire) et je n'ai pas pu le tester !
et encore : il y a pas mal de vidéos sur youtube pour les DSO nano et les picoscope, faites vous en une idée !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.