_pv

А как вы хотели сохранять данные изначально, руками нажимая на кнопки на осциллографе во вставленную в него флэшку? То есть это один раз надо сделать, а не автоматически из скрипта с ПК? там всё получение данных состоит из следующих команд, и им должны должны быть соответствующие аналогичные менюшки/кнопки на морде. self.write(":STOP") self.write(":WAV:POIN:MODE RAW") self.write(":ACQ:MEMD LONG") trig_mode = self.ask(':TRIG:MODE?') self.write(":TRIG:"+trig_mode+":SWE SING") //!режим у тригера должен быть sweep enable self.write(":RUN") self.waitForStop() self.write(":STOP") где waitForStop просто ждет изменения статуса def waitForStop(self): while self.ask(":TRIG:STAT?") != 'STOP': time.sleep(0.5)

там какие-то грабли вроде были с режимами триггера чтобы он именно в так называемую "long memory" писал

да вроде там на 1М отсчётов должно быть памяти https://github.com/dstahlke/rigol_long_mem

Да можно пожалуй и без серверной части вообще, без питона и без руби, просто тупо из браузера. https://whatwebcando.today/serial.html Правда совсем без js не обойтись. И с некими дополнительными танцами с бубном упаковать всё в один кроссплатформенный оффлайн-html файл. который можно с просто диска открывать как file://, а не с локального сервера, там со всякими CORS вроде не до конца ещё гайки закрутили, как-то работает. Гуй опять же рисовать возможно проще. А что-то и в webassembly собрать можно, чтобы богомерзкий js по минимуму использовать. p.s. для труЪ кроссплатформенности ещё есть cosmopolitan libc, позволяет собрать один бинарник который запускается вообще везде.

https://www.jamieiles.com/80186/ 1800 ALM пятого циклона в ep4ce6 вроде как раз поместиться должны. https://marsohod.org/projects/marsohod2/amber-arm-soc даже линукс вроде запустили на древнем ARMv2 а вот кортекс, особенно m3/m4 как небольшой МК внутри плис идея как по мне не очень. если так не нравятся "родные" nios или micro/pico blaze, есть ещё всякие openMSP430/neo430, относительно небольшие, и средствов разработки/компиляторов хватает готовых.

разборки с шумами по-хорошему с набора гистограммы в "статике" (на закороченном входе) начинать надо. а потом уже разбираться c "динамикой", откуда там берутся 2/3 гармоники, из АЦП, входного тракта или это сам генератор такой.

бывает, только цены не понравятся, https://www.ni.com/nl-nl/shop/category/multifunction-io.html?page=1&BusTypeFormFactor=PCI Express&BusTypeFormFactor=USB&foc=2 https://rudshel.ru/ по сравнению с теми же осциллографами, https://eu.rigol.com/eu/products/products/oscilloscopes которые даже у самых младших моделей, десятки млн сэмплов запоминать умеют, и вроде с указанной в начальном посте задачей должны справиться. ешё как промежуточный вариант - оценочные платы АЦП от ti / ad, но там что-то с софтом придётся изобретать, то что идёт в комплекте обычно использовать невозможно, ну и стримить непрерывно данные не все умеют.

старенький он уже: Были какие-то usb hantekи которые внутри на cy7c68013, без памяти и непрерывно тупо слали отсчёты в ПК. Но какой-нибудь почти любой китайский обычный осциллограф за <200$ пожалуй всё равно лучше будет и с памятью на на несколько млн. отсчётов найти можно. Можно ещё такое же "из говна и палок" на каком-нибудь pi pico или blue pill за пару $$ собрать, 1msps ацп который будет непрерывно в usb данные пихать без буферизации, в full speed 8бит х 1мспс поди пролезет, но это на случай если совсем заняться больше нечем. Я как-то похожий "самописец" из какой-то готовой оценочной платы для АЦП (16бит х 1мспс) и ft232h собирал, но там ряд требований был по синхронизации и по шумам, что проще было так чем какой-то готовый USB DAQ искать.

Ну если действительно картинка статическая, то желание подключить её к, грубо говоря условному AVR, который медленно и печально будет изредка её обновлять впринципе как-то, хоть и с трудом, но оправдать можно. Сам как-то довольно давно хотел попробовать в обратную сторону, из каких-то сенсоров изображения (особенно которые сами в jpg умеют) неспешно изредка картинки забирать через mipi-lp какими попало МК, без гигабитных трансиверов на борту, но документацию, точнее её отсутсвие тогда победить не смог.

У mipi там физика ещё своя "неприятная", даже не lvds. И это не говоря о том, что выше. Изображать такое самостоятельно - то ещё развлечение. Ну из начальной постаноки вопроса вроде следует что "месье знает толк в извращениях".

у mipi там есть LP режим, который не очень высокоскоростной и не совсем дифференциальный, 10МГц вроде, и 1.5В LVCMOS, и его некими костылями можно попробовать изобразить ногодрыганием и/или через SPI, но вот данные для отображения контроллер монитора скорее всего через него принимать не будет.

в winxp помнится синий экран вызывал какой-то пролифик или его китайский клон, если переходник просто выдернуть из USB при открытом порте в любой программе. так что не надо недооценивать возможности корявых драйверов.

в даташите есть 2246 G08: LTC2246: Grounded Input Histogram, 25Msp, с среднеквадратичным отклонением 1.107 lsb. по вашей картинке с кучей графиков сложно на глаз гистограмму строить, но p-p шум ~8 lsb, делённый на 6 = 1.33 примерно соответствует заявленному в даташите.

там же черным по белому написано git clone --recurse-submodules

там данные через уарт отдаются... #define B(x,i,j) (((x)&(1<<(i)))?(1<<(j)):0) #define SWAP(x) (B(x,0,6)|B(x,1,5)|B(x,3,4)|B(x,4,3)|B(x,5,2)|B(x,6,1)|B(x,7,0)|B(x,8,13)|B(x,9,12)|B(x,10,11)|B(x,11,10)|B(x,12,9)|B(x,13,8)|B(x,14,7)) uint16_t y = SWAP(x);