First lab for Spring

I had a very long day today (as I expect all Tuesdays and Thursdays to be this quarter).  It started out with me in a panic, because I had gotten a message late yesterday afternoon, telling me that the parts kits for the course were not ready yet, but not telling me what was available, so I didn’t know whether I’d be able to run today’s lab or not. I thought I probably would be able to do the essential parts, because the main part of the lab was soldering headers onto the KL25Z boards, and the boards and headers were ordered from Digi-key, which has very fast delivery (thanks to their almost instant packing of parts for shipping and their using the post office rather than FedEx, which has been unbelievably slow this year).

I went into work a bit early this morning to check on what parts were available (after a night of thinking about what labs I could do if the KL25Z boards were not available—pretty much only the thermistor lab scheduled for next Tuesday, and that takes about an hour of setup to prepare the lab and have hot water and ice water available).  As it turns out, the person who had informed me of the incomplete parts list had sent out a spread sheet with the information—he’d just forgotten to CC me on it. The KL25Z boards, the headers, and the USB cables were all available, so we could do the main part of the lab.  We couldn’t do the unpacking of the parts kit and identifying parts, but that can happen later, as the parts come in.

For Thursday’s lab, it would be good if they had their breadboards, resistor kits, and electrolytic capacitors—but I don’t know whether those will all be ready by then (the resistor kits haven’t all arrived yet).

Once the boards arrived, I started part of the class soldering (we only had 6 soldering stations, two of which were not very functional, despite my request 2 years ago for enough soldering irons for the 12 benches).  While some were soldering, the rest were downloading the PteroDAQ software and trying to get it to work on their machines.

The soldering went well, with one serious exception.  One student soldered in the connectors on the wrong side of the board, and neither the group tutor nor I noticed in time (and we could have, because we had looked at the board and just not noticed). We helped remove the connectors (removing a 2×10 female header from a board is a lot of work), but the student did not have enough time to get all the connectors replaced by the end of lab.  The tutor will provide some supervision at another time before Thursday’s lab to finish up.  All the solder joints looked clean—I saw neither bridges nor voids.  I did send several students back (more than once) to reheat cold-solder joints, but in the end all the students had good connections.  Since only 2 or 3 of the 32 students had ever held a soldering iron before, I think that getting each to make 64 good solder connections is a pretty positive outcome.  They’ll have 3 more labs this quarter where they will have to solder (their own designs, not just headers), but I think that they’ll approach those labs with more confidence now.

The PteroDAQ downloads were not quite as successful.  I think that everyone managed to get the MBED.ORG download software installed, and transferred the daq_kl25z.bin executables to the KL25Z boards. Most (all?) got PteroDAQ working with the lab computers. But few, it any got PteroDAQ working on their own machines.  There were three classes of problems:

• On Windows 7 machines, I forgot how to use the mbed-usb-windows.inf files to install Windows drivers for the USB port on the KL25Z board. I looked it up after class before going home and found a page about installing Windows drivers for Arduino boards that seems to have all the right instructions (but use the .inf file in the PteroDAQ extras directory, not arduino.inf): http://arduino.cc/en/guide/windows#toc4
• On Windows 8 machines, I don’t know whether the same approach will work, but I hope that some of the students will try. The approach given in the MBED handbook did not seem to work, but I’m not very comfortable with Windows, so I may have missed something obvious to a serious Windows user.
• On Mac OX 10 machines, we had two problems:
  1. OS 10.10, 10.10.1, and 10.10.2 were not willing to write to the MBED device. This seems to be a known problem that the MBED user community is pretty upset about. The MBED developers have been working (slowly) on the bug since last October, with patches for only a few of their many supported boards (not, so far as I can see, the KL25Z).  There are claims on the developer forum about the bug that OS X 10.10.3 beta finally fixes the bug, but no one in their right mind would suggest that students install Apple beta code on a machine that they plan to use for anything. A student was going to enter an “issue” ticket on the PteroDAQ website, but it doesn’t seem to be there yet.
  2. If the Windows 7 machines in the lab were used to put the daq_kl25z.bin onto the boards, then OS 10.10 seemed to work ok (a student got it running), but OS 10.10.1 and 10.10.2 machines failed.  The problem seemed to be with Tkinter: the selection of the port for the KL25Z was not sticky—it deselected itself within a second of being selected. Some of the students had freshly downloaded versions of Python 3.4, so the problem doesn’t seem to be with old code, though I suppose a Tcl/Tk incompatibility with Python is possible—I didn’t have any of the students try re-installing Tcl.  I hope that a student with an OS 10.10.1 or 10.10.2 machine will post an issue ticket about this issue on the PteroDAQ website also.

  I’m now very glad that I did not “upgrade” my old OS 10.6.8 Mac to 10.10 on my 2009 MacBook Pro—it seems that I would have broken many of the things that I rely on my Mac for. Perhaps I’ll wait until I get new a new laptop before “upgrading”—and I won’t buy a new Apple as long as they don’t work with MBED, even though my current laptop has a very sick battery and is beginning to show its age. (I have no intention of buying a MacBook with only one USB-C port, either: I routinely use the power cable, the ethernet port, the firewire port, the display port, both USB ports, and the SD card port, and often use three or four of these at once.)

It would be really nice to have installation instructions with PteroDAQ—I forgot some steps of how to do the installation on Windows (the driver installation), and it would be nice to have a written description of the steps for a Mac that I could just point students to, rather than walking them through it.

I set up a mailing list for the class this evening, and I hope that students who manage to get PteroDAQ working on Windows 8 or OS 10.10.1 or 10.10.2 will share the information.

Third weight-loss progress report

In 2015 New Year’s resolution , I said that I want to lose 10–15 pounds by June 2015. In Weight-loss progress report and Second weight-loss progress report, I provided a monthly updates.

For March, I continued the same diet and exercise as in January and February, except for March 20–29, when I had Spring “break” (a huge pile of grading, rewriting the book for my applied electronics class, and other administrative and course preparation tasks).  I wasn’t cycling up to campus everyday, so my average exercise dropped to 4.31 miles/day of bicycling. Also, my son, a freshman at UCSB, had his Spring break at the same time, and so came home for the break.  Because he is very thin (as I was at a corresponding age), his mother served a number of comfort foods while he was here, to encourage hearty eating.  So I put on a little weight and am trying to lose it again.

A simple linear extrapolation would have me reaching the upper end of my target range by 2015 Apr 23, but an exponential decay predicts that I won’t reach it until June 13.

I am at the lowest weight I’ve been since I bought the scale in 2011 and started recording my weight.  Although I was losing 1.24 lbs/week in January and 0.74 lbs/week in February, I only lost 0.52 lbs/week in March.  Because of this progressive slowdown, I fit an exponential decay to my weight loss, as well as the simpler linear fit.  The exponential predicts an eventual minimum weight of 157 lbs with a decay time constant of 89 days. This asymptotic weight is comfortably within my target range—but if the exponential holds up, then it will take me longer than I had originally expected even to get within my target range.

During break I had a checkup with my physician, who thinks my target weight range is fine, but she’d be happy even if I just managed to maintain my current weight. Interestingly, my cholesterol was at the lowest level since I’ve had it measured (starting in 1989), and the desirable HDL was actually up.  Unfortunately, I did not check the cholesterol levels before starting my diet, so I don’t know whether the low levels are due to the diet or to the rather high levels of atorvastatin (60mg/day) that I’ve been taking for the past 2 years.  In any case, I’m cutting back to 40mg of atorvastatin a day, and I will check my cholesterol levels again over the summer.

 

First day of S15 circuits class: demo failure

I went into the class with a fairly short to-do list—much shorter than last year’s. I managed to cover the following:

1. Went over syllabus .✔I showed them the syllabus and managed to go over scheduling of labs, partner work, and online texts, but did not get to some of the boilerplate about cheating and about disability services. ✘ Oh well, it is enough that the boilerplate is on the syllabus.
2. Demoed pressure sensor ✘ with PteroDAQ on KL25Z board. I hooked everything up and it didn’t work. I fixed one problem of a loose wire (using the jeweler’s screwdriver, but it still didn’t work. I did manage to show them PteroDAQ and used gnuplot to show them a pressure trace I had recorded in the BME88A demo last quarter.
3. Reading the book and doing design well before lab.
4. Assigning reading due tomorrow and Thursday.
5. Partners changing every week, so no one gets a free ride for very long and no one has to suffer with a freeloader.

I was thinking that I’d use the chalkboard a lot, so I used the small screen in the classroom (this classroom is ridiculously over-equipped with projectors, even having a project for a screen at the back of the classroom) rather than the big one, which covers most of the chalkboard. But I ended up using the projector to show them parts of the book and to use the document camera to show the KL25Z board and instrumentation amp protoboard, and barely used the chalkboard at all.

The rearrangement of the labs, with soldering on Tuesday, sampling and aliasing on Thursday, and the thermistor labs next week does give me a little leisurely start-up than last year, as I don’t have to get to Ohm’s law and Kirchhoff’s current law until the voltage-divider lecture on Friday.

Overall, I’m fairly happy with how the first day of class went, despite the demo failure.  I’ll debug the demo and show them either in lab tomorrow or in class on Wednesday.  I just hope I haven’t fried the instrumentation amplifier with static—they’re expensive and I don’t know whether I have any spares on hand.

Update 2015-Mar-30 17:58:  When I got home I checked out the board to figure out what might be wrong.  After probing for a while with the voltmeter, I determined that the wire that had come loose from its screw terminal and that I had fixed in class was not the only wire that had come loose.  The one next to it had also come loose.  It still looked ok, but wasn’t making contact.  Opening the screw terminal, reinserting the wire, and tightening it down again fixed the problem.

 

Ideas about vibration detection

Yesterday, my son and I were looking at the “Quantum Bit” toys sold by ThinkGeek.  These are LED lights with plastic cases that flash briefly then fade after a second or so.  We tried reverse-engineering them from what we could see through the clear cases, then building the electronics to see if we got it right.

A rather blurry closeup of the “quantum bit” toy. The two white LEDs are triggered by the vibration switch in the middle. There are two coin cells on the back of the PC board to power the device. In addition to the vibration switch, the electronics seem to consist of 2 capacitors, 3 resistors, and a transistor.

The key to the device is a vibration switch that consists of a spring coiled around, but not touching, a metal wire.  Shaking the device causes the spring to move around and touch the wire briefly. Those brief contacts are turned into longer pulses by the electronics.

This cutaway image, copied from http://www.adafruit.com/images/970×728/1767-02.jpg , shows the working part of a typical vibration switch.

The first thing I did was to look at the flashes with a phototransistor, a 1kΩ resistor, and an oscilloscope (because I happened to have a phototransistor wired up from a previous project). I could see very rapid turn-on for the LEDs (faster than the response time of the phototransistor circuit), followed by moderate-speed exponential decay, followed by a slower, very dim fade:

This 50ms/division, 2V/division trace shows a couple of bounces of the contact, followed by the exponential delay. It took me several tries to get a clean single hit like this—most often I got a series of decaying pulses, as the spring bounced back and forth and made multiple contacts.

From the decay curve, I estimated a decay time constant of about 28msec initially, slowing down as voltage dropped. We guessed that the circuit consisted of a couple of capacitors connected by the vibration switch: one slowly charged by the coin-cell batteries in the device, the other rapidly charged from the first when the vibration switch makes contact, then slowly discharged through a resistor and the base-emitter junction of an NPN transistor. We guessed which resistor was the one that produced the decay, and (with some struggle through the distorting plastic casing) read its value as 3.3kΩ. That gave us a capacitance around 8µF (other measurements of the decay got different time estimates, so we guess that the capacitor is 4.7µF or 10µF, those being popular sizes for ceramic capacitors).

The other two resistors are 22Ω and are probably series resistors to limit current through the LEDs (that is probably not necessary, given the high internal resistance of the batteries).

We tried duplicating the circuit using a different LED and a pushbutton in place of the vibration switch:

The resistor R1 limits the current through the LED and also sets the charging time for C1—it approximates the internal resistance of a pair of coin cells. C2 and R2 provide RC decay (down to the threshold voltage for the base-emitter junction). Once the voltage has decayed enough, the base current is limited by the characteristics of the transistor rather than resistor, and the decay slows way down.

This circuit worked fine and gave flashes of light that lasted about the same amount of time as the original device. I tried reducing R1 to 50Ω to get brighter flashes with the green and blue LEDs of an RGB LED, and the flash and fade looked a lot like the white LEDs of the toy.

While we were looking at vibration switches, we decided to redesign the SparkFun “Wake on Shake” device, which uses an ATtiny2313A microprocessor and an ADXL362 accelerometer to control a  pFET.  The idea is that the microprocessor samples the acceleration occasionally and turns on the pFET for 5 seconds.  They claim that the device takes only 2µA at 3.7V, which seems almost reasonable, since the ADP60-3.3 regulator takes 1µA, the ATtiny takes 2µA (assuming the microproccesor is powered down without a watchdog timer, woken by the ADXL362), and the ADXL362 takes 0.27µA when in motion-triggered wake-up mode.  But using microprocessors and accelerometers for this task seems like overkill—the whole thing should be doable by a vibration switch and a few analog parts, at considerably lower cost.

We set out to do a design with a somewhat wider voltage range and lower power budget (say 1.8V–5.5V and only 1µA) controlling a beefier pFET (lower on-resistance) at a lower parts cost. The design of the LED flashing circuit won’t work for us, because we want the pFET either to be all the way on or all the way off—not heating up in the linear region.  The switch and RC circuit are fine, but we can’t read the RC delay with just an NPN transistor—it doesn’t provide a sharp transition.  Instead we chose a low-power comparator, the TS881, which can operate on less than 400nA and that has a supply voltage range of 0.85V to 5.5V. Initially, I just planned to use the output of the comparator to drive the pFET gate directly, but my son wanted to add the capability to have an external active-high “wake” signal that kept the output on, and that turned off quickly (not with the 5-second delay) when removed (possibly under the control of the circuit that normally gets 5 seconds of power, so that it can keeps its power on until it is done).  To add this extra functionality, we put in another stage between the comparators and the pFET:

After C1 is charged by the vibration switch, it discharges through R1. The comparator output is high as long as the voltage on C1 is more than 1/3 of the supply voltage, which turns on Q2, which then turns on the pFET.

The pFET was chosen to have a very low threshold voltage (so it could be turned on even with low-voltage supplies—the pFET threshold is the main limitation on how low the voltage can go) and a low ON-resistance, so that moderately high currents could be handled. With a minimal pad layout, I calculated that the pFET could handle about 2A. With 2oz copper and a square inch of board space on the back as a heat sink, perhaps 4A. Note: if the pFET is used to power anything with significant current, one would want a much larger bypass capacitor than the 4.7µF shown here—something like a low ESR aluminum-polymer electrolytic capacitor with over 100µF of capacitance.

The NPN transistors were chosen to be a cheap pair in a single package (reducing assembly cost slightly).

The timing capacitor was chosen to be a film capacitor, to get better precision on the capacitance and less temperature dependence. Unfortunately, this limits the amount of capacitance, unless a large through-hole capacitor is used. That in turn requires a large resistor to get the RC time constant, which puts strong constraints on how much leakage current is permitted on anything connected to the charged node.  If the 5-second on-time can be allowed a large fluctuation in duration, then C1 could be a 10µF ceramic capacitor and R1 a 470kΩ resistor, but the bypass capacitor on the other side of the switch would have to be made much larger, to ensure that C1 is fully charged in the momentary contact of the vibration switch.

The voltage divider takes up to 5.5V/20MΩ (183nA), the comparator up to 750nA, and the leakage through the NPN transistors when off about 20nA each, and about 300nA leakage through the pFET for a power budget of about 1.3µA when the circuit is not activated (SparkFun hadn’t counted the pFET leakage, and adding that to our power budget put us over our arbitrary 1µA limit). We originally had nFETs instead of NPN transistors for the comparator output and WAKE inputs, but think that they would leak more current in the presence of noise on the WAKE line. The pullup resistor adds up to 2.5mA of current when the pFET is turned on, which is probably a bad thing if the load is small.

If you don’t need the functionality of the WAKE line to hold the circuit on, a simpler circuit will do, without the power consumption of the pullup resistors:

Without the need for “wake” functionality, the extra OR-stage of bipolar transistors can be eliminated, if the inputs of the comparator are swapped.

If the WAKE function is supposed to do the same thing as shaking (providing about a 5-second ON time, rather than turning off quickly), then the bare circuit above can be made to have the WAKE function:

Here an nFET is put in parallel with the vibration switch, so that the WAKE signal has the same effect as vibration. My one concern is that the leakage currents through the source of the nFET will make the RC decay computation wrong—both drain-source and gate-source leakage currents could be a problem. Unfortunately , these are specified on data sheets at quite different operating conditions than we have here. One could also use an optoisolator in place of the nFET, but the dark current may be enough to charge the capacitor.

Warning: none of the Shake’n’Wake circuits here have been tested (only the LED flashing circuits)—this is all paper design. I think that everything here should work (except the nFET for WAKE in the last schematic, which I suspect has too much leakage current), but it has not been built and tested. Long experience leads me not to trust paper designs, so I recommend that you not rely on these designs, until you have prototyped and tested them. I probably won’t bother to, as most of the parts are surface-mount parts, and so a bit of a pain to work with.

Bogus comparison of Word and LaTeX

An article was recently brought to my attention that claimed to compare LaTeX to Word for preparing manuscripts: PLOS ONE: An Efficiency Comparison of Document Preparation Systems Used in Academic Research and Development. The authors claim,

To assist the research community, we report a software usability study in which 40 researchers across different disciplines prepared scholarly texts with either Microsoft Word or LaTeX. The probe texts included simple continuous text, text with tables and subheadings, and complex text with several mathematical equations. We show that LaTeX users were slower than Word users, wrote less text in the same amount of time, and produced more typesetting, orthographical, grammatical, and formatting errors.

It turns out to be a completely bogus study—they compared typist or typesetting tasks, not authoring tasks. There was no inserting new figures or equations into the middle of a draft, no rearranging sections, no changing citations styles—not even any writing—just copying text from an existing typeset document. It is very misleading to say that the “LaTeX users … wrote less text”, as none of the subjects were writing, just copying, which uses a very different set of skills.

I don’t think that there is much question that for simply retyping an existing document, a WYSIWYG editor like Word is better than a document compiler like LaTeX, but that has very little to do with the tasks of an author. (And even they noted that the LaTeX users enjoyed the task more than the Word users.)

For those of us who use LaTeX on a regular basis, the benefits do not come from speeding up our typing—LaTeX is a bit slower to work with than a WYSIWYG editor.  The advantages come from things like automatic renumbering of figures and references to them, floating figures that don’t require manual placement (except when there are too many figures—then having to do manual placement with LaTeX is a pain), good math handling, automatic formatting of section and chapter headings, being able to define macros for commonly used actions, and the versatility of having a programming language available. For example, I have a macro that I like to use for proper formatting of conditional probability expressions, and another that I use for references to sections, so that I can switch between “Section 3.2”, “Sec. 3.2”, and “§3.2” through an entire book with a change to just one line in the file.

LaTeX also has the advantage of having a much longer life span than Word—I can still run 30-year-old LaTeX files and print them, and I expect that the files I create now will still be usable in 30 years (if anyone still cares), while Word files become unusable in only 10-to-20 years.  LaTeX is also free and runs on almost any computer (the original TeX was written for machines that by modern standards were really tiny—64k bytes of RAM).

For those who want multiple-author simultaneous access (like Google Docs), there are web services like sharelatex.com that permit multiple authors to edit a LaTeX document simultaneously. I’ve used sharelatex.com with a co-author, and found it to be fairly effective, though the server behind the rendering is ridiculously slow—40 seconds for  a 10-page document on the web service, while I can compile my whole 217-page textbook three times in about 12 seconds on my 2009 MacBook Pro.

Like the emacs vs. vi wars, the LaTeX vs. Word camps are more about what people are used to and what culture they identify with than the actual advantages and disadvantages of the different tools. Bogus studies like the one in PLoS One don’t really serve any positive function (unless you happen to be a monopoly software seller like Microsoft).