Posts Tagged RPi
The display started up fine, became encrypted during the next few hours, and remained garbled as the track information changed. This is almost certainly a bad SPI transfer trashing the OLED module’s control registers.
Dropping the clock to the absolute minimum of 0.5 MHz didn’t help, either:
serial = spi(device=0,port=0,bus_speed_hz=500000) device = sh1106(serial)
This particular display woke up blank after loading the new code, then worked OK after another reset. The other streamers lit up as expected on the first try, so the slower SPI isn’t making the situation instantly worse.
Running the clock at 1 MHz definitely reduced the failure rate, which suggests it’s a glitchy thing.
Good embedded systems practice suggests resetting the entire display from scratch every now and again, but my streamer code has no concept of elapsed time. Opening that particular can o’ worms would almost certainly result in an on-screen clock and I do not want to go there.
I suppose I must get a new oscilloscope with SPI bus decoding to verify all the SPI setup and hold times …
The first height map looks like a mountain sproinged right up through the glass:
More red-ish means increasing height, more blue-ish means increasing depth, although you can only see the negative signs along the left edge.
The Z axis leadscrew produces 400 step/mm for a “resolution” of 0.0025 mm. The bCNC map rounds to three places, which makes perfect sense to me; I doubt the absolute accuracy is any better than 0.1 mm on a good day with fair skies and a tailwind.
The peak of the mountain rises 0.35 mm above the terrain around it, so it barely counts as a minor distortion in the glass sheet. Overall, however, there’s a 0.6 mm difference from peak to valley, which would be enough to mess up a rigidly held pen tip pretty badly if you assumed the glass was perfectly flat and precisely aligned.
Rotating the glass around the X axis shows a matching, albeit shallower, dent on the other side:
For all its crudity, the probe seems to be returning reasonable results.
The obvious question: does it return consistent results?
As part of some protracted flailing around while trying to get GNU Radio running on a Raspberry Pi 3, I discovered Raspbian defaults to a 100 MB swap file, rather than a swap partition, and everything I thought I knew about swap management seems inoperative. The key hint came from some notes on
/etc/dphys-swapfile config file to set
CONF_SWAPFACTOR=2 for a 2 GB swap file = twice the size of the Pi’s 1 GB memory.
Start it up:
sudo dphys-swapfile swapoff sudo dphys-swapfile setup sudo dphys-swapfile swapon
And verify it worked:
cat /proc/meminfo MemTotal: 949580 kB MemFree: 194560 kB MemAvailable: 594460 kB Buffers: 85684 kB Cached: 377276 kB SwapCached: 0 kB Active: 600332 kB Inactive: 104668 kB Active(anon): 250408 kB Inactive(anon): 20688 kB Active(file): 349924 kB Inactive(file): 83980 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 1918972 kB SwapFree: 1918972 kB Dirty: 40 kB Writeback: 0 kB AnonPages: 242072 kB Mapped: 136072 kB Shmem: 29060 kB Slab: 33992 kB SReclaimable: 22104 kB SUnreclaim: 11888 kB KernelStack: 1728 kB PageTables: 3488 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 2393760 kB Committed_AS: 947048 kB VmallocTotal: 1114112 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 8192 kB CmaFree: 6796 kB
Then it became possible to continue flailing …
A pair of known-good MicroSD cards arrived direct from Samsung at a surprisingly slight premium over the junk available on Amazon:
f3probe reported they’re OK, which is no surprise:
sudo f3probe --time-ops /dev/sdc F3 probe 6.0 Copyright (C) 2010 Digirati Internet LTDA. This is free software; see the source for copying conditions. WARNING: Probing normally takes from a few seconds to 15 minutes, but it can take longer. Please be patient. Probe finished, recovering blocks... Done Good news: The device `/dev/sdc' is the real thing Device geometry: *Usable* size: 29.81 GB (62521344 blocks) Announced size: 29.81 GB (62521344 blocks) Module: 32.00 GB (2^35 Bytes) Approximate cache size: 0.00 Byte (0 blocks), need-reset=no Physical block size: 512.00 Byte (2^9 Bytes) Probe time: 2'04" Operation: total time / count = avg time Read: 51.79s / 4197134 = 12us Write: 1'10" / 4192321 = 16us Reset: 1.41s / 1 = 1.41s
These will go into Raspberry Pi projects, where their huge capacity won’t produce any benefit. It seems one can’t get known-good, small cards these days.
I don’t see much point in buying known-crap counterfeits on Amazon, given their commingled-storage problem as pointed out by their helpful FBA advice:
Use the manufacturer barcode to track inventory
By default, your seller account is set to use the manufacturer barcode to track your eligible inventory throughout the Amazon fulfillment process. You can change this default barcode preference at any time. You have the option to change your barcode preference for each offer you create. You can also change your barcode preference for a product when you change a listing from Fulfilled by Merchant to Fulfilled by Amazon.
Important: Items in your inventory that are identified and tracked using manufacturer barcodes are commingled with items of the same products from other sellers who also use manufacturer barcodes for those items.
If you choose to use manufacturer barcodes, when customers purchase a product from you, Amazon can send the item that is closest to them, even if you didn’t send it to the fulfillment center. When that happens, you get the credit for the sale, and we transfer an item from your inventory to the seller whose inventory was used to fulfill the order. In addition, if you use the manufacturer barcode, you don’t have to apply an Amazon barcode to each item yourself.
Even though inventory tracked using the manufacturer barcode is commingled within the network, the source of the inventory is tracked by our fulfillment systems and is taken into consideration if inventory problems arise.
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.
While contemplating all the hocus-pocus and precision alignment involved in the DIY plotter project, it occurred to me you could conjure a plotter from a pair of steppers, two disks, a lifting mechanism, and not much else. The general idea resembles an Rθ plotter, with the paper glued to a turntable for the “theta” motion, but with the “radius” motion produced by pen(s) on another turntable:
The big circle is the turntable with radius R1, which might be a touch over 4.5 inches to fit an 8.5 inch octagon cut from ordinary Letter paper. The arc with radius R2 over on the right shows the pen path from the turntable’s center to its perimeter, centered at (R1/2,-R1) for convenience.
The grid paper represents the overall Cartesian grid containing the XY points you’d like to plot, like, for example, point Pxy in the upper right corner. The object of the game is to figure out how to rotate the turntable and pen holder to put Pxy directly under the pen at Ixy over near the right side, after which one might make a dot by lowering the pen. Drawing a continuous figure requires making very small motions between closely spaced points, using something like Bresenham’s line algorithm to generate the incremental coordinates or, for parametric curves like the SuperFormula, choosing a small parameter step size.
After flailing around for a while, I realized this requires finding the intersections of two circles after some coordinate transformations.
The offset between the two centers is (ΔX,ΔY) and the distance is R2 = sqrt(ΔX² + ΔY²). The angle between the +X axis and the pen wheel is α = atan2(ΔY,ΔX), which will be negative for this layout.
Start by transforming Pxy to polar coordinates PRθ, which produces the circle containing both Pxy and Ixy. A pen positioned at radius R from the center of the turntable will trace that circle and Ixy sits at the intersection of that circle with the pen rotating around its wheel.
The small rectangle with sides a and b has R as its diagonal, which means a² + b² = R² and the pointy angle γ = atan a/b.
The large triangle below that has base (R2 – a), height b, and hypotenuse R2, so (R2 – a)² + b² = R2².
Some plug-and-chug action produces a quadratic equation that you can solve for a as shown, solve for b using the first equation, find γ from atan a/b, then subtract γ from θ to get β, the angle spearing point Ixy. You can convert Rβ back to the original grid coordinates with the usual x = R cos β and y = R sin β.
Rotate the turntable by (θ – β) to put Pxy on the arc of the pen at Ixy.
The angle δ lies between the center-to-center line and Ixy. Knowing all the sides of that triangle, find δ = arccos (R2 – a) / R2 and turn the pen wheel by δ to put the pen at Ixy.
Lower the pen to make a dot.
Some marginal thinking …
I’m sure there’s a fancy way to do this with, surely, matrices or quaternions, but I can handle trig.
You could drive the steppers with a Marlin / RAMPS controller mapping between angles and linear G-Code coordinates, perhaps by choosing suitable steps-per-unit values to make the degrees (or some convenient decimal multiple / fraction thereof) correspond directly to linear distances.
You could generate points from an equation in, say, Python on a Raspberry Pi, apply all the transformations, convert the angles to G-Code, and fire them at a Marlin controller over USB.
Applying 16:1 microstepping to a stock 200 step/rev motor gives 0.113°/step, so at a 5 inch radius each step covers 0.01 inch. However, not all microsteps are moved equally and I expect the absolute per-step accuracy would be somewhere between OK and marginal. Most likely, given the application, even marginal accuracy wouldn’t matter in the least.
The pen wheel uses only 60-ish degrees of the motor’s rotation, but you could mount four-ish pens around a complete wheel, apply suitable pen lift-and-lower action and get multicolor plots.
You could gear down the steppers to get more steps per turntable revolution and way more steps per pen arc, perhaps using cheap & readily available RepRap printer GT2 pulleys / belts / shafts / bearings from the usual eBay sellers. A 16 tooth motor pulley driving a 60 tooth turntable pulley would improve the resolution by a factor of 3.75: more microsteps per commanded motion should make the actual motion come out better.
Tucking the paper atop the turntable and under the pen wheel could be a challenge. Perhaps mounting the whole pen assembly on a tilting plate would help?
Make all the workings visible FTW!
Some doodles leading up to the top diagram, complete with Bad Ideas and goofs …
Centering the pen wheel at a corner makes R2 = R1 * sqrt(2), which seems attractive, but seems overly large in retrospect:
Centering the pen wheel at (-R1,R1/2) with a radius of R1 obviously doesn’t work out, because the arc doesn’t reach the turntable pivot, so you can’t draw anything close to the center. At least I got to work out some step sizes.
A first attempt at coordinate transformation went nowhere:
After perusing the geometric / triangle solution, this came closer: