Created attachment 337 [details] debug log output When accessing a Hantek 6022BE on Windows, everything works fine until I request more than 1M samples. PulseView just stays in the Running-State forever, the log reports: sr: [00:38.406000] hantek-6xxx: data_amount: 4000000 (rounded to power of 2: 4194304) sr: [00:38.406000] hantek-6xxx: Request channel data. sr: [00:38.406000] hantek-6xxx: receive_transfer(): calculated samplerate == 0ks/s sr: [00:38.406000] hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_ERROR received 0 bytes. See the attached full log for more. The log first does a run with 1M samples, which works fine, and then one with 2M samples, which gets stuck. It does not crash or hard-fail forever, setting the Sample-Rate back to 1M or anything lower right after also works just fine again.
Created attachment 338 [details] log_1M_1MHz.log
Created attachment 339 [details] log_2M_1MHz.log
Further research and discussion on IRC found out that libusb on Windows apparently fails to read chunks larger than 2M. There already is code in place in the hantek-6xxx driver to limit the chunk size, but right now this limit is 12M. So changing this single line: https://sigrok.org/gitweb/?p=libsigrok.git;a=blob;f=src/hardware/hantek-6xxx/protocol.h;h=73d8f868da27430072a30b674ea96440ab27da22;hb=HEAD#l63 From 12M to 2M should fix it. No idea if it should just be limited to 2M on Windows, or on all platforms.
Thanks for the report and patch! I can reproduce this on Windows 10 and can confirm that the 2M limit fixes the issue. It's a bit unclear why exactly this is, maybe this should be investigated some more, but for now this is fine as fix. The error case with -l 5 and "set LIBUSB_DEBUG=1" looks like this: sr: [00:07.386000] hantek-6xxx: data_amount: 4000000 (rounded to power of 2: 4194304) sr: [00:07.386000] hantek-6xxx: read_channel: amount = 4194304, using 3145728. sr: [00:07.386000] hantek-6xxx: Request channel data. libusb: debug [libusb_alloc_transfer] transfer 07EB59A0 libusb: debug [libusb_submit_transfer] transfer 07EB59A0 libusb: debug [add_to_flying_list] arm timer for timeout in 4000ms (first in line) libusb: debug [winusbx_submit_bulk_transfer] matched endpoint 86 with interface 0 libusb: debug [usbi_add_event_source] add HANDLE 53c events 0 libusb: debug [winusbx_submit_bulk_transfer] reading 3145728 bytes libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling libusb: debug [handle_events] event sources modified, reallocating event data libusb: debug [usbi_handle_events] WaitForMultipleObjects() for 3 HANDLEs with timeout in 0ms libusb: debug [usbi_handle_events] WaitForMultipleObjects() returned 2 libusb: debug [windows_transfer_callback] handling I/O completion with errcode 1, size 0 libusb: error [windows_transfer_callback] detected I/O error 1: [1] Unzulässige Funktion. libusb: debug [usbi_remove_event_source] remove HANDLE 53c libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer libusb: debug [usbi_handle_transfer_completion] transfer 07EB59A0 has callback 00A08DF0 sr: [00:07.386000] hantek-6xxx: receive_transfer(): calculated samplerate == 0ks/s sr: [00:07.386000] hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_ERROR received 0 bytes. From WinUSB's point of view the error is thus ERROR_INVALID_FUNCTION (error code 1), resulting in the libusb error code LIBUSB_TRANSFER_ERROR. Why exactly this happens is unclear, though. https://msdn.microsoft.com/en-us/library/windows/hardware/ff538112(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx Anyway, I merged the patch from the mailing list as 095eba19d6ddda139f01eeb36e81f06bd2d91748, which only reduces the size on Windows (this doesn't seem to be an issue on Linux from what I can see). I'll also try to check on Mac OS X, FreeBSD or Android as time permits.