DAC calibration

[rodolfocarobene]

This PR adds a notebook (in rst format) that explain how to calibrate DACs in order to get a function that converts a frequency/amplitude/reconstuction-waveform to dBm (@marcogobbo).

I would like to add sooner or later also a notebook with the corresponding ADC calibration, but let's start from here.

Is there a better way of uploading a jupyter notebook, @alecandido? Maybe having this rst is worse than the notebook itself, but I was not sure what the best option was.

Checklist before merge:

• [ ] Reviewers confirm new code works as expected.
• [ ] Tests are passing.
• [ ] Documentation is updated.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.96%. Comparing base (ae46092) to head (8b931cf).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #123 +/- ## ======================================= Coverage 93.96% 93.96% ======================================= Files 12 12 Lines 729 729 ======================================= Hits 685 685 Misses 44 44 ``` | [Flag](https://app.codecov.io/gh/qiboteam/qibosoq/pull/123/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=qiboteam) | Coverage Δ | | |---|---|---| | [unittests](https://app.codecov.io/gh/qiboteam/qibosoq/pull/123/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=qiboteam) | `93.96% <ø> (ø)` | | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=qiboteam#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[alecandido]

Is there a better way of uploading a jupyter notebook, @alecandido? Maybe having this rst is worse than the notebook itself, but I was not sure what the best option was.

The rst is not a bad idea, since we're rendering it as docs, and all our Sphinx is made of rst. So, it's one of the best solutions for this

However, the idea is that you should always commit the source of your code, in such a way that you can still modify in the original way (even if it's a different person on a different machine, cloning from scratch). But if you can convert it back to the original notebook (from files in here), that's also fine. Otherwise, you should commit the notebook as well (and consider generating the rst in Sphinx, with your own script, hooked into conf.py, or a suitable Sphinx extension, like nbsphinx).

In general, notebooks are great, but what's the best way to include them is still something that I have to work out. And there could be multiple best solutions, according to the situation. nbconvert (shipped by default with Jupyter) already provide a variety of formats, and there is also Jupytext. I encourage you to pick the option that requires the least effort for you, and for someone else that might want to edit the notebook in the future. (the other relevant bit are diffs, that are uselessly complex with notebooks - but at least GitHub, not Git, is becoming smarter and smarter on that side)

[alecandido]

Ok, scrape the rant above: in this case is not going to be included in the docs, so the plain notebook could be the solution.

Otherwise, you could try Jupytext with Python. But notebooks have the advantage of being rendered by GitHub, and more familiar to people to edit. I'd go for that (to keep it simple).

[rodolfocarobene]

Makes sense to just use jupyters. At least for "examples" of this sort

[alecandido]

Unfortunately, GitHub gives nice rendering even for Notebooks diffs, but I can not comment on the lines. So all the review comments will be just on the file.