Getting rid of scratchiness in a volume pot

[AnalogSteph]

Every pot on an amp I use (even digital knobs like on my RME) have gone to shit in less than a year or two. With digital, it's skipping, with amps it's just scratchy.

That's an unusually bad track record. Do you happen to live anywhere with air pollution issues?

You can buy a replacement encoder if need be. That being said, the traditional #1 problem with mechanical encoders has been silicone goop from the bearing making its way out onto the contact surfaces. Generally you can open and clean them relatively easily, they I don't know how it would work on this particular type:

I've had one device that developed a scratchy pot fairly quickly, a BTech headphone amplifier back in the mid-2000s. I then applied a bit of my contact cleaner (Teslanol t6 "Oszillin"), never had any issues again.

 

[Tks]

That's an unusually bad track record. Do you happen to live anywhere with air pollution issues?

You can buy a replacement encoder if need be. That being said, the traditional #1 problem with mechanical encoders has been silicone goop from the bearing making its way out onto the contact surfaces. Generally you can open and clean them relatively easily, they I don't know how it would work on this particular type:


I've had one device that developed a scratchy pot fairly quickly, a BTech headphone amplifier back in the mid-2000s. I then applied a bit of my contact cleaner (Teslanol t6 "Oszillin"), never had any issues again.

The RME has skipping issues, this is something that needs to be rectified with replacements. 2/3 of the encoders on the device have this issue, its not something the user should be doing according to the owner. Ive just been procrastinating on sending the unit out. Also hearing tales of very costly repair (not sure why seeing as how its an issue with a bunch of people).

 

[Sharpi31]

In my experience it happens most often when there is a DC offset. Adjusting output stage offset and coupling caps can remove the issue entirely. Obviously depends on the equipment you’re using, and if you can adjust these elements. Thought it best to mention.

 

[threni]

It irks me to no end. Is every mechanical piece of hardware made today as if it's the first iteration of the concept (so high failure rates)? Does anyone in these design schools take an education on history of how any of our products were made, and made to be reliable. Or is it the case that every company is on their own discovery tour, or do they simply not care?

What's the business case for spending time and money to make something which delays the purchase of replacement equipment, or a paid-for after-sales service? It's a race to the bottom, and we're nearly there!

 

[MakeMineVinyl]

The RME has skipping issues, this is something that needs to be rectified with replacements. 2/3 of the encoders on the device have this issue, its not something the user should be doing according to the owner. Ive just been procrastinating on sending the unit out. Also hearing tales of very costly repair (not sure why seeing as how its an issue with a bunch of people).

The skipping is very likely sloppily done firmware which processes the encoder data. I write this kind of firmware regularly - skipping doesn't have to be a problem.

 

[DonH56]

I find a couple on Amazon, any preference? Both claim they are safe on plastic... Asking because my old Breemer or whatever is running empty.

https://www.amazon.com/Hosa-F5S-H6-DeoxIT-FaderLube-Spray/dp/B00006LVF1 -- some comments say this does not lube very well?

https://www.amazon.com/Hosa-D5S-6-D...1c4ab&pd_rd_wg=O4ip3&pd_rd_i=B00006LVEU&psc=1

As an aside, I see they are a division of Hosa, my least-favorite cable maker, go figure...

 

[JWAmerica]

I find a couple on Amazon, any preference? Both claim they are safe on plastic... Asking because my old Breemer or whatever is running empty.

https://www.amazon.com/Hosa-F5S-H6-DeoxIT-FaderLube-Spray/dp/B00006LVF1 -- some comments say this does not lube very well?

https://www.amazon.com/Hosa-D5S-6-D...1c4ab&pd_rd_wg=O4ip3&pd_rd_i=B00006LVEU&psc=1

As an aside, I see they are a division of Hosa, my least-favorite cable maker, go figure...

If you just want lubrication Faderlube F-100 is what you want. Apply F-5 for cleaning, then apply F-100 for lubrication.

 

[DonH56]

If you just want lubrication Faderlube F-100 is what you want. Apply F-5 for cleaning, then apply F-100 for lubrication.

Thanks!

 

[Tks]

What's the business case for spending time and money to make something which delays the purchase of replacement equipment, or a paid-for after-sales service? It's a race to the bottom, and we're nearly there!

For B2B failure rates and reliability data is paramount. Otherwise you could simply sell parts to businesses that are consumer grade. That doesnt fly.

The skipping is very likely sloppily done firmware which processes the encoder data. I write this kind of firmware regularly - skipping doesn't have to be a problem.

Nope, its hardware, otherwise there would be a pattern (and not 1-3 encoders skipping for some, while others experience only 1 failing). The firmware couldn't be any better, and if it was firmware it would have been long fixed instead of acknowledged as a hardware issue that requires the device go back to Germany for service.

 

[MakeMineVinyl]

For B2B failure rates and reliability data is paramount. Otherwise you could simply sell parts to businesses that are consumer grade. That doesnt fly.



Nope, its hardware, otherwise there would be a pattern (and not 1-3 encoders skipping for some, while others experience only 1 failing). The firmware couldn't be any better, and if it was firmware it would have been long fixed instead of acknowledged as a hardware issue that requires the device go back to Germany for service.

Perhaps, but getting the timings and dwell periods right on encoders is more involved than one would think. Like I said, I write this type of control programming all the time, so I know of what I speak. The firmware could be on the edge of being acceptable with the timings slightly less than optimum, and that could cause otherwise 'random' type malfunctions - the failures wouldn't necessarily follow a pattern. No, I'm not letting the programmers off the hook for this. Unfortunately we'll never know since we can't dive into their programming and place logic analyzers on all the ports. If there's separate hardware and software teams, there's always the very real possibility one might not know exactly what's going on with the other.

Yes, it could be hardware, but you've got a lot of failures going on, and outside of manufacturing or design defects on the encoders in the first place (which the manufacturer should have never let out the door!), there's plainly something abnormal going on which cannot be chalked up to coincidence.

 

[Tks]

Perhaps, but getting the timings and dwell periods right on encoders is more involved than one would think. Like I said, I write this type of control programming all the time, so I know of what I speak. The firmware could be on the edge of being acceptable with the timings slightly less than optimum, and that could cause otherwise 'random' type malfunctions - the failures wouldn't necessarily follow a pattern. No, I'm not letting the programmers off the hook for this. Unfortunately we'll never know since we can't dive into their programming and place logic analyzers on all the ports. If there's separate hardware and software teams, there's always the very real possibility one might not know exactly what's going on with the other.

Yes, it could be hardware, but you've got a lot of failures going on, and outside of manufacturing or design defects on the encoders in the first place (which the manufacturer should have never let out the door!), there's plainly something abnormal going on which cannot be chalked up to coincidence.

I agree it's not coincidence at all. I posit simply a poor choice of encoders (either unwitingly, or by simply manufacturers sending garbage batches).

 

[MakeMineVinyl]

I agree it's not coincidence at all. I posit simply a poor choice of encoders (either unwitingly, or by simply manufacturers sending garbage batches).

There could always be a defective batch of encoders - it does happen, though defects are relatively rare in my experience. If the encoders were otherwise good but poorly chosen for the job, the firmware could still be re-written to make them work. The programmers ain't getting off that easy if they didn't think things through or didn't test things enough. I'd certainly ask them a few uncomfortable questions.

 

[Tks]

There could always be a defective batch of encoders - it does happen, though defects are relatively rare in my experience. If the encoders were otherwise good but poorly chosen for the job, the firmware could still be re-written to make them work. The programmers ain't getting off that easy if they didn't think things through or didn't test things enough. I'd certainly ask them a few uncomfortable questions.

I highly doubt they would waste their time and ours replacing the encoders if a relatively simple firmware fix would do the job. As for probing them, I've not met a single company yet on this scale or larger that would simply allow unfetered access to talent. There's a reason why everything is compartmentalized and why the company as customer facing people, and backend people well, in the back. Last thing you want is some employee mouthing off about failures if that's indeed the case (especially if it's something ill intended like blatant cost cutting they were forced to perpetuate).

 

[vallandar]

I highly doubt they would waste their time and ours replacing the encoders if a relatively simple firmware fix would do the job.

There's a new firmware update released in Dec 2021 that addresses this, maybe you can try it and see if it helps.
From the announcement post:

Encoder jumping and direction errors: This firmware includes a new logic unit that intelligently detects and eliminates encoder switching contact errors. In addition, there is a variable filter with levels 1 to 5. Default is 1, which is largely similar in feel to the previously used filter. Higher values lead to an attenuation of very fast changes. Strongly jumping or backward running encoders can in most cases be used normally again with the setting 3. Very fast, short rotations can be replaced by medium-fast rotations after a short period of familiarization.

 

[Tks]

There's a new firmware update released in Dec 2021 that addresses this, maybe you can try it and see if it helps.
From the announcement post:

Holy crap, it actually works. Thanks for the heads up vallandar!

 

[maverickronin]

Holy crap, it actually works.

That was my reaction as well.

Apparently if you procrastinate long enough the problem does go away on it's own.

 

[vallandar]

Interestingly, I can't tell the difference between the different encoder filters on my new unit, 3 or even 5 don't feel very different from 1 (default). I'm sure there are differences, but they seem subtle. RME could just set the encoder filter default to 3, I don't think anyone would complain.