tknopp / RedPitayaDAQServer

Advanced DAQ Tools for the RedPitaya (STEMlab 125-14)
https://tknopp.github.io/RedPitayaDAQServer/dev/
Other
34 stars 9 forks source link

Add EEPROM access and calibration #32

Closed jonschumacher closed 2 years ago

jonschumacher commented 3 years ago

Closes #10.

I added access to the EEPROM and would like to also add a small GUI for calibrating the ADCs and DACs. Which framework did you use for the GUI or do you already have something like that?

nHackel commented 2 years ago

Since the Julia functions just want some kind of String as an input, I think it would be helpful if we replicate the C Struct for the Julia side too.

We could then add a function that fills this struct completely, but we can also extend the Julia function. It could either check itself if a given field name would fit or catch the error case if the server rejects the fieldname. In either case the exception could reference the field names of the eeprom struct with fieldnames(...) and a client would have a more meaningful exception message.

For convenience another eeprom function could work directly on Symbols and internally just convert them to string and call the existing function.

Additionally if the struct ever changes on the server side then this could be "documented" directly in the code by adapting the client side struct.

tknopp commented 2 years ago

The struct contains quite some parameters that are not really valid / used in our image. We just need to store the scaling and offset values for the two different modes and for the two channels. We certainly could use a struct for that but maybe the struct should contain "user friendly" values i.e. those that are already in floating point and not in integer.

The easiest thing is to have a new SCPI command that request the values and then the read function on the client side can call these (or store them in the RedPitaya struct at initialization).

It would be great if we move the actual calibration to a future pull request. Right now we just should initialize the scaling parameters with rough values.

jonschumacher commented 2 years ago

I would tend to not replicate state in two places. Retrieving the data requires only four calls to the SCPI interface which is cheap in bandwidth compared to the actual reading of data. I would also keep the checking of the given strings within the server in order to not duplicate things. A convenience function returning a struct encapsulating the necessary calibration data might make sense on the Julia side.