About Input port and data collection

[Lex]

Hello All,
We are currently building an experiments about lock-in amplifiers with Moku:Go and have following problems when use the device.

1. The value of input signal (show with the figure 1)
   
   

A calibrated R&S RF signal source is used to produce a CW signal with 1 MHz and a series amplitude from 0.06 V to 0.4 V.
Input these signals into the input port 1 of Moku:Go box.
Then we use the desktop app of Moku, run the Lock-in amplifier function, set the “A” probe on the “In 1” point.
Switch on the RF signal source out, the waveform and the amplitude could be observed.
The values displayed on two devices have a quite large difference, show as follow:

Signal Source Value (V):       0.06  0.07  0.08  0.09  0.10  0.20  0.30  0.40
Moku device app value (V):     0.17  0.20  0.23  0.26  0.29  0.67  1.01  1.34
Ratio (Moku / Signal):         2.83  2.86  2.88  2.89  2.90  3.35  3.36  3.35

The change of the difference is not linear either.
Thus we guess if there is an amplifier at the input of Moku device?
How could we fix this difference?

2. The noise at input port (show with the figure 2)
   
   

Continue with the above setting, when the RF signal source output are switched off,
there is still a 2.44 mV exist at “In 1”.
We’re not sure if this is normal?
Is there any way to reduce this value?

3. Self defined data acquisition

We also use Python to read the data from Moku device and we notice there is a similar topic:

Oscilloscope: number of points + averaging in API

Hi, I have two suggestions/questions regarding the Oscilloscope instrument and the (Python) API: The Oscilloscope instrument has a nice averaging function in the desktop / iPad app which we like to use through the API as well. Currently, we can mimic the behavior by requesting the same (triggered) waveform for the amount of averages we want over and over with osc.get_data(), but this means that we communicate a lot with the device and hence our readout time is much larger compared to the cas…

We need API that the frame length could be self defined (2^n or arbitrary number).
It mentioned that related features are under development and testing.
What is the situation now and any progress?

Thank you for your attention and looking forward to your replies.

[nadia]

1. I assume the signal generator is calibrated for 50Ohm impedance, I wanted to confirm a few things:
   Is the Moku:Go terminated at 50Ohms to match? This will require a T-piece and terminator as the Moku:Go does not support 50Ohm impedance at the ADCs.
   Does the level displayed on the signal generator in figure 1 correspond to RMS, Vpp or amplitude?
   Would you be able to check the signal through an Oscilloscope, change the coupling to DC and decrease the frequency to see how that impacts the signal you see?

2. The Moku:Go has 12-bit ADCs set at 10Vpp range, when at a smaller timebase the sample rate is 125MSa/s and will have a 2.4mV quantization step size. There is a way to reduce this; if you set the acquisition mode to Precision and increase the timebase, i.e. above 100us, the sample rate will decrease allowing for averaging and dropping the noise floor. See Bit Growth via Oversampling - Liquid Instruments for more information on this topic.

3. User defined frame length is now available through the API! The convention is:
   i.set_timebase(t1, t2, frame_length=2**n)
   Where the frame length can be powers of 2 between 128 and 16384 (2^7 - 2^14) for Moku:Go. This will be added to the API reference documentation soon.