Fates - a DIY norns DAC board for Raspberry Pi

encoders are dead simple - they’re directly connected to the Raspi header.

Check these pins on the header for E3 (or the vias shown here)
Screen Shot 2020-03-25 at 5.41.33 PM

if it’s a different enc, lemme know

1 Like

Thank you both @amgnowhere and @okyeron for your replies, I’m gonna check this and swap the encoder with the fourth one too (don’t know why I didn’t think of that earlier!). Will report back :slight_smile:

1 Like

check those pins on the header first for sure

removing the thru hole stuff can be a hassle sometimes, so take your time and make sure not to overheat or overwork the pads. A solder sucker is key here.

1 Like

I’m having a hell of a time getting audio into my fates. It’s worked once but was a bit spotty with what I thought was a bad cable (stereo cable into one of the mono inputs). I bought some mono cables and now I can’t get anything to register on the input. I’ve tried a number of cables (mono and stereo) and audio sources (pocket operator, korg monotron, output from my phone) I’ve tried reflashing my SD card, reflowing the solder joints, and have run the audio tests here a few times but I cannot get anything from an external audio source into the fates via either the L or R input jacks.

What could I be missing?

off the top of my head…
Check the input levels on the MIX page?
Check your capacitor orientation
Post a high rez picture of the DAC area (could be the output pins?)

1 Like

Which specific scripts? (Misc??)

How did you install/remove them?

That misc repo is a year old and probably incompatible with current norns. @dan_derks can you confirm?

It also duplicates other scripts (Islands,Kria) so is likely gonna cause exactly these problems if you already have those scripts installed.

I think at the moment any repo installed outside of maiden could be considered “at your own risk” or “not guaranteed to work”

woah, wild. that was just my branch off of @junklight’s misc. weird it came up, apologies to @encephalitislethargi!

i’d echo @okyeron’s advice – keep to the maiden project manager, as it has the best guarantee of reducing conflicts and duplication.

fwiw, if all you did was drag the folder into code, then deleting it from code should clean things up fine.

1 Like

maiden will report the exact filepath that’s having issues while loading a problematic script – do you have your output from that?

1 Like

Re-flashing the SD card is something of a “scorched earth” approach and should not be necessary.

You will need to restart/RESET after adding/removing any script with an engine. (supercollider compiles all these when it starts up, so the system needs a restart to get changes).

As dan mentions - Maiden is your friend and will tell you details about errors, duplicates, etc.


curious if anyone else is experiencing this… i’ve noticed this with the last 2 updates.

when powering down and booting back up again (mon and tp) are at their minimum regardless of their positions when powering down.

is there a solution to this?

hmm it’s also happening when switching from script to script

Would you please share what should be changed for the hp level to be working ?
For me the hp volume is not enough and most of the times I have to use the compressor to listen when I’m using my fates outdoors, so I’m thinking of creating a script and reapplying after every update.

I believe this is a norns issue introduced in the last update and has been addressed

Should be fixed in the next update

See the following from up thread, although I am not sure what the “max” value should be

So you can do the following from maiden to change the hp volume on fates (use at your own risk :grin:)

os.execute("i2cset -f -y 1 0x1a 0x05 0x0")

Will set it to zero - last parameter there is a hex value for volume. 0x70 is a good medium value.

0x7F might be the max value to try so os.execute("i2cset -f -y 1 0x1a 0x05 0x7F")

1 Like

is the docs page clear enough?

1 Like

I have tested this and it is working but where should I put the i2c id to have the actual hp control working ?

I don’t understand your question.

Would you clarify - Are you saying your headphone output is not working at all? Or that it’s working and the volume too low?

The headphone output level is controlled by the main “out” level on the MIX page. Turn that all the way up. (headphones and main outs are managed by the same control)

There is a Headphone Gain control in the Parameters (previously in the SYSTEM>AUDIO menu). This only works on norns hardware. This does nothing on Fates because it uses a different DAC.

If the main volume level is not enough you can manually change the headphone amplifcation level on the DAC with the command above - copy and paste that into the maiden REPL and run it.

Mix looks fine. All 6 levels at 100%, nothing on input shows in the VU when input is playing. Used the assembly youtube video (frame by frame) to check capacitor orientation, they’re all aligned to the correct polarity. Attached is a high res photo of the input area of the DAC after I spent this evening de-soldering, removing, reseating, and reflowing the connections for the input jacks.

Another odd thing I just found: while there is still nothing when using arecord, when using aplay to play the blank file I’ve just recorded, if my source is still putting out sound, I can hear it (quietly) through my headphones. BUT the playback only lasts 15 seconds (as long as I recorded). To clarify, this 15 second chunk is definitely live sound, and the wav file is definitely empty.

Is there some audio firmware somewhere on my Pi4 that could be messed up?

My headphones work fine and I’ve also been using i2cset -f -y 1 0x1a 0x05 0x0 through ssh and works fine. I was asking about the menu volume control that once was on SYSTEM>AUDIO. I tried changing the address on matron/hardware/i2c.c and running ./waf but that didn’t work or I did something wrong. I couldn’t find any other place where hp volume is defined.

This won’t work on Fates. (Or I tired the same and never made it work so gave up). Different Codec chip - fates has an integrated hp driver and norns uses a separate hp driver.

No. This is likely a hardware issue.

In your picture the soldering could be better. Reflow. On the jacks add more solder to fill the holes. On those and the electrolytic caps, leave the iron in contact until the solder is obviously flowing then release. If the solder is not flowing well, your iron may be set too low.

I can’t look up up right now - was this an smd-assembled board or did you do the smd yourself? If the later, a pic of the codec chip would help to diagnose.