Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
That’s a 0.035 inch = 35 mil hex wrench, of which Eks reminds me “Any time your design requires a tiny [obscene gerund] wrench, you’re doing it wrong”.
After a few days of downtime, an Official Makergear Thermistor arrived and is now installed amid a dab of heatsink compound:
M2 – Thermistor with heatsink compound
With the hot end set a bit higher than usual, position the platform at Z=0, lower the nozzle to be flat on the platform, tighten the lock screw, then run off a set of large calibration squares:
M2 – Nozzle Z Offset Recal – first test
The scrambled square in the front left says the Z=0 nozzle position came out just a bit too far above the platform and, indeed, the measurements (upper left numbers) say it’s off by 0.15-ish mm:
M2 Nozzle and Platform Re-Cal Measurements
Probably a little PETG stuck to the nozzle; I hate adjusting things when they’re burning hot.
The walls are also thin by a smidge, but the first order of business is to reset the Z offset with M206 Z=-2.15. With that in hand, the second set of squares came out at 3.00 to 3.08 mm (lower left numbers), which I defined to be Close Enough.
The 0.08 mm variation across the platform isn’t enough to worry about.
The first skirt threads were too thick and not solidly bonded together, but the second skirt came out normally, with a thickness from 0.21 through 0.30, which is also Good Enough.
The three-thread walls were still 1.15 mm, rather than 1.20 mm, so the EM should go from 0.95 to 0.95*1.20/1.15 = 1.05.
Next, a set of single-thread thinwall boxes to verify the Z offset and recheck the Extrusion Multiplier:
M2 – Nozzle Z Offset Recal – thinwall test
They’re dead on 3.00 mm tall, varying by not enough to worry about.
Their single-thread walls are 0.38 mm, not the intended 0.40, which suggests the EM should become 0.95*0.40/0.35 = 1.00.
It turns out the filament diameter at this part of the roll is scant of 1.75 mm, maybe 1.73 mm, so I decided to not fiddle with the EM.
The flange around the bottom of the arch support grid (in the middle) is intentional; it’s not an overstuffed first layer. The clamp sections rise from the platform just like they grew there.
So the M2 is back in operation and I have a spare thermistor on the shelf!
Not much to my surprise, my hack-job thermistor rebuild went bad:
M2 – thermistor – assembly 2
Having nothing to lose, I heated the brass tube over a butane flame to wreck the epoxy, which blew out with a satisfactory bang and filled the Basement Laboratory with The Big Stink.
Much to my surprise, the active ingredient still worked:
M2 DIY thermistor corpse
The multimeter reported absolutely no intermittent dropouts for as long as I was willing to watch the trace while doing other things:
DIY Thermistor Autopsy – Resistance Trend
So it must be my crappy soldering technique.
A brace of real M2 thermistors will arrive shortly …
I’ve been coaching a high-school student (and his father!) on the intricacies of building a self-balancing robot; they’re doing all the hard work and I’m running interference with techie bugs. This one turned out to be particularly nasty.
Reading the chip’s temperature sensor once every second produced this output:
BNO055 Sensor – Temperature Register vs I2C
He now knows why you must always leading-zero-fill binary values.
The shorter values say the chip ran at 26 °C, which means the longer values have a bogus binary 1 in bit 7. I2C bus transfers proceed MSB-first, so the Pi occasionally reads a bogus 1 at the first clock transition while reading the single temperature byte from the BNO055.
After some flailing around, we observed two types of I2C bus transactions.
Without clock stretching:
BNO055 – Normal I2C transaction
With clock stretching:
BNO055 – Clock-stretched I2C transaction
Contrary to what one might think from the lead-in description, the non-stretched version always produces the incorrect leading bit and the stretched version usually delivers the correct result.
He had previously installed the clock stretch workaround and we verified it was active. Turning it off had no effect, as did turning it back on again. The value uses units of the SCL period, so the modified value of 20000 produces 20×103 counts of 1/(100 k bit/s) = 2 s, far longer than any delay we observed. In fact, the default 640 μs would (apparently) suffice for the BNO055.
We noticed, but I did not record, nasty positive-going pulses on both SDA and SCL which were not due to noise or supply problems. As far as I can tell, the Pi does not maintain control over the I2C bus lines during some phases of the transaction, perhaps when the BNO055 invokes clock stretching, allowing the pullups to produce narrow upward glitches crossing the logic threshold. This will merit further study.
The solution, such as it is, seems to require slowing the I2C bus transactions to 25 kb/s, by inserting a line in the /boot/config.txt file:
dtparam=i2c_arm_baudrate=25000 ... dummy line to reveal underscores ...
Slowing to 50 kb/s produced intermittent errors, while 25 kb/s seemed to completely eliminate them. This contradicts suggestions of proper operation at any speed other than the default 100 kb/s. Note: this applies to a single-byte data value and longer transactions remain to be tested.
I want to verify that the lower rate also eliminates the glitches, which will require running the Pi with the scope plumbed into its guts for some time. For obvious reasons, he’d rather get the robot working, so, until he encounters more problems, I won’t see the hardware …
Update: There’s now a way to do I²C with software bit-banging in a reasonably easy way. Thanks to Simon Blake for pointing this out!
A loud crack during a windy thunderstorm announced this mess:
Driveway branch – as fallen
Some deft bow saw work cut it down to size:
Driveway branch – trimmed
Whereupon our neighbor arrived home and we dragged the carcass off the driveway.
Fortunately, it missed everything important, as have several recent branch falls in our yard. The same cannot be said for the many downed trees around the immediate area from recent storms; some folks are hurtin’ bad.
One of my Tektronix AM503 Hall Effect Current Probe Amplifiers (B075593, for future reference) lost its DC Level zero-ing capability:
Tek AM503 front panel
The front-panel knob produced only positive output voltages from maybe 50 mV to the amp’s upper limit around 200 mV (into a 50 Ω termination, Tek not being one to fool around with signal quality & bandwidth). Other than that, the amp seemed to work fine, but you definitely want a 0 V baseline corresponding to no current through the Hall probe.
The manual includes troubleshooting recommendations:
Tek AM503 Amplifier – troubleshooting zero set problems
Because I didn’t understand the circuitry, I check the supply voltages, then started at U350, the differential amp rubbing the DC level knob against the input signal, and worked outward in both directions (clicky for more dots):
Tek AM503 Current Probe Amplifier – p 61 – Output Amplifier schematic
The PCB looks like this:
Tek AM503 – Q230 PCB detail
U350 is the round epoxy package in the the square spider-leg array over on the far left. Contrary to what you (well, I) might think, the index mark denotes pin 16, not pin 1:
Tek AM503 Amplifier – Tek-unique IC pinout reference
Which puts pin 1 at the upper right corner of the package on the PCB. The part listing in the manual says MICROCKT,LINEAR:VERTICAL AMPLIFIER / SELECTED, which makes perfect sense given Tek’s oscilloscope business; if you needed a high-speed differential amplifier, that’s what Tek’s internal catalog would surely suggest. Newer AM503 revisions use somewhat less unobtainable op amps, although they replace the DC Level knob with one of those newfangled microcontroller thingies for some sweet auto-leveling action.
Nothing seemed out of order. The unable-to-zero condition pushed the bias voltages off the expected values, but nothing seemed completely out of whack / stuck at the rails / broken.
The problem turned out to be in Q230, the first item on Tek’s checklist after the power supplies, even though its bias voltages looked OK. It produces the “Attenuated AC Signal” seen above and lives on another page of the schematics:
Tek AM503 Amplifier – Q230 detail
Q230 is clad in the natty red heatsink in the PCB picture above. CR226 is the metal TO-18-ish can partially hidden by the orange-red-brown ribbon cable from the DC Level pot.
For future reference, C234 and C244 aren’t installed in this PCB; they’d fit in the conspicuously vacant spots to the right and in front of Q230.
What may not be obvious at a first glance: Q230’s pins sit in teeny individual sockets installed in the PCB. One might remove and reinstall Q230, should one be so inclined and, given that it’s the first active device after the input attenuator, one might imagine such an action being necessary after a catastrophic oopsie.
At this late date, finding a suitable dual JFET would be … difficult, even were one were willing to compromise on the hermetic metal TO-78A package.
Seeing as how Q230 has been sitting quietly in its socket for the last three decades, I proceeded cautiously:
Turned the power off
Waited for the supply voltages to drop
Pulled Q230 slightly upward
Wiggled-and-jiggled it around
Shoved it back down
Turned the power on
I heroically refrained from pulling it completely out of its socket to dab DeoxIT on the pins; JFETs being notorious for susceptibility to static damage and, likely, lube would make no difference anyway.
Fired that devil up and the DC Level knob resumed doing exactly what it should:
Tek AM503 – Q230 reseated
The output now has the usual ±200 mV range centered at 0 V. The waveform shows a 100 mA signal at 50 mA/div, produced by a bench supply into a 100 Ω power resistor switched by a DC-DC SSR.
The Smell of Molten Projects in the Morning 