Posts Tagged RPi

Streaming Radio Player: OLED Garble

Even in the dim light of dawn, it’s obvious slowing the SPI clock to 1 MHz didn’t quite solve the problem:

RPi OLED display - garbled

RPi OLED display – garbled

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 …




MPCNC: Z Height Probe vs. Tempered Glass Sheet

Sliding the tempered glass sheet I used for the initial trials and B-size Spirograph plots under the Z height probe eliminated the plywood benchtop’s small-scale irregularities:

MPCNC - Z-probing glass plate

MPCNC – Z-probing glass plate

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?

, ,


Raspberry Pi Swap File Size

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 gr-gsm installation.

Tweak the /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 …

, ,


Samsung EVO Plus 32 GB MicroSD Cards: Verification

A pair of known-good MicroSD cards arrived direct from Samsung at a surprisingly slight premium over the junk available on Amazon:

Samsung EVO Plus MicroSD - 32 GB

Samsung EVO Plus MicroSD – 32 GB

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.


1 Comment

WWVB Reception: 60 kHz Tuning Fork Resonator Filter

Some early morning data from the WWVB preamp with the 60 kHz tuning fork resonator filter in full effect (clicky for more dots):

WWVB - xtal filter - waterfall 5 fps RBW 109.9 Hz Res 0.02 s - gqrx window - 20171116_103542

WWVB – xtal filter – waterfall 5 fps RBW 109.9 Hz Res 0.02 s – gqrx window – 20171116_103542

The dotted line comes from WWVB’s 1 Hz PWM (-ish) modulation: yeah, it works!

The filter cuts out the extraneous RF around the WWVB signal, as compared with a previous waterfall and some truly ugly hash:

WWVB - 24 hr reception AGC - 2017-01-16 to 17 - cropped

WWVB – 24 hr reception AGC – 2017-01-16 to 17 – cropped

Well, not quite all the hash. Enabling the SDR’s hardware AGC and zooming out a bit reveals some strong birdies:

WWVB - xtal filter - waterfall - hardware AGC - 2017-11-16 0612 EST

WWVB – xtal filter – waterfall – hardware AGC – 2017-11-16 0612 EST

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:

Ham-It-Up Test Signal source - schematic

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

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

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

WWVB – xtal filter – waterfall – 10 dB hardware preamp – 2017-11-16 0713 EST

I love it when a plan comes together …

, ,


Raspberry Pi USB vs. Arduino

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

RPi vs Arduino – USB current

The solution / workaround requires a tweak to /boot/config.txt:

#-- boost USB current for Arduino CNC


# 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.

, , ,


Two-Wheel Plotter

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:

Rotary Plotter - geometry 4

Rotary Plotter – geometry 4

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:

Rotary Plotter - geometry 1

Rotary Plotter – geometry 1

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:

Rotary Plotter - geometry 2

Rotary Plotter – geometry 2

After perusing the geometric / triangle solution, this came closer:

Rotary Plotter - geometry 3

Rotary Plotter – geometry 3

, ,