Posts Tagged RPi
Of late, the OLED displays on two RPi 3 streaming players (the others are RPi 2) have occasionally gone blank, while the players continue to work fine. I checked the logs, swapped MicroSD cards, rebuilt the images, and generally screwed around, all to no avail. The SH1106 controller has a command containing a single bit to blank the display and, perhaps, an SPI data transfer error could shut it off.
This is much harder to explain:
There’s a hardware command to flip the display top-to-bottom, not left-to-right. The Luma OLED driver can rotate the display in 90° increments, but AFAICT not reflect it.
Yes, they’re networked, but, no, they’re not directly exposed to the Intertubes.
Changing streams had no effect. Shutting down and rebooting restored normal operation.
There’s been exactly one such failure so far, so I lack evidence.
I have no clue what’s going on.
The Sandisk Extreme Pro 64 GB MicroSD card in the Sony HDR-AS30V died on the road once more, got reformatted, worked OK for a while, then kicked out catastrophic I/O errors after being mounted, so I swapped in the High Endurance card:
The Extreme Pro still passes the f3probe tests, so it’s not completely dead, but if I can’t trust it in the helmet camera, it’s dead to me.
It survived 17 months of more-or-less continuous use, although we didn’t do nearly enough riding for three months early this year. Call it 14 months x five rides / week x 1 hour / ride = 300 hours of recording. Multiply by 4 GB / 22.75 minutes to get 3 TB of video, about 50 times its total capacity.
The never-sufficiently-to-be-damned Sony cards failed after less than 1 TB and 15-ish times capacity, making the Sandisk Extreme Pro much better. However, it’s painfully obvious these cards work better for low-intensity still-image recording, rather than continuous HD video.
Using them as Raspberry Pi “hard drives” surely falls somewhere between still cameras and video, although Octoprint’s video snapshots and streaming media must make ’em sweat.
We’ll see how Sandisk’s High Endurance memory works in precisely the application it’s labeled for.
Every now & again, streaming music from distant servers fails, for no reason I can determine. In that situation, it would be nice to have a local source and, as
mplayer works just fine when aimed at an MP3 file, I tried to set up a USB stick on the ASUS router.
That requires getting their version of SAMBA working with the Raspbian Lite installed on the streaming players. After screwing around for far too long, I finally admitted defeat, popped the USB stick into the Raspberry Pi running the APRS iGate in the attic stairwell, and configured it as an NFS server.
To slightly complicate the discussion, there’s also a file server in the basement which turns itself off after its nightly backup. The local music files must be available when it’s off, so the always-up iGate machine gets the job.
On the NFS server:
nfs-common, both of which should already be included in stock Raspbian Lite, and
nfs-kernel-server, which isn’t. There were problems with earlier Raspbian versions involving the startup order which should be history by now; this post may remind me what’s needed in the event the iGate NFS server wakes up dead after the next power blink.
/etc/exports to share the mount point:
/mnt/music *(ro,async,insecure,no_subtree_check) # blank line so you can see the underscores in the previous one
Plug in the USB stick, mount, copy various music directories from the file server’s pile o’ music to the stick’s root directory.
Create a playlist from the directory entries and maybe edit it a bit:
ls -1 /mnt/part/The_Music_Directory > playlist.tmp sed 's/this/that/' < playlist.tmp > playlist.txt rm playlist.tmp
Tuck the playlist into the Playlists directory on the basement file server, from whence the streamer’s
/etc/rc.local will copy the file to its local directory during the next boot.
On every streamer, create the
/mnt/music mountpoint and edit
/etc/rc.local to mount the directory:
nfs_music=192.168.1.110 <<< snippage >>> mount -v -o ro $nfs_music:/mnt/music /mnt/music # blank line so you can see the underscores in the previous one
In the Python streaming program on the file server, associate the new “station” with a button:
'KEY_KP8' : ['Newname',False,['mplayer','-shuffle','-playlist','/home/pi/Playlists/playlist.txt']],
The startup script also fetches the latest copy of the Python program whenever the file server is up, so the new version should Just Work.
I set the numeric keypad button associated with that program as the fallback in case of stream failures, so when the Interwebs go down, we still have music. Life is good …
The white OLED displays measure 1.3 inches diagonally:
They’re plug-compatible with their 0.96 inch blue and yellow-blue siblings.
All of them are absurdly cute and surprisingly readable at close range, at least if you’re as nearsighted as I am.
Some preliminary fiddling suggests a Primary Red filter will make the white displays more dark-room friendly than the yellow-blue ones. Setting the “contrast” to 1 (rather than the default 255) doesn’t (seem to) make much difference, surely attributable to human vision’s logarithmic brightness sensitivity.
I must conjure some sort of case atop a bendy wire mount for E-Z visibility.
In order to probe a crystal’s response with decent resolution, I need a gadget to step a decent-quality sine wave by 0.01 Hz across the 10-to-100 kHz range and a logarithmic front end with a decent dynamic range. That’s prompted by looking at crystal responses through the SA’s 30 Hz resolution bandwidth:
Mashing a cheap AD9850/AD9851 DDS board against an Arduino Pro Mini, adding a knob, and topping with a small display might be useful. A Raspberry Pi could dump the response data directly into a file via WiFi, which may be more complication that seems warranted.
The DDS boards come with absurdly high-speed clock generators of dubious stability; a slower clock might be better. A local 10 MHz oscillator, calibrated against the 10 MHz output of the HP 3801 GPS stabilized receiver would be useful. If the local oscillator is stable enough, a calibration adjustment might suffice: dial for 10 MHz out, then zero-beat with the GPS reference, so that the indicated frequency would be dead on to a fraction of 1 Hz.
The HP 8591 spectrum analyzer has a better-quality RF front end than I can possibly build (or imagine!), but, at these low frequencies, a simple RF peak detector and log amp based on the ADL5303 or ADL5306 should get close enough. One can get AD8302 / AD8310 chips on boards from the usual low-budget suppliers; a fully connectorized AD8310 board may be a good starting point, as it’s not much more than the single-connector version.
With frequencies from 10 kHz to 100 kHz coming from a local oscillator, one might argue for a synchronous detector, formerly known as a lock-in amplifier. A Tayloe Detector might be a quick-and-dirty way to sweep a tracking-filter-and-detector over the frequency range. Because it’s a tracking generator, the filter bandwidth need not be very tight.
At some point, of course, you just digitize the incoming signal and apply DSP, but the whole point of this is to poke around in the analog domain. This must not turn into an elaborate software project, too.
At first, the yard camera worked fine, but a few days later the stream of JPEG images would unpredictably stall. I connect to it through a public-key SSH session and, sometimes, the login would stall for tens of seconds and, with a session set up, various exciting operation like, say,
htop would unpredictably stall; if I waited long enough, they’d complete normally.
It’s a known-good card from a reputable supplier, not that that means much these days. The camera flash highlights the gritty silkscreen (?) texture of the orange overlay, but the production value seems high enough to pass muster.
Popping the card in my desktop PC showed:
- It remains functional, at least to the extent of being mount-able and write-able
3probe --time-ops /dev/sdbshowed it still held 16 GB
fsck -fv /dev/sdbshows no problems
- Both partitions looked good
So I shrank the main partition to 7.5 GB, copied the image to the desktop PC’s SSD, fired up the Token Windows Laptop, ran the Official SD Card Formatter, and discovered that it thought the card had only 63 MB (yes, MB) available. That’s the size of the FAT
boot partition, so I returned the card to the desktop PC, unleashed
gparted on it, blew away the partitions, reformatted the whole thing to one 16 GB FAT32 partition, and stuck it back in the laptop, whereupon the Official Formatter agreed it had every byte it should.
A format-with-overwrite then proceeded apace; the card doesn’t support format-with-erase.
Back in the desktop, I copied the saved image back onto the card which, en passant, blew away the just-created FAT format and restored the Raspbian partition structure. The 8 GB of that copy proceeded at an average 12.1 MB/s. I did not watch the transfer closely enough to notice any protracted delays.
Back in the Pi, the card booted and ran perfectly, sending an image every second to the laptop (now running its usual Mint Linux) on the guest network:
SSH sessions now work perfectly, too, and commands no longer jam.
So it seems a good-quality MicroSD card can experience protracted delays while writing data, to the extent of tens of seconds, stalling the Pi in mid-operation without producing data errors or any other symptoms.
It’s not clear the Official Formatter does anything that simply copying the image back to the card wouldn’t also accomplish, although overwriting the entire 16 GB extent of the card exercises all the cells and forces the card controller to re/de/un/allocate bad blocks. If, indeed, the blocks are bad, rather than just achingly slow.
Moral of the story: Don’t use MicroSD cards as mass storage devices, at least not for industrial applications that require consistent performance.
The yard camera I mentioned a few days ago consists of a Raspberry Pi 3 with an Official V2 Pi Camera peering through two layers of 1955-era window glass into our back yard:
Yes, that’s black duct tape holding it to the window pane. The extension cord draped across the floor gotta go, too.
This being a made-in-haste lashup, I used the streamEye MJPEG HTTP streamer, started from
/etc/rc.local in the usual way:
logger -s Starting camera streamer sudo -u pi sh -c '/home/pi/yardcam.sh' & logger -s Camera running
yardcam.sh script feeds one moderate-quality frame to the streamer every second:
/home/pi/streameye/extras/raspimjpeg.py -w 1280 -h 720 -r 1 -q 80 | streameye
MJPEG has a lot to dislike as a streaming video format. In particular, without any hint of inter-frame compression, the network usage gets way too high for any reasonable frame rate.
But it got the camera up & running in time for the March snowfall:
In a nod to IoT security, the Raspberry Pi’s wireless interface sits behind the router’s firewall on our guest network, with no access to the devices on our main network. The router passes a one-port peephole from the Internet to the Pi, which protects all the other services from unwarranted attention.
The router maintains a dynamic DNS record with a (not particularly) mnemonic URL, which seems better than an ever-changing dotted-quad IP address.
Because the router doesn’t support hairpin connections from the main network to the guest network, I can’t monitor the video from my desktop through the outwardly visible URL. Instead, I must fire up a laptop, connect to the guest network, then connect directly to the camera at
You do not have a Need To Know for the URL; I’m sure it’ll appear on Shodan. I plan to take it down when the snow melts.