search

jmicrobe / odin

Repo for documentation related to the Optical Density Instrument at the Stahl lab
MIT License
1 stars 2 forks source link

Reads multiplied at single timepoint #38

Open jmicrobe opened 5 years ago

jmicrobe commented 5 years ago

I am currently running samples in the ODIn, but recording this issue I recently noticed. On 3/11/19 close to 23:00 all channels show a spike in readings at one time point, then go back to normal. I looked closer at this time point, and not only is there a spike, but there are also 11 reads for each channel, all at the same time. This is from data on the server, and time is only reported down to the second. Since it didn't impact the curves and it hasn't happened again, this issue is low priority but still a curiosity.

At the next shut-off I'll compare the server data with the onboard SD card.

image

jmicrobe commented 5 years ago

I've checked the SD card from onboard the ODIn and I don't see any issues with the timepoints in the raw data, so I think this was an issue with the server.

Here are the datetime and millisecond columns from the data frame around the timepoint mentioned (note that there's always a delay between the server timepoint and the raw data)

Raw from ODIn:

datetime milliseconds
2019/3/11 21:45:43 455187514
2019/3/11 22:05:43 456387569
2019/3/11 22:25:43 457587625
2019/3/11 22:45:44 458787669
2019/3/11 23:05:44 459987723
2019/3/11 23:25:44 461187777

Sever data:

datetime milliseconds
03/11/19 21:34:51 -0700 453987473
03/11/19 21:54:51 -0700 455187514
03/11/19 22:14:51 -0700 456387569
03/11/19 22:34:52 -0700 457587625
03/11/19 22:54:52 -0700 441132436
03/11/19 22:54:52 -0700 101975597
03/11/19 22:54:52 -0700 106104385
03/11/19 22:54:52 -0700 104203841
03/11/19 22:54:52 -0700 225124258
03/11/19 22:54:52 -0700 103482936
03/11/19 22:54:52 -0700 84936260
03/11/19 22:54:52 -0700 103745108
03/11/19 22:54:52 -0700 392832234
03/11/19 22:54:52 -0700 104007220
03/11/19 22:54:52 -0700 405282553
03/11/19 23:14:52 -0700 459987723
03/11/19 23:34:52 -0700 461187777
03/11/19 23:54:52 -0700 462387817

Also of note is the the data on the server is showing different values in the milA readings, so the entries (as you can see in the plot) are not direct copies.

jmicrobe commented 5 years ago

@dacb Any insights on this? Seems to be a server issue. I'm noticing it again with a new run that I started. I can't check the SD card as it's still going, but I would bet you'd see the same thing as before.

From the current run you can see 3/23/19 8:09 repeated 18 times, with some deviations in the milliseconds reported (sequenceID is milliseconds)

time error_flag sequenceID
3/23/19 8:09 0 103941670
3/23/19 8:09 0 103417382
3/23/19 8:09 0 103220788
3/23/19 8:09 0 104793680
3/23/19 8:09 0 142348518
3/23/19 8:09 0 103351862
3/23/19 8:09 0 103220809
3/23/19 8:09 0 103876160
3/23/19 8:09 0 198969470
3/23/19 8:09 0 103417386
3/23/19 8:09 0 102106651
3/23/19 8:09 0 105121320
3/23/19 8:09 0 197265615
3/23/19 8:09 0 103679541
3/23/19 8:09 0 104531525
3/23/19 8:09 0 98043447
3/23/19 8:09 0 241503102
3/23/19 8:09 0 104138296
3/23/19 8:09 0 176163170

Then the subsequent readings are correct with only one entry each:

time error_flag sequenceID
3/23/19 8:29 0 334951580
3/23/19 8:49 0 336151664
3/23/19 9:09 0 337351748

And for more info, these are the readings prior to the glitch, which show that none of the milliseconds are correct at 8:09, but they correct afterwards:

time error_flag sequenceID
3/23/19 7:29 0 331351327
3/23/19 7:49 0 332551411
jmicrobe commented 5 years ago

Just giving a follow-up on this issue - it hasn't happened again, strangely. As far as I know nothing was changed on the server, nor on the arduino. I've run several sets of samples without seeing this phenomenon.