• Content Count

  • Joined

  • Last visited

  • Days Won


Fa-b last won the day on July 30 2018

Fa-b had the most liked content!

About Fa-b

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thats right, plus you will need it to setup WiFi in the first place and to flash a new firmware to your device.
  2. Hi @Vroobee, I experienced this when the WiFi signal of our local network was not strong enough where the OpenScope was located. Also check if you have a MAC filter or static IP adresses enabled in your local network. I think the Scope will prompt that error also when the connection has been refused by the other side for any reason. Regards Fabian
  3. Hi @Phil_D, Where do you see ADG612? OpenScope MZ uses TS3A5017 to switch between 4 gains (0.075, 0.125, 0.25, 1). And as far as I can see from the schematic there is no gain switch for the OpenLogger. Are you sure you are asking your question in the correct (sub-)forum? Regards Fabian
  4. Amplifier for K type Thermocouples: AD8495/AD8497 TMJ = (VOUT − VREF)/(5 mV/°C) Reference OpenLogger
  5. @Raghunathan, Maybe the Windows 10 Firewall is blocking requests to port 42315 or to the Digilent Agent in general? I recommend to check the firewall settings. Regards Fabian
  6. Hi @TaiShengY, I think the transmission is the bottleneck for continuous acquisition. When using USB the baudrate is at 1.25MBaud and then we're talking bits so including 1 start and stopbits there is 125kB/sec. 12 bit resolution probably sent in 16 bit raw integers makes 62.5kSa/sec in theory. Then you have to account for protocol overhead. The OpenScope hardware though is capable of 6.25MSa/sec. I don't know about the WiFi transmission rates achieved by the OpenScope, but I expect the protocol stack to consume a lot of the potential speed. I can even imagine that data are sent from the scope at the same rates as if it where connected through USB. Interested what Digilent will say. Regards Fabian
  7. @BecauseIHaveto, Unfortunately I think you won't be able to use the SPI of the OpenScope MZ without adding custom code to the existing firmware. And I guess that would be a tricky thing to do. Is a serialnumber the only purpose of that external EEPROM? Maybe there are other ways to achieve what you need. This chip can be both UART + I2C Bridge at the same time. If you plan to use the openscope with USB, maybe you can modify the hardware to use this instead of the FTDI chip onboard. The Baudrate might be a limiting factor though... Regards, Fabian
  8. @BecauseIHaveto, Have a look at point 19 of the Getting Started Guide. It is Typescript, but the order of commands to be sent to the OpenScope will be similar: - Set Parameters of the Oscilloscope Module - Set Parameters of the Trigger Module - Arm the Trigger Module ('single' trigger is used since 'run' is not implemented in the Openscope, you will have to re-issue the 'single' trigger arming after you successfully read, see @Kristoff's post above) - continuously call read the Oscilloscope Module (The guide uses a 100 ms Timeout for the calls) The read will return with a success status (statuscode: 0) with the count of samples taken when the trigger condition is met and a chunk data transfer following the JSON packet. It will return with a statuscode other than 0 if the trigger condition is not met (Probably: Instrument In Use). You can then force the trigger instead of waiting for a real trigger condition to occur. It is important that you always wait for the response of the instrument before you send out the next command. The Typescript library uses Observables for that purpose. Hope this helps, Fabian
  9. Hi @Bruce Boyes, No idea about Ubuntu setup and I'm really not an expert about this, but here are some of my thoughts that hopefully will be of help to you and maybe others: This sounds like a driver related issue. When you first plug-in the OpenScope, drivers should install automatically. If not, maybe you can try to manually install the drivers (check this out). 42135 is the port used by the Digilent Agent for WaveForms Live to communicate to it. If you try to access the Digilent Agent directly from your browser, I'm not suprised you get a 404 Error, since this is not a valid HTTP request expected by the agent. Let me explain how I see it: WaveForms Live itself is a front-end that displays a GUI in your browser. It has no access to the physical ports of your device/PC (I know unfortunately this is not exactly true in reality, but I guess it is for WaveForms Live) and for this reason a back-end is used to establish a connection to the OpenScope MZ through USB, namely Digilent Agent. Digilent Agent simply identifies Serial COM Devices attached to your device/PC and makes them available to the front-end by establishing a HTTP server on your machine using port 42135. The front-end knows about that port and the routes required to communicate with this server. It sends out HTTP requests to it and gets responses. The Digilent Agent is just a bridge between OpenScope MZ and WaveForms Live, forwarding messages in both directions. You actually only need it at first to configure the OpenScope MZ to use your WiFi network. After that, the OpenScope MZ itself can act as a server and WaveForms Live will be able to communicate directly with it. This means the communication will be over your access-point but still inside your local area network rather than over your device/PC only as it would be with the Agent. So no need for an Internet connection in any of the cases. Will be slower also because of the WiFi network in between. I hope this answers the following question: Using waveformslive.com just makes sure you are running the most up-to-date version of it. There is no limitation I can think of when running it locally (check for the offline build) I think cookies and local cache are used to store configuration data. I am not sure about the calibration data. I would expect it to go into the flash of the OpenScope MZ. But maybe clearing your browser cache and cookies will help getting this fixed. OK that's weird. Cannot imagine that this has anything to do with Digilent. These are most likely the binary chunks from your measurement. The terminal just shows you what is being sent as a HTTP response to WaveForms Live. Communication is using JSON format, but for the measurement data this is far too much overhead. So the binary data is sent in raw format, upfront a JSON 'header' specifying the amount of data following. Have a look at the Digilent Instrumentation Protocol. No need to worry about that. Short note on this: My latest knowledge is that the Trigger_IN as well as Trigger_OUT functionality are yet to be implemented in the OpenScope MZ firmware. Please correct me if I'm wrong. Regards Fabian
  10. They are to get a negative supply out of the positive digital output from the uC. Since the output of the uC is between 0 ... 3.3 V max. VREF1V5 is the node determining at which point the IC10A will switch from positive output to negative and vice versa. The opamp will always attempt to keep the difference between inverting and non-inverting inputs zero. VREF3V3 is a pullup of the inverting input, if the inverting input is pulled below 1.5V, the IC10A output will become positive in order to bring the inverting input back to 1.5V. On the other hand, when the inverting input is above 1.5V, the output of the IC10A will become negative to bring the inverting input back to 1.5V. I guess VREF3V0 could have been a higher voltage as well. But VREF1V5 should be as close to the center of the uC supply as possible in order to achieve symmetric output and the best resolution thereof. I'm also guessing they were not willing to rely on a stable supply voltage from the linear 3.3V regulator and probably already required a precision 3V reference for other purposes.
  11. @BecauseIHaveto, Have you reset the instrument prior to using it? Have you configured and armed the trigger before attempting to read the osc? As far as I remember there is no 'No Trigger' mode implemented in the OpenScope. If you want this, you will have to manually force the trigger periodically. Regards Fabian
  12. Hi @AndrewHolzer, You were right. I went to the Developer Tools' Application Settings and cleared the site data one after the other. But luckily it was neither cache nor cookies, but the IndexedDB storage that caused this issue. I looked a bit deeper: The reason for this issue appears to be the advanced settings. After clearing IndexedDB I get this list of firmware versions from 'update-firmware.ts': ["0.176.0", "0.185.0", "0.283.0", "0.339.0", "0.352.0", "0.354.0", "0.355.0", "0.358.0", "0.369.0", "0.371.0", "0.374.0", "0.387.0", "0.392.0", "0.414.0", "0.423.0", "0.428.0", "0.533.0", "1.2.0", "1.4.0", "1.37.0", "1.286.0", "1.294.0", "1.295.0", "1.296.0", "1.301.0"] When I go to the Advanced Settings in WFL and opt-in to 'Use Dev Firmware Builds', I will afterwards receive this list of firmware versions: ["0.176.0", "0.185.0", "0.218.0", "0.243.0", "0.283.0", "0.319.0", "0.320.0", "0.321.0", "0.326.0", "0.334.0", "0.336.0", "0.339.0", "0.352.0", "0.354.0", "0.355.0", "0.356.0", "0.358.0", "0.369.0", "0.379.0", "0.381.0", "0.385.0", "0.386.0", "0.387.0", "0.391.0", "0.392.0", "0.397.0", "0.399.0", "0.414.0", "0.415.0", "0.416.0", "0.417.0", "0.418.0", "0.423.0", "0.428.0", "0.516.0", "0.529.0", "0.533.0", "1.1.0", "1.2.0", "1.4.0", "1.5.0", "1.9.0", "1.19.0", "1.24.0", "1.27.0", "1.30.0", "1.32.0", "1.35.0", "1.37.0", "1.56.0", "1.61.0", "1.71.0", "1.84.0", "1.94.0", "1.95.0", "1.102.0", "1.105.0", "1.107.0", "1.110.0", "1.115.0", "1.120.0", "1.123.0", "1.190.0", "1.194.0", "1.200.0", "1.202.0", "1.208.0", "1.214.0", "1.217.0", "1.219.0", "1.223.0", "1.226.0", "1.229.0", "1.231.0", "1.233.0", "1.238.0", "1.239.0", "1.243.0", "1.245.0", "1.246.0", "1.251.0", "1.253.0", "1.254.0", "1.259.0", "1.260.0", "1.262.0", "1.269.0", "1.276.0", "1.279.0", "1.285.0", "1.286.0", "1.288.0", "1.291.0", "1.294.0", "1.295.0", "1.296.0"] Note that now the latest firmware version '1.301.0' is not listed anymore. So this switch was actually what was causing me not to see the latest firmware. I'm guessing the Dev-Builds list is simply not up-to-date yet. Thanks and regards Fabian
  13. Hi @AndrewHolzer, Thanks for updating the version on GitHub. I can't tell why, but version 1.301.0 is not shown for me using WFL: Version 1.296.0 is the latest version I can find scrolling the list. Can this be a regional thing?! Looking at the code differences from your GH update, I assume this won't have an effect on the LA trigger anyways. So I will just do as you requested using v1.296.0: - Starting WFL and connecting to the device (tested both WIFI and UART). - On the OSC page changing trigger source to LA - press run without modifying the trigger configuration.. works (All triggers off): - Changing any of the trigger slopes (in this case Ch1 to falling edge) and pressing start again prompts the following toast: During writing, I have just realized that I might be missing an additional step for this to work. Since I have not actually needed the LA trigger-in functionality, I have never thought about actually configuring the GPIO's through the 'Digital' tab. Doing that once after the OpenScope has powered up solves the whole issue. So it appears the GPIO's are initialised to an incompatible state for the LA. Maybe this is the same issue @banban faces using his python library. Let's wait and see what he will say. Thanks again, regards Fabian
  14. Hi banban, Sorry, I have not seen version 1.310.0 when I checked. I agree with you, therefore I have just opened an issue on GitHub: https://github.com/Digilent/openscope-mz/issues/7 Please +1 for it to be considered by Digilent. Regards Fabian
  15. Hi banban, There is an open issue #6 on github about the MPLAB-X IDE project files (see here). Though, i don't think this will happen since the firmware appears to have been developed using Arduino 1.6.9 IDE. Here is a resource explaining why: https://blog.digilentinc.com/digilent-core-on-arduino/ The Digilent Core for Arduino IDE comes with a compiler, so I suggest you stick with that. The latest available firmware is indeed available on github (v1.296.0). I agree it is very confusing but '1.296.0' does not mean '', so Digilent has made a huge step forward from the previous version available on github (1.6.0). I can confirm that LA trigger does not work on that latest firmware and unfortunately I could not find version 1.6.0 using waveforms live. I was however able to flash version 1.9.0 and it appears that LA trigger is not broken there! So chances are high it is working on 1.6.0 as well. I suggest you 'git checkout -b <branch-name> d05afb1' rather than trying to find the responsible piece(s) of code, and see if that works for you. @Digilent: At least, versions that you make available for flashing through Waveforms Live should be available as source code as well. From 1.6.0 to 1.296.0, there has been no information on what has changed in the openscope. Though, the minor-version increase is massive. Why not use the patch-version if those changes contain mainly bugfixes and really minor changes that may be unstable? It appears now, that one of those patches has introduced a major bug and it will be nearly impossible for us to fix that without your help. Migrating back to 1.6.0, nobody knows what features will be lost/broken... Regards Fabian