2016 March 31

PteroDAQ bug fixes

I spent much of my lunch break today using a laptop borrowed from a student in the Applied Electronics course to debug a problem in PteroDAQ (one that I thought I had fixed on 2016 Feb 6 and again on 2016 March 30).

The problem was that on newer versions of Mac OS X, our original way for finding the serial ports and listing them in PteroDAQ (with good names) was failing, and the serial ports weren’t appearing. I fixed it for Mac 10.11.3, but that fix was breaking for most of the students in the course. Yesterday, a student who is a friend of a student in the class suggested that the problem was just that I was only looking for USB 2 ports, and that the new USB stack used different data types for USB 3 ports.

Since I did not have any hardware with USB 3 ports (yes, I hang onto my computers for a while—the machine I’m typing this on is a MacBook Pro bought in mid-2009), I was unable to test the fix, so I released it to the class and asked them to test it. A few students reported it working, but in the lab this morning, several students with Mac OS X computers were still unable to use PteroDAQ. It was clearly a USB 2 vs. USB 3 problem still, since they were able to use PteroDAQ if they connected using my cable that has a USB 2 hub in it. One other student had gotten PteroDAQ to work for her by using a USB 2 hub that she had bought just for the purpose (probably a $7 or $8 one from Staples).

So instead of eating my lunch of raw vegetables, I sat with one of the laptops that was failing, uncommented some debug print statements that I had left in the code (I don’t delete debugging statements—I just comment them out, precisely for this sort of later bug fixing), and looked at the data structure for that Mac. Apparently there are many different USB stacks for Mac OS X, with all sorts of differences. I put together ways of finding the appropriate name for the serial port using as many different methods as I could think of, based on either the child or the parent of the object in the chain that had the name I wanted.

After it was working on his computer, I handed it back to him and redid the bug fixes on my laptop and pushed them back to the bitbucket site, asking students to test the new code. So far, everyone who has tested it has gotten it working (except for one student who seems to have a fried Teensy LC board—we were not able to get even the Arduino environment on my Mac to see his board). We don’t have any spare Teensy boards, so I suggested he order one from PJRC with the male headers already soldered on. That makes two students (out of 48) who have had to order replacement boards (the other one soldered the male headers on the wrong side of the board, and delaminated some of the pads in attempting to correct the problem). Perhaps next year we should order an extra 5% of Teensy LC boards, to cover for this sort of problem and have a local source for replacement boards.

I managed to finally finish my lunch after lab ended (around 5:30pm), but I’m glad to have gotten PteroDAQ working for (almost) everyone. It is now 10pm, and time for me to prepare for tomorrow’s lecture.