some issues with continuous.read

[piotx]

thanks for sharing the api!

I would like to gather data for a longer period of time. I've played around with the continuous read script, and have some questions.

sample_rate_index = 0x1E
What does 0x1E stand for? I couldn't find it in the dictionary of SAMPLE_RATES in LubUsbScope.py; The oscilloscope gathers 12 Million data entries within one second, so I suppose that it's a sampling rate of 12 MS.

It doesn't seem to be possible to change the sample_rate, when using the read_async method. The data has always a length of 12288000 (within one sec), regardless of chosen sample rate and the data looks strange (gaps between measured samples). Is this a limitation, or am I not understanding something?

'Also the data_points doesn't seem to change anything. I'm a little bit confused about that.

It would be great, if you could clarify these points. thanks

piotr

[jhoenicke]

sample_rate_index = 0x1E

0x1E is 30 in decimal and stands for 30 MHz. The modded firmware and custom firmware support some new sample rates. It is not supported by the stock firmware. The list of sample rates is: 10,20,50=100/200/500kHz, 1,2,4,8,12,16,24,30,48 = samplerate in MHz. 48 MHz doesn't really work, since USB 2.0 is too slow.

It doesn't seem to be possible to change the sample_rate, when using the read_async method. The data has always a length of 12288000 (within one sec), regardless of chosen sample rate and the data looks strange (gaps between measured samples). Is this a limitation, or am I not understanding something?

This is not what happens for me. Did you install the modded firmware, or the custom firmware? Also try a different USB port/hub. If you can only read up to 12 MB/s, there may be some other USB device on the same bus that needs some bandwidth. This also explains the gaps you see. I can sample up to 30 MB/s with very few gaps.

You can also choose 8MB/s by setting the sample_rate_index to 8.

[jhoenicke]

I finally got around playing with my Oscilloscope again. Please try this patch: jhoenicke@6dfbf52

1. The sample rate 0x1e = 30 was too high for isochronous transfers.
2. The firmware wasn't reflashed and this leads to the python library not supporting the single channel mode (maybe I can change the python library to autodetect single channel support). Single channel is important to get 24Msamples/s, and explains why you only got 12288000 samples/s (3072 bytes per 1/8 ms divided by number of channels).

[piotx]

thanks a lot for checking that out! I'm very busy right now, but will definitely test it, when I find some more time... 2017-04-24 18:00 GMT+02:00 Jochen Hoenicke <[email protected]>:

…

I finally got around playing with my Oscilloscope again. Please try this patch: ***@***.*** <jhoenicke@6dfbf52> 1. The sample rate 0x1e = 30 was too high for isochronous transfers. 2. The firmware wasn't reflashed and this leads to the python library not supporting the single channel mode (maybe I can change the python library to autodetect single channel support). Single channel is important to get 24Msamples/s, and explains why you only got 12288000 samples/s (3072 bytes per 1/8 ms divided by number of channels). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANHZpmebD6-FgJl5k6lyEsbVtPl3BIlbks5rzMc2gaJpZM4JpW30> .

[holgerschillack]

Hey @jhoenicke, thank you for helping.
I'm a colleague of piotx and I've had the time to do some more testing on the oscilloscope.
When I tried to apply your patch, I got an error at line 69:

Traceback (most recent call last):
  File "example_linux_continous_read2.py", line 69, in <module>
    scaled_data = scope.scale_read_data(data, voltage_range)
  File "/usr/local/lib/python2.7/dist-packages/Python_Hantek_6022BE_Wrapper-0.0.2-py2.7.egg/PyHT6022/LibUsbScope.py", line 490, in scale_read_data
    return [(datum - 128)*scale_factor for datum in read_data]
TypeError: unsupported operand type(s) for -: 'str' and 'int'

I've also come to the conclusion, that the sample_rate or better the data-point-creation-rate is always 24*10⁶ data points per second.
When I change the sample rate to 0x14 (equals "200 KS/s") and record 2 seconds, I've got 48M datapoints. I've noticed, that in my case (Voltrage range -2.5V to +2.5V) the actual sample rate is 200kS, but there are added useless data points with value "-2.5".
So when I apply a work-around to delete these values, I'm left with a fine recording. The other problem is, that every second the deque is filled with 24 millions of points, so when I#m recording 10 seconds, 240 million datapoints need to be processed, although I just need e.g. with 200Ks only 400.000 data points.
So the limit on my computer is around 15 seconds - he needs like a minute to save the data. Any longer time period results in a program crash.
Generally I just want to record data for about 2 minutes with a sample rate of 200-500Ks for both channels simultaneously and write the values into a file. Plotting and calculating then is done with R.
Do you think, that would be possible?
I would be very glad, if you could take a look on that problem :)

And here my current code for deleting the useless values:

print '\n', "Points in buffer:", len(data), '\n'
scaled_data = scope.scale_read_data(data, voltage_range)

print("Deleting useless data points...")

scaled_data= [x for x in scaled_data if x != -2.5]

print '\n', "Real data:", len(scaled_data),'\n'

with open('/home/h/Downloads/Hantek6022API/examples/continuous_read2.out','wt') as ouf:
   ouf.write(str(scaled_data)[1:-1].replace(', ',chr(10)))

with open("continuous_read2.out","r") as f, open("outfile.txt","w") as outfile:
 for i in f.readlines():
       if not i.strip():
           continue
       if i:
           outfile.write(i)  

100.0*bad_pulse_count/len(stab)))
print("Finished! :)")