One of the slower parts of collecting data is waiting for the pump laser to reach the desired detuning. I think that my current method could be improved significantly. Previously I was scared to make too big a jump of detuning in one shot, but I'm now convinced it's time to try.

Pasted below are two examples of the laser going from one detuning to another. The task is to find out the ratio of voltage shift to detuning shift, and add that factor into pumpLaserControl.c program. Then when the laser changes voltage to get to a given detuning, it will be calculating the needed change in voltage based on this ratio.

Again, @nstamos20, I think this is a fairly straightforward change that you can implement to help yourself get familiar with the code.

PuL @ d=1.41-> d=12.00Increasing detuning
The piezo is currently at 1.5 GHz
The piezo is currently at 39.8V, increasing to 41.8V
.Increasing detuning
The piezo is currently at 2.3 GHz
The piezo is currently at 41.8V, increasing to 43.8V
.Increasing detuning
The piezo is currently at 3.1 GHz
The piezo is currently at 43.8V, increasing to 45.8V
.Increasing detuning
The piezo is currently at 4.0 GHz
The piezo is currently at 45.8V, increasing to 47.8V
.Increasing detuning
The piezo is currently at 4.9 GHz
The piezo is currently at 47.8V, increasing to 49.8V
.Increasing detuning
The piezo is currently at 5.8 GHz
The piezo is currently at 49.8V, increasing to 51.8V
.Increasing detuning
The piezo is currently at 6.8 GHz
The piezo is currently at 51.8V, increasing to 53.8V
.Increasing detuning
The piezo is currently at 7.7 GHz
The piezo is currently at 53.8V, increasing to 55.8V
.Increasing detuning
The piezo is currently at 8.7 GHz
The piezo is currently at 55.8V, increasing to 57.8V
.Increasing detuning
The piezo is currently at 9.6 GHz
The piezo is currently at 57.8V, increasing to 59.8V
.Increasing detuning
The piezo is currently at 10.6 GHz
The piezo is currently at 59.8V, increasing to 61.8V
.Increasing detuning
The piezo is currently at 11.6 GHz
The piezo is currently at 61.8V, increasing to 62.0V
.Increasing detuning
The piezo is currently at 11.8 GHz
The piezo is currently at 62.0V, increasing to 62.2V
.Increasing detuning
The piezo is currently at 11.9 GHz
The piezo is currently at 62.2V, increasing to 62.3V
.Increasing detuning
The piezo is currently at 11.9 GHz
The piezo is currently at 62.3V, increasing to 62.4V
.The laser is correctly tuned at 62.4000023.1V

PuL @ d=12.04-> d=1.50Decreasing detuning
The frequency is currently at 12.0 GHz
The piezo is currently at 62.4V, reducing to 60.4V
.Decreasing detuning
The frequency is currently at 11.3 GHz
The piezo is currently at 60.4V, reducing to 58.4V
.Decreasing detuning
The frequency is currently at 10.4 GHz
The piezo is currently at 58.4V, reducing to 56.4V
.Decreasing detuning
The frequency is currently at 9.6 GHz
The piezo is currently at 56.4V, reducing to 54.4V
.Decreasing detuning
The frequency is currently at 8.7 GHz
The piezo is currently at 54.4V, reducing to 52.4V
.Decreasing detuning
The frequency is currently at 7.7 GHz
The piezo is currently at 52.4V, reducing to 50.4V
.Decreasing detuning
The frequency is currently at 6.8 GHz
The piezo is currently at 50.4V, reducing to 48.4V
.Decreasing detuning
The frequency is currently at 5.8 GHz
The piezo is currently at 48.4V, reducing to 46.4V
.Decreasing detuning
The frequency is currently at 4.9 GHz
The piezo is currently at 46.4V, reducing to 44.4V
.Decreasing detuning
The frequency is currently at 3.9 GHz
The piezo is currently at 44.4V, reducing to 42.4V
.Decreasing detuning
The frequency is currently at 2.9 GHz
The piezo is currently at 42.4V, reducing to 40.4V
.Decreasing detuning
The frequency is currently at 1.9 GHz
The piezo is currently at 40.4V, reducing to 40.2V
.Decreasing detuning
The frequency is currently at 1.8 GHz
The piezo is currently at 40.2V, reducing to 39.1V
.Increasing detuning
The frequency is currently at 1.3 GHz
The piezo is currently at 39.1V, increasing to 39.3V
.Increasing detuning
The frequency is currently at 1.3 GHz
The piezo is currently at 39.3V, increasing to 39.5V
.Increasing detuning
The frequency is currently at 1.4 GHz
The piezo is currently at 39.5V, increasing to 39.6V
.Increasing detuning
The frequency is currently at 1.4 GHz
The piezo is currently at 39.6V, increasing to 39.7V
.The laser is correctly tuned at 39.7000013.1V

During the course of normal operation, I found the polarimeter motor began to seize, manifesting as a "clicking" of the stepper motor as I'm collecting data.

I tracked the issue down to the interface between the delrin hub and the aluminum rod that passes through it. The rubbing of these two surfaces created a fine powder/residue which greatly increased friction between the two objects. So much so that rotating the rod wasn't possible.

I disassembled the polarimeter, cleaned and sanded the rod, then wiped with methanol. This seemed to help initially, but I'm not sure how long-term of a solution this will be, since it seems as though the rod is already getting a bit stickier.

Here I will copy and paste my email exchange with Ken where I describe the issue. We also had a conversation in the Zoom chat, which I forgot to save. I'll post my text as normal text, and put his replies in quote blocks.

Occasionally, it would happen that the Pi would receive an unexpected number of bytes in the past, so I wrote code to just have it retry 5 times if it failed for any reason. It would only fail once in a while and didn't really disrupt data collection. Now it will repeatedly fail, sometimes 10 times in a row.

I tried increasing the delay time before it retries. I have it at 900 ms and it still will fail multiple times in a row.

I unplugged the GPIB bridges, the RS485 Bridge and the Ammeters and turned them back on and the problem is still there.

At this point, it's rare that it will go through a set of 200 measurements without failing out at least a few times.

I just had it get through a set of 200 measurements without any 3417 errors, so like I said it's intermittent.

Here's an example of a particularly bad set.

karl

164 -4.20240e-12 | +1.20000e-12 | +3.86800e-09 | +0.00000e+00
164 -4.22540e-12 | +1.40000e-12 | +3.87100e-09 | +0.00000e+00
164 -4.22480e-12 | +1.10000e-12 | +3.86800e-09 | +0.00000e+00
164 -4.22150e-12 | +1.00000e-12 | +3.86800e-09 | +0.00000e+00
164 -4.21420e-12 | +1.20000e-12 | +3.87100e-09 | +0.00000e+00
164 -4.18490e-12 | +1.30000e-12 | +3.87900e-09 | +0.00000e+00
164 -4.18300e-12 | +1.00000e-12 | +3.87600e-09 | +0.00000e+00
164 -4.15260e-12 | +1.20000e-12 | +3.87000e-09 | +0.00000e+00
164 -4.13050e-12 | +1.20000e-12 | +3.87000e-09 | +0.00000e+00
72 -4.15400e-12 | +1.20000e-12 | +3.85200e-09 | +0.00000e+00
72 -4.15990e-12 | +1.20000e-12 | +3.85000e-09 | +0.00000e+00
listenGPIBData process returned an unexpected number of bytes
30 2e 30 30 31 30 45 2d 39 0d 0a 4a c4
0.0010E-9
J▒11
U

ListenGPIBBridge process returned error code 3417
0c 99 19 33 66 cc cc d1 cb ce c3 85 4b 15
listenGPIBData process returned an unexpected number of bytes
30 2e 30 30 31 33 45 2d 39 0d 0a 4a f7
0.0013E-9
J▒1
U

listenGPIBData process returned an unexpected number of bytes
30 2e 30 30 31 31 45 2d 39 0d 0a 4b 15
0.0011E-9
K1
U

listenGPIBData process returned an unexpected number of bytes
30 2e 30 30 31 32 45 2d 39 0d 0a 4b 26
0.0012E-9
K&1
U

listenGPIBData process returned an unexpected number of bytes
98 2e 30 30 31 32 45 2d 39 0d 0a 4b 26
▒.0012E-9
K&1
U

ListenGPIBBridge process returned error code c417
06 e6 36 86 46 36 56 ad 19 d6 4c d8 2d fb
ListenGPIBBridge process returned error code c417
06 e6 36 86 46 86 56 ad 19 d6 4c 98 4d fc
ListenGPIBBridge process returned error code c417
06 e6 36 86 46 36 56 ad 19 d6 4c d8 2d fb
listenGPIBData process returned an unexpected number of bytes
2b 30 2e 33 38 34 32 45 2d 38 0d 0a 5a b0
+0.3842E-8
Z▒1
U

ListenGPIBBridge process returned error code c417
06 e6 36 86 46 76 56 ad 19 d6 4c 98 ad ff
ListenGPIBBridge process returned error code c417
06 e6 36 86 46 46 56 ad 19 d6 4c 98 cd ff
72 -4.16260e-12 | +0.00000e+00 | +0.00000e+00 | +0.00000e+00
listenGPIBData process returned an unexpected number of bytes
30 2e 30 30 31 30 45 2d 39 0d 0a 4a c4
0.0010E-9
J▒11
▒
listenGPIBData process returned an unexpected number of bytes
30 2e 30 30 30 39 45 2d 39 0d 0a 5a 9d
0.0009E-9
Z▒11
▒
listenGPIBData process returned an unexpected number of bytes
98 2e 30 30 30 39 45 2d 39 0d 0a 5a 9d
▒.0009E-9
Z▒11
▒
listenGPIBData process returned an unexpected number of bytes
30 2e 30 30 31 31 45 2d 39 0d 0a 4b 15
0.0011E-9
K11
▒
listenGPIBData process returned an unexpected number of bytes
30 2e 30 30 31 31 45 2d 39 0d 0a 4b 15
0.0011E-9
K11
▒
listenGPIBData process returned an unexpected number of bytes
30 2e 30 30 31 30 45 2d 39 0d 0a 4a c4
0.0010E-9
J▒11
▒
ListenGPIBBridge process returned error code c417
06 e6 36 86 36 76 56 ad 19 d6 4c 18 59 f2
ListenGPIBBridge process returned error code c417
06 e6 36 86 36 96 56 ad 19 d6 4c 58 d9 f8
ListenGPIBBridge process returned error code c417

New Message

Is there a buffer reset time that if I wait long enough it will clear everything?

Karl

New Message

AH! I'm getting some errors from communicating with my RS232 device as well. I think this indicates that the errors are happening in the RS485 layer, rather than the GPIB layer.

Karl

I wonder if there’s a bad 485 device on the line. Maybe two devices with the same address?

The address would have had to spontaneously change. I didn't add any devices between when it was working properly and when the issues started showing up. Do you think that's possible for the address to randomly change?

I remembered that at some point we had the UART to RS485 converter (pictured) go bad, and you left me with a spare in case it went bad again. I tried switching that component out, but it looks like I'm still experiencing the same issues.

It sounds like you have a ‘bad actor’ . A device that is going bad(?).

I suggest removing all of the devices and ’talk’ to them one at a time.

A simple way to talk to them is issue a ’slaveID’ command

~$ sudo ./slaveID

Each should respond with an ascii description of what it thinks it is.

Okay, I'll give that a try.

Instead of sending 10 commands to make 10 measurements on the ammeter, we should send a single call for 10 measurements.

With the current setup, the rubidium will be heated to much too high of temperatures as the heat slowly dissipates to the location of the thermocouple. There are a number of solutions to this problem.

1. Modify the temperature controller box to have two variac inputs. This will allow me to hold the reservoir variac at a lower voltage which will not be too hot.
2. Play with the PID settings to limit how hot the reservoir can get from the TC controller.
3. Related to the previous point, there's actually a serious issue with the operation of the PID controller. It is set up to allow PROPORTIONAL control, but as we have it configured, it cannot deliver a proportional signal. We're essentially relying on the ID portion of the controller to modulate our temperature. I should have a conversation with @tranthamkw to see what device I should be using rather than the solid state relay to provide proportional control with the temperature controller.
4. Use the Ramp/Soak function of the controller to provide a way to slowly raise the temperature over a period of a few hours.

This is an issue that has shown up occasionally in the past. Previously I thought it was a power issue. I told Ken about it, and said I thought the problem was intermittent, but I can now confirm that it very consistently doesn't work.

That is, until I unplug the ethernet cord and plug it back in a few times. Now it seems to reliably work.

Since the Rb Spin Filter was first implemented, we have observed an asymmetry in the rubidium polarization we can achieve with the two types of circular polarization. When Munir observed this, he attributed it to a viewport which transmitted the two types of circularly polarized light differently. We have since replaced this viewport, but still do not achieve equal rubidium polarizations.

I would like to get to the bottom of this phenomenon, and the first step is to collect data to determine conclusively if the viewport contributes to the differences in polarization. We will achieve this by determining if the viewport alters the polarization state of the pump laser when it is present in the system. We will determine this by measuring the degree of circular polarization of the pump laser in three different situations.

1. With the viewport in and the magnetic field oriented parallel with the laser propagation direction.
2. With the viewport in and the magnetic field oriented anti-parallel with the laser propagation direction.
3. With the viewport out.

We will determine the degree of circular polarization using the "Ken retro-reflection method" where the laser is reflected back on itself and the intensity is measured as a function of the QWP position. The closer the intensity gets to zero at whatever position of the QWP, the better circularly polarized our light is.

@nstamos20, I'd like for you to collect this data.

Our rubidium polarization formula has somewhat mysterious origins. I believe I used the formula that was in Munir's thesis. I am only aware of one paper that lists a formula for the polarization, which is Ueno - 1987 (attached).

Ueno et al - 1987 - Faraday Rotation of Optically Pumped Sodium Vapour in a Weak Magnetic Field.pdf

The paper specifically notes that it's for a weak magnetic field, which for sodium was less than 600 G. We are well under 600 G, so up until now I assumed that we were fine with Rubidium, but it would be good to explicitly verify this. The paper describes how to find the critical field, but my Google skills weren't good enough for me to find the g-factor of the sodium atom in less than 5 minutes, so I'm adding this as a project to figure out later. I was attempting to first verify that I get 600 G for sodium using their formula, then would also calculate it for Rubidium.

Currently we have a pretty big mess of files lying around, to the point where someone unfamiliar probably wouldn't be able to make heads or tails of it.

• I'd like to have the source files in a separate directory, so that we just have executables in the root directory of RbControl.
• A well written README of what someone might want to do from the main directory.
• Move unused programs to the unused folder.

An unknown issue caused problems with the communication with the Sacher laser. Now two communications must be sent to the device in order for it to respond. Figuring out this issue would generally speed up data collection.

Also, we currently scan the frequency of the laser by adjusting the temperature. It would likely be faster to instead adjust the current. I should look into doing this. I originally chose to adjust the temperature rather than the current because then the intensity would be more consistent.

In its current form, the excitation function/ retarding field can take a really long time to run (4-5 minutes if doing a scan over 140 V). It takes so long because we step in 1.5 V increments over the full range. In reality, it would be best to do larger steps of voltage through the region far away from onset of the excitation function and the turnoff of the electron beam, then do smaller steps to get a high resolution scan of the turnoff.

Our method of painting on the cysteine results in visibly non-isotropic distributions of cysteine on the surface. Ideally, we would have a deposition method which we could control the thickness on the scale of 10s of nm.

One way to do this would be with physical vapor deposition. Keith Foreman built a chamber to do this for his thesis, and I had some conversations with him about using it to deposit cysteine. He was very supportive- as well as Shireen.

Dr. Gay mentioned that he was looking for things that Keith could do over the summer. If we could have Keith collaborate on growing variable depth cysteine surfaces, I think this would be a great use of Keith's skills that also contributes to the research that we want to do.