Is there any way to get pyrpl to use the calibration data stored in EEPROM?

[ttuibk]

I used the procedure described here to null out the input offsets:

https://redpitaya.readthedocs.io/en/latest/developerGuide/125-14/fastIO.html#

However in pyrpl (at least in the scope app) the old offsets remain. There did not seem to be any effect. I used pyprl.exe (windows 10 64-bit).

In the Red Pitaya scope / generator app, however, everything was beautiful. The recalibration worked.

[lneuhaus]

At the moment there is no way to retrieve these data from EEPROM. If you have a nice script showing how to read out these values, do not hesitate to post it here and we can think of having a "Impport calibration offsets from EEPROM"-function.

There is some offset calibration method for the lockbox module, but you are specifically asking for scope and function generator, right?

I am rather hesitant to include such an offset compensation per default to pyrpl (unless many people would want this functinality) because

• overly confusing, some modules would have offset compensation and others not
• sometimes a user has to remember that there are offsets in order to do the right thing (e.g. put a high-pass filter or remove analog offsets directly)
• clipping of output waveforms with large amplitudes may occur (fgen cannot deliver 1V amplitude for nonzero offset)
• adding/removing the offsets by yourself is really simple (just evaluate "data+offset" in python), but calibration is really error-prone
• more gui buttons competing for the user's attention
• I have no good data on how stable these offsets really are over time

The main argument to me is that a user has to read too many pages to understand how exactly the calibration is done or can be customized. Let me know if you see a good, intuitive way to guide the user here, and we can discuss implementing it..

[ttuibk]

Ok, thanks. My immediate concern is mainly with the input offset in the lockbox module. One of my input offsets is 18mV, which is about 10% of my Pound-Drever-Hall signal. This is just huge.

What kind of script would you need? Python? Another possiblity would be to just allow the user to type the 10 calibration numbers directly into the *.yml file. This avoids buttons.

But I don't understand in principle why the calibration can't be invisible? A high pass filter just becomes more accurate. Clipping can be prevented the same way that it is now at +-1V. The distinction between 1V and 0.982V seems rather artificial. Isn't it just a tweak in the global coordinate transformation between samples and volts? (Does it work that way? Sorry I have not looked at the code yet. I will do so.) Pyrpl already seems to restrict analog data entry anyway. The numbers in the drop-down menus would just change slightly.

That said, I have no idea how much recoding of the modules this requires. Which modules would not work with offset compensation?

[ecdlguy]

At the moment there is no way to retrieve these data from EEPROM

There's the calib utility

something like

calib -r- v

reads the calibration data from the EEPROM.

cheers, Thorsten

[lneuhaus]

@ecdlguy Thanks for the link, we can definitely have this function available in the API this way! @ttuibk Thanks for insisting, and sorry again for my late answer. Having thought it over, there are a few options: 1) Add offsets to the FPGA code for the two analog inputs and two analog outputs, that are read from the .yml or EEPROM at startup. As far as I know, the official redpitaya code does not use such hard-coded offsets, but only uses them to transform the numbers read and written to and from FPGA to and from the numbers displayed in the GUI. Hardcoding has the advantage that everything is rather clear and confusion does not occur so easily. It has the disadvantage that offsets might also be present in a demodulated IQ signal, for example, and there are not enough FPGA resources to add offsets for all signals (furthermore, IQ offsets will likekly change with the frequency, phase and amplitude settings). 2) Store offsets for each signal in the yml file and leave it to the higher-level code to use them properly. The risk with this option is that it is easy to forget using the offsets and do a mistake. This could be solved by generating a generic class for signals that all higher-level code makes use of, but is still a bit of work. Another risk is that upon changing the .yml file, these offsets will be lost. Again, one could store the offsets on the redpitaya directly (e.g. EEPROM, if there is enough space on EEPROM). Still, this would probably require a calibration module in pyrpl to inspect these offsets. I really do not dislike this option, but it will take time to implement in a proper way. 3) You just use the available offset correction functionality of the lockbox module in the meantime. This should solve your problem, and the more general offset correction will be left for later. The following hints will help you: a) Read the code of the function Signal.get_analog_offset(self, duration=1.0) here:
https://github.com/lneuhaus/pyrpl/blob/0ee0f44e6c2bc930865a92c49e3cb90fd3d96275/pyrpl/software_modules/lockbox/input.py#L76 b) Usage of this function in a python shell:

form pyrpl import Pyrpl
p = Pyrpl("myconfigfilename")
# block the laser beam so that you have the real offset at the input
p.lockbox.inputs.reflection.get_analog_offset(duration=10.0)

For a PDH error signal, you probably want to execute the get_analog_offset function with the laser on but offresonant, since there might be an offset from residual amplitude modulation as well.

The measured offset will be used only within the lockbox module, that is, the scope will continue to display the raw signal. But in principle you are right, the offset determination is a generic issue that is more general than the lockbox module, so it should receive its own "Calibration"-module and be used by all other modules. Just need a bit of patience...