No pun intended.
When I agreed to handle the two DIGCOLA (I forgot the new name. LBYECE-something.) sections, I figured it wouldn't be too much of a problem. It wouldn't really, had it been the same DIGCOLA course I took two(?) years ago.
Apparently, during my time, there were two professors who took on DIGCOLA, Mr. Sybingco and Mr. Manzano, and each used their own manual. Hence, there are two sets of experiments that are totally different from one another. I took mine with the latter as my prof and now, I am using the former's version of the manual. To my shock and dismay, I can't recognize any of the experiments. Big trouble. At this point, my students and I are pretty much on the same level. My only advantage is that I'm with the faculty.
So, since I can't pass this burden to anyone (No one would take it anyway. Maybe the reason why I got it is because Mr. Sybingco doesn't want to take it in the first place and so did the full-timers, as well as the other part-timers. Maybe because I am the last one to apply, I got the "latak" courses, the rejects. Heck, even the other subject I have is a lot of hell to go through. I know. I survived through it. I also took INDELIN.), I have no other choice but to get on with this until the end of the term. So, I decided to perform the experiments alone. So far, I've finished two.
Experiment 1: I managed to find out that Mr. Leonor got to handle this subject two terms back. I went straight to him. According to him, he did take on DIGCOLA once. Never again, he says. Great. He gave me some precious handouts though.
So, last Thursday morning, I went to deal with the impossible, to perform the experiments on my own. I managed to get the code working. However, my output was incorrect. I reckoned I'd take care of it later on a spare PC during lab period.
But luck was just not on my side. There were five available set of equipment according to the technician. Enough for the five groups of the Thursday class. To make matters worse, there were only six PCs in the lab and one was busted. I decided to let them do the experiments first and step in when there are any troubles. Soon enough, they arrived.
First, one group can't proceed with the experiment because their PC lacked the needed drivers to interface the function generator and the digital oscilloscope with the PC. I told them to share a PC with another group. And second, all of the groups can't understand the second activity. I can't blame them. I don't expect anyone to get the experiment anyway.
Basically, the first experiment's objective is to remotely control the function generator and the digital oscilloscope using the PC. Then, the display on the oscilloscope should be sampled and stored in Matlab as a matrix. Afterwards, the matrix should be plotted to trace the same display from the oscilloscope onto a Matlab graph. This is accomplished by adjusting their settings using Matlab codes. Sounds easy. Exactly. It just seems that way. One setback is that the students are expected to have prior knowledge of the user manual of both the oscilloscope and source. The user manual contains the correct syntax of the codes that are used to configure the oscilloscope and generator. Another problem is the number of connections for the experiment, which makes it quite challenging to troubleshoot where an error is coming from should the students encounter one. A detailed example might help you understand this one.
I performed the experiment earlier before the class started. I had some trouble with the output. I let it go for the meantime. When the class was getting uneasy because of the difficulty of the experiment, I went to the PC that was directly in front of the professor's desk. I ran my program. It didn't work. That's impossible, really. If it ran in another PC, it should run anywhere else. That is, unless the Matlab program in the other PCs are not functioning as they should be. So, I went to the PC that I used during the morning. I figured it should work there. I then warned the class that there will be an output but it wouldn't be correct. Lo and behold, the PC showed us the right output. It was then that I considered Sir Leonor's advice: "Skip Experiment 1".
I went to the front and explained to the class exactly that. I told them what happened to me earlier. What I initially thought to be a software-related problem turned out to be with the hardware, specifically, with the probe that was connected to the function gen. I enumerated to them the all the possible causes of errors and told them that this would be a good experiment if the instruments we have are uniform. But they aren't. So, much to their relief (and mine as well), I canceled Experiment 1. Before I dismissed the class, I demonstrated the process of adjusting the function generator's settings and I showed all who are interested the output.
Experiment 2: This turned out to be a whole lot easier. Purely software. Even if the experiment numbered 30 pages in all, all the students have to do is to just drag the icons onto a workspace and make the necessary connections and a few minor adjustments to correctly display the outputs. Above all these, the steps are all listed down on the manual. I have yet to let any of the two classes perform this one though but it took me a little less than two hours to finish everything. That is, without sleep the night before and falling asleep in front of the PC from time to time.
I can't wait for the term to be through. Hahaha.
Currently listening to: Jamiroquai
Currently reading: Nothing
Currently feeling: still okay. Wow.