Essentially then the mount is actually peforming correctly.
The installation platform your RCX400 is mounted on is flawed, if you're seeing shake then look at how it is secured. Likely something has loosened in how the mount is attached to whatever pier system being used, or a substandard pier is in use that is not deadening movement.
Mode selection issues are operator error misunderstanding or not properly watching the read out to know you have switch modes. This is a common new-user error for those unfamiliar with Autostar operation. And it happens occassionally even to us seasoned owners. Again, operator error... not a flaw in design.
As this is in a permanent location and has been for years it's about time your organization invested in external control from a PC/Tablet which would also eliminate mode button mis-selections, as well as allow a hands-off operation which might also deal with any settling issues.
The process of collimation of ANY SCT will result in a centered star becoming uncentered... this IS NOT a flaw in the design it is NORMAL result of moving a spherical secondary.
Collimation of an RCX400 should be done at the start of a session and unless there is an issue with one of the three focus motors not moving in unison with the others collimation should remain rock steady and not be necessary. In a permanent location I wouldn't expect for visual use to need to recollimate in a session and likely not for several.
There is an RCX400 group on Groups.io, and there is an individual who did engineer a control system for deforked RCX400s and he is active on that group. He would have to source some new components but has a stock of the boards he created for this purpose.
From what owners have advised, issues with the focus motor drive/collimation often stem from someone dismantling the front dust cover and not understanding that the motors of 10-14" models have an end-stop for each motor that can be lost and should be accounted for when disassembling and reassembling. If you are experiencing problems with setting collimation or focus it is likely that when the RCX400 was disassembled one or more of these end-stops were not reinstalled. Contacting the Groups.io RCX400 group would likely help identify and correct this problem.
The general idea that lack of support for the RCX400, which was discontinued more than 10 years ago, is somehow a ghastly problem makes me laugh... try and source an obscure part for any 8 years or older limited electronic device(less than 5,000 units produced) from the OEM manufacturer, you'll likely get the same reply that they don't support it. Understand, the RA/DEC/GPS are all the same as any LX200... other components may or may not fail, but that's the chances we take with any old advanced telescope mount.
Try and get parts for some of the Celestron Ultima mounts, or hand controls that went obsolete for the early Nexstar. It's not an uncommon dilemma IF A PROBLEM OCCURS. Which is not in any way a certainty or guaranteed that it will occur to an irreplaceable component of any vintage telescope mount.
Anyway, the issues you raised are mostly installation/operator error. Concerns about failures/replacement parts are the dilemma of any owner of electronics and telescope mounts which aren't simplistic in design. Thus logic pretty much indicates there is no more risk for the RCX400 than for any other choice in the grand scheme.
Imagine if your organization had a custom control system for a telescope mount and had to find someone to re-engineer it from an old 286 architecture with clock-based calculations. One of my old clubs had to deal with this issue for an ancient Clark refractor which had upon installation in the 1980's, a state of the art computer control. Years down the line that system had to be re-engineered twice to bring it into modern computer control. That's a lot more worrisome than the RCX400 let me tell you!
Thanks for the detailed reply. That's good news about the groups.io RCX group, and even better news that they may have a way to focus and collimate without the mount. I did not know about them (just joined). I joined the LX200 group years ago when it was still on Yahoo, and the participants there (and here on CN, but there's a lot of overlap) have been my best resource for working with this telescope. No one had mentioned the RCX group.
I think you misunderstand some of the comments I made, though.
I realize that the act of collimating a telescope will decenter a star. My concern was the need to constantly flip between modes to adjust, re-center, adjust, etc. This requires the operator to have to take his eye off the eyepiece, look at the handset, change modes, then go back to do the other operation. Rinse and repeat. The system does seem to be operating as designed, there may not be a better way to do that with a single handset, and as you note, since it's permanent it's not necessary to do often, but occasionally it is. I do think this is something a prospective buyer who might be thinking "oooh.... electronic collimation using the handset. Cool!" should be aware of.
Similarly, yes, being in the wrong focus or slewing mode is an operator error. It's also an easy error to make (at least it is for me). When you're looking through an eyepiece (or a screen), getting the focus jussssssttt right, critically looking at the view for a while, then nudging the pointing just a tad when Boom! it goes out of focus because you forgot you hadn't taken it out of focus mode is still annoying. Again, the system is working as designed, but here I think it could have been done better. [N.B. This comment is coming from someone who wrote embedded system software as a career, and I've too often heard someone to say, "it can't take more than a few lines of code to do that... how hard can that be" (they were always wrong), but, to me, this seems like a significant UI design error. Some systems (this is one) are far better if routine operations can be operated by feel (cars are another - I hate driver controls implemented by touchscreen - but that's a discussion for elsewhere).]
Shake: I have no reason to think it is an improper installation. It's bolted to a 2' diameter, 15' tall reinforced concrete pier set in bedrock. This telescope shook as described when it was alt-az mounted, and still shakes now that there is a Meade Giant Wedge between adapter plate and telescope base (no surprise there). Smacking the adapter with the heel of your hand does not cause the image to shake at all, and smacking the base of the telescope mount (which is firmly firmly screwed to the wedge plate with 4 bolts) doesn't produce much shaking, either. Touching the back end of the telescope, however, does. If this is not normal, whatever is wrong just about has to be somewhere in Meade's fork mount system, not how it's anchored through the pier to the ground, as far as I can tell. Maybe is is something we've done wrong, but I've checked the obvious.
Support: Fortunately we have not needed parts (yet), and do not expect manufacturers to stock parts for out of production equipment indefinitely. What was disappointing was Meade's absolute refusal to even offer advice on how some parts are supposed to fit together. Did they destroy all of their internal documentation when they stopped production? It is what it is, though, and this is something that any potential buyer should be aware of. Fortunately we were able to solve the problem ourselves, so that particular crisis was averted.
I disagree that the RCX400 is no more of a risk than other computerized telescopes since some critical functions within the OTA are integrated with and depend on the mount electronics. Because of this, these telescopes can be rendered completely useless (without substantial effort to modify it) if a vastly larger number of things go wrong. This is unusual. Most OTAs are not nearly so dependent on a particular mount's functionality (in fact, for most now, no dependence at all as long as the dovetail is reasonably common) and can be moved from one mount to another with substantially less effort, and no technical effort at all.
Your anecdote about the Clark refractor is not relevant. You're describing what sounds like an aftermarket (or, most likely, amateur) hack as a retrofit to much older equipment, and comparing it to a premium product sold as an integrated system with all-in-one functionality that was produced by a respected manufacturer. Even in the '80s, timing loops were considered a very poor technique for exactly the reason you described - they're hardware dependent. The fact that it was a 286 system is significant if the designer also took some not-recommended but often done liberties with segment register usage that no longer work with newer systems, and by "newer" I include some that are now quite old. Sometimes you gotta do what you gotta do, recommended or not, to get a system working, but you describe the typical result quite well - the system cannot be maintained long term. Honestly, you'd be insane to try to re-engineer the 286 code and equipment. Why in the world would you want to do that? Modern systems have far better performance than needed for tasks like this, so hard to maintain programming-down-to-the-bare-metal tricks aren't necessary to get needed performance, and system resources like timers are commonplace and well documented. Since it was a retrofit, anyway, just toss it and start over from scratch - the result will be easier, cheaper, and would just about have to be better. And it can be maintained (for a while, anyway; longer if properly designed).
Edited by SkipW, 22 July 2021 - 11:31 PM.