We have two EVAL-ADH4702-1CPZ evaluation boards which are nominally configured as 21V/V gain noninverting amplifiers.
First I provided power with a Newport +-15V supply, connecting +, -, and GND on the power supply to VCC, VEE, and GND respectively, on the eval board.
This resulted in a gain of 12.3dB up to about 100kHz
Next, I used the on board power supply by connecting the DC jack to the +15V and GND of the power supply. I then connected the power supply half of the eval board to the opamp circuit by jumping VCC_TRANSFORMER
to VCC, VEE_ TRANSFORMER to VEE, and GND_TRANSFORMER to AGND, as described in the manual of the eval board in the section "Initial Power-Up." These jumper wires are white, turquiose, and yellow.
I performed a transfer function and a pulse delay measurement.
Both of these opamp eval boards have been outfitted with pin jumpers. They are being stored in the EE lab in the tall white cabinet on the west wall to the left of the drill press.
I made some laser safety signs for the doors into B111A and B111B that have the power and required OD at different wavelengths. We still need to mount the metal laser safety signs, especially because the signs that light up are not particularly visible.
[JC, Daniel]
JC bought some first aid kits from amazon and I (temporarily?) placed them in the following locations:
B106 in the back
B110 by the fume hood on a shelf
B111A in the middle
B111B left of the shelves by the main entryway
B111D in the middle by the main entryway
B102 by the entryway
I cleaned the inside and outside of the plexiglass around the laser tables in B111A. It was still a little dirty, but it seems much cleaner than before.
[Jeff, Daniel]
We moved 12 cubbies from B102 to the B111 entryway to hold our clean and dirty shoes. I cleaned the inside of the cubbies with iso and water. I wasn't able to find a label maker, but 6 of the top cubbies should be for clean shoes and 6 of the bottom cubbies should be for dirty shoes.
With cubbies by the entryway, we won't get B111 dirty with shoes we're about to take off.
[Ian, Torrey, Jeff, Daniel]
Since we are limited by the 1 meter length of the fiber coming out of the amplifier, we decided to move the Laser and amplifier below the table from its current position on the shelves above the optical table. The thought is that that space will be very valuable and since we don't plan on touching the laser much we would rather put it under the table. Jeff found a rack that will fit under the table and we plan to put it under the South side of the table. This will give enough room to let the short fiber get to the top of the table. The amplifier will be mounted on the top of the short rack and the seed laser and polarizing paddles will be below it on a ThorLabs rack mount bread board. Daniel is mocking up how all the components will fit into the box.
We also want to mock up a way to protect the fiber coming out of the amplifier. I want to put a plate in front of the rack mountable amplifier that attaches to the rack. This full face plate will protect any of the cables from getting kicked.
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 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"