Nice.
So this means that it could possibly work on 8-bit scopes like the 1104x-e for example?
Yes, more likely than not it should work, unless Siglent bungles up their SCPI implementation in the 1104x-e. I spent quite some time debugging my code yesterday, only to discover my 8-bit sds2504x plus self reports it has 127 LSB per vertical division

. Upgraded its firmware and now it reports 30 LSB per div, and the math now works fine. So give it a shot, make sure you have the latest FW, and report back any success or otherwise.
Nice.
So this means that it could possibly work on 8-bit scopes like the 1104x-e for example?
There are several preexisting SW packages that work with Siglent devices:
https://int.siglent.com/download/drivers/
And an amount of free SW:
https://int.siglent.com/download/softwares/
Then for instruments with a webserver and SCPI command panel the programming guides can be found here:
https://int.siglent.com/download/documents/
Don't get me bloody started on Siglent's remote programming resources, or this will become a rant post. Their VISA implementation causes the scope to hang and report junk data half of the time, the only reliable way to talk to the device is through sockets.
And look at this example python code from Siglent's own programming manual.
convert_data = []
if BIT[MODEL] > 8:
for i in range(0, int(len(recv_all) / 2)):
data_16bit = recv_all[2 * i + 1] * 256 + recv_all[2 * i]
data = data_16bit >> (16-BIT[MODEL])
convert_data.append(data)
else:
convert_data = recv_all
volt_value = []
for data in convert_data:
if data > pow(2,BIT[MODEL]-1)-1:#12bit-2047,8bit-127
data = data - pow(2,BIT[MODEL])
else:
pass
volt_value.append(data)
del recv,recv_all,convert_data
gc.collect()
especially these two lines
if data > pow(2,BIT[MODEL]-1)-1:#12bit-2047,8bit-127
data = data - pow(2,BIT[MODEL])
Look, my favourite programming language is solder, and I self identify as an EE, not a programmer. But this is beyond hopeless
- Calculating 2 to the power of bit depth for every single data point (there are literally hundreds of millions of data points) , TWICE per loop, instead of calculating it once outside of the loop. And it is Python, so not like there's a compiler to optimise that bit of code away. WHY?
- The person that wrote this piece of gem has likely slept through programming 101 class and never heard of 2's complement. Why else would someone in their right mind write this instead of just casting the one or two u8 into signed integers?