JColvin

Administrators
  • Content Count

    2879
  • Joined

  • Last visited

  • Days Won

    81

Everything posted by JColvin

  1. Hi @mmhnto, Unfortunately, WaveFormsLive does not currently support WiFi logging and connectivity at this point in time. I believe this functionality is intended to be added soon. Thank you, JColvin
  2. Hi @istiaq, We have uploaded a 3D model to the Pmod CLP Resource Center under the Additional Resources section: https://reference.digilentinc.com/reference/pmod/pmodclp/start#additional_resources. Please let me know if you have any questions. Thank you, JColvin
  3. Hi @Abdul Qayyum, Since we do not know the details of your custom IPs, zygot's suggestion of simulating your design will give you a much more accurate description of how your design will perform than we can provide. Thanks, JColvin
  4. Hi @herve, Re-reading this thread I realized that I was stuck on the "add-on board" side of things, but if you are fine with a completed commercial product (such as @Notarobot mentioned) I would be remiss if I did not also mention Digilent's Analog Discovery 2. Thanks, JColvin
  5. Hi @Yacov Cohen, Unfortunately, I have not had the opportunity to debug and solve the issue of getting continually updated data. I will see if I can get a demo that uses multiple inputs enabled and initiated this week, though I do not think I will be able to get the first problem resolved during that time. Thanks, JColvin
  6. Hi @Nianyu Jiang, Looking at the setExtClock function (line 89 in the .cpp you attached), setting the external clock to be true just sets a parameter to 16 MHz rather than the internal 16.776 MHz. What I would guess that would need to be done for other frequencies is to add another parameter in that function to allow the user to provide their own frequency that matches the oscillator/chip they provided. Thanks, JColvin
  7. Hi @andrewshivers, That is a limitation of the Demo mode; when you initially boot up WaveForms and select demo you are limited to each of the 16 channels to having 1k buffer each. With an AD2 connected, you would be able to select configuration 4 which gives you the 16k sized buffer for each of the 16 channels. Let me know if you have any further questions. Thanks, JColvin
  8. Hi @srv565, The WF32 firmware would not work on the Max32 since it presumes a certain configuration and location of the pins (such as the location of the SPI locations), so I am not surprised that it did not work. I looked at the firmware code (available where you installed the examples for when you downloaded LINX; mine is in the Arduino->libraries folder) and confirmed that the WS2812 libraries are only configured to work with boards defined as "BOARD_WF32" and "BOARD_MEGA". I believe the reason for this is because the board files in MPIDE and the Arduino IDE define (for whatever reason) a Max32 as a "BOARD_MEGA" so the WS2812 libraries that the LINX VIs call also require the mega definition. I was hoping that I would be able to adjust the board files to change this requirement/definition, but I was unsuccessful in my attempts to do so. So unfortunately for now the result is that the WS2812 VIs are incompatible with the Max32. The libraries themselves are compatible with it through the Arduino IDE though. Thanks, JColvin
  9. Hi @Nianyu Jiang, To add onto what @jpeyron said, I took a look at the AD5933 datasheet (the embedded chip on the Pmod IA) and wasn't able to find if there is a limitation as to what the external clock rate or crystal oscillator should be. However, looking at the schematic for the Pmod IA, there are some suggested external oscillators on the page, though they are all for 16 MHz oscillators rather than a 32 kHz oscillator you are looking at, so I am not certain how the chip would respond to a much lower clock rate/oscillator frequency. Thanks, JColvin
  10. Hi @stelian, Thank you for the feedback; we have passed this information on to our content team to verify and implement your suggestion. Thanks, JColvin
  11. Hi @victagayun, Thanks for sharing the solution you found! Thanks, JColvin
  12. Hi @Deskarano, I happened to also have a Rev C to test and I'm getting the same results (within 20 mV) as you for testing the requested capacitors and I know my Arty is working and does not over heat, so we will take a further look into this as to why all of the voltage measurements are not as expected. Thank you for your patience, JColvin
  13. Hi @srv565, I'm not certain what the error actually is; the LabVIEW forum thread you linked with the comment that the firmware code restricting the code to only work on WF32 and Arduino Mega boards would be the most likely reason though I don't know how to readily change. I made a simple LabVIEW code setup to use the Max32 with the WS2812 VIs and stepped into and out of the VIs until I found the VI that generated the source of the error (Wait for Packet VI) though I don't know what's going wrong; it seems like one of the checksums isn't returning a proper value, but I'm not certain how that could be fixed. I have asked another engineer more familiar with LINX and the associated firmware to see if they have a recommendation on what can be done. Thanks, JColvin
  14. Hi @stunix, If both the Cmod A7 and the Raspberry Pi are being powered through an external power supply from the general source (i.e. a power strip) that should be fine. Any differences that would exist in that case should be mitigated by connecting the grounds like you described. How are you monitoring the packets being sent to and from the Cmod A7 and the Raspberry Pi? In general, I would expect that it would be a timing error based on what you described, but I'm not certain. Thanks, JColvin
  15. Hi @StuE, You can set the acquisition mode to be in a different mode than the single acquisition mode (FDwfAnalogInAcquisitionModeSet) which I believe is the default mode and will only fill up a single buffer that then needs to be read and then refilled. There are other modes such as ScanShift, ScanScreen, and Record mode (detailed more on page 22 on the WaveForms SDK Reference Manual) that would do what you are wanting. Specifically the ScanScreen mode does write to the buffer in a circular fashion, though I personally don't know the limitiations associated with reading from and writing to a buffer at the same time. Otherwise what you may want to do Record mode since that runs up to 1 MHz from my understanding ( @attila would be better able to confirm specs on this). I'm also not certain how tight your timing requirements are, but since changing the buffer size and some of the other functions aren't so easily changed, it may be worth it to just have LabVIEW call python scripts (or c based scripts, both available with samples in WaveForms SDK folder with Analog Input examples. Again, I'm not certain on your timing constraints so that may not be of help to you. Thanks, JColvin
  16. Hi @stef, I believe @attila was just showing an example of how to read from I2C since we don't know how your specific sensor is set up so we went with a more general example. Thanks, JColvin
  17. Hi @StuE, I'm not certain what what might be able to be done differently in your setup since you've stripped down the process for what you need done. What you are needing is WaveForms SDK function (which is what the LabVIEW functions call) to adjust the buffer size used by the analog inputs, though I'm not certain what the maximum buffer size is, nor do I believe this function is implemented within LabForms. The function names you would be looking for in WaveForms SDK (available as part of the WaveForms download available on it's Resource Center here), are FDwfAnalogInBufferSizeInfo, FDwfAnalogInBufferSizeSet, and FDwfAnalogInBufferSizeGet. Let me know if you have any questions about this. Thanks, JColvin
  18. JColvin

    AD2 synced with picoscope

    Hi @PEF, I don't know which threads you've looked at already, but I would recommend this thread and some of the links that are in that thread as well, so yes you can sync two or more AD2s to get more than 2 Analog inputs through the use of triggering. Correspondingly, you can probably also sync acquisitions with a picoscope as well, though as each device will have their own independent oscillators, so you'll probably need to periodically resync the two devices to help account for any phase shift that would occur. I'll have to defer to @attila on your last question about the analog and digital signals time synchronization. Thanks, JColvin
  19. JColvin

    3D Model

    Hi @aaronBe, I don't believe we have a 3D model that includes both the case and the PCB, but the case is now available for download in at the bottom of the Resource Center under Additional Resources: https://reference.digilentinc.com/reference/instrumentation/analog-discovery-2/start. Thanks, JColvin
  20. Hi @inselcontroller, That is accurate that DB0-7 is U-PD0 through U-PD7 on the Coolrunner II. Did you configure the Coolrunner II with a DEPP compatible design? This is described more in the DEPP Programmer's Reference Manual and the Digilent Asynchronous Parallel Interface (DEPP) documents that are part of Adept SDK, available for download on the right-hand-side on the Adept Resource Center. Within there, there is also a sample VHDL file for the DEPP that can be used to configure the CPLD so that it properly communicates with Adept on your computer. I also found what seems to be a complete .ucf file for the Coolrunner II on this users GitHub here which more directly answers your question about the pin assignments under the section called "Parallel Data Bus from microcontroller - Port "C" ", starting around line 297. Specifically, it looks like the pins you need are as follows: Wait is on P42, Write is on P41, Data Strobe (DSTB) is on P40, and Address Strobe (ASTB) is on P35. The .ucf and the VHDL file don't have matching names though, so you'll need to fix those as needed so they match. Let me know if you have any questions about this. Thanks, JColvin
  21. Hi @Mary Becker, Unfortunately, we do not have any further details about the conducting paths that describe the resistance and capacitance of each of them, nor a user's manual. Please let us know if we are misunderstanding what you looking for. Thank you, JColvin
  22. Hi @jasons, When you said "I haven't messed with any of the bitstream or device properties" does that mean your project has not changed or that your project has been changed an updated, but the creation process hasn't changed? In general, you may need to adding an initial delay in the beginning of the SDK code can sometimes help if the application is trying to run before all of the power rails are fully up. This can be an issue when the verbose is commented out. Could you post a screen shot of your Block design, the wrapper file and the SDK code? Thanks, JColvin
  23. Hi @pmjobin, Yes, we can make a note to the Cmod page (and other pages as appropriate) to be wary of charging only cables. Thank you for the feedback. Thanks, JColvin
  24. Hi @Yacov Cohen, Unfortunately you have the latest files that I do as I have not had the opportunity to work on this further. Hopefully I will get a bit of time to work on it a bit more this week, but I will let you know when I have made some progress on it, though I cannot guarantee that I will have the time to do so. Thanks, JColvin
  25. Hi @TestDeveloper, That is accurate in that you are not able to do the simultaneous sampling with the two channels configured as is; I asked another one of our engineers about this and they let me know that from what they recall it was originally intended to use auxiliary inputs 4 and 12, but was (evidently) changed during the development cycle. Thanks, JColvin