Pi est-il assez puissant pour un projet d'oscilloscope?

Mon objectif est de fabriquer des instruments basés sur Pi, à commencer par un oscilloscope. J'ai donc lu les réponses à

• Quels convertisseurs analogique-numérique sont disponibles pour RPI?
• Comment puis-je connecter un convertisseur analogique-numérique (ADC)?

Il semble possible de lire des entrées analogiques à des taux d'échantillonnage très faibles, mais je me demande si je pourrais atteindre des taux de méga-échantillons par seconde. L'acquisition continue de données serait probablement difficile, si possible, donc je peux m'en passer. Pi serait-il sous-équipé pour cela? Je veux d'abord observer les formes d'onde sur les écrans connectés à Pi, puis sur mes appareils mobiles (tandis que Pi leur transmet des données sans fil).

Mon expérience avec le système sur puces me dit que ces systèmes peuvent facilement saturer les E / S continues. Est-ce aussi le cas pour Pi?

Ayons un aperçu de haut niveau de ce qu'un oscilloscope a:

Nous avons d'abord le frontal analogique. Ici, nous avons un réseau d'adaptation d'impédance pour les sondes (mais les sondes devront également avoir une partie d'adaptation de capacité), une section d'atténuation (très importante, donc nous ne surchargeons pas l'ADC ou ne laissons pas de hautes tensions), le déclenchement et la connexion à Convertisseur analogique-numérique. Je n'en parlerai pas trop, car je ne suis pas trop bon avec les trucs analogiques, mais le résultat est: il n'y a rien que nous puissions faire avec Pi dans cette section.

Ensuite, nous avons la partie convertisseur analogique-numérique. Vous aurez besoin d'au moins un ADC pour chaque canal. Plus peut être utilisé pour un taux d'échantillonnage plus élevé. Dans la portée traditionnelle, l'ADC est connecté à un périphérique ASIC ou FPGA. Ils sont utilisés parce que les ordinateurs traditionnels ne sont pas assez en temps réel (et ne confondez pas en temps réel et rapide!) Pour traiter les données fournies par l'ADC. Ces données sont ensuite stockées dans la RAM d'une sorte. Certains appareils utiliseront la RAM statique, tandis que d'autres utiliseront la RAM dynamique. En général, l'approche SRAM est plus traditionnelle et observée chez les grands fabricants, tandis que l'utilisation de la DRAM semble être la nouvelle approche observée dans les unités de conception chinoise moins chères.

La quantité de RAM et sa vitesse détermineront le nombre d'échantillons pouvant être stockés. L'ADC sera presque toujours un ADC 8 bits, donc pour un méga-exemple, nous aurons besoin de 8 b fois 100000 = 8 Mo ou 1 Mo de RAM. Pour un MSa / s, nous aurons besoin de RAM qui peut fonctionner à cette vitesse. Aujourd'hui, cela devrait être relativement facile à obtenir. Le FPGA pilote généralement la RAM directement et est responsable du stockage des données qu'il contient. Cela fonctionne en remplissant l'échantillon de mémoire alors qu'il y a encore de la place vide et en le remplaçant quand il est plein. Lorsqu'il y a plusieurs ADC par canal, le FPGA les réglera de sorte que commence d'abord l'échantillonnage, puis la seconde d'horloge suivante et ainsi de suite. Une fois l'échantillonnage terminé, l'échantillon du premier ADC sera d'abord enregistré dans la mémoire, puis l'échantillon du second ADC. Cela donnera l'impression que les ADC échantillonnent plus rapidement qu'ils ne le sont vraiment.

Le point suivant de cette section est que les échantillons doivent être équidistants dans le temps. C'est le principal problème avec l'utilisation des PC dans les oscilloscopes et la raison pour laquelle les FPGA et les ASIC sont prédominants. Si certains échantillons sont en retard ou en avance, l'image représentée à l'écran sera incorrecte.

Dans cette partie, nous voyons la première utilisation possible du Pi. Si le taux d'échantillonnage est suffisamment faible, nous pourrions être en mesure de piloter les ADC directement à partir du Pi et de stocker leurs résultats dans la RAM du Pi. La vitesse à laquelle nous pouvons aller dépend de la façon dont l'ADC est connecté au Pi et de la manière dont Pi effectue ses E / S. D'après ce que j'ai lu, la vitesse la plus élevée des ports I ^ 2C de Pi est de 150 MHz (combien cela serait facile à réaliser dans GNU / Linux est une autre question) tandis que la vitesse standardisée la plus élevée est de 5 MHz et pour SPI la vitesse la plus élevée dans Pi est de 250 MHz. Je ne sais pas quelle est la vitesse standard la plus élevée de SPI, mais je m'attends à ce qu'elle soit quelque part dans la plage de 100 MHz au maximum.

Donc, en théorie, nous avons plus de suffisamment de vitesse sur Pi pour exécuter un ADC dans une plage MSa / s faible. J'ai le sentiment que la vitesse de la RAM ne sera pas un problème ici, mais je n'ai pas de données pour le sauvegarder. Si tel est le cas, nous aurions alors un avantage majeur par rapport aux étendues habituelles: il y aurait une très grande quantité de mémoire de capture disponible. Par exemple, si nous consacrons 32 Mo de RAM au programme de mémoire d'échantillonnage et que nous avons deux canaux, cela nous laisserait 16 Mo pour chaque canal ou un peu plus de 134 Mo ou 134 méga-échantillons par canal. C'est quelque chose que de nombreux oscilloscopes n'ont pas encore aujourd'hui.

L'inconvénient est que nous aurions besoin de lourdes modifications du système d'exploitation afin de pouvoir obtenir un échantillonnage précis ici. Je n'ai aucune expérience avec Linux en temps réel, donc je ne sais pas à quel point ce serait facile.

Quoi qu'il en soit, passons à l'étape suivante. Nous avons donc un système d'échantillonnage qui remplit la RAM. La partie suivante est le déclencheur. Le déclencheur est étroitement lié au taux de rafraîchissement de l'écran. Ce qu'il fait, c'est de trouver un échantillon intéressant et de le garder en mémoire. Lorsque l'oscilloscope se déclenche, il continue l'échantillonnage après le déclenchement jusqu'à ce qu'il ait rempli la mémoire, puis il l'envoie pour être traité et affiché à l'écran. Pendant le traitement des données, le système d'échantillonnage est souvent gelé et en attente d'affichage des données. C'est pourquoi les étendues bas de gamme ont des taux de rafraîchissement inférieurs tandis que les étendues haut de gamme auront des affichages spéciaux à taux de rafraîchissement élevé et passent beaucoup moins de temps à attendre que les données soient affichées.

Dans cette section, il y aura souvent un autre ASIC ou FPGA qui effectuera le traitement du signal sur les échantillons, tout décodage de protocole si la portée le prend en charge et pilotant réellement l'affichage lui-même.

C'est la partie où d'après ce que je peux voir, le Pi peut vraiment briller. Il peut piloter un bel écran 1920x1080 (alors que les portées sont souvent dans le sous-pays 800x600) et peut très bien décoder le protocole. Le seul problème que je peux voir serait la vitesse et l'impact du traitement sur le temps d'attente. Si nous optons pour un faible taux de rafraîchissement, nous pouvons obtenir un très bon analyseur logique avec.

Enfin un mot sur les oscilloscopes USB et pourquoi l'USB est mauvais en général pour ce type de projet: l'oscilloscope USB traditionnel effectue la saisie et l'échantillonnage et envoie les données d'échantillonnage au PC pour le traitement pour lequel une application hôte existe. Fondamentalement, quelque chose de très similaire serait également fait avec Pi. Habituellement, les applications PC sont mal conçues et pleines de bugs. La mauvaise partie suivante est l'USB lui-même. Il est annoncé comme un bus rapide qui peut faire 480 Mb / s en mode "Hi-Speed". La vérité est qu'il est extrêmement rare de trouver un contrôleur USB capable de supporter des vitesses aussi élevées (la moyenne semble être d'environ 250 Mb / s d'après ce que j'ai vu) et que ce protocole n'est pas très adapté à tout réel -application de temps. Tout d'abord, il est partagé entre tous les appareils sur un concentrateur (et Pi n'a qu'un seul port USB auquel Ethernet + concentrateur USB est connecté), a un temps système relativement élevé (par rapport au SPI, par exemple) et une latence élevée (rappelez-vous qu'à 1 MSa / s, chaque échantillon ne dure que 1 µs, nous devons donc avoir de la mémoire sur notre carte car nous ne pouvons pas envoyer d'échantillons en temps réel via USB). Enfin, l'utilisation de l'USB ferait de la partie d'acquisition de données la possibilité d'être un autre oscilloscope USB et c'est là que nous perdons tout avantage d'utiliser Pi: ​​les ordinateurs de bureau traditionnels sont beaucoup plus courants, plus rapides, plus faciles à obtenir et ont de bien meilleures capacités USB.

EDIT J'ai lu relativement récent message par Gert van Loo et selon lui, les taux réalistes pour I ^ 2C Pi sont 400 kHz et SPI sont 20 MHz.

Nous avons trouvé que le Raspberry Pi était une excellente plate-forme pour exécuter le logiciel dont vous auriez besoin pour un projet comme celui-ci. Le problème consiste à obtenir les signaux dans le RPi en premier lieu et à effectuer une capture de signal en temps réel sans gigue à haute vitesse sur le même processeur qui exécute le logiciel d'exploitation et d'application. Notre solution est l' oscilloscope BitScope Raspberry Pi qui associe un BitScope (pour la capture de forme d'onde de signal mixte à haute vitesse) avec le Raspberry Pi qui exécute tous les logiciels nécessaires.

NB: Il s'agit plus d'un texte «penser à haute voix» que d'une vraie réponse

L'idée m'a aussi traversé l'esprit il y a quelque temps, et j'aime toujours l'idée générale!

Pour autant que je sache, les oscilloscopes haut de gamme sont depuis 15 ans (ou même plus) uniquement des ordinateurs (PC) avec un tas d'E / S haute vitesse spécialisées. Je pense que lorsque des E / S similaires sont conçues / connectées au RPi, le résultat peut être surprenant.

À mon humble avis, un bon moyen de le faire est de laisser le RPi simplement stocker et afficher les données collectées (reçues par exemple sur le port USB) et laisser un matériel spécialisé effectuer la mesure à grande vitesse. Cette unité de mesure à grande vitesse peut alors également être contrôlée par le RPi en fonction de l'entrée de l'utilisateur ou quelque chose de similaire.

Dans la première version du RPi, il y avait / il y a des problèmes avec les ports USB, je n'ai pas cherché récemment si ceux-ci sont résolus pour le moment. J'ai également entendu une rumeur selon laquelle la nouvelle version 2.0 du RPi ne devrait pas avoir ces problèmes, mais je n'ai pas non plus vérifié cette rumeur.

Je pense que les résultats sans matériel externe (spécialisé) sont limités en raison du nombre de ports d'E / S et du fait qu'un système d'exploitation complet fonctionne dessus (ce qui limite les options en temps réel). Sauf si vous prévoyez d'écrire votre propre système d'exploitation?

L'utilisation de puces I2C par exemple à cette fin n'aura pas une vitesse suffisante pour faire quelque chose de vraiment sympa. SPI donne déjà beaucoup plus de bande passante (jusqu'à 100 MHz à partir du haut de ma tête), mais j'opterais pour l'USB et si nécessaire je compresserais, ou utiliserais un bon schéma d'encodage avant d'envoyer les données, pour gagner plus de bande passante.

Donc je suppose que c'est possible, mais le matériel qui doit être ajouté au RPi sera beaucoup plus cher que le RPi lui-même.

Dernier point mais non le moindre (avant d'arrêter de rêver à ce sujet), je ne serais pas surpris si une recherche sur Internet entraînerait un groupe déjà occupé à le faire.

La réponse est oui.

C'est assez puissant! Mais seulement pour certaines fréquences - comme déjà souligné à cause des limitations.

DONC! -> Vous devez vous demander ce que vous voulez mesurer?

• Parce que vous ne demandez pas précisément ce que vous voulez mesurer, les réponses sont sujettes à spéculation.
• Alors laissez-moi vous présenter des alternatives et des suggestions. Vous pouvez peut-être poser une nouvelle question plus spécifique au sujet de la framboise et non du thème général de l'oscillateur!

Les oscillateurs peuvent aller de simples basses fréquences qui coûtent 5 USD, puis d'autres peuvent gérer jusqu'à 50 GHz + - ce qui coûte autant qu'une petite maison! 75 000 USD-100 000 USD!

Je pense que le Raspberry sera assez bon pour mesurer les fréquences sous Giga, comme les signaux sans fil 433 MHz, les communications par bus CPU à faible vitesse, TTS / UART, le débogage I2C - pas beaucoup plus vraiment. Et les fréquences plus élevées ne seront pas vraiment précises, car par conception, le Raspberry ne fonctionne pas en temps réel. Vous devrez donc commencer par le système d'exploitation (ou comme mentionné en temps réel sur les périphériques externes - mais à quoi ça sert alors?)

Mais si vous vouliez vraiment mesurer des signaux, alors vous pouvez acheter un appareil vraiment bon et à un prix raisonnable qui est à égalité avec les spécifications Raspberry. Mais est déjà bien conçu, plein de fonctionnalités, très mature dans la conception et s'est avéré être pratique dans un environnement amateur.

Il n'est pas nécessaire de réinventer la roue ici. Par exemple, un DSO Nano pour un canal unique de moins de 100 USD.

Un DSO Nano Quad Channel pour moins de 200 USD

Et puis, ce qu'un Raspberry ou un appareil similaire NE PEUT PAS FAIRE!

Et coûte une petite fortune ...

• Jusqu'à 110Ghz, avec disque dur pour stocker des données, extrêmement précis, simulations et déclencheurs.
• Mesures Buuetooth, WCDMA / EDGE / 3G / 4G, sans fil A / B / G / N 2,4 GHz / 5 GHz, SATA, AGP / PCI / PCI-Express, signaux satellites bruts, canaux de tête de disque dur, Ethernet, etc., etc. .

Vous pouvez connecter l'un de nos oscilloscopes / générateurs de signaux arbitraires Handyscope HS5 d'ingénierie TiePie au port USB. Une bibliothèque compilée pour que le Raspberry Pi utilise un ou plusieurs oscilloscopes simultanément est disponible en téléchargement. L'instrument utilise sa propre synchronisation et sa propre mémoire, il n'y a donc aucune perte de performances. Alors oui, le Pi est assez puissant pour un projet d'oscilloscope.

Spécifications clés de l'oscilloscope: 2 canaux, 14 bits, 500 MS / s, bande passante 250 MHz, 20 MS / s streaming continu sans espace 14 bits, mémoire 32 MS par canal, précision de la base de temps de 1 ppm.

Spécifications clés du générateur de signaux arbitraires: formes d'onde de 1 µHz à 30 MHz, 240 MS / s, 14 bits, mémoire 64 MS, sortie -12 à 12 V (24 Vpp), précision de base de temps de 1 ppm.

Votre meilleure chance est d'essayer si sigrok et son libsigrok frontal peuvent être compilés sur Pi, puis acheter du matériel d'oscilloscope compatible. De cette façon, vous pouvez saisir des signaux jusqu'à 24 méga échantillons par seconde. Avec suffisamment de connaissances, vous pouvez personnaliser le logiciel comme vous le souhaitez, y compris la transmission sans fil vers les appareils mobiles.

Quelqu'un parle de Sigrok. Je pense que le moyen le plus proche est d'utiliser le CY7C68013A bien documenté avec le pilote EZ-USB FX2LP. Sur PC de bureau, cela ne fonctionnait pas avec Weezy, mais sur Jessy, cela fonctionne bien. Voici la limitation connue sur 24 Msps. Je pense à une autre façon, en utilisant l'interface de la caméra. Cette interface pourrait gérer 2,1 mégapixels et 30 images par seconde, ce qui signifie qu'elle pourrait transférer des données vers le GPU à une vitesse supérieure à 60 méga "échantillons" par seconde. Sons plus utiles que 20 MHz SPI ou USB.

Si cela ne vous dérange pas d'être limité aux fréquences audio, j'utilise un convertisseur A / N double canal MCP3202 12 bits peu coûteux pour acquérir sur le pi avec spidev, et pydatascope pour afficher les données transmises via Ethernet via la prise TCP. Le pydatascope agit également comme un analyseur de spectre!

J'ai apporté des modifications relativement triviales au code open source de pydatascope pour avoir deux canaux, principalement parce que c'était facile et non pas que j'en ai vraiment besoin.

Postez des suivis ou écrivez-moi directement si vous avez des questions, je serai heureux de vous aider.