Isso se resume a uma questão de largura de banda e latência. Para um sistema simples, vamos assumir uma sonda com largura de banda de 100 MHz com taxa de amostragem de 1GS / se um conversor A / D de 10 bits (tive experiências ruins com escopos de 8 bits).
Eu quero uma exibição em tempo real no PC com uma janela de amostragem mínima de, digamos, 10ns - 1 ciclo de uma onda senoidal de 100 MHz e uma janela máxima de (eu serei generoso com você) meio segundo. Em outras palavras, a configuração de tempo mais baixa será algo como 1ns / div e a mais alta será 0,05s / div. Eu também quero vários modos de tensão - 100mV variam até 20V, digamos.
Que tipo de taxa de dados isso envolve?
1Gs / s * 10 bits / amostra = 10Gbits / s
Essas não são velocidades USB. Longe disso. E nem levei em conta as despesas gerais. Primeiro, você simplesmente não tem largura de banda. E também não é apenas largura de banda. Para sua exibição em tempo real, você precisa ser consistente. Você precisa transferir 100 bits para a camada do aplicativo a cada 10 nano segundos. Esse tipo de consistência não pode ser obtido pelo USB. Ele não foi projetado para atender a um dispositivo com demandas extravagantes - foi projetado como um ônibus. E você não pode controlar quando possui o ônibus - os dispositivos são apenas escravos. Se o host permitir que outro dispositivo fale quando você precisar enviar dados, eles serão perdidos.
Você pode estar chorando - por que transferir dados em tempo real para o computador quando o "tempo real" de uma pessoa é de 60Hz? Se tudo o que você precisa fazer é atualizar a exibição, certamente não precisará de tantos dados. Exceto o que você faz - sua exibição é uma combinação linear de todas as amostras que você coletou. Interpolação de spline cúbica média, com menor quadrado médio aproximado - isso não importa. Para criar uma bela exibição bonita que não seja apenas um monte de pontos, você precisa de mais de todos esses dados e precisa processá-los posteriormente. Algum gatilho? Os cálculos devem ser feitos no host - na camada de aplicação. Não importa como você o divide, para exibições em tempo real a taxas de 1GS / s para qualquer precisão, você precisa transferir ordens de magnitude mais dados do que o USB pode suportar e você deve fazê-lo com mais confiabilidade do que você '
Quais são as formas de contornar isso? Não faça uma exibição em tempo real. Alguns escopos USB oferecem apenas modos acionados. O acionamento é tratado no dispositivo e, quando um acionador é encontrado, os dados são coletados em um buffer. Quando o buffer é preenchido, o escopo USB o transfere lentamente para o aplicativo e, em seguida, o aplicativo o exibe. Isso é suficiente para muito uso do escopo, mas não é em tempo real. E a transferência - isso também leva um tempo. É inconveniente. E geralmente os motoristas são péssimos. Você pode dizer que tive experiências ruins.
Sempre me perguntei por que o Firewire não foi usado para escopos. Evita algumas das dores de cabeça do USB. É ponto a ponto, oferece modos isocrônicos (tempo consistente) e é relativamente alta largura de banda. Você pode criar um escopo em tempo real de 10 MHz ou mais com isso.
Para abordar seus pontos após a edição:
A usabilidade de um escopo aumenta tremendamente com o preço. Quando você passa de um escopo USB de US $ 200 para até US $ 500, obtém tremendos aumentos nos recursos e na funcionalidade básica. Por que gastar apenas US $ 200 quando, por um pouco mais, você pode obter um escopo real? Agora que a China abriu as comportas de escopos baratos e eficazes, há poucas razões para querer economizar US $ 300 que apenas o frustrarão mais tarde. Os escopos 'sofisticados' que possuem esses recursos são baratos hoje em dia.
Sim, limitar a transferência de dados para fornecer apenas algo consistente em torno de 60Hz de dados consistentes será mais fácil com o USB, mas isso ainda não é algo que você deseja fazer. Não se esqueça das suas classes DSP - apenas pegar certos dados do fluxo equivale a dizimação. Ao dizimar, você precisa adicionar filtros antialiasing. Quando você faz isso, você perde largura de banda. Isso torna seu escopo menos útil - ele limitará sua largura de banda na exibição em tempo real (e somente para modos acionados em tempo real seria bom) a muito menos do que a largura de banda do seu front-end analógico. Gerenciar os aspectos de processamento de sinal de um osciloscópio é um negócio complicado.
Tela responsiva clara? O PC? Não de forma consistente. Independentemente de como você faz isso, você precisa armazenar dados em buffer. Como eu disse antes, o USB não garante quando seus dados são enviados. Vou dizer de forma diferente: o USB não foi projetado para acomodar transferências de dados em tempo real. Claro, para quantidades suficientemente pequenas de dados em grandes intervalos, você pode obter um bom desempenho, mas não um desempenho consistente. Você usará o buffer e, de vez em quando, sentirá falta de transferir seu buffer em tempo hábil. Em seguida, sua tela é ignorada, os dados ficam obsoletos etc.
Disparo simples - mais uma vez, voltamos ao custo x complexidade vs. responsivo. Para acionar o dispositivo para detectar transientes, seu dispositivo não pode ser apenas um canal de dados estúpido que transfere amostras de forma irresponsável por USB. Você precisa colocar buffer, buffer, amostras de buffer no dispositivoaté ver sua condição de gatilho. Isso significa que você precisa de memória e inteligência no seu dispositivo - um FPGA grande ou um microcontrolador grande. Isso aumenta o tamanho e o espaço. Se você usa um FPGA, precisa equilibrar a quantidade de lógica de acionamento com a necessidade de muita RAM para espaço no buffer. Portanto, seu buffer é menor do que você gostaria que fosse. Isso significa que você obtém uma quantidade minúscula de dados em torno do seu ponto de disparo. A menos que você adicione memória externa - poderá fazer mais. Isso aumenta o tamanho e o custo do seu dispositivo - isso certamente não será apenas uma sonda com um cabo USB conectado a ele.
Você teria sorte em obter largura de banda de 100 MHz - normalmente 10x a taxa de amostragem é considerada o ponto de corte mínimo para a largura de banda. Portanto, se você tem uma taxa de amostragem de 1GS / s, isso dificilmente fornece largura de banda de 100MHz. Você não pode obter mais - uma onda quadrada de 200 MHz será semelhante a uma onda senoidal de 200 MHz. Isso é péssimo. Isso é idiota - não chega nem perto do nível profissional.
Seu outro conjunto de pontos:
- US $ 200? Como você imagina? Qual é a lista de peças?
- Bons escopos para ler sinais de alta velocidade não custam milhares de dólares. Eles custam talvez mil dólares. 100MHz é uma brincadeira de criança no departamento de escopo, e sua ideia nem atinge esse ponto de referência nem um escopo de US $ 1000
- Sim, da maneira que você descreve, seria muito limitado. Os aspectos técnicos, mesmo dos poucos requisitos, têm um dispositivo muito limitado.
- Não seria tão útil quanto o escopo de US $ 1100 que comprei com um analisador lógico e largura de banda analógica de 60MHz. Prefiro pagar pelo meu equipamento de teste que brinca com brinquedos de criança intencionalmente limitados.
Você vive e morre por seu equipamento de teste como engenheiro. Se você não tiver certeza, pode confiar que está perdendo tempo. Dada a falta de conhecimento que você demonstrou sobre comunicação em alta velocidade, processamento de sinal e o poder do processamento incorporado (em FPGAs ou microcontroladores), eu não apostaria que você está planejando projetá-lo sozinho e mais ninguém que respondeu é algo diferente de ambivalente.
Se houvesse um conjunto de requisitos mais direcionado que atendesse a uma necessidade real na comunidade que não estava sendo atendida, que eu pudesse ver como tecnicamente viável, estaria a bordo. Mas seus requisitos vagos não parecem pesquisados. Você precisa fazer uma pesquisa das opções disponíveis para os entusiastas - quais escopos e independentes de USB as pessoas estão usando, quais são seus pontos fortes e fracos e determinar se algum nicho não está sendo preenchido. Caso contrário, isso é apenas fantasia.