De CO scope. Requests topic

je kan altijd FFT draaien op de data ...
als iemend echt een spectrum analyser wilt go ahead. ik begin daar niet aan. das veel te moeilijk om dat goed te krijgen.

signaalbron zit ook al int achterhoofd.

maar eerst de scoop. das stap 1 ... 2 is de logic analyser module.

de reden dat ik fft zou nodig hebben is voor ELF signalen
(0,.... hZ tot maximum 100hZ ofzo)
vrij goed analoog te doen anders miss dak wel iets doe met een zaagtand generator en een analoge filter.
dan kom je al ver met een 2 kanaals scoop in XY modus

swat voor de rest echt super project zeer goed aanpasbaar voor de hobby lijkt me.
de kaarten zelf die je er insteekt als het ware zouden die dan ook 4 laags worden? of alleen de backplane?
ik zal al vast beginnen sparen denk ik
logic analyser ook altijd mooi.
100mhZ is ook mooi voor de hobby.
dan nog desnoods een signaalbron.
cho ik kan niet direct veel meer bedenken als extra opties.
een module met een lcd schermpje ofzo idd

Op 12 oktober 2005 22:29:35 schreef beertje_01:
de reden dat ik fft zou nodig hebben is voor ELF signalen
(0,.... hZ tot maximum 100hZ ofzo)
vrij goed analoog te doen anders miss dak wel iets doe met een zaagtand generator en een analoge filter.
dan kom je al ver met een 2 kanaals scoop in XY modus

swat voor de rest echt super project zeer goed aanpasbaar voor de hobby lijkt me.
de kaarten zelf die je er insteekt als het ware zouden die dan ook 4 laags worden? of alleen de backplane?
ik zal al vast beginnen sparen denk ik
logic analyser ook altijd mooi.
100mhZ is ook mooi voor de hobby.
dan nog desnoods een signaalbron.
cho ik kan niet direct veel meer bedenken als extra opties.
een module met een lcd schermpje ofzo idd

backplane is dubbelzijdig. de plugins zijn 4 laags (we gaan nog altijd proberen 2 laags. maar tkzit er dik in dat dat multilayers worden

FFT in software is niet echt moeilijk. De wiskunde die er echter zit is relatief complex.
Maar je kan genoeg code voorbeelden van het net downloaden. Let Google be your friend!
BTW: als je 'maar' 100Hz wil FFT'en, kan je je eigen soundkaart wel als scope gebruiken. ook hier is veel op het net over te vinden. Meestal zit er in die SW al een FFT functie.

Hallo leuk om te zien dat het scoop project weer aan de gang is

Ik heb nog een aantal vraagjes:

-Zit er op de scoop ook een (pre)trigger? (lijkt mij erg handig)

-Hoe herkent de computer welke kaarten er in de backplane zitten?

-Is het ook mogelijk om een backplane te krijgen waar 'maar' 4 kaarten in passen? (ik denk niet dat iedereen behoefte heeft aan een backplane met 8 uitbereidings sloten)

-En met wat voor connectors wil je die kaarten gaan verbinden met je backplane? Daar op aansluitend met welke snelheid ga je je fifo's uitlezen?

-Bij het vorige toppic meen ik me te herinnneren dat het analoge deel nog niet goed werkte. Is dat inmiddels opgelost?

Zo dat zijn weer genoeg vragen . Ik
ben benieuwd naar het 1e prototype vd scoop

Die backplane, lijkt het niet een beetje op de ruggegraat van een ouderwetse bus computer? Je steekt bij-wijze-van-spreken een cpu+geheugen-kaartje er in en een videokaartje, en je hebt een standalone scope

Die backplane, wordt toch een soort van USB IO expander, je kan er echt van alles opprikken, als je maar software ondersteuning hebt.

S-100 bus

Op 13 oktober 2005 16:59:15 schreef miniK0bo:
Die backplane, lijkt het niet een beetje op de ruggegraat van een ouderwetse bus computer? Je steekt bij-wijze-van-spreken een cpu+geheugen-kaartje er in en een videokaartje, en je hebt een standalone scope

Die backplane, wordt toch een soort van USB IO expander, je kan er echt van alles opprikken, als je maar software ondersteuning hebt.

ik ben ondertussen van gedacht veranderd : we gaan geen backlpane maken. das een extra kost. tis simpeler met flatcable te werken. dan kan je zelf bepalen hoe je de kaarten inbouwt en dergelijke. ( verticaal , horicontaal , diagonaal whatever.

de USB kaart is inderdaa een io expander. je kan daar opprikken wat je wilt. ik voorzie een address decoder en een mechanisme om kaarten te pollen 9 idere kaart kijgt een ID register , waar je kunt uitlezen wat hij precies is. zo kan de software zich automatisch mappen.

een kaart heeft 256 IO addressen. zodoende zijn er voldoende mogelijkheden. en de decoding wodrt simpel. de laagste byte van het address selecteert een reigster, de hoogste byte selecteert een kaart.

De fifos worden uitgelezen zo snel we kunnen.

softwar eondersteuning voor de expander is geen probleem. alles is modulair opgezet. de HAL heeft slechts 5 routines.
readregister,Writeregister, ReadBlock, writeblock en reset_system. daarbovenop draait een of meerder API's ( uitgevoerd als een CLASS die instantieerbaar zijn)

er is een initialisatie code die de karten afprobed en bepaald wat ze zijn en wat hun addres is. er worden dan gewoon nieuwe instaces gekreerd van de juist classes en we zijn weg. tis hoop en al 10 lijnen code.
meer is er niet.

is het niet makkelijker om jumpers te gebruiken om een ID aan een kaart toe te kennen?

Even mijn eerste gedachten:

Ik weet niet meer wat de VRAM (schuifregister+dram) chips kosten vandaag de dag, maar in mijn grafische HW tijd waren die goedkoper dan FIFO's voor hoge snelheden.

10V/div lijkt me prima, maar erg fijn is het wel als de ingang "230V AC bestendig" zou zijn.

Ik zag niet duidelijk gemeld of je een lokale delayed timebase wilde in designen. Of bedoel je dat met offset? Kan deze negatief zijn? B.v. de samples voor het triggermoment deels bewaren?

Externe trigger. Liefst zonder dat je hier een kanaal voor hoeft op te offeren.

X/Y mode. Geen echte must, maar is wezenlijk anders lijkt mij omdat er niet perse een "triggermoment" hoeft te bestaan.

Toch nog even iets over de SW, ook al ga je het waarschijnlijk in VB doen. Je hebt al veel talen opgenoemd die je niet liggen, maar C# wil ik toch even noemen. Als de GUI in C#.Net geschreven zou worden, kan het ook via Mono op andere OS-sen worden gedraaid zonder al te veel problemen. Mono als platform krijgt steeds meer support in de Open Source gemeenschap.
Maar goed. Dit is wellicht aan de mensen die dit deel moeten gaan overnemen.

Als laatste nog iets over de Logic Analyser module. 8 kanaals @ 50MHz lijkt me al heel wat voor een 100 Euro ding. In plaats van 2 analoge dan in 1 analoog + 8 bit logic level te werken is al erg nuttig. Wat voor trigger/sample condities denk je in de FPGA te kunnen supporten? Ik heb ooit met een dure Gould gewerkt en deze had heel wat creatieve mogelijkheden waar ongetwijfeld heel wat ECL logica in is gaan zitten. Ik zou niet goed weten wat hiervan naar FPGA zou kunnen gaan. Kun je de FPGA logica "dynamisch herladen" op basis van trigger of sample wensen? Of moet het meeste in postprocessing aan de PC kant gebeuren?

Meer dan 8 L.A. kanalen door losse modules te maken geeft ook weer zijn eigen problemen als je triggercondities wilt aan kunnen die "cross-module" plaats vinden.

Op 13 oktober 2005 18:30:09 schreef miniK0bo:
is het niet makkelijker om jumpers te gebruiken om een ID aan een kaart toe te kennen?

neen. de id code zit in de fpga geflashed. door de manier waarop de bus werkt komt dat dan vanzelf zop zijn poten terecht ( ik haat jumpers )

Op 13 oktober 2005 18:45:32 schreef jojo:
vanalles :
VRAM
230V AC bestendig
lokale delayed timebase
B.v. de samples voor het triggermoment deels bewaren?
Externe trigger.
X/Y mode.
C# wil ik toch even noemen. Dit is wellicht aan de mensen die dit deel moeten gaan overnemen.
Ik heb ooit met een dure Gould gewerkt en deze had heel Meer dan 8 L.A. kanalen door losse modules te maken geeft ook weer zijn eigen problemen als je triggercondities wilt aan kunnen die "cross-module" plaats vinden.

VRAM is dikke miserie. das nog altijd geen dual port ( je hebt een dead time tijdens de refresch van de DRAM . ik heb geen zin een refresh engine te ontwikkleen. veel te veel miserie, niks simpeler dan SRAM of fifo's.

230 volt protectie : dit is niet haalbaar. de bandbreedte krijgt te grote kloppen. het circuit wordt veel te complex. ( btw ik heb hier en lecroy wavemaster staan. Bij 4 volt aan de ingang gaat die kapot ! . dat ding kost 70.000 dollar ). het is aangeraden altijd 1:10 probes te gebruiken op de CO scope. dan kan ie 400 volt houden.

locale delayed: timebase. das nergens voor nodig. je kan delayed views maken zoveel je wilt op de computer. Je kan WEL het triggerpoint zetten. 100% pretrigger , 50% pretrigger of 100% posttrigger. Misschien dat ik die compleet floating maak ( das kwestie van een counter/comparator bij te steken in de fpga ). je kan dus inderdaad kijken wat er x samples voor de trigger gebeurde.

externe trigger is voorzien. ( zowel vanuit software als vanuit hardware.) combined triggers ook. je kan een complete trits qualifiers programmeren die heel specifiek kunnen triggeren.. ik ben aant nadenken om er ook time based qualifiers in te stoppen ( puls korter dan x , puls lager dan x ) das niet zo moeilijk. kwestie van comparatorcounter die triger kan afvuren. mijne fpga is toch groot genoeg.

x/y mode kan gedaan wordne in free-run mode. de kaart doet een acquisitie, je dumpt de twee kanalen , start een nieuwe ( via de software trigger mogelijkheid ) en plot ondertussen de data x/y op't scherm

c#. ik heb daar nog nooit in geprogrammeerd. dus blijf ik daar voorlopig van weg. ik schrijf de code om mijn ding te doen. als iemand anders dat wil porteren of compleet opnieuw schrijven , fijn, niet gelaten go ahead. maar nogmaals ik doet in VB omdat mij dat het minste probleen geef. (ik moet niet teveel 'zever' hebben van mijn programmeertaal als ik hardware aan't ontwikkelen ben. het grote voordeel van VB is de interpreter mode in de IDE waar je on the fly de code kan aanpassen en uitproberen zonder constant te moeten hercompileren en de run te herstarten. Geen enkele andere taal heeft dat bij mijn weten. Ik kan het programma in break zetten , twee lijnen code aanpassen of een complete routine aanpassen , de excution pointer verplaatsen en direct het resultaat zien. probeer dat maar eens in C of iets anders. en via het immediate window kan ik eender welk basic commando of routine direct laten lopen. das een geweldig voordeel bij het uitproberen van de hardware. ik kan mij concentreren op de hardware en hoef geen tijd te spenderen aan haakjes en krulletjes en typo's. als er ergens een syntax error is stopt mijn programma , ik verbeter de fout en loop verder. in C moet ik eerst alles in orde brengen voor ik ook maar iets kan proberen en das geseldig frustrerend als je met 3 dingen tegelijk bezig bent ( de fpga code , aant meten en de api aant ontwikkelen in parallel. ik kan perfect effe mijn fpga herflashen , er een testregister bijmaken om intern iets te bekijken, en via een paar commandos in het immediate venster daar dingen mee doen zonder dat ik debug code in het hoofd programma hoef te stoppen.)

Gould ben ik al een tijdje niet meer tegengekomen ( heb daar ooit mee gewerkt . zo een 8 kanaal ding met een printer bovenaan ). das inderdaad (was, nu niet meer) ECL vanbinnen.

cros module triggeren is mogelijk in mijn architectuur. ieder kaart heeft een qualify out en een composite trigger in. de backplane verzamelt alle composite outs ( waar elke kaart een eigen mask en setup register heeft , heeft een mask register om op kaartniveau te masken en vuurt een composite trigger naar alle kaarten. zo kan je een systeem wide trigger veroorzaken.

bijvoorbeeld een opstlling met 2 analoge kaarten en een digitale kaart : als ingang 1 boven de 2 volt staat , ingang 2 onder de 1 volt , op de logic inputs staat 0x000111xxx010xx0000111xxxxxx en er komt een puls op ingang 3 die langer is dan 10 nS dan moet de acquisite gestart worden (ingang 4 speelt geen rol en staat uitgemaskeerd maar kan perfect nog een andere conditie forceren.)

Het is misschien ook leuk er een frequentieteller in te steken

Op 13 oktober 2005 19:45:02 schreef free_electron:
[...]

VRAM is dikke miserie. das nog altijd geen dual port ( je hebt een dead time tijdens de refresch van de DRAM . ik heb geen zin een refresh engine te ontwikkleen. veel te veel miserie, niks simpeler dan SRAM of fifo's.
...
Gould ben ik al een tijdje niet meer tegengekomen ( heb daar ooit mee gewerkt . zo een 8 kanaal ding met een printer bovenaan ). das inderdaad (was, nu niet meer) ECL vanbinnen.

Ik zie VRAM ook niet veel meer aangeboden. Maar de NEC chips die wij hadden waren uitgerust met een schuifregister in 2 delen die je onafhankelijk van elkaar van/naar het DRAM kon klokken. We gebruikten dit niet, maar in principe kon je dus "gebroken beeldijnen" maken zonder de line-pitch te alignen met de schuifregisterbreedte. Plenty of tijd om hieromheen een refresh te doen. Meestal deed het displayen van een beeld dit automatisch al door alle adressen een keertje te "bezoeken". Maar goed ik dwaal af.

Die Gould was wel een poepie luxer hoor. 64bit @ 100MHz of 32 @ 200Mhz. Ik spreek over zeker 15 jaar geleden. Je kon een schema ingeven als: "blijf samplen, wacht op triggerconditie X, neem dan 128 samples en wacht op conditie Y, neem nog eens wat samples en dan is het wel genoeg. Maar komt conditie Z voor tijdens wachten op Y begin dan maar overnieuw want dat is niet wat je wilt zien". Hoe ze het op 200MHz voor elkaar kregen, geen idee.

Ook typisch was de uitrusting met een selecteerbare externe clock in plaats van de interne sampleclock. Er zat een 68020 probe bij die realtime de processor bijbeende en zodra aan te geven geheugenadressen werden aangesproken met bepaalde data (=triggerconditie voorbeeld), dan sampelde je met de busclock de datalijnen. De gesamplde data kon als Assembly instructies weer op het beeldscherm worden gezet. Dat was nog eens een debugger...
Een ander voorbeeld van gebruik van de externe clock was een RS232 probe. Hierin zaten 2 UARTS die een clockpuls gaven zodra 1 van de twee een byte voorbij hadden zien komen. Natuurlijk weer te listen als HEX/BIN/ASCII/EBCDIC... Leuk voor het ontcijferen van seriele protocollen van apparaten die we wilden aansturen zonder documentatie er van.

Goed. Allemaal te veel om te verwachten van een 100 Euro analyser, maar een FPGA zou best wel eens meer features kunnen bieden dan je rechttoe-rechtaan bedenken zou met concrete logica.
Post-processing aan de PC kant kan natuurlijk altijd, maar niet bij max samplerate. Dan loop je al snel de USB te flooden.

Een andere feature die me te binnenschiet die ook belangrijk was voor ons was de "glitch" detectie. Stel: je sampled op een magere 1MHz. Je ziet af en toe een level veranderen, maar wat je ziet op het beeld verklaart niet het gedrag van je schakeling. Een voorkomende bron van ellende is dan vaak een veranderend signaal op lijn A dat overspraak heeft op lijn H. Maar dit zie je normaal niet. De Gould sampled altijd op maximale snelheid en onthield dat binnen de sample momenten een niveau-change (spike) was geweest van b.v. een paar nS. Er kwam dan een speciale warning in beeld bij deze trace.

Nog een andere luxe waren de pods. Via het scherm kon je per pod instellen wat de logic levels moesten zijn. ECL, TTL, CMOS@5V, CMOS@12V of vrij instelbaar losse high en low levels. Ook hadden ze een ongelofelijk gelijke delay gespect tussen de lijnen onderling en zelfs de pods onderling.
No pressure , maar heb je al een ideetje voor de inputschakeling kwa haalbaarheid? B.v. zowel 5V logic als 3.3V logic?

Op 13 oktober 2005 21:31:31 schreef Stynus:
Het is misschien ook leuk er een frequentieteller in te steken

Softwarematig ja, hardwarematig lijkt me een beetje te ver gaan, je bent dan niet meer met een scoop bezig maar met een alles in 1 apparaat...

ik ken die dingen, je hebt nog altijd een state machine nodig om de refresh alle zoveel tijd te doen. dikke kloterij.

glitch detectie zit er inderdaad in. de samplers draaien altijd vol gas. de memory controller beslist welke sampes er gestockeerd worden en welke weggesmeten. een min/max detector houdt de stand bij van de weggesmeten samples. Als je glitch detect aanzet dan stockeert de memory engine niet de sample waarde maar de grootste afwijking tov de vorige gestockeerde samplewaarde een extra bit in het fifo wordt gebruikt om het teken te stockeren. ( de fifo is 18 bit breed. elk kanaal gebruikt 8 bit + een van de extra's om het teken te stokeren in glitch detect. )

ik heb al een paar ideen voor de input crcuit s van de analyser. maar ben eerst bezig met de scoop. ik weet dat dallas en maxim een heel snelle comparator hebben ( 900 picoseconde ) waarvan je de schmittlevels kan instellen via DC spanningen. comparator werkt tussen +5 en -5 volt. dus met een resistief delertje ervoor breng ik dat naar +15 en -15 ... en een paar octal 8bit DAC's via een i2c bus regelen de levels . ... moet dat wel lukken ja.

Op 13 oktober 2005 22:16:12 schreef klein is fijn:
[...]
Softwarematig ja, hardwarematig lijkt me een beetje te ver gaan, je bent dan niet meer met een scoop bezig maar met een alles in 1 apparaat...

hmmm. misschien dat ik dat er wel instop maar voor een andere reden: alias detectie. als de samplefrequentie onder de signaalfrequentie valt stockeer ik gewoon de min en max waardes (de omhullende). je krijgt dan een 'band' te zien optscherm net zoals bij een analoge scoop
zodanig kan je perfect gemoduleerde signalen bekijken zonder allerhande bizarre schermfenomenen. maar das niet echt een meting. tis een frequentie vergelijking van sampleclock en inkomend signaal

frequentiemeting gebeurt in de software , ofwel via cursors ofwel via seek algoritmes.

Om dit toppic niet helemaal te laten verzanden wil ik nog wel een duit in het zakje doen:

Kan er ook een voedingsspaanings connector komen waar ik een actieve probe aan kan hangen?

Lijkt mij wel handig want anders heb ik voor zo'n probe weer een adapter voor nodig.

Op 26 oktober 2005 16:49:55 schreef surge_me:
Om dit toppic niet helemaal te laten verzanden wil ik nog wel een duit in het zakje doen:

Kan er ook een voedingsspaanings connector komen waar ik een actieve probe aan kan hangen?

Lijkt mij wel handig want anders heb ik voor zo'n probe weer een adapter voor nodig.

hmmm. probleem is dat al die probes andere spanningen nodig hebben. die van HP zijn anders dan die van tek dan die van LeCroy ...

Op 26 oktober 2005 16:55:49 schreef free_electron:
[...]

hmmm. probleem is dat al die probes andere spanningen nodig hebben. die van HP zijn anders dan die van tek dan die van LeCroy ...

regelbare spanning (stand tek, lecroy, hp)?

zeg jongen. Hp heeft +9 en -5 volt nodig. tek heeft +15 -15 +5 en -5 nodig. Lecroy dan nog weer iets anders en waar ga je de interface connectoren halen ? Hp heeft zo een ronde 3 pin die custom is of via de infiniuum interface ( 8 naalden rond de bnc ), Tek doet het via hun scope interface ( 6 naalden rond de bnc en voor lecroy heb je hunb speciale mcx connectoren nodig.

da lukt niet.

Leuker zou dan zijn er zelf eentje te kunnen maken. Nu heb ik daar wel eens naar gezocht maar dat leverde niet veel op. Ja, Elektuur heeft er een jaartje (of 2) terug geloof een gepubliceerd, maar dat was een rechttoe-rechtaan Fet versterker (effectief een 1:10 verzwakker eigenlijk).
De common mode rejection zal naar verwachting niet hoog zijn. En volgens de dure probes die in de handel verkocht worden zal dit toch zijn nut wel hebben. Maar hoe die precies in elkaar zitten weet ik niet.
Jij misschien Free?

Op 26 oktober 2005 20:50:34 schreef free_electron:
zeg jongen. Hp heeft +9 en -5 volt nodig. tek heeft +15 -15 +5 en -5 nodig. Lecroy dan nog weer iets anders en waar ga je de interface connectoren halen ? Hp heeft zo een ronde 3 pin die custom is of via de infiniuum interface ( 8 naalden rond de bnc ), Tek doet het via hun scope interface ( 6 naalden rond de bnc en voor lecroy heb je hunb speciale mcx connectoren nodig.

da lukt niet.

srry ik wist niet dat ze zo erg verschilden (ik dacht alleen dat de spanningen verschilden en over de connectors wist ik niks)

Op 27 oktober 2005 01:02:04 schreef jojo:
Leuker zou dan zijn er zelf eentje te kunnen maken. Nu heb ik daar wel eens naar gezocht maar dat leverde niet veel op. Ja, Elektuur heeft er een jaartje (of 2) terug geloof een gepubliceerd, maar dat was een rechttoe-rechtaan Fet versterker (effectief een 1:10 verzwakker eigenlijk).
De common mode rejection zal naar verwachting niet hoog zijn. En volgens de dure probes die in de handel verkocht worden zal dit toch zijn nut wel hebben. Maar hoe die precies in elkaar zitten weet ik niet.
Jij misschien Free?

Ik was namelijk van plan om dat elektuur ding na te bouwen is trouwens uit het oktober nummer van vorig jaar
linkje:

http://www.elektuur.nl/Default.aspx?tabid=27&year=2004&month=1…

Ok. Dan toch de hamvraag:

Hoe wil je uberhaupt als hobbyist aan de benodigde onderdelen komen??? Kan me herinneren dat indertijd toen die 60MHz logic analyser van elektuur werd gepubliceerd ook zowat niemand aan die FIFO's kon komen. En dat waren nog maar erg kleine FIFO's. Hier moet je daarnaast gaan klooien met FPGA's ed. Hoe ga je die programmeren?

En bovendien denk ik dat mensen wel heel erg graag hier voor een dubbeltje op de eerste rij willen zitten. Veel samples/s kost nou eenmaal geld! En ik denk haast ook dat veel mensen veel te simpel denken over dat soort samplerates.

Ik ben er zelf toch fors voorstander van om eerst een vrij eenvoudige PC scope te ontwerpen. Zoiets als een 1 kanaals 10 MSamples/s scoopje die je direct (1 printje dus) op de PC kunt aansluiten. Dat is nog met vrij standaard onderdelen te maken en zijn je FIFO's tenminste niet zo enorm groot. In eerste instantie zou ik ook uitgaan van bediening via de PC.

Eventueel in een later stadium zou je een uitbreidingsprintje kunnen ontwikkelen met zijn eigen uC die met de hoofd uC communiceert via bv SPI om de parameters zo in te stellen.

Hogere specs zou ik persoonlijk voorlopig niet aandurven. Begin simpel. Uitbreiden/aanpassen kun je altijd nog.

Op 27 oktober 2005 14:29:05 schreef dexter:
Ok. Dan toch de hamvraag:

Hoe wil je uberhaupt als hobbyist aan de benodigde onderdelen komen???

Free_electron had al gezegt dat ie z'n hele ontwerp maakt naar de digikey catalogus, dus dat wordt denk ik een simpele inkoopactie als het ontwerp klaar is.