#1804

Mmm yes. But it’s weird because mine are the “complete kit encoders”. Maybe are there better ones? Any suggestions?

#1805

I would like to treat another question: what about the latest Norns firmware?

#1806

Encoders will go bad more quickly than pots if your device is bumping around unprotected in the bottom of a bag. Replacement is a good bet, and then considered packing when transporting to extend the life of said encoders.

#1807

I’ve had this problem with encoders I bought new from Mouser when building my Fates. One of the four was jumping values unless i was turning it reaaaally slow, after a few month it became completely unusuable so I replaced it and now everything works as it should.
Be careful while desoldering, i lifted a pad accidently by heating it too much.

1 Like
#1808

Use the ones listed in the BOM. The ones in the kits are exactly the same part.

It’ll get updated when I have time (and I’m crazy busy the next couple days)

4 Likes
#1809

Update 200712 now available

If you are running a version prior to 200218, DO NOT USE SYSTEM > UPDATE .
You must update manually via SSH. Instructions are on the release page: https://github.com/fates-project/norns/releases/tag/2.4.2

If you are on 200218 or later
use SYSTEM > UPDATE while connected to the internet.
(please report back if you have problems with this)

General Norns update notes and info about this release are on the norns release post here Norns: update 200712

21 Likes
#1810

Thank you so much and 20ch of appreciation!

#1811

Update went smoothly as usual. Thank you for this!

1 Like
#1812

So reflowing seemed to work at first, but now the same situation occurred again. I will reflow again, but is there a chance the fault is within the encoder and I should try a different one?

#1813

Yeah… It’s possible the encoder is bad.

A good solder pump/sucker helps a bunch for removal.

#1814

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.

#1815

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.

#1816

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

1 Like
#1817

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?

#1818
  • 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)?
#1819

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)?

#1820

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

#1821

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

#1822

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.

#1823

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.