Fa-b

Members
  • Content Count

    17
  • Joined

  • Last visited

  • Days Won

    1

Fa-b last won the day on July 30

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. Fa-b

    Read EEPROM via OPENSOPE MZ

    @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
  2. @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
  3. 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
  4. 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.
  5. @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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. Hi Marcel, It might be that the Trigger output and input pins are simply not implemented in software yet. The Openscope MZ is an OpenSource project after all. So it would be possible to implement that functionality yourself, theoretically. Since you are planning to write a JSON script to trigger your OSC2 from OSC1, you should be able to set the trigger position to 100% of the time axis, and in your program immediately set a dedicated GPIO output to trigger OSC2. Of course the captured data from OSC1 is of no use in that case. And again, not sure if the achieved timing would be good enough for you.. Regards Fabian
  14. Hi WaRc3L, I have checked this today using an external Scope. I can confirm that the Trigger Output pin seems to not be implemented (though I did not have much time to test it, so I might be wrong). I didn't also find any hint in the protocol that there was a setting for activating the pin. Even tried it with a pullup in case it was an active low output, but with no sucess. I did not have enough time to check if the Trigger Input (ext. Trigger) works. But I guess it wont, since there is no such trigger source available from neither Waveforms Live nor the protocol. Waveforms Live had an error whenever I tried to use LA as the instrument with any of the GPIOs as trigger source. Does that at least work for you? If so, maybe you can use the red LED of the Openscope as the Trigger Output. I don't know how accurate its timing is though. Regards Fabian
  15. Hello Andrew, Thanks for your detailed explanation of what is going on between WFL and the OpenScope. Still I have a few questions regarding your answers: So acqCount indexes the buffers and not single datapoints? I have forked https://github.com/Digilent/dip-angular2 in order to implement the missing parameter acqCount in my own repo. Unfortunately with little success until now. So I was not able to test what it does. Without this parameter OpenScope won't reply with any data. It appears to me it doesn't even start sampling without the trigger being armed. About the dip-angular2: reinstalling this package (or also digilent-chart-angular2) in my project folder - even when using the original repos - will somehow lead to corrupted dependencies in my setup. The transpiler will throw rxjs related errors then. I was just yesterday able to fix this by manually changing the rxjs version in both package.json's from "5.0.0-beta.12" to "5.5.11" and reinstalling them. It gave a warning that some peer dependency from angular 2.0.0 was missing, but my ionic project worked again. It would be nice if the dependencies were updated on github. my ionic info outputs: Ionic CLI 3.20.0 Cordova CLI 8.0.0 @ionic/app-scripts 3.1.11 ionic-angular 3.9.2 Node v8.11.3 npm 6.2.0 Raspbian Jessie (Linux 4.14) That's right. Only instead of replacing older buffers (in the chart) with the most recent one, I would like to row them up to get the whole graph until a trigger condition is met. So if I have to turn off the trigger in order to 'stream' the data, I wont be able to stop acquiring data without manually reading out the data points to see if the trigger condition is met. At least this is how I understood your proposal. I think I might have found an easier way to achieve this (if the trigger is anyways of no use) by using the logger instead of the osc. Here I simply have to tell the device to sample infinity amount of data -> read all available data starting from an index -> increment that index by the amount of data samples actually read -> push the data to my chart -> go back to the second step of reading data starting from the new index. That way I don't see the risk of either overlapping or loosing data samples, as long as I can make sure that my read frequency is higher than the "buffer full"-frequency of the device. Another advantage is that I don't have to wait for a whole buffer to fill up, enabling me to draw a smooth streaming plot by setting a high read frequency. It appears not so many developers are interested in customizing the OpenScope for their needs rather than trying to have you get WaveForms to do what they want. That's really sad! Thanks again Fabian