Crunch time

Well it’s been a busy few days and we’ve got deadlines, so things are going to have to happen and quick! Meaning it’s officially crunch time because there’s not a lot of it between now and Friday, when I’m scheduled to present some of the stuff I’ve been working on. Over the weekend my goal was to get at least one of the datasets processed and have a rough idea what’s going on. It was the main reason yesterday’s post was a short paragraph and nothing more. Sometimes things don’t quite go to plan.

We’re just days away from the first of several deadlines this month, several really big deadlines. The first is the “smallest” of the bunch, but still important to hit. It’s my first (of many) presentations on the data I’ve collected and hopefully processed at that point. There’s a ton of other stuff going on in the background, two papers, probably more, lots of experiments, and general other stuff I need to do, so finding time to finish all this won’t be easy. Which seems to be a theme around here.

Staying on topic though, my first deadline is the one I’m most worried about right now (for obvious reasons). If I can’t even meet this one, then I’m not sure how the others will fare. The answer, I’m afraid, is not well. Which meant that yesterday I spent my time working hard on getting the analysis done, or at least started to the point that I had a rough idea about what was going on.

I had already gotten most of the preprocessing stuff done and out of the way. Most of it anyway, but I came into it after taking saturday off (thankfully!) and feeling pretty good. It was a huge boon for me because I did manage to get to the ~95% point to have a rough idea of how things are working. I did run into some trouble that really cost me at the end of the day though and that’s part of the reason why yesterday’s post was not really a post.

That’s the good news, if there is good news. I’m very, very close! At least for the first dataset and frankly getting through the first one is almost certainly the hardest. The rest should (SHOULD) go smoother, the code I’m writing should (SHOULD) be generalizable to all the datasets, so it shouldn’t be an issue once I get to that point to process all the data. It’s why it’s not too much more work to collect a lot of data vs. just a few datasets. An n = 5 isn’t significantly easier than an n = 20, even though the preprocessing time follows dataset size pretty linearly, the analysis doesn’t, which is my only saving grace in all this.

Now for the bad news… where to start though.

There’s two rather large bits of bad news, so let’s talk about them in order of occurrence, since the last one is … well we’ll get there. I wrote some code that I thought was super slick. It imported my EMG data very nicely, resampled everything so it was all nicely aligned with the EEG data, and in parts it worked great. Then came for me to hit the run button and wouldn’t you believe it, it worked! Until I realized I had used the wrong logic for part of the resampling. No worries, I caught it, fixed it, and even checked it against the “correct” way to do it.

While I can’t go into details, I had some data with start and stop triggers (markers) to scale everything to. This is the best way to do this because we can align with negligible error. Unfortunately there were at least a few instances where I did not get a stop trigger. I came up with a way, in theory, to resample the data to the correct size without it. That’s what the logic was going to do, determine if there was a stop trigger or not and resample accordingly. It was pretty brilliant if I do say so myself. Since all my data got scaled assuming no stop trigger it became an accidental way for me to validate the method. With the exception of one chunk of data, they all resampled very closely to the “true” or correct datasize. The differences were negligible so I’ve arguably salvaged data that I had originally planned to scrap.

The bad news in that story is the time it ate. But it turns out there’s a second issue that I need to go in and fix, which I caught as I powered through mistake after mistake haphazardly to get to the rough, very rough, answer to my ultimate question, does super secret technique (SST) actually work? So here’s the thing, I’m powering through this stuff as quickly as possible trying to get the answer, or at least a hint of an answer, and I go to make THE plot. That is, THE PLOT to tell me if what I found the first time was a fluke or not. Can you imagine my disappointment when the EMG data didn’t plot?

Or rather the plot didn’t make sense. So I look and think that maybe the order of the data is wrong. It wouldn’t be the first time that my data didn’t get organized how I wanted it and there was a tricky part in the aligning code that maybe I got wrong. Since time is ticking away and I’m desperate to find the right row of data I need to plot to get the answer to my question, I finally say screw it and plot ALL the data, that’s ~30 graphs I generate en masse because I want to know and be done for the night as quickly as I could. The data I needed wasn’t in any of the plots and suddenly I’m panicking.

I’ve since figured out what happend, the EMG data isn’t just EMG, it’s a bunch of other data as well, accelerometer and gyro (both 3-axis) for each sensor. Unfortunately for me, the sample rate is different for each thing so I pull out the data by type, resample, then stuff it back into the table it came from. Testing it initially I had success, but apparently between my screwing around in the command line and committing it to actual code I screwed something up because the EMG data didn’t make it, my dataset is short by exactly the EMG channels. I have an idea of what happened, but I haven’t had a chance to debug yet.

Which leads us to letdown number two. Which is THE PLOT that I was trying to make. Since I didn’t have time to fix my resampling code, I used a quick and dirty solution to get to THE PLOT, which was create a time vector to scale my data by. I could plot my EEG data and use the time vector to scale my EMG data to it even though it’s a different length. It’s a trick I use semi-often so it wasn’t something I smartly came up with on the fly, but it worked and since I had my EEG data and my EMG data already properly aligned thanks to the way it was all setup, all that was left was to make the plot.

And it wasn’t the picture perfect data I had for my qualifying exam. So it goes.

While it’s not great news, it’s actually not bad news either because if you squint a little, it actually looks like I would expect it to look, the only problem is it appears to be noisy, like really noisy to. That could mean that I need to go back and run through my preprocessing steps again (this isn’t uncommon unfortunately), or it could mean a whole list of other things, like (1) it doesn’t actually work and my first dataset was a fluke/code error/I’m an idiot and messed something up, (2) it works, but it’s not that generalizable, (3) it works and it’s super sensitive, requiring precise setup to make it work, or (4) what I get from SST is not what I think it is. Just to name a few possibilities!

I wish I had better news and I won’t know the answer to the, “does this work” question for at least a few more days, even then it is tentative until I can process more of the data and say for certain. I’m not thrilled, but at least I’m making some progress. The project was (is?) high risk/high reward so there was a fair amount of a chance that it wasn’t going to work in the first place. I’m going to remain optimistic until I can get at least a few of the datasets finished and looked at, at least roughly.

So for now it’s a maybe situation? Which is why it’s crunch time.