O Pi é poderoso o suficiente para um projeto de osciloscópio?

Meu objetivo é fabricar instrumentos baseados em Pi, começando com um osciloscópio. Então eu li as respostas para

• Quais conversores analógico para digital estão disponíveis para o RPI?
• Como conectar um conversor analógico a digital (ADC)?

Parece possível ler entradas analógicas com taxas de amostragem muito baixas, mas eu me pergunto se eu poderia alcançar taxas de mega amostras por segundo. A aquisição contínua de dados provavelmente seria difícil, se for possível, para que eu possa ficar sem ela. Pi estaria mal equipado para isso? Quero observar formas de onda nos monitores conectados ao Pi primeiro e depois nos meus dispositivos móveis (enquanto o Pi transmite dados sem fio para eles).

Minha experiência com o sistema em chips me diz que esses sistemas podem facilmente saturar em E / S contínua. Esse também é o caso do Pi?

Vamos ter uma visão geral de alto nível do que um osciloscópio possui:

Primeiro, temos o front-end analógico. Aqui temos uma rede de correspondência de impedância para as sondas (mas as sondas também terão que ter uma parte de correspondência de capacitância), seção de atenuação (muito importante, para não sobrecarregar o ADC ou permitir a entrada de altas tensões), acionamento e conexão a conversor analógico para digital. Não vou falar muito sobre isso, já que não sou muito bom com coisas analógicas, mas o ponto principal é: não há nada que possamos fazer com Pi nesta seção.

Em seguida, temos a parte do conversor analógico para digital. Você precisará de pelo menos um ADC para cada canal. Mais pode ser usado para uma taxa de amostragem mais alta. No escopo tradicional, o ADC está conectado a um dispositivo ASIC ou FPGA. Eles são usados ​​porque os computadores tradicionais não são em tempo real o suficiente (e não confundem em tempo real com rápido!) Para processar os dados fornecidos pelo ADC. Esses dados são armazenados em algum tipo de RAM. Alguns dispositivos usarão RAM estática, enquanto outros usarão RAM dinâmica. Em geral, a abordagem SRAM é mais tradicional e vista em grandes fabricantes, enquanto o uso de DRAM parece ser a abordagem mais nova vista nas unidades mais baratas projetadas na China.

A quantidade de RAM e sua velocidade determinarão quantas amostras podem ser armazenadas. Quase sempre o ADC será um ADC de 8 bits, portanto, por exemplo, uma megasample precisará de 8 b vezes 100000 = 8 Mb ou 1 MB de RAM. Para um MSa / s, precisaremos de RAM que possa funcionar nessa velocidade. Hoje, isso deve ser relativamente fácil de obter. O FPGA normalmente dirige a RAM diretamente e é responsável por armazenar dados nela. Ele funciona preenchendo a memória de amostra enquanto ainda há espaço vazio e substituindo-o quando estiver cheio. Quando houver vários ADCs por canal, o FPGA os definirá para que primeiro comece a amostragem, depois no próximo relógio, segundo e assim por diante. Quando eles terminam a amostragem, a amostra do primeiro ADC será gravada primeiro na memória, depois a segunda amostra do ADC. Isso fará com que pareça que os ADCs estão amostrando mais rapidamente do que realmente são.

O próximo ponto desta seção é que as amostras devem ser equidistantes no tempo. Este é o principal problema com o uso de PCs em osciloscópios e a razão pela qual FPGAs e ASICs são predominantes. Se algumas amostras estiverem atrasadas ou adiantadas, a imagem representada na tela estará incorreta.

Nesta parte, vemos o primeiro uso possível do Pi. Se a taxa de amostragem for baixa o suficiente, poderemos conduzir os ADCs diretamente do Pi e armazenar seus resultados na RAM do Pi. A rapidez com que podemos ir depende da maneira como o ADC está conectado ao Pi e de como o Pi faz sua E / S. Pelo que li, a velocidade mais alta das portas I ^ 2C do Pi é de 150 MHz (o que seria mais fácil de obter no GNU / Linux é outra questão), enquanto a velocidade padronizada mais alta é de 5 MHz e para o SPI a velocidade mais alta em Pi é 250 MHz. Não tenho certeza de qual é a velocidade padrão mais alta do SPI, mas espero que esteja em algum lugar na faixa de 100 MHz no máximo.

Portanto, em teoria, temos velocidade mais do que suficiente no Pi para executar um ADC na faixa de MSa / s baixa. Sinto que a velocidade da RAM não será um problema aqui, mas não tenho dados para fazer backup disso. Se for esse o caso, teríamos um grande benefício em relação aos escopos comuns: haveria uma quantidade muito grande de memória de captura disponível. Por exemplo, se dedicarmos 32 MiB de RAM ao programa para memória de amostra e tivermos dois canais, isso nos deixará com 16 MiB para cada canal ou um pouco mais de 134 Mb ou 134 megasamples por canal. Isso é algo que até hoje muitos osciloscópios não possuem.

A desvantagem é que precisaríamos de modificações pesadas no sistema operacional para poder obter amostras precisas aqui. Eu não tenho nenhuma experiência com Linux em tempo real, então não sei como isso seria fácil.

De qualquer forma, vamos ao próximo passo. Portanto, temos um sistema de amostragem que preenche a RAM. A próxima parte é o gatilho. O gatilho está intimamente relacionado à taxa de atualização da tela. O que basicamente faz é encontrar uma amostra interessante e mantê-la na memória. Quando o osciloscópio é acionado, ele continua a amostragem após o acionamento até encher a memória e envia-o para ser processado e exibido na tela. Enquanto os dados estão sendo processados, o sistema de amostragem, se frequentemente congelado, aguarda a exibição dos dados. É por isso que os escopos low-end têm taxas de atualização mais baixas, enquanto os escopos high-end têm exibições especiais de alta taxa de atualização e gastam muito menos tempo aguardando a exibição dos dados.

Nesta seção, haverá frequentemente outro ASIC ou FPGA que processará o sinal nas amostras, qualquer decodificação de protocolo se o escopo o suportar e realmente direcionar o próprio monitor.

Esta é a parte em que, pelo que vejo, o Pi pode realmente brilhar. Ele pode exibir uma bela exibição de 1920 x 1080 (enquanto os escopos geralmente estão no terreno inferior a 800x600) e pode decodificar muito bem o protocolo. O único problema que vejo é a velocidade e como o processamento afetaria o tempo de espera. Se optarmos por uma baixa taxa de atualização, podemos obter um analisador lógico muito bom com ele.

Finalmente, uma palavra sobre os osciloscópios USB e por que o USB geralmente é ruim para esse tipo de projeto: O osciloscópio USB tradicional faz entrada e amostragem e envia os dados de amostragem ao PC para processamento para o qual existe um aplicativo host. Basicamente, algo muito semelhante seria feito com o Pi também. Geralmente, os aplicativos para PC são mal projetados e cheios de bugs. A próxima parte ruim é o próprio USB. Ele é anunciado como barramento rápido, que pode fazer 480 Mb / s no modo "Alta velocidade". A verdade é que é extremamente raro encontrar um controlador USB capaz de suportar velocidades tão altas (a média parece estar em torno de 250 Mb / s do que eu vi) e que, como um protocolo, não é muito adequado para qualquer real aplicação em tempo real. Primeiro, ele é compartilhado entre todos os dispositivos em um hub (e o Pi possui apenas uma porta USB à qual o Ethernet + USB Hub está conectado), possui uma sobrecarga relativamente alta (quando comparado ao SPI) e alta latência (lembre-se de que a 1 MSa / s cada amostra dura apenas 1 µs, portanto, devemos ter memória em nossa placa, pois não podemos enviar amostras em tempo real via USB). Finalmente, o uso do USB tornaria a aquisição de dados parte do escopo para ser apenas outro osciloscópio USB e é aí que perdemos qualquer benefício do uso do Pi: os computadores de mesa tradicionais são muito mais comuns, mais rápidos, mais fáceis de obter e têm recursos USB muito melhores.

EDIT Eu li um post relativamente recente de Gert van Loo e, segundo ele, taxas realistas para o I ^ 2C de Pi são 400 kHz e para o SPI são 20 MHz.

Nós descobrimos que o Raspberry Pi é uma excelente plataforma para executar o software necessário para um projeto como este. O problema é obter os sinais no RPi em primeiro lugar e executar a captura de sinal em tempo real sem tremulação de alta velocidade na mesma CPU que está executando o sistema operacional e o software aplicativo. Nossa solução é o osciloscópio BitScope Raspberry Pi, que emparelha um BitScope (para captura de forma de onda de sinal misto de alta velocidade) com o Raspberry Pi, que executa todo o software necessário.

NB: Este é mais um pedaço de texto 'pensando em voz alta' do que uma resposta real

A ideia também passou pela minha cabeça há algum tempo, e eu ainda gosto da idéia geral!

Até onde eu sei, os escopos de última geração são, desde 15 anos (ou mais), apenas computadores (PC) com várias E / S especializadas de alta velocidade. Eu acho que quando E / S similares são projetadas / conectadas ao RPi, o resultado pode ser surpreendentemente bom.

IMHO, uma boa maneira de fazer isso é permitir que o RPi armazene e exiba os dados coletados (recebidos, por exemplo, pela porta USB) e permita que algum hardware especializado faça a medição em alta velocidade. Essa unidade de medição de alta velocidade também pode ser controlada pelo RPi com base na entrada do usuário ou em algo semelhante.

Na primeira versão do RPi, houve / há alguns problemas com as portas USB, não pesquisei recentemente se elas foram resolvidas no momento. Também ouvi boatos de que a nova versão 2.0 do RPi não deveria ter esses problemas, mas também não verifiquei esse boato.

Eu acho que os resultados sem nenhum hardware externo (especializado) são limitados devido ao número de portas de E / S e ao fato de um sistema operacional inteiro estar sendo executado nele (o que limita as opções em tempo real). A menos que você esteja planejando escrever seu próprio sistema operacional?

Também usar, por exemplo, chips I2C para esse fim não terá velocidade suficiente para fazer algo realmente bom. O SPI já oferece muito mais largura de banda (até 100Mhz do topo da minha cabeça), mas eu usaria o USB e, se necessário, comprimiria, ou usaria algum bom esquema de codificação antes de enviar os dados, para obter mais largura de banda.

Acho que é possível, mas o hardware que precisa ser adicionado ao RPi será muito mais caro que o próprio RPi.

Por último, mas não menos importante (antes de parar de sonhar acordado sobre esse assunto), não ficaria surpreso se uma pesquisa na internet resultasse em algum grupo já ocupado fazendo isso.

A resposta é sim.

É poderoso o suficiente! Mas apenas para certas frequências - Como já foi apontado por causa das limitações.

ASSIM! -> Você precisa se perguntar o que deseja medir?

• Como você não está perguntando especificamente o que deseja medir, as respostas estão abertas à especulação.
• Então, deixe-me apresentar-lhe alternativas e sugestões. Talvez você possa fazer uma nova pergunta mais específica para o tópico Raspberry e não para o Oscillator!

Os osciladores podem variar de baixas frequências simples que custam 5 USD, e outros podem suportar até 50 Ghz + - que custam tanto quanto uma casa pequena! 75.000USD-100.000USD!

Eu acho que o Raspberry será bom o suficiente para medir frequências sub Giga, como sinais sem fio de 433 mhz, comunicações de barramento de CPU de baixa velocidade, TTS / UART, depuração I2C - não muito mais. E as frequências mais altas não serão realmente precisas, pois, por design, o Raspberry não executa o SO em tempo real. Então, você precisará começar com o sistema operacional (ou como dispositivos externos em tempo real mencionados - mas qual é o objetivo, então?)

Mas se você realmente deseja medir sinais, pode comprar um dispositivo realmente bom e com preço razoável, compatível com as especificações do Raspberry. Mas ele já foi bem projetado, cheio de recursos, realmente maduro em design e provou ser útil em um ambiente amador.

Não há necessidade de reinventar a roda aqui. Por exemplo, um DSO Nano para menos de 100USD de canal único.

Um DSO Nano Quad Channel para menos de 200 USD

E então, o que um Raspberry ou dispositivo similar NÃO PODE FAZER!

E custou uma pequena fortuna ...

• Até 110Ghz, com disco rígido para armazenar dados, extremamente precisos, simulações e gatilhos.
• Mede Buuetooth, WCDMA / EDGE / 3G / 4G, Wireless A / B / G / N 2.4Ghz / 5Ghz, SATA, AGP / PCI / PCI-Express, sinais de satélite em bruto, canais de disco rígido, Ethernet, etc., etc. .

Você pode conectar um de nossos osciloscópios de engenharia TiePie Handyscope HS5 / geradores de formas de onda arbitrárias à porta USB. Uma biblioteca compilada para o Raspberry Pi usar um ou vários osciloscópios simultaneamente está disponível para download. O instrumento usa seu próprio tempo e memória, para que não haja perda de desempenho. Então, sim, o Pi é poderoso o suficiente para um projeto de osciloscópio.

Principais especificações do osciloscópio: 2 canais, 14 bits, 500 MS / s, largura de banda de 250 MHz, streaming livre de gap contínuo de 20 MS / s de 14 bits, memória de 32 MS por canal, precisão de base de tempo de 1 ppm.

Principais especificações do gerador de forma de onda arbitrária: formas de onda de 1 µHz a 30 MHz, 240 MS / s, 14 bits, memória de 64 MS, saída de -12 a 12 V (24 Vpp), precisão da base de tempo de 1 ppm.

Sua melhor chance é tentar se sigrok e seu front -end libsigrok podem ser compilados no Pi e comprar algum hardware compatível com o osciloscópio. Dessa forma, você pode captar sinais de até 24 mega amostras por segundo. Com conhecimento suficiente, você pode personalizar o software da maneira que desejar, incluindo transmissão sem fio para dispositivos móveis.

Alguém falando sobre Sigrok. Acho que a maneira mais próxima é usar o CY7C68013A bem documentado com o driver EZ-USB FX2LP. No PC de mesa, não funcionou com o Weezy, mas no Jessy é um bom trabalho. Aqui está a limitação conhecida sobre 24 Msps. Pensando em outra maneira, usando a interface da câmera. Essa interface pode gerenciar 2,1 mega pixel e 30 quadros por segundo, o que significa que pode transferir dados para a GPU com velocidade acima de 60 mega "amostras" por segundo. Soa mais útil que SPM ou USB de 20 MHz.

Se você não se importa em limitar-se a frequências de áudio, eu uso um conversor A / D duplo de 12 bits MCP3202 de baixo custo para adquirir no pi com spidev e pydatascope para exibir dados passados ​​pela Ethernet via soquete TCP. O Pydatascope também atua como um analisador de espectro!

Fiz alterações relativamente triviais no código-fonte aberto do pydatascope para ter dois canais, principalmente porque era fácil e não que eu realmente precisava.

Poste acompanhamentos ou envie-me um e-mail diretamente se tiver alguma dúvida, teremos prazer em ajudar.