Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


AndrewHolzer last won the day on February 13

AndrewHolzer had the most liked content!


About AndrewHolzer

  • Rank
    Prolific Poster

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. Hi @Raghunathan, I took a look into the WPA/WPA2 issue you've been having. In short, the WINC1500 driver doesn't distinguish between WPA & WPA2 from the perspective of the software, in happens internally on the chip. The OpenLogger reports back to WaveForms Live what the WINC1500 is telling it during a WiFi AP scan, which is that a WPA/WPA2 network is just a WPA network. I'm glad to hear that switching to WPA got you to the saving stage, but I urge you to go back to WPA2 instead. You are increasing the vulnerability of your local network. Instead, can you please send a capture of the browser console when you try to connect to the network? Perhaps you can also speak about the router you have? Is it using WPA2 Enterprise?
  3. Hi @orquesea, There are a few things going on that I will try to explain to you, that I hope will help you get things working properly and perhaps impart some info on how WaveForms Live is working. WaveForms-Live calculates the expected acquisition time based off the buffer size and the sampling frequency. After clicking Start, WaveForms-Live waits for this period of time to pass before querying the OpenScope for available data. WaveForms-Live also calculates the sampling frequency from the time per division value in order to fit the entire acquired signal on the chart by default. If we were to set the chart to 10 seconds per division, the sampling rate would be 11.8 S/s, at 2360 samples total (also a default). The expected acquisition time would be (2360 S ) / (11.8 S/s) = 200 seconds. Clicking the lock to the right of either values disables those behaviors and lets you manually specify values, thereby tweaking the acquisition time via these two "knobs". You can decrease the acquisition time by decreasing the buffer size or increasing the sampling frequency. You should note that the acquired signal may not completely fill the chart, or may contain more data that the chart window can't show. The defaults given are supposed to be good estimates of sampling frequency for a given time division and the assumed 2360 Sample buffer size. The idea is to change the Time/Division setting to get as close a fit to the signal under inspection you can get with the given defaults, then tweak the sampling frequency and buffer size manually to really clarify the acquired signal. I hope this helps, and if you still have any questions please do not hesitate to ask them here. Regards, Andrew
  4. Hi @Raghunathan, Is it possible for you to send a capture of the browser console log when you are trying to log to the SD card and get the "Error Starting or Running" message? There should be some more technical information in there that should help in debugging your issues.
  5. You will have to redo the calibration every time you program the OpenScope with the Arduino tools. It isn't preserved through the process. You can possibly re-implement the firmware upgrade flow in WFL, which will allow you to preserve the calibration settings that have been saved in flash. Otherwise you can save to an SD card as well. We intended that user calibration exist on the SD card and manufacturing calibration be kept in flash, but both can be overwritten by the user, anyways.
  6. Hi @Ravi Kumar, Thank you for supplying these log outputs as they've proved helpful in finding a solution that should work for you. I took a look through the source code and found that the OpenScope will attempt to save the calibration configuration to the SD card when using the terminal UI, which fails if you don't supply an SD card . I confirmed that I received the save error as you have demonstrated and after a small change that I'll describe to you I saw the error disappear. If you look at line 811 inside IO.cpp, you will see a call being made to CFGSaveCalibration . You can configure the device to save to the flash by changing the second & third arguments to VOLFLASH and CFGFLASH respectively. Let me know what results you get when you make the same changes here.
  7. Hi @Ravi Kumar, I am going to need some more information from you. What version of the Digilent Agent are you running? Can you connect from your PC to the OpenScope using a terminal application (puTTY, TeraTerm, etc.) and see what the output is booting your compiled firmware, and share the results? How recent was the last time that you synced your copy of the firmware source with the Digilent repo (in case you've had it a while)? Can you enable the console logs, and see the output in your browser's developer tools when you try to calibrate your device? I am curious to see what error code you get when trying trying to do so. I would also like to suggest changing something in the versioning info in Version.c, as an easily verified change in the firmware. It is curious how the issues are presenting themselves. I've tried to replicate your issues as best I can, but I haven't been able to do so. I can confirm, with firmware built on my home desktop, that my device can do what you say yours can't. Either way, together, we'll get to the bottom of this.
  8. Hi @Ravi Kumar, I am going to need more information from you in order to proceed with this issue. I haven't been able to replicate your issue unfortunately; I've made a few additions to the OpenScope source, built and flashed the device and can trigger the scope instrument. Can you tell me what Arduino version you are running? Have you made any changes to the OpenScope source code? After uploading your custom firmware, have you calibrated your OpenScope? Your answers to these questions should form a foundation from which we can build an understanding of the issue you are experiencing. Regards, Andrew
  9. Hi @frokostfredag, That's some odd behavior that you're describing there. There is one thing I'd like you to try to debug this, and that's to enable the console output in WaveForms Live before trying to connect to the device. I'm hoping that this lets us see what command is causing the OpenScope to choke. You can do this by going into the Settings page, opening the Advanced section and clicking on Change Console Log. Set this to Console, then open the developer tools for your browser. For Chrome and Firefox this is Ctrl+Shft+i. The commands and their responses, plus some other additional information will be printed in the console here as you use WaveForms Live to configure the OpenScope. I would appreciate it if you could share the results with me, and together we will get to the bottom of this.
  10. Hi @ravikumargrk, Glad you were able to find your solution! If you need any further help, do not hesitate to reach out. We'd be more than happy to help out! Regards, AndrewHolzer
  11. Hi @ravikumargrk, Can you describe what else you have done to configure the OpenScope, such as trigger conditions, and anything else you are doing? Typically this error is thrown while the instrument being read hasn't idled yet. You'll need to issue another read command in that case until the status code comes back 0, with data, or a terminal error. Let me know the answers the above questions, and we'll get to the bottom of this. Regards, Andrew
  12. Hi @herg, I apologize for the long delay, and want to say that I appreciate your patience. I took a look into the source code to reaffirm my knowledge and found that things are a bit easier than I have previously described to you. I had erroneously assumed that the oscilloscope data is sent to WaveForms Live with the samples interlaced into a binary blob. In short, each channel's databuffer is a contiguous portion of the binary data, whose lengths and positions are known from the JSON portion of the response. The read response is still sent in a chunked-transfer format, and I have included an example response for reference here. Note that I have added newlines in the JSON portion to make it easier to read and they aren't included in the response normally. Each chunk first begins with its length given in a hex format which is followed by a CRLF (\r\n in the example) and then the data portion also followed by a CRLF. The read response consists of the first chunk that contains a JSON data structure, followed by the binary data portion and finally followed by a zero-sized chunk. In the JSON portion, each channel has a binaryOffset which is used to index the byte position in the binary data for that specific channel. The binaryLength details the byte count of that channels data buffer. Each sample consists of 2 bytes, so these binary values can be converted into a sample index and sample count by dividing the binary values by 2. The time step for each channel is also found in the JSON portion, from the actualSampleFreq. This value is in mHz which is noted in the device enumeration as sampleFreqUnits. Also found in the enumeration is the voltageUnits, mV for the OpenScope, so proper scaling is required if you want straight Volt units. The triggerDelay is also needed from the JSON portion, as it is used to ultimately calculate the sample's time value as the trigger position. Trigger position can be found by the following formula: triggerPosition = -1 * triggerDelay / 10^12 + dt * (# of samples in channel buffer) Ideally, you'd use the binaryOffset and binaryLength to separate each channel buffer from the binary data. Then, for each channel buffer, iterate the collection sample by sample, or 2 bytes at a time. If we let idx represent the iteration index/count, the time value for that sample can then be found by the formula t = idx * dt - triggerPosition and the voltage value by dividing the value being indexed by 1000. At this point WaveForms Live packages the point for use with the charting system, but you are free to use it how you see fit. I understand that there is quite a bit being described here at a rather high level, and if there needs to be further clarification I'd be happy to help further. I hope this info does you well and sees you to your goal. Regards, Andrew Example Read Response 1FF\r\n { "osc": { "1": [ { "command": "read", "statusCode": 0, "binaryOffset": 0, "binaryLength": 4724, "acqCount": 36, "actualSampleFreq": 236127508, "pointOfInterest": 1181, "triggerIndex": 1181, "triggerDelay": 0, "actualTriggerDelay": 0, "actualVOffset": -1, "actualGain": 0.25, "wait": 0 } ], "2": [ { "command": "read", "statusCode": 0, "binaryOffset": 4724, "binaryLength": 4724, "acqCount": 36, "actualSampleFreq": 236127508, "pointOfInterest": 1181, "triggerIndex": 1181, "triggerDelay": 0, "actualTriggerDelay": 0, "actualVOffset": -50, "actualGain": 0.25, "wait": 0 } ] } }\r\n 24E8\r\n <ch1-binary><ch2-binary>\r\n 0\r\n \r\n
  13. Hi @alockcal, Thank you for your patience. Can you take a look at the Task Manager and see if the Digilent Agent is still running, or if there's any Digilent-associated process running? You may need to kill them here if you still run into the error when uninstalling. You may also want to give your computer a reboot if the process-killing didn't work. Do you happen to have any other Digilent devices plugged into your computer? Any other software? Regards, AndrewHolzer
  14. Hi @herg! Good to hear from you again. I am happy to hear that you found my response helpful. I want to let you know that I'm working on a description of the de-interlace process and data-point extraction. I'm going to need some time to work on that, but you can be sure that it is in the pipeline. I do want to answer the questions in your second paragraph, however. To start, there isn't currently any functionality the way you've described. The firmware would need some modification to allow the dynamic functionality you describe, or to wire that behavior into the system directly. Now, I came in after OpenScope, but looking at the schematic and the pinout on WaveForms Live, it looks like this functionality was at least planned for with the Trigger Out pin. I dug through the code firmware and found no use of this pin anywhere, unfortunately. I'll continue on the de-interlace explanation, and I appreciate your patience throughout our correspondence. Regards, AndrewHolzer
  15. You can follow along with how WaveForms Live sends the commands to the OpenScope, using the browser tools to inspect the HTTP requests, since the commands are either sent to the agent if using serial communication, or directly to the OpenScope using these requests. For Chrome and Firefox, press Ctrl+Shft+i then navigate to the network tab to see these commands and the responses received to them. You can also get an idea as to what commands to send and in what order by looking at the WaveForms Live GitHub source, however, I am not expecting you to take a dive into that just to figure this out. If you are following along in the browser tools, navigate to the instrument panel, configure the device how you want and then hit run. The first command that you should see sent, will be a multi-command that sets the parameters for channel 1, the "osc" portion below, and then one that sets the trigger. These can be sent as separate commands, but the OpenScope also supports these multi-commands that combine several commands into one HTTP request. The relevant section in the code would be at line 729 in waveforms-live/src/pages/instrument-panel/instrument-panel.ts, where the command is sent to the device after being constructed. I only specified a single channel when running this, but for two channels the "osc" command will have both a "1" and "2" portion detailing the parameters for channel 1 and channel 2 respectively. { "osc": { "1": [ { "command": "setParameters", "vOffset": 0, "gain": 0.25, "sampleFreq": 94000000, "bufferSize": 940, "triggerDelay": 0 } ] }, "trigger": { "1": [ { "command": "setParameters", "source": { "instrument": "osc", "channel": 1, "type": "risingEdge", "lowerThreshold": 470, "upperThreshold": 500 }, "targets": { "osc": [ 1 ] } }, { "command": "single" } ] } } The next command you should see sent is one to read the oscilloscope channels. The response that you get back here depends on the state of the OpenLogger. If the trigger is armed, but hasn't fired, you should get something like { "osc": { "1": [ { "command": "read", "statusCode": 2684354571, "wait": 0 } ] } } where StatusCode 2684354571 corresponds to am InstrumentArmed error. In this case, WaveForms Live re-issues the read command until something else is received. If there is data then you'll get a Chunked Response which looks something like this FF\r\n { "osc": { "1": [ { "command": "read", "statusCode": 0, "binaryOffset": 0, "binaryLength": 1880, "acqCount": 39, "actualSampleFreq": 93984962, "pointOfInterest": 470, "triggerIndex": 470, "triggerDelay": 0, "actualTriggerDelay": 0, "actualVOffset": -1, "actualGain": 0.25, "wait": 0 } ] } }\r\n 758\r\n <binary of length 1880 bytes>\r\n 0\r\n \r\n In short, each chunk is prefixed with the byte length of that chunk in hexadecimal followed by a CRLF, then the data itself, also followed by a CRLF. In our case, the device first sends back the JSON response (I've made this 'pretty' for easier reading). From the above example we know that the JSON portion is 255 bytes long. After the JSON portion comes the data portion. Each sample in the binary data consists of two bytes multiplied by the number of enabled channels. For a run with multiple channels enabled the channels are interlaced into one sample in numeric order, so the first two bytes of the sample correspond to channel 1, and the second two to channel 2. After the binary data is another chunk length specifier, but this will be zero and is signal to you that the transfer has completed. Once you have this response, you need to extract the channel data from each sample by de-interlacing it. I can show you how it's done in WaveForms Live if you are interested. Now, WaveForms Live sets the OpenScope trigger to Single, and resets it if doing a continuous run. There is the option to set the trigger to re-arm after acquisition with a Trigger Run command. I can't make a comment as to why WaveForms Live does it like this, since my time with the software was during OpenLogger development, and I don't know why this design decision was taken. In the case that you let it run continually, you'll just send a read command repeatedly and respond accordingly if the trigger is just armed, if there is data available, or some other state has been reached. I believe this will answer your questions, however if you still need further information and details do ask and I will be happy to provide. Regards, AndrewHolzer