Fates - a DIY norns DAC board for Raspberry Pi

[desolationjones]

I will also point out that the encoders are not debounced in the Fates hardware. I do not know if any software debouncing is used. Without such methods a noisy encoder will be annoying to operate.

[csboling]

@desolationjones

I do not know if any software debouncing is used.

There’s a bit of filtering done here. From a quick look it doesn’t appear to me that the dir[i] direction tracking here actually affects the encoder events, so basically this just throttles the input events from the kernel I think.

Some more processing on the Lua side here.

[okyeron]

Folks could try to bodge a cap between encoder pins for hardware debouncing if they find the default situation too annoying.

[nexnex]

Finally got everything to build the Fates. Yay! Unfortunately I seem to have gotten a few wrong components by our local component store, and I noticed too late. So I had to desolder quite a few things. Now I finally finished everything the way it should be. Add the SD flashed card - but no action on the screen.

Is there some way to try to diagnose the issue without a display? Or am I screwed?

[okyeron]

• Does the green led on the pi do some flashing when you start up?
• Can you connect via SSH (probably over ethernet since you havent setup wifi yet I guess)?

[nexnex]

Yes the green light works. Will try over ssh. Once I connect via SSH, what could be done? Is there an easy way to check if the display is ok (as I had to desolder the pin-strip there)?

[okyeron]

Once connected you can run dmesg to see if the various devices are working - looking for the fbtft and fb_ssd1322 entries for the display and wm8731 for the DAC.

Testingwise - I can probably DM you some instructions, but you’ll need to install some extra stuff from the command line

[nexnex]

On that front, I’m getting:

[ 6.077837] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 6.089035] fbtft: loading out-of-tree module taints kernel.
[ 6.089050] fbtft: module is from the staging directory, the quality is unknown, you have been warned.
[ 6.092346] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[ 6.093376] fb_ssd1322: module is from the staging directory, the quality is unknown, you have been warned.
[ 6.095006] fbtft_of_value: buswidth = 8
[ 6.095022] fbtft_of_value: debug = 3
[ 6.095033] fbtft_of_value: rotate = 180
[ 6.095046] fbtft_of_value: fps = 20
[ 6.095306] fb_ssd1322 spi0.0: fbtft_gamma_parse_str() str=
[ 6.095318] fb_ssd1322 spi0.0: 1 1 1 1 1 2 2 3 3 4 4 5 5 6 6
[ 6.095449] fb_ssd1322 spi0.0: fbtft_request_one_gpio: ‘reset-gpios’ = GPIO4
[ 6.095500] fb_ssd1322 spi0.0: fbtft_request_one_gpio: ‘dc-gpios’ = GPIO17
[ 6.095597] fb_ssd1322 spi0.0: fbtft_verify_gpios()
[ 6.095609] fb_ssd1322 spi0.0: init_display()
[ 6.095620] fb_ssd1322 spi0.0: fbtft_reset()
[ 6.237544] fb_ssd1322 spi0.0: Display update: 3119 kB/s, fps=0
[ 6.237560] fb_ssd1322 spi0.0: set_gamma()
[ 6.237832] graphics fb0: fb_ssd1322 frame buffer, 128x64, 16 KiB video memory, 8 KiB buffer memory, fps=20, spi0.0 at 16 MHz

And

[ 6.064807] wm8731 1-001a: Assuming static MCLK
[ 6.064838] wm8731 1-001a: 1-001a supply AVDD not found, using dummy regulator
[ 6.064929] wm8731 1-001a: Linked as a consumer to regulator.0
[ 6.064953] wm8731 1-001a: 1-001a supply HPVDD not found, using dummy regulator
[ 6.065053] wm8731 1-001a: 1-001a supply DCVDD not found, using dummy regulator
[ 6.065133] wm8731 1-001a: 1-001a supply DBVDD not found, using dummy regulator

[nexnex]

Ah interesting, the display came up now after a couple of minutes. That’s quite a relief. Let me investigate. Maybe there’s a loose connection somewhere.

[okyeron]

I’m making an updated SD card right now and I noticed it took a little while for screen activity to happen before I had expanded the filesystem. It’s possible something is not working correctly until the disk is expanded.

[nexnex]

Awesome, it seems like it is working now! Great stuff & I loved your video instructions for building the case - made it so much easier.

Next step - as you might remember I built a teensy-neotrellis-monome. So I need to run ~/fates/install/norns/scripts/diy_device_fix.sh, right? Or is that already run during the initial setup? It gives me a “source not found” issue.

It doesn’t look like I should ignore it. Is that normal?

source not found: ‘src/SoftCutClient.cpp’ in bld(lib=[‘jack’, ‘pthread’, ‘m’, ‘sndfile’, ‘atomic’], use=[‘ALSA’, ‘LIBLO’, ‘BOOST’], target=‘crone’, idx=1, posted=True, tg_idx_count=6, meths=[‘process_rule’, ‘process_source’, ‘apply_link’, ‘create_task_macapp’, ‘create_task_macplist’, ‘install_boost’, ‘process_use’, ‘propagate_uselib_vars’, ‘apply_incpaths’, ‘set_full_paths_hpux’, ‘set_macosx_deployment_target’], includes=[‘src’, ‘./’], cxxflags=[’-std=c++14’, ‘-O2’, ‘-Wall’], source=[‘src/main.cpp’, ‘src/BufDiskWorker.cpp’, ‘src/Commands.cpp’, ‘src/MixerClient.cpp’, ‘src/OscInterface.cpp’, ‘src/SoftCutClient.cpp’, ‘src/Taper.cpp’, ‘src/Window.cpp’, ‘src/softcut/FadeCurves.cpp’, ‘src/softcut/SoftCutHead.cpp’, ‘src/softcut/SoftCutVoice.cpp’, ‘src/softcut/SubHead.cpp’, ‘src/softcut/Svf.cpp’, ‘src/softcut/TestBuffers.cpp’], path=/home/we/norns/crone, _name=‘crone’, typ=‘program’, features=[‘c’, ‘cxx’, ‘cxxprogram’, ‘cxx’, ‘cxxprogram’]) in /home/we/norns/crone

[okyeron]

@nexnex

So I need to run ~/fates/install/norns/scripts/diy_device_fix.sh, right? Or is that already run during the initial setup? It gives me a “source not found” issue.

You don’t need to run the diy_device_fix.sh script. It’s already applied on the last handful of Fates updates.

Is the “source not found” error is on compile with ./waf?
If so it means the norns directory needs to get various submodules downloaded to properly compile. Not sure why that would needed with recent updates though.

Did you already run SYSTEM>UPDATE? if not - do that first and all should be good.

[nexnex]

I got it when running the script manually - but if it is applied with the updates, that is even better.

So the comment from the fates README.md no longer applies? “As of 12-30-2019 DO NOT run the on device SYSTEM > UPDATE from the norns menu.”

Ran SYSTEM>UPDATE as you suggested - no errors shown on the fates display, but after pressing a key for shutdown it seems to hang on “shutting down.”

EDIT: Took it off the power connector and restarted - now it says “Up to date”, so I suppose that’s fine? Will test more on the weekend. Anything I should look out for?

[zebra]

ok, thanks for clarifying the conditions, that’s very helpful.

@avenir

The only difference is that from FATES / TAPE the sample is recorded in 24 bits. While the sample that sounded low was 32bit. Both at 48khz.

i did listen, i agree that there is something weird. it sounds almost like phase cancellation.

48khz is the correct sample rate. TAPE import doesn’t resample, so the symptom of other sample rate is just a pitch shift. that’s not the issue here.

so i wonder about the sample format. we are not dealing with sample formats directly in TAPE, we are using the ubiquitous and very robust libsndfile library. 32-bit PCM and 32-bit float should both be totally fine and i have used the latter quite a bit myself. if you go to that link you will see the container/sample format compatibility matrix, which is extensive.

if you want to message me and send the actual soundfile i can try and reproduce the issue on stock norns, and check the header for anything weird-looking.

[okyeron]

@nexnex

So the comment from the fates README.md no longer applies? “As of 12-30-2019 DO NOT run the on device SYSTEM > UPDATE from the norns menu.”

Yeah that is out of date (If you have release 200218 or later) and I’ll rewrite/update it. The “releases“ pages have more info now

@nexnex

after pressing a key for shutdown it seems to hang on “shutting down.”

This May be normal. Watch the Pi leds for activity. Depending on which pi you have The screen may stay illuminated with whatever text was there after shutdown. (The screen still has power applied even if the pi is shutdown so it might not be a hang at all)

[hollasynth]

Thanks for the knob suggestions everyone. I went for the black sifam with grey caps. Thanks to @muncky for supplying them. It’s finished and I like it!

[glia]

@okyeron

You might check to see if you’re getting undervoltage warnings. dmesg from the commandline (over SSH) should tell you. Or if you see the red LED flick off and back on, that’s likely a power issue.

I don’t think I’ve seen the issues you’ve described.

As others have said, check your power supply or cables. The official norns PSU may not actually provide enough power for a RasPi. Are you sure it’s 5.25A and not 5.25V with some other A rating? (5.25A seems like an odd number for amperage to me).

What about the power cables (if separate from the PSU)?

Which Pi are you using? Which power port are you using (Raspi or Fates)?

For more debugging, run without a case for awhile and if things start to get flickery again, touch around the Fates board and see if anything seems hot to touch (it should not be).

Triple/quadruple check your solder joints on the display headers (all sides).

I just switched from an acrylic to metal case and now fates is functioning differently…powering on takes multiple attempts + when it boots the screen flickers on each button press (and sometimes blacks out or flickers intermittently)

I’m using a raspi psu thru the fates usb-c port (rear), the red led is steady, audio seems to pass thru unaffected by the screen dropouts so i doubt power is the main issue

i’ll try running caseless but hope i haven’t done serious damage to the screen

Any troubleshooting suggestions welcome

[okyeron]

Perhaps try some kind of insulating layer between the case and the raspi. (?)

There’s lots of places for things to short out in the bottom of the pi.

[glia]

Any recommendation for safe insulation?

[jmsiener]

I’d say electrical tape would do the business immediately but if you wanted to get real fancy you could find a thermal pad that could squeeze between the pi and your case. Hell, you might even help with dissipating heat from the pi if you go that route!