#35

for sure! we’ve tried to keep this info searchable, but glad we can help clean up some less-than-ideal experiences :slight_smile:

folks who feel comfortable with an iron and have any experience working with solder wick will quickly get their legs with this – brian’s video above is a nice confirmation that you can tackle it with a little less finesse than you’d assume. if you’re on the fence, though, i’d say send it in :slight_smile:

mmm. it should manifest the same in any script that uses E1 as a scroller – since it was already evoked, the main menu of cheat codes could be a good test.

1 Like
#36

@Deru, i just finished replacing a wonky encoder on my norns. for what it’s worth, if you are comfortable de-soldering stuff, it’s a breeze!

2 Likes
#37

Thanks @dan_derks. In terms of the E1 encoder, what I mean is that it doesn’t control a level on the LEVELS page so it’s harder to diagnose in that example. I was curious if there was an ‘official’ way for visualizing that one as well. All good though I’ll mess around.

And thanks @Justmat. I’ve soldered some throughout the years but I don’t have a good setup atm so I’m thinking about the buy-in costs… Do either of you have a guess as to the amount I’d need to spend to get a decent enough setup? Like $100 or something? More?

Thanks all!

1 Like
#38

personally, if i didn’t already have something workable, i’d want to send it in. :sweat_smile:

2 Likes
#39

for sure – sorry, i didn’t mean to make it seem like your question wasn’t clear. it was a really good one, so i spun up this lil test script, which should basically be the same as what the LEVELS page example does, but for all three encoders:

-- encoder test

screen_dirty = true

function init()
  counter = {}
  for e = 1,3 do
    counter[e] = 0
  end
  clock.run(screen_redraw_clock)
  redraw()
end

function enc(e,d)
  counter[e] = util.clamp(counter[e] + d,0,100)
  screen_dirty = true
end

function redraw()
  screen:clear()
  screen.level(15)  
  for i = 1,3 do
    screen.move(120, 22 + (10*i))
    screen.text_right("e"..i..": "..counter[i])
  end
  screen:update()
end

function screen_redraw_clock()
  while true do
    if screen_dirty then
      redraw()
      screen_dirty = false
    end
    clock.sleep(1/30)
  end
end

i echo mat’s message, but anything that has an actual temperature control and can reach 800-900 degrees would be perfect for this sort of stuff. a good-for-life station would be ~$100, add $15 for solder and braid

2 Likes
#40

Amazing. Thanks for that @dan_derks.
They are indeed all jumpy :wink:

Email incoming, thanks again!
B

1 Like
#41

@Nornsrulez, @Deru, @Justmat: heads up, i moved our encoder convo here. thanks for the excellent dialogue!

2 Likes
#42

first… aww man, I do have the issue. then… oh nice diy fix! I might even have some spare encoders around :slight_smile: . Edit, damn I have two encoders in my parts box and looks like all three need replacing. Time to order another batch :upside_down_face:

#43

i would like to reiterate that this is not a good “first soldering experience” and please only attempt the fix if you’re already comfortable with soldering!

6 Likes
#44

both of mine are broke I guess

#45

Yup, thanks @dan_derks. Triple whammy!

#46

yeah, this is like one of my least favorite things to do

#47

If the part is toast and you’re going to replace it anyway, clipping the legs off and pulling one pin at a time can make things easier on the board and solder pads.

6 Likes
#48

my E3 encoder has been buggy since I got my norns first or second batch (can’t remember). but living in the EU makes it hard and kind of stupid to send my norns across the ocean just to fix one encoder…
there was a norns update that made a “software fix” for this and I made my peace with it. sometimes we get along other time we don’t :slight_smile:
I don’t have the skills to do the DYI encoder swap but with the norns encoder fix video, maybe I can find someone to do it here in Lisboa, Portugal :crossed_fingers:

#49

Are we sure about this ? Because according to this test both EC2 and EC3 need to be replaced on my unit, but when I go to parameter pages they work correctly (I mean, up and down works correctly and it’s not jumpy). The only thing that indeed doesn’t work correctly anywhere is the fact that if I keep turning an encoder when any value is set to its maximum, it goes back to a lower setting at some point and then turns back up to the maximum (like on the level page). So this looks like it’s a widespread problem at that point, but I’m unsure I want to send back my Norns across the ocean for something that hasn’t yet proven to be a huge problem in most cases. I mean I would like it not to jump back if I turn it up and a setting is at Max but… I can try to just avoid that most of the time (I didn’t notice it before this “test” was proposed).

1 Like
#50

1000%. i didn’t mean to add worry + we don’t want to add to resource scarcity for something that can be addressed with software tweaking (and honestly isn’t a noticeable thing for most folks who aren’t cranking on an encoder during a test case). there’s a huge gap between “need to be replaced” and “values are a little jumpy when testing with non-normal gestures.” this all sparked really nice conversation!

to clarify, there is a software-addressable encoder sensitivity setting. the values used across norns are:

  • main menu: E1 = 8, E2 = 2, E3 = 2 (out of 16)
  • all scripts: default to 1 unless the script states otherwise

there’s also an acceleration setting which helps fine-tune responsiveness.

we can tweak the menus and the inherited script-level default, but could use some feedback on this (it’ll definitely change how things feel, but it actually solves a lot of mid-level jumpy values).

here’s a new test script: enc-test.lua (1.7 KB)

K3 to jump between setting a value to test the encoder, setting the encoder sensitivity, and setting the acceleration. we’re basically looking for what feels good and steady for everyday use.

i found sensitivity 2 to 4 with acceleration to be precise and very workable for normal turns with previously semi-jumpy encoders but ymmv, which is why we’re asking :slight_smile:. so please give it a spin and let us know what values feel right!

1 Like
#51

I’ve got a first-gen Norns and this test reveals that the encoders are jumpy only when really moving quickly. The encoders are smooth and precise when moving slowly. I’m generally happy with their operation but hope that it doesn’t signal that the encoders are degrading over time?

#52

this is key – if if you’ve had norns for this long and you only notice it when you’re actively looking for it with this test, then the encoders do not need to be replaced. the proposed software fix will likely help and you won’t have to worry about it :slight_smile:

3 Likes
#53

My encoders seem jumpy… it’s never been unbearable, but it’s starting to become more problematic. I ran the enc-test and they seem to work perfectly fine. But in use, enc3 specifically seems to get completely stuck. This easily repeatable for me as shown below, trying to adjust the BPM in Patchwork.

#54

I have had this issue from the outset. I thought it was just something that would eventually get fixed with firmware and hadnt bothered me too much except that I am mixing in norns a little bit more and its not usable for a performance. I’ll catch up on this thread and run the test!