PCSU1000 capturing speed

  1. I have found that PCSU1000 works faster if connected to USB 2.0 port.
  2. pcsu1000.DataReady function returns 1 for one channel and time/div= 0.5 ms (250000 samples per second) for every 40-50 ms. It means that 4096 samples takes just 16 ms, and 24 ms are missed. How is it possible to speed it up?
  3. As I see UBR (a data block on USB pipe) contains a data like
FF FD FE FC FF FD FF FD FF FD FE FC FF FD FE FC FE FC FF
FD FF FD FF FD FF FD FE FC FE FC FF FD FE FC FE FC FF FD
FE FC FE FC FE FC FE FC FF FD FE FC FF FD FE FC FE FC FE
FC FF FD FE FC FE FC F7 FF

Looking into a schema of PCSU1000, I think that PCSU1000 is implemented as LPT device with LPT-to-USB adapter. Is it true? :shock:
If so, it is understandable why a speed between PC and PCSU1000 is so slow. Is it possible to speed it up? :wink:
4. Is it possible to add a mode for digital signals, when:

  • a threshold is defined by user
  • PCSU1000 returns just one bit per sample - digital ‘0’ or ‘1’ - instead of ADC value (I guess it may increase a data rate between PC and PCSU1000 by 8 times)
  1. That is interesting and new info for me that PCSU1000 runs faster with USB2.0. How big difference you noted between USB1.1 and 2.0?

  2. There is used FTDI’s FT245BM USB FIFO as an USB interface.
    According to the data sheet “Transfer Data rate to 1M Byte / Sec - D2XX Drivers”.
    The amount of data is 8192 bytes. The calculated transfer time is 8.2 ms if the speed is 1 MB/s. According to your test results the transfer time is 24 ms.
    You measured the loop time (40-50ms). Please note that also the trace drawing on the screen is within the loop.
    Have you checked is it faster if you disable the trace drawing?

I think that it is not possible to speed the transfer time. It is a fixed feature of the FT245BM chip.

  1. The FT245BM is USB to parallel converter not an LPT-to-USB adapter.
    See the datasheet: ftdichip.com/Documents/DataS … T245BM.pdf

  2. It is interesting idea. – Indeed, it should speed up the calculated transfer time from 8.2 ms to about 1 ms.
    The resulting one bit data is OK for digital signals only.

  1. It is a mistake that PCSU1000 works faster with USB 2.0. I have got the same strange result for USB 1.1 and USB 2.0 (when Show_PCSU1000 is on or off):

Sample1:

data ready delay(ms)=0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 
read delay(ms)=90
data ready delay(ms)=0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 10 
read delay(ms)=90
data ready delay(ms)=0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 
read delay(ms)=80
data ready delay(ms)=0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 
read delay(ms)=90
data ready delay(ms)=0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 11 0 0 0 0 0 0 0 0 10 0 
read delay(ms)=91
data ready delay(ms)=0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 10 
read delay(ms)=90
data ready delay(ms)=0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 10 
read delay(ms)=90
data ready delay(ms)=0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 
read delay(ms)=80
data ready delay(ms)=0 0 10 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 
read delay(ms)=90
data ready delay(ms)=0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 
read delay(ms)=90
data ready delay(ms)=0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 10 
read delay(ms)=90
data ready delay(ms)=0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 
read delay(ms)=80
data ready delay(ms)=0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 11 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 
read delay(ms)=91
data ready delay(ms)=0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 
read delay(ms)=90
data ready delay(ms)=0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 0 
read delay(ms)=90

Sample 2:

data ready delay(ms)=0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 
read delay(ms)=40
data ready delay(ms)=0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 
read delay(ms)=50
data ready delay(ms)=0 0 10 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 10 0 0 
read delay(ms)=50
data ready delay(ms)=0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 
read delay(ms)=50
data ready delay(ms)=0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 10 
read delay(ms)=50
data ready delay(ms)=0 0 0 0 0 0 0 0 0 11 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 10 
read delay(ms)=51
data ready delay(ms)=0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 
read delay(ms)=40
data ready delay(ms)=0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 10 0 0 
read delay(ms)=50
data ready delay(ms)=0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 10 
read delay(ms)=50
data ready delay(ms)=0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 10 
read delay(ms)=50
data ready delay(ms)=0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 
read delay(ms)=40
data ready delay(ms)=0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 
read delay(ms)=50
data ready delay(ms)=0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 10 0 0 0 

A measurement code is:

	pcsu1000_Start_PCSU1000
	jc	func_osc_capture_error_starting
	;
	mov	func_osc_capture_cnt,50
	;
	_Sleep	3000
	pcsu1000_Show_PCSU1000 1
	pcsu1000_RunOn_PCSU1000 1
func_osc_capture_loop:
	AppendErr <13,10,'data ready delay(ms)='>
	jmp	s func_osc_capture_loop2
func_osc_capture_loop1:
	_Sleep	1
func_osc_capture_loop2:
	;
	_GetTickCount
	push	eax
	sub	eax,func_osc_capture_timeDr
	AppendErr_4Decnz eax
	AppendErr <' '>
	pop	eax
	mov	func_osc_capture_timeDr,eax
	;
	pcsu1000_DataReady
	cmp	eax,1
	jne	s func_osc_capture_loop1
	;
	_GetTickCount
	push	eax
	sub	eax,func_osc_capture_timeRd
	AppendErr <13,10,'read delay(ms)='>
	AppendErr_4Decnz eax
	pop	eax
	mov	func_osc_capture_timeRd,eax
	;
	pcsu1000_ReadCh1 <o func_osc_capture_buff>
	;
	dec	func_osc_capture_cnt
	jnz	func_osc_capture_loop

About “Sleep 1 ms”: as you can see, a system makes nothing during 9 times, but one time takes 10-11 ms for “sleeping”. So, a resulting delay is like 40-50 ms, or 80-90 ms.

PS: I use pure ASM code in my program

  1. Trace drawing has no visible effect on delay.

  2. As I see, “Transfer Data rate to 1M Byte / Sec - D2XX Drivers”. So, during 40 ms it is possible to transfer up to 41943 bytes (40 KBytes). But in our case it is just about 8Kbytes of efficient data (5 times less).
    Looking in a code of my previous post, commands like

FF FD FE FC
FF FD
FF FD FE FC FE FC 
FF FD
FE FC FE FC FE FC FE FC 

provides an answer why an efficient data rate goes down for 5 times as I guess. A computer performs a bit manipulation for USB_D0, USB_D1, USB_D2 to send a get data from/to PCSU1000. Why do not you use a full byte width for data transfering (like USB_D4, USB_D5, USB_D6, USB_D7)?
In my understanding, DCLK generation shall not be performed by PC. It is a job of PIC microcontroller or FPGA, is not it?

  1. Can you implement it?

Thank you.

Thank you for your detailed search results and description of the USB communication speed of the PCSU1000. If I understand right, you are looking the USB traffic and it seems that only the lower nibble of the bytes transferred contains some data. This is very strange. In both ends full byte width is sent / received. In the PCSU1000 full byte width data is transferred to the FT245BM USB FIFO. On the PC side the data is read /sent from / to the transfer buffer. The data transfer is handled by the driver of the FT245BM USB FIFO.
Sorry that all those operations are totally hidden and out of the control of the PC software. No clocking is sent from the PC when the data is input from the PCSU1000.

Sorry - but I think no speed increment is easily done…

As I understand now, the lower nibble of the bytes is used only for commands to PCSU1000. A data from PCSU1000 is going as full bytes.

What is a reason to send 8193 bytes to PC (1st zero bytes plus 8192 bytes of data) instead of 8192 ?

Can you implement a program, when two 4K buffers are used: one for capturing, 2nd for sending data to PC, and next buffers swapping?

OK. Eight bit data is sent from the PCSU1000. Indeed, the commands may be 4 bit data. The first byte from the PCSU1000 contains some data in the 1GS/s mode. On other time/div ranges it is 0, as you noted.

Indeed nice idea to use two buffers. That way only single channel operation should be possible. – Indeed possible but too big change to existing software / firmware – sorry.