Это тоже самое, что Hantek DSO5202B, только имеется 16-канальный логический анализатор. Ну как анализатор, просто 16 каналов для визуализации логических сигналов. Анализировать протоколы он не умеет.
Был у меня такой (с полосой 100МГц), тоже повёлся на встроенный лог.анализатор с вроде бы очень неплохими параметрами. Казалось бы самое то для отладки микропроцессорных устройств. Но кажется практически ни разу серьёзно так и не воспользовался, всегда что-то мешало: или памяти мало (чаще всего пожалуй); или каналов мало (обмен с той же SDRAM посмотреть уже не очень получается); или глюки были на фронтах/спадах сигналов, чего лог.анализатор не видит и просто "съедает"; или хватало двух каналов осцилла (иногда с отдельным запуском), зато сразу с формой сигналов; или тупо лень было подключаться щупами к smd деталям и проще было щупом осцилла тыкать и сразу смотреть; или ещё что-то. Иногда было жаль экранной площади, предпочитал больше под форму сигнала отдать чтобы подробнее рассмотреть (переколебания или сдвиг фаз). К сожалению уже не помню можно ли там запускать осцилл по триггеру лог.анализатора (надеюсь можно), вот эта фича обалденная, можно в подробностях рассмотреть сигналы вокруг глюка (по коду совсем других сигналов). Но жаль что запуск лог.анализатора невозможен по логическому условию, а только по (не)совпадению с маской, по двум вариантам маски уже не запустишься (и например кажется нельзя запуститься по перепаду одного или нескольких сигналов при заданных уровнях других, банальную START/STOP в I2C не отловишь). Но даже так отловить момент глюка в цифровом протоколе сильно легче.
Потом несколько раз в особо сложных случаях, когда осцилл не помогал разобраться, пользовался отдельным лог.анализатором (совмещённого уже не было), чем он оказался лучше встроенного уже не помню, но всё писалось в комп и там уже долго и мучительно исследовалось на глюки. Видимо условие глюка было недостаточно простым чтобы сразу его увидеть, писались специальные утилитки по анализу лога (глазками просмотреть сотни килобайт малопонятной "каши" трудно) или преобразованию лога в протоколы и где они находили аномалии, там уже подробно разбиралось глазками. Хотя без встроенного анализатора протоколов (и запуска по артефактам или условиям уже протокола) польза от него заметно меньше: приходится писать всё подряд и потом постфактум разбираться а записан ли собственно глюк ... (при длине записи в доли секунды с хорошей дискретизацией попасть на глюк ручным запуском весьма проблематично) и повторять до получения результата.
(Идеальный логический анализатор)
Ещё лет 20 назад в курилке на работе обсуждал с народом создание анализатора с FPGA плюс стандартный DIMM, чтобы писать сразу 32-64 канала в SDRAM объёмом в сотни мегов или гиги. Вот там сразу закладывались и всегда максимальная частота дискретизации (100 или 200 МГц смотря какой тип SDRAM) для надёжной регистрации всяких пичков и переколебаний (для медленных сигналов производилось сжатие повторов) и огромная длительность записи (секунды-недели, смотря как часто менялись сигналы) и большое разнообразие условий запуска (не просто совпадение по маске, FPGA же, ей несложно и гораздо сложнее условия). Но за все годы так и лень было доразвести плату и написать прошивку контроллера, хотя пара знакомых таки собрала себе нечто подобное (правда по готовым проектам из инета). Меня даже больше останавливала не сложность разводки платы с 200МГц сигналами или написание прошивки для МК, а сложность интерфейсного ПО на компе (а готовые или закрытые или уродские).
В общем, по своему опыту отладки цифровых устройств на МК (я ж программист), лог.агализатор нужен на два-три порядка реже осцилла. Но иногда, когда его возможностей хватает и не лень им воспользоваться, он буквально спасает. Тем более если встроен/спарен с осциллом в realtime.
А уж если он достался Вам фактически бесплатно или около того, то это
однозначно плюс. А для анализа медленных протоколов (менее мегагерца или сотен кГц, а таковых немало) есть много простеньких поделок чуть ли не на ардуино (или даже на программаторе PicProg).
, но не нашел вариантов, чтобы и полоса до 200 МГц и Equivalent Sampling был, и памяти на 10М выборок.
Но между полосой и памятью полоса пожалуй важнее, а уж вам тем более.
Вариантов много.