[Update: It seems I interchanged “em” and “de” throughout this post. ]
Up to this point, I’ve been labeling printed parts with
emdebossed legends that look OK on the solid model:
Alas, the recessed letters become lost in their perimeter threads:
Raising the legend above the surface (“
deembossing”) works reasonably well, but raised letters would interfere with sliding the battery into the holder and tend to get lost amid the surface infill pattern.
The blindingly obvious solution, after far too long, raises the letters above a frame embossed into the surface:
Which looks OK in the real world, too:
The frame is one thread deep and the legend is one thread tall, putting the letters flush with the surrounding surface and allowing the battery to slide smoothly.
The legend on the bottom surface shows even more improvement:
An OpenSCAD program can’t get the size of a rendered text string, so the fixed-size frame must surround the largest possible text, which isn’t much of a problem for my simple needs.
Spotted this in a mall built just before the 2008 financial implosion:
Maybe the original catalog items went obsolete by the time they signed up enough tenants in that section to justify any lighting at all?
In related news, a facelift some years ago at the motel next to the decaying Red Oaks Mill dam installed square lamp posts on the existing square concrete pedestals, but replaced the original metal conduit with a plastic sheath:
The cable may sit low enough in the recess to survive, but I wouldn’t bet my life on it.
A Red Fox came trotting around the garden on the day before Christmas, then nosed up to the back of the house:
Presumably, it was in search of a snack. We wish it good hunting.
A few hours later, the fox walked quickly across the back yard with half a dozen turkey toms close behind, perhaps urging it away from their hens. Everybody remained calm and collected, knowing their roles in this particular play.
A bag of 100 nF ceramic caps arrived from across the continent (“US Stock”) and failed incoming inspection:
The capacitor mark says 104, which is what you’d expect on a 100 nF cap, but the first half-dozen out of the bag measured around 55 nF, far outside even the loosest -20%/+50% tolerance.
Stipulated: the factory can ship every capacitor it makes with a proper mark.
Given their (lack of) provenance, they could be mis-marked 47 nF caps.
Somewhat to my surprise, a refund occurred instantly after I reported the problem.
Trust, but verify.
Taping a cardboard support under the soldering fixture helped hold all the parts in place:
The struts fit neatly into an NP-BX1 battery holder and the circuit began blinking merrily:
My photography hand is weak …
The circuit schematic / layout resembles this:
The missing 1 MΩ resistor at the LED would serve as a physical support to tether the loose end of the 100 (-ish) Ω resistor, which desperately needed some stabilization under the LED spider.
The simulation says it should blink about every 4s:
The 2N7000 MOSFETs use a SPICE model from the
Motorola ON Semi downloads, although they behaved about the same way using the LTSpice 2N7002 model.
It really does blink every 4s:
The LED pulse width should be about 50 ms:
The voltage at the bottom of the ballast resistor is directly proportional to the LED current:
So the pulse is actually 80-ish ms, which is Close Enough™ for my purposes.
The key advantage here is making both the astable’s period and the blink’s duration (roughly) proportional to the component values, so I can tweak them with some confidence the results will come out more-or-less right.
I love it when a plan comes together!
As with the Siglent SDS2304X oscilloscope, the SDM3045M multimeter delivers broken screen shot files over the network: the actual file size doesn’t match the BMP file size field, causing kvetching in subsequent use:
[ed@shiitake tmp]$ lxi screenshot -a 192.168.1.41 -p siglent-sdm3000 test.bmp Saved screenshot image to test.bmp [ed@shiitake tmp]$ convert test.bmp test.png convert-im6.q16: length and filesize do not match `test.bmp' @ warning/bmp.c/ReadBMPImage/831.
Files stored on a USB stick jammed into the meter’s front panel have the correct size, so it’s not clear where the fault lies.
Because the files contain extra data following the (intact) image, it will display correctly:
The BMP header contains the correct size at offset +0x02:
lxi screenshot -a 192.168.1.41 -p siglent-sdm3000 test.bmp hexdump -C test.bmp | head 00000000 42 4d 36 fa 05 00 00 00 00 00 36 00 00 00 28 00 |BM6.......6...(.| 00000010 00 00 e0 01 00 00 10 01 00 00 01 00 18 00 00 00 |................| 00000020 00 00 00 fa 05 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
The horizontal image size at +0x12 and vertical size at +0x6 are correct: the screen is 480×272 pixels. Each pixel has three bytes = 24 bits, as specified at +0x1C.
So the file should contain 0x0005fa36 = 391734 bytes, but, as delivered, it’s much, much larger:
ll --block-size=1 test.bmp -rw-rw-r-- 1 ed ed 1152054 Dec 26 08:45 test.bmp
Oddly, 1552054 bytes is exactly the size the oscilloscope files should be. I have no explanation, although it looks like a copypasta error.
As before, the simplest solution is to truncate the file and be done with it:
#!/bin/bash lxi screenshot -a 192.168.1.41 -p siglent-sdm3000 /tmp/"$1".bmp truncate --size=391734 /tmp/"$1".bmp convert /tmp/"$1".bmp "$1".png echo Screenshot: "$1".png
And then It Just Works:
~/bin/getsdm3045x.sh testfix Saved screenshot image to /tmp/testfix.bmp Screenshot: testfix.png
Sheesh & similar remarks.
Some poking around revealed an astable multivibrator using now-obsolescent ZVNL110A MOSFET transistors. The key idea seems to be large gate resistors putting the DC operating point exactly at the voltage required to hold each transistor in the linear region, pretty much guaranteeing the astable will eventually start up.
A bit of simulation suggests this variation ought to work:
Well, after the kickstarter in the lower left shorts the transistor for millisecond to enforce some asymmetry, whereoupon the simulation ticks along just fine.
The yellow trace shows the voltage across C2 ramping back and forth between ±1.3 V, with a period just over 4 s and almost exactly a 50% duty cycle: much better than the bipolar version, with sensible component values. As before, the cap sees both polarities, so an electrolytic cap isn’t appropriate.
The red trace is the drain voltage at M2 (presumably, “M for MOSFET”, rather than a plebeian “Q” or “T”), which is firmly at 0 V when it’s ON and ramps upward as R4 pulls C1 higher to turn it even more firmly OFF.
The green trace shows the LED current pulse when M2 turns ON at the end of each cycle. Rather than contort the astable into a very low duty cycle, I generate the pulse by dumping current through a smallish cap into the gate of M4. A few tens of milliseconds makes a perfectly serviceable blink and keeps the average current drain down around a milliamp or so.
In between, M3 buffers the astable’s output to deliver enough current to C4. Without the buffer, the cap draws enough current to mess with the oscillations; that’s how I got backed into this corner.
Figuring the LED at 20 mA for 50 ms, the astable at 10 µA, and the buffer at half of 40 µA, the average current of 1 mA comes entirely from the LED, so even a weak lithium camera battery should last a good long while.
If the low average drain ekes 1000 mA·h from the battery, the LED should blink for a month or two before the battery shuts down.