I have found that PCSU1000 works faster if connected to USB 2.0 port.
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?
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?
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)
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?
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.
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.
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
Trace drawing has no visible effect on delay.
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?
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…
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.