I have moved the cavity superoptics from B102 to B111B. They are located in the Lista cabinet nearest the optics tabled. See pictures. I have updated the wiki entry https://wiki.mccullerlab.com/bin/edit/DCC/S2400001?t=1729789909 accordingly.
Here is an example of a stabilizing controller we have used to lock the cavity, described in a few ways.
In the Moku UI it is described as:
Fast controller: PI controller: proportional gain +0.0 dB, integrator crossover 1.2 kHz, integrator saturation +43 dB, invert on
As a continous time transfer function, described in zpk (zeros, poles, gain) form, this is
z = [-1200*2*pi]
p = [-8.495*2*pi]
k = 1.0
Attached is a plot of the transfer function.
What is the sampling frequency?
Moku is a bit secretive about the details of their digital filter implementation. The PID controllers in the Moku are designed in continuous time but must be implemented in discrete time. At an in-person meeting I asked a Moku technical rep. this question: How do you digitally implement the PID controllers on the Moku? And the Moku technical rep. refused to answer, citing the need to protect industry secrets. We can make some educated guesses using the specs.
• Integrator crossover frequency: 3.125 Hz to 312.5 kHz
• Differentiator crossover frequency: 31.25 Hz to 31.25 MHz
The DAC sample rate is 1.25 GSa/s at the output of the Moku, but as far as I understand this can be decoupled from the clock rate of the digital filter by using downsampling or interpolation.
Moku does give more information about their "Digital Filter Box" which is a more general IIR filter compared to the specific PID controller. Their IIR filters have a sample rate of 39.063 MHz and they use "48-bit fixed-point numbers, with 45 fractional bits." Attached is a screenshot from the user interface that explains a bit about their IIR filters.
First, I connected to the Red Pitaya over local network by
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?
I have re-attached all the fibers that were detached ahead of the move from B102 to B111. The last fiber management system was a mess so I have spent special care to make it much nicer this time around. I've fed all of the 775 and 1550 fibers that were in use (as well as the fourth AOM path in preperation for it being used) through a 1 inch flexible metal tube and fixed this tube to the table. I think it turned out quite well. Pictures attached.
Nice job. It looks like flexible metal conduit like this: https://www.lowes.com/pd/Common-1-in-Actual-1-in-Metal-Flex-50-ft-Conduit/50412994
Protecting fibers from the sharp ends is good -- do I see duct tape? Probably good enough. I think there might be plastic connectors that do a similar thing: https://www.lowes.com/pd/1-in-Screw-in-Connector-Flexible-Metal-Conduit-Compatible-Conduit-Fitting/999921004
While CNC machining a 1/4-20 breadboard pattern into a 2nd 10" CF flange, the tap broke going into the first hole in the middle of the part. It did two "peck taps" into this hole and then broke while tapping near the bottom of it, I think on the way down. I am not sure why it broke; maybe Paul Stovall (the head of the MCE shop) will know when he is in tomorrow.
There are a few paths forward: scrap the part or tap the rest of the holes. The best case senario is that we can remove the tap and fix the hole. If the hole isn't salvagable, I can drill it out and tap it with something like a 5/16-18 or 5/16-24 hole. We could also proceed with one hole that is useless.
Another life achievement unlocked! Welcome to the world of machining SS. I hope your expert machinists will help with one of these solutions, or one of their own tricks. https://www.practicalmachinist.com/6-effective-ways-to-remove-broken-taps/
If this will be in vacuum, it is not a good idea to leave it. If it is in air, perhaps grinding it down to below the surface level is sufficient.
There is a link to the instructions to sync the next cloud to ios or mac:
https://docs.nextcloud.com/server/19/user_manual/pim/index.html
The nextcloud is currently down so I cant test it to verify. I will add comments when it is back up
You will need to add a username and password that is generated on the nextcloud account screen.
go to nxc.mccullerlab.com/settings/user/security and add a password under the heading "Devices & sessions"
This is the password and username that you will use to add the calender to your mobile device.
I cleaned a clamp and clamped the seeder and amplifier sled to the shelf. This should prevent it from moving.
I ran the attached CNC code on the Haas VF-2 to add 37 tapped 1/4-20 holes with 1" spacing (a breadboard hole pattern) to a 10" CF Flange. I added a 0.0156" deep groove for venting so that we can cover a hole and not have a virtual leak.
The "pipeline" was to design the part in SolidWorks (CAD), give some CAM commands (tell it what holes to drill, how deep, etc), then "post" the G Code. I then copy the G Code into .txt file adn import it into the python script. This python script adds a custom cycle call (M97) to remove chips and allow me to visually confirm this. I then copy the code's output into a new .nc file. I then add the custom cycles at the bottom of the code. I can then read this G Code in the Haas.
I attached the flange the same as this post. Because the part and tool are flooded with coolant, the masking tape didn't do a great job at holding the flange to the knife edge and some chips got under the copper gasket. Luckily, these chips did not scratch the knife edge. I think the flange helped.
I used the 4 following tools: this #4 Cobalt Steel drill bit with a TiN coating, a 3/8" diameter 90° chamfer tool, this 1/4-20 steel bottom tap with 3 flutes and a black oxide coating, and a 1/8" diameter carbide end mill with 4 flutes and a TiAlN coating.
The tools did not appear to be too worn out after this cycle. There is a bit of wear on the tap and end mill, possibly due to earlier use.
After machining, I carefully removed the chips and used a stone and WD 40 to remove burrs from end mill.
I am going to machine another flange tomorrow and clean these Friday so that they can be baked out over the weekend.
This should probably be in the "Vacuum Systems" section not "GQuEST General"
This should probably be in the "Vacuum Systems" section not "GQuEST General"
The parameters in this post are mostly good, but the #4 carbide drill bit chipped after seemingly everything was done right. I could increase the spindle speed or decrease the plunge feed rate by ~10% each, but I have gotten frustrated trying to get the parameters for this drill bit dialed in. The issue is a combination of carbide's sensitivity to parameters, the four facet (narrower spiral) point, or the 118° point angle.
Instead, I used this #4 Cobalt Steel drill bit with a TiN coating to make 4 test holes. This drill bit has a split point and 135° point angle to hopefully prevent chipping of the bit. I used a spindle speed of 506 rpm and a feed rate of 1.68 in/min, what FSWizard recommended.
Separately to figuring out these parameters, I also wrote some Python code to edit my G-Code so that the spindle reverses to clear chips, stops coolant and dwells above the part so that I can visually make sure the chips are gone, and then resumes the cutting cycle. This works very well.
Tomorrow, I will finally machine the 10" flange.
In the post after I've made the flange, I will post the CAD, CAM, G-Code, and python script.
I've transfered most of the contents of the B102 cabinet to the Lista cabinet in B111B and done some semblance of reorganization. See attached photo.
I have added "Escort Required" signs to the doors of B110, B102, and B111. Hopefully this will prevent unknown lab access a problem that we have been dealing with. I have attached the signs so they can be edited
I have placed the new computer on one of the tables on the east wall of B111B. I cloned the disk of the NUC in B102 onto an external hard drive using clonezilla, but was unable to copy this onto the new machine becasue the NUC drive is 1TB and the new machine's drive is 500GB. A clone may still be possible using a partition strategy, but I also expect that Lee's plan to use virtual machines will make this a moot point. As of now the new machine is running windows and I have installed no additional software.
Would it be possible to start work on the disconected ssh idea. We should get a rack mounted computer to have all of the small Nuc's tunnel into. Do we have that already?
I've equiped Sander with a Red Pitaya to take back to California; it contains a working biquad filter bank running at 16 bits and 125MHz, using Direct Form 1 with the Scattered Look-Ahead technique. I'll continue to tease performance out of the other implementations, specifically DF2T and BQF for higher bit counts, and I'll provide firmware updates when possible. Hopefully the current version will at least allow you to get some latency baselines. The board runs Pynq so installing the newer versions should be a breeze.
The Red Pitaya is set to use a single channel, and you can program via Pynq how many filters in series you would like to put in the signal path, up to 6. Each one can be programmed independently, so in this way you can run an arbitrary filter designed with SOS stages. Do keep in mind the current limitation of 16 bits, however. Also, I didn't include a gain stage so this is probably an obvious addition to the next version.
I've set up a Github organization with all of my work on this thus far. It's set to private so if anyone wants to take a look please comment your emails in the comments. Chris told me there was a Gitlab instance so maybe I can migrate this there eventually.
I am definitely interested in checking out your repos, jeffwack111@gmail.com
Link is possibly broken or I don't have access.
Hi Ian, just sent you an invite to macmillan@caltech.edu
