I have two suggestions/questions regarding the Oscilloscope instrument and the (Python) API:
The Oscilloscope instrument has a nice averaging function in the desktop / iPad app which we like to use through the API as well. Currently, we can mimic the behavior by requesting the same (triggered) waveform for the amount of averages we want over and over with osc.get_data(), but this means that we communicate a lot with the device and hence our readout time is much larger compared to the case where the API would use the Moku’s buffer to capture the averages and then only send the data once to the computer.
Could the averaging function be integrated into the API?
The Oscilloscope can now only return a fixed number of data points (1024). From a Data Logger viewpoint it would seem that the Moku should be able to capture more data in its buffer.
Would it be possible to increase (and also change through API) the number of points that can be captured through osc.get_data()?
The desktop app does its averaging on the computer-side itself, though it uses a higher-performing (and more complex!) method for retrieving the frames with lower overhead. We’re looking at ways to improve the efficiency of the get_data calls in order to make things like script-side averaging more feasible. We could potentially do some kind of “batch transfer” of frames rather than a real time stream, I hadn’t thought too much about that, I’ll talk to my engineers.
For different data lengths, stay tuned, coming soon
I’m also very keen on the different data lengths! glad to hear it’s coming soon! Just out of curiosity… how soon? Sorry, I don’t mean to be pushy, the answer to the question might change how I structure the next week of work haha
Glad to hear this will be useful to folk! We’re taking it through QA now, it should be at least in beta for the next release which hasn’t been publicly announced but is expected next month. The kinds of issues you might expect if it does end up in beta would be things like frame rate degradation at very long frame lengths and maybe a limitation on just how many points you can retrieve (expect somewhere between 16k and 64k).
User defined frame length is now available through the API! The convention is: i.set_timebase(t1, t2, frame_length=2**n)
Where the frame length can be powers of 2 between 128 and 16384 (2^7 - 2^14). This will be added to the API reference documentation soon.
I just wanted to add my vote to the need for API-based averaging, as well as averaging more than 100 frames It would be extremely useful for a lot of our applications.
the answer to the question might change how I structure the next week of work haha
It would be extremely useful for a lot of our applications.