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]
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.
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?
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!
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.
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!
I just learned from colleagues who are using our Moku:Pro (fw 591, moku 3.2.0) that this bug has not been resolved yet. Do you know the current status of it?
I am so sorry for the issue you are dealing with. I thought this had been fixed in the most recent release, but I was wrong.
This issue can be reproduced on my end, and I will talk to our dev team and let you know once it is fixed. Thank you very much for your patience and understanding!