AD9959 DDS Sweeper #126
AD9959 DDS Sweeper #126
Conversation
… for user to specify mode. Currently defaults to single steps
|
A result from testing in the lab: we should either remove timing mode or implement it fully. At the moment, the labscript device just sends an instruction table without timings (regardless of whether timing mode is 1 or 0), which fails. I think I am leaning towards removing it, but I could go either way. On a related note, we should check that the number of bytes we want to send matches the bytes the Pico is ready for. |
…n binary mode. At the moment, if it fails it will simply send all zeros and throw an error. I think this is the best option, as it prevents the device from getting locked up waiting for bytes (if we restart the blacs tab).
|
I added the "ready for ... bytes" check and an option to use an external reference clock for the labscript device. These should be tested before merging. |
|
Talked a tad with David and we settled on not supporting internal timing at all since the prawnblaster clockline is much better for less work. I'll remove those and try to add any remaining docs |
There was a problem hiding this comment.
Mostly minor tweaks, with two more significant things
- I am now noticing that we basically have a firmware limitation that there must be at least one dynamic output to use this device. I get why and it isn't totally unreasonable, I do think it could be worth allowing for all the outputs to be StaticDDS.
- The BLACS worker transition functions feel a bit rough. They don't quite respect the conventional boundaries (which are admittedly poorly documented) and I think
transition_to_bufferedhas a number of edge case issues that need to be tested and fixed. I would appreciate testing confirmation that everything works as expected if you do the following things:
- Program no outputs
- Only use StaticDDS
- Only Use DDS
- That the BLACS tab updates to the final values of all outputs correctly
- That aborts leave the device in a functional state
…l need to implement PrawnDO style smart cache and graceful aborts
|
I found a rather insidious bug: if two instructions are spaced by less than the reprogramming time (10us for 4 channels), the trigger for the second instruction arrives before the DDS Sweeper has finished reprogramming the AD9959. I think the result of this is a partial update of the AD9959 parameters. For an example of this, we were trying to use the DDS Sweeper to pulse on an AOM for 4us, 8us, and 12us. In the first two cases, the second instruction doesn't run, and the AOM never turns off. |
|
I've added some comments to comments (mostly for me) to make sure everything in the review got addressed. Carter and I met and talked about filling out some more docs but otherwise I think we should be looking good. |
|
|
…enforce it. This will allow the maximum clock rate to be determined.
This handles the case where static and dynamic channels are mixed a bit better.
|
Mostly working so far, but I did manage to get it to crash while running an unusual sequence earlier today. I want to investigate that a bit further. It seems to have mostly affected one on a remote BLACS, so it might have been a network issue. |
I was unable to recreate the issue, so it may have been an issue with our lab's network. I am satisfied. |
No description provided.