Data width is not set correctly; wrong offset in conversion from buffer to array

[rbansemer]

These issues both concern read_data_one_channel, which is why I summarize them both in one issue entry.

For setting the data width, the command WFMO:BYTE_NR 2 is sent to the scope. For all my devices (DPO2k, DPO2kB, DPO4k), this is not a valid command. Therefore, I am either lucky and set the data width correctly before already, or the resulting waveform data is wrong. The correct command is WFMO:BYT_NR 2.

The offset used in np.frombuffer later on in the same method is wrong, although the intention is obviously correct according to Tektronix' programmers' manuals: You read the value in the buffer at position [1] and add two to this value. As usual, the devil is in the details.

buffer is of type bytes. Using buffer[1] returns the ASCII value at position [1] as int. If the character at this position is '7', buffer[1] will therefore return 55. In order to get the content of the buffer at this position, it is necessary to use the slice buffer[1:2]. In the example I just made up, buffer[1:2] will return b'7', and int(buffer[1:2:]) is 7. This is the intended behavior: If the character at position [1] in the buffer is 7, then the offset in np.frombuffer needs to be 7+2, not 55+2.

As some times before, I do not write this issue to complain, but to explain what my merge request that is about to follow is about. The problem in the conversion from the buffer to an array is quite severe, it makes it impossible to read a correct waveform (might be a Python 2 residue?). Do you plan a new release with the fixes soon?