Recommended Posts

Hi all,

I'm working on the python code now as well, but am struggling to get the acquisition going sadly. Most confusingly, trigger GetCurrentState gives me a status "busy" and the return looks different than in the instrumentation protocol. @Kristoff, is it up to date? Also, if anyone knows the correct steps to get the acquisition going, like when to do what commands that would be super helpful too.

Thanks in advance,

Jeremi

PS

Here are the returns I'm getting:

>>> o.triggerGetCurrentState()

{   'trigger': {   '1': [   {   'acqCount': 0,

                                'command': 'getCurrentState',

                                'source': {   'channel': 1,

                                              'instrument': 'osc',

                                              'lowerThreshold': 0,

                                              'type': 'risingEdge',

                                              'upperThreshold': 10},

                                'state': 'busy',

                                'statusCode': 0,

                                'targets': {'osc': [1]},

                                'wait': 0}]}}

Link to post
Share on other sites

Hi, I'm new to the forum and I'm not sure that this is the right place to write this.

I am communicating via Wi-Fi with the OpenScopeMZ through JSONs, the problem is that when the OpenScope returns the data I am not able to understand the binary part.

I have been able to read that "signed 16 bit numbers and each one represents a single sample in mV"  but it is not enough for me, I attach JSON "osc" where you can see the response of the OpenScope.


I would appreciate any information on how to convert this binary file to decimal, and then I hope can program it on javascript.

Thank you.

osc.txt

Link to post
Share on other sites
5 minutes ago, jeremimiller said:

Don't know if anyone's interested but I got the code to kinda work. In the oscRead() method data is defined as result[4], but should be result[3] in line with the instrumentation protocol. @David Bradway can I post the code on my repo with acknowledgements and reference your repo? (I've implemented some more methods.)

Thanks,

Jeremi

@jeremimiller I'm not exactly sure what you are asking. Do you have fixes for my repositories? I would be glad to review a Pull Request and incorporate them into my work. I admit I haven't looked at them since May 2018. Regardless, it's all open source, free to reuse.

Link to post
Share on other sites
  • 5 months later...

For those coming to this thread at a later date, looking for a solution to the "busy" Trigger state:

In short the "busy" state is a catchall for any Trigger state that isn't Idle, Stopped, Triggered, Running or Armed. In the case of the Trigger, it is usually busy due to being in a Waiting state but can be other states as defined in the OPEN_SCOPE_STATES enumeration in OpenScope.h of the firmware source (starting at line 476). The solution here is to wait for the Trigger to leave that "busy" state by continuing to send the Trigger getCurrentState commands. I suggest that an easement algorithm is implemented that increases a delay between the getCurrentState commands (what WaveForms Live does) or to just use a flat, sufficient delay between each getCurrentState call just to avoid inundating the device with too many network calls.

 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now