Title: Searching for the source of the noise
1. Thread sewed in the wrong place.
Today we found out that a single conductive thread was sewed in the wrong place as shown below:
The problem here is that the conductive thread does not have the thin layer of fabric below it and so it always connects the top layer of conductive sensor to the bottom layer. I will fix this issue as soon as I can get some conductive thread.
2. Reversing the 10 pins on the Arduino
I plotted the FFT plots again after reversing these pins. Below are the new FFT plots:
They look a lot more reasonable, with a lot less spikes. We can still see the spikes at 7 Hz and 15.3 Hz in some cells but they are much less than the previous time and with much less power.
(1,1):
(1,2):
(1,3):
(1,4):
(1,5):
(1,6):
(1,7):
(1,8):
(1,9):
(1,10):
(2,1):
(2,2):
(2,3):
(2,4):
(2,5):
(2,6):
(2,7):
(2,8):
(2,9):
(2,10):
(3,1):
(3,2):
(3,3):
(3,4):
(3,5):
(3,6):
(3,7):
(3,8):
(3,9):
(3,10):
(4,1):
(4,2):
(4,3):
(4,4):
(4,5):
(4,6):
(4,7):
(4,8):
(4,9):
(4,10):
(5,1):
(5,2):
(5,3):
(5,4):
(5,5):
(5,6):
(5,7):
(5,8):
(5,9):
(5,10):



















































Just a note (observed to Bita ~1 week ago) that I'm unable to see the plots for some reason. I could see earlier ones.
ReplyDelete-km
Checking in. I think we are waiting on some input from Kerem?
ReplyDeleteRe plots, looking closer (bad eyes!) I am realizing that I *can* see them, just the first few are very low scale. I guess you kept the scale the same as before for comparison.
I am not sure of the practical calibration - the FFT's mostly give an idea of relative noise, and consistency across the device. In any case, if the scale is the same as before, then the case is certainly much improved and we should just proceed with new data collection, perhaps forgetting about the one bad pixel if it still gives a problem.