Ilyenre is át lehetne rakni? Minap találtam a panelek között, meg vannak Cyclone 3 FPGAim.

És ezt át tudod forrasztani úgy hogy jó is legyen, és páciens is túlélje????

Manapság mindent meg lehet oldani, több ismerősöm is foglalkozik bga forrasztással

Megvásároltam a Hantek DSO2D10 oszcilloszkópot, szerintem a 72000Ft-ot nagyon megérte. Van rajta még jelgenerátor is.
Így már nem gondolkodok építésben sem.

6 éve építettem egy digitális szkópot:
A méregdrága Microchip demó kijelzője tönkrement, nem tudtam pótolni, Most elővettem az analóg panelt és egy raspberry pi -re írtam egy python kódot a Tkinter felhasználásával. A Microchip kijelzője a 320x480 képet kb 10fps-sel tudta frissíteni addig a tkinter csak 1 azaz 1 fps-sel, meg kell rajzolni 400x256 képpontot kell összekötni vonallá 2x a két csatornára, majd újra rajzolni feketével hogy az előző ne látszódjon majd újra rajzolni a hátteret, nem kevés.

Milyen olcsó hardwer vagy program raspberry-re lenne jó ami nagyon gyorsan tud rajzolni?
Készítettem egy szkóp demót javascripttel ez nagyon gyors de nem tudom hogyan tudnám beletolni az adatokat, pedig jó lenne mert egy telefon is lehetne a képernyő:
Bővebben: Javascript szkóp demó

Lassú kommunikációs lehetőségeknél más megjelenítési módot kell használni!
Pl, kirajzolod a két csatorna vonalait, ez még azért elég gyors művelet..., majd a teljes képernyő törlése helyett újrarajzolod ugyanezt, de háttér színű vonalakkal! Ekkor eltűnik a régi ábra, mintha csak törlést végeztél volna, csak jóval gyorsabban végezve vele! Innentől rajzolhatod a normál csatorna színekkel az új adatokat... Nagyvonalakban ennyi.

Nem törlöm a teljes képernyőt ennyire kezdő nem vagyok. Úgy van ahogy leirtad.
Canvas.create_line(x1, y1, x2, y2, fill="green")
Így rajzol a Tkinter vonalat, a javascript így:
ctx.beginPath();
ctx.moveTo(0,0);

for(var i= 0; i<480; i++){
ctx.lineTo(i,256-y[i]);
}
ctx.strokeStyle = '#00FF20';
ctx.stroke();

Az utolsó sorra jelenik meg az ábra,

Tudom hogy lehet pythonnal gyorsan rajzolni, pl a cura is azzal van megírva, ez egy gkód konvertáló 3d nyomtatóhoz, a 3d modelleket nagyon szépen lehet vele forgatni, az WX nevű GUI-t használ nem Tkintert
Megmutatom a programot, a fifo ram-okból kiolvasom az adatokat mikor megtelt 1024 byte adat, majd az első 540 adatban keresek egy trigger pontot ahonnan ki tudom rajzolni a képernyő 480 oszlopát.

Én a helyedben ebbe az irányba mennék el. Kell egy stream forrás, ami tolja az adatokat, erre meg már vannak kész megoldások. De most gondolatébresztettél amúgy, ennek én is utána fogok nézni, mert pont kapóra jönne az egyik projektemben

Amit leírtál ott, az nem éppen erről a megjelenítési módról szólt, amiről beszéltem...! Amit leírtam, abban sehol sem törölsz effektíve, csak a legszükségesebb helyen újrarajzolsz! És mivel a teljes kép csak kis része változik kockáról kockára, így átlagban jó nagy a nyereség...

Majd tanulmámyozom. Elkészíthető akkor egy digit szkóp amely nodemcuról megy, és a telefon a kijelző wifin keresztül?

Ha javascriptes (webes) megjelenítést szeretnél, akkor websockettel tudsz vele aránylag kisebb késleltetéssel kommunikálni, de az se lesz szerintem elég gyors.

Ha pythonnal rajzolnál, akkor ajánlom a pyGame használatát, az SDL-el rajzol, azaz kihasználja a hardveres gyorsítást is. Ha egy játéknak elég fps-t tud, akkor egy grafikonnal se lesz baja.

Egyszerű megoldások még: C# és mono, vagy Pascal és lazarus, mind a kettő fordít és fut linuxon (ARMen is) és szinte biztos, hogy van hozzájuk ilyen komponens ami ezt kirajzolja neked gyorsan.

Kipróbáltam jó lett, 256x480 as képernyőt a két csatornával 300ms alatt frissít, ebből 150ms a 2048 adat beolvasása a két RAM ból, elég lassú a raspberry gpio kezelése, mint az arduino digitalWrite megoldása.
Kezelőgombokat (radiobutton) kellene még létrehozni pygame alatt.
A programozása is egyszerűbb mert újra rajzolja ciklikusan a képernyőt, de mégis gyors

Hát igen, sajnos ezen a Linux is lassít amiért nem valós idejű ugye, mint egy kontroller esetében. DMA-t nem tud amúgy a pi? Az sokat tudna rajta gyorsítani, ha lenne esetleg, de erről nincs információm.

Szerkesztés: ja, most esett le, hogy RAMból való olvasás esetén nem feltétlen segítség, ha van dma.

Csak gyorsabb, kifelejtettem hogy a mintavétel is időbe telik, ha a legnagyobb 40Ms/s akkor akkor 10fps a képfrissítés több nem is kell. A tkinter egy másik panelon fut az vezérli az analóg panelt, fapados de nekem így jó. Ha a kép jobb sarkába belekattintok akkor ott megjelenik egy kék vonal ami a szinkron szintet állítja be. Hogy tudjak mérni még azt szeretném hogy ha belekttintok a képbe akkor elmentse a kordinátákat egy fájlba, azt pedig beolvasom egy gombnyomással a DSOPanelen (mert ott tudjuk a beállításokat), így ott ki tudom íratni a feszültséget és az időt.

Kicsi zajos jel így látszik a képen egy analóghoz képest, nem is jó de nem is rossz.

Egy bit hiányzott, ilyen a kép hogy javítottam, tudom magamban beszélek csak nem akarom hogy egy rossz kép maradjon fent.

Magadban beszélsz ez igaz, de azért van aki hallgasson!

Hogyan állítottad össze a cuccot? Mi végzi az átalakítást?

A bemenete osztó olyan mint a hagyományos oszcilloszkóban, kompenzált feszültségosztó, természetesen szabványos 1/10 es mérőkábellel, azután van egy jfet bementű műveleti erősitő, utána egy 74HC5051 analóg kapcsoló a finom osztáshoz, mégegy gyors műveleti erősítő, ez végzi az offszet eltolást a egy digitális poti meg egy invertáló műveleti erősítő segítségével, a jel TLC5540 párhuzamos A/D átalakítóra kerül, a 8 bites kimenete egy MK45H120 fifo RAM bemenetére kerül, ennek a ramnak van párhuzamos be és kimenete, nincs címzése csak az adatbelépést egy órajel bemenet végzi, mikor megtelt jelzi egy lábon, a memóriája 1kB 2x akkora mint a képernyő szélessége, az adat kiolvasását egy másik órajel bemenettel lehet elvégezni, az órajelet 400Hz és 40MHz között egy p8x32a proci belső pll áramköre adja, végez még portbővitést a reléknek és az analogvkapcsolóknak, illetve i2c a digit potinak. Mikor megtelt a ram akkor egy raspberry kiolvassa mind az 1024 bájtot amit eltárol egy tömbben, maj az elsò felében keres egy trigger pontot, a szintet és a slope ot is be lehet állitani valamint a pretiggert is így a trigger előtt is láthatjuk mi van. A képernyőre rajzolást raspberry pi vel van, a pygame python modul rajzol, illetve fut egy tkinter nevű gui is, ez uart on keresztül vezérli a p8x32a procit mint emlitettem beállitja a mintavételt, kapcsolgatja a reléket stb, illetve a két futó alkalmazás között egy text fáj tart kapcsolatot meg 2 pár összekötött gpio láb hogy a kurzorral mért érték helyes legyen. Egyébként két csatornás.

Ez igen! Azért ez nem kicsi projekt! Tervezel belőle cikket közölni? Én biztosan nagyon örülnék neki!

Még nem írtam cikket, az analóg panel régebben készült (mivel a kijelző része tönkrement, kidobtam hogy ráértem visszahoztam a "kukából" gondoltam csak életre keltem a 20 IC-t tartalmazó panelt, mert sok munka volt vele) most már egyrészt korszerűbben megoldható (órajel), másrészt fifo ram-ot nem gyártanak csak ebay-en lehet még kapni de abból is a leggyorsabb rank jó csak, ahhoz képest hogy próbapanelen van öszerakva, ami meglepő hogy látom zajmentesen hogy a múltkor épített rádióm első erősítőfokozatán 10mVpp jel, van ,ezt a gyári márkás digit szópon is láttam de saját zajából kellet kivenni itt egy pixel zaj sincsen. A kapcsolást is vissza kell rajzolnom, itt a nyák terv is fontos meg a GND kialakítása, de a 3 programot ami működteti azt ide is felrakhatom.

Mindent egérről lehet kezelni, kivéve a RUN/HOLD az maradt nyomógomb hogy gyorsan rá lehessen csapni, biztos jó jönnem még más funkciók is de azok csak lassítanák a rajzolást, esetleg egy X-Y módot nem nehéz leprogramozni, illetbe a raspberry SPI portja szabad így a dobozban még elférne egy AD9833 - mal egy funkciógenerátor.

Nem akarlak elkeseríteni, mert sok munkád van benne..., de ez még így mindig a kb használhatatlan kategória! Ránézve a szkópábrára te meg tudod mondani, tiszta sin a jel, vagy van rajta tüskék hada??! Mert ha ilyen a jelforrásod - dobd ki, vagy szűrd meg előtte! Ha az kifogástalan jelet ad, akkor viszont visszakanyarodunk az elejére...
Egy szkóp akkor ér valamit, ha megbízhatóan mutatja a pillanatnyi helyzetet, jól determinált hibaértékkel ábrázolva azt. Ha ezt nem tudja, csak egy játékszer marad, de nem műszer....

Nem akarok meg nem is tudok egy gyári több évtized munkájával kifejlesztett gyári szkóppal versenyezni, nincs is értelme mert már 80ezerért lehet kapni, ha nagyon akarok veszek egyet, meg a munkahelyemen van egy köbméter mindebféle szkóp, az előbbi képemen tényleg van egy tüske hogy azt most a rádióból jövő zaj volt vagy a szkóp tévesztett nem tudom, de igazából mindegy. Ha visszaolvasod 2006 óta a topikot más mit tudott elérni? (Egy kivétellel)

Olvasgatva az utolsó kommenteket, meghoztad a kedvem, hogy én is elővegyem a 2014-ben eltett szkópot aminek nekifogtam Az egy két csatornás USBs szkóp 100Msps ADC-vel, SRAM-al, CPLD-vel és egy PIC32-essel A HW megvan és elvileg működőképes csak a SW kellene rá + a számitógépes interfész...lesz vele még munkám bőven

BUÉK! Van pár MCM6290 16k*4bit SRAM-om. Nem túl lassúak, 15ns. Egyszer egy távoli galaxisban úgy gondoltam építek én is házilag szkópot, de már elmúlt. Szóval akinek kell kap egy csôvel. DIL24 tok. Számlálókkal gondoltam hajtani.

Hogyan működne?

BUÉK!
Az elgondolás az volt, hogy legyen egy mikrovezérlő ami USB-n kommunikál PC-vel és mellette vezéreljen egyebeket is leszámítva a mintavételezést mert akkora frekvenciákra egyik mikrovezérlő se képes. Mivel akkoriban nem voltak ennyire gyors mikrovezérlők mint manapság és többnyire csak PIC-ekkel foglalkoztam ezért maradt a PIC32MX440 a maga 80MHz-es sebességével ami édeskevés egy jobbacska szkóphoz.
Ehhez kellett egy gyors ADC (pl 100MSps - 8bit / csatorna), egy RAM amiben el lehet tárolni a mintákat (64k x 16 bit (8 bit /csatorna) ha jól emlékszem) és valami ami képes másolgatni az adatokat ADC-ből RAM-ba és ehhez jött a CPLD (XC9536XL) ami egyszerűbb és olcsób, mint egy FPGA, mert hogy ez egy diplomadolgozat volt és szerettem volna a lehető legolcsóbban megoldani, hogy aztán majd hobbiként használjam itthon méricskélésekre.
A RAM-ra azért lett szükség, mert az USB-n nem lehet(ett) annyi adatot küldeni egyszerre mert csak FullSpeed USB-t tud a PIC ami elvileg 12Mbps ha jól tudom.

Az egész folyamat úgy nézne ki, hogy a PIC beállít mindent (a PC interfészből) pl analóg kapcsolók/multiplexerek a bemeneten, jelerősítés PGA-val ADC előtt, DAC stb, meg CPLD, ADC és RAM kontroll jelei, majd ezután elindítja a mintavételezést amit tovább a CPLD végez ameddig megtelik a RAM, ezután a PIC szépen kiolvassa az adatokat a RAM-ból és továbbítja a számítógépnek USB-n, és ahogy ez minden hasonló szkópnál így van, ez idő alatt természetesen nincs mintavételezés.

Jelenlegi fejjel és lehetőségekkel a PIC-et és a CPLD-t egy gyors ARM procira cserélném esetleg FPGA-val kisegítve és egy dedikált HighSpeed vagy SuperSpeed USB meghajtóval gyorsabb adatmozgatás miatt, persze a RAM és egy jó ADC megmaradna, mert azok nélkülözhetetlenek, de ez csak valamilyen unaloműző projekt esetén mert a befektetett fejlesztési idő és energia miatt most már nem érné meg, sokkal kevesebbe kerül megvenni egy jól kifejlesztett kész terméket.
Elnézést kérek, hogy ilyen hosszas lett, de ennél rövidebben nem tudtam megfogalmazni a teljes működési elvét

BUÉK!
Az XC9536-hoz az én forrásom használod? (2014 Jan22. 103old.) Itt.
Azért kérdezem , mert a forrásban találtam egy jó nagy bakit. Több mint 2 hetem ráment, mire rájöttem, hogy a probléma forrása ez lehet. A probléma az, hogy a GTS1=0-nál a CPLD lábai nem mennek 'Z' nagy impedanciás állapotba. Most javítom a forrást. Ez a hiba okozhatja akár a CPLD, akár a mikrovezérlő tönkremenetelét !!! A régi szimulációs ábrákon is látható ez, de ennek nem tulajdonítottam nagy jelentőséget, mert azt hittem, hogy a testbench fájlt írtam meg rosszul. Gondoltam ezt eddig, de nem. Addig amíg ellenállások voltam a CPLD lábain nem is volt gond. Az SRAM-ot tudta a CPLD és a mikrovezérlő egyaránt címezni. Az új áramkörömnél az ellenállásokat elhagytam és ezután rögtön jött a címzési probléma.
Én kisebb teljesítményű eszközöket használok. Vissza nézve a fórumot 2012-2014 megtalálhatóak a részletek. Szeretnék egy cikket írni belőle. Nem az után építhetőség lesz a célja a cikknek, inkább csak kedv csinálás saját fejlesztések indításához. Gondolok itt arra, hogy a PCB nyákrajzolat tervet nem fogom közzé tenni. Lesznek mikrovezérlő, CPLD források, kapcsolási rajzok, de a nyákot aki akarja tervezze meg magának. Azon vagyok hogy minél előbb közzé tehessem.

Igen, ahogy gyanítottam a CPLD lábai a GTS1=0-nál nem mentek 'Z' állapotba csupán 'L'-be. Ennek hatására a dsPIC nem tudta címezni az SRAM-ot. Micsoda egy alattomos hiba, mert önállóan az alkotó részek jól működtek. 2 hetem ment rá.
A mintavételezett jel nagyon zajos jelenleg. Minél nagyobb a mintavételezési frekvencia annál nagyobb a zaj. Nyilván a CPLD forrásán kell még leginkább farigcsálnom.

Szia,
Köszönöm a figyelmeztetést, de ha nem haragszol akkor nem a te forrásod használtam a CPLD-hez mert az enyémnek teljesen más a kapcsolási rajza, bár a CPLD pontos típusa ha jól emlékszem valóban a te szkópod kialakításából vettem, mert akkor az volt az egyik legelterjedtebb ár és tudás arányban.
Örvendek, hogy sikerült megtalálni egy ilyen problémát ennyi idő elteltével.
A többiek nevében is hálás vagyok, hogy egy ekkora projektet közzé akarsz tenni, ez nagylelkü dolog a részedről. Majd ha én is előveszem a szkópom és befejezem a fejlesztését akkor lehet hogy én is írok egy cikket róla, bár amennyi idő eltelt azóta nem hinném, hogy sokat segítene valakinek, mert szerintem most már nem is kapható az akkori alkatrészek nagy része és ennél sokkal jobbat lehetne most csinálni