AndrewHolzer

Technical Forum Moderator
  • Content Count

    115
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by AndrewHolzer

  1. Hi @mltma, At this moment SD card logging is not supported. You can expect an update that supports it within the week. We are working hard bring this feature to you all, and we greatly appreciate your patience while we work. I can message you here once we've posted the update if you prefer. As for the SD card, it needs to be formatted to a FAT32 file system. If your SD card is formatted correctly, great! You don't need to do anything more. Otherwise you can use your system's tools to properly format the SD card, and once SD logging is supported in WFL you'll be good to go! Regards, AndrewHolzer
  2. Hi @sgrobler, 1. Can you tell me what you are trying to accomplish here? I don't think I understand what you'd like to happen, but I'll try to explain why it is the way it is: We have the concept of units of measurement and prefix, units being things such as voltage, pascal, ampere, etc and prefixes as milli, micro, Mega, etc. The OpenLogger only measures voltages and passes these voltage samples back to WFL which draws the data on the chart. The sensor that your OpenLogger is sampling takes real life analog signals and converts them to a voltage, but you and I would think of that voltage as representing those signals, ie pascals if you're measuring pressure. The scaling popover takes care of translating the voltage output of the OpenLogger to whatever unit of measurement makes sense for the signal you are measuring. The scaling of the unit value happens based on what you want to see in the chart, which can be changed by shift+scrolling in the chart or setting the Volts/ input. 2. Profiles are saved within the flash storage of the OpenLogger. When WFL connects to the device it will query it for any profiles it may have. If you check the file explorer in the logger page, you can expand the Flash section and see each profile saved to your device. Saved scaling equations on the other hand are saved to localstorage in your browser. What browser are you using? I will also mention that in order for these settings to be applied and saved you must click their respective save buttons. If you are doing that but nothing is being saved then there is a bigger issue that I can help you debug. Regards, AndrewHolzer
  3. I am very glad to hear that you got things working John! I hope that you enjoy your new OpenLogger! Feel free to start another post on the forums or shoot me a personal message if you encounter any further issues. I'd be more than happy to help you out. Regards, Andrew
  4. @Scooby, It doesn't seem like your board is bricked and can still be recovered. I want you to try the recovery process one more time. Before you do, exit the Agent in the task bar and check to Task Manager to be sure the process has exited. Once it has, spin up a new instance of the Digilent Agent before proceeding. If you are able, try running through the process on a different computer, so that we can be sure that the real issue isn't with what you're currently using. At this point, check the Device Manager, and underneath Ports you should see which COM port the OpenLogger is on. When you get to step 6, select this COM port instead of the Digilent OpenLogger MZ entry. I also ran through the recovery sequence myself once more, and found that clicking Open while the OpenLogger is in bootloader mode will show the 'Unable to Communicate with Device' popup message, but you can proceed to the next step and click Load Firmware. When you do so, the selected device will be Other, and you'll need to upload the firmware hex yourself. If you visit this link you'll download the latest OpenLogger firmware. Click Browse, navigate to where the hex file was downloaded and select it. Status should say 'Ready to upload "OpenLoggerMZ-0.1619.0.hex". File size is 1892510 bytes". Once you are good and ready, click Flash Selected Firmware and the flashing process should begin. Let me know if this works for you. I also want to thank you for your patience while we work through this issue together. I certainly appreciate it. AndrewHolzer
  5. @Scooby, Did you see LD6 flashing as you typed into the terminal?
  6. Hi @victagayun, When your OpenScope starts initializing the WiFi state, it is reporting a WiFiNoNetworksFound error. Even though you've asked it to save the credentials, the auto connect may happen to fail for several reasons. When a connection attempt fails, the OpenScope only knows that it's disassociated based on the response it gets back from the radio and doesn't retry. One cause of failure may be due to the signal. On a network with many connected devices the routers are increasingly busy and can't service all the traffic. If the OpenScope were on such a network, it may fail to connect to the access point. If possible, try connecting to a network with less traffic, or a stronger signal. Another possibility is that the credentials you've entered are wrong. Because the OpenScope only knows it is disassociated when it fails to connect, it cannot recognize that a connection attempt failed because of incorrect credentials and not because the network is busy. If you double (triple) check the passphrase you used, you should first delete the connection entry from the OpenScope, then proceed to entering the credentials anew.
  7. @Scooby, When you say boot mode I take it you mean bootloader mode? You won't see any output over the serial terminal when you enter bootloader mode. You should connect your open logger up to your computer and establish a terminal session. The first image I've included has the settings I use in PuTTY. Once you've established a session, press just the reset button (P32 RST). After the OpenLogger powers on and initializes itself, you should see some text similar to whats in the second image I've attached. If you don't see any output, try mashing some keys and observe LD6 on the OpenLogger. It should be flashing as you type. Let me know how this turns out.
  8. Hi @dklann, At this moment the OpenLogger is only supported on Windows. Some effort needs to be put into getting the Agent working on Mac & Linux. @Scooby, Is it possible for you to capture the serial output of your OpenLogger during boot? If you use something like TeraTerm or PuTTY, you can see the OpenLogger's serial port output as it boots which can provide some troubleshooting information. When setting up the session, you'll want to specify a speed of 1.25 MBaud. Once the session has established, hit P32 RST near the radio module and observe the output in the terminal. If you can include a screenshot or textual representation of the output in your response we can proceed troubleshooting your issue. AndrewHolzer
  9. Hi @Scooby, It sounds like the .hex file may have been corrupted when it downloaded due to a network issue, or when transfering the file via USB. If you are using a USB hub, we require that you use a USB 2.0 high-speed hub. While updating firmware will usually work with a full-speed hub, we have encountered issues when using full-speed. You will need to run through the Corrupt Firmware Recovery flow to fix the issue. You may want to downloaded the firmware .hex from the resource page, underneath Firmware on the right. If you decide to download the hex from the resource page, when you get to selecting the version of firmware you'd like to flash, select Other and then Browser to select the .hex you downloaded earlier and continue following the guide. Let us know whether you were successful or whether we need to work with you further on troubleshooting this issue.
  10. 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
  11. 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
  12. @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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. @D@n, You're welcome! Glad to do what I can. Andrew
  19. @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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. Hello @nisarg_shah114, The Nexys 4 has an onboard USB host connector with a microcontroller that sits between it and the FPGA. The microcontroller will handle the USB HID protocol and emultates PS/2 bus signals. There will be no need for an external PS/2 to USB converter at all. This section of the Nexys 4 reference manual has details regarding the keyboard connection. The section before it gives details to the HID controller. I hope this information helps you. Do not hesitate to ask any questions you may have, and I will do what I can to help. AndrewHolzer