# Gas station without pumps

## 2020 January 11

### First week of class W2020

Filed under: Circuits course — gasstationwithoutpumps @ 21:16
Tags: , , , , , ,

I’ve just finished the first week of class for BME 51A (Applied Electronics for Bioengineers), and it has been a rather hectic week.

First, I had about 5 people sign up for the class at the last minute (from 56 to 61), which drove the BELS staff to having to do a lot of expensive last-minute purchasing of additional items for the parts kits.  It also meant that when we handed out the parts kits on Tuesday, several of them were incomplete and so more items had to be handed out during the Thursday lab period.  Since getting their kits, 2 students have dropped taking us down to 59, and one other has told me that they might drop (assuming that they can get a coherent plan together for an independent study to replace the course).  This enrollment is less than last year’s 82 students, but still a fairly large number, given that the BELS labs can only accommodate about 24 students.  I’m using two lab rooms for the first section and one for the second section, and have hired 3 group tutors (one for each lab room and time) to work along with me in the labs.

The first week’s labs consist of soldering headers onto the Teensy LC boards and installing software: Python with SciPy (using the Anaconda install), gnuplot, Arduino+Teensyduino, PteroDAQ.  For the first time in years, everyone got their soldering done within the allotted lab times!  I don’t know what was different this year that made it work as it was supposed to.  One thing that helped a little was that when students soldered the male headers on the wrong side of the boards (which happens every year, despite all the written, pictorial, and verbal warnings I can give), I had them cut apart the male headers to unsolder, then gave them new male headers to solder on.

Software installation is always a problem, because students are attempting to install on a variety of platforms, and something is always incompatible. Here are some problems that came up this year:

• Gnuplot on old Mac OS X systems would not install with homebrew, as qt could not be installed—it insisted that you needed the full Xcode (not just the command-line subset), but Apple will not provide the full Xcode for such old, unsupported systems.  There may be already compiled versions of gnuplot for these old systems, but I have not gone looking for them. I’m not sure what to recommend to these students, other than updating to a system that Apple still supports.  I can’t recommend updating to Catalina, as they will lose all 32-bit apps, some of which will never be ported to newer versions of macos (for example, I lost access to Finale Notepad, which is no longer available on Macs—probably because Apple makes it so very difficult for third-party software developers to maintain their code).
• Gnuplot on new Mac OS X systems installs and runs, but produces bad PDF files.  The workaround for this was posted at https://stackoverflow.com/questions/57698204/gnuplot-pdf-terminal-exhibits-font-issues-on-mac. The answer to that stackoverflow question had two lines to fix the problem:
brew uninstall --ignore-dependencies pango
brew install iltommi/brews/pango


The problem is that the default homebrew “bottle” for gnuplot points to a broken version of pango, and you have to remove that version and install an older version.  This one I knew about, because it had bitten me when I was trying to finish the book in December.

• The standard Arduino+Teensyduino installation fails on macos Catalina (10.15). I knew about this one also, as I had tested the PteroDAQ install after I had “upgraded” to Catalina (which broke nearly everything).  The workaround is a beta release of Teensyduino (currently https://forum.pjrc.com/threads/59030-Teensyduino-1-49-Beta-5), which is pointed to from the Teensyduino installation page, but many of the students with macos Catalina did not notice the pointer.  One nice feature of the Teensyduino beta release is that it includes the Arduino IDE, so that you don’t need to install Arduino first.
• The PteroDAQ GUI seems to be crashing on macos Mojave (10.14)—logging the user out when they try to run “python daq” as usual.  I think that this may be a weird filesystem thing, as it seemed to make a difference whether PteroDAQ had been cloned from GitHub or downloaded as a zip file, and whether the files were on the hard drive or on a Google Drive.  The only thing that seemed to work consistently was to clone the files from GitHub onto the hard drive of the laptop, then run the app that is in pterodaq/extras/maclauncher/ .  Why the launcher app works, when invoking “python daq” directly from a terminal results in logging the user out, is a mystery to me.
• On macos Catalina, PteroDAQ can’t find the board if it is connected to the laptop through a USB2 hub connected to a USB3 port (I ran into this problem on my laptop before classes started also).  Apple has once again scrambled their USB stack, and USB Serial no longer seems to be visible through a USB2 hub (though the USB device is visible, the serial interface does not seem to be).  This hasn’t caused a problem for any students yet, as direct connection to a USB3 port works ok, and connection from hubs on USBC ports seems to be ok (probably because they are USB3 and not USB2).
• One student had trouble getting PteroDAQ to run on his Windows 8 machine, with the python program crashing on trying to access the list of ports.  No one else with Windows 8 was having trouble, and his machine was running extremely slowly (slower even than the ancient “Barbie” laptop that I used for testing Windows implementations of PteroDAQ), so I suspect he was having hardware or malware problems on his machine.

I think that nearly all the students got their software installed—at any rate, people left the lab early on Thursday and were not queuing up for installation help, as they had in previous years.  Only one student asked for installation help during Friday office hours (the one with the probably bad hardware or malware), and there were no requests on Piazza for help.  If I’m right that everyone got things installed, then we are well ahead of previous years.

On Thursday, before lab, one of the group tutors ran a tutorial session on $\LaTeX$, which about half the class attended.  That should help somewhat in the prelabs to be turned in on Monday.

Monday’s assignments will be stressing our grading system a bit, as we have a lot coming in, but I couldn’t schedule a grading session until Wednesday at noon.  I’m hoping that we can get both homework 3 and the first prelab graded before Thursday’s lab.  If necessary, we can just give a turned-in/not-turned-in grade for the first prelab, as they are turning in a more complete draft of the same prelab on Friday, but I’d much rather give them feedback so that they can correct mistakes before the Friday draft.

So far, the quiz and homework scores look pretty good, so I’m hopeful that this will be a high-performing class this year.  It would be really nice to give out more B+ (and even A-) grades and fewer C grades.  I’m keeping my fingers crossed (even though that makes typing the blog post hard).

## 2017 June 25

### Fidget spinners revisited

Filed under: Uncategorized — gasstationwithoutpumps @ 17:55
Tags: , , ,

In Fidget spinners, I wrote about measuring and modeling the acceleration of two fidget spinners, 5-spoke spinner that cost $6.90 made from plastic and brass and a 3-bladed spinner that cost$8.90 milled out of brass:

The 5-spoked wheel spinner weighs 32.88±0.03g, and the 3-spoke brass spinner weighs 61.14±0.02g.

The previous post looked only at the fidget spinners spinning vertically (that is, with a horizontal axis), but I had noticed in playing with the spinners that they seemed to have different drag in different orientations, so I redid the measurements with the spinners horizontal (that is, with a vertical axis). I had a somewhat harder time spinning the spinners fast with them horizontally mounted, as my makeshift support for the photointerrupter was a bit precarious.

The 5-spoke wheel seemed to run smoothly , but the fit suggests more dry friction and less fluid friction.

The 3-spoke spinner really does not like to spin horizontally.

To visualize the physics better, I tried making acceleration vs. velocity plots for the fitted models:

When holding the wheel horizontally, there seems to be mainly dry friction, almost independent of the speed of the spin.

The 3-spoke spinner has much worse drag at all speeds when held horizontally rather than vertically. The fluid drag seems to be about the same as before, but there is much larger dry friction component (possibly from brass-on-brass contact between the spinner and the axle caps).

As expected from fidgeting with the spinners, the 3-blade spinner has much more drag than the wheel, both horizontally and vertically. The change from mainly wet friction to mainly dry friction for the wheel was unexpected, though.

Update 2017 Jun 25 21:15:  My wife just pointed me to a Wired article: https://www.wired.com/2017/05/the-phyiscs-of-fidget-spinners/ which does a poorer job of the same thing I did. They sampled at a fixed rate, rather than recording time stamps on each rising edge, so they had much poorer time resolution, and they assumed constant acceleration (dry friction), which is only appropriate for low-quality bearings.

## 2017 June 20

### Fidget spinners

Filed under: Uncategorized — gasstationwithoutpumps @ 17:34
Tags: , , ,

I recently bought two fidget spinners from Elecrow:

The 5-spoked wheel spinner weighs 32.88±0.03g, and the 3-spoke brass spinner weighs 61.14±0.02g.

The heavier 3-bladed spinner cost $8.90 and is milled out of brass (though the site claims “pure copper”, the material looks like brass and is slightly magnetic, so I’m sure it is brass).The lighter 5-spoke spinner cost$6.90.

The lighter spinner is easier to get to high speed, spins longer, has more gyroscopic effect, and has a dimple for balancing it on a pencil point, so makes the better fidget spinner in many ways.

I was curious whether I could characterize the fidget spinners electronically. I have a photointerrupter (an aligned LED and photodetector) from Sparkfun with a 1cm gap that the spinners just fit in.

Here is the 3-spoke spinner mounted in the Panavise Jr, with the photointerrupter counting 6 ticks per revolution.

Here is the 5-spoke spinner with the photointerrupter counting 5 ticks per revolution.

I set up PteroDAQ to record a timestamp on every rising edge of the photodetector, which counts 5 uniformly spaced ticks per revolution for the 5-spoke wheel, but 6 ticks (in 3 pair of closely spaced ones) for the 3-bladed spinner. I can then plot the angular position of the spinner as a function of time in gnuplot:

plot '3-spoke-spin-down-ticks.txt' u 1:(\$0/6.)


I tried fitting the spin-down using constant deceleration (a quadratic), using deceleration proportional to velocity (exponential decay), and using a model that has both terms: $v_{0}\tau(1-e^{-t/\tau})+a t^2 /2$.  I expressed position as number of turns (that being simpler to interpret than radians), and so the initial velocity $v_{0}$  is in turns/sec, acceleration $a$ is in turns per second per second, and the decay time $\tau$ is in seconds.  I got terrible fits with the constant deceleration, decent fits until the spinning got slow with the exponential decay, and quite a good fit with the combined model:

The longer spin time for the wheel is partly due to higher initial velocity, but the time constant for the decay is also much longer for the wheel, indicating better bearings.

I’m not quite sure how to interpret the slightly higher contact friction term for the 5-spoke wheel.

## 2016 February 21

### Optical pulse monitor software

Filed under: Circuits course,freshman design seminar — gasstationwithoutpumps @ 18:43
Tags: , , ,

I have previously written several posts about doing an optical pulse monitor as a lab exercise in the applied electronics course or as a project in the freshman design seminar. Most of what I’ve written up as has been the electronics design, with recording using PteroDAQ and post-processing using filters written in Python for display using matplotlib or gnuplot.

I decided today to try writing the software to do the pulse monitor on the Teensy and report the pulse rate out the serial port.  This meant sampling at a fixed rate, doing digital bandpass filtering to remove drift and noise that is not eliminated by the electronics, detecting rising edges in the filtered output (with hysteresis to increase noise immunity), and converting the measured period to beats per minute.  I used the LED on the board to report the pulses detected (flashing the light synchronized with the pulse).

I also added some tests to see if the pulse has been lost, and only report the pulse rate if there have been enough pulses properly detected since the last loss so that a smoothed pulse rate can be reported.

I output the time, the unsmoothed pulse rate, and the smoothed pulse rate to the serial monitor, and I can save that output to a file for plotting:

The movement artifacts around 20s and 40s are greatly reduced by either averaging or median filtering, but median filtering provides a more stable output.
At 70s, I removed my finger from the sensor for about 2s, so that the pulse was lost and had to be reacquired.

Before anyone asks, the pulse rate of 44 bpm is normal for me when resting—this is not likely to be a timing bug.

I’ll also want to try the 240×320 RGB ILI9341 TFT display that I bought, so that I can display the pulse (and maybe the pulse waveform) without needing a USB connection for anything but power.

## 2015 April 29

### More model fitting in lecture

Filed under: Circuits course — gasstationwithoutpumps @ 22:05
Tags: , , , , ,

Today’s lecture was all about fitting models for the electrode data. I started by showing them how one could hand-sketch Bode plots, at least for RC and RL circuits.  We did a hand plot and a gnuplot plot for the $R_{s} + (R_{p} || Z_{c}(C))$ model with arbitrary values, showing the initial horizontal $R_{s} + R_{p}$, the final horizontal $R_{s}$, and the diagonal at $\frac{1}{2\pi f C}$.

In class I went through trying to do fits to data collected for stainless-steel electrodes, and showing how to debug various problems (it was all live-action plotting—I did not script my actions).  The biggest problems were getting very bad fits (in one case from taking the log of the function but not the log of the data, in another case from having bad initial values) and singular matrices (mainly from having variables in the function that didn’t affect the fit, though in some cases from trying to fit complex models to real data without taking absolute value of the complex model).

It turns out that the standard R+(R||Z_C) model is very hard to fit to the data we collected for the stainless steel electrodes.  The oxide coatings don’t leak much current, so we had no low-frequency plateau for estimating the parallel resistance from.  I suggested making the parallel resistance infinite and using a simple R+Z_C serial connection.  That can model the data well at high frequencies, where the change in |Z| is fairly small, but at low frequencies the model is poor.

I came up with a different model on the spur of the moment (not one I had ever tried before on electrode data): $R + \frac{1}{j \omega^\alpha D}$ with a capacitor-like element having a smaller slope that the normal 1/f slope of a capacitor (about 0.6).  This turned out to fit the data quite well.  I don’t have a convincing physical explanation for the exponent α, but I suspect it has to do with diffusion times for ions near the surface of the electrode and depletion regions in the electrolyte.

In the new model, the R term probably corresponds to the bulk properties of the electrolyte solution and the $\frac{1}{j \omega^\alpha D}$ term to the surface chemistry at the electrode, so 1/R should be proportional to the concentration of the NaCl, I think.  I wonder whether students will get that result in their fits.  I’m thinking that I should rewrite some of the book to incorporate this model.

I ended by trying to model some of the data collected by students that did not work well—they had a huge inductance uptick at high frequency (fitting nicely to something like a 3mH inductance).  I’ve no idea how they got that data, as I saw their setup and they couldn’t have had more than a few µH of stray inductance.  Other students had small upticks at the high frequencies that were almost certainly stray inductance, since moving the voltmeter leads to connect directly to the electrodes eliminated the uptick, which did not happen with the students whose data I tried modeling.  I showed students how to model the uptick with an additional inductor, but I really don’t know what went wrong with the student data—I didn’t see any problems with their setup or recording, so I can only assume we all missed something.

Some of the students at least are getting the idea that modeling is not forcing your data to fit the theory in the book, but looking for regularities in the data.

Next Page »