Im looking at the mouser bom and it appears as if the MEC switch is out of stock.

Would this do?:

https://www.mouser.es/ProductDetail/MEC-Switches/5GTH920?qs=sGAEpiMZZMsgGjVA3toVBPjP8QioiSm51yY4L5YTKHY%3D

Thanks

yes, they are recommended as an alternative

1 Like

I’m curious why the denouncing circuit on the encoder outputs is not symmetrical, i.e., the “B” phase output is not connected to 3v3 through a resistor? Perhaps @tehn is the better person to ask

2 Likes

@frankchannel you just found a bug! :rainbow:

weird news is the existing boards work. but i’ll get the files fixed.

(this is proper on the actual norns, just the shield has missing resistors).

5 Likes

See note above

Mouser cart is NOT up to date. Check GitHub BOM for alternates

You could also get the 5GTH935 in a pinch (higher actuation force - 35 instead of 20)

Also Also - build guide got updated yesterday too.

1 Like

My Octopart BOM for Fates Board:
Link: https://octopart.com/bom-tool/fX3ixXTQ

Is essentially the same of okieron´s github BOM…but with the encoder cups and the PCB spacers etc… (all in one BOM)
All the parts are in stock on Mouser: 79.42€ + TAX (deppend of your country)
image

Pd: whitout Raspberry PI , PCB and case.

6 Likes

After lots of troubleshooting, it turns out the display issue was rooted in the interaction between my SD card and the pi boot sequence. I was originally using an old 4GB class 4 sdhc card that was super slow. Based on dmesg, my very uninformed hypothesis (guess) was that this was causing some sort of race condition between bcm2708_fb and fbtft. I have logs of both good and bad dmesg if anyone with deeper knowledge about that stuff wants to take a look. Once I switched to a 32GB U3 card the display started working reliably.

However, oddly, the wifi worked flawlessly with the slow card, but would not work out of the box at all with the new card. I did a bunch of things that ultimately resulted in wifi working w/o having to disable 5ghz on my AP (which is an older airport extreme that does not have the ability to disable 5ghz). Specifically, I connected directly from my laptop via ethernet, reconfigured eth0 to not use dhcp because that kept shutting down the interface when dhcp timed out, added a wlan0 config to /etc/network/interfaces that pointed to wpa_supplicant, configured wpa_supplicant accordingly, disabled bluetooth and deleted all of the cruft config files in NetworkManager that came from my repeated attempts at connecting via the norns UI.

I have no idea why wifi was working fine w the old slow card and not w the fast new card, but I have a suspicion, based on the display issue, that it stems from what happens when the pi is scanning for devices and loading various drivers on boot. That said, I’m new to the pi OS so, these are just guesses. Hope this maybe helps someone else!

1 Like

Has anyone updated to the new norns version on their Fates?

just for you I tried it … seems to be working ok.

(I just did update from the norns update menu item)

and sidekick continued to work after update too, so thats a bonus :slight_smile:

2 Likes

I am neck deep in hardware testing (smd-assembled boards) so haven’t had time to check yet.

If anyone gets a Supercollider Fail please post about that.

Good news! Thx!

2 Likes

Thank you for your bravery!

2 Likes

FYI - if you run the 191016 update from the norns menu, the last step of the update does a shutdown. Thus on Fates you will need to power cycle afterwards (plug/unplug)

This reminds me - I think I need a little switch or switching power strip at my mains power connection.

1 Like

yeah that caught me out too… but assumed this was the case, when I could no longer ping it :slight_smile:

These work well depending on where things are plugged in https://www.adafruit.com/product/3723 (full disclosure I work for Adafruit)
Even better may be this thing: https://www.canakit.com/raspberry-pi-4-on-off-power-switch.html (update, there’s a bundle on Amazon for that switch and their Pi4 power supply that is cheaper than getting just the switch + shipping from CanaKit, so I just ordered that bundle.)
Update: I am using the CanaKit PiSwitch now to power on and power off (after shutting down Fates w Sleep command) and it works great.

4 Likes

Acrylic Case Assembly Video

…and the standoff guide has been added to the github pages along with this video link

16 Likes

have you seen this post about an alpha version of rPI4 usb firmware (vl805_update_0137a8) which was supposed to make rPI4 run a bit cooler.
(I found this whilst crawling the blokas forum for other information :slight_smile: )

any idea if this firmware has been now included in some update? are we all running already?

edit:
ok, dont think its been released yet , so we dont have it applied,
I also found the latest test/release on the raspberrypi forum…
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=250990

I guess I’ll give it a go, its a modest improvement apparently… (talk of ~5c)

edit2:
applied new vl805 firmware (vl805_fw_0137ab), I’ll keep an eye on it - so far looks good :slight_smile:
good news, is the old firmware is also supplied (vl805_fw_013701) so you can always revert if you have issues.

1 Like

This post talks about how to change/upgrade/recover the raspberry eprom firmware.
It´s in beta, but seems that works well.

Pd:Raspberry foundation are working in USB 3.0 boot support, this could be the best of the best improvements in the raspberry´s world.

2 Likes

is there a new rPI4 eprom firmware?

my post is above is about updating the vl805 (usb chip) firmware, (uses its own util to do this)
iirc, it reduces heat by implementing powersaving on usb

Here is the EPROM update (changelog) that changes the power consumption

well that turned into a bit more effort than expected.
I was on an early release of the fates image, so ended up needing to use the latest image (due to need a slightly later kernel version).
not that bad, as it now means I’m on the same fates image as everyone else which I meant to do at some point anyway

now, I have the vlc update and eprom update installed.
initially tests are looking good, even under some load (*) its seems to be staying fairly around ~68c,
which is ok.

(*) even when I was compiling stuff… so thats promising

Im going to do a long test, with orac constantly playing for a few hours.

a couple of days ago (prior to these update) when I did this, I saw it rise to about ~80c which is a bit high,
so im just hoping for a few degrees drop, to bring it under 80c , anything else is a bonus :slight_smile:


EDIT: ok, so pretty promising results…

for first 1.5 hours - I had orac running a ‘3 track’ patch, drum, melody, bass with some reverb and other fx. seemed rock steady at ~68c
after than I upped the game :slight_smile: I added synths and fx that i know are heavy cpu guzzlers - so took one core to a full 100% - this unsurprisingly push the temp to around ~75c very quickly, but then even after 1.5 hours its was appprox ~77c
this seems pretty good, for an over 3 hours stint, esp. since in reality we cannot push to 100% as we get audio glitches, I think in normal conditions it’ll now stay between 65-75c
(by comparison previous even under lighter loads by 3 hours it was 80-81c)

testing note:
rPI4 - 4gb, small copper heatsinks, inside enclosure
Fates image , running sidekick/orac.


one thing i have noticed, with the latest eprom update, the display no longer turns itself off after shutdown (so its like the rPI3b) - not really and issue, just an observation.

1 Like