Bug: oscilloscope on Moku:Go returns incomplete data arrays with trailing NoneTypes for frame_lenghts > 2048

Moku model: Go M1 (Hardware version 4.0)
Operating system: Windows 11
Software version: Python API: 3.1.1, Moku:Go fw=587

Hi,

I’m testing a simple setup on the Moku:Go with the Python API where the MIM has a waveform generator that feeds data into the oscilloscope. When I retrieve the data from the oscilloscope, my arrays contain not the required number of data points, but rather contain NoneType values for the last part of it, i.e. data['ch1'] = [float, float, float, ..... , NoneType object, NoneType object]

My code sets the timebase and specifies a frame_length (according to Oscilloscope: number of points + averaging in API - #6 by nadia), after which I get the data through osc.get_data().

To test how many values I get back from the scope I check for the amount of non-zero elements in the returned data set, as that excludes the NoneType values. I found that up to 2048 elements works well, but for larger frame_lengths something goes wrong. See the table below for the data (note: the number of non-zero elements can vary by a few elements from run to run).

frame_length number of non-zero elements in returned data
2^7 = 128 128
2^8 = 256 256
2^9 = 512 512
2^10 = 1024 1024
2^11 = 2048 2048
2^12 = 4096 3832
2^13 = 8192 7665
2^14 = 16384 16352

Could you please address this bug in a future update?

P.S. On the Moku:Pro we’ve already used the longer frame_lengths without issues.

Hi @dhwielens,

For cases where this happens, it can be helpful to use the wait_complete argument when getting the data:

osc.set_timebase(t1, t2, frame_length=4096)
data = osc.get_data(wait_complete=True)

Waiting for a complete frame before getting the data will ensure there are no NoneType values in the results.

Hi @nadia,

Thanks for your reply. I’ve just added the wait_complete argument, but that does not make a difference for our setup. We get exactly the same amount of NoneType’s irrespective of the argument.

Just out of curiosity: if wait_complete enforces the frame to be completed, what determines when to get the frame and send it in case you don’t add this argument?

HI @dhwielens ,

Thank you very much for pointing this out! I have reproduced this issue on our end, and this issue actually relates to the timebase settings. If the time length for the frame is short enough, you should be able to get the data frame with the correct number of data points. I will follow-up with our dev team to see what we can do with that. Thank you again for your patience and understanding!

Best regards,
Hank

1 Like

Hi @hanklong,

I was just able to test my code on a Moku:Pro too and it seems that the same issue is present there as well. Previously I did not notice it as I chose much faster time frames, but now that I tested for slower time frames as well, the same problem arises.

Hi @dhwielens ,

Thank you very much for confirming the issue on your end. Our dev team is working on that, it should be fixed in the March release. Thank you very much for your patience and understanding!

Best regards,
Hank