Hur gör man en bra A/D omvandling till USB?

[zwitter]

Jag funderar på att göra ett PC-oscilloskop. Så jag behöver lite idéer om hur jag bör gå till väga och lite vad för max frekvenser som jag kan tänkas kunna mäta. USB har ju sin gräns tex.

Jag har kollat på en pic, PIC18F2550. Den har A/D och USBstöd. Eller är detta fel grejer att bygga med? Det är kanske bättre att bygga med en separat A/D-omvandlare och sen bygga ihop med med någon USBkrets.



PIC18F2550: http://www.microchip.com/stellent/idcpl ... e=en010280

[babbage]

Jag känner inte till något om PIC18F2550, men andra här kan säkert analysera dess lämplighet.

Oberoende av interface till PC:n, USB eller något annat, kan det vara en bra idé att inte förlita sig på prestandan på interfacet. Istället buffrar man samplingarna i ett minne utanför PC:n. Då är det storleken på detta minne och hastigheten på AD-omvandlaren som bestämmer prestandan.

Grundläggande aaker att tänka på innan man börjar kan vara:

* Vilka frekvenser vill du mäta? Hastighet på AD-omvandlaren, samplingsteoremet säger teoretiskt att man klarar sig med dubbla samplingsfrekvensen mot den frekvens man vill mäta men räkna gärna med en faktor 10 för att det ska fungera bra i praktiken istället.

*Vilka spänningar ska du mäta. Det kan vara knepigt att få till ett bra ingångssteg om man vill mäta olika spänningsintervall, mV till kV.

*Vilken noggrannhet behöver du? Hur många bitar behöver AD-omvandlingen vara 4,8,10 ... bitar?

*Nogrannheten på klockan för AD-omvandlingen.

*Analog bandbredd på ingången, finns det risk för aliasing?

Det finns mycket mer att tänka på men det här kan vara några frågor att börja med. Haka inte upp dig på USB-interfacet, det är bara ett medel att kommunicera med pc-oscilloskopet. Det är visserligen viktigt men inte avgörande för prestandan.

[zwitter]

Jag känner igen det där som du pratar om. Det där med minst dubbla samplingsfrekvensen, för att unvika vikning om jag inte minns fel.

Tanken är väl att kunna mäta upp till 5V med ett längre mål på 30V. Men först vill jag få det att funka alls. Frekvens i första skedet är alltså inte jätteviktigt. 1MHz vore ju trevligt.

Men jag funderar på en sak som du pratar om. Om jag har ett minne som värdena samplas till, borde det inte vara rimligt att man läser av det minst i den takten som det lagras med. Annars fylls väl minnet bara på mer och mer? Det var där som jag tänkte att USB satte en gräns. (eller är jag ute och cyklar helt?)

Max 10-bitars omvandlig. Bör räcka.

Har du något bra tips?

[babbage]

Angående externt minne: Om man ska visa vågformen på datorn så har man dels en begränsad uppdateringsfrekvens, dels ett begränsat antal bildpunkter. Förenklat, för att kontinuerligt se en bild på PC:n räcker det kanske att uppdatera vågformen 10-25 ggr i sekunden för att den ska se bra ut. Alltså samplar man till minnet med en hög takt en gång, för över vågformen till datorn, när det är klart samplar nästa omgång data till minnet osv. Data som måste överföras till PC:n per gång är t.ex 10bitar*100 (y*x)=1000 bitar. Om man ska uppdatera den 25 ggr/s blir det 25000bitar/s, vilket inte är så mycket.

Om man däremot vill spela in kontinuerligt till hårddisken för väldigt långa förlopp har du naturligtvis rätt i att när minnet tar slut måste man läsa ut det med samma takt som man samplar för att inte förlora data.

Vikning är det korrekta svenska ordet för aliasing.

Ett bra tips är väl att inte sikta för högt och göra det för avancerat i början, en lämplig målsättning är kanske bara att få det att fungera till att börja med och inte tänka för mycket på de saker jag skrev i förra postningen. Om man sen inte är nöjd med resultatet kan det kanske vara en lämplig utgångspunkt för att förstå vad van kan göra för att förbättra det.

Det fanns en tråd tidigare om pc-oscilloskop som kan vara värd att läsa
http://www.geekjoan.com/forum/viewtopic ... sc&start=0

[$tiff]

Jag undrar då om det går att få några bra MHz-samplingar med en prolle som tuffar på i max 48MHz (12MIPS).

Jag tvekar på att man kan komma över 100k samplingar per sekund med ADCn i en PIC.

[Digger]

Jag har själv funderat på att bygga ett oscilloskop. Jag tycker att realtidssampling verkar svårt att få till med användbar bandbredd. Däremot har jag funderat på ifall inte "Equivalent Time Sampling" skulle fungera. Vet inte hur lätt det är att få samplingerna synkroniserade med triggningen. Är det rimligt att kunna uppnå bra resultat med den metoden mha A/D:n i en Atmel t.ex.?

[babbage]

$tiffs uppskattning av prestanda med pic: Om man inte får ut mer än ca 100kHz samplingsfrekvens så är ju det inte så imponerande. Man kan kanske få bra vågformer med frekvenser på 30-40kHz med sinc-interpolering. Om man använder någon sämre form av interpolering kan det bli betydligt värre. Det gäller för sinusvågor. Än värre blir det om man t.ex. vill se fyrkanstvågor eftersom de innehåller många frekvenser över grundfrekvensen. Det kan ju vara intressant att bygga ändå men ett alternativ vore att använda ljudkortet till datorn istället, då får man antagligen även fler bitars upplösning (16-24bitar). Om man ändå vill bygga eget kanske man kan satsa på att konstruera något som skyddar ljudkortet från för höga signalnivåer.

Diggers idé att använda Equivalent Time Sampling": Som vanligt ursäktar jag mig för att jag egentligen inte kan något om PIC:ar eller AVR:er så resten av detta stycke kanske bara är en massa mumbo jumbo. Jag borde verkligen skaffa en uP snart och lära mig, de är ju flexibla och kan vara kostnadseffektiva men nu är det mest FPGA som gäller för min del. Tillbaka till ämnet. Det finns en uppenbar brist med ETS, det fungerar bara för periodiska signaler och inte för engångsförlopp. Om man är medveten om det och har periodiska signaler så är det inget stort problem (det som kanske kan ställa till det är jitter). Problem jag kan tänka mig med ETS och en uP är att man har begränsade resurser för att bestämma var man befinner sig relativt en hypotetisk fas i systemklockan. Om man använder något högnivåspråk skulle det kräva att man har tillräckligt med fristående hårdvaruresurser som räknare, watchdogs, interrupthanterare mm och att det går att göra samplingen vid en väl definierad tidpunk relativt dessa resurser. Om man programmerar i assembler kan man kanske lösa det genom att räkna klockcykler som instruktionerna tar. Om man t.ex startar samplingen med att skriva till ett register och sedan får en interrupt när samplingen är klar så gäller det ju att tiden registerskrivning till interrupt är någorlunda konstant. Nu ska man väl inte bara se problem, det är väl klart att man kan tolerera vissa variationer men om de är stora så försämrar de ju resultatet. I en FPGA är det i det närmaste trivialt att göra samma sak.

Om man vill få prestanda i storleksordningen >MHz kanske man ska satsa på en extern AD-omvandlare istället och försöka optimera uP att kommunicera så fort som möjligt med den. Jag kan tänka mig en lösning med en ADC, ett minne och en uP. Om ADC:n har parallelldata ut kan man koppla dessa ledningar till dataingången på minnet. uP får ansvara för att ge minnet en adress och sedan klocka ADC:n. och minnet. Det borde krävas rätt få instruktioner för att utföra detta. När man sedan har samplat så mycket man vill, eller minnet är fullt kan man låta uP:n läsa från minnet i en lugnare takt och kommunicera med PCn.