• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JColvin

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. Hi @BTTroyer, I haven't looked into the ChipKit Core recently (we have our own Digilent Core), but presuming the functions are the same, I believe the DEIPcK library has two functions that do just this (getMyMac and getMyIP, described on lines 351 and 382 of DEIPck.cpp) that will populate their respective values when called and then you will be able to send these values to a serial terminal (or whatever you prefer) to be able to see them. Let me know if you have any questions. Thank you, JColvin
  12. Hi @sus-e, One thing that I would try would be to call the mtds.SetDisplayOrientation prior to the mtds.SetDrawingSurface since the latter function tells the system where the drawing surface is, so it is my understanding that currently the code is unaware that the drawing surface has been reoriented. Let me know how this goes. Thanks, JColvin
  13. Hi @bharaths, Can you provide some more detail on what DDR you are attempting to read from/write to? Are you using the on-board DDR present on the Nexys Video? If you are, the DDR chip is hardwired to a 1.5V bank so you would not able to readily use 1.8V logic with it. If you are using an external DDR chip (presumably DDR2 if you are using 1.8V logic), you could use the FMC connector to facilitate the communication between the LVDS and HSTL logic. Based on this forum thread from Xilinx, you should be able to directly use HSTL and LVDS with AC coupled termination with both receiving the others signals without issues. Let me know if you have any questions. Thanks, JColvin
  14. Hi @rosey12, I would recommend you look at online troubleshooting instructions for this as the error does not pertain to an FPGA board of any kind, but your computer; if you are uncertain of how to fix this I would recommend you take your computer to a local repair shop. If you have any questions about Digilent products, please feel free to post them. Thanks, JColvin
  15. Hi @rprevost453@gmail.com, Homework solutions for the Real Analog materials do exist (though they are all scanned copies of the original solutions made by the creator of the Real Analog materials, so Digilent has not gone through to verify the complete accuracy of all the solutions). However, it is my understanding (I am verifying this) that only verified instructors/teachers will be able to get these solutions in the interest and spirit of helping maintain academic integrity for those are taking this as a course at a university. I do not know the policy of providing solutions to users who are going through the material on their own time without a formal setting, partially because of the reality that there is no real way to determine if this is actually true (or just a student pretending to do this on their own time) outside of the honor system, though again, this is just a guess on my part and not an answer. I have contacted our product manager responsible for the Real Analog material to get her thoughts on this, though they are out of the office this week at a conference, so it may be a few days before I hear back. Thank you, JColvin
  16. Hi @cliftw, Digilent simply sells the Multisim Student Edition (as opposed to licensing it), so we are not able to readily comment with certainty in terms of who is authorized to install and use that particular edition of Multisim, though it is my understanding that the $40 version is a permanent license, so long as the user remains in enrolled in the Academic Institution, as per section 4 of Addendum E in the English version of the National Instruments Software License Agreement, https://www.ni.com/pdf/legal/us/software_license_agreement.pdf. I am not a lawyer, but the language used in National Instruments Software License Agreement makes it seem like to use a Student Edition License the user would need to be in "continuing education classes"; there is apparently an option for a secondary school license (as mentioned in Section 5 of Addendum F of the same license agreement), though I don't know the details of that beyond what is stated there. In terms of the limitations of the software, I am not certain if there is limitation between this particular Multisim for students vs the one for education in general. I do know that the $40 version does not come with a Standard Service Plan (which according to NI's website offers live phone and email support from NI engineers, automatic version updates, access to training and demonstrations, and access to historical versions). I don't know what you are planning to use in your course, but depending on your needs/planned classroom material the free version of Multisim Live from National Instruments may suit your needs. In the end, you will likely need to contact National Instruments for accurate information on the available licensing details. Thank you, JColvin
  17. Hi @sambuls, LabVIEW 2014 Home Edition is indeed based on LabVIEW 2014; it includes the Full Development Version of LabVIEW (as opposed to a Student Version of LabVIEW) and is a lifelong (perpetual) license (more details available on the license agreements here and here). I'm not familiar with the Student License so I'm not certain if it's yearly or not; that would be a question for National Instruments rather than Digilent. Unfortunately, there are currently no plans to update LabVIEW 2014 Home Edition to a newer version of LabVIEW, nor do I anticipate there being any plans to do so. Let me know if you have any questions about this. Thank you, JColvin
  18. Hello, None of us here at Digilent have any experience porting material to risc-v material, but the Xilinx materials that we have on the Digilent GitHub for the PmodSF3 is based off of the Arduino styled material for the SF3 (link to PmodSF3 Resource Center), so you might look there for easier to interpret material. I'm sorry we couldn't be of more help. Thanks, JColvin
  19. Hi @Ufuk Keskin, The same github user has a SPI slave version here: https://github.com/Nematollahi/SPI-FPGA-VHDL/blob/master/hdl/spi_slave.vhd. Additionally, remember that in HDL, everything happens simultaneously rather than sequentially so the HDL you have written where you assign data_out as all 1's and then in following line assign data out to one of two options can potentially happen at the same time; so I believe the resulting circuit that is implmented when the code is synthesized will not assign dat_out as all ones and then check the if statement after that. Thanks, JColvin
  20. JColvin

    DMC60c CAN Bus

    Hi @opethmc, I have reached out to some of our other engineers more familiar with the DMC60c CAN protocol about this. Thanks, JColvin
  21. Hi @mkj, I apologize for the delay. I asked our firmware engineer if they had any sample CSV files available for the OpenLogger (simulated or otherwise) and they informed me that they did not have this material at this point in time. Thanks, JColvin
  22. Hi @TSch, Thanks for sharing what you did to get it working!
  23. Hi @Ufuk Keskin, Could you attach your test bench? Right now your code looks like it is set up just so that the dat_out is being fed with the data and filling MISO (so your slave device, the Basys 3, would be sending out data) and the dat_reg is getting data from MOSI, which makes sense, but something is isn't quite right in your design. I would also recommend taking a look at this SPI design to reference to ensure everything is set up correctly. Thanks, JColvin
  24. Hi @bacif, Based on your picture and the voltages you gave me for the capacitors, my best guess at the moment is that some ESD was applied to the FMC connector (which is much easier to do with the FMC breakout board you have attached with all of the exposed pins and the FMC connector in general is very sensitive to this, i.e. no protection, to maintain high speed data throughput), causing the damage you experienced. I'm not certain where the connections have all been made with regards to connecting to the 3.3V to 5V on the initial HEF4104BP, but from what I can tell they look reasonable to me (i.e. nothing jumping out at me with regards to power and ground shorting each other out). The good news is that I'm also fairly sure that it is just IC27 that is damaged (as opposed to the entire Zedboard) as the two capacitors that were not at the expected voltage were C340 (measuring the VADJ voltage) and C368 which measures PG-ALL. PG-ALL (which controls the "power good" LED, hence why it is off), is controlled by a couple of voltage rails (both of which were fine based on the capacitor voltages I requested you check) and VADJ-FB, which if the VADJ supply is not working, would likely lead to the feedback for it not working properly as well. For peace of mind though, it wouldn't hurt to load a different project onto the Zedboard to confirm that the other components are working as intended. One aspect you may not be able to readily test is the PS side of things as PG-ALL does also control Power-On-Reset button for the PS, so if that is not properly being initialized upon power up, it probably will not work as intended. From your second post though, it seems that you have a second Zedboard with a similar set of issues? Thanks, JColvin
  25. Hi @sus-e, As per this thread, the maximum SPI frequency is 3.5 MHz for a PIC32 and a 4 MHz for an AVR chip; anything faster than that will start to cause erratic behavior with the implemented state machine on the embedded PIC32MZ on the MTDS, especially if the touch screen functionality is being used. Thanks, JColvin