Shakespeare cookies v7

Today (2019 August 31), my son and I baked shortbread cookies using version 7 of the Shakespeare cookie cutter, which is a two-part design with a separate cutter and stamp:

Version 7 of the Shakespeare cookie cutter uses a simple outline for the cutter and a separate stamp for adding the facial features. Version 6 of the stamp failed, because I made the alignment markers too thin and they did not survive even gentle handling.

In addition to the new cutter and stamp, we also tried out the “cookie sticks” that I made for rolling the dough to a consistent 6mm thickness:

I made two different sticks: a straight one and one with a 90° corner. The OpenSCAD file also allows other angles, so I could have made 120° corners for a hexagon.  I made the sticks about as big as I could print on the Monoprice Delta Mini.

The hooks at the two end of the stick lock the sticks together.

I made enough of the sticks to make a rectangular frame almost as big as my cookie sheets. I ran out of the ugly green PLA filament after only 3 sticks, so I did the rest in the Hatchbox gold PLA filament.

I made the same shortbread dough as last time: 1 cup butter, 2 cups pastry flour, and ½ cup powdered sugar. I cleared a counter to make some workspace:

I had a cookie sheet,a rolling pin (a piece of birch dowel that I sanded and coated with mineral oil decades ago), a silicone baking mat, the cookie sticks, the cookie cutter and stamp, and a shallow bowl for flour.

The entire batch fills about 2/3 of the frame when rolled out:

For the first batch, we tried rolling the dough directly on the silicone baking mat, and removing the excess dough without moving the cookies.

The cookie sticks worked well for getting a uniform, consistent thickness to the dough, and 6mm is about the right thickness for these cookies. Having a complete frame around the dough meant that I did not have to worry about the cookie sticks shifting position, nor what the orientation of the rolling pin was.

The stamping is easily done on the cookies, but removing the excess dough from between the cookies was harder than we expected. It probably didn’t help that it was a warm afternoon and the dough got sticky quickly, even though we refrigerated it before rolling.

For the second rolling, we rolled the dough onto waxed paper, then transferred the cut-out cookies to a baking sheet lined with a silicone mat, doing the stamping only after the cookies were on the baking sheet.

We ended up with 19 cookies from the batch, and they came out pretty good:

This picture is a bit misleading as these were probably the best two of the nineteen.

The biggest problem was with dough getting stuck in the nose when stamping—it might be easier to do Tycho Brahe cookie cutters!

The second biggest problem was getting accurate alignment of the stamp with the cutter. For several of the cutters we were a millimeter off, resulting in an extraneous line at one of the alignment markers.

Despite these minor problems, the v7 cutters were much easier to use than previous versions, and I don’t have any immediate ideas for improvements (other than changing from a 3D-printed cutter to a injection-molded cutter, which would require a lot of changes and cost a few thousand dollars—something I’m not prepared for.

BitBucket being killed by Atlassian

I have been using BitBucket for source code repositories since about 2012, when my son chose it for the Arduino data logger project, which later became the PteroDAQ project (in a separate BitBucket repository).  This month Atlassian decided to end support for all Mercurial projects, with no new repositories after February 2020, and deletion of all remaining repositories in June 2020.

I will have to move PteroDAQ from BitBucket well before the deadline, because there are pointers to it in my book, and these pointers will need to be updated for the end-of-December release.

I think that Atlassian’s tone-deaf announcement will kill off BitBucket as a source-code hosting site, even though they plan to continue to support git.  Who will trust them to maintain repositories if they plan to delete everything some group of their customers have relied on them for?  I could sort of understand stopping support for Mercurial (though that was the main thing that made BitBucket better than GitHub), but the result should have been making the repositories read-only for ten years, not deletion.  Atlassian picked up a bunch of users from GitHub when Microsoft bought GitHub, but I think that they will lose a lot of them from this managerial mistake.

Making things worse, Atlassian is providing no automation to convert repositories from Mercurial to Git, suggesting that people do the move(s) manually.  Even GitHub provides better tools, with an automatic import of Mercurial repositories that even maps authors.

The net effect of Atlassian’s managerial decision will not be migration from BitBucket Mercurial to BitBucket Git, but to GitHub or GitLab.  GitHub or GitLab could accelerate this migration by providing an automatic import that moves the wiki and issues database from BitBucket at the same time.

I moved one repository to GitHub, just to see how well the automatic import of the repository worked.  That repository had no wiki or issue tracking, so was easy to move.  I’ll probably move my book sources to GitHub also, after the next push I do to the BitBucket repository.  (I considered using GitLab instead of GitHub, but they don’t seem to have an automatic transfer of Mercurial repositories from BitBucket, the way that GitHub does.)

The PteroDAQ move will be the most difficult, because I’ll want to move the issues and the wiki as well.  There seem to be some scripts on the web for doing those transfers, but they are not part of the standard GitHub suite of tools, and may be a bit iffy.

 

Gain-bandwidth product

I spent yesterday afternoon collecting data for two figures for my book illustrating the limitation on gain caused by the gain-bandwidth product:

This graph shows the measured gain of non-inverting amplifiers built using the MCP6004 op amp.
It also includes a line for f_{GB}/f fit to the data for the highest-gain amplifier.

This graph compares the measured data (thin lines) to the model used in the book for amplifiers with gain-bandwidth limitations (thick yellow lines) for three of the amplifier configurations.

I did all the data collection with my Analog Discovery 2, using the network analyzer.

The data looks easy to collect, and I expected it to take me just an hour to gather all the data, but it was a bit trickier than I thought. I used a symmetric ±2.5V power supply from the Analog Discovery 2, so all the signals could be centered at 0V.

One problem was that I initially had not set the offset and gain of the oscilloscope channels to “auto”, and the output was not centered precisely at 0V. The network analyzer does not do as good a job of compensating for DC offsets as I think it should. I set the channels to automatic gain and offset and I tweaked the offset of the waveform generator by 1mV to make the output be centered correctly. I think that the 1mV offset is compensating for the offset of the op-amp chip, but it may be correcting an offset in the waveform generator.

For the high-gain amplifiers, I needed to reduce the signal from waveform generator, because the smallest signal the network analyzer allows is ±10mV, and with a gain of 393, that would cause clipping. My first voltage divider reduced the signal sufficiently, but I got very noisy results. It took me quite a while to realize that the problem was not just loose wires (though those were also a problem), but that I had used resistors that were too large, so that the input of the amplifier was amplifying capacitively coupled 60Hz noise. Reducing the input voltage divider to 1kΩ resistors solved that problem.

I was having another problem in which the shape of the curve for the low-gain amplifiers changed at the high-frequency end as I changed the amplitude of the signal. It took me an embarrassingly long time to realize that the problem was that I was hitting slew-rate limits before hitting the gain-bandwidth product limits. The high-gain amplifiers all had much lower gain at 1MHz than at low frequencies, so an input signal small enough to avoid clipping at low frequencies produced such a small output at high frequencies that slew rate was not limiting. But for low-gain amplifiers, I had been increasing the amplitude for better measurements, and the gain at 1MHz was only a little less than the gain in the passband, so I was asking for over 8V/µs, and the amplifier’s slew rate is only 0.6V/µs. I realized the problem when I used the oscilloscope to look at what the amplifier was producing, and saw that it was not a sine wave, but a small weirdly distorted signal.

After I finally got everything set up and working with small enough inputs to avoid clipping in high-gain amplifiers and slew-rate limitations in low-gain amplifiers, I finally was able to collect a consistent set of data.

The model for the op amp is that the open gain is , and the gain of the non-inverting amplifier is , where is just the gain of the voltage divider used as a feedback network. The model breaks down at high frequencies, because the op amp has further filtering above 1MHz, and for very high gain, where the DC amplification limit matters. We don’t design op-amp circuits to use such a high gain that the DC open-loop gain matters, but pushing the frequency limit is common.

But the simple gain-bandwidth model does a very good job of fitting the data, as long as you avoid signal levels that cause clipping or slew-rate limitations.

Shakespeare cookies v5

On Saturday, my son and I baked shortbread cookies using version 5 of the Shakespeare cookie cutter:

The difference between version 4 and version 5 is mainly around the left eye (on the right in this photo). Version 4 had a lot of trouble with the dough getting stuck in the small regions there. (See prior post for cookies made with the V4 cutter.)

Despite the simplifications, Shakespeare’s head is still quite recognizable.

We used the classic recipe (2 cups flour, 1 cup butter, and ½ cup confectioner’s sugar), but this time I used pastry flour instead of a mixture of all-purpose flour and sweet rice flour.  The dough works about equally well either way.

The cookies came out good, but the cookie cutters are still having problems with dough sticking to the cutters. Chilling the dough after rolling helped a little, but stickiness was still a problem. We also had problems rolling the dough out to a uniform 6mm thickness—sometimes we had the dough too thin, and the interior lines were not clear, and sometimes we had it too thick and couldn’t get the cookie out of the cutter without destroying the cookie.

My son had two suggestions, both of which I’ll follow up on:

• Go back to having separate cutter and stamp (as in Version 3), but don’t try to connect the two.  Make the stamp just have a few alignment marks so that it can be hand-aligned to the cookie outline.  The stamp can have a lot of open space, so that the visual alignment is relatively easy, and so that the cookie dough can be easily separated from the stamp.  The stamping can even be done after the cookie has been transferred to the baking sheet, to make distortion from moving the cookie less of a problem.
• Make a set of 6mm thick sticks that can be put down around the dough, that the rolling pin can rest on.

Version 6 of the stamp failed, because I made the alignment markers too thin and they did not survive even gentle handling.  I’m now printing Version 7, which has more robust alignment markers.

 

Beginning design of a cat drinking fountain

One of our cats likes to drinking from running water (a bathroom sink on a trickle setting), so my wife challenged me to make a drinking fountain for the cat that recirculates water in a water dish.  This project will be mainly physical design (3D printing, gluing things together) with a little electronics to control the pump.

I started by buying a very cheap pump from American Science and Surplus: an ET 23 series pump that they are getting rid of for only $2.50.  Somewhat surprisingly, there is a data sheet available for this pump from the manufacturer: http://www.et-pump.com/brushless_23.html, but (not so surprisingly) the specs are different from what American Science and Surplus claims. The manufacturer says that the pump is submersible and can be run at 5V to 12V, while American Science and Surplus says it is not submersible and runs on 4V to 6V.  Because the pump electronics are fully potted, I tend to believe the manufacturer on this one.

The pump uses a brushless motor with two sets of windings (and only 2 transistors to power them) and seems to start pumping at about 4V.  To characterize the pump, I used my Analog Discovery 2 to sweep the power-supply voltage from 0V to 10V, measuring the current through a 0.5Ω resistor.  The results were interesting:

At low voltage, the current seems to be exponential with voltage, as would be expected from having a diode in the circuit—the nonideality of 5.6 is consistent with about 3 silicon diode drops. Above 4V, the motor behaves about like a 26Ω resistor, though with a lot of noise. The turn-on and turn-off behavior between 2V and 4V is interesting—the pump takes a lot of power at these voltages. All these measurements were taken with the pump running dry—it likely behaves differently when pumping water.

The “noise” in the I-vs-V curve is not random noise—it is fluctuation in the amount of current taken as the circuitry for the brushless motor switches between the two sets of coils. If we set the power supply to a constant 5V across the motor in series with the 0.5Ω resistor, we can observe the voltage and the current for the motor:

The two coils seem to take slightly different peak currents when the switch for them is turned on, but both spikes are about 2.8 times the average current. The frequency is around 643 Hz, which implies a speed of around 19300RPM.

I tried controlling the pump with one of the PWM LED controllers that I made for the desk lamps. With a 6V power supply, I need about 60% duty cycle to start the motor, but then can turn it down to about 15–20% duty cycle.  With an 8V power supply, I need about 40% to start and with a 10V supply about 30% to start. All these were crude measurements by turning a potentiometer until the motor started, but they are consistent with about a 3.3V average starting voltage and ability to keep running down to almost 1V.  If the pump stalls at low voltage, one has to bring it up to about 3.5V to turn it back on.

The motor runs even with fairly slow, low-duty cycle PWM. The current spikes at the beginning of each cycle are large.

The PWM control seems to work even with a PWM frequency as low as 270Hz, which is somewhat surprising.  There does not seem to be much in the way of voltage spiking, even with no capacitor or flyback diode added.  There is a short-lived initial current spike of about 3.5A (staying above 2A for about 4µs), which probably comes from charging capacitor C3 in the motor, which is across the power lines after the diode D1 (which seems to be there to prevent reversed power supply).  The 11µC spike is consistent with C3 being about a 1 µF capacitor (or maybe 2.2µF), which seems plausible.  I’m not sure why the current drops to 0 before the motor voltage drops more than about a volt.

I bought some cheap plastic bowls from a thrift store, and my next task is going to be to design a 3D-printed base to hold the pump and the electronics under the bowl and a clip to hold a ¼” ID vinyl tube over the bowl.  The pump is not self-priming, so I need to drill a hole in the bottom of the bowl and glue on the pump to make a gravity feed to do the priming.