Squiggles!

I averaged all of the ICP runs from the past two weeks and compiled them onto one Excel spreadsheet. I then began looking at the Na/Co ion competition more thoroughly using the article Prof. Andresen and John Giannini collaborated on a few summers ago, "Ion Competition in Condensed DNA Arrays in the Attractive Regime" as a guide. I tried to use the ion binding model used in the article to analyze the relationship between the number of ions near the DNA arrays and the solution's ion concentrations. This involved finding a constant, ξ, to relate the two sets of numbers (aka. the squiggle). After rearranging the formula given for a simplified ion binding model, I found a ξ for each data point. I took a rough average and an actual average and compared the values found using the ξ against the data from the ICP (shown below).

As you can see, the model only fits the middle three points. This could be due to my own error in calculating each point, the assumptions I made when using the model, the interactions due to Cl- that I neglected, or the model might not accurately represent this data. 

The Long Post

I haven't been blogging lately because I broke the USB wifi adapter on the computer I've been working on. I accidentally stepped on it. So, here's a run down of everything I've been doing lately, with pictures. Also, the magnetic tweezers are almost finished, minus a working flow cell.

As of today, this is what the Tweezers look like:

As you can see, the lab is not as much of a mess as it has been in the past. Besides that, let's take a tour of each part of the MT, now that it is completed (more or less).

In general, MT is actually an inverted microscope with magnets jammed into it. It is inverted because in a normal microscope, the light source comes from the bottom. However, in MT, the light source comes from the top down. 

This is the light source. It is a red Thorlabs LED with a wavelength of 625nm. The LED has been collimated by an aspheric condenser lens, f=20mm. In MT, it is important to have a collimated light source with a low coherence length, as this allows for a better generation of diffraction rings around the beads, which is essential in taking measurements. The long, ventilated part on top of the LED is the heat sink. The LED is being held by a kinematic mount attached to our rail system. This allows for greater control over the positioning of the LED and direction of the light source.

Directly under the light source are two motors and the magnet setup. Here you see the rotary motor, which has been coupled to a sled moved by a stepper motor, which in turn has been mounted on the rails. The rotary motor holds the magnet holder, and allows for rotation of the magnets. By rotating the magnets, we can apply a torque to the magnetic beads, and thus, the DNA (or whatever is attached to the bead). The stepper motor that controls the sled allows for moving the rotary motor up and down in space, and therefore controls the strength of the force being applied to the beads (magnet closer to the bead, stronger force).

This is the magnet holder, and attached to the magnet holder are the magnets. They are two Neodymium magnets.

Here we can see the full-middle setup of the MT. Underneath the rotary motor is the XY table. We will couple our flow cell (still in production) to the top of this. The XY table allows manual movement of the flow cell in X and Y directions (i.e. horizontal to this picture.

This is the view underneath the XY stage. Not shown here is the microscope objective, which is a Nikon 100X oil-immersion objective. The objective attaches to the objective holder, which has been coupled to another sled controlled by a stepper motor. This stepper motor allows for control of the focus of the magnified image of the sample cell. By moving the objective closer or further away from the sample, we can change the focus of the image.

Light exiting the objective is reflected by this 45 degree mirror. I have momentarily removed it from the MT setup in order to make access to the underside of the MT easier. The mirror reflects the light to the camera setup.

And this is the camera setup. It consists of a lens tube, a 100mm aspheric focusing lens, and a JAI-Pulnix CCD camera. The light collected in the tube is focused onto the CCD, which then transmits black and white images of the sample to the computer.

This is the entirety of the MT setup. So, how does it work, and what is it's purpose? You'll just have to wait for another blog post...

 

Last Week...

Today, I tried to normalize the cobalt-only data several ways. I'm still not sure if I did it right or if WinLab did it correctly on the computer. Both ways I normalized it lead to larger error bars (not by much but still). Overall they all look pretty much the same. Because of this, I made a PowerPoint of my overall results for this set of data off of the original data instead of the reprocessed. A few days ago I thought my error bars were great overall, then today I realized I forgot to multiply one set by three so now they are not that good. Hopefully they are good enough when I add a few more runs of samples onto it in the next three days that have the extra buffer.

All three of the ways I tried to look at my data. All pretty much the same except for slightly different error bars.

Tie dye Thursday

This morning I created new calibrations that included 0- 2.5 ppm Na to see if there are any effects due to sodium in the cobalt- only samples. I then diluted another set of sample solutions to run. This afternoon, I attempted to run the samples with the new calibration solutions but the sodium was very very off. I used a new stock solution of Na to make the solutions so tomorrow I am going to use the old and see if that fixes the problem. If not, I might have to scrap the new calibrations and simply use the old without sodium. The rest of the afternoon, the physics department tie dyed behind the science center.

Week 8: Wednesday

This morning, I ran the remaining samples from the other dilution of the cobalt- only series. They had concentrations similar to the runs I have made this week so I must have made a mistake a month ago when I ran them. This afternoon, I made more samples to run and ran a combination of all the samples I have made this past week. The last run had an overall trend of lower concentrations for Co, P and the internal standard Sr. Hopefully I can use the standard to correct for this tomorrow.

Steve and Prof. Andresen are super excited about making the motors move!! (and other stuff probably but I wasn't paying attention)

Week 8: Tuesday

I recreated a 30x dilution set of the cobalt-only samples and got the same result as yesterday. Although the ion concentrations are about a factor of 10 lower than the previous data, the charge ratio of cobalt for both dilutions are within each other's uncertainties. Tomorrow I'm going to play with the old samples to see if the factor of 10 still exists in the samples and then possible make new samples of that dilution and run it to compare to the old results.  

Monday Funday

On Friday I created a new calibration set to run more cobalt-only samples. In those and the samples I made today to run, I included an internal standard (Sr). The standard worked well in all the calibration solutions on Friday, but I must have made the samples less precisely this morning because the concentration of Sr was no where near the value it should have been, so the internal standard was dropped. The samples I ran today were a factor of 10 lower than the cobalt-only samples I ran more than a month ago. I am still unsure if this is a calculation mistake or a trend that actually exists in the data. 

Week 7: Wednesday

I read several articles while making sure Steve did not harm himself in the machine shop. The first article I read will be discussed on Friday during the lab's journal club and was about the effects of different salts on DNA elasticity using magnetic tweezers. If you have been reading this blog, it is obvious that this article includes aspects of both our projects. Funnily enough, Prof. Andresen contributed to two of the articles in the reference section of this article. The other articles I read further explained the compaction of DNA and the protocol we can utilize in my project using the ICP-OES. I also reviewed all of my notes thus far to condense the method I've used this summer.

Week 7: Tuesday

Today, I completely finished analyzing the data I have so far! Hopefully I can start the cobalt only samples tomorrow and finish them up by next week.

Week 7 Day 1

Today, I machined.I finished the taps for the piece that I made last Thursday, which connects a stepper motor to the 95mm rail mount, thus allowing us to attach the stepper motor to the rails. I also drew up plans and began to machine parts to allow us to connect the rotary motor to the stepper motor. The rotary motor will have the magnet holder (which we have yet to machine) attached to it.

7/7

Today, I worked on the data from the last two dilution sets. I averaged them together two different ways and then had to decide which way to display the data in a rough results explanation. The weighted average gave an odd shape for sodium similar to a wave. Now we are trying to fix the odd graphs by analyzing the data in different ways.

The Third of July

This morning, I ran the second set of samples twice. The calibrations for the second run were a little funky but overall it mostly affected the wavelengths that we do not use in data analysis. This afternoon I have been organizing the four runs, averaging them together and creating graphs that match the ones for the 100x and 20x dilutions. 

As you can see from the graph above, the sodium was all over the place for each run. There is a slight increase of sodium with higher sodium amounts (shocker) but it is not as smooth by any means as the other dilutions.

Week Six: Wednesday

Because we have only taken data for a high and low dilution, today I made and ran samples at a dilution between the previous samples. I created two sample sets along with new calibration solutions. This afternoon, I ran the first set of samples twice. Taking a quick glance at the data, I noticed that the concentrations for the different elements are not a steady increase or decrease as it was previously. Hopefully once I begin analyzing the data, these strange data points will not significantly affect the overall trends. 

Week Six: Tuesday

Today I got to run all of my samples! First I ran 10 samples of 20x buffer solution twice to get smaller standard error. The error was reduced from about 0.14 to 0.04. I also ran a sixth run of the 20x samples for varied sodium by combining the left over solution from the other 4 runs. Unfortunately, this run measured sodium much lower than the other runs so I am not sure if we should include this data or not. 

United States vs. Belgium: Week 6 Day 2

Yesterday and today, I machined and fixed a rail that will be used to hold our XY stage. I also spent some time figuring out the step size for our motors. That is all.

Week Six: Lunes

I continued researching articles about the various parts of my experiment from ion competition to the different techniques used to investigate DNA compaction and aggregation including the ICP, tweezers, AFM, SAXS and different types of crystallography. This afternoon, the argon gas was replaced and the ICP began to warm up for the numerous runs that will hopefully take place the rest of the week. The first run will be with the 10 buffer solutions I just made at 20x dilution to decrease error bars. In the previous four runs at 20x, the concentration of sodium in the buffer solutions steadily decreased each run. Hopefully running ten more samples will even out the averaged concentration.

Week Five: Friday

Today we had our first journal club meeting of the lab. Abby and I had read the paper Stretching DNA by Marko and Siggia. The paper introduces the theory behind the worm like chain model of polymers and applies it to DNA, which happens to be a semi-flexible polymer. The main importance of the paper is a useful formula which gives an approximate interpolation for the WLC force versus extension. This is a go to formula for most force extension work when it comes to force spectroscopy experiments with DNA. The main importance of this article however, is the fact that this interpolation formula is only useful for low and high end force ranges. At ranges in the middle, this formula is no longer accurate.

In addition to reading, I looked at more of the code today, trying to get the images displayed from the camera to the screen saved to file. What I found is that there exists a fatal error in the existing version of the code due to an inappropriate file call. What will happen if the user attempts to save the images to file is that the application will crash, and the user will be forced to stop the program through the task manager. This is of course not very useful.

Finally, Professor Andresen continued to teach me the basics of machining, introducing me to the procedures in operating the mill. We used the mill to machine a piece that attaches our XY table to the posts we machined earlier. This is what the lab looks like as of now:

TGIF

Today I read and talked about reading, that is all.

Week Five: Thursday

Today I started by playing with the rotary motor. While it worked as expected following my port of the motor code to existing code that works for the other stepper motors, I had some difficulty figuring out what the exact unit was to make the motor do one full rotation. This actually took some time to calibrate. In the end, I had to find both how many steps the stepper motor took, and how many substeps the motor controller takes, multiply the two, and then for some reason multiply this number by three. This gives me how many sub steps are in one revolution for the motor. I then made this number be defaulted to 1, so that if the user entered in 1 for the unit the motor should turn, the motor will turn just 1 time. In order to ensure that the error in turning was minimized, I blew up the amount of turns the motor should take to 100. Thankfully, the motor stopped at the same spot it started at after 100 turns, indicating that the error is minimal.

By the afternoon, I had played with the code and camera interactions a little bit more. I noticed that there was a significant lag between what is displayed on the screen of the computer and movements that the camera actually sees. I believe, although I can't test this yet since I don't have the objective lens, that the portion of the code that generates the lookup table works as well.

The next steps will be to finish focusing the lens for the camera and to clean it. I also need to figure out how to attach the rotary motor, and the stepper motors to the XY table. There will probably be a significant amount of machining to do in the near future, which isn't ideal, but necessary.

Week Five: Thursday

Today, I fixed the error bars on my graphs because I forgot to add my standard errors in quadrature. I also talked to Prof. Andresen to decide what to run next week to shrink the error bars. This afternoon I have been reading about optical emission spectrometers and I read the information for our round table tonight about research ethics. 

Week Five: All the Graphs, all the Time

Today, I finished my PowerPoint and fixed all of the first run data of the cobalt- varied samples. I also read several journal articles including one about the Wormlike Chain Model that was very confusing. This afternoon, I showed my PowerPoint to Prof. Andresen and he noticed that the amount of sodium in the samples was significantly different between the 20x and 100x dilution. To try and correct this, I redid my analysis using all three wavelengths the ICP measured, averaged them all for each sample and added this to the figure to result in the figure below.

As you can see, the addition of the other wavelengths just shifted the data down but did not bring them closer to each other.

Week Five: Mike Mike Mike Mike Mike! Guess what day it is!

Today I read up more on the worm like chain (WLC) model and its applications to a semi-flexible polymer, which DNA is. The posts that I spray painted yesterday have fully dried and are ready to use. The power supply for the camera arrived, and we managed to get the camera safely working with it. By the afternoon, we placed the focusing lens in place, and although it isn't focused at the right distance, we managed to get a pretty nice picture.

In the process however, we dirtied the focusing lens a good bit, and it will have to be cleaned. The next step after cleaning will be to get it focused at just the right distance.

Week Five: Tuesday

Today, I finished (relatively, I still need the motors to test it for sure) porting the code for the remaining motors to work off of the code for our motor control board. This is pretty good, because it means that the code is almost, if not entirely, full operational.

Also, I spray painted some posts.

Week Five: Tuesday

Today, all day, I worked on completing the analysis of the varied sodium DNA samples and create a PowerPoint and I am almost finished!!!

Week Five: Monday

Today:

All four posts have been machined and are ready to be mounted. Also, the framegrabber for the camera arrived today. We placed this in the computer, installed the software, and set about trying to get the camera to work. Unfortunately, we do not yet have a power supply for the camera, so we rigged one up momentarily.

Attached camera with rigged power supply.

After a little hassle, we managed to get the camera working to show changes in light. Nothing was in focus of course because the focusing lens is not yet set in the lens tube. As of today, all of the files needed for the code to work are present, so all of the code is technically working, just not for us. My next step is to update the code for the remaining motors to be run off of our motor control board. After this is finished, all of the code should be working for us.

Week Five: Monday

Today, I recreated the sodium-varied samples at 20x dilution and ran them through the ICP twice. Mistake time: I tried to open up chrome once I began the second run to send myself the first set of data and apparently that is a horrible idea because the computer freaked out and shut down :( 
Once I got the computer to be alive again, I ran the data for the second time. This afternoon, I started work on the data from the four runs of the samples. Tomorrow I will fix the graphs, clean up the excel file and create a PowerPoint to share with our collaborators including full explanations of the method, error propagation and detailed explanation of each graph.

Week Four: Wednesday

Today with the help of Dr. Good we managed to get the LED collimated. Although the setup is slightly different now in its attachment to the kinematic mount, it still functions the same.

The setup with the mounted LED in place. 

The Beam of Reasonable Collimation

I continued my work with porting the code for all of the stepper motors. I also added a table which can save values to screen of the stepper motor coordinates.

Lastly, Professor Andresen managed to machine one more post bringing our total to two.

Week Four: Tuesday

I began my day by trying to figure out why the .flx files generate errors, even when they are being used for the same motor control board as in the code. What I found was that a separate motor control board was being used for the other stepper motors. So, my next task which I already started today successfully is to port the code for these stepper motors for use with our motor control board. To do this, I took the code that already works for our stepper motors that will move the xy table, and began to allow it to move the other stepper motors. I managed to successfully do this with the stepper motor for the objective. 

The current driver and power supply for the LED arrived today, allowing us to play with the LED for a little bit of fun. Here's the mess it's in now:

The LED with the attached current driver. Trust me, it works.

Towards the end of the day Professor Andresen began to show me how to use the different machines in the workshop. We managed to machine one of the four posts that will hold up the rest of the tweezers set up. So now, the lab looks like this:

The post that Professor Andresen machined. 1/4" 20 tapped holes on both ends.

How the floating table looks now. It's all coming together. 

 

Week Four: Tuesday

I ran the six calibration solutions on the ICP and got reasonable results so I continued to run the calibrations with the first sample set I made yesterday. This data should follow a similar trend-line to the first sample run because the only difference was the concentration of the samples. However, the buffer solution had a much higher sodium concentration, by a factor of ten, causing the relative sodium in each sample to be much lower as seen in the graph below. Tomorrow, I hope to find the cause of this inconsistency and possibly make new samples at the same dilution. 

Figure shows the difference in the sodium concentration for each of the samples and the common buffer used for all samples. Because the measured level of sodium in the buffer was so high, the first few samples to show a concentration less than zero.

Week Four: Monday

The rails came in yesterday, allowing us to finalize our positioning of objects on the bread board to estimate the size of items that we will machine. For the LED, we will be placing an order for a current driver and power supply.

In terms of the code, I found that the cursor keys work for controlling the stepper motor. The up/down keys correspond to the x stepper motor, while the y corresponds to the left/right keys. These work through relative moves, but can be switched to absolute moves. All of this was done in the top level of the program. 

At the top level of the code, I added a little bit of code to show the users what coordinates they were at as they moved the stepper motors. We can add on to this code at any time in order to display more useful motor coordinates to the user. 

Week Four: Monday

Today, after discussing the goals of the week as a group, I began figuring out how to structure the next part of the experiment. I decided, with much help from Prof. Andresen, to run the first set of samples that has varying sodium concentrations at a 20x dilution. I created six new calibration solutions with different levels of sodium, cobalt and phosphorus than the last calibration set. I plan on running the new calibration set this afternoon and I will begin running the DNA samples tomorrow.

Week 3: THURSDAY

Today, we figured out how to connect the kinematic mount to the posts. Turns out, those posts have quite an ingenious design. 

More importantly, however, we managed to get the .flx files somewhat working. They exist now, although they run with errors. It doesn't seem to affect the final read out of the code however. This is an important development, as it opens up more of the code to work on. 

The most important thing that was accomplished today was the figuring out the units of one rotation of the motor in SimpleMove.vi. This is good, because just a little later I figured out how to modify the number of units in one rotation. This is exciting because it means we can modify these units to whatever we want.

Week 3: WEDNESDAY; the build begins...

Today I began setting up the different optical components that just recently arrived for a mock up as to how we might want to build things. As of right now, I have the lens tube holder and mirror kinematic holder set up in a decent fashion. 

Side view of the lens tube setup with the kinematic mount
for the mirror. The whole setup can be raised or lowered as
needed.

 One of the first problems that I ran into with the optomechanical components was with our larger kinematic mount. This larger mount will be used to hold the LED with the collimator attached to it.

The problem that I found was with the screws provided for the kinematic mount. The problem is that the screw size is too small for our optical posts; the stainless steel rods you see in the pictures to the left. To complicate things, it turns out that the large kinematic mount is not threaded, so the optical posts can't be screwed into the kinematic mounts either.

Ideally, this should be enough space for the rest of the
tweezers setup to go above the 45 degree mirror.

Ideally, you could just drill a hole into the kinematic mount to run a screw through it and into the stainless steel post. The thread count for the stainless steel post is unknown however, which will make it difficult to find something to attach it with. I believe that Thorlabs does this with their threading in order to make it so that you have to purchase their products.

View of the kinematic mount. You can see inside the mounting holes that the hole size changes.

Alternative view of the kinematic mount. There is no threading inside of the holes.

Another issue that I ran into today was with the CCD camera. Unfortunately, we didn't order a cable for the camera yet. This needs to be done. The problem is, we might end up needing a CameraLink cable, and a frame grabber control board in order to capture images from the camera. This could be costly.

Finally, I began to look at the high-powered LED that we received from Thorlabs. According to the included specs sheet, we'll need a power supply that can deliver current at a Forward Voltage of 2.2 V. This is quite strange. We also probably don't have anything that can provide that. 

Closeup of the LED

The nifty case that the LED came in with the specs sheet. High-tier.

Thankfully, the strangeness of these problems that I'm dealing with was mitigated by some quality Lab Swag.

Ithaca Waterfalls!

After four days of running samples for 16 hours each day, we finished our BioSAXS experiments. But before we left, we went to see several of the amazing waterfalls in Ithaca. 

Path leading up to the largest falls. Unfortunately the path was closed further up because of construction, so we had to circle back and follow another path to the waterfalls. 

WATERFALL!!

Prof. Andresen attempting to take a panoramic view of the falls. 

Week Three: TUESDAY

I started the day off by figuring out once again what the initial motor position would be if I connected everything up to the computer and ran the motor control code. Once again, I found that it was initialized to -16,777,216. This number must have some meaning, but I am not sure what.

Following this, I attempted to figure out how to do a little programming challenge to see if we could make the motors do what we want them to in the long run, or figure out if the existing code we have can accomplish this. The task is as follows:
1) Tell the motor to rotate 3.5 turns and stop.
2) Move back 1.2 turns and stop.
3) Report the position as 2.3
4) Save this position so that when the program is closed and reopened it still recognizes that the motor is at 2.3, ceteris paribus.

As it turns out, this is a bit more difficult than it would seem. The reason for new positions in the motor becoming zero each time the control board is unplugged as opposed to the program being closed and reopened is because the motor position is stored in the control board's memory, not the program's.

So how difficult is it to create a vi to do what was described above? Not very, but you need to have the right tools. Tasks 1) through 3) can easily be accomplished with the base code that I've been working with, but the unit "turns" would have to be figured out empirically. This is not optimal, so I set out to figure out what the units were, and more importantly, how this motor code works in the scheme of the whole program.

It turns out that the units, speed, and voltage of the motors can all be calibrated in a nice little calib.ini file. This file is then called by a CalibConstants.vi which appears everywhere in the overall tweezers.vi code structure. This CalibConstants.vi should be able to figure out the units and normalize instructions from turns to what the base code I was using earlier uses for units.

CalibConstants.vi is unfortunately not run-able because there are two important files missing: Reset Position.flx and Read Position.flx. The observant reader would note that these file endings are different for every other LabVIEW file that I've discussed so far. That's because, (after doing a little bit of research) these files are related to the NI-Motion set of *stuff*. .flx are Flex Motion files, used by the NI-Motion driver. These .flx files appear several times throughout the tweezers.vi and are most of the missing files in all of the code.

With the inclusion of these two .flx files, CalibConstants.vi should be run-able, and by extension, simplemove.vi, which is the overhead code for the base motor code I've been using, which should mean that the programming task I outlined above is entirely executable by the existing code we have. Also, since much of the tweezers.vi code has CalibConstants.vi throughout it, more of that code will be run-able too. This is exciting since our camera and other optics equipment just arrived today.

So what's the bottom line? Either we rewrite the code or get this NI-Motion driver which should contain the .flx libraries. I did manage to comment out sections of the CalibConstants.vi and SimpleMove.vi that referred to the .flx files we don't have. I managed to get both running, but since I commented critical sections out, the code was stuck in an infinite while loop and I was unable to proceed further.

CHESS: Second half of BioSAXS

Yesterday, after looking over the data from overnight, Prof. Andresen and I began running more samples. Instead of varying the salt concentration (the amount of K in each sample for dilutions of 1x, 2x, and 4x) we began changing the contents of each sample and diluting that. The samples were separated into the categories of blue and red and each had 6 types of samples. The first three were tetramers and the last three were dodecamers. The first in each series was simply the nucleosomes in solution of TEK10, the second included globular H1 protein, and the last included globular H5 protein. For these samples, we did not use any TEK but instead had a buffer of 1mM Mg. This could change much about how the nucleosomes interact because of the change from a +1 ion to a +2 ion in the solution. Because tetramers and dodecamers are more prone to aggregation, we began cleaning the sample cell after each sample much more thoroughly. We washed the buffer solution through the cell twice after running the sample and then washed the water and alcohol through twice as much than on Saturday. On Sunday, we were able to run all of the Red series, a trimer and a large portion of the Blue series. Our other group finished that series and began to run their own samples of proteins. 
Today, we ran the gold samples that were given to us by Prof. Thompson for his experiments. Because the composition of the gold samples was so different than the nucleosome arrays, our sample cell was wrecked and Prof. Andresen had to insert a new cell and reconfigure the alignment. While he was doing this, I attended a thesis defense on the ion interactions with single and double stranded DNA measured using solution x-ray scattering.  This talk included several biophysical techniques that we discussed in physics 246 this past spring such as SAXS (obviously), spFRET and molecular dynamics. The presenter also used data obtained from Gettysburg's ICP-AES that Prof. Andresen ran. To finish off the day, we are going to run the R series with a 2x dilution for the different levels of TEK (50, 100 and 200) including double the buffer between samples (the TEK of the previous and the TEK of the next). Hopefully we will get through most of the series before we switch off at midnight.

Week Three: MONDAY

Today I accomplished a couple of things; reading and code-documenting, not necessarily in that order. I generally like to break up the day as a mix between reading and viewing code, so that neither become to monotonous.

I finished reading Kruithof's thesis, Magnetic Tweezers Based Force Spectroscopy Studies of the Structure and Dynamics of Nucleosomes and Chromatin (2009), which was quite a read; 9 out of 10, would recommend. I also began reading a thesis by Fan-Tso Chien, Chromatin Dynamics Resolved with Force Spectroscopy (2011), which I plan to finish tomorrow. In general these readings have strengthened my understanding of force spectroscopy. More so, it highlighted more things that I should learn about. I've slowly been creating a list of things to delve more deeply into, in no particular order. Since this project is on magnetic tweezers, it would be helpful to further my knowledge on microbiology, so I've included topics such as DNA, chromatin, and the worm-like-chain model, mostly with respect to their use in force spectroscopy experiments, and what questions we can resolve about chromatin through force spectroscopy. I've also included more technical things, some which I know a little about already, and others which I feel I should know but unfortunately don't since I've never had a class in Bayesian statistics. These are, Brownian motion, Monte-Carlo experiments, and Markov analysis w/ respect to a Hidden Markov model.

Back to the mechanical side of things, I made a couple of important breakthroughs, but I'm not entirely sure of their implications. I analyzed how the motor control board and our code for the control board works more thoroughly. When I initially ran the code, I found that the setup thought it was at initial coordinate setting of -16,777,216 (units, still need to figure out what the units are). Not remembering what I had left the motor at yesterday, I assumed this might have been just where I left off, although it was highly unlikely. I told the code to move the motor to a position of 0. After this, I proceeded to unplug the motor control board from power and the computer. I closed out all of the code as well. Reconnecting everything, the position remains at 0. I then told the code to move to 100,000 and verify it was at 100,000. Closing and unplugging everything only to reconnect later, I found the position was now 0. I noticed that after a move to 100,000, the motor was at roughly the same position as 0. To verify that 100,000 wasn't simply a "rotational multiple of 0" (like on the unit circle, 0, 2pi, so forth), I made a move to 50,000, believing that this should be somewhere in half, and give an initialized number. This is not the case however. This will also read 0 on startup, as well as any non-multiple of these. What this means is, the control board does not hold memory after power down. I also noticed that the absolute moves as used in the code, 25,000, 50,000, 100,000, and 700,000 are not multiples of one another, as they do not remain at the same position. What this also means is that there will be a problem with initialization for absolute moves. Any position the motor is in at shutoff will become the new 0 at startup, so absolute moves no longer are absolute. I also have no idea why the code believed the motor was at -16,777,216 at startup.

I found what I thought could be possible Piezo-related subvi's. All of them are contained within the SimpleMove vi, or within the Piezo-related subvi's as additional Piezo sub vi's. This is good, as it means it should be relatively easy to remove the part of the case structure in SimpleMove that contains the code for the Piezo with little repercussions.

Finally, I began exploring the code above SimpleMove. I found that SimpleMove has instances in InitializeLUT, InitTweezers, MoveTrajectory, the main instance of the code, and UseParFile. I began my documentation of MoveTrajectory, although it is quite a complicated bit of code. For tomorrow, I plan to continue to document these vi's. Also, out of curiosity, I will find what the code believes to be the initial position of the motor.    

BioSAXS Controls Video

Video of System Running: The first computer screen shows a spreadsheet of all the runs with information about each run; what it is, how many seconds its exposed for each image, how many images, and the time that the run began. The second computer screen controls the spec to make each run start and to vary the time of the run. This screen also controls the sample cell to tell it to move the sample left or right, to oscillate and at what step size it should take. The TV screen above both shows what the camera sees so that the oscillations can be regulated and we can be sure that no aggregates or bubbles are in the cell. Above all of this is the sensors for I2, I3, GDoor and the diode. The diode does not give us much information. When I2 and I3 are large, that signifies the strength of the X-rays in the beam.

Week Two: BioSAXS

I accompanied Professor Andresen to the Cornell High Energy Synchrotron Source (CHESS) to run SAXS experiments on various nucleosome arrays. Friday and a large part of Saturday, we modified the experimental setup. We elongated the tubing in the hutch, inserted a beam stop, switched the detector from a 100K pixel to a 200K and began with an X-ray of 200 by 200 micrometers. 

Inside the hutch, overall view of the setup. The long tube farthest to the left was exchanged with the tube on the wall behind to lower the q value. The X-ray beam enters at the far right.

Further to the right the 200K detector can be seen which is the box on the end of the tubing. Right before the detector is a glass plate that the beam stop is placed on. **Fun Fact: Professor Andresen, as a graduate student, painted the maroon square behind the detector.

Then a camera was set up to look at the sample inside the beam mostly to ensure that the sample was centered at the beam and to look for possible air bubbles or aggregates in the sample. At this point the guards and elements of the tube were varied to get the best beam signal throughout the tube with minimal scattering due to the sides of the tubes. Silver behenate was used as a calibration of the beam to find rough values for q to see what range we were working with. All of this was changed in the hopes of lowing the q value, which is the momentum transfer or scattering vector, to a low of 0.004. After the physical setup was chosen and implemented, all the different elements had to be synced with the computer outside the hutch (the hutch is the room where the X-rays are present during experiments).This was what took the most time because so many variables were changed since the last time the G1 hutch was operating. 

Operating system outside of hutch including the real time values of I3 and I2 which give an idea of the strength of the X-rays inside the hutch, the camera monitor that is looking at the sample, and all of the programs that control the beam, guards, sample etc. 

In the image above, Professor Andresen was closing the hutch door and turning the key. This is where the key is placed and the X-rays are turned on. After searching the hutch (pressing two buttons on either side of the hutch and ensuring no one is inside) the door is shut, key is taken and placed in the Station G1 control and the black buttons are pressed on the top right corner of the control box. 

 The element that gave the most trouble was the beam stop which was not in the correct place for running initally and also had different components that continually got in the way of the X-ray beam. This caused the I3 signal to be very low (~16) until it was fixed and showed a signal of ~200. After many hours of centering the beam and correcting the scattering from the sides, we began taking data from our samples. 
We began with the Trimer A which is three nucleosomes together because it is the smallest set of nucleosomes we will look at this weekend. First, distilled water is sent through the sample cell (about 3 times), then ethanol is sent through (about 2 times). At this point the sample cell is mostly clean so we turned on the air to dry the area for about 30 seconds minimum. After all that, we inserted a buffer, closed the hutch, and ran the buffer. This gives us a base line to subtract out any systematic problems against the actual samples. 

View of where the sample is inserted. Between the two plates, a small clear sample cell can be seen. This is where the samples, buffers, water and alcohol is placed and also where the air comes out. The camera is on the opposite side of the beam.  

We ran everything for 5 seconds with 20 images with a ten second break and then once more. After the buffer, we cleaned the sample cell with water, alcohol, and air once more and put the sample inside. We repeated the set up of 5 seconds, 20 images twice for the sample. This procedure was followed for all of Trimer A which included three dilutions (1x, 2x, 4x) for buffers of 10, 50, 100 and 200. 
Today, we are running samples of higher nucleosome arrays. Tetramers and dodecamers (4 and 12 nucleosome arrays respectfully) are much larger structures so the set up had to be modified so that the scattering angles could be measured. This is because larger objects give smaller scattering angles and smaller objects give larger scattering angles. We had some issues with a peak coming off in the z direction from the beam but by changing the guards and the beam stop, this was corrected. Because we are working with the other samples, we lower the beam size to 100 micrometers in the z direction which also lower our intensity so we will be taking longer time intervals when we run. 

Week 2: Friday

Today I worked primarily on experimenting with the motor control VI and documenting the SimpleMove vi and its sub vi's. I also did a little bit of reading on magnetic tweezers. But first, I'd like to share with you the current setup we have for the lab.

We took the floater table from the nuclear lab and moved it into the middle of the room. Also featured is the new computer.

I started the day by messing around with the motor control board, the motor, and the VI that's supposed to run it. I improved over my messing with it from the other day by managing to successfully make it rotate in the opposite direction today. Although I initially thought that the code written for the control board would be bug free, I discovered later in the day that there would be certain cases in which the code would break. For example, starting from point zero, it is possible to move the motor in the wrong direction into negative absolute points. This could be bad for the MT setup, as it could result in the motor moving when it cannot physically move due to a barrier. I also found that when just launching the VI, the code does not always recognize what is zero for the motor.

The motor setup: A control board straight out of the box (or in it), a motor, and a breadboard. A USB cable leads to the computer. A power supply runs off of the table to the control board.

A picture of the control board that we are using. It is a Trinamic TMCM 6110 motion control board.

I also ran into issues today with the code that calls the move controls for the motor. Yesterday I attempted to see if deleting parts of that code that don't pertain to the motor control would allow for it to run even though we don't have the other parts that the parts of the code that I deleted refer to. Unfortunately, today I found that it still will not be able to run, as the unit calibration and timing sub vi's will not run due to missing files. It's possible that if this overhead code that calls the motor control code fixes the problems with zeroing I mentioned earlier, but I'm not 100% sure.

Week 2: Thursday

Today I reviewed the new LabVIEW code sent to us. We finally have our new computer up and running in the lab installed with LabVIEW. I managed to make the motor control board operate the motors through the supplier's LabVIEW code just as Dr. Andresen had. However, I found that the existing MT LabVIEW code could also run the motors. While I was quite pleased with this, I found it to be somewhat buggy, and had no way to make the motor move in the opposite direction, which is disappointing. I believe it to be a problem with some uninitialized values, which might be initialized or transformed in some other VI in the codeset.

For the rest of the day, I began looking at the SimpleMove.vi, the part of the code that basically tells the motor control to move. It also does several other things, however, it's not functional right now, since there are several pieces of the code missing. With our optics in order and just waiting to be ordered, it is now my job to figure out how to get this section of the code running again, which should take a couple of days.

Week 2 Wednesday

For the most part this week, I've been figuring out the optical system and components that we are going to include in the magnetic tweezers setup. It's been problematic so far, because we're having difficulty with the parts list from one of Professor Andresen's friends. Complicating the situation is the fact that they're in Singapore, so any communication is delayed significantly.

One of the first problems we have is determining how to focus the collimated light coming out of the objective. This light has to be focused in order to be stored on our CCD. We have a choice of either a f=100 or f=180mm lens. However, we're unsure if (and what would happen) if we include both lenses in the setup at the same time. Secondly, we need to figure out what type of LED we want as our light source. We're leaning to using Thorlabs as our main supplier for all of our opto-mechanical and optics equipment for ease. So, for the most part of this afternoon, I've been chatting with a tech-adviser from Thorlabs for help with selecting the LED and the appropriate opto-mechanical components. Right now we're leaning towards a red (625nm) LED w/ an output power of 1000mA. To collimate the LED, we'll be constructing our own collimator out of different Thorlab stuff. We'll be using an aspherical lens with AR coating in some appropriate housing to collimate the light from the LED. This housing will attach to the LED itself. Of course, the main problem now is making sure that the whole list of everything we need is complete, and get everything ordered.

Week Two: Mike Mike Mike Mike! Guess what day it is!?!

This morning, I reanalyzed the cobalt- only samples on the ICP, exported the raw data, and added the information to the graphs I made yesterday. The fraction of charge neutralized by cobalt was within the standard deviation from the first run but the individual concentrations of cobalt and phosphorus were significantly lower than yesterday. Although the second run had much lower concentrations, the trendline for both ions traced the same as the first run. This afternoon, I have been catching up on my reading about DNA, nucleosomes, SAXS and studies related to my experiment. 

Week Two: Tuesday

I recreated the graphs from yesterday of the fraction of charge neutralized by Cobalt and Sodium among others using data from both of the runs. Below are the separate graphs of the charge neutralized by the ions. 

I also began to run the other samples given to us with no sodium present in large or varying quantities and only cobalt was varied. Tomorrow I will run the samples again to verify the initial results. 

Week Two: Monday

I analyzed the data collected from my final run last week to determine the quality of the run based on the knowledge I have about how the concentrations of cobalt, sodium and phosphorus change with increasing sodium levels. Using the fact that each of the samples increased in sodium from 0 mM to 80 mM, I created Excel graphs to show the relationships between each of the ions and also how the system competitively behaves. I also determined the relative proportions of cobalt and sodium in solution and created a graph to show their congruence relative to the amount of phosphorus detected. This is shown in the graph below. 

The error bars are rather large so I will be adding a second run of the same samples to clean the graphs up. Today, Steve and I also had a group meeting with Prof. Andresen to discuss the current state of our experiments, mostly so each of us understand what the other is doing, and also discussed what we will be doing for the next two weeks. 

Settimana Due Giorno Uno

Oggi io ho letto molti documenti per il mio lavoro. In the morning I read up on optics, particularly relating to ccd cameras and camera focusing in general. A problem that we've encountered is that, while the focus from the back end of the objective in the setup may be infinity, we still need a way to resolve the picture so that it is in focus for the ccd camera. We need a lens, and a couple of other optics to get the setup to work properly.
I also began to document and review parts lists for other magnetic tweezers setups. I will begin comparing these groups' parts lists to our own, and figure out which are necessary.
Around 3.30, the motor control board and the motor itself arrived. I began to play with the motor control board by connecting it to my laptop via usb. A green light came on flashing on the board, which is a good sign. After a little hassle, I believe that I have my laptop using the right driver for the control board. Hopefully my pc will now recognize the device.

Week One Day Four: The Chickie Buffer

After starting the ICP- OES, I created 5 mL samples including 50 uL of the samples provided that consist of DNA with 1 mM Cobalt2+ and varied amounts of Sodium+ ions dissolved in a solution of KCl and Tris. The samples had sodium amounts from 0 to 80 mM. The samples were run with the calibration of cobalt, sodium and phosphorus that were created previously. I had the chance to modify the method for this run from the method used yesterday. The ICP was then put on standby for Monday and I have several graphs to make on Monday based on the data from today's run. Hopefully I can put a few of them in on Monday once they are completed.

P.S.

I almost forgot to mention a revelation I had while Prof. Andresen was explaining the physics (mostly thermo) behind what we are attempting to do. For over ten years, studies have been undertaken to determine why, under certain conditions that I don't remember exactly, DNA will attract another DNA even though they are both negatively charged. The Poisson- Boltzmann equation fits what is observed except for the attraction part. In lab, we are trying to evaluate what is causing this attraction. This leads to my revelation, Prof. Andresen explained this to me today and all I thought about was a scene in Chasing Liberty (a movie about the president's daughter on an adventure in Europe) and the part where the president's daughter was a "Chickie buffer (that) negates the potential for man-touching-man discomfort" so that the two guys in the movie could hug with her between them. So this summer, I am trying to find the chickie buffer!

Week 1 Day 4

Today I delved into some LabVIEW code that we will be using for our magnetic tweezers setup. We identified the sub VIs pertaining to motor control and basically figured out how they work. We also identified possibilities for future motor control.

Summer 2014: Magnets, DNA, and Fun!

Abby and Steve hard at work in our newly created student office!

The summer has begun with two great new students (and the same old professor). We have a couple of great projects going on this summer from building a new instrument from the ground up to continuing our quest to understand the physics behind DNA packing! (In fact they have gotten some posts in ahead of me below.)

Week 1 Days 1/2/3

Day 1

I began by familiarizing myself with the programming language LabVIEW. I had done a little bit of programming before this, mostly in MATLAB and java. LabVIEW is very different than these other languages, in that it is a graphical (visual) programming language. Instead of the code being written, it looks like a circuit diagram. LabVIEW has several advantages over traditional programming languages is that there is no real compiler. Errors also tend to be easy to find as the interface won't even let you run the code if there is an error present, and shows you the error. I made several simple programs from a tutorial that introduced LabVIEW concepts. Such programs include one that determines whether or not to hire someone based on their grade, a conversion of a numbered grade to a letter grade, and a decision maker based on a machine's running temperature.

Fig 1: This is an example of the decision maker program. The top shows the front panel of LabVIEW, which displays the output of the code. The bottom is the block diagram, the code itself. For an input temperature and current machine speed, the code determines if the machine is running too hot. If it is not running too hot, it allows the machine to speed up.

Day 2

I continued my familiarization with LabVIEW by writing several programs that created a sine signal and then applied noise to it. One program filtered the noise out and produced a filtered sine signal and displayed both the unfiltered and filtered signal for the user. Another allowed the user to create an rms form of the sine wave and displayed a table of the rms measurements for the user. I also created a program which allowed the user to save data and selected data points of peak to peak measurements of the filtered sine wave to a text file.

Fig 2: This program creates a sine signal and then adds noise to it. The unfiltered sine signal is displayed for the user graphically in the front panel. The signal is then filtered and displayed for the user. The code displays a warning signal to the user for peak to peak measurements of the filtered signal that are above a threshold. The user also has the option to press a button on the front panel that allows them to save certain data points to a text file.

Day 3

I read several papers on the principles and design of a magnetic tweezers (MT) experimental apparatus. I discovered that multiple methods exist for the tracking of the beads used in MT applications. I also familiarized myself with the physics behind MT.