DTS coding
-Added progressbar for data validation
-Updated the progress bar (see figure 1)
-Fixed bug with wrong sample size (see figure 2)
-Fixed bug with unorganized barplots (see figure 2)

Exp always to the right:
plotOMparams <- plotOMparams[order(plotOMparams$desc),]
plotOMparams$group <- factor(plotOMparams$group, levels=paste(unique(plotOMparams$group)))

Samplesize fix:
samplesizes.annotate(boxes, as.numeric(table(plotOMparams$desc)))

Progressbar:
progress <- c(round(l(100/(length(xml_list)))),round(flycount(100/(totalflies))))

Rescreening:
-Finished rescreening last Thursday. Started to evaluate the new data

Optomotor platform: Ran a few more tests to confirm that the machine was still working, it is. I also adjusted the 0 line so that it is at 0, by readjusting the “zero line” screw. Looks much better now but it is still not perfectly at 0. A difference 0.1 on the computer screen translates to 100 in the evaluation chart.

Optomotor platform:
Ran a few more tests to confirm that the 0 line is always at 0. Readjusted the “zero line” screw. Looks much better now. It is still not perfectly at 0 but a difference of 0.1 in the chart translates to 100 in the evaluation graph.

Recently I measured the optomotor response in T4/T5 flies. As expected, they did not respond to the optomotor stimulus as seen in the left chart below. However, statistical evaluation struggles to quantify this difference. It might be that this is because of the low sample size, or that we are using the wrong statistical analysis?

Mean or median?

A highly hypothetical scenario of how the distribution of dwelling times could be. Even if unrealistic, it still illustrates the problem of using median instead of mean.

Plotting the dwelling times as means

Grouped analysis of dwelling times

Cumming estimation plot

• Added a timer
• Previous version generated faulty xml files. This bug has been squashed (see image below)
• Display window of the software now also prints which direction the striped arena turns

The schematic drawing is an example. The method that is currently used to calculate the dwelling time is excluding times that are 50 ms. Each dwelling time is getting an additional 50ms to compensate for the transitional time loss (dashed line in schematic drawing). The chart on the right side is the total time for each period when adding negative and positive dwelling times.

Johann Schmid and I have been working on getting updates to the torque meter software. Small changes but with significant increase in user friendliness.

● Inability to overwrite the data

● Progress bar and a time bar implemented

● It resets the pattern from one period to another. This is of critical importance as this enables one to do basically any kind of experiment on the machine

I have also gotten hold of a free version of LabView. I thought it could be a good idea that we could to small changes ourself to the software. However, my version is 2017 and Mr Schmid mentioned that he will be transferring to LabView 2019, and thereby retiring the 2017 version. A student version of labview is affordable, less than 50 Euros. It could be worth getting a legal licence of this software.

● The A/D converter now connects directly to the PCB. Only problem is that it is inverted, meaning that the signal from the torque machine gives a positive signal it is registered as a negative signal in the software. Mr Schmid is aware of this and will invert the signal in the software, rather than resoldering the PCB connection.

Updates to the DTS

● DTS is now also better compatible wit the new kind of data we are getting. A conflict occurred because of differences in pattern. An easy fix by just ignoring this parameter.

Correlation plot between the mean ratio of the flies that stay in the middle versus the Weighted PIs

Slope = 0.0053
Intercept = 0.240
R square value = -0.03834

contrary to the expectations, there seems to be no correlation .