search

rpcope1 / Hantek6022API

Hantek 6022BE Python API for Windows and Linux.
GNU General Public License v2.0
125 stars 41 forks source link

Usb bulk transfer buffer size #32

Open merbanan opened 8 years ago

merbanan commented 8 years ago

Why is bulk mode using quad 512 byte buffers while isochronous uses quad 1024 byte buffers ?

jhoenicke commented 8 years ago

This is an USB limit. Maximum bulk size is 512 bytes, maximum isochronous size is 1024 bytes. Note that ez-usb can only do at most quad buffering, so you want to have the maximum packet size to get the maximum cached samples.

merbanan commented 8 years ago

Ok, so to be able to use the full 4k buffer in bulk mode 2 endpoints would be needed. EP2 and EP6 both with quad 512 bytes. The theory is to split each channel to an endpoint of it's own. That way you have double the time to get the buffer data but you need to ask 2 endpoints to get both data channels. Do you know if this is possible to realize in the firmware and have you tried it ?

jhoenicke commented 8 years ago

I doubt that this works. You would need to waveforms running in parallel, one for ep2 one for ep6 and they wouldn't be synchronized.

If you need the larger buffer, use isochronous mode. Also this is the only way to guarantee that no samples are dropped and it does support 24 MB/s (bulk can only do a bit more, up to 32 MB/s, and then it will drop samples from time to time).

If you really need 48 MHz then isochronous will give you 3k continuous samples (due to the way isochronous transfers 3 kB in an usb frame). You can also try to record one shot to get 4kB.

merbanan commented 8 years ago

http://www.cypress.com/knowledge-base-article/maximizing-transfer-rate-fx2fx2lp suggests that the usb bulk bandwidth is there for 30MHz sample rate.

But as you observed samples are dropped from time to time. Do you know if that is because the usb host wasn't able to fetch packets fast enough from the FX2 or if the packets got lost in the usb stack / hardware somewhere?

Only in the first case would more buffer memory help. And then as you say if you split the channels, synchronization would be an issue if packets actually get lost somewhere.

jhoenicke commented 8 years ago

I used the oscilloscope to watch its own TX-line on the USB cable. The occasional drops are probably caused by config or interrupt transfers on other devices or by bad alignments: The protocol requires that there is a new frame every 1/8 ms. If the bulk package would not fit at the end of the current frame the usb controller doesn't ask for the bulk transfer but waits until the next frame starts. At that time it also asks all devices for control/interrupt/isochronous transfers before requesting the next bulk transfer.

It doesn't happen in every frame but it happens from time to time.