I attached an aluminum wire screen to the back of the AOM Amplifier 2U Chassis to (hopefully) prevent RF radiation from going around the lab but allowing for airflow to cool the amplifiers. I needed to cut the chicken wire to allow for the #4-40 screws to go thorugh. I also needed some 0.281" outer diameter washers to hold the chicken wire since the screw head diameter went through the (cut) chicken wire. The wavelength of 200 MHz light is 1.5 m, so this chicken wire should be sufficiently dense to contain most of the RF output. See attached photo.
I've been trying to make the wireless work well with the new subnet. Looks like the only way to do it is to switch the router into access point mode, where it just acts like a switch that included connections over wireless. It forwards the outer network's DHCP and other broadcasts.
The downside of this mode is that it can't use the VPN feature on the router, but we will eventually get that more natively on our network (using CIT credentials) once they set it up.
I tried several things before settling on AP mode. You can attempt to connect the WAN through one of the LAN ports and disable DHCP + NAT, but I never could get it to pass the outer network DHCP, so I gave up. In the process, I accidentally put an access restriction on the user interface and locked myself (or anyone..) out of the machine. Thus I reset it. We lost the existing IP/MAC assignments, but we shouldn't need them anymore on the new network.
The VPN is also down now.
The IPADs on the wireless should see wired Mokus and should see devices from the other lab. You can move the router into B111 if needed, and we should buy more access points.
I cut a corner out of a tile (of unknown material) that goes in the mobile clean room using a bandsaw. This allows the patch panel cables to go from the optics table to the rack. The tile was easy to cut and didn't generate any dust.
I did the same thing to a 2nd tile for a 2nd set of cables. To also allow for the passage of other cables, I made this cut a 2" by 2" square. I placed the tile back to prevent dust from getting into the clean room over the weekend (or longer).
I think they are just acrylic sheets.
The 16 port patch panel has been installed in the rack and on the optics table. We have made 16, 24ft cables to go between these two patch panels. These cables are completed and installed. During testing we found one shorted cable and replaced it while strung up. 3 cables have a small piece of orange tape on them as a warning that the pin that makes the connected may be recessed too far in the cable. All 16 have been tested and are functioning however. Currently they are simply labelled according to numbers on the patch panel. We may update this labeling system. At minimum we will add these numbers to the cabel themselves in case they are unplugged for whatever reason.
Photo dump for the log. I have labelled all cables associated with the first patch panel. I have also cabeled (BNC only) the first filter cavity sled. See here.
Update to cabling for patch panels.
To add support for the lab DNS naming please follow this guide to add the DNS server (192.168.248.15) to your network adapter settings on Windows.
You should then be able to call devices by their set names on the lab network
After doing this I am now able to use the DNS name to call on my scope, ping it, and use within python frameworks
Be sure to stick a label of the assigned host name onto the device (you can also add its IP as well if you want).
This goes for computers, scopes, gpib and network serial converters and so on.
I have unpacked the dewar packages and have placed them in the lab area. The dewar will soon be assembled once the thorlabs cart is approved and purchased.
The components (see sheet) were transferred from Downs to Bridge with Ioana's assistance and are now in the cabinet shown in last 2 images.
All large pieces are accounted for. I will also be procuring a T pipe splitter and release valve from Kurt j Lesker to fit onto the dewar assembly such that we cant pressurize the vessel when outgassing and filling with nitrogen (as per request from Chris James-fermilab)
I machined and cleaned 3 more AOM mounts like in this post. I mounted one and put the others by the SHG sled.
I put the extras in the lista cabinet with the 5 axis stage mounts.
Update to https://mccullerlab.com/logs/lab/index.php?callRep=11746. We have swapped the Endres lab AOM that was on loan to our own. We will return this AOM to them tomorrow. MX-24004 SN1004 is now in use instead. The wiki has been updated accordingly.
I tapped the remaining 36 holes in the 10" CF Flange with a new tap. I raised the tapping depth by 0.0463" in case it was a chip in the bottom of the hole that broke the tap. I then added the groove pattern with the 1/8" end mill. The grooving would have hit the broken tap and possibly damaged the end mill, so I did not groove into it.
I will go to the chemistry machine shop tomorrow to see if I can use their sinker EDM to remove the tap. I will then retap or remake the hole, add the grooving pattern, then clean the two 10" CF Flanges.
I dropped off this part and some drawings at the Caltech CCE Machine Shop. They will remove it with a Plunge EDM. They say the hole will be usable.
I spoke with the shop and the part should be done by tomorrow (11/5) morning.
The CCE shop gave me back the part. The tap has been removed and I don't think I need to rethread the part.
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?
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 borrowed a Gooch & Housego 3080-125 AOM from the Endres Lab. My point of contact is Elie Bataille. It is currently in East Bridge B102.
I have also borrowed an SMB female to SMA and SMA to BNC male
I returned the AOM and cable to Hannah Manetsch.