• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JColvin

  1. Hi @arlene703, Could you attach a picture of your physical setup? The only thing I was able to find that closely replicated your setup was that the WaveForm generator (yellow wire) was connected to Oscilloscope channel 2 (the blue wire) rather than Oscilloscope channel 1 (orange wire). Let me know if you have any more questions. Thanks, JColvin
  2. Hi @Deskarano, Thank you for the information; the voltage all look pretty good to me as well aside from the 5V. How are you powering your board? If you are powering it via USB (direct to PC or USB hub?), could you test that voltage? You can access it by measuring between the underside of J13 (the regulator vs USB power jumper) and J11 (an unloaded single pin next to the Ethernet port); this value should be pretty close to 5V (mine is 4.98V). Also, did you get the opportunity to try a different USB cable or computer (to see if that affects power delivery)? Thanks, JColvin
  3. Hi @opethmc, Can you attach a picture of the setup that you are using so that we can better understand your configuration? I presume also that you are keeping PWM pulse width within the parameters described in this section of the Reference Manual here? Thank you, JColvin
  4. Hi @Deskarano, I apologize for the delay; I thought I had sent this off, but apparently not. In the meantime I relooked at this and realized that we inquired about capacitors that are for a newer revision of the Arty, rather than the Rev C board. The newer revisions have some additional protection and capacitors for the DDR memory, so a lot of the numbering system was shifted around, while the board between revisions functionally remained the same. The correct schematic for the Arty Rev C is available here: https://reference.digilentinc.com/_media/reference/programmable-logic/arty/arty_sch.pdf. With that, here are the correct capacitors that line up with the voltage rails we were intending to have you measure: C143 (should be 5V): C64 (should be 0.95V): C162 (should be DDR 1.35V): C159 (should be 1.8V): C152 (should be 3.3V): I have attached a picture for your convenience showing the location of C143, C162, C159, and C152. C64 is on the back of the Arty underneath the letter 'N' in the "Xilinx" silkscreen label. I apologize for the confusion and let me know what you find. Thanks, JColvin
  5. Hi @Nianyu Jiang, Not quite; the mux selects external feedback resistor used. The programmable gain (1x or 5x) is controlled by bit D8 in the Control register (address 0x80) within the embedded AD5933. Similarly, the output voltage range (whether 2V, 1V, 400mV, or 200mV peak-to-peak) is also controlled by bits D10 and D9 in the same Control register address. Can you also link to the paper you saw that talks about expanding the number of electrodes? I'm having difficulty finding it. Let me know if you have any further questions. Thanks, JColvin
  6. Hi @contraption, You'll actually be in SPI Mode 1 (clock idles low and the data is sampled on the falling edge of the clock) since that's what the IC for the DA2 needs. This is what I used on the ICSP header for an Arduino Uno (I don't have a Leonardo available). Let me know if you have any questions. Thanks, JColvin
  7. Hi @Nianyu Jiang, 1. I believe this is high pass filter to move the offset. -- That is correct. 2. I believe this is Op-Amp, but why do we need this? -- This op-amp is arranged as a voltage follower, to help further stabilize the signal. 3. I think this is a switch or multiplexer, but why do we need this here? & 4. Same as part 2. -- This is part of the feedback amplifier that goes from the received signal (after passing through the device under test) to internal ADC, detailed further on page 15 of the AD5933 datasheet and shown again in Figure 24 on page 18. As this user mentions in their post, driving SEL to ground sets the feedback resistor (what the mux/switch is selecting) to 100 kOhms and setting SEL to Vdd sets the feedback resistor to 20 Ohms. The choice in the feedback resistors (as well as the gain factor and output excitation voltage range selected in the Control Register) affects the result which needs to stay within the internal ADC input range of 0V to Vdd. To figure out if the gain through the system is within the ADC voltage input range, follow the calculation presented on page 18: You'll note that this inherently limits what can be reliably measured with regards to the unknown impedance depending on what settings you have chosen, which is also noted in the user post I linked to earlier. Let me know if you have any questions. Thanks, JColvin
  8. Hi @m@tt, I don't believe there is any formally recommended (re)calibration schedule for the Analog Discovery 2; the easy answer is that you can re-calibrate it whenever you feel the need to do so. In truth, the calibration schedule will be dependent on both the individual components personal integrity as well as the number of hours that each component was used. So every year would not be a bad start. @attila do you have a recommendation on this? Thanks, JColvin
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. Hi @victagayun, Thanks for sharing the solution you found! Thanks, JColvin
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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