Jump to content

DIP using dip-angular2


Recommended Posts

Hi All,

 

I'm a beginner in both Typescript/JavaScript and JSON, but have experience in C/C++.

I have followed this tutorial and everything worked fine.

 

Now I'm trying to receive continuous data for plotting, I have succeeded to emulate auto-trigger by re-sending the single trigger command after reception of data, but this is not what I want. So I was attempting to use the command forceTrigger instead.

 

I simply changed the tutorial code from using the trigger function 'forceTrigger(number[])' instead of 'single(number[])' and the device responds with statuscode 0xA000001D:

{

  "trigger":{

    "1":[

      {

        "command":"forceTrigger",

        "statusCode":2684354589,

        "wait":0

      }

    ]

  }

}

 

1. Is there a more detailed list containing information about status codes than this?

 

2. Looking at the OpenScope MZ firmware on GitHub forceTrigger appears to be implemented, is that correct?

 

3. Is there a better way to achieve what I want e.g. turning off trigger entirely?

 

Thanks

Fabian

Link to comment
Share on other sites

Hi again,

 

I was able to get the forceTrigger function to work. It seems to be so that forceTrigger only works if the trigger has been previously armed and will return with this error/statusCode otherwise. So what I do now is:

1. set the trigger parameters to ridiculous tresholds that are hopefully never reached.

2. requesting the device to perform a single trigger

3. immediately requesting a forceTrigger after that

4. reading the data

5. resuming from point 2.

 

Though I found that the OpenScope gets stuck eventually, this is probably due to high frequent requests. So I added a short Timeout before the forceTrigger request.

=> How is this achieved in Waveforms Live? I just checked that when turning off the trigger in Waveforms Live, it also appears to be random trigger events rather than a continuous (rolling) data stream. Looking at the digilent instrumentation protocol, I see that the 'read' command has an additional parameter 'acqCount'. This unfortunately appears to be not available in dip-angular2 osc.read function (reference1).

Leaving the trigger in idle state for me would result in not receiving any data ever when sending a read command to the device. Would that be different if I was providing this missing parameter to the device?

Also, since my attempt will be to row-up the received data chunks to get a continuous stream it is important for me to understand how the OpenScope handles the previously acquired data. Will it throw away the whole chunk once it has been sent out or will it simply push new data to its internal buffer and start overwriting once this buffer is full?

I'm asking because I don't want to row-up overlapping data.

I'm guessing that it would be hard work to implement an parameter 'timeStamp' to the Digilent Instrumentation Protocol's Osc. Read command? This would be a really nice feature though. I did think there was something like that when I found this (looking at 't0'). Unfortunately it is statically set to 0 in the read function (see reference1 above).

 

Btw. I know that my approach is questionable regarding timing and accuracy, though the sample rates I need for my project are hopefully slow compared to the time required for the 'system' to initiate another trigger and the overall time in my chart is expected to be between 1 and 60 seconds, where a few ms of inaccuracy are tolerable. Think of it as triggering at one point -> recording data till a second different trigger point -> measuring time between those points.

If any of you have another approach or ideas to achieve something similar I would be happy to hear.

 

Thanks

Fabian

 

Link to comment
Share on other sites

HI @Fa-b,

I talked with another engineer more experienced with the Angular 2 that we use, but they themselves haven't gotten to look much further into it, so they don't have any further recommendations at the moment. I will let you know if I hear an update though.

Thanks,
JColvin

Link to comment
Share on other sites

Hello Fabian,

I'm the other engineer JColvin mentioned. I'll begin with your question about how WFL handles forceTrigger:

If you a look at the WFL source, specifically the trigger component, you should notice that the component wraps trigger.forceTrigger, and this component method is bound to the on tap event of a button. If the user clicks this button when acquisition isn't running or the trigger is set to off, then the status code you were seeing is reported and the user is told of the error.

When setting the trigger to off, the command sent to the OpenScope when told to run has the trigger source instrument set to 'force'. I assume the OpenScope then readies a buffer whether or not a trigger condition is met since we told it to not care about that. Once the instruments are running and the multiCommand that was issued completes, WFL calls setTimeout with a delay that's calculated from the buffer size and sampling frequency, which attempts to read the OpenScope buffers when completed. If we aren't doing a single run acquisition then this timeout is repeatedly set until an error occurs or the user stops acquisition. After going over all this I believe the trigger type should really be called auto instead of off.

The acqCount parameter requires some explanation, which hopefully clarifies your data row-up question. Both the OpenScope and WFL keep a running count of acquired buffers which is this acqCount value. When querying the OpenScope for a buffer, WFL doesn't ask for the most recent buffer in most cases, and instead asks for the previous acqCount plus one. If the OpenScope hasn't buffered the data yet, it reports back as such, at which point WFL will periodically queries the OpenScope for the buffer until it gets it. This method ensures that there is no overlapping data that is coming back from the OpenScope. Depending on the triggering conditions you set there may be some lost data between buffer packets. To specifically answer your question, the OpenScope keeps the most recent full buffer of data while it fills a new buffer up, which becomes the most recent full buffer when it is full.

It sounds like you want a similar approach to what is happening when the trigger is set to off: begin acquisition, poll the OpenScope for available an available buffer until you get it, process the buffer and then ask the OpenScope for more until you are satisfied.

If you have further questions or need further clarification on something, I'll do my best to help you. It might take me some time for me to reply as I find you your answers but I'll be digging as deep as I need to to find them.

Regards,
Andrew

Link to comment
Share on other sites

Hello Andrew,

 

Thanks for your detailed explanation of what is going on between WFL and the OpenScope. Still I have a few questions regarding your answers:

11 hours ago, AndrewHolzer said:

The acqCount parameter requires some explanation, which hopefully clarifies your data row-up question. Both the OpenScope and WFL keep a running count of acquired buffers which is this acqCount value.

So acqCount indexes the buffers and not single datapoints? I have forked https://github.com/Digilent/dip-angular2 in order to implement the missing parameter acqCount in my own repo. Unfortunately with little success until now. So I was not able to test what it does. Without this parameter OpenScope won't reply with any data. It appears to me it doesn't even start sampling without the trigger being armed.

About the dip-angular2: reinstalling this package (or also digilent-chart-angular2) in my project folder - even when using the original repos - will somehow lead to corrupted dependencies in my setup. The transpiler will throw rxjs related errors then. I was just yesterday able to fix this by manually changing the rxjs version in both package.json's from "5.0.0-beta.12" to "5.5.11" and reinstalling them. It gave a warning that some peer dependency from angular 2.0.0 was missing, but my ionic project worked again. It would be nice if the dependencies were updated on github.

my ionic info outputs:

Ionic CLI 3.20.0

Cordova CLI 8.0.0

@ionic/app-scripts 3.1.11

ionic-angular 3.9.2

Node v8.11.3

npm 6.2.0

Raspbian Jessie (Linux 4.14)

 

Quote

It sounds like you want a similar approach to what is happening when the trigger is set to off: begin acquisition, poll the OpenScope for available an available buffer until you get it, process the buffer and then ask the OpenScope for more until you are satisfied.

That's right. Only instead of replacing older buffers (in the chart) with the most recent one, I would like to row them up to get the whole graph until a trigger condition is met. So if I have to turn off the trigger in order to 'stream' the data, I wont be able to stop acquiring data without manually reading out the data points to see if the trigger condition is met. At least this is how I understood your proposal.

I think I might have found an easier way to achieve this (if the trigger is anyways of no use) by using the logger instead of the osc. Here I simply have to tell the device to sample infinity amount of data -> read all available data starting from an index -> increment that index by the amount of data samples actually read -> push the data to my chart -> go back to the second step of reading data starting from the new index.

That way I don't see the risk of either overlapping or loosing data samples, as long as I can make sure that my read frequency is higher than the "buffer full"-frequency of the device. Another advantage is that I don't have to wait for a whole buffer to fill up, enabling me to draw a smooth streaming plot by setting a high read frequency.

It appears not so many developers are interested in customizing the OpenScope for their needs rather than trying to have you get WaveForms to do what they want. That's really sad!

Thanks again

Fabian

 

Link to comment
Share on other sites

  • 2 weeks later...
On 7/19/2018 at 2:01 PM, Fa-b said:

1. Is there a more detailed list containing information about status codes than this?

 

See here. These are the codes extracted from enum OPEN_SCOPE_STATES in Openscope.h. I think this list of status codes is faulty with regard to the 'Warning' code range. Anything between 0x00 (OK) and 0x40000000 is used for internal states and manufacturing tests. I don't think they will ever be sent out by the Openscope and therefore I haven't included them to my list.

Note that compound error codes may come OR'd with more detailed information from the indicated source:

// OR'd in errors can be from 0x00000000 -  0x000FFFFF

 

I did not add any description but the identifiers should be self-explanatory.

 

Regards

Fabian

image.png

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...