Repository navigation
docs: add frequency-matching back to the tProc v2 tutorials, delete junk tutorials - #434
Merged
Merged
Conversation
…dd_pulse) The tProc v2 tutorials passed gen_ch to add_readoutconfig/declare_readout but no ro_ch to add_pulse. The pulse was then rounded only to the generator's frequency step and the readout to the coarser common step, so the two differed by a few Hz (9.2 Hz at 100 MHz on the RFSoC4x2). The measured I/Q phase slid over time and came out at a different angle on every run; a user hit this with tutorial 01 on a ZCU216. - add ro_ch to the 46 add_pulse calls whose readout uses the same frequency (off-resonant tones in tutorial 12 and muxed pulses in tutorial 07 are left as they are; the mux case already matches in declare_gen) - tutorial 01: explain ro_ch/gen_ch and link the frequency-matching topic - topics/freq_matching: add the AveragerProgramV2 recipe and the symptom of matching only one side Checked on the RFSoC4x2: matched, the phase repeats over 6 runs within 0.3 deg; unmatched, it spreads over 210 deg.
The cell printed inspect.getsource(prog_fast.add_readoutconfig) before the cell that defines prog_fast, so it raises NameError when the notebook is run top to bottom. The published output (a dump of add_readoutconfig's source) came from running it out of order.
fs_mr was never defined in the notebook (it came from kernel state), so the FFT cell raised NameError when run top to bottom. It is now the readout's full sample rate, the same one get_time_axis_mr() uses. The published output had used 307.2 MHz (the decimated rate), so its frequency axis and alias estimates were off by 8x on the ZCU216.
- 00: 'import qick' for qick.get_version(); 'from qick import *' does not bind the package name - 11: drop a leftover debugging cell that printed iq_avg, time_axis, reps_per_round, ... before the cell that defines them A pyflakes pass over every tutorial, code cells in order, finds no other name used before it is defined.
Outputs regenerated on a ZCU216 with the public 2025-08-10 standard tProc v2 firmware (r26), with the frequency matching and cleanup fixes in place and every notebook run top to bottom. Tutorial 08's MR spectrum now uses the real sample rate: the ~1 GHz tone shows at -999 MHz (the old output folded it to -125 MHz with the decimated rate). Not re-run: - 07: its channel map (mux8, readout_v3, PFB and readout_v2 on fixed channels) is the 2024 demo firmware's, not the standard one - 10, 13, 14, 15: they need multi-board, custom-firmware or QICK box setups
Contributor
|
Removed the following new tutorial notebooks:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the frequency-matching bug in the tProc v2 tutorials that a user hit with tutorial 01 on a ZCU216: the I/Q phase of the same pulse came out at a different angle on every run. Also removes leftover debugging cells and undefined variables, so every notebook runs top to bottom, and regenerates the outputs on hardware.
Frequency matching (the bug)
The tutorials passed
gen_chtoadd_readoutconfig()/declare_readout()but noro_chtoadd_pulse(). The pulse frequency was then rounded to the generator's own step, and the readout's to the coarser common step, so the two differed by a few Hz. On an RFSoC4x2 at 100 MHz that is -9.2 Hz (generator step 2.3 Hz, common step 20.6 Hz), so the demodulated phase turns once every ~0.1 s.ro_chadded to the 46add_pulse()calls whose readout uses the same frequency. Two kinds of pulse are left as they are:declare_gen(ro_ch=...).ro_ch/gen_chand links the frequency-matching topic.topics/freq_matching.rstgains an AveragerProgramV2 section, with the symptom of matching only one side.Measured on an RFSoC4x2 loopback, same program over 6 separate runs:
Notebooks that did not run top to bottom
inspect.getsource(prog_fast.add_readoutconfig)beforeprog_fastis defined. Its published output came from running it out of order.fs_mr. It is now the readout's full sample rate, the same oneget_time_axis_mr()uses. The published output had used the decimated rate, so its frequency axis was 8x off on the ZCU216.import qickforqick.get_version().A pyflakes pass over every tutorial, code cells in order, finds no other name used before it is defined.
Regenerated outputs
00-06, 08, 09, 11 and 12 were re-run top to bottom on a ZCU216 with the 2025-08-10 standard tProc v2 firmware (r26), library 0.2.381.
Not re-run: