The shirt this year has a couple of differences from previous years’ shirts:

The slug now as a beard, at the request of the class.

The shirt is exclusive to the class this year, with “I survived” added at the beginning of the text, again at the request of the class. In previous years I was willing to let anyone buy a shirt, to lower the prices for the students in the class, by amortizing the setup fees.

I’m also dealing with a different T-shirt company this year, at the suggestion of one of the students. I’m using BroPrints, a Santa Cruz company since 1994 (or 2000, depending on whether you count the start of the business or their opening a storefront). Their prices are considerably lower than The Print Gallery, who I used last year. I’m hoping the quality is good (the student who recommended them said that she had used them for several different orders and had good durability of the printing). I stopped using Sports Design after two sets of shirts (one in 2011 and one in 2014) had bad cracking of the printing, and an order was miscounted in 2014.

Broprints has lower setup fees and lower per-shirt charges than the other companies I’ve dealt with, and the order is a little larger this year (35 shirts), so the per-shirt price should be the lowest yet (about $12 a shirt, and $15 for long sleeve).

I’ve now got the slug design as an SVG file as a master, but what I communicate to the printer is a layered Photoshop file (created with Photoshop Elements from an Inkscape png output), with each silk screen mask on a separate layer. The SVG file is only 85,868 bytes, while the layered Photoshop file is 11,075,976 bytes. Obviously the vector format of the SVG file is going to be smaller than a 600dpi raster image, but I’ve found that T-shirt companies can’t deal with Inkscape-created SVG files—especially not when I use non-standard fonts like Optima. The photoshop file is quite inefficiently stored even for a raster image, as a PNG file with essentially the same information (except for splitting the different colors into different layers) created by Photoshop Elements is only 201,677 bytes.

Today was the last day of the Applied Circuits class, and the students were turning in their 10th lab report. It’s all over but the grading (though I expect a few more redone assignments to be turned in on Monday).

Today’s class started with my explaining a bug that was just found in the PteroDAQ code.

Symptoms: On the EKG assignment a number of students ran into trouble in the lab with the PteroDAQ software suddenly switching from normal recording to a sawtooth waveform, then spontaneously switching back after a while. When plotting the saved data with gnuplot, the timestamps were all messed up in the part of the recording where the sparkline had displayed a sawtooth waveform, but returned to normal when the sparkline did. We had never seen this behavior on the Macs, nor had we seen it previously on the Windows machines. The one new thing in this lab is that we were using a higher sampling rate on the Windows machines than we had previously used.

Diagnosis 1: The sawtooth waveform suggested to me that the low-order part of the timestamp was being taken as the signal, and the disordered timestamps as intrusion of the data into the timestamp. I suspected that the old, slow Windows machines were not able to keep up with the USB serial traffic, and that they were losing a byte and getting a framing error.

I suggested this diagnosis to my son, but he showed me the framing character and checksum used to detect malformed packets, and pointed out that even if a malformed packed passed the checksum, synchronization would be re-established within a packet or two. Although the behavior certainly looks like a framing error, the packets should not go out of frame consistently.

Today, after watching the Shakespeare To Go 50-minute production of Hamlet with me, my son accompanied me to the lab to observe the behavior for himself. We got the behavior very quickly with a 300Hz sampling rate, and the error message for a checksum failure was not printed. He added a print statement in the code where the data packets were getting their checksums checked, so that we could see what data was coming in. We looked at the transition from good behavior to bad, and noted that the packets were still the right length, but the information in the packet seemed to have been shifted. So there seemed to be a framing error, but not in the USB communication.

Diagnosis 2: This shift indicated that the problem was in the software running on the KL25Z board, rather than in the software running on the Windows host. The packets to be sent out the USB serial port are stored in a queue in the KL25Z, and I conjectured that the queue was overflowing. Since a circular buffer is used for the queue, writing when the queue is full would overwrite data for a different packet. Because the queue length in bytes was not a multiple of the size of the items on the queue, this overwriting would be out of phase, and we would observe periodic switching between in-frame and out-of-frame packets, which is what we were observing.

We checked the code, and found that the test for sufficient room in the buffer for another packet had not been included in the routine for adding a new event to the queue. The code to check the remaining space had been written, but not not used yet. A fifteen-minute bug fix, while I went to my office to get my materials for my class, confirmed that this had indeed been the problem. He will be pushing the fix to https://bitbucket.org/abe_k/pterodaq this evening. The fix consists of discarding any event for which there is insufficient room in the queue. Some loss of data is unavoidable when the queue fills up, and this delays the loss as much as possible, as well as minimizing how many events are discarded. Since the events are timestamped, losing an event will often have little or no consequence for downstream analysis or plotting.

The first part of the class was explaining the bug to the students, which I had to do in a rather handwavy fashion, since most of the class has not had programming, much less queues and circular buffers.

We then talked about a variety of different things: deadlines for redos, when the t-shirts would be available, instructor feedback forms to fill out online, differences between bioengineering programs at the various UCs, what the job market was like for bioengineers, and other general advising sorts of things. I also reviewed some of the goals of the course in terms of engineering thinking, tinkering vs. engineering by design, the usefulness of models that aren’t perfectly accurate, trying to switch them from answer-getting to keeping in mind the meaning of what they were doing, sanity checks, methodical work and lab notebooks records, and that the real world trumps any models (“try it and see!”).

Incidentally, this year’s t-shirts have that motto on the shirts:

2014 Applied Circuits t-shirt has the design only on the front, and has the class slogan above the cyberslug. (Click for high resolution image)

When the students finally ran out of questions, I had about 10 minutes left, so I introduced them to the Wien-bridge oscillator, first by reminding them of the bridge-null condition (which them almost remembered from the quiz it had been on), then deriving that and . I even had time to tell them about how the amplitude of the original oscillators was regulated by having a light bulb as a non-linear resistor in place of R1.

After class I attempted to help one of the students get PteroDAQ working with his laptop, but we got as far as determining that the drivers were missing for the USB serial device on the KL25Z board, and that the Windows 7 driver installation did not fix the problem before he had to go to another class. My son and I will have to look for Windows 8 driver initialization that will set things up properly for the KL25Z board—this might be tricky as we have no access to a Windows 8 machine to test putative solutions on.

2013 March 20

Back of T-shirt. The silkscreen is intended as a white silkscreen over a black T-shirt.

Because the applied circuits course did not have a final exam, the students asked if we could get together at a bar for a beer during the exam time instead (which my son quipped should be considered a “bar exam”). Because we had some underage students in the class, I chose Caffe Pergolesi as a site (they serve beer but also coffee, hot chocolate, and coffee-house snacks). The café was surprisingly crowded for 4 p.m. on a Tuesday (probably due to it being the first day of exam week), and I had to sit out on the deck, because there were no tables available inside. At first I was a bit worried that no one would show up (a common problem for parties I’ve tried to have in the past, so I’ve stopped attempting to have parties), especially when no one was there by 4:10. But the students started trickling in and we eventually had all the students in the class—even those who had sent e-mail saying they couldn’t make it.

I showed the students the T-shirt design, modified according to their suggestions the day before, and they approved it. I still need to check with the screen printer that the SVG files I have will work—I think that the back is ok (it is a single black rectangle for the T-shirt with a single path for the white layer on top), but I’m worried about the front. The text, slug, and small thought bubbles should be fine, but the black images on the large thought bubble are currently objects on top of the white thought bubble, and I’ve not figured out how to get Inkscape to make them cuts through the thought bubble to the black T-shirt underneath. The Inkscape “path difference” operation, which worked for the back of the T-shirt doesn’t do the right thing with these images. So far I’ve gotten 7 orders for T-shirts from the class (including one for me and one for my son), and I’m hoping for another 5 or 6 to amortize the setup costs. I think that we’ll have about $90 in setup plus $12/shirt, so 7 shirts would be about $25 each and 12 shirts would be about $20 each (long sleeve shirts a couple of bucks more).

I used the time to get feedback from the class about how it should be modified in future, starting from a handout I’d given them the day before. Here are some of my notes from the discussion. If I’ve missed anything, I hope that students will send me e-mail.

Parts and tools to add: inductor for class D amplifier, soldering iron. A soldering station like the one I have (and similar to the ones they used in the lab this year) would add $20 to the cost of the course.

It may be worthwhile upgrading the screwdriver set, as the under $2 set was really low-quality and some of the screwdrivers failed (blade slipped in handle, so that screwdriver did not turn with handle).

I had been worried about the high price for the large assortment of resistors ($13.35 for 1120 resistors, 10 each of 112 sizes), but the students liked that they always had whatever resistor size they needed, and were contemptuous of the approach used in EE101 of providing students with only about 20 resistors of the precise sizes that the faculty had decided the students would use.

One student suggested having a protoboard for designing the class D amplifier, since that is something they might want to keep. I’ll have to think about that, as it doesn’t strike me as an immediate win, though I can see wanting to keep the power amplifier. One problem is that the class-D amplifier is not as generic a project as the instrumentation amplifiers, so it is harder to come up with a general-purpose protoboard. Also, most students ended up having to do a lot of experimenting to get the biasing to work out for the power FETs, which could be difficult on a PC board. The class-D amplifier also needs a bit more space than the two instrumentation amp projects, so a PC board for it would have to be bigger ($2/board instead of $1/board). Having the same protoboard for both the pressure-sensor lab and the EKG lab meant that time spent learning how to use the protoboard was amortized over two projects, which would not be the case for a special-purpose power-amp board.

One student suggested adding a voltmeter for home use, but the problem there is that voltmeters that can read AC voltage correctly for 100kHz signals are mostly in the $100-and-up range. The $5 voltmeters that could be put in a kit for everyone to buy are not useful for some of the labs.

Students suggested that the first quiz should be given as homework instead of a quiz—a good idea, since the questions were too hard for the students as a quiz, and having time to think about them and discuss them with each other would lead to more learning.

The students do not think that adding a textbook to the class would help, but being directed to the All about Circuits readings more often (including the worksheets) might help. They generally found the Wikipedia articles too detailed and too broad to be helpful in learning the material. They got fairly good at at searching the web for keywords and finding lecture powerpoints from other courses that were relevant. No one found a steady source of good material though—the searches tended to find different sources for each topic. The students reported being able to find data sheets fairly easily and consulting them fairly often, so at least one of the goals of the course was met.

One student reported that soldering the instrumentation amp for the pressure sensor lab seemed a bit pointless to some, as they don’t buy the pressure sensors to connect to, so a permanent board is not much use. The benefits (soldering practice and less noise pickup from long wires) may not justify the extra effort of soldering.

We discussed re-ordering the labs, moving the electrode measuring and modeling lab later, and the sampling and aliasing lab earlier. A possible new order is

Thermistor

Sampling and aliasing

Microphone

Audio amp

Hysteresis oscillator

FET and phototransistor

Electrode modeling

Pressure sensor

Class-D power amplifier

EKG

That order could cause some difficulty for the sampling lab, which needs RC filter design (hence complex impedance), so maybe swapping the mic and sampling labs would be better.

We also discussed the idea of having 2 labs a week (both Tuesday and Thursday), with a data analysis day in between (to teach gnuplot scripting and fitting models). None of the students had done model fitting (other than straight lines) in any other course, so this is a skill worth spending a bit more time on in class. Having 2 105-minute labs a week (the standard TTh time slot) would probably not be enough, as that is barely more than the 3-hour lab weekly lab this quarter, and the setup time would probably eliminate any gains. I’d probably have to schedule 2 time slots per lab (say 10–1:45, 2–5:45, or 6–9:45). If the course grows to full size, I would be spending 8–12 hours in the lab on Tuesdays and Thursdays, without break.

If I do have more lab time next year, I could start a little slower, using the first week to have students learn to identify all the parts, mark the capacitor bags with the capacitor sizes, learn to use the ohmmeter and power supplies, … . Some of the later labs would have no more time than this year, but some of them needed no extra time.

Students would like several explanations to come earlier in the course relative to the labs—FETs before the microphone lab, PN junctions and phototransistors before the tinkering lab, block diagrams earlier in the course, … . I agree, and moving the first labs a week later could help with that. I’ll be doing a day-by-day topic planner before resubmitting the course approval paperwork. One problem with teaching block diagrams earlier is that—like outlining in writing—they’re really only useful once the complexity of the design gets high enough that subdividing the problem is useful.

The students were pretty pleased with the data logger software that my son wrote. The biggest complaint was about the logger freezing when recording a long run at high sampling rate (a known problem). I believe that he is developing a fix for that problem, which will generally result in faster live charts. Students also like the idea of being able to produce eps, pdf, png, or svg output directly from the data logger, so that they didn’t feel the need to make screenshots. Providing starter gnuplot scripts (which they could then add to in order to do model fitting) was also attractive to them. There was one request for icon-based executables (avoiding the command line), but I actually prefer for engineering students to have to learn to use command-line tools—I was shocked that they had gotten to their senior year and had not learned how to use command lines.

Students thought that the current prereqs for the course were fine—they did not see a need to add a programming prereq, unless the course was changed in a major way to include Arduino programming (which I’m not tempted to do, as there are already courses on campus covering that). They did think that the course needed to remain an upper-division course, but that sophomores might be able to handle it by the Spring (which is when it will be scheduled in future).

Some students thought that the course could be reduced to 9 labs (from 10)—mainly to reduce the number of reports written. I think that we could achieve that by putting the microphone lab and audio amp lab together and having 3 lab sessions with only one report. We might be able to combine the hysteresis lab and the tinkering (FET and phototransistor) lab into one report also.

The students really liked the undergrad group tutor we had—saying that he was the best TA they’d ever had. I believe that he is graduating this year (as are all the students in the course), so I don’t know whether we’ll be able to get as good an assistant next year.

Students liked having learned gnuplot, though they initially struggled with it and hated it. Once they got past the initial learning, they found it useful for senior theses and courses other than the circuits course.

Overall, students thought that the class had met most of the learning goals I had set for it, and several of them wished the course had been available to them earlier—some of them might even have opted for the bioelectronics track (they were all biomolecular track), had they taken this course early enough (and if EE would accept it as prereq to the other upper-division courses needed for bioelectronics). I’m certainly going to try to convince the EE faculty that this course can serve as more than adequate preparation for courses like signals and systems (better than the existing circuits course).

The students in the class gave me two bottles of wine as a thank-you for the course—that is a first for me in 30 years of being a professor. Most often students are glad to have survived my courses, but don’t generally appreciate them until several years later.

The student appreciation certainly isn’t because I’ve been grading leniently—the class is mostly in the B- to B+ range, and some had to go through 2 or 3 drafts of the lab reports to get to even that level. There may be one or two A- grades (I still have the last 2 lab reports to grade, so I don’t know yet—I’m hopeful, but I’m not going to give out As unless the work justifies them).

I think that the recognized that I was genuinely interested not just in the material but in getting them to do real engineering design and to think like engineers. Several have taken to heart the “try it and see” mantra and have learned to appreciate the value of “sanity checks”. I think that the value of a UC education lies mainly in these high-contact “artisanal” courses, not in the mega-lectures and cookbook labs that they have mostly been suffering through. (To be fair, many of them are working on senior theses in various faculty labs, so they have had high-contact educational experiences—just not structured as a required course.)

Like this:

2011 June 3

Last year I started a “tradition” of designing a T-shirt for one of my classes.
Last year, it was for the Banana Slug Genomics class:

This was the 2010 design. Slug reproduction does involve them curling around each other, but in a planar spiral, not in a helix.

Although I taught the Banana Slug Genomics course again this year, I had few students in it, and I did not want to repeat last year’s shirt. So I designed a shirt for my other class, in which I was teaching about computational protein design. The protein image is an SH3 barrel (PDB id 1jo8A), which we had used as an example in class. It turned out that there were two other courses also doing protein work this quarter: an undergraduate course in protein engineering and the lab part of an undergraduate course in molecular biomechanics. My students did the same lab as the undergrads (but a day earlier). The lab consisted of transfecting E. coli with a plasmid, growing the cells, expressing the protein, lysing the cells, purifying the protein on a cobalt column using the HIS tag, and using SUMO protease to cleave off the HIS and SUMO tag.

We had hoped to be able to get genes synthesized for proteins of our own design, but the 10-week quarter was too short—we did not have any computational plausible designs until about 8 weeks into the quarter.

I’m hoping that enough of the undergrads will like the t-shirt design to amortize the setup charges for the two silk screens needed for the design:

This is the design for this year's t-shirt. I'm taking orders (from people affiliated with the Jack Baskin School of Engineering, since JBSoE has the rights to the cyberslug—for UCSC people the affiliation can be pretty loose) until Monday 6 June 2011.