• Content Count

  • Joined

  • Last visited

  • Days Won


JColvin last won the day on April 19

JColvin had the most liked content!

About JColvin

  • Rank
    Forum Moderator
  • Birthday April 22

Profile Information

  • Gender
  • Location
    Pullman, WA

Recent Profile Visitors

9086 profile views
  1. Hi @jamesW, I think that the bit depth of both images would need to be the same in order for it to work correctly (which I believe you said did work correctly at the end of your original post), though I am not certain of this. From what I can tell in the MTDS Library Programmer's Reference Manual (available as part of the documentation included in library download), it says in the BitMap Objects section that "Depending on the coordinates specified and the graphical element being drawn, the clipping can result in all, some, or none of the pixels making up the graphical element to be rendered actually being drawn on the bitmap itself. This is not an error, it is simply a natural consequence of the view that a bitmap is a viewport onto a larger virtual coordinate space." Truthfully, though I'm not certain when these circumstances would occur, though it seems to support the idea that both images would need to be the same bit depth. I also know there are a number of raster operations you can apply in the BitBlt() function as it's own parameter which specifices how the source and destination pixels are combined, but I'm not very familiar with how those all work visually, but the operations are defined on page 12. Thanks, JColvin
  2. JColvin

    Vivado free for Artix-7?

    Hi @TerryS, Unfortunately, the download speeds you are reporting are due to your end (either your internet connection or your computer hardware), not Xilinx's end. Note also as a fair warning (since I believe this is your first time using Vivado) that even simple projects, such as LED blinking project that xc6lx45, will probably take more time than you expect as the Vivado software needs to program and set every transistor inside the FPGA. There is a nice comment summarizing what all the tools need to during synthesis, implementation, and bitstream generation here. But as @xc6lx45, a lot of the material looks more complicated than it actually is, mostly because it's a different language. Thanks, JColvin
  3. Hi @dcc, I'm not certain how you are verifying that the HDL is writing to and then reading back from the SD card in a normal formatting style, but in general FAT32 is a widely used format for SD cards that has existing material for it. I am uncertain why you are using a special tool to write to the SD card though; from what I can tell the tool is Windows compatible, so why not just use the Notepad program which comes with Windows and save a .txt file with the data you are interested in reading to the SD card or just using Windows Explorer (the file manager) to move the file of interest onto the SD card? If you do have a header in your file, you will need to take account for that, though I do not know what you mean by "random file" in this case. Thanks, JColvin
  4. Hi @sgrobler, Our design engineer who designed the OpenLogger did an end-to-end analysis to determine the end number of bits of the OpenLogger. This is what they ended up doing in a summarized fashion: <start> They sampled 3 AAA battery inputs to the SD card at 250 kS/s and set the OpenLogger sample rate to 125 kS/s and then took 4096 samples; they then took the raw data stored on the SD card and converted it to a CSV file and exported the data for processing. Their Agilent scope read the battery pack at 4.61538 V and as they later found from FFT results the OpenLogger read 4.616605445 V, leading to a 0.001226445 V or ~1.2mV difference, which is presuming the Agilent is perfect (which it is not), but it was nice to see that the values worked out so closely. They calculated the RMS value of the full 4096 samples in both the time domain and using Parseval's theorem in the frequency domain as well, both of which came up with the same RMS value of 4616.606689 mV, which is very close to the DC battery voltage of 4616 mV. Because RMS is the same as DC voltage, this gives the previously mentioned DC value of 4.616605445 V. They can then remove the DC component from the total RMS value to find the remaining energy (the total noise, including analog, sampling, and quantization noise) of the OpenLogger from end-to-end. With the input range of +/- 10V input, this produces an RMS noise of 1.5mV. At the ADC input, there is a 3V reference and the analog input front end attenuates the input by a factor of 0.1392, so the 1.5mV noise on the OpenLogger is 0.2088mV at the ADC. With the 16 bits (65536 LSBs) over 3V, 0.0002088V translates to ~4.56 LSBs of noise. The ENOB is a power of 2, so log(4.56)/log(2) results in 2.189 bits, giving us a final ENOB of 16 - 2.189 = ~13.8 bits. Note though that this ENOB of 13.8 bits is based on system noise and not dynamic range, so for non-DC inputs (which will likely be measured at some point) the end number of bits is not easily determined. The datasheet for the ADC used in the OpenLogger (link) shows that the ADC itself gives an ENOB of about 14.5 bits at DC voltage (so the 13.8 bits is within that range), but at high frequencies, this of course rolls off to lower ENOB at higher frequency inputs. Thus, they cannot fully predict what the compound ENOB would be over the dynamic range, but they suspect it all mixes together and is 1 or 1.5 bits lower than the ADC ENOB response. </end> Let me know if you have questions or would like to see the non-abbreviated version of his analysis. Thanks, JColvin
  5. Hi @tjaplayer, When you say WaveForms would not recognize it, do you mean WaveForms does not detect the Analog Discovery 2 at all, or does it just come up as an unknown device? Additionally, are you able to see the Analog Discovery 2 on the Windows Device Manager (presuming) you are Windows? It will appear as "USB Serial Converter" under Universal Serial Bus controllers. Thank you, JColvin
  6. Hi @GMA, Yes, the standard micro USB cables will be sufficient, so long as they are not charging only cables. If you're looking to transfer data at high speeds, you may want to also look into getting a USB certified cable for better results. Those of us at Digilent have used standard cables (such as ones that come with phones to charge and connect to your PC) without issue though. Let me know if you have any other questions. Thanks, JColvin
  7. JColvin

    Genesys 2 DDR Constraints

    Hi @SeanS, Jon and I looked at this a bit further, and it looks like you are using ISE rather than Vivado. Is there a particular reason you are using ISE rather than Xilinx's newer Vivado software? Otherwise, my understanding is that you would need the UCF file loaded with the correct information (as per the legacy ISE material we have for the Genesys and MIG tutorial here). However, the Genesys 2 was developed and released a few years after the last formal release of ISE, so we do not have a UCF file for the Genesys 2 available (nor do we have the appropriate details in the .xdc file thanks to the existence of the board files for Vivado. Thanks, JColvin
  8. Hi @doconnor, I emailed our sales team about this; haven't heard back from them yet myself, but I am confident they will get back to you sometime today or tomorrow. Thanks, JColvin
  9. JColvin

    booting from sd card

    Hi @Michael P, I'm still a little confused. Does Vivado give an error when you are attempting to create the bitstream file? In one of your earlier posts you mentioned that you were able to program the FPGA with the bitstream file stored on the SD card and Jon gave some instructions on how to program the SD rather than QSPI for SDK projects, so I'm not certain what you are running into now. How much space does Vivado claim to this project of yours requires? Thank you, JColvin
  10. Hi @flying, I believe you can implement it (or at least for the Pcam 5C demo, not necessarily the PetaLinux project, as per these two threads here and here). My understanding is that the Z7-10 simply didn't have enough space to also contain the debug portion of the CSI-2 IP core. Otherwise, I believe the Petalinux release uses V4L2 drivers to receive the Pcam inputs. Let me know if you have any questions about this. Thank you, JColvin
  11. Hi @doconnor, Have you received a response yet? The team that manages that email is on a different timezone so they may have been out for the weekend; otherwise, there is no link to go to. The forum is otherwise the appropriate location to ask questions as the Digilent engineers (including the creator of the WaveForms software who responded to you) are the staff that respond to questions. Thanks, JColvin
  12. Hi @LazerBoi64, I'm not certain on the hardware/software (in)compatibility, but I do seem to recall that it should be okay with regards to LINX 3.0 working on both the Raspberry Pi 3 and 3+. The older versions of Raspian are available for download from this page here: http://downloads.raspberrypi.org/raspbian/images/. Based on the dates from other threads, I would recommend going for either the one late 2016 (Nov 29 or Sept 28), or perhaps the early 2017 one. With that, you should be able to install and use it through the Instructables tutorial you linked or through the tutorial here: https://www.labviewmakerhub.com/doku.php?id=learn:tutorials:libraries:linx:3-0. Let me know how this works and if you have any questions about this. Thank you, JColvin
  13. JColvin

    Sample mode

    Hi @Dejdys, I apologize for the delay. I'm not certain what the function would be for that. @attila, do you happen to know the equivalent function name that they can call it within the LabVIEW VI's? Thank you, JColvin
  14. Hi @davittarius, I apologize for the delay; I have sent you a PM about this. Thanks, JColvin
  15. Hi @Ashish Kashinath, I apologize for the delay. The folks over on the NetFPGA mailing list (link if you are not already signed up) which have more experience specifically running the acceptance tests. However, based on what you have described, it seems like the acceptance tests projects are not loaded on your computer if the script does not find the bitstream nor the acceptance test project. Vivado getting stuck during the synthesis and implementation procedure would not be a board issue as the board is not directly involved at this point of the procedure. One potential solution that you could try that has resolved this sort of issue before is using a different, known working USB cable to connect to the NetFPGA SUME and a different USB port on the host computer, as a faulty USB cable can lead to the Vivado Hardware Manager not detecting the attached FPGA. Thank you, JColvin