<hartytp>
sb0: fast scope triggered from the reference
<hartytp>
there is a lot of fancy stuff in this PLL and it looks like it doesn't really behave as an int-N PLL when the fractional words are set to 0
<hartytp>
problem is that the documentation isn't really good enough to understand it
<hartytp>
look at that ADI article I posted on GitHub about phase sync
<hartytp>
it has a cryptic comment about how it is important to disable the VCO automatic calibration to achieve deterministic phase. How does that make sense? VCO is inside a feedback loop, so it shouldn't make a difference
<hartytp>
anyway, will poke a bit more on Monday, otherwise it's back to plan (B)
<hartytp>
(oh, and answering your other question, the small phase jumps were usually at power on. But sometimes reprogramming the PLL would cause a phase jump. These were relatively rare events. Not consistent with incorrectly reset integer-N dividers)
hartytp has quit [Ping timeout: 256 seconds]
<rjo>
i can imagine that the feedback paths involving the different vcos/bands are also physically different. i.e. the difference between vco-to-out and vco-to-pfd is not the same accross the vcos/bands.
<bb-m-labs>
I'll give a shout when the build finishes
lkcl has joined #m-labs
<GitHub-m-labs>
[artiq] jordens commented on pull request #1251 4ba4e9c: At this point you probably want to check that the background job has not completed yet. Otherwise you are relying implicitly on some event loop granularity that I can't derive, right? https://github.com/m-labs/artiq/pull/1251#discussion_r249294367
<GitHub-m-labs>
[artiq] klickverbot commented on pull request #1251 4ba4e9c: The background job will never complete unless termination is requested. `scheduler.stop()` should kill the workers, which is what this is testing. https://github.com/m-labs/artiq/pull/1251#discussion_r249294771
<d_n|a>
(The above blame is vacuous; this is the pulse rate test being flaky again.)