• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JColvin

  1. Hi @joniengr081, You should be able to attach files now as part of a reply to a thread; you were in a different member account type since you had created an account but had not posted anything within a month or so of creating that account (this is done as an attempt to help prevent any bots from just waiting until their account is "old enough" before attempting to spam). I apologize for the confusion. Thanks, JColvin
  2. Hi @Stefano Antoniazzi, Have you gotten to look through the Adept SDK download that is available on the right hand side of the Adept 2 Resource Center? It has a number of examples and documentation for it all contained in there. Let me know if you have any more questions. Thanks, JColvin
  3. Hi @Rob Young, Personally I would be more concerned about the data rate that the Pmod WiFi can achieve (with network traffic and software overhead) rather than the rate at which the hardware can provide data through a Pmod port, as the latter can almost always be orders of magnitude faster. In theory an IEEE 802.11g complaint chip (like the one on the Pmod WiFi) can achieve data rates up to 54 Mbps (equates to 6.75 MBps), though in practice this throughput will be less, for example Resource Center for the Pmod WiFi shows 1 or 2 Mbps for transferring data over 400 meters; by how much depends on network speeds/interference and how quickly you are collecting the data to send out over UDP. On the software side for the Pmod WiFi, it only communicates through SPI, so for our FPGAs we use Xilinx's soft core processor (Microblaze) to work with the WiFi software stack to communicate with the Pmod WiFi through AXI Quad SPI IP (Xilinx product guide on it here), and there is some limitation on how fast that soft core processor will be able to run the SPI protocol communicating with the Pmod WiFi, though I'm not certain what the exact impact is in this case. I'm a little confused about your second question. RMII is designed for a physical interface rather than a wireless one, so they don't tend to be directly compatible (they even have different IEEE standards), so unless you find a module that does both (maybe some ESP32 modules do this) it won't be readily feasible. Also, what do you mean by "would look (as closely as possible) like a wired connection"? Do you mean visually look like it, physically in terms of connectivity, or internally with the software? Out of curiosity, why are you looking to do wireless connectivity rather than wired? Thanks, JColvin
  4. Hi @GMA, As a clarification point though since you mentioned it, Digilent does not have any software material for using the USB OTG port, though I believe that Avnet and zedboard.org has some resources on this. Thanks, JColvin
  5. Hi @GMA, As long as they are not "charging only" cables, then yes they will be able to transfer data as well. Naturally, the cables do not facilitate the software side of the data transfer, but there are a number of existing materials to help get the software side of things working. Let me know if you have any other questions. Thanks, JColvin
  6. Hi @GMA, A microUSB Type B cable will be physically compatible with all three of those ports that you listed (PROG, UART, and USB OTG). Thanks, JColvin
  7. Hi @sgrobler, I guess it hasn't been updated for OpenLogger; I personally wasn't aware of an Android app for WFL in the first place. I'll ask about the plans for that, though I suspect since I don't recall hearing about it that there aren't any immediate plans to get it updated. I do agree about the phone browser not being ideal; even in landscape mode, it's difficult to see any relevant details. Thanks, JColvin
  8. JColvin

    Zybo hdmi

    Hi @adityasonavane7, Which particular Zybo board are you using? The original Zybo with both an HDMI port and a VGA port? Or a Zybo Z7-10 or a Zybo Z7-20? We have a demo for the HDMI out for each of the three boards available here and here, with the latter being the same demo example for both the Zybo Z7-10 and the Zybo Z7-20, though the existing projects are different for the two boards. They are all designed for Vivado 2016.4 though and so will not immediately work in 2018.2. As Jon mentions in this thread, upgrading these projects is not trivial. You can update these IPs though as described in this thread. Let me know if you have any questions about this. Thanks, JColvin Edit: looks like Jon beat me to the punch by about a minute. Oh well.
  9. Hi @mossygreen, Okay; to confirm, have you tested this again after your initial post this morning? I did hear (after I originally commented) that the downloads were again briefly down again this morning or at least a bit slow (we're looking into the root cause of this). Out of curiosity, where did you get that particular link you posted? It appears to have the version number that would be present at the end of the link stripped away so the url link is invalid. I believe the link you need for the latest firmware is here. Thanks, JColvin
  10. Hi @mossygreen, The links for the Digilent Agent and (I believe) the firmware were down over the weekend until yesterday morning, so that might be what you ran into in this instance. I just verified on the OpenLogger I have that through WaveFormsLive I can configure with different released firmwares. Are you still running into this issue today? Thanks, JColvin
  11. Hi @hjain, Are you specifically using Adept to connect to your FPGA board (is it a Digilent designed board or a custom board) or are you using the Vivado Hardware Manager to connect your board? I presume you are still using Linux with the newer Vivado versions like you mentioned in a previous thread? If you haven't already, it may be worth it to uninstall and then reinstall the Adept components (available here) if you are using Adept (both the Runtime and Utilities) to make sure it was installed correctly. Thanks, JColvin
  12. Hi @eriksan, I believe that is correct that you would not be able to dynamically store every pixel for the Pmod OLEDrgb within the uC32 to display it. However, if you have a pre-designed image (or set of images), those can be stored externally and accessed and displayed whenever you need them. The other thing to consider though is if you are changing every pixel on the display or only a small subset of pixels (or just storing premade images in the on-board flash). In the end though, @xc6lx45's suggestion/consideration of using a board that is more readily designed to accomplish the task of image display and double-buffering than doing a lot of up-front work yourself. Thanks, JColvin
  13. Hi @hongthiet1994, I think you are correct in that the HY3131 will not be able to read a 1 kHz signal, based on the datasheet of the HY3131 only claiming an output rate of 5 Hz (though it isn't the most clear on this point). I believe the important thing to remember with this module is that it is acting as a digital multi-meter, not an oscilloscope (which can operate at high speed). Does that answer your question, or did I misinterpret what you were asking? Thank you, JColvin
  14. Hi @GMA, The physical end of a Type-C connector will not work with the Zedboard as the pins and data lines inside of the cable are different between Type C and Type B. You can connect the micro-B cable to a USB 2.0 or 3.0 (or 3.1) port on a host computer though, but the data connection speed will be limited to 2.0 data rates (because that was all that existed at the time the Zedboard was designed). Let me know if you have any other questions. Thanks, JColvin
  15. Hi @eriksan, Could you let me know what you are hoping to accomplish with the double buffering? Additionally, when you are referring to a QVGA Pmod, are you referring to the Pmod MTDS? If you wanting to know if you can use it with Digilent boards, you can see the list of support Digilent boards (of which the uC32 is listed) in the library download. You would not want to use the SF3 to expand RAM; the SF3 (and other serial flash modules) are designed to store data in the long term and cannot be used as RAM in the way you are intending. You could store premade images on them, but realistically I would recommending having them on a microSD card and then insert that SD card into the slot that is present on the Pmod MTDS (or the MTDS Shield). Regardless, the both variants of the MTDS have their own embedded PIC32MZ processor that controls the display process, so you are only able to send commands and are not able to configure if double buffering is used by the display or not. As for the individual connections, you can individually wire the Pmod MTDS to the correct pins on a uC32, attach it to a Pmod Shield as you suggested, or just use the MTDS Shield directly on the uC32 (or a different supported board with Arduino headers). I don't believe any of the Digilent boards have graphical RAM that you are able to specifically utilize. They tend to instead have SRAM. With regards to the Pmod OLED or the Pmod OLEDrgb, I'm not certain what the purpose of double buffering would be since OLEDs do not refresh their displays like an LCD screen; you can simply manipulate the individual pixels to be on or off through the provided libraries. However, you certainly can have other images prepared and loaded into memory on the Pmod OLED before updating the display. Let me know if you have any questions about this. Thanks, JColvin
  16. Hi @sgrobler, The only time I encountered this error regarding your second question was when I powered on my OpenLogger (after the WiFi data had been stored on the OpenLogger) before I had turned on the hotspot on my phone; if I did that, I would get the connecting to device message and nothing would happen. If I powered on the hotspot first and then the OpenLogger second, the blue LED on the OpenLogger would turn solid (indicating WiFi was ready and connected), then it would connect without issue. Thanks, JColvin
  17. Hi @ammolytics, That's interesting for the Magnetospeed only having one input; usually you would expect two separate outputs so that there is no conflicting voltages with the two of them. But if it works, it works I suppose. If the accelerometers you have are all analog (which I guess I didn't realize was a thing), the OpenLogger would be a lot more suitable for this. The only concern I would have then is that the OpenLogger can manage the aggregate sample rate to keep up with all of the analog inputs that are being measured (6 analog inputs for an aggregate 83 kS/s, equating to 12 microseconds between each sample) which equates to about 10 samples per a single stress wave traversing the distance. Depending on your application, this may be sufficient for you though. As for the microcontroller/microprocessor board that could work, an Arduino styled board could work, though both the sample rate and the voltage range for the analog inputs; I'm only familiar with Arduino style of boards and Digilent's own brand of microcontrollers (which are similar but have different specifications in terms of number of IO and speed and some peripherals, but will still potentially have the voltage input range issue depending on the signals being provided from the source. I haven't used the Raspberry Pi or BeagleBone boards so I can't really comment on the effectiveness of those. Thanks, JColvin
  18. Hi @BTTroyer, I'm still looking into this (hoping to get it resolved today), but as a workaround that popped into my head, you could have the WF32 connect to your phone's hotspot (if that's a feasible option for you). That way you can get it connected to a network without it leaving the building. Thanks, JColvin
  19. Hi @BTTroyer, I compared the functions between the Digilent Core and the ChipKIT core and it looks like the functions are different (i.e. doesn't look like it needs to be connected to WiFi initially to get the MAC), but I will test this out and see what I can get. Thanks, JColvin
  20. Hi @Erickson, As an additional reference, here is a link to the matching component that would go with the Arduino styled headers for the unloaded J1 (digikey link). Thanks, JColvin
  21. Hi @sgrobler, This should be possible to do, or at least I have it successfully set up on my phone's hotspot. I remember there being similar issues with the OpenScope MZ, but I wasn't able to replicate them* Here is what I did to get it working: - Get the phone hotspot details stored into the OpenLogger Wifi information while it's connected to the PC via the Digilent Agent. Be sure to write down the IP address so you can connect to it later. I also confirmed while it was still powered to the computer that I could connect to my phone via the hotspot. - Disconnect the OpenLogger from waveformslive.com on the PC and make sure the Digilent Agent has disconnected as well. I then turned off hotspot and removed the instance of the OpenLogger connection on the phone for good measure. I also disconnected the Openlogger from the power source (the PC in this case). - I then turned the phone hotspot back on, and after that connected the OpenLogger to power (in this case, it was my PC, but I checked to make sure that the Digilent Agent didn't automatically connect to it, and thankfully it didn't). The OpenLogger lit up with the solid blue LED and I was then able to bring up waveformslive on the phone browser and connect to the OpenLogger via the previously written IP. *Of note in this procedure was that I had to turn on the hotspot first and then connect the OpenLogger to power. If I attempted the other way around (power on the OpenLogger and then turn on the hotspot), I was not able to connect to the OpenLogger. I am not certain why this is. As a fair warning though, while the WiFi streaming capability technically works, WaveFormsLive.com cannot keep up with the incoming data from the OpenLogger at fast sampling rates (I was only able to do about 200 kS/s for a single channel) before the two devices (phone and OpenLogger) got desynced, making it so that you are not able to get more data without either the streaming process stopping or forcing you to close out of the instrumentation panel and then going back into it. The screen update rates (i.e. the rendering on the screen) at faster sampling rates will also be slower than over USB. Let me know if you have any questions. Thanks, JColvin
  22. Hi @PhilHaw, Any number of supplies will have the appropriate audio jack (it's just a standard 3.5mm audio port), but the specific part number that was used is: Kycon 806-STX-3000. Thanks, JColvin
  23. Hi @hongthiet1994, My understanding is that the code for the DMM Shield does not currently support the reading and displaying of waveforms (because the DMM shield doesn't have a display). As shield is reading inputs from an external source, it is possible minimize the reading delay and set up some extra code to display these points on a separate screen. None of us here at Digilent have attempted this though. Thanks, JColvin
  24. Hi @ammolytics, This forum section will work. It definitely sounds like an interesting project. The main hurdle that I'm seeing with this project is that you will either need multiple Discovery's and OpenLogger to collect all of the analog inputs and the digital inputs. Accelerometers tend to provide their information in a digital fashion (such as through SPI or I2C) so while the Analog Discovery 2 can read in this data, the OpenLogger is not able to directly interpret protocol messages. However, the Analog Discovery 2 needs to be connected to a laptop to store the data, which you stated you do not need. The 3 strain gauges will likely have analog outputs as well as the output from the Magnetospeed Chronograph that you linked, though I don't know if it provides 1 or 2 analog outputs (since it uses 2 hall effect sensors). So that is 3 analog inputs required, plus 2 digital inputs (from the 2 hall effect sensors), as well as 3 digital inputs that will likely require interpretation. Looking at the sources you linked, it does not appear the required sample rate will need to be incredibly fast (guessing based the links where it said the stress wave travels from receiver to muzzle in about 0.12 mS, or 120 microseconds). Based on this, you likely could use a 1 MHz sampling rate (1 microsecond resolution) to capture all of the data you needed, of which the Analog Discovery 2 can achieve, while the OpenLogger will be limited (while using 3 analog inputs) to 166.7 kS/s (6 microsecond resolution), though depending on how many sample points you need, this may be sufficient for you. The main thing I'm getting at is that I don't think that either the OpenLogger or the Analog Discovery 2 will an all-in-one solution for you; the Analog Discovery 2 because it only has 2 analog inputs and you need at least 3 (and it can't store data to an SD card), and the OpenLogger because it doesn't directly interpret data protocols that will likely be coming from the accelerometers. To be fair, the OpenLogger could in theory receive all of the bit-banged data accelerometer data on digital inputs and then you interpret them later, but the logging functionality (or at least the ability to read the logged data) isn't integrated yet and this also presumes that accelerometers will power on and start sampling data in the exact configuration you want upon start-up with no instructions provided to them which is not a guarantee. What I would probably recommend looking into would be using a microcontroller or microprocessor to collect the data and store it on an SD card, since there are a number of microcontollers that have both enough analog and digital inputs and you can program them to to interpret the protocol data from the accelerometers for you and send only the relevant data to an SD card. You'll likely need to use an external analog-to-digital converter if the voltages you are measuring are outside of the ranges that the on-board ADC can accept (usually either 0V to 3.3V or 0V to 5V and Magnetospeed sensor you linked was showing 7.6V to 9V readings). Let me know if you have any questions about this. Thanks, JColvin
  25. Hi @rprevost453@gmail.com, Thank you for information; the product manager is still at the conference so I haven't heard back as of yet (or at least haven't had a formal conversation with them), but even if that doesn't go through nicely, I'll work on making sure you receive the material regardless. Thanks, JColvin