Fa-b

Members
  • Content Count

    20
  • Joined

  • Last visited

  • Days Won

    1

Fa-b last won the day on July 30 2018

Fa-b had the most liked content!

About Fa-b

  • Rank
    Member

Recent Profile Visitors

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

  1. Amplifier for K type Thermocouples: AD8495/AD8497 TMJ = (VOUT − VREF)/(5 mV/°C) Reference OpenLogger
  2. @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
  3. 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
  4. @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
  5. @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
  6. 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
  7. 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.
  8. @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
  9. 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
  10. 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
  11. 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
  12. 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 '1.2.9.6.0', 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
  13. Hey banban, I have not tried to mess with the openscope firmware myself yet and I'm not much experienced with pic32 MCU's, so I don't know if there is a possibility to toggle a GPIO directly through the same hardware modules used for the trigger. But there might be. So I will just tell you what comes to my mind looking at your software TRIGGER_OUT approach: 1. Keep in mind that you are working on a 32 bit MCU that is able to do 32 bit operations in hardware, use size_t (falls back to uint32_t) rather than uint8_t unless really necessary. 2. Put your piece of code directly to the interrupt service routine for the LA to save some more time: void __attribute__((nomips16, at_vector(_CHANGE_NOTICE_E_VECTOR),interrupt(IPL6SRS))) TrigISR2LA(void) { //put code here Trig2(); } 3. The algorithm you're using to toggle an output pin comes down to this C code: if (toggle) { toggle = 0; if (1 == 0) { LATA &= ~(1 << 5); } else { LATA |= (1 << 5); } } else { toggle = 1; if (0 == 0) { LATA &= ~(1 << 5); } else { LATA |= (1 << 5); } } while this would be enough: LATA ^= (1 << 5); while '^' is the bitwise XOR operator, no need for a toggle variable. Depending on the C compiler you're using (optimizations), the generated assembly from the C code can be really inefficient. This is another reason why I would not try to modify the firmware myself. What latencies are you seeing anyway? Regards Fabian
  14. Hi Ictinike, I do not have a solution for your problem but maybe I can help you finding one. The Errorcode you received in the first image of your second post shows 0x90403F0F. This is a compound WIFI connection error (0x90400000), so the interesting bits are 0x03F0F. Digging through the MRF24G universial driver headers makes me believe that you receive a deauthentication frame from your AP. Maybe looking into the log of your AP can help you at least to find a reason for that. The Error you receive in your latest post indicates that there are no WIFI networks found. Regards Fabian
  15. See here. These are the codes extracted from enum OPEN_SCOPE_STATES in Openscope.h. I think this list of status codes is faulty with regard to the 'Warning' code range. Anything between 0x00 (OK) and 0x40000000 is used for internal states and manufacturing tests. I don't think they will ever be sent out by the Openscope and therefore I haven't included them to my list. Note that compound error codes may come OR'd with more detailed information from the indicated source: // OR'd in errors can be from 0x00000000 - 0x000FFFFF I did not add any description but the identifiers should be self-explanatory. Regards Fabian