Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


AndrewHolzer last won the day on February 1 2017

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. AndrewHolzer

    Digilent Instrumentation Protocol

    Hey @BecauseIHaveto, First, I must apologize for my delayed response. I'm still scratching my head on this. Ideally, before reading the oscilloscope you would issue a getCurrentState command and check to see whether the trigger has fired and data has been made available, then perform the read. With how you've got things configured, the 3 second delay before reading would allow enough time for data to be made available to you. I suggest that you try a getCurrentState before the read, looping on that while there is no data and once there is, then performing the read to fetch it. I also suggest that you make sure that you are looping the output of the WaveGen back into channel 1 of the oscilloscope. It is a simple solution, but its easy to overlook because of its simplicity. I'll be looking forward to your update. AndrewHolzer
  2. AndrewHolzer

    Digilent Instrumentation Protocol

    Hi @BecauseIHaveto, What it sounds like to me is that the oscilloscope hasn't acquired any data yet because the trigger conditions haven't occurred. When the trigger is armed, the instrument will wait for the specified trigger conditions to occur, and when that happens some amount of data is acquired and is then made available for the subsequent oscilloscope read command.The error you are seeing makes sense in this case. However, I also see that you are setting of the wavegen instrument and I am assuming that you are feeding this signal back into the OpenScope via oscilloscope channel 1, so we should see some acquired data. I do not see a run command for the awg being sent in the code snippet you sent above, and this right here looks to be the cause of the issue. If you drop in a awg run command after the awg setRegularWaveform, your osc read should (hopefully) come back with some data. Let me know if that works out for you, or whether there is another issue that needs to be fixed. Regards, AndrewHolzer
  3. @Fa-b, It is possible that your browser could be caching the results of the firmware version list operation. You might try a force refresh on the page to see if that fixes the issue. If that doesn't work, I'd like you to try a different browser to see if you can see version 1.301.0 there. If you can, then please go back to your regular browser, and visit the WaveForms Live settings page. Expand the Advanced portion and click the Change Console Log button, and choose Console to enable logging to the browser's console. Open the console (usually with Ctrl + Shift + i), and then visit the Update Firmware page. Capture the console output, and send it to me through a PM. You could also try clearing the browser cookies and cache, however this would mean WaveForms Live would forget your devices, so I only advise you do this if you are okay with this happening. Regards, Andrew
  4. Hi @banban & @Fa-b, I've pushed the most recent firmware version onto GitHub. I don't have a changelog for the changes from 1.296.0 to 1.301.0, but moving forward each release of the firmware will be posted to the repository along with a changelog for the update. I hope that this will help with bug fixes in the future. I also spoke to Keith about the LA trigger where he and I both confirmed that it is working on the latest firmware. We tested this using WaveForms Live and connecting LA channel 1 up to a source producing a square wave at a fixed frequency. Can either of you please clarify how you came to find the LA trigger isn't working as expected? As you, banban, are trying to make a Python interface, it is possible that you aren't configuring the trigger properly. WFL issues a trigger.setParameters command when the user clicks Run. This command sets the source instrument you want to trigger on and the rising & falling bitmask for the trigger conditions. I'll be looking for your updates regarding the LA trigger issue, Andrew
  5. AndrewHolzer

    Was working OpenScope, Now no Wifi

    Hi @Ictinike, Have you resolved your issue, or found anything new? You mentioned this issue began when you updated the firmware; have you tried rolling back to a previous version and seeing if things work properly? If you are still having issues, I can help you troubleshoot and find the real issue at cause here. Regards, AndrewHolzer
  6. AndrewHolzer

    AD2 sample rate

    Hi @chuerta, In WaveForms Live you can configure an oscilloscope channel's sampling rate and the number of samples taken in the instrument panel. The sampling rate is based on the time base by default, but toggling the lock to the right of the setting will allow you to manually set it. You can tweak these values to hone in your FFT resolution. AndrewHolzer
  7. Hey Banban, Trigger In functionality hasn't been implemented in the firmware. We reserved those pins for future implementation but as you've noticed we haven't done so yet. I'll speak to Keith about getting the latest/all the firmware version(s) onto GitHub. He's out until next week, so I ask for your patience until we can get you the updated firmware. Can you please elaborate on how you were using the LA trigger to accomplish your goal? I'll see how I can help you here but I need some more information to do so. Thank you, Andrew
  8. AndrewHolzer

    DIP using dip-angular2

    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
  9. AndrewHolzer

    Web design needs a little help

    @D@n, You're welcome! Glad to do what I can. Andrew
  10. AndrewHolzer

    Web design needs a little help

    @D@n, Ctrl-F5 should perform a hard refresh in Firefox. If you can accomplish the same action through other means, then (hopefully) you'll see some changes. It is also possible that the webpage is cached on some content delivery system. Those are flushed about every 24-hours to my knowledge. Let me know if the hard refresh doesn't work and I will continue looking into it. If it is the case that the webpage is cached remotely, then you should see changes once that cache is refreshed. Andrew
  11. AndrewHolzer

    Web design needs a little help

    Okidokie, I've gone and made a fix and verified on Chrome and Firefox. If you don't see an immediate change when you reload the page, try ctrl-f5 and see if that helps. Do let me know if there are further issues. Regards, AndrewHolzer
  12. AndrewHolzer

    Web design needs a little help

    Hi D@n, Thank you for bringing this to our attention. I'll work on getting this fixed, and I will report back when I have. In the meantime, you can correct the issue by logging into your wiki account if you have one. Thank you, AndrewHolzer
  13. AndrewHolzer

    Petalinux /tftpboot directory not present

    Hi @mihai5, If you are up to date with your tools, then you should check <dir-of-your-project>/images/linux. The link that you provided says that the files you are looking for are found in the /tftpboot directory as well as this images/linux directory. These are just copies of each other. If it isn't important that you find the files you are looking for in /tftpboot, then you should look in the <dir-of-your-project>/images/linux directory. AndrewHolzer
  14. AndrewHolzer

    Cmod A7 GPIO Demo errors

    Hi BeamPower, I've worked on the project you are trying to use. The error you are seeing arises because the clk_wiz IP block is outdated and needs to be upgraded. Thankfully this is easy to do within Vivado. What you need to do is open up the GPIO project, and underneath tools git Report>Report IP Status. This will open a new tab at the bottom of your screen that shows any IP that is being used by the design. The status for the clk_wiz should say that it needs to be upgraded, so check the box next to clk_wiz, and then Upgrade Selected should become active. Click that, and if you see a confirmation that asks you to use Core Containers, make sure you select that option that doesn't use them. After that, you should be asked if you want to generate new output products, and you can do so. Once that is completed, give a shot at generating the bitstream. I've updated the online repositories to contain the updated clk_wiz ip cores. Let me know how everything works out for you! Regards, AndrewHolzer
  15. AndrewHolzer

    artix nexys 4 and keyboard

    Hi @nisarg_shah114, Could you please send a quote of the Vivado error or a screenshot of it? Without seeing the error I would guess that you need an equivalent library statement to make the library that your custom package resides in visible. If that is the case when you get back to me, I will give you the details on how to create your own library using the Vivado tools. Looking forward to hearing back from you, AndrewHolzer