I couldn’t get the ‘get_stream_data’ working in matlab (just saw this thread), so I’m using ‘start_logging’ instead. It mostly works, except for one weird bug. This command works fine:
(I’m using multi instrument and having the PID controller log) Polls using ‘logging_progress’ all make sense, it says “Logging in progress” while it counts down 10 seconds, then says 0 seconds remaining and “Logging complete”. But this command does not work:
In this case, it says “Logging in progress” while it counts down 10 seconds, but then says 0 seconds remaining and “Logging in progress” for another 10 seconds until finally reports “Logging complete” after 20 seconds and the file saved has 20 s of data, not 10 s. The time is always double when I choose precision.
Everything works fine from the Moku app saving data manually, but there seems to be an issue with the API (matlab & python) getting precision data from the PID controller (multi-instrument mode, 3 slots, PID in slot 2). The problem is with ‘start_logging’ and ‘start_streaming’. The data returned is not precision, it’s normal mode data. It also takes twice the duration to capture.
When I pipe the PID output to a lock-in amplifier I have in slot 1, I am able to get precision data just fine from the lock-in. So the problem is just with the PID controller. I have only tested with 3 slots and the PID in slot 2 so I don’t know if moving slots would change anything or going to 3 slots or the dedicated PID.
I can confirm this is a bug. Specifically, for the datalogger embedded within the PID instrument, the Precision acquisition mode does not function correctly; it returns twice the expected number of samples and it is indeed ‘normal’ mode data, not ‘precision’ mode data.
While we work to fix this issue, attached is a Python script that will sample data at a higher rate (100x) and then average this data locally - within Python - achieving same outcome as precision acquisition mode.
The diagram shows a (slightly) noisy sine wave that is improved by this method.
