First, I connected to the Red Pitaya over local network by
- Connecting the Red Pitaya (RP) via ethernet to the network (pLANk in b102). A usb connection via the COM port was not necessary.
- finding the IP address on the board using "ip neigh" in terminal and matching the MAC address printed on the RP's ethernet port
- navigating to the IP address using a browser
- enter the password 'xilinx'
Next, I navigated to the notebook labelled "RunMe.ipynb" in the folder "Biquad SLA."
Overall, it's great! Worked first try.
The filters behave quite poorly when trying to put features at frequencies below 1MHz or so, as can be seen by the attempt to make a bandpass filter centered at 150kHz. This is perhaps no surprise given the sample rate of 125MHz and 16bit arithmetic.
I also measured the delay using an oscilloscope pulse as is described here, giving a result of 1.3 microseconds.
Thinking about incorporating this into the experiment makes me wonder: how can we pass new filter coefficients and open or close the loops without being in the Jupyter notebook? For example, could I send command strings to the IP address of the board?
Great news! Now we can work on the details.
Indeed, making the filters work a "extreme" critical frequencies is precisely the challenge. I have been studying various implementations of difference equations in Python, using a fixed-point package, where you can change the number of bits in the integer and the fractional parts of each register. I alway assume 16 bit integer intput and output, but that can also vary. When you push to have, for example, a low-pass filter with f_critical/f_sampling < 1e-3 or 1e-4 you need more bits for it to work. So, this is why we are asking what are realistis goals for actual control loops we need.
So far, that transformed direct form II works well, but has extra noise a low frequencies. The idea is that the LIGO version fixes this and that is what I'm testing now. I you want to get more involved in this characterization (HINT HINT!) let me know and I'll get you access to the examples and demose I'm using for this.
Of course, 100 bits works better than 16, but Javier also needs to determine what we can actually implement, so we need to make a trade-off. There is also a trade-off of the amount of resources one implementation of a filter uses, compared to how many cascading filters and independent channels, and sampling rates we need.
Great news that the delays with the RP are low; the implementation on the custom hardware we are designing will be better, but we can use the RedPitaya to understand the algorithms.
REMOTE CONTROL WITHOUT JUPYTER
The notebooks are a convenient way to show how to use the firmware and do unit tests, but to integrate into an operation system you want more direct control.
In the QICK project we use this package: https://pyro4.readthedocs.io/en/stable/intro.html
This allows you to instantiate python object on a control computer (not the ps of the pynq board) and use them the same way. So you can set filter parameters and all other APIs exposed by the objects. For the custom board, there will be APIs to do similar things.
In regards to control of the boards from a separate computer, I have worked a bit on using Pyro to control the Moku and found it works well, so I am glad to hear that is the kind of interface we can create for our custom boards.
I'd be happy to look into the numerical experiments you've run for filter precision questions, do you have them hosted on a git repo you can share?