Archive for category Electronics Workbench
The folks I’ve been coaching through their plotter build project showed it off at the local MiniMakerFaire this past weekend. Next time around, I’ll insist they secure their circuit boards and use good wiring techniques, so as to avoid destroying more stepper drivers.
To that end, adding mounting holes to my proto board holder seems in order:
The board dimensions now live in an associative array, so you just pick the board name from a Configurator drop-down list:
/* [Options] */ PCBSelect = "ArdUno"; // ["20x80","40x60","30x70","50x70","70x90","80x120","ArdDuemil","ArdMega","ArdPro","ArdUno","ProtoneerCNC"] PCB_NAME = 0; PCB_DIMENSION = 1; PCBSizes = [ ["40x60",[40,60,1.6]], ["30x70",[30,70,1.6]], ["50x70",[50,70,1.6]], ["20x80",[20,80,1.6]], ["70x90",[70,90,1.6]], ["80x120",[80,120,1.6]], ["ArdDuemil",[69,84,1.6]], ["ArdMega",[102,53.5,1.6]], ["ArdPro",[53,53.5,1.6]], ["ArdUno",[69,53.1,1.6]], ["ProtoneerCNC",[69,53.1,1.6]], ];
Which seems easier than keeping track of the dimensions in comments.
You can now put the PCB clamp screws and mounting holes on specific corners & sides, allowing oddball locations for Arduino boards with corner cutouts along the right edge:
A “selector” notation separates the hole location from the board dimensions & coordinates:
ScrewSites = [ // [-1,1],[1,1],[1,-1],[-1,-1], // corners // [-1,0],[1,0],[0,1],[0,-1] // middles [-1,1],[-1,-1],[1,0] // Arduinos ];
Might not be most obvious way, but it works for me. Most of the time, corner clamps seem just fine, so I’m not sure adding the clamp and mounting hole locations to the dimension array makes sense.
The OpenSCAD source code as a GitHub Gist:
Rather than bestir myself to measure the Test Signal Source on the Ham-It-Up upconverter:
The 74LVC2G14 Schmitt-Trigger Inverter datasheet supplies useful parameters:
All of which come together and produce a waveform (clicky for more dots):
Which suggests the Test Signal ticks along at tens-of-MHz, rather than the tens-of-kHz I expected from the birdies in the filtered 60 kHz preamp response.
Of course, hell hath no fury like that of an unjustified assumption, so actually measuring the waveform would verify the cap value and similar details.
The dotted line comes from WWVB’s 1 Hz PWM (-ish) modulation: yeah, it works!
Well, not quite all the hash. Enabling the SDR’s hardware AGC and zooming out a bit reveals some strong birdies:
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 one at 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:
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:
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:
With all that in mind, a bit of careful tweaking produces a nice picture:
I love it when a plan comes together …
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:
The solution / workaround requires a tweak to
#-- 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.
The PDF “slides” for a lightning talk I gave at this month’s MHV LUG meeting: MHVLUG Lightning Talk – Bose Hearphones.
You don’t get my patter, but perhaps you’ll get the gist from the pix.
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.
FWIW, I tinkered up a beamforming microphone array with GNU Radio that worked surprisingly well, given a handful of hockey puck mics and a laptop. Bose does it better, of course, but I must revisit that idea.
Radio communication between our bikes failed on the way back from a grocery ride and the problem turned out to be a failed radio:
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:
Which looks a bit odd, but holds the plug adapter plate firmly in place:
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:
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.