USB/Parallel latency

Forum for discussing PicoScope (version 5)
Post Reply
jyh
Active User
Active User
Posts: 13
Joined: Wed Nov 23, 2005 3:48 pm
Location: CERN (Geneva)

USB/Parallel latency

Post by jyh »

Test of a USB to Parallel converter using the latest software version on :
3 different Win XP computers (1.2, 1.3,1.6GHz + USB1 and USB2 )
2 DrDAQ modules

any combination leads to the same deffect:

approx 15 sec latency occurs between clicking GO and getting the signal displayed
http://hemery.sytes.net/USB-Parallel-100ms.jpg

an equivalent latency exists for 200ms/div but timewise 90% of the signal is missing (never displayed)
http://hemery.sytes.net/USB-Parallel-200ms.jpg

The same tests carried out while connected to the // port gives no latency
and the signal appears on the whole width of the display namely over the 2 sec duration for a 200msec/div selection.

What can explain such a huge difference?
a) everything works fine with the // port
b) absolutly unusable with the USBtoPARALLEL interface

Obviously, the other USB ports were not connected to other devices

jyh
Active User
Active User
Posts: 13
Joined: Wed Nov 23, 2005 3:48 pm
Location: CERN (Geneva)

Post by jyh »

Additional pieces of information:
Whenever used with other devices such as auxiliary disks, the USB data transfer rate is of 6 MegaBytes/sec or much much much more.
Therefore, PicoScope is not taking advantage of the available transfer data rate on the USB interface.
Maybe Picoscope sees my USB2 interface as a slow RS232 fax machine?

jyh
Active User
Active User
Posts: 13
Joined: Wed Nov 23, 2005 3:48 pm
Location: CERN (Geneva)

Post by jyh »

Troubles remain the same with Version 5.13.4
using the USB to PARALLEL converter

picoscope display is refreshed every 5 sec while 100ms/div selected
http://jy.hemery.free.fr/jy/usb-parallel-100ms_a.jpg

small fraction of the signal displayed
http://jy.hemery.free.fr/jy/usb-parallel-200ms_a.jpg

any idea to get this USB converter usable ?
Thank you

p.s. this deffect is verified on 3 different computers and with 2 different DrDAQs. The problem does not exist when using the parallel connection on the computers
the USB ports of those computers when interfaced to other devices stand more than 6Mbytes/s. Only PICOSCOPE triggers the fan of the computer to ON to only display very few values every several seconds.

Sarah

Post by Sarah »

Hi

Thank you for your posts.

I will need to get our engingeers to look at this and get back to you.

Best Regards

jyh
Active User
Active User
Posts: 13
Joined: Wed Nov 23, 2005 3:48 pm
Location: CERN (Geneva)

USB/Parallel latency

Post by jyh »

Under WIN XP
"
PICOSCOPE 5.13.4,
DRDAQ USB driver V3.1,
PICOPP.SYS V1.9
"
leads to the same performance problem as encountered in November 2005:
Namely, the signal amplitude plot is being refreshed from 5 to 15 second interval,
whatever the time scale base (msec/div) is, while no other USB devices are connected.
Note that on the only PC with both the USB and a parallel port, the
data rate acquisition is 10 times faster on the parallel port than via the USB port.
The latter test is carried out such that only one interface type is connected at a time.

As a result, the USB interface do not fulfil my required acquisition
data rate on any of my laptop PC's.

Thank you for your help to eventually get the "USB parallel port" interface operational.
Regards

Guest

Post by Guest »

Test on another desktop PC!
PICOSCOPE with DRDAQ USB/Parallel interface plugged onto :
intel P4 2.4GHz 512MB RAM USB2
WIN XP PRF. Service Pack 2

Trace data are displayed by bursts every 5sec or more whatever the width of time window is selected.
PICOSCOPE is the only application running and consumes 100% cpu.

Is there a computer onto which the DRDAQ USB/Parallel interface runs
with no terrific idle time between 2 acquisitions?

Thank you for your answer since I can't get it to work on my own
after having carried out tests on 5 PC's of different brands (ACER,TOSHIBA,SONY,ELONEX.VOBIS)

Guest

Post by Guest »

Test on another desktop PC!
PICOSCOPE with DRDAQ USB/Parallel interface plugged onto :
intel P4 2.4GHz 512MB RAM USB2
WIN XP PRF. Service Pack 2

Trace data are displayed by bursts every 5sec or more whatever the selected width of time window is.
PICOSCOPE is the only application running and consumes 100% cpu.

Is there a computer onto which the DRDAQ USB/Parallel interface runs
with no terrific idle time between 2 acquisitions?

Thank you for your answer since I can't get it to work on my own
after having carried out tests on 5 PC's of different brands (ACER,TOSHIBA,SONY,ELONEX.VOBIS)

jyh
Active User
Active User
Posts: 13
Joined: Wed Nov 23, 2005 3:48 pm
Location: CERN (Geneva)

Post by jyh »

Actually, V5.20 (year2008) behaves the same since V5.14 (year 2006). Namely, DrDAQ on USB Parallel Port of Picotech is not usable from PicoScope on my winXP computers (USB 2.0). Above 50ms/div, data acq and display stops before it gets to the end of the time window. The scope screen is refreshed at about once every 10 or 15 odd seconds. The XP task manager shows PSW32.EXE using only 50% of the 1.66GHz CPU time while the other 50% are squandered by "System Idle Process" of XP. In addition, about 500MB of ram are free out of the total 1GB installed. If a remedy procedure exists to use PicoScope on USB Parallel Port as a scope, please let me know where I can read the steps to follow.
Sincerely

PeterF
Advanced User
Advanced User
Posts: 435
Joined: Thu Jun 07, 2007 10:53 am
Location: Cambridgeshire

Post by PeterF »

Hi,
I am afraid that the DrDaq and USB converter combination has never been a good one. There is little that can be done. The design of the DrDaq is now quite old and not suitable for efficient operation unde the latest operating systems and via USB. Sorry! Our latest USB scopes, including the new 2203, 4 & 5 are much faster. The DrDaq was always not much more than an educational tool.
PeterF.

jyh
Active User
Active User
Posts: 13
Joined: Wed Nov 23, 2005 3:48 pm
Location: CERN (Geneva)

Post by jyh »

Thank you for you prompt reply.
Actually, the DrDAQ module itself on a parallel port was quite satisfactory. Next, the USB to parallel port interface (hardware+software) was put for sale while this interface was not fully commissioned. I would then put the source of malfunction onto the latter. Seemingly from your above statement, this interface will remain in the present state.
Shame on me, I will have to discard the 3 items I bought !!!

Post Reply