The Smell of Molten Projects in the Morning
Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
If you measure something often enough, it becomes science
A cold snap in early January caught plenty of humidity inside the house and, in fact, the attic temperature dropped so abruptly that the nails protruding through the roof iced over:
You’d think they were coated with plastic:
The incandescent bulb lighting the attic highlights the crystal planes:
As nearly as I can tell, the ice sublimes or melts-and-evaporates, because the plywood floor under the nails doesn’t have the drip marks you’d expect.
In the course of running off some Superformula plots, I found what must be my original stash of B-size plotter paper. Although it wasn’t archival paper and has yellowed a bit with age, it’s the smoothest and creamiest paper I’ve touched in quite some time: far nicer than the cheap stuff I picked up while reconditioning the HP 7475A plotter & its assorted pens.
Once in a while, all my errors and omissions cancel out enough to produce interesting results on that historic paper, hereby documented for future reference…
A triangle starburst:
A symmetric starburst:
Complex meshed ovals:
They look better in person, of course. Although inkjet printers produce more accurate results in less time, those old pen plots definitely look better in some sense.
The demo program lets you jam a fixed set of parameters into the plot, so (at least in principle) one could reproduce a plot from the parameters in the lower right corner. Here you go:
The triangle starburst:
The symmetric starburst:
The meshed ovals:
The current Python / Chiplotle source code as a GitHub gist:
| from chiplotle import * | |
| from math import * | |
| from datetime import * | |
| from time import * | |
| from types import * | |
| import random | |
| def superformula_polar(a, b, m, n1, n2, n3, phi): | |
| ''' Computes the position of the point on a | |
| superformula curve. | |
| Superformula has first been proposed by Johan Gielis | |
| and is a generalization of superellipse. | |
| see: http://en.wikipedia.org/wiki/Superformula | |
| Tweaked to return polar coordinates | |
| ''' | |
| t1 = cos(m * phi / 4.0) / a | |
| t1 = abs(t1) | |
| t1 = pow(t1, n2) | |
| t2 = sin(m * phi / 4.0) / b | |
| t2 = abs(t2) | |
| t2 = pow(t2, n3) | |
| t3 = -1 / float(n1) | |
| r = pow(t1 + t2, t3) | |
| if abs(r) == 0: | |
| return (0, 0) | |
| else: | |
| # return (r * cos(phi), r * sin(phi)) | |
| return (r, phi) | |
| def supershape(width, height, m, n1, n2, n3, | |
| point_count=10 * 1000, percentage=1.0, a=1.0, b=1.0, travel=None): | |
| '''Supershape, generated using the superformula first proposed | |
| by Johan Gielis. | |
| – `points_count` is the total number of points to compute. | |
| – `travel` is the length of the outline drawn in radians. | |
| 3.1416 * 2 is a complete cycle. | |
| ''' | |
| travel = travel or (10 * 2 * pi) | |
| # compute points… | |
| phis = [i * travel / point_count | |
| for i in range(1 + int(point_count * percentage))] | |
| points = [superformula_polar(a, b, m, n1, n2, n3, x) for x in phis] | |
| # scale and transpose… | |
| path = [] | |
| for r, a in points: | |
| x = width * r * cos(a) | |
| y = height * r * sin(a) | |
| path.append(Coordinate(x, y)) | |
| return Path(path) | |
| # RUN DEMO CODE | |
| if __name__ == '__main__': | |
| override = False | |
| plt = instantiate_plotters()[0] | |
| # plt.write('IN;') | |
| if plt.margins.soft.width < 11000: # A=10365 B=16640 | |
| maxplotx = (plt.margins.soft.width / 2) – 100 | |
| maxploty = (plt.margins.soft.height / 2) – 150 | |
| legendx = maxplotx – 2900 | |
| legendy = -(maxploty – 750) | |
| tscale = 0.45 | |
| numpens = 4 | |
| # prime/10 = number of spikes | |
| m_values = [n / 10.0 for n in [11, 13, 17, 19, 23]] | |
| # ring-ness 0.1 to 2.0, higher is larger | |
| n1_values = [ | |
| n / 100.0 for n in range(55, 75, 2) + range(80, 120, 5) + range(120, 200, 10)] | |
| else: | |
| maxplotx = plt.margins.soft.width / 2 | |
| maxploty = plt.margins.soft.height / 2 | |
| legendx = maxplotx – 3000 | |
| legendy = -(maxploty – 900) | |
| tscale = 0.45 | |
| numpens = 6 | |
| m_values = [n / 10.0 for n in [11, 13, 17, 19, 23, 29, 31, | |
| 37, 41, 43, 47, 53, 59]] # prime/10 = number of spikes | |
| # ring-ness 0.1 to 2.0, higher is larger | |
| n1_values = [ | |
| n / 100.0 for n in range(15, 75, 2) + range(80, 120, 5) + range(120, 200, 10)] | |
| print " Max: ({},{})".format(maxplotx, maxploty) | |
| # spiky-ness 0.1 to 2.0, higher is spiky-er (mostly) | |
| n2_values = [ | |
| n / 100.0 for n in range(10, 60, 2) + range(65, 100, 5) + range(110, 200, 10)] | |
| plt.write(chr(27) + '.H200:') # set hardware handshake block size | |
| plt.set_origin_center() | |
| # scale based on B size characters | |
| plt.write(hpgl.SI(tscale * 0.285, tscale * 0.375)) | |
| # slow speed for those abrupt spikes | |
| plt.write(hpgl.VS(10)) | |
| while True: | |
| # standard loadout has pen 1 = fine black | |
| plt.write(hpgl.PA([(legendx, legendy)])) | |
| pen = 1 | |
| plt.select_pen(pen) | |
| plt.write(hpgl.PA([(legendx, legendy)])) | |
| plt.write(hpgl.LB("Started " + str(datetime.today()))) | |
| if override: | |
| m = 4.1 | |
| n1_list = [1.15, 0.90, 0.25, 0.59, 0.51, 0.23] | |
| n2_list = [0.70, 0.58, 0.32, 0.28, 0.56, 0.26] | |
| else: | |
| m = random.choice(m_values) | |
| n1_list = random.sample(n1_values, numpens) | |
| n2_list = random.sample(n2_values, numpens) | |
| pen = 1 | |
| for n1, n2 in zip(n1_list, n2_list): | |
| n3 = n2 | |
| print "{0} – m: {1:.1f}, n1: {2:.2f}, n2=n3: {3:.2f}".format(pen, m, n1, n2) | |
| plt.select_pen(pen) | |
| plt.write(hpgl.PA([(legendx, legendy – 100 * pen)])) | |
| plt.write( | |
| hpgl.LB("Pen {0}: m={1:.1f} n1={2:.2f} n2=n3={3:.2f}".format(pen, m, n1, n2))) | |
| e = supershape(maxplotx, maxploty, m, n1, n2, n3) | |
| plt.write(e) | |
| pen = pen + 1 if (pen % numpens) else 1 | |
| pen = 1 | |
| plt.select_pen(pen) | |
| plt.write(hpgl.PA([(legendx, legendy – 100 * (numpens + 1))])) | |
| plt.write(hpgl.LB("Ended " + str(datetime.today()))) | |
| plt.write(hpgl.PA([(legendx, legendy – 100 * (numpens + 2))])) | |
| plt.write(hpgl.LB("More at https://softsolder.com/?s=7475a")) | |
| plt.select_pen(0) | |
| plt.write(hpgl.PA([(-maxplotx,maxploty)])) | |
| print "Waiting for plotter… ignore timeout errors!" | |
| sleep(40) | |
| while NoneType is type(plt.status): | |
| sleep(5) | |
| print "Load more paper, then …" | |
| print " … Press ENTER on the plotter to continue" | |
| plt.clear_digitizer() | |
| plt.digitize_point() | |
| plotstatus = plt.status | |
| while (NoneType is type(plotstatus)) or (0 == int(plotstatus) & 0x04): | |
| plotstatus = plt.status | |
| print "Digitized: " + str(plt.digitized_point) | |
We ride through the intersection at the Rt 55 end of Burnett Blvd a lot, because it’s the only route between Raymond Avenue and the Dutchess Rail Trail. Previous posts have documented the signal timing, but this sequence shows the situation we’ve feared from the beginning… cross traffic not stopping because we are in the intersection with an opposing green light.
I’m towing a trailer with three bags of groceries.
The sequence numbers indicate the frame at 60 f/s.
T +0.000 = our signal just turned green:
T +1.250 s = the drivers ahead of us release their brakes and begin rolling:
T +2.400 s = we begin rolling:
It’s worth noting that we cannot start any earlier, unless you regard jumping the green and passing cars at an intersection as Good Practices, which we don’t.
T +7.217 s = the yellow signal goes on in our direction:
That’s six whole seconds from the time the cars started rolling and 4.8 s from the time we started.
Notice the white car to our right that’s stopped in the leftmost eastbound lane of Rt 55.
T +12.100 s = our signal turns red:
I’ve reached the middle of the intersection, Mary’s about centered on the three eastbound lanes of Rt 55.
T +13.333 s = the opposing signal turns green:
Traffic in both directions of Rt 55 can now begin moving, but the white car remains stopped; it’s almost directly behind me in the leftmost lane. Because Mary is following the curved line guide lines, she’s just entering the rightmost lane. What you can’t see is a black car approaching from behind her that didn’t have to stop.
T +20.950 s = the car in the right lane that didn’t have to stop passes me:
I’m 140 feet from the stop line (figured with the distance calculator):
At 40 mph = 60 ft/s, that car passed the stop line 2.3 s earlier, at T +18.7 s, when I was still crossing the right lane.
It’s entirely likely that the driver didn’t see either of us while approaching the intersection, because he (let’s assume a he for the sake of discussion) had a green light nearly 5 s = 300 ft before reaching the stop line. Unless he’s paying more attention than most drivers, he was intent on the signal to judge whether he must slow down; for the last 7.3 s he’s known that the intersection is clear, because nobody else should be in the intersection against his green signal.
T +24.667 s = The white car in the left lane passes Mary:
All I’m asking NYSDOT to do is lengthen the signal timing so we’re not caught in the middle of the intersection by opposing traffic with a green signal. Adding a few seconds onto the yellow and minimum cycle time doesn’t seem unreasonable, but it’s been six months since I reported the problem with no action; I’ve pinged their Bicycle & Pedestrian coordinator several times with no response.
If their engineers are “studying” the situation, it’s not producing any visible results; they haven’t asked me for any additional data.
I Am Not A Lawyer, but I think my collection of photos should provide sufficient evidence to convince a jury that NYSDOT is totally liable for any bicycling injuries at that intersection, based on the inability of cyclists to meet the signal timing. I really don’t want to find out if I’m right…
Rolling through the back of the Vassar Campus, watching a murder of crows on the lawn, when all of a sudden:
That squirrel passed about three feet in front of Mary’s bike, running flat out and, at 60 frame/s, touched the ground every 200 ms:
Figuring a squirrel body+tail is 1.5 ft long and it covers 3 of those units with every leap, it’s moving at 22 ft/s = 15 mph. That’s about as fast as we travel…
After 95 minutes on a pleasant ride with temperature around 55 °F, the STK C battery had 0.59 W·h remaining (dark green trace):
The last time around, it had 1.85 W·h after 61 minutes. Subtracting the two (and ignoring that it may have started with slightly different charges and behave differently at different temperatures) says the camera used 1.26 W·h = 76 W·min in 34 minutes, which averages out to 2.2 W.
That’s close enough to the “a bit over 2 W” figured from those partial-to-empty measurements for me.
The discharge tests from early November:
The best STK battery (D) holds just under 4.2 A·h, so its absolute longest run time could be 110-ish minutes. That graph shows the A cell was just about done after 75 minutes, so changing the battery after an hour still makes sense; you never know what will happen during the last few minutes of a ride…
So I can find it again, the way to change the sudo timeout for a particular user (that would be me) involves adding a line to the /etc/sudoers file using sudo visudo, thusly:
Defaults: ed timestamp_timeout=90
# blank line to make the underscore visibleNote the colon! Should you add the timeout to the global Defaults env_reset line, then everybody gets a monster timeout, which may not be what you want.
You can change the default editor (nano in Ubuntu) thusly:
sudo update-alternatives --config editorOr, in Arch / Manjaro, add a stanza:
Defaults editor=/usr/bin/nanoBecause my vi hand is weak:
That’s all I need to insert the proper stanza & move on.
So another knockoff Neopixel started flickering and its blue LED went dark:
Squirting it with circuit cooler brought it back to life, albeit briefly, so it’s a real thermal failure. OK, after I get smacked upside the head twice, I can recognize a problem when I see it.
I removed the top cover and jammed a themocouple into the screw hole in the middle of the pillar:
A folded tissue weighted down with random desktop junk kept the breeze out of the interior:
If the middle of the column hits 50 °C, what’s it like inside the 5050 packages with all those LEDs blazing away? Looks like I’ve been cooking those poor knockoff Neopixels to death.
The temperature is 50 °C with the LEDs running at maximum PWM = 128. Reducing the maximum PWM to 64 reduces the core to 30 °C and that dead blue LED springs back to life.
Figuring each LED package dissipate 250-ish mW at full throttle, that’s 120 mW at PWM 128 / 60 mW at PWM 64. The set of 12 packages dissipates 1.4 W / 750 mW, so, in a 22 °C room, the thermal coefficient is up around 10 to 20 °C/W, which is somewhere between bad and awful. Running the LEDs at full throttle obviously isn’t an option and even half-throttle really doesn’t work.
So, OK, mounting LED strips on a clever 3D printed plastic column with zero air circulation isn’t nearly as smart an idea as I thought: barely more than a watt burns right through the redline.
The Neopixel specs have nothing to say about the thermal coefficient from the LED junctions to the package leads, but cooling the copper conductors in the flex PCB can’t possibly hurt.
No, I do not want to CNC machine an aluminum pillar with little tabs on the platter for better heatsinking. It would be an interesting design project, though.
The Smell of Molten Projects in the Morning 