qtc-umd / dds-sweeper Goto Github PK

It seems like if you tell the AD9959 to sweep from a phase offset of 0 degrees then go up to an offset of 360 degrees, it will just keep sweeping the phase offset, never stopping.

Triggering an up sweep on all 4 channels at once seems to break everything.

I had an issue earlier where the reset pin on the AD9959 was connected to an output pin on the pico which was next to the 4 profile lines, and I think the cross talk was enough to put the reset line high when the profile pins went high. This should no longer be the case since I have moved the reset line, and the issue seems to persist even if I remove the reset line from the pico and tie the reset pin on the AAD9959 directly to ground.

It seems like the frequency changes during a phase sweep -- I have no idea why.

The pico is responding quickly when triggers are sent close to each other. However, when there are more than a few hundred microseconds between triggers, the pico takes much longer to respond to triggers.

For examples, if you sent 3 triggers 5 microseconds apart in single stepping mode, the pico would be fine. However, if you sent the first trigger, waited for 500 microseconds, then sent the next 2 5 microseconds apart, the pico would miss the second one in that burst because it was still responding to the first and had not finished.

For some frequency sweeps, the amplitude changes as the frequency is sweeping.

There is a memory misalignment issue which can cause the DDS to go into an unrecoverable error state. The current iteration of the board does not have any connection between the pico and the AD9959 reset pin that would reset the DDS, so the only way to recover is to power cycle the both the pico and the AD9959.

I did fix this problem by soldering an additional wire onto the boards. The problem is that to actually incorporate this wire as a trace on the breakout board is to switch the two of the GPIO pins the pico is currently using which can be done easily in the firmware.

Basically the problem can be trivially fixed but it would break the two working boards I have. For now these boards are still necessary to keep on testing. When I have a chance I just need to make new boards to replace them so that I can push the change to the repo.

There is a choice to be made in how to best document everything. In the end, all reasonable functionality should be contained within the README (as you are already doing). But I suspect that a more complete spec characterization (ie including figures and tables) might be better served by a separate doc of some type. This is particularly true if we plan to write this up for some journal. We should think about a reasonably easy documenting system (that maps over to latex easily).

Also, I'd like to see a guide for actually setting up the build environment as well. If it's fairly simple, adding to the README is fine.

The communication speed could be increased for large numbers of instructions by allowing binary data to be sent over the serial interface.

The easiest way to implement this would be to send over the actual instruction commands that the pico programs into memory. This would require a substantial duplication of the instruction creation logic into some sort of wrapper for the pico.

Another option would be to define a binary API that the pico interprets and uses its own instruction creation logic. This would make it easier to generate the binary necessary for a sweep. You would just need to be careful about handling the raw binary for floating point numbers.

Some way of programming tables more quickly - with less serial communication

Don't let the user put in known bad inputs.

• frequencies
• times
• find all inputs

As it currently stands, the pico can store about 8000 instructions in sweep mode. If using all 4 channels it would only be 2000 instructions. If the pico is timing itself, it loses 25% of its instruction storage.

If single stepping frequency, phase and amplitude, the max number of instructions would be about 15000.

It could be possible in the future to utilize the flash memory on the pico to store significantly more instructions, but that would add decent amount more complexity.

When sweeping amplitude, downward sweeps will not be longer than the previous upward sweep. For example, if you sweep up from 0% to 50%, then try to sweep down from 100% to 25%, the downward sweep you get will only go from 75% to 25.

This seems to be specific to amplitude sweeps; frequency sweeps do not have the same issue.

There also seems to be a related issue that the downward amplitude sweep is triggering before the profile pin goes low. Not sure if that is a separate issue.

Allow the pico to run a table without any external triggers provided.

Planning on adding additional modes which accept static values for the secondary parameters which are not being swept. This will increase the instruction size, decreasing total number of instructions allowed and the wait times between instructions.

@dihm I seem to recall that the Novatech has some ability to loop back to the beginning of the table when it reaches the end and start again. I am assuming that is a desired functionality for the pico?

Currently, trying to talk to the pico during buffered execution can randomly cause it freeze and eventually crash. I believe this is due to a bug in the most reason version of the pico-sdk.

There is a PR for this issue, but it has not been merged yet.
raspberrypi/pico-sdk#918

The version of the sdk in that PR does seem to make this problem with the sweeper go away.