Страница 1 из 2

Многоканальный (> 6) цифровой осциллограф через LPT (EPP)

Добавлено: Вс апр 08, 2007 21:40:31
dem-vr
Помогите с работающей программой.
Надо отсканировать сигналы(относительное время на четырех периодах по 5 мс) по 6-8 каналам
На интервале 5 мс. происходит от 10 до 50 событий в 6 каналах.

Добавлено: Вт апр 10, 2007 19:27:45
Mamonth
С работаеющей программой не подскажу, однако направление: к нулевому кольцу защиты мастдая...

Добавлено: Вт апр 10, 2007 20:26:25
Сэр Мурр
Так вроде есть программы анализатора цифровых сигналов через ЛПТ. Кому-то даже ссылку давал.

Добавлено: Пт апр 13, 2007 19:41:55
dem-vr
Есть digan.exe - под DOS, но при длительности менее 1мс гонит мусор.
ulog20d - тоже под DOS, прекрасная штука, но каналов мало.

Под ХР "LPT 3D HARD ANALYZER - программа 17 канальный запоминающий цифровой осциллограф через (LPT 1-3) порт_ 95-98-ME-NT-2000-XP.htm"
но по быстродействию не тянет.
Появились аппаратные USB-OSC - но для разового применения дорого!

Добавлено: Пт апр 13, 2007 19:54:19
Мышонок
Насчёт быстродействия и т.д. гляньте здесь: http://www.radiokot.ru/forum/viewtopic.php?t=3833 , конкретнее, особенности цифровых осциллографов. Это также относится к любой цифровой обработке аналоговых сигналов.

Это надор многим!!!

Добавлено: Ср май 02, 2007 19:46:06
dem-vr
http://www.xs4all.nl/~jwasys/old/diy2.html
Digitrac.exe - эта программа работает под ХР и через порт принтера дает по 8 каналам 1 млн. измерений в секунду.
Это надор многим!!!

Добавлено: Ср май 02, 2007 21:43:25
ARV
1 миллион в секунду через LPT порт?!?!
НЕ ВЕРЮ!!!
Кстати, по указанной ссылке сказано "up to 1 million samples per second, depending on your hardware" - т.е. "до 1-го миллиона отсчетов в секунду в зависимости от вашей аппаратуры". Извините, но 1 отсчет в секунду - это тоже "ДО миллиона" :)

Реально я проверял быстродействие обращения к LPT из-под Win9x и WindowsXP и могу утверждать с гарантией: даже в режиме прямого доступа к памяти (что вообще-то говоря уже большая сложность под WinXP без отдельного драйвера) реальная скорость ввода-вывода практически не поднимается выше 500-600К в секунду. К тому же неизбежны пропуски отсчетов, связанные с тем, что непрерывно и бесконечно вести в память нельзя, время от времени приходится прерываться на работу самой операционной системы и записи на винт.
Лично я достиг в своих программах задержки между отдельными ображениями к порту где-то на уровне 10 микросекунд, т.е. частота 100 кГц. В идеальных условиях - наверное можно и 1 МГц достичь, но верится с трудом...
Рискну проверить на эту прогу... Буду рад оказаться неправым...

Добавлено: Чт май 03, 2007 08:08:14
ARV
Получил первые грубые результаты:
1. Программа устанавливается криво - надо взять "новую установку", установить все, затем взять архив "старой" и из него скопировать все DLL в папку "новой", только после этого программа запустится.
2. При первом запуске программа ругается - какие-то ошибки драйвера, потом их нет.
3. Программа каждый раз при старте автоматически вычисляет период опроса каналов и показывает его. Проверял на двух компах с WinXP SP2: Pentium IV 3,2GHz RAM512M и Pentium D 2,66GHz RAM1G. Пока что на обоих показывает период опроса 1,48 мкс (если даже мышь не шевелить). Если шевелить мышку - период опроса увеличивается. Если запущен WinAmp - период становится на обоих компах 1,68 мкс.
4. Программа содержит ошибку в отображении диаграмм, даже ранее сохраненных в файле: не зависимо от того, с какой частотой опроса был снят график, показывается он так, как будто снят с текущей. Т.е. один и тот же файл данных без запущенного WinAmp показывается как снятый при опросе через каждые 1,48 мкс, а с WinAmp уже становися снятым при 1,68 мкс... На более слабом компе график будет показан совсем не так, как на более быстром.

На реальном сигнале пока не проверил, к обеду постараюсь.
Первые выводы: вызывает сомнение тот факт, что на довольно сильно различающихся по производительности компах программа показывает одну и ту же частоту опроса. Как я и думал, налицо явная связь с загрузкой системы - это обязательно даст погрешности в работе. Ошибка отображения уже дает непредсказуемую погрешность не меньше 10%, что практически исключает использование ранее сохраненных диаграмм. Реальная скорость опроса отличается от заявленной (компы довольно неслабые) - максимум 676 кГц (близко к моим предварительным оценкам).

Проверю на реальном сигнале - сообщу.

Добавлено: Чт май 03, 2007 11:55:09
ARV
Провел тестирование на реальном сигнале.
Отчитываюсь:

1. На вход подавал сигналы с обычного двоичного счетчика, самая высокая частота 104 кГц (период около 9,6 мкс)/ На рисунке 1 осциллограмма входных (фактических сигналов), снятая качественным осциллографом. На рисунке видны два вертикальных зеленых пунктирных маркера, которые "отмеряют" фактический период верхнего сигнала - справа параметр Delta и есть реальная длительность периода.
2. Программа работает в режиме порта SPP и EPP+ECP (оба проверил), обязательно сделать в настройках Divisor=1 и PreTriggerDelay=1 (Divisor можно больше, но точность измерений высокочастотных сигналов будет хуже).
3. Программа искажает 100 кГц-овый сигнал - это видно по рисункам 2 и 3. На рисунке 2 красными маркерами так же выделен период верхнего сигнала - видно, что показания программы не соответствуют фактической длительности сигнала (врет неимоверно).
4. Есть искажения и по форме - самый высокочастотный сигнал (104 кГц) несимметричный, хотя входной сигнал - чистый меандр.

Выводы.
1. Программа работает.
2. Программа при периоде опроса (по ее собственным заверениям) 1,45 мкс довольно сильно искажает фактические сигналы (по расчету в периоде 100 кГц-ового сигнала должно уложиться 6,5 отсчетов, а фактически - всего 4).
3. Курсорные измерения в программе так же врут неимоверно (почти в 2 раза).
4. На низкочастотных сигналах я не проверял, но думаю, что погрешности, естественно, снизятся.

Итог.
По-моему, программу нельзя использовать для исследования сигналов с частотой более 20 кГц, т.к. погрешности могут быть недопустимыми. Так же не следует доверять показаниям этой программы, если нет настоящего осциллографа (показания плавают как от производительности процессора, загрузки системы, так и по неизвестной причине).

Думаю, когда я говорил "НЕ ВЕРЮ" - я был абсолютно прав. Надеюсь, все, кто станет использовать этот анализатор, благодаря моим исследованиям не попадут в неприятное положение.

Добавлено: Чт май 03, 2007 18:07:28
Сэр Мурр
Товарищу ARV- кусочек омуля и стопку валерьянки за проделанную работу. Учитесь, граждане, как надо делать по принципу "доверяй, но проверяй!"
Спасибо от имени администрации сайта. :)

Добавлено: Чт май 03, 2007 18:12:45
tych
ARV писал(а):когда я говорил "НЕ ВЕРЮ" - я был абсолютно прав.
Всё подвергай сомнению !

Кстати вы же выше написали что 1 гц тоже "до 1 МГц".

Добавлено: Чт май 03, 2007 18:20:55
ARV
tych писал(а):
ARV писал(а):когда я говорил "НЕ ВЕРЮ" - я был абсолютно прав.
Всё подвергай сомнению !

Кстати вы же выше написали что 1 гц тоже "до 1 МГц".
не вижу в том криминала. главное, программе не стоит слепо верить - первый посыл к этому и была заявленная частота, а дальше уж пошло-поехало...

Добавлено: Чт май 03, 2007 18:43:53
tych
Я не спрю. Я и говорю что хитро указаны параметры как цены указывают "от ..."

Добавлено: Пт май 04, 2007 22:27:23
dem-vr
ARV - спасибо за великий труд, но я снимал свои диаграммы сразу в режиме DMA (ECP - порт принтера). И по 8 каналам видел выставляемые задержки сигналов в портах MEGA8 на уровне 0,25 мкс от стробов. Увеличил их до 0,5 мкс. и тоже заметил. Меня это устроило.

Добавлено: Пт май 04, 2007 23:39:35
ARV
dem-vr писал(а):ARV - спасибо за великий труд, но я снимал свои диаграммы сразу в режиме DMA (ECP - порт принтера). И по 8 каналам видел выставляемые задержки сигналов в портах MEGA8 на уровне 0,25 мкс от стробов. Увеличил их до 0,5 мкс. и тоже заметил. Меня это устроило.
1. Если я не ошибаюсь, то программа DigTrace не использует DMA-режим (ибо что в SPP, что в ECP режиме ее показания одинаковы абсолютно - я проверял).
2. Судя по ее интерфейсу и явным ляпам в работе, она написана непрофессионалом, поэтому вероятность того, что ее автор сумел-таки реализовать поддержку режима DMA в Windows, мною оценивается как ничтожно маленькая.
3. 0,5 и тем более 0,25 микросекунды - это в принципе не по силам этой программе даже теоретически, т.к. даже автор говорит о пределе в 1 мкс.
4. Указанная программа может показать то, что в принципе отсутствует, равно как не показать то, что есть на самом деле.

Где-то есть какой-то нюанс... Ты не ошибся ни в чем? Может, речь о миллисекундах? Если ошибся где-то я - укажи где... Выложи диаграммы, как сделал я...
Надо бы разобраться. Просто опасаюсь я, что твоя уверенность кому-то может дорого обойтись (если этот кто-то необоснованно уверует в эту программу)...

Digitrace - mega8

Добавлено: Сб май 05, 2007 21:09:25
dem-vr
посмотри диаграмму 8 сигналов и покрути увеличение

Digitrac.exe

Добавлено: Вс май 06, 2007 14:50:28
dem-vr
Я выложил диаграмму записи 8 сигналов, весь процесс длился 13,77 мс. и создался файл побайтовых измерений величиной 32767. получается 13770 мкс делим на 32768=0,42 мкс.

И где я не прав? А в литературе пишут, что порт ЕСР при получении от LPT-сканера информации выдает скорость свыше 2Мб. в секунду.
Это связано с тем, что южный мост порт-принтера подключает к шине ISA с тактовой частотой 16 Мгц. А с введением технологии "Hyper Transport низкоскоростные порты в чип-сете перенесли на новую шину LPC. Она работает на уровне протокола Logical Link Control and Adaptation Layer Protocol (L2CAP) и только с асинхроннами соединениями." Это из книги В. Мураховуский Железо ПК.Новые возможности. "2005 г. Поэтому ЭВМ с новыми наворотами не всегда дают желаемый результат. Для этого лучше применить USB.

Добавлено: Вс май 06, 2007 15:06:08
Мышонок
1) Просмотрел я тему и возник вопрос: При чём здесь вычилительная мощность компьютера и пропускная спосбность интерфейса?

Отвечаю - не причём. Разве Windows является ОС реального времени?

2) Про обработку сигналов я упомянул в самом начале темы. Для успешной работы надо обеспечить качественное преобразование аналогового сигнала в цифровой, возможно с предварительной обработкой и т.д. Полученный результат можно передать по любому интерфейсу практически в любой компьютер. Тем самым мы достигнем необходимых характеристик наблюдения исследуемого сигнала, и нам быстродействие самого компьютера и пропускная способность интерфейса на это не повлияют.

3) Про ОС реального времени я упомянул, но это другая тема, весьма большая и сложная.

Добавлено: Вс май 06, 2007 15:13:03
ARV
Если на клетке со слоном увидишь надпись "Буйвол" - не верь глазам своим! ©К.Прутков.
Это я к тому, что не стоит слепо верить всему, что написано в книгах. Теоретически аппаратура порта позволяет такой скорости достичь, однако в жизни это получается только в "тепличных" условиях. Я никогда не встречал никого (и упоминаний от кого-либо), что фактически была достигнута скорость больше упомянутых мною 600-800 килобайт/сек. Точно так же, как не встречал приводов, которые могли бы реально прочесть CD на скорости х52... Но это так, к слову.
Что касается диаграмм - то я уже писал, что их "размерность" зависит от того, на каком компе их смотришь. Значит, на моем все длительности будут совсем иными (скорее всего). Лучше всего, если бы ты привел снимок окна программы - тогда мы бы увидели, что она тебе написала. Диаграммы проанализирую завтра.

Добавлено: Вт май 08, 2007 07:37:06
ARV
мышонок писал(а):1) Просмотрел я тему и возник вопрос: При чём здесь вычилительная мощность компьютера и пропускная спосбность интерфейса?

Отвечаю - не причём. Разве Windows является ОС реального времени?

2) Про обработку сигналов я упомянул в самом начале темы. Для успешной работы надо обеспечить качественное преобразование аналогового сигнала в цифровой, возможно с предварительной обработкой и т.д. Полученный результат можно передать по любому интерфейсу практически в любой компьютер. Тем самым мы достигнем необходимых характеристик наблюдения исследуемого сигнала, и нам быстродействие самого компьютера и пропускная способность интерфейса на это не повлияют.

3) Про ОС реального времени я упомянул, но это другая тема, весьма большая и сложная.
мышонок, ОС реального времени в чистом виде не существует! максимум, что существует - это гарантированное выделение каждой задаче определеннного кванта времени, не более. Я не рассматриваю многопроцессорные системы, где все гораздо запутаннее, но в общих чертах мое утверждение верно и для нее. Название "реальное время" - не более, чем описательное название класса ОС. Или вы станете утверждать, что существуют ОС, в которых одна задача и 100 таких же точно задач будут выполняться с одинаковой скорсотью каждая на одном и том же компьютере?!
Пропускная способность интерфейса - это теория. Практически она ограничивается именно возможностями программы (ОС или прикладной - это все равно). Поэтому рассматривать чистые цифры пропускной способности в отрыве от центрального процессора, ОС и программ вообще - бессмысленно. Скажем, если мы к ATMega приспособим SCSI-интерфейс, который теоретически может качать со скоростью 100 мегабайт в секунду и более - неужели же вы думаете, что наша система сможет обрабатывать информационный поток, поступающий с этой скоростью?! Естественно, интерфейс обеспечит пропускную способность примерно 1 мегабайт в секунду, вряд ли более, и именно из-за процессора (хотя каждый байт, возможно, и будет пролетать по интерфейсу с бешеной скоростью).
По поводу того, что быстродействие компьютера нам не помешает исследовать процессы, лишь бы они "попали" в него - это тоже не совсем верное утверждение. Помимо уже сказанного, если мы хотим не пропустить ни одного периода входного сигнала частотой 100 кГц, нам надо зашвыривать в компьютер минимум по 100 отсчетов за каждый период сигнала (только не надо вспоминать теорему Котельникова), т.е. на частоте 10 МГц. Если каждый отсчет - всего байт, то это уже за гранью многих интерфейсов (хваленый USB-2 опять-таки не обеспечивает заявленной скорости в реальных системах). Кроме того, этот поток по определению должен идти непрерывно, а обработка всегда дискретна - получили массив данных - обсчитываем его, затем выводим результаты. То, что паузы между этими моментами человек не видит, еще не означает, что они отсутствуют. В результате мы обязательно будем пропускать часть периодов входного сигнала. Сколько именно пропусков будет - зависит от программы, интерфейса, АЦП и т.п., но они будут (на таких частотах, естественно). Так что мощность компьютера очень важна, особенно в нашем случае, т.е. когда съем данных осуществляется чисто программно, без аппаратной поддержки.