https://sigrok.org/gitweb/?p=libsigrok.git;a=blob;f=src/hardware/hantek-dso/protocol.c;h=c74187ada435f2441e7aa3b88ed926194c9d530b;hb=HEAD#l851 According to Renate on IRC: The trigger point is coming in Gray code so that capture and data skew are not a problem. toff ^= (toff>>1); toff ^= (toff>>2); toff ^= (toff>4); toff ^= (toff>>8); toff ^= (toff>>16); That's it. That's how they convert Gray code in the big leagues.
Apparently the sigrok project has been aware how to do Gray decoding for ages, according to libsigrokdecode/decoders/graycode/pd.py:gray_decode() The question is whether the hantek-dso driver's dso_get_capturestate() routine does Gray decoding in that spot. The reporter claims to have no access to the device, and would not provide a fix or improvement. And the existing driver code reads somewhat different to me. Instead of a repeated x ^= x >> 1 the code instead reads x ^= b - 1 which may or may not be a totally different operation. The comment suggests something Gray like, haven't "decoded" the implementation in detail, whether it's a very unfortunate re-invention of an XOR or not. I'd say before blindly replacing the code and its comment the report needs verification on hardware, or comparison to a known working upstream project which parts of the driver are based on. The reporter provided neither.