Python API: Data Logger sampling rate sometimes differs from the set value

Product / Environment Information

  • Device: Moku:Go

  • Firmware version: 622

  • Moku App / driver version: 4.0.3

  • OS: Windows 11

  • Python version: 3.13

Issue Summary
When setting the Data Logger sampling rate via the Python API, the actual sampling rate on the device sometimes differs from the requested value.

Target: 500kSa/s → Actual: 496.03kS/s

Setting 500 kSa/s in the Moku App consistently works and yields exactly 500,000 S/s.However, when setting the same 500 kSa/s through the Python API, the resulting value is 496.03kSa/s

I used `Datalogger.start_logging(duration=120, sample_rate=500_000)` to log data in python.

Hello @xiangyuwei ,

Thank you for reaching out to Liquid Instruments! How are you calculating the sample rate of the API results? Are you dividing the number of points by the expected timespan or the actual timespan? Since you are logging at 500 kSa/s, you should see 2 µs between points; is that what you are seeing? If you could share a snippet of your script that would be helpful in reproducing the issue. I’m looking forward to hearing from you!

Hello @xiangyuwei ,

Upon further testing and discussion with my team, it appears this is a known issue. I will update this thread when a fix is released. Thank you!

I’d like to share an inconsistency I observed:

When I connect to Moku via the Python API, set the sample rate to 500 kSa/s, and log a segment of data, then immediately take control using the Moku App, the sample rate displayed in the UI is 496 kSa/s instead of the expected 500 kSa/s. Additionally, the time interval calculated from the logged data corresponds to a sampling rate of approximately 496 kSa/s.

In contrast, when I perform the entire measurement using only the Moku App and set the sample rate to 500 kSa/s, the time interval in the logged data is exactly 2 µs, as expected.

This discrepancy is not limited to 500 kSa/s. On Moku:Pro, I’ve observed that some sample rate values match the expected rate, while others—particularly specific frequency settings—do not. For example, setting the sample rate to 2 MSa/s via the Python API also results in a mismatch between the configured and actual sampling rate.

@xiangyuwei ,

Thank you for your patience as I looked into this. For some sample rates, the exact rate may be coerced to a rounded value. In previous firmware versions, the script would raise an error when setting a sample rate that couldn’t be achieved. As of MokuOS 4.0, the handling of this has changed; the API will let you set the sample rate you want (i.e. 500 kSa/s) but may coerce the value, even if the error is not raised. Adding the line:

For Moku:Go and Moku:Lab
print(dl.summary().split('\n')[3])

For Moku:Pro
print(dl.summary().split('\n')[5])

to your script will return the true sample rate.

The Moku app handles this similarly. The app will let you set the sample rate you want, but when you export the data, the true sample rate will be displayed at the top which may be slightly rounded from the set sample rate.

If the true sample rate is needed, you can add the line above to your script, or get it from the exported log.

I hope this was helpful!

-Dylan

Hi Dylan,

Thank you for clarifying the issue. I still have one point of confusion: On Moku:Pro, it seems that an exact sample rate of 2 MSa/s cannot be achieved—it gets coerced whether I use the Python API or the Moku App. However, on Moku:Go, when I set the sample rate to 500 kSa/s using the Moku App, it appears to achieve exactly 500,000 Sa/s. Why is this value still being coerced?

Hi @xiangyuwei ,

When I set the sample rate to 500 kSa/s in the app and extract the .csv file, the actual sample rate is 496.03 kSa/s, which is consistent with the API results. Are you getting the sample rate from the .csv file or from the Moku app? Looking forward to hearing from you!

-Dylan

Hi Dylan,

You’re right—I wasn’t able to achieve an exact 500 kSa/s sample rate using the Moku app this time either. It seems my memory may have been mistaken. Thank you for your help.

Best regards,

Xiangyu