attila

Thank you so much for your time! This is working great.
 
 

Dear attila,
Thank you for your quick reply.
I could make the wave form by your advice.
Thank you so much.

Thanks @attila for the detailled answer. I will implement it like that!

Thank you @attila for your swift reply. Works perfect. Problem solved!

Hi @bobql
1. The Sensor tab on execution first calls the initialize function, where sensor register, global variables, file initialization... can be performed.
2. Calls the software loop function, without executing it in the device, to build a pattern with the transfers, like for CS, CLK and MOSI.
3. Starts to generate this pattern with hardware timer at the specified rate and iterations, and at the same time it captures the transfers.
4. Decodes the received MISO bits by software call of loop function, without executing it in the device.
5. At the end calls the finish function, where sensor register shutdown and file finalize can be performed.
The software timing of the software function calls in not precise but the pattern generation is, which are basically loop function calls in hardware.
Similar can be done in SDK.
Pattern with digitalout functions, see DigitalOut_SPI.py example, repeat can be set to 'infinite'.
Steps 3-4 can be merged, to receive and decode simultaneously, see DigitalIn_Spi_Spy.py. In Sensors tab these are separate since the sw loop execution takes some time and it would be a bottleneck at high rates.

Hi @AndyMessier
It can generate waveform or pattern from device buffer up to system frequency sample rate or higher, by skipping some, see AnalogOut_Custom.py example
The system frequency, for all instruments can be adjusted with DwfParamFrequency.
In play mode the data is streamed, transferred in chunks from computer, limiting the sample rate to 1-2MHz
The newly added idle hold option keeps the last output value in done state, with finite run time.

Hej @attila Thank you and we will look into them.

Hi @attila,
Thanks for the explanation. I have updated my scripts, where I now set the Logic Analyzer sampling frequency as a multiple of the system frequency (with the maximum being 8x). My capture timing now looks good for system frequencies other than 100MHz.
Thank you

Hi @bobql
You can also use the newly added DwfParamDigitalVoltage with FDwfParamSet or FDwfDeviceParamSet

Thank you for the feedback !
Are you referring to Buffer size of the DUT (device under test) being tested please?
thank you

Hi Attila,
I was hoping not to have to learn how to use the interpreter and develop the code myself for this. . I think it will be a lot of work to do.
Thank you very much for your response.

Thank you, that worked!

Hi @David Aurora
It will be in the next build.

Hi @David Aurora
Corrected in the latest:
 

Damn you're fast! Thanks for that!
Just did a quick test and vertical cursors worked as expected, but for some reason I'm getting strange results on the horizontal (screenshot attached). Any idea what I'm doing wrong here?
As you can see, the Y axis cursors correctly show roughly 30mA with a 10mA delta, but the X axis is showing 809V with a -230V delta when it's actually set to 200V/200V delta.
At first I thought it was to do with the offset, but the Y axis is offset too and works fine. Plus the X axis number doesn't seem to make any sense with regard to the offset anyway (e.g. if I drag it to 500V it displays 458V, if I drag it to 50V it displays 980V, etc). Mouse pointer still displays correct values when I move it around so it seems to only be the cursor function mis-reading. Cursor can't be dragged lower than around 0.4 of a division either, the number keeps climbing if I try but the cursor stops there whereas on the Y axis I can drag all the way up/down the display
This quirk aside though I'm stoked to be able to use cursors in XY now, thanks again

Hi @attila
Thanks for sharing the console window.
I will check from my side and get back to you in another couple of days.
 
 

Hi @KTP
Yes, all functions are thread safe.

Thank yo very much, this is what I was looking for.

Hi @Eugene101
Ideally it should be flat but nothing is perfect. I think such 0.2dB deviation is acceptable, unnoticeable with common usage.
https://www.ni.com/en/shop/electronic-test-instrumentation/oscilloscopes/what-are-oscilloscopes/3-hidden-oscilloscope-specs-that-really-matter.html
 


If you take relative measurement, like it is done by default in Network Analyzer, the different between channels is lower 0.002-0.05dB, see C2 is relative to C1
For more accurate measurement a close compensation can be used, an initial close loop reference curve R1, see M1 is C1 relative to R1 (earlier saved C1 curve)

You are the absolute best! Thanks so much!

Hi @Eugene101
Is the wiring to the two scope channels completely identical and symmetric, splitter in middle and identical cables ?
If you are using probes at 10X you could try adjusting the trimmers.
The device has two trimmers for each channel for positive and negative inputs. These may need a bit of adjustment for high range, above 5Vpk2pk, 500mV/div. The 2nd and 3rd trimmers are for +, and 1st and 4th for - input.
With short BNC cables + T splitter I see ~0.005dB difference at low and ~0.02dB high range between the channel readings. This may also come from the BNC adapter capacitance difference.

Hi @Luke Aldrich
The demo mode is intended to explore the application and device options; triggering, record... are not its strengths. 
The ADP2230, AD3X50 have deep onboard memory so even if the computer is slow on data transfer or storage it should be able to capture up to device buffer size lossless.

Thank you very much!

Thanks for the detailed explanations.
It helped me with getting some better results from my lab equipment.
_______________________________________
Alexandra from portable gas analyzer

That looks like it fixes it, thank you