Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
The big spike over on the left at 125.000 MHz comes from the Ham-It-Up local oscillator. A series of harmonics starting suspiciously close to 125.032768 kHz produces the oneat 125.066 MHz, just to the right of the WWVB signal, which leads me to suspect a rogue RTC in the attic.
There is, in fact, a free running “Test Signal Source” on the Ham-It-Up board:
Ham-It-Up Test Signal source – schematic
Although I have nary a clue about that bad boy’s frequency, measuring it and cutting the inverter’s power trace / grounding the cap may be in order.
The SDR’s AGC contributes about 30 dB of gain, compresses the hottest signals at -25 dB, and raises those harmonics out of the grass, so it’s not an unalloyed benefit. Manually cranking on 10 dB seems better:
WWVB – xtal filter – waterfall – 10 dB hardware preamp – 2017-11-16 0630 EST
The bump in the middle shows the WWVB preamp’s 2 kHz bandwidth around the 60 kHz filter output, so the receiver isn’t horribly compressed. The carrier rises 30 dB over that lump, in reasonable agreement with the manual measurements over a much narrower bandwidth:
60 kHz Preamp – Bandwidth – 1 Hz steps
With all that in mind, a bit of careful tweaking produces a nice picture:
WWVB – xtal filter – waterfall – 10 dB hardware preamp – 2017-11-16 0713 EST
Plugging an Arduino with GRBL into a USB port on a Raspberry Pi 3 with bCNC causes an immediate crash: the Arduino doesn’t power up and the Raspberry Pi stops responding. A hardware reset / power cycle with the Arduino plugged in doesn’t improve the situation, so it seems the Arduino draws more current from the USB port than the default setup will allow.
Most likely, the Arduino’s 47 μF power supply caps draw too much current while charging, as the steady-state current seems to be around 40 mA:
RPi vs Arduino – USB current
The solution / workaround requires a tweak to /boot/config.txt:
#-- boost USB current for Arduino CNC
max_usb_current=1
# blank line above to reveal underscores
Update: As mentioned in the comments, the max_usb_current option doesn’t apply to the Pi 3 you see in the picture and, thus, shouldn’t have changed anything. Your guess is as good as mine.
I’d be more comfortable with a separate power supply plugged into the Arduino’s coaxial power jack, but that’s just me.
You don’t get my patter, but perhaps you’ll get the gist from the pix.
Hearphone – Detail
Summary: I like ’em a lot, despite the awkward form factor and too-low battery capacity. If you’re more sensitive to appearances than I, wait for V 2.0.
Radio communication between our bikes failed on the way back from a grocery ride and the problem turned out to be a failed radio:
Wouxun KG-UV3D – defunct
The Wouxun KG-UV3D radio seems jammed firmly somewhere in its power-up sequence, doesn’t respond to any buttons, and has no hard-reset switch. On the other paw, it’s been in constant (and rugged!) use for almost exactly five years, so I suppose it doesn’t owe me much of anything.
The new radio, another KG-UV3D from PowerWerx, has marginally different spacing around the screw attaching the plug cover preventing the previous screw from fitting, so I kludged up a screw from a 2 mm socket-head screw, a 2.5 mm (yes) washer, and a pair of 2 mm nuts:
Wouxun KG-UV3D – APRS plug plate screw
Which looks a bit odd, but holds the plug adapter plate firmly in place:
Wouxun KG-UV3D – APRS Voice Plug Block
I suppose when the radio on my bike fails, I must rebuild both APRS + voice interfaces for Yet Another Radio, because the Wouxuns will be completely unobtainable.
The weather abruptly became too cold for riding, at least for sissies such as we, but maybe we’ll get out later in the month …
Unlike the last CFL failure, this time I noticed the faint smell of electrical death near the Electronics Workbench, but I couldn’t track it down until the can light over the the Bench didn’t start:
Another Hot-Failed CFL Bulb
The date code suggests it’s been in the fixture for over a decade, so I can’t complain. Having two unrelated bulbs fail within a week, after years of service, is surely coincidence. If another fails within a week or two, however, it will definitely be Enemy Action.
The Fly6 rear camera on my bike started giving off three long beeps and shutting down. Doing the reformatting / rebooting dance provides only temporary relief, so I think the card has failed:
Sandisk Extreme Plus vs. Samsung EVO MicroSD cards
The Fly6 can handle cards up to only 32 GB, which means I should stock up before they go the way of the 8 GB card shipped with the camera a few years ago.
Some back of the envelope calculations:
It’s been in use for the last 19 months
The last 22 trips racked up 88 GB of video data = 4 GB/trip
They occurred over the last 6 weeks = 3.6 rides/week
Call it 250 trips = 1 TB of data written to the card = 32 × capacity
That’s only slightly more than the failure point of the Sony 64 GB MicroSDXC cards. The Fly6 writes about a third of the data per trip, so the card lasts longer on a calendar basis.
So now let’s find out how long the Samsung cards last …
Being a big fan of having a CNC machine know where it is, adding endstops (pronounded “home switches” in CNC parlance) to the Mostly Printed CNC axes seemed like a good idea:
MPCNC – X min endstop – actuator view
All the mounts I could find fit bare microswitches of various sizes or seemed overly complex & bulky for what they accomplished. Rather than fiddle with screws and nut traps / inserts, a simple cable tie works just fine and makes the whole affair much smaller. Should you think cable ties aren’t secure enough, a strip of double stick tape will assuage your doubts.
A snippet of aluminum sheet moves the switch trip point out beyond the roller’s ball bearing:
MPCNC – X min endstop
I’m not convinced homing the Z axis at the bottom of its travel is the right thing to do, but it’s a start:
MPCNC – Z min endstop
Unlike the stationary X and Y axes, the MPCNC’s Z axis rails move vertically in the middle block assembly; the switch moves downward on the rail until the actuator hits the block.
Perforce, the tooling mounted on the Z axis must stick out below the bottom of the tool carrier, which means the tool will hit the table before the switch hits the block. There should also be a probe input to support tool height setting.
The first mount fit perfectly, so I printed four more in one pass:
MPCNC MB Endstop Mounts – Slic3r preview
All three endstops plug into the RAMPS board, leaving the maximum endstop connections vacant:
MPCNC – RAMPS min endstop positions
Obviously, bare PCBs attached to the rails in mid-air aren’t compatible with milling metal, which I won’t be doing for quite a while. The electronic parts long to be inside enclosures with ventilation and maybe dust filtering, but …
The switches operate in normally open mode, closing when tripped. That’s backwards, of course, and defined to be completely irrelevant in the current context.
Seen from a high level, these switches set the absolute “machine coordinate system” origin, so the firmware travel limits can take effect. Marlin knows nothing about coordinate systems, but GRBL does: it can touch off to a fixture origin and generally do the right thing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Smell of Molten Projects in the Morning 