Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
The DRV8825 stepper driver chip has a -Home output going active during the (micro)step corresponding to 45°, where both winding currents equal 71% of the peak value:
DRV8825 pinout
Unfortunately, pin 27 is another unconnected pin on the DRV8825 PCB, without even a hint of a pad for E-Z soldering.
It’s also an open-drain output in need of a pullup, so I globbed on a 1/8 W 10 kΩ resistor in addition to the tiny wire from the IC pad to the left header pin:
DRV8825 PCB – Home signal output
Read it from the right: brown black black red gold. Even in person, the colors don’t look like that, not even a little bit: always measure before installation!
The right header pin is firmly soldered to the PCB ground pin I also used for the 1:8 microstep hack. The whole affair received a generous layer of hot melt glue in the hope of some mechanical stabilization, although hanging a scope probe off those pins can’t possibly end well.
The general idea is to provide a scope sync output independent of the motor speed, so I can look at the current waveforms:
3018 X – Fast – 12V – 140mm-min 1A-div
The alert reader will note the pulse occurs on the down-going side of the waveforms, which means I have the current probes clipped on backwards or, equivalently, on the wrong wire. The point is to get a stable sync, so it’s all good no matter which way the current goes.
It’s been sitting there for least five years, as witnessed by the sun-yellowed hot melt glue blob, which is pretty good service from a switch intended for indoor use. The 3D printed button never fell off and, in fact, was difficult to remove, so that worked well.
I took it apart and cleaned the contacts, but to no avail, so her bike now sports a new switch with a similar rounded dome:
Tour Easy – new PTT switch
I clipped the wires a bit beyond the terminals and soldered the new switch in place, so it’s the same cable as before.
Unfortunately, the thermal tape on one of the CPU heatsinks was sufficiently wrinkled to prevent good contact with the CPU:
RPi taped heatsinks – as received
The seller sent a replacement copper slug with tape on one side. Presumably, they glue it to the heatsink with thermal silicone:
Moster RPi Heatsink – silicone adhesive
Of which, I have none on hand.
So I did what I should have done originally, which was to drop a few bucks on a lifetime supply of thermally conductive heatsink tape, apply it to the bare side of the slug and stick the slug to the heatsink with their tape:
Moster RPi Heatsink – replacement adhesive tape
The blue stuff is the separation film, with the tape being white. It doesn’t match the black tape on the other side, but seems gooey enough to work.
Done!
Despite the heatsink hype, ball grid array chips dissipate most of their heat through their pads (and perhaps a central thermal pad) into the PCB, so sticking a heatsink atop the package is largely decorative, along the lines of hotrod ornamentation.
The epoxy packages used in previous Raspberry Pi iterations had better thermal conductivity to their top surface:
RPi 3 B – epoxy CPU
Than the more recent metal-top packages, which surely have inert-gas fill under the lid:
Yes, the heatsink does conduct some heat into the air, even if not nearly as much as you might want.
(*) I’m pretty sure “Moster” was a typo in the original eBay listing which took on a life of its own to become something of an unofficial trademark. All of the search results ship from Duluth, Georgia (USA), regardless of the nominal seller; feel free to draw your own conclusions.
Fiddle with the amp to select the phonograph, poke the TAPE 2 button to send audio to/from the UCA202, fire up an SSH session, kill the streaming audio program, and figure out what audio hardware is out there:
$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
Not much else to choose from on a Raspberry Pi, so see what the UCA202 can do:
Given those limited choices, 16 bit little-endian at 48 kHz seems like a no-brainer.
Find out all the ALSA device names:
$ arecord -L
null
Discard all samples (playback) or generate zero samples (capture)
sysdefault:CARD=CODEC
USB Audio CODEC, USB Audio
Default Audio Device
front:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Front speakers
surround21:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
4.0 Surround output to Front and Rear speakers
surround41:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Direct sample mixing device
dsnoop:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Direct sample snooping device
hw:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Direct hardware device without any conversions
plughw:CARD=CODEC,DEV=0
USB Audio CODEC, USB Audio
Hardware device with all software conversions
They all point to the same hardware, so AFAICT the default device will work fine.
Try recording something directly to the RPi’s /tmp directory, using the --format=dat shortcut for “stereo 16 bit 48 kHz” and --mmap to (maybe) avoid useless I/O:
$ arecord --format=dat --mmap --vumeter=stereo --duration=$(( 30 * 60 )) /tmp/Side\ 1.wav
Recording WAVE '/tmp/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+02%|01%+ overrun!!! (at least 1.840 ms long)
+02%|02%+ overrun!!! (at least 247.720 ms long)
+# 07%|06%##+ overrun!!! (at least 449.849 ms long)
+ 03%|02%+ overrun!!! (at least 116.850 ms long)
Huh. Looks like “writing to disk” sometimes takes far too long, which seems to be the default for MicroSD cards.
The same thing happened over NFS to the file server in the basement:
$ arecord --format=dat --mmap --vumeter=stereo --duration=$(( 30 * 60 )) /mnt/part/Transfers/Side\ 1.wav
Recording WAVE '/mnt/part/Transfers/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+ 09%|07% + overrun!!! (at least 660.372 ms long)
+# 08%|06%# + overrun!!! (at least 687.906 ms long)
So maybe it’s an I/O thing on the RPi’s multiplexed / overloaded USB + Ethernet hardware?
Trying a USB memory jammed into the RPi, under the assumption it might be better at recording than the MicroSD Card:
$ arecord --format=dat --mmap --vumeter=stereo --duration=$(( 30 * 60 )) /mnt/part/Side\ 1.wav
Recording WAVE '/mnt/part/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+01%|01%+ overrun!!! (at least 236.983 ms long)
Well, if it’s overrunning the default buffer, obviously it needs Moah Buffah:
$ arecord --format=dat --mmap --vumeter=stereo --buffer-time=1000000 --duration=$(( 30 * 60 )) /mnt/part/Side\ 1.wav
Recording WAVE '/mnt/part/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+## 10%|06%# + overrun!!! (at least 359.288 ms long)
When brute force doesn’t work, you’re just not using enough of it:
$ arecord --format=dat --mmap --vumeter=stereo --buffer-time=2000000 --duration=$(( 30 * 60 )) /mnt/part/Side\ 1.wav
Recording WAVE '/mnt/part/Side 1.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
+00%|00%+
Sampling four bytes at 48 kHz fills 192 kB/s, so a 2 s buffer blots up 384 kB, which seems survivable even on a Raspberry Pi.
The audio arrives at 11.5 MB/min, so an LP side with 20 min of audio will require about 250 MB of disk space. The USB memory was an ancient 2 GB card, so all four sides filled it halfway:
$ ll /mnt/part
total 1.1G
drwxr-xr-x 2 ed root 4.0K Dec 31 1969 ./
drwxr-xr-x 17 root root 4.0K Jun 7 19:15 ../
-rwxr-xr-x 1 ed root 281M Sep 1 14:38 'Side 1.wav'*
-rwxr-xr-x 1 ed root 242M Sep 1 15:01 'Side 2.wav'*
-rwxr-xr-x 1 ed root 265M Sep 1 15:27 'Side 3.wav'*
-rwxr-xr-x 1 ed root 330M Sep 1 15:58 'Side 4.wav'*
Side 4 is a bit longer than the rest, because I was folding laundry and the recording stopped at the 30 minute timeout after 10 minutes of silence.
Now, to load ’em into Audacity, chop ’em into tracks, and save the lot as MP3 files …
Which suggested putting it in a ball mount for E-Z aiming:
CNC 3018-Pro – Probe Camera – ball mount
Black filament snippets serve as alignment pins to hold the ball halves together while they’re getting clamped. They’re epoxied into the upper half of the ball, because who knows when I’ll need to harvest the camera.
USB Camera – Round PCB Mount – solid model – build
The clamp pieces fit around the ball with four M3 screws providing the clamping force:
USB Camera – Round PCB Mount – solid model sectioned
The whole affair sticks onto the Z axis carrier with double-sided foam tape:
CNC 3018-Pro – Probe Camera – alignment
It barely clears the strut on the -X side of the carriage, although it does stick out over the edge of the chassis.
After the fact, I tucked a closed-cell foam ring between the lens threads and the ball housing to stabilize the lens; the original camera glued the thing in place, but some fiddly alignment & focusing lies ahead:
Alignment mirror – collimation
It’s worth noting that the optical axis of these cheap cameras rarely coincides with the physical central axis of the lens. This one requires a jaunty tilt, although it’s not noticeable in any of the pictures I tried to take.
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 ball-shaped Logitch QuickCam Pro 5000 has a rectangular PCB, so conjuring a case wasn’t too challenging:
Probe Camera Case – Logitech QuickCam Pro 5000 – bottom
That’s more-or-less matte black duct tape to cut down reflections.
The top side has a cover made from scuffed acrylic scrap:
Probe Camera Case – Logitech QuickCam Pro 5000 – top
The corners are slightly rounded to fit under the screw heads holding it in place.
The solid model shows off the internal ledge positioning the PCB so the camera lens housing rests on the floor:
3018 Probe Camera Mount – solid model
The notch lets the cable out, while keeping it in one place and providing some strain relief.
I though if a camera was recognized by V4L2 and worked with VLC, it was good to go:
Logitech QuickCam Pro 5000 – short focus
Regrettably, it turns out the camera has a pixel format incompatible with the Python opencv interface used by bCNC. This may have something to do with running the code on a Raspberry Pi, rather than an x86 box.
The camera will surely come in handy for something else, especially with such a cute case.
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 CAMTool V3.3 board on the CNC 3018-Pro hardwires the three DRV8825 stepper driver chips in 1:32 microstep mode by pulling all three Mode pins high. Unlike most CNC boards, it does not include jumpers to let you select different microstep modes; the designers know you want as many microsteps as you can possibly get.
As it turns out, 1:32 microstep mode requires 1600 steps for each millimeter of travel and, because GRBL tops out around 30 k step/s, the maximum speed is about 18.75 mm/s = 1125 mm/min. Which isn’t at bad, but, because I intend to use the thing for engraving, rather than the light-duty machining it’s (allegedly) capable of performing, running at somewhat higher speeds will be desirable.
For sure, a 3018-Pro does not have a physical resolution of 625 nm.
If you’re willing to settle for a mere 400 step/mm = 2.6 µm, then you can just ground the Mode 2 pin to get 1:8 microstep mode:
DRV8825 – Stepper Motor Controller – Microstep Modes
Rewiring the CAMTool board isn’t feasible, but hacking the DRV8825 carrier PCB doesn’t require much effort.
So, we begin.
Clamp the PCB in a vise, grab the Mode 2 pin with a needle-nose pliers, apply enough heat to melt the solder completely through the board, and yank that pin right out:
CAMTool V3.3 – DRV8825 M2 pin removed
I do wonder how the layout folks managed to reverse the “N” for the Enable pin. Perhaps it’s a Cyrillic И in a dead-simple font?
With that done, add a snippet of wire from M2 to the GND pin in the opposite corner to complete the job:
CAMTool V3.3 – DRV8825 wired for 8 ustep mode
Despite that picture, remember to plug the DRV8825 boards into the CAMTool V3.3 board with the heatsink downward and the twiddlepot on the top, as shown in the little instruction book you got with the hardware:
The Smell of Molten Projects in the Morning 