I've got the PIC code modified and tested it in the MPLAB simulator. It uses the TMR0 interrupt to poll the encoder, and can queue up to 64 knob steps (about two rotations). Hopefully this doesn't affect the IR period timing too much; if it does I can convert that code to use a different timer.

The new PIC chips will be here in a couple days and then I can test it for real.

Apart from a replacement PIC, what else is needed?

It's pin compatible and uses the same old clock of 20 MHz. Nothing special for the kernel. So yeah just swapping the PIC chip should be all that's needed.

There is the added difficulty of the VFD, it's above the PIC chip. But it's possible to pull it away and solder the new chip under it, and then push it back down with a bit of glue on the foam pads.

So, completely unrelated to SqueezeSlave, does the faster sampling rate fix the glitching that occurs on old worn-out knobs? I mean the general glitching that everyone who runs the stock Empeg software experiences when their knobs get old, as I mentioned at the top of the thread and also here in the FAQ. Does it magically improve the knob sampling so that aging knobs don't confuse the debouncer as much?

Well, I would think the better sampling would be more immune to noise. The old code was a kind of state machine, and it would be deaf to the encoder when it was transmitting the IR bits. I didn't really analyze all the old encoder code as I was replacing it anyway and it's unusually complex. Not to mention that I am looking at a disassembly of it with no comments.

But I suspect that because the old code wasn't always listening to the encoder, it would try to 'infer' the count direction if something happened while it was deaf.

The new programming is pretty simple. It compares the 'new' A phase to the old 'A' phase, and if they are different it counts. The direction of counting is determined by which way 'A' changed and also the state of 'B' phase. It's important to note that it doesn't look at the transition of 'B', as this transitions at the detent. If it happens to sample 'A' when there is noise, no matter, as worst case it will be correct a couple milliseconds later.

Here's the new ISR code for the curious:
http://pastebin.com/0nMEFgAZ


As far as I can tell there's no hardware debounce. So it wouldn't hurt to throw a couple small 0.01uF caps across the encoder leads if one has a unit with a flaky encoder. This could actually improve the lifetime of an encoder as the current from discharging the caps will have a cleaning action ("wetting") on the encoder contacts.

So in conclusion, it could be a lot better with the improved PIC, and won't be worse, I hope.

Has anyone noticed "stuck" keys or an ignored keypress with the stock software? I recently put Squeezeslave into the Empeg in my Subaru, but before that it was all stock. I noticed sometimes it seems it wouldn't respond when I pushed the next track button, and very rarely it would get a "stuck" key (in the software sense, nothing with the button itself).

In the old PIC code it sends the keyup code twice. I think this is because it was a known problem, and a stuck key is much more annoying than a missed tap. I'm playing around with doing keyup (as well as keydown) codes more than twice, to fix it with brute force.

The new PIC is in and it works. It's really nice actually. You can see that it queues the knob rotation, but it's not obtrusive.
http://www.youtube.com/watch?v=uB3Is5rhpRw

I'm going to play with it this week to see if it needs any tweaks here or there.

No, not unless there is a malfunction in the player somewhere. Here are a couple of FAQ entries on the cases where stuff like that can happen, my vote is on the PIC solder joint in the first one:

Why do my remote and front panel buttons only work intermittently?

Why does my player start doing things all by itself?

In DC mode, player responds extremly slowly to button presses, and music skips.

My buttons and/or knob are sticking.

Well, pin 2 is certainly the pin of interest. It's the one that carries the IR pulses to the StrongARM.

But it doesn't seem like a cold solder joint to me. I've seen it on all three of the empegs I have, albeit two of those have been running Squeezeslave. I suspect the use of the Ethernet port causes more jitter in the IR interrupt. I'll have to wait and see if my "brute force" approach fixes this problem when using Squeezeslave.

So far so good on the commute to/from work today. If anyone genuinely wants a PIC of their own (and promises to actually install it) I could be convinced to throw one in the mail.

I'd like one. But perhaps not until you've had a week or more of daily use with yours.