attila

Technical Forum Moderator
  • Content Count

    2527
  • Joined

  • Last visited

  • Days Won

    175

Everything posted by attila

  1. Hi @jtw The API functions return raw capture data. The processing like FFT should be done in custom application. About a year ago, functions for network/impedance analyzer were added. In case this is what you need see the examples in SDK/ samples/ py/ AnalogNetwork_Analyzer.py, AnalogImpedance_Analyzer.py, AnalogImpedance_Input.py ...
  2. Hi @Pazzo Sorry but I had/have no time for it this week I will try to do it next week.
  3. Hi @vinodcxlv var rgFile = (""+FileRead("~/Desktop/default.txt")).split(", "); // 1, 2, 3 var rgSend = [] rgFile.forEach(function(v){rgSend.push(v<<2)}) Start() Write(16,rgSend) Stop() return("done "+rgSend.length+" bytes")
  4. Hi @dbkincaid You can use the Protocol tool to spy on one UART line with (Send&Received tab). You can enter any desirable rate. In this mode only the decoded bits are stored. In case the average UART transfer is less than ~1Mbps it will work. In the UART Spy tab in order to capture multiple UART lines the decoding is done in software. Lot of data is streamed to the PC limiting the UART rate to ~200kbps. To capture multiple lines at high frequency the Logic Analyzer should be used repeated or record mode.
  5. Hi @jody Unfortunately, depending on the capture rate you may notice communication errors (erc 0x02) after hours or days of continuous usage.
  6. Hi @GeorgeIoak The acquisition data contains only the raw capture. In order to visualize your colleague should add the signals, bus or other interpreter to visualize the data. You can also save/send the project or workspace which contains the instrument setup or all the opened instruments.
  7. Hi @GeorgeIoak I just tested the Save/Load Acquisition in Scope and Logic Analyzer, it is working for me. Could you attach or send your acquisition files to me?
  8. Hi @Federico Massimi You can use Scope Record mode for such purpose and select to trigger on external Trigger. For the 'master' device select to output Manual trigger. Start both Scopes and press the Manual Trigger on 'master' device.
  9. Hi @S.Kagawa We have not tested the device in such extreme conditions. 'Faraday' shielding of the device should protect it from EMI. Are you using shielded USB cable Could you provide details about the scope input connection? are you using BNC/ 10x scope?
  10. Hi @ibutter Such operation will void the warranty. On the bottom of the board under the USB connector you have access to the USB 5V/GND directly (middle pads) and the VBUS/GND after the filter ferrites (external pads) On the top after the "T" from 'Digilent' logo you can find two caps with the GND/DVCC3V3 and on the board edge the GND/VCC5V0. https://reference.digilentinc.com/reference/instrumentation/analog-discovery-2/reference-manual#power_supplies_and_control
  11. Hi @GeorgeIoak The next software version will have 'record to file' in protocol/i2c
  12. Hi @ibutter Do you need access to the VBUS (USB 5V), VCC5V0 (USB/AUX 5V), DVCC3V3 (digital 3.3V) ? https://reference.digilentinc.com/reference/instrumentation/analog-discovery-2/reference-manual#power_supplies_and_control https://reference.digilentinc.com/analog_discovery_2/refmanual#figure_32
  13. Hi @Sid Price .... fData = 1&(s>>iDio); if(fData) bValue |= 1<<b; // LSB first ...
  14. Hi @FloMai The issue is that the USB packets get lots, the communication gets out of sync. This should also happen with custom application/script, but with this it is possible to reconnect to the device. I will try to add to some retry or reconnect mechanism to the library. With lower communication rate, ~1 per second it was running for me 1-2 days without any issue.
  15. Hi @Sid Price You could try the following custom interpreter. Like ieee802.3 https://en.wikipedia.org/wiki/Manchester_code // Decoder // rgData: input, raw digital sample array // rgValue: output, decoded data array // rgFlag: output, decoded flag array const hzCoding = 100000; const cBits = 11; const iDio = 0; // DIO 0 const fPolarity = 0; const cSamples = rgData.length // number of acquisition samples const cSamplePerBit = hzRate/hzCoding; var pData, fData = 0; // previous and current bit value var cByte = 0; // byte count for(var i = 0; i < cSamples ; i++){ var s = rgData[i]; // current sample if(fPolarity) s = ~s; pData = fData; fData = 1&(s>>iDio); if(pData != 0 && fData == 0){ // falling edge var bValue = 0; for(var b = 0; b < cBits; b++){ var ii = round(i+(0.75+b)*cSamplePerBit); // sample at 3/4 of clock s = rgData[ii]; if(fPolarity) s = ~s; fData = 1&(s>>iDio); bValue <<= 1; // MSbit first if(fData) bValue |= 1; } var iEnd = round(i+(cBits+0.5)*cSamplePerBit); for(; i < iEnd; i++){ rgFlag[i] = cBits; rgValue[i] = bValue; } fData = 0; } } // Value to text // value: value sample // flag: flag sample function Value2Text(flag, value){ switch(flag){ case 0: return "X"; default: return value.toString(2); } } Value2Text(1,1)
  16. Hi @GeorgeIoak You could use the 4th device configuration to have more device buffer. For such, probably timing issues it might be better to use the Logic Analyzer and try to trigger on the issue or on its consequence, like on an odd NAK...
  17. Hi @dos6510 In the WF SDK the CS is controlled by software, so it has a latency of 1-10ms. In the WF app Protocol/I2C/Sensor the instructions in loop are translated to a custom pattern. This constant pattern can be repeated at high rate. This ideal for sensor where the same command is sent out and the received data can be decoded in parallel. See the SDK/samples/py/DigitalOut_CustomBus.py
  18. Hi @Pazzo In case the data processing or saving in your loop function takes too much time it could lead to buffer overflow (samples lost/corrupt). You could try opening the device with 2nd configuration to have more device buffer. # 2nd configuration for Analog Disocovery with 16k analog-in buffer #dwf.FDwfDeviceConfigOpen(c_int(-1), c_int(1), byref(hdwf))
  19. Hi @laurent You should apply the run/repeat settings before starting the output, just like the other options. The run time should be expressed in seconds.
  20. Hi @Pazzo I will try to build it for 64bit arm next week.
  21. Hi @FloMai Sorry for the late reply. It looks like event the RP4 has problems with the AD2. In my earlier tests where it was running for 1-2 days, the communication rate with the device was only about 1/second. Repeating the test with ~100/second rate, I get 0x02/timeout error after about a day with USB 2 and 3 ports, and with USB hub every 6-12 hours.
  22. Hi @jeason15 There is no time-stamp returned by the library. The code you posted performs separate captures of 4k samples. Also notice that you are writing in the file the same sample 4k times... "for v in rgSamples1: f.write(repr(rgSamples1) ... i+=1 In case you want longer continuous capture, at up to ~1MHz, see the record examples.
  23. Hi @Mr.Spriggs I thank you for the feedback. BTW: You could use the combined, 'in one' or colored, options instead the horizontal/vertical tx/rx split views.
  24. Hi @jeason15 See the AnalogIn_Record.py or the other record examples, in WF SDK/ samples/ py
  25. Hi @Mr.Spriggs In the next software version you will have a global option in Protocol tool for data and/or time stamps.