Create Indestructable SBC's with overlaysf -- Cut the Power, Scotty!

A fun discussion at a geeky tech meetup lunches:

You have a Linux single board computer or "SBC" (or any Linux host) as the basis of a cool DiWHY audio project what is the best way to shut it down?  

Easy!

sudo shutdown now #or something like this--depends on distro

....of course. The command makes the OS spin everything down without stressing the file system.

But what if the linux system is an appliance and someone yanks the power cable without issuing said command? 

Any habitual Linux user knows: bad idea. The file system will attempt to recover from an abrupt shutdown, and usually will, but every now and then: not as much.

But--there must be a way to do this!

There are Linux based routers, set top boxes, Internet TV's and everything else, routinely surviving abrupt power loss. 

 

How do they work? 

Huge shout out to group member MVCL who pointed me to OpenWRT, a Linux based router appliance, and the technology it uses to survive power hits--overlayfs--more info here.

In the coming months I'd like to create an SBC based appliance that can survive a power hit. Could I get it to work?  

Yep..

CHEAT CODE--OVERLAYFS ON A NOVEMBER 2025 RASPBERRY PI:

The folks at RPi abstracted all the tough configuration away.

Get a Raspberry Pi (I used one of these) and Raspberry Pi OS Lite (download it here)

Install the OS 

Then:

sudo apt-get install overlayroot

 Edit this file:

sudo vi /boot/firmware/cmdline.txt  

# add to the end of the single line in cmdline.txt: overlayroot=tmpfs   

Reboot--

BAM! you are good--the OS is read only; contents on the SD card are copied to RAM during boot; end user changes are stored entirely in RAM.

If you pull power your OS configuration is safe; RAM contents are lost; at power up the process starts over.

That's it! 

Are we done? 

Nooooo.....

• What about other distros (like Debian 13)?  Same steps?
• How does overlayfs work at a deeper level?  
• How do we change the read-only OS to do things like change configuration files and perform updates?

TESTING OVERLAYFS WITH VM's

For proofs-of-concept I created 2 VMware Workstation Pro Debian VM's: One to experiment with overlayfs' basics, another to create a "kiosk system" that could survive power hits.

Creating the first VM was pretty easy, here are the steps:

#in Debian, add user your username to sudoers

#this makes sudo commands work like ubuntu.

su - #use the minus to preserve paths for normal user.

usermod -aG sudo charlie #I am user charlie, you are not.

#use your username instead of charlie, elmo.

#-----------------------------

#OverlayFS requires 4 directories to work.

#lower directory: the OS

#Upper directory: where changes are stored

#work directory: the kernel prepares files before moving them to #upper layer

#merged directory: the mountpoint the end user sees

# Create a main project folder

mkdir ~/overlay_lab

cd ~/overlay_lab

# Create the four required directories

mkdir lower upper work merged

#What these directories will be used for.

#overlay: The device name (can be anything, but overlay is standard).

#-o: Specifies we are adding options.

#lower dir: The bottom layer. This is a directory used by overlayfs.

#upper dir: The writable top layer.

#This is a directory used by overlayfs

#work dir: The directory for internal operations 

#(must be on the same partition as upperdir).

#merged: The mount point.  This is what the end user sees.

#-----------------------------------------------

#put data into lower dir. from overlay_lab dir:

echo "I am a base system file." > lower/base_config.txt

echo "Do not delete me." > lower/important_data.txt

#-----------------------------------------------

#run the overlayfs mount cmd. watch the line wrap!

sudo mount -t overlay overlay -o lowerdir=lower,upperdir=upper,workdir=work merged

#now you can see in merged these 2 files that came from lower.

#what does it all mean?

#changes to files in merged directory are mimicked to upper 

#deletions in merged directory cause a "whiteout" file in upper, #"masking" the deleted file

#files added to upper (copying a read only OS for instace are copied #to merge dir

#if you edit a file in upper the edits do not appear in merged.

#if you edit fstab incorrectly you'll brick your SBC. This is why we #snapshot experimental VM's!

#edit fstab so your new configuration isn't lost at reboot 

#you are going to want to create a VM snapshot

#before you mess with fstab. (watch the wrap for the following cmd)

overlay /home/charlie/overlay_lab/merged overlay noauto,x-systemd.automount,lowerdir=/home/charlie/overlay_lab/lower,upperdir=/home/charlie/overlay_lab/upper,workdir=/home/youruser/overlay_lab/work 0 0

All of this means that you have created a new mount at startup; "merge" is the directory where your active files will reside. Other directories are hands-off--pretty easy.

No Sh*t Sherlock: Docker makes heavy use of overlayfs. Didn't know that! Video here.

AND NOW--A WORD FROM THE BLOG'S SPONSOR:

               

 

After getting your kiosk setup going, you might want to design a hat for your SBC then get a bunch of them fabricated.

For this, you should use PCBWAY. 

This month PCBWAY is featuring some awesome holiday specials, details here.

PCBWAY has a service to fabricate PCBs and other materials using any and all visible colors. Imagine that--full color PCB's! Details here. 

In addition to top notch PCB fabrication they also do fantastic work with assembly, 3D printing, injection molding, and so so SO much more. 

Their staff is super friendly and PCBWAY always turns work around quickly. 

I am always impressed! 

As always--you can help this blog by checking out the PCBWAY site. Thanks.

CREATING THE "KIOSK" VM

On a second Debian VM here are the steps I used to configure the kiosk VM:

#root and login

su -

#make sure overlayroot is installed. Should be....if not....

apt-get update

apt-get install overlayroot

#add overlay module on next boot. 
#we are adding overlay as a single line to the bottom of the modules #file.

echo "overlay" | tee -a /etc/initramfs-tools/modules

#edit grub; do this carefully 

vi /etc/default/grub

#change the GRUB_CMDLINE_LINUX_DEFAULT to this (quotes are needed)

GRUB_CMDLINE_LINUX_DEFAULT="quiet overlayroot=tmpfs"

#save the file (":wq!)

#rebuild grub

update-grub

update-initramfs -u

#reboot.

#------------------

file system (dh -f) should look like this.

The main thing: overlayroot is now mounted as /

For me, I could force-power-off the VM and restart--yep, all seemed OK.  

After several reboots I didn't see tons of inode rebuild errors and whatnot. The virtual machine survived the power hits A-OK.

So far, so good.

HOW DO I CHANGE THE READ-ONLY FS?

To make minor changes to the read only partition:

overlayroot-chroot

(make changes--apt installs, for instance)

when done...

exit

I could use this for apt installs and updates...."exit" sometimes threw errors, but my changes stuck.

-----------------

Another method: this flipped me back to normal Debian once; when I rebooted the OS it was back to overlayfs mode. 

I read this is best for major OS changes and configuration file redo's.

1. Reboot the VM.

2. At the GRUB menu, press e.

3. Find the line with overlayroot=tmpfs.

4. Change it to overlayroot=disabled.

5. Press F10 to boot. (You are now in a standard, persistent Debian environment).

6. to check: mount | grep overlay # produces no output. overlayfs is not #running.

7. Run your updates, then reboot to re-enable protection.

Finally, I deployed a trick for advanced Linux nerds.....allowing a menu choice in GRUB to disable overlayfs, visible from the initial grub menu seen at startup--info here....

Editing grub configurations is not for the faint of heart and can potentially brick your SBC's OS configuration; if you aren't into moderate to advanced Linux tweaking you should probably skip this option.

#--------------------------------------------------

Follow the "go to normal once" mode using e key, above.

Once in normal mode create some text we will need later.

grep -A 20 "menuentry '" /boot/grub/grub.cfg >>  grub.txt

Now use vi to open 2 files at once:

vi /boot/grub/grub.txt /etc/grub.d/40_custom

once in vi you see grub.txt....issue this command (no : needed)

20yy

this yanks the top 20 lines of the grub.txt file. 

in vi, issue escape then this command

:bn

this flips you to the 40_custom file, then type

p

this pastes the 20 lines from the bottom of the grub.txt file

...now edit the 40_custom file to match what I have boxed in red:

reboot.

If all went well you get a new option each time you reboot: choosing what is boxed below puts you into "normal" mode. Make OS changes; reboot, and pick "Debian GNU/Linux" to go back to overlayfs.

MORE ABOUT OVERLAYFS ON MY RPI SBC

SBC setup for overlayfs. Most important component: the coffee.

As I said at the beginning of this post--getting overlayfs working on a current Raspberry Pi was a piece of cake.

Because I will forget all of this in about 3 hours, here's more detail about what I did:

I used a RPi 4B purchased in 2018.  

Next I downloaded the latest "Trixie" text-only Raspberry PI OS and RPi imager. 

Getting wireless to work in text-only RPi Trixie was a giant time waster; raspi-config was throwing up errors that made no sense such as:

Could not communicate with wpa_supplicant

 entering the error messages into AI took me down rabbit holes that were nonsense.  

 

In the end, I didn't let the RPi imager create a custom configuration. Each time I did the Wi-Fi configuration on boot was broken and couldn't be easily fixed.

I ended up doing a standard install of PI OS and configured Wi-Fi settings on first boot via its wizard.

I had to type in the SSID exactly (doh); but, why did that not work at first?  

After some head scratching: what I called my home Wi-Fi SSID and what the RPi thought it was called were different.

The command in the "Trixie" version of RPI OS to list of available Wi-Fi SSID's was something I'd never seen before:

sudo nmcli dev wifi list  #yeh, I knew that.

There was a difference in case, RADISH vs. Radish. I entered Radish, then raspi-config worked OK; no bonkers error messages. 

With wireless working, I sudo raspi-config again, option 3, interfaces, and enabled SSH.

Cool, what IP to SSH into?

ip -a

This revealed the IP of the RPi. I could SSH into the host.

Next I followed the same steps for overlayfs on Raspberry Pi, stated at the top of this post, only 3 steps were needed.

sudo apt-get install overlayroot

then

sudo vi /boot/firmware/cmdline.txt  

# add to the end of the single line: overlayroot=tmpfs

sudo shutdown -r now  #reboot to overlayfs

To go back to normal RPI (not overlay): I pulled the SD card and edited /boot/firmware/config.txt on my Windows 11 PC (raspberry OS is formatted fat32, so yes, this worked), getting rid of overlayroot=tempfs then saving cmdline.txt.  

I could make a copy of the single line in cmdline.txt, add the string above to one of them, and comment out the line I didn't want using a #.

WHAT'S NEXT?

I need to get rid of the SBC's mandatory login, then conjure a DIY app for the junker RPi.  It has I2C, SPI, serial UART, all the usual stuff; perhaps what can be done with an Arduino Nano can be done here....I have this old sequencer idea (here) that i could continue to work on....  

Regardless: overlayfs is an important technology....instead of just entering the cheat code I dug in a bit further. Now I know more a widely implemented and important technology. 

This knowledge will ultimately enrich my work skills, my sense of professionalism, and my piwece of mind.

There is a lesson here? Nope. Next time: just use the damn cheat code.

Canva Affinity and Kicad 9: Graphical Madness for DiWhy Projects

Many thanks Elton at Otter Mods for introducing me to Kicad and Affinity.

============

When I look at professionally created front panels, surrounding knobs I often see "goes to 11" gradients:

                             

(What are these called? Dials? Tick marks? Tap Mach II? I'm not sure, but, I wanted to add them to my front panels. 

For the post I'll call them "dials").

Using the built-in graphics tools in Kicad 9 didn't get me far, but found I could import graphics into Kicad as footprints, then add them to PCB's used as front panels on a silkscreen layer. 

OK, how?

There are two graphics import methods in Kicad I know of:  

First--easy: through Kicad's main menu I could turn PNG graphics into bitmaps, using the Image Converter tool. 

Works, but, I found at times the output was grainy.  

What else?

Elton at Otter Mods, the resident Kicad expert of my geeky tech group, described a better way:

Use Affinity Designer to create SVG formatted files, then import the files into Kicad as footprints. Finally, place the graphic footprints onto your front panels.

Today's post outlines a workflow to do this--this may be documented somewhere, but I couldn't find it, and ChatGPT was out to lunch.

CANVA AFFINITY 

First I needed to get Canva Affinity, Elton's choice for creating SVG graphics. 

Tough choice. Pay enormous bucks for an Adobe Creative Cloud subscription, complete with hidden fees, a confusing cloud presence, and terrible tech support? 

Nope. Good news: like Kicad 9, Canva Affinity is free. 

Or is it? I had to set up a Canva account, last I heard the friendly Canva folks aren't a 501C, rather someone has to buy lunchroom donuts and most important: keep the shareholders happy.  

Whatever....I set up a "free" Canva account, downloaded Affinity, and installed it on my W11 PC. 

So far, so good.

Hazzah! After a few hours of trying out the new Affinity: it felt like a true Adobe killer, combining features found in Illustrator, Photoshop, and InDesign, in one mega-graphics app. Affinity can do most everything Adobe-like, except grab you by your legs, flip you upside-down, shake you, then pocket the change that falls out.

For creating dials I focused on Affinity's VECTOR persona which closely matched features found in illustrator.  

It had an Export > SVG feature--so far, so good.

CREATING THE DIAL

Knowing squat about Affinity vector I watched this video which contained a lot of what I wanted to do. 

An aside: I found a lot of online documentation for Canva Affinity out of date; perhaps Affinity, like Microsoft, has no problem changing their UI early and often, like soiled chonies;  Internet documentation (and AI) is slower to catch up.  

....they moved around the furniture?

.

After an hour or so I ended up with this:

A few notes; I won't remember any of this 2 days from now.

• I chose a 120mm x 120mm artboard and made sure the diameter of the outer circle had a 100mm diameter. How to set up artboards and canvases in Affinity is covered in this video--video is not for the current UI but I could follow it. The 100mm diameter made the size conversions described below easier to figure out.

• I used grids/guides. Good video for that (again, for an earlier version of Affinity Designer but the steps still seem current?) is here. However, there does not appear top be a way to save a custom grid configuration, unfortunate. Here are the settings used:

• To make the tick marks, use Affinity's Vector "power repeat" feature; take a look at this  how-to video. I had to make sure to set the checkboxes and adjust rotate points as described in the video or I'd end up with an ugly mess. 
• The repeat settings used for the big ticks:

• I then created a smaller tick over the large one at 12 o'clock, dragged its rotation point to center (red line and green guide lines visible) and repeated with rotation of 7.5 and number of copies of 64. 

Couldn't find anywhere: how I created the gap between 7PM and 5PM at the bottom of the dial. 

By trial and error, most everything I found online was uselessly out of date since Affinity massively/recently rearranged its UI: 

• Use the Affinity Vector knife tool
• If you zoom way in on the circle the knife tool becomes the scissor tool—yeh, I knew that.
• Make the start and end cuts on the arcs, where we need to get rid of parts of the circle, by left clicking with the scissor tool
• From the main menu: vector > separate curves 
• Using the move tool (not node tool!) click between 5 and 7; 
• The arc to be deleted is boxed with a faint blue rectangle.
• Hit delete on your keyboard
• Arc that was boxed is now gone
• Use node tool to further clean up any ugliness.

Finally I exported the 100mm x 100mm dial using File > Export > Export > SVG > SVG (for export).

AND NOW--A WORD ABOUT THIS BLOG'S SPONSOR

As soon as you have your design and gerber, you will need your work fabricated. For this, you should use PCBWAY.

PCBWAY, the sponsor of this blog, has a service to fabricate PCBs and other materials using any color of the rainbow. That's full color PCB's folks! Details are here. I will be covering this super cool service in a future post.

In addition to top notch PCB fabrication they also do fantastic work with assembly, 3D printing, injection molding, and so much more. Their staff is super friendly and PCBWAY always turns the work around quickly. I am always impressed!

You can help this blog by checking out the PCBWAY site.  Thanks.

IMPORTING INTO KICAD

In Kicad 9 I used the footprint editor to create a new footprint library then a new footprint for the dial.  SVG's import: file > import > graphics.

Blammo, this dialog:

This seemed straightforward until I discovered the "Import Scale" was linear but inaccurate. 

Meaning, if I set Import scale to .5 and imported a 100mm circle the resulting footprint was not a 50mm circle. 

Damn!

Not sure if this is documented anywhere--probably is, but, I couldn't it--I ended up crafting this formula which seems to get the job done:

X = Z/(A*3.08)

Where:

• X is the # to use for Kicad's import scale
• Z is final size you want
• A is the original size of SVG

Why 3.08?  No idea, I figured it might be PI, which got me close, but no, 3.08 yielded better results.  

For instance, for a 100mm diameter, and 25 mm output, I used this.

X = 25/(100*3.08)

X = .0811

BINGO.

For 100mm source, and 15mm target:

X = 15/(100 * 3.08) 

so x = .0487 to use for import scale, here’s what I got in Kicad. BUTTER!

I found that for smaller inputs (e.g., 50mm circle SVG instead of 100mm) the outputs drifted a bit, not sure why, but was still good enough. In general, I figured: why not start with 100mm SVG's?

Summarizing--some common input scale values to use based on a 100mm SVG source. Target footprint size in millimeters is the column on the left.

8 0.025974026

9 0.029220779

10 0.032467532

11 0.035714286

12 0.038961039

13 0.042207792

14 0.045454545

15 0.048701299

16 0.051948052

17 0.055194805

18 0.058441558

19 0.061688312

20 0.064935065

21 0.068181818

22 0.071428571

23 0.074675325

24 0.077922078

25 0.081168831

26 0.084415584

27 0.087662338

28 0.090909091

29 0.094155844

30 0.097402597

31 0.100649351

32 0.103896104

33 0.107142857

34 0.11038961

35 0.113636364

36 0.116883117

37 0.12012987

38 0.123376623

39 0.126623377

40 0.12987013

Before wrapping up--one more thing. Affinity allowed me to jump between "Vector" ("Illustrator") and "Pixel" ("Photoshop") mode. Great, it meant that I had more editing tools at my disposal. But--I found that SVG's modified in Pixel mode often created a file that Kicad couldn't import. I found it best to do all the work in the Vector Persona.

WHAT'S NEXT?

This whole SVG > Kicad thing can be used for more than dials. Line art?  Yep. Logos? Sure. Any single color or BW 2D graphic import should work. 

I uploaded my footprints from this SVG > Kicad silk workflow into Github (here) and will try to keep the repo current.

For the full color materials, Affinity would be a great way to get into that. I'll cover this in a future post....

And of course I will add more dials and graphics to future projects using the methods above.  

Overall, many hours down the rabbit hole. More to come.

Small Dual LFO--OTA based--Works Great!

Readers: If you'd like to build the dual LFO featured in this post, please go to PCBWAY's Community pages--gerber file; KiCAD 9 project/pcb/schematic/library files, B.O.M.'s, and more, are here.  

You can also help out this blog immensely by checking out PCBWAY. Thanks!

==============

Hello again:

I needed a small dual LFO with edge connectors for a few upcoming projects. 

Done--fabricated--worked first time. Joy!

To review: I found a cool OTA-based LFO design on EFM's site, here. I built a single really small CA3080 version, see this post, but then realized for some projects I needed--more? 

I redesigned two LFO's in one small PCB--read about that in this part I post.. 

The Revision1 design had some stupid mistakes, which are corrected in the version you see in today's post. Everything now works. Go A's!

THE PCB

Thanks as always to PCBWAY for sponsoring this blog and coming through with perfectly manufactured PCB's. They do great work! You can help out the blog by checking 'em out, here. 

PCB remains pretty small, 48 x 63mm. Which means: You can get 10 of these for $5USD from PCBWAY.

This rev worked great the first time!

....doesn't happen often, but when it does 
I'll take it.

DUAL LFO SETUP AND PINOUTS

As with the earlier designs, the 10K trimmers set the minimum LFO frequencies when CV = 0V.  

On the bench I could adjust this trim to make the slowest frequency REAALLLLY slow--didn't figure out exactly how slow but maybe one full cycle every 5-10 seconds, something like that.

Because I want to use this design as a drop-in to future projects I broke the inputs and outputs of each LFO to 100mil edge pins:

• TRI1, SQR, TRI2 and SQR2 are outputs.  
• 11,12 are ground; 
• 13 is Vcc (circuit should work with different rail voltages; I have only tested with +/-12);
•  Bias (Pins 4,5,9,10) set the voltage offsets for each output independently, with negative voltages relative to ground driving the offset up. I used "inverted CV" to avoid needing another op amp stage for each bias offset.

You shouldn't have to do a lot of tweaking, except for R9 and R5. These 2 resistors set the overall frequency based on incoming CV.  I tried values from 10K to 100K, what you use here depends on your needs. 

On the bench 20K worked for me, but if you are adding more external CV you should put a 0 ohm resistor in there then follow the guideline laid out in step 3 in "ideas" section below.

IDEAS FOR PROJECTS USING THE DUAL LFO AS A DAUGHTERBOARD

First idea: output of LFO1 feeds input of LFO2.  Put a digitally controlled switch or VCA in here?  

Second idea:  Have bias controls for each output.  As mentioned above, to save op amp stages the bias is wired "backwards" so plan accordingly.  Also, the output of each waveform is about 12V P/P so to not clip a voltage divider at each triangle output may be needed.  

This bias offset could be clamped and then controlled by CV.  Why not?

Step 3: add more CV.  I found the LFO's respond well to wide swings in CV, from maybe -10V to 10V, going from EVENN SLOWWER to way into the audible range. Cool!  If I set R9 and R5 to 0 ohm resistors the CV input op amps become mixers, so it's easy to add as many CV's as needed....maybe a "master CV" pot  from -12 to +12 and a few CV inputs with a B100K in front.  The diagram above shows you how to set this up.

OUTTRO

Overall: glad this design is finally working.  I will use this and the 3080 miniLFO in upcoming projects.  Until then, modulate slowly, and don't breathe the fumes!

CEM3320 Based Voltage Controller Filter. RTFM.

"Read the freaking manual"--"freaking" may not be the right word.

This last week I built my second clone of the Sequential Pro-One VCF, reconfigured slightly for Eurorack:

After 2 revisions: works but more effort needed.

ABOUT THE IC

The CEM3320--the IC upon which this post's voltage controlled filter is based--is a strange beast. 

Read about its developer here; essential reading about the CEM3320 can be found on Electric Druid's page, here.

Specifics about the CEM3320 and the Pro-One, a classic mono synth that used this IC, are also found on Electric Druid's site, here. 

Mod wiggler pages focusing on this IC are found here and here.

PAIA (one of my favorites) made an experimenter's board for the CEM3320...cool! Get the PDF here.

And--didn't find this until a few days ago--a schematic for a complete DIY Pro-One VCF can be found on dslamnig's site, here.

Fortunately finding 3320's for sale is easy. Original early 80's CEM3320's are unobtanium, but there are clones and work-alikes available from CoolAudio and Alfa, and I read that CEM has reissued it.  

UNDER THE CERAMIC

To learn about what makes this chip go: two datasheets are found online--the 2 pager (here) and a 6 pager (here).  

At the heart of the 3320 lies 4 active filter building blocks--a current to current gain stage, whose input is held a diode drop above ground, feeding a pin to tie a capacitor to ground or to an input source, and after that, a buffer. 

A feedback resistor ties output to input. 

With no signal at input, the gain stage is set for .65V (diode drop) at input and .46*VCC at output. Ohms law reveals that for 15VCC, Rf should thus be 100K. Details here.

Resonance is taken from the IC's capacitor-coupled output and fed back into the initial gain stage. 

The amount of resonance feedback is controlled by an OTA--in this case, easier to implement than say a CA3080; current limit the OTA's resonance control voltage to a 0-12V DC signal and present it to Pin 9.

In general, even after reading, the 3320 didn't make a lot of sense until I redrew the layout for a few common use cases' resistor configurations. This information was already available online, but the exercise helped me better understand the IC.

Bandpass. Yes, the CEM3320's 4 active filter blocks have odd pin assignments.

Highpass

Lowpass

THREE TIMES' THE CHARM?

I have already created 2 revisions of a Eurorack Pro-One type VCF, sent them off for fabrication to this blog's ever-humble sponsor, PCBWAY, who sent PCB's back to me lickity-split, to see if my layout yielded a working filter or a smoking piece of charcoal.

For the first revision: sadly, its PCB layout turned out to be a non-starter because it contained a stupid error: the Pro-One schematic indicates that these 3 critical resistors get tied to the negative rail:

 .....but I tied them to V+.  

Very Nice!  

This foobar was indeed beyond all repair--it would have meant too many trace cuts and fixes. The REV1 build went into E-waste.

Fortunately after a redesign the good folks at PCBWAY rushed Rev 2 PCB's back to the USA.  

Double happiness is getting boards and stencils from the blog's patient sponsor, PCBWAY....please help this blog by checking them out.

 Stencil + paste + SMD parts, then I put the PCB on a hotplate. 150C > 215C > 150C did the trick.

Parts is parts

Testing....

More testing....

So--did REV2 work?  

Lo and Behold. Nope. 

If I had read the frigging datasheet with a bit more care it might have, but, well, I didn't.

In fact, looking over all the links above, what I was thinking? There was a ton of information about how to wire up a CEM3320 and I apparently ignored most all of it.

One critical detail missed: to control VCF's cutoff frequency you send the CEM3320 an inverted control voltage. Meaning: lower voltages meant higher cutoff frequencies while higher voltages meant a lower cutoff frequency. 

The suggested CV range is 155mv to -25mv. 

Did I read this before starting the layout and build?  Nope. 

For revisions one and two I had a CV mixer at input, then inverted the inverter:

For revision 2 I used a 24 gauge jumper wire to go from R4 to pin 6 of the TL074:

  

Which ended up looking like this:

                                                          

With this fix and some component value changes the filter now worked--it swept, got the famous shimmery resonance sound, and sounded funky with fast decay.

But the wiring fix bugged me; I finished a 3rd revision to clean up this mistake.

To not have to do a major PCB redesign I left a quad op amp on the PCB, even though only 2 op amp stages are used. Sorry.

The modified REV2 sounds pretty good, but not great, it may be a bit too bright with some unwanted grittiness when resonance is approaching oscillation.  

I noticed that changing the voltage rails (from -12V to -9V, from +12V to +15V, and so on), made the filter sound, well....different, and every now and then, to my ears, better; more tweaking of REV3 is in order. 

I'll do that in the next few weeks and post again. 

Until then avoid the CEM-icals.

AD5761: Arduino Library and S/H Mux--one worked, the other sucked

 

Two goals since last time: see if I could create an IC library for Arduino sketch, which was surprising easy, and breadboarding an Arduino based bipolar audio Sample &Hold multiplexer, which I never got working. 

A basic sample and hold circuit, aka S/H or just SH. The HOLD COMMAND is provided by a microcontroller switching multiples of this S/H circuit one after another in rapid succession, allowing a single DAC to produce multiplexed output voltages.

At the bench I used an AD5761 16 bit bipolar DAC IC (previous post here), an Arduino Micro, a library for the DAC I wrote for Arduino Sketch (get the library on github, here), and, for the mux switch, the ADG413 analog switch featured in previous post here.

Writing the sketch library took a lot less time than anticipated.  

I used the Helge Langehaug's sketch here as a starting point and combined it with embedded C code created previously--post is here. 

To get the C library working with an Arduino sketch IDE:

• I put the IC C code for the AD5761 into a single .h file: AD57651
• I put the .h file into the same INO directory and the setup() n' loop() Arduino .ino sketch file.
• I #included the library file at the top of the sketch's INO file
• I compiled.

Worked first time--after initializing the DAC I could enter values into an AD6751_out() function and sure enough, correct voltages were present on my scope. 

You can get the working library file and a sample .ino sketch on github, here.

Whole thing took less than an evening to craft. Joy!

With confidence soaring I used the same library to create a 16-bit four-channel sample and hold. 

It's the idea found in this previous post, but employing Arduino sketch .ino/.h files instead of embedded C.

Guess what: the AD5761/ADG413 based S&H circuit never worked. At all.

I could get pretty steady sampled DC voltages out of the circuit, but the voltages at output were never close to being accurate, especially when voltages went below ground.  

I speculated that the issue was a combination of trying to breadboard the design (I read that accurate S/H circuits need to have caps and buffers close to one another which didn't happen here), using the AD5761 in bipolar mode instead of 0-10V, which I hadn't tried in a mux design before, and the lack of precise timing in the world of Arduino--I constrained my sketch to use only delay(), digitalWrite(), Serial.begin() function calls and the rest, in the best Arduino fashion; I could have called out Atmel registers in my code and slammed away, but I might have well have used embedded C for that.

And/or some really stupid mistake(s) I never figured out.  

After a too many evenings (four? five?) I gave up; easier to use unipolar dacs then level shift them with op amps.  

Or, use 3 AD5761's in parallel.

Or, buy a 4- or 8-channel DAC with the mux built in.  

Or, whatever.....

Thinking I had an issue with the ADG413 I tried a CD4051 Mux. Nope, that sucked too.  

The S/H worked, sort of, but the voltages were never close to accurate. I stripped things out and tried to use a Salae logic analyzer to sort the issue. Nope, it wasn't SPI.   

OMG, too many wires, too much mess.  

Overall: breadboarding is NO FUN. 

I am probably returning to ditching breadboards and getting small quantities of PCB's for experimentation from the blog's faithful and patient sponsor, PCBWAY. 

If said PCB's don't work because my design is crap, well, I will pitch them and try again.  

Even with the tariffs, I think time- and money-wise I would have come out WAY ahead this time. 

Overall a win in library land, but this was a lot bench time spent chasing what I thought was a cool idea with zilch to show for it. 

Enough! See ya next time.