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 it used to work, it can work again
The neutral conductor is down to its last three strands:
Perhaps the power drop got snagged twice, because there’s a splice only a few feet away:
Spotted overhead on Redondo near Rt 376 during an evening walk. I reported it using Central Hudson’s dead streetlight page, because there seems no other way to get their attention. It may be the homeowner’s responsibility, in which case a second splice will surely appear after the next power outage.
One might expect the NYS Department of Transportation to maintain New York State Bike Route 9, a.k.a. NYS Rt 376 from Poughkeepsie to Red Oaks Mill, in a bicycle-aware manner.
One would be mistaken.
The most recent patch strip very carefully avoids the deteriorated shoulder, all the way around the curve:
The weeds growing in the serrated shoulder add a decorative counterpoint to the black asphalt patch in the travel lane:
It was a rather large repair crew:
The crew chief said they were there because “somebody wrote a letter” describing the conditions. I suppose that would be me, although after half a year it’s hard to establish causation, let alone correlation.
He also says no details of the letter reached him, which explains why they laid the patches in the travel lane, rather than repairing the conditions I described. He was adamant they were doing the best they could with the inadequate manpower, materials, and time available for the projects.
There are absolutely no requirements to consider bicyclist safety in their repairs, so laying asphalt over the shoulder never happens.
NYS DOT’s Bicycling FAQ says I should “take the lane” around that curve, due to the deteriorated shoulder, to ensure motorists pass only when it’s safe.
Whenever I offer to take a NYS DOT bureaucrat on an inspection ride along their roads, they never have the time. Of course, they don’t “work” on weekends, so they’re unwilling to join me on a pleasant ride around the area some Saturday or Sunday morning.
Just another day of bicycling along NYS DOT’s “complete streets” …
Almost exactly three years later, it’s time to tighten the helmet mirror mount screws:
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”.
The sequence goes like this:
Going strong after seven years!
A wind gust pushed Mary’s bike over with the daytime running light on the downward side:
Frankly, it’s better to have a cheap and easily replaceable plastic widget break, instead of something expensive and hard to find.
Because we live in the future, a replacement part was just a few hours away:
Well, a few hours after installing a replacement thermistor and recalibrating the M2, but nested repairs happen every now and again.
To the road!
After a few days of downtime, an Official Makergear Thermistor arrived and is now installed amid a dab of 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:
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:
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:
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 first production part came out fine:
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:
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:
The multimeter reported absolutely no intermittent dropouts for as long as I was willing to watch the trace while doing other things:
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.
It seems all versions of Raspberry Pis have an I2C bus hardware problem preventing them from working correctly with Adafruit’s Bosch BNO055 (yes, “bee en oh zero five five”) Absolute Position Sensor. The problem has been variously diagnosed as being due to the Pi’s inability to handle clock stretching in arbitrary parts of the I2C transaction and the BNO055 chip’s exquisite sensitivity to I2C bus levels, but it’s worse than that.
Reading the chip’s temperature sensor once every second produced this output:
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:
With clock stretching:
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.
I installed the Adafruit-recommended pullup resistors and we verified they had no effect.
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!
