jif001

Someone requested the STLs, and the only reason I didn't upload these in the first place is that I was still tinkering with them. I think they are OK now, so here they are... Five files: The RA motor bracket attaches the motor to the weight bar. For this you'll need to add two M5 nuts (which fit inside the tube) and two corresponding M5 bolts (I use the thumbscrew type shown here). RA MOTOR BRACKET: Note: this is for a NEMA 17 motor and will need amending if you use a NEMA 14 The RA junction box houses the two DIN sockets that you will find attached to a black plastic box marked 'RA IN' and 'Dec OUT' on the mount. Be very careful when removing and refitting these - the soldered joints are not very strong and can break. Take some pictures before removing them so you can record which wires go where, just in case. The RA junction box back plate is a 'nice-to-have' but is not essential. RA JUNCTION BOX AND BACK PLATE: The Dec motor housing similarly requires an M5 nut, which fits in a recess (not shown in this picture). The bolt used to mount the existing motor bracket is re-used here. Again, be very careful with those DIN socket connections, and the back plate is a 'nice-to-have' but is not essential. DEC MOTOR HOUSING AND BACK PLATE: Note: this is for a NEMA 17 motor and will need amending if you use a NEMA 14 Obviously there are numerous other bolts and washers needed to fit stuff together, plus some self-tapping screws for the Dec motor housing back plate, but they are easy enough to figure out and some existing bolts already on the mount can be re-used. Here are some pics showing the final assemblies, for reference. My next project is to replace the DIN sockets with something better. If that works then there will be some redesign work on this lot, so watch this space! NOTE: Before printing the components you may need to rotate them in your slicer to minimise the need for supports - they may not be in the best orientation for printing when opened. RA Motor Bracket.stlRA Junction Box.stlRA Junction Box Back Plate.stl Dec Motor Housing.stlDec Motor Housing Back Plate.stl

Yes - see the updates added to the thread linked above 👍🏻

It seems to be mentioned a lot in a Green Swamp Server forum. I think the author has a presence there.

Thanks very much for that. Do you know of any documentation explaining its use? I've been trawling various forums over the past few days trying to figure out how this mount works 'under the hood' and this looks like it will provide the answers. As a minimum, it throws light on what was previously incomprehensible terminology used in some posts I read in the EQMOD forum (e.g. the meaning of :a and :b and :I ...). These are the numbers it reports: ... and these correspond with the 'Autodetect' numbers I've seen. They don't, though, match the numbers I have quoted in my previous post. The RA gearbox ratio in the image above is 47:12 (not quite 4:1) even though I have counted the physical teeth on each gear wheel and confirmed the ratio is exactly 4:1. The same numbers are used for Dec (so 47:12) even though, once again, I have determined by inspection a ratio of 11:1. On the 'Data' tab (presumably standard numbers for numerous mounts including EQ6, EQ8, etc.) it reports this for the EQM35: ... and this agrees with my numbers (see the red numbers for RA above). It's an interesting conundrum. Maybe the firmware is not correct, but it works for imaging so at least I know I can fall back on the defaults ('Autodetect Mount') when the sky is clear and tinker with the numbers in the day!

That was very interesting - thank you. It revealed the fact that choosing 'Auto Detect' in the EQMOD Mount Options was the wrong thing to do! The thread gives figures for microsteps per axis revolution for RA and Dec, and BOTH were incorrect in my EQMOD settings! I confirmed this by doing the calculations myself, and the results agree with those in the thread you quoted. Another lesson learned - don't trust the Skywatcher motor controller to report the correct parameters to EQMOD! I know this mount shipped with the wrong parameters in the firmware, but I assumed this was fixed by updating it.... EDIT: after testing the settings below I discovered they did not work. NINA 3PPA started by pointing the scope at the ground (or it would have, if I hadn't stopped it). Resetting to the original values fixed it. So, don't use the numbers below. I'll have to try to figure out WHY they didn't work! For reference (and to make this whole thread a little more comprehensive) the correct numbers are as follows for the standard mount (note: numbers are for the EQM35 only, but the method applies to any similar mount): RA: Dec: A: motor degrees per step 1.8 1.8 ... this is a characteristic of the motor B: motor steps per motor rev 200 200 B = 360degrees/A C: Micro-steps per step 64 64 ... this is a characteristic of the motor controller and the motor (each 1.8 degree step is made up of 64 micro-steps) D: micro-steps per motor rev 12800 12800 D = C x B E: gear ratio 4:1 11:1 ... this is a characteristic of the gearing of the mount F: micro-steps per worm rev 51200 140800 F = E x D G: worm revs per axis rev 180 65 ... this is a characteristic of the mount (basically, the no. of teeth on the worm gear) H: micro-steps per axis rev 9216000 9152000 H = G x F F and H (in red) are the new values to be set in the Custom Mount dialog (open EQASCOM Toolbox / press the Driver Setup button / tick the Show Advanced Options box / select Custom from the drop-down in Mount Options / press the wrench button). There is a field labelled 'Tracking Offset' there too, but right now I don't know what to do with that so have left it at zero (Google isn't helping). Using the belt mods described in this thread none of the RA numbers change but for Dec A becomes 0.9 degrees and B becomes 400 steps as a result. The gear ratio changes to 5.5:1 also. These changes have no effect on the above values of F and H because, basically, all I did there was divide by two in A and multiply by two in E. I've yet to try these new numbers in the setup, so will report back here if I learn something worth knowing!

Thanks for the feedback 👍🏻 I’d be interested to read any other threads on this subject if you can point me at them … there might be useful tweaks there!

I did think of that as an option for the Dec axis when I was unable to match the 11:1 ratio, but the motor idea meant I didn’t need to the end. 👍🏻

I’m using the standard EQM35 motor controller with no changes made to EQMOD settings. The aim of the exercise was to achieve the same ratios as the hard coded ones because I recognised at the start that there was nothing I could do to change them. On the RA axis I did it with 48 & 12 tooth pulleys (ratio 4:1, as in the original gear train). On the Dec axis I used 66 & 12 tooth pulleys, but that ratio is 5.5:1 and would run at twice the required speed because the original ratio is 11:1, so I halved the speed with a 0.9 degree motor in place of the 1.8 degree motor. I chose 66 & 12 (i.e. 5.5:1) specifically because I could halve the motor speed. I’ve also got a 55 and a 10 on the way from China (and a 66, to go with the 12, just in case…) The upshot is that the pulse rates going to both axes drive them at the correct speed, with no software tweaks needed.

The above post has been amended to cover both axes. Cost is a bit more than £30 now but it’s complete belt mod, not just RA!

Parts list for the whole job: RA Axis NEMA 17 1.8 degree motor. You could re-use the existing motor though (I replaced mine because it had failed) 12 tooth GT2 timing pulley – 5mm bore (for a 6mm wide belt) 48 tooth GT2 timing pulley – 6mm bore (for a 6mm wide belt) 158mm GT2 timing belt (6mm wide) Custom mounting bracket and socket housing 2x M5 (5mm x 15mm) thumbscrews (standard M5 bolts would do if you're not fussed) + 2x M5 nuts + the existing bolts used to attach the motor (add some washers) Dec Axis NEMA 17 0.9 degree motor (a NEMA 14 might do if you can get a 0.9 degree version, but the stock motor needs to be replaced here. Keep it as a spare in case your RA motor ever fails) 12 tooth GT2 timing pulley with 5mm bore (alternatively, 10 tooth - but not yet tried) 66 GT2 tooth timing pulley with 6mm bore (or 55 tooth if using 10 above) 200mm GT2 belt 6mm wide (or 196mm) custom motor and socket housing 1x M5 nut + the existing bolts used to attach the motor (add some washers). I’m happy to supply STLs on request for the 3d-printed brackets and socket housings if you have – or have access to – a 3d printer.

Another update. Dec is now belt-modded following a Eureka! moment. This is how it went ... The Dec axis gear ratio on an EQM35 is 11:1. The smallest pulley I have is a 12-tooth and can’t get one much smaller, but to get an 11:1 ratio with that I would need 12 x 11 = 132 teeth on the larger pulley and, as stated earlier, it would be the size of a dinner plate and would clash with other parts of the mount (if I could even source one). Then I had an idea - the stock stepper motor is a 1.8 degree-per-step type ... could I use a 0.9 degree type? The drive is based on pulses from the motor controller, which has no idea what type of motor is connected, so a 0.9 degree motor will turn at half the rate of a 1.8 degree motor (200 ‘steps’ sent to a 1.8 degree motor would result in 1.8 x 200 = 360 degrees of rotation - i.e. one full turn - whereas the same steps sent to a 0.9 degree motor would result in 0.9 x 200 = 180 degrees of rotation - half a turn in the same time). That would mean I would need a gear ratio of only 5.5:1, so in effect I would be halving the motor speed but doubling the rate again through the lower gear ratio with a smaller pulley, overall resulting in the same rate as the original 11:1 gear train. That means I can use 12-tooth and 66-tooth pulleys (5.5:1), or a 10 and a 55 if I could find them. Both are much more reasonable propositions. Finding pulleys of the right size has been difficult. I eventually found some in China via Ebay and Amazon, and right now I'm a week into the one-month delivery time! I have a 12 tooth pulley so I 3d-printed a 66 and after some trial and error managed to get it to grip the worm shaft without slipping. In tests over two nights I got guiding with an RMS below 1" and for this mount and this image scale it's perfectly fine. Attached are some pics, including the new Dec setup and about 90 minutes of H-alpha data from the Sadr region of Cygnus to demonstrate the performance. As expected it didn't (it can't) completely cure the Dec backlash. The worm and worm gear are what they are and a belt won't have any effect on them. All I can do there is try to optimise the meshing. Nevertheless, I can at least be satisfied that the additional backlash that was in the rest of the Dec gear train (3 meshed gears) has been eliminated. Hopefully a proper metal pulley will make a slight improvement, and I have some work to do to fine tune it all. If there is anything new to report I'll add it here.

Certainly the EQM35 is not the best mount on the market, but nor is it the most expensive so you can't expect the best quality from it. I find it has worked quite well for widefield work - Samyang 135 or Sharpstar 61 EDPHII in my case (with a cooled mono camera and filter wheel so a bit of extra weight). If you want evidence of its astrophotography capabilities then see the attached image created using data gathered using it with the Sharpstar 61 (14 hours). It can be an absolute pig at times, particularly the Dec axis where backlash seems to be ever present no matter what tweaks I have made. Getting the RA gears to mesh properly can also be a challenge - I was finding some high-frequency periodic errors that had PHD2 chasing them constantly, caused simply by the repeated meshing of individual gear teeth every 10 seconds or so. Persevere with the small tweaks and you may be able to tune it yourself into something very useable, but recognise its limitations - it's for lightweight scopes only. PHD2 Log Viewer is a great tool to help you pinpoint the problematic periodic errors and target them. There is a video online by a bloke who replaced the washers in his EQ3 with needle bearings. It's essentially the same mount as the EQM35 so I had a go, and it was all straightforward enough. However, my RA motor failed before I could have a good go at testing it, so I really don't know if it improved matters. My solution to the RA motor failure was a new motor and a home-made belt mod, which you can read about in the attached link. There's a link to the bearing mod video there too. The belt mod (possibly helped by the bearing mod) has been very successful and I've been scratching my head over how to do the equivalent to the Dec axis (the linked thread explains the issues with that). I think I have at last found and implemented a solution for it, and will be testing it tonight if all goes well, so hope to update that thread this week.

I have a Sharpstar 61EDPHII that has a built-in manual rotation mechanism, which is great for altering the orientation of different targets within the frame. Unfortunately there is no scale or reference points that allow the same orientation to be re-set next time I go for a target I’ve imaged before, and keeping track of different orientations used for different targets is difficult. So, I fixed that … Using the NINA framing assistant I platesolved the current field of view and asked for NINA to tell me the camera orientation. By altering the rotation of the scope and repeating the platesolve / orientation query I eventually got the camera to zero degrees orientation (perfect precision is not necessary). I marked this zero position on the OTA. By measuring the diameter of the OTA I could calculate the circumference in millimetres (you could just measure it directly with a tape measure - again, perfect precision is not necessary). Since the full circumference covers 360 degrees I could then calculate the number of millimetres per degree and established that 10mm of circumference is near-enough 15 degrees. So, starting from the zero position described above, I marked the tube at 15 degree (10mm) intervals up to 180 degrees. By aligning the appropriate number with the datum mark I can now ‘dial-in’ any orientation I need. Using the NINA framing assistant I can determine the orientation I want using the orientation slider and then set that on the scope. The markers were made using a label printer, each one individually printed and then overlapped slightly to get the correct 10mm spacing. You could easily do the same with masking tape and a pen. One thing to be wary of is the need to avoid physical clashes as you rotate the scope. I’ve had to position the dovetail in the clamp so that I can get the full 180 degree rotation without the EAF clashing with anything on the mount. This has resulted in the arrangement being back-heavy and unbalanced in dec but with the limited use I’ve had (about 2 hours) due to our customarily poor weather, it seems to guide and track ok. With this mount (EQM35) some dec imbalance can be helpful in managing backlash, but If it proves to be a problem I’ll investigate adding some weight to the front end of the dovetail. It’s important that if the setup is ever dismantled it can be put back together again in the same way (I occasionally switch the camera and filter wheel onto a Samyang 135) and so additional alignment marks have been added to achieve this. These allow me to align the filter wheel with the focus tube markings, and align the camera with the filter wheel so that ultimately everything is properly aligned.

The RA gear train is as follows: 12 teeth on the drive gear (attached to the motor) - call it gear A 48 teeth on the first driven gear - gear B 35 teeth on the co-axial gear rigidly attached to that - gear C 35 teeth on the last driven gear (attached to the worm) - gear D Gear A drives gear B. Gear C rotates with gear B because they are attached to each other co-axially. Gear C drives gear D. So: 1 rotation of gear D requires 1 rotation of gear C (both with 35 teeth). 1 rotation of gear C requires 1 rotation of gear B, since B and C are co-axial 1 rotation of gear B (48 teeth) requires 4 rotations of gear A (12 teeth) From all of that, 1 rotation of the worm (gear D) requires 4 rotations of gear A, hence 1:4 For dec the gear train is: 12 teeth on gear A (attached to the motor) 66 teeth on gear B 35 teeth on gear C (co-axial with, and attached to, gear B.) 70 teeth on gear D (attached to the worm) As for RA, Gear A drives gear B. Gear C rotates with gear B because they are attached to each other co-axially. Gear C drives gear D. 1 rotation of gear D requires 2 rotations of gear C (70:35) 2 rotations of gear C requires 2 rotations of gear B (co-axial) 2 rotations of gear B requires 11 rotations of gear A (66:12) So, 1 rotation of the worm (gear D) requires 11 rotations of gear A, hence 1:11

I made this mod and am also unconvinced about its effectiveness, but I’ve left the bearings in place. They are thicker than the fibre washers but a few strategically-placed metal washers on the worm carrier bolts allow alignment of the worm and gear and it works fine. I’ll never really know if it made a significant improvement because it was hotly followed by another mod that I know did make a significant improvement, but it’s also possible that the two mods together gave me that result. See the link below.

An update … Last night I managed about an hour of testing before it clouded over, and it confirmed the above conclusions. I left it running for as long as I could to get a decent guide log (it was quite windy, which wasn’t helping) and managed enough time to record a full worm cycle. The guiding graph is attached, showing an RMS of 0.74”, which was consistent through the time I had it running (other than when it was wind-affected) and far better than I’ve had before. I dug out a pre-modification guide log and had a look at the frequency analysis plot and as you can see from the comparison, the high-frequency oscillations (left side) have been eliminated and some of the low frequency oscillations have lower amplitudes. Those high-frequency oscillations were a problem, with one of them having an amplitude of over 1” and a period of 10 seconds. PHD2 was constantly chasing that. The one I cannot influence is the largest peak, which is caused by the worm itself. Some of the low-frequency oscillations are probably a result of the wheels not being perfectly true. Those two grub screws holding the wheel in place will inevitably push the wheel slightly to one side, meaning its axis does not perfectly align with the worm axis, and avoiding any slight tilt in the larger wheel is also tricky. The effect of these can be seen at maximum slew rate when there is a visible wobble in the wheel. Some tinkering and fine tuning is needed to limit those effects, but the bottom line is the RMS figure and the significant improvement this change has made. 😊

Ha! Yes that did cross my mind, and I’m willing to provide kits if anyone is really interested!

Excellent, thanks 👍🏻

Thanks - but they don't seem to provide any detailed product information or pricing. Is there another site that does?

I've just posted in the 'Equipment: Mounts' forum about a DIY belt mod on the RA axis of my EQM35, costing about £30. I'm sure cross-posting to multiple forums would be frowned upon, so here's a link --> https://stargazerslounge.com/topic/408724-eqm35-low-cost-ra-axis-belt-mod/?do=findComment&comment=4369316

For some time now I’ve been having trouble with the RA tracking on my EQM35. I use it for a wide-field setup (Sharpstar 61-EDPHII, 268mm) with an image scale of 2.9”/px, and the RA error was mostly tolerable but often not so. Recently the RA motor stuttered at all speeds other than maximum slew, and to identify the problem I connected a NEMA 17 in its place. It worked perfectly, eliminating the possibility of a connection or communication issue outside the non-maintainable motor itself. It looks like the stock RA motor is shot. So, I set about establishing whether the NEMA 17 could replace it. Initially the answer was a flat no given the need to connect to the existing gear train and the fact that it’s a bigger motor, so I pondered the possibility of a DIY belt mod instead, which had the advantage of eliminating some of the tolerance issues that gears present: the RA drive has four gears between the motor and the worm, with three points where gears mesh, each one introducing some kind of periodic error and backlash. To cut an already long story short, not only did the belt mod work but it was a spectacular success: my guiding has gone from a typical 2” RMS (if I was lucky, and I often wasn’t) to 1” RMS or lower during two nights of lengthy testing. On the first night of testing, it was matching my EQ6r Pro in roughly the same area of the sky (one on the Rosette, the other on the Cone). On the second night it was not so good, but still significantly better than what was previously normal for this mount. It was straightforward to establish the gear ratio on the RA train between the motor and the worm. There are four gears: the driving gear on the motor shaft (12 teeth); a gear driven by it (48 teeth); a coaxial gear rigidly attached to that (35 teeth); and finally, the driven gear attached to the worm (35 teeth) giving an overall gear ratio of 4:1. My first effort used 20-tooth and 80-tooth pulleys that I had lying around, connected by a 200mm belt, all held together by a Heath Robinson lash-up (a 3d-printed bracket attached to the weight bar). It wasn’t very elegant, but it worked and proved the concept, so I set about refining the bracket and bought new smaller pulleys and a belt – this time 12 teeth / 48 teeth and a 158mm belt. The photograph shows how it looks now. Still some minor refinements needed, but my EQM35 is performing better than it ever has. You may notice that the motor and pulleys are operating on the opposite side of the mount from the side the stock motor would be on. Viewed from this position the stock motor would be in the same orientation (drive gear facing you) on the other side of the mount, but conveniently the stub for the manual slow-motion control (that big old dangly spring that you probably don’t even possess) is well placed on this side and is longer than the stub on the other side, allowing more room for the large pulley. Another convenience is the position of the bolt holes for mounting the old motor, which have been repurposed to mount a new 3d-printed box to house the cable sockets (second picture). I should add that last month I had the mount in bits and replaced the fibre washers with needle bearings, as in this video -> (69) EQ3 Hyper Tune - YouTube (for an EQ3, but essentially the same mount). I didn’t get much chance before the motor problems to evaluate whether this alone made a significant difference, and the limited imaging time I did get left me unconvinced: it seemed as bad as before. I mention it because it’s possible that the improvement I’m seeing is a combination of the bearing mod and the belt mod. There’s no doubt though that the improvement following the belt mod has been dramatic – much better RA stability and improved guiding. I know there are commercially available controllers and belt mods for this mount, but they are not far short of £300. Leaving aside the cost of a 3d printer (which has paid for itself handsomely in the two years since I bought it, and continues to do so with every astro-widget I make) this has probably cost me no more than 10% of that. I’ve improved the RA, but what about the dec? Normally it’s pretty good and RA has been the source of all my issues, except one. Whenever I dither with this mount there’s a good chance my guiding will go off-scale due to dec backlash, and I usually have to stop-and-restart the guiding to recover it or lose one sub-exposure to drift – not great if you want to do unattended imaging. So, that’s the next target for improvement, but it’s a bit trickier to do a belt mod here. The gear ratio on the Dec axis is 11:1 and I won’t be able to get that ratio with two pulleys unless one is the size of a dinner plate. Perhaps the solution is a similar arrangement to the one I now have on RA but with altered dec slewing and guiding rates set in EQMOD, so there may be some trial-and-error involved. Those commercial upgrades no doubt have pulse rates to match their small pulleys, but I can’t alter the stock motor controller. Any suggestions here would be welcomed. For now, I’ve adjusted the worm carrier bolts to reduce the dec backlash but need to wait for the next clear night to test it. If that's improved it I'll leave it alone! For anyone wanting to give this a go, the parts list is: · NEMA 17 motor (4-wire with fitted connector) – a NEMA 14 might do it (I think that’s the stock motor) but haven't tried one so not sure. · 48 tooth timing pulley – 6mm bore (for a 6mm wide belt) · 12 tooth timing pulley – 5mm bore (for a 6mm wide belt) · 158mm timing belt (6mm wide) · Custom mounting bracket and socket housing (if you have – or have access to – a 3d printer!) · 2x M5 (5mm x 15mm) thumbscrews (standard M5 bolts would do if you're not fussed) + 2x M5 nuts STLs available on request for the 3d-printed bracket and socket housing. Total cost about £30 (less if you reuse the existing motor)

Thanks for feeding back into this thread - it’s always useful to have the solution recorded 👍🏻

I hope you track the problem down. Everything points to a broken connection, so check and check and check again. if (when) you find it, please post the solution here 👍🏻

The motor has several coils which are energised in turn by the controller. Each time a coil is energised it turns the rotor a small distance, then it’s picked up by the next coil as it becomes energised, and then the next coil as that is energised … and so on, resulting in the rotation. If a connection to one of those coils is broken then instead of being pulled forward the rotor stops, and can be dragged backwards by subsequent energisation of the previous coil. At high speed, the inertia of the rotor is probably too great for it to be dragged back after a tiny fraction of a second, so it struggles to get going but then it succeeds. At low rate the rotor stops and then just quivers. There’s a good explanation of stepper motor function here …

The motor issue you are having looks identical to the problem I had with my EQM-35. At a high rate it struggles to get going like mine did, but then spins freely. What about at a low rate? Set to a lower rate my motor just jerked backwards and forwards and didn’t turn at all (in fact I think it only turned at rate 9). Like you I investigated everything (I even dismantled the motor - not recommended - although it survived the trauma). I would say the problem is a broken connection somewhere. For me it was at the DIN plug - those black shrink-wraps can make it look fine when it’s broken. The connections are very fragile (poor design in my view) and moving them around can create enough stress to cause a break. You have shown a broken wire at the JST connector, which will obviously need to be fixed. Connecting the motor directly to the board doesn’t cure the problem, which suggests it’s not the interconnecting cables or the DIN plugs that are broken. Mine failed again recently and I discovered a broken pin in one of the JST connectors - no doubt it was weakened by all of my earlier efforts to track down the cause of the problem. To fix it I bought some new JST connectors (both male and female) with attached wires, but unfortunately the connectors were not the same size as the existing ones, so I cut the existing wires at the mid point and spliced the wires onto the new ones, same for both sides, replacing both the male and the female connectors. Now it works fine. I’ve had this issue twice now and both were due to broken connections. I did at one point buy a new motor controller but the problem remained, so it wasn’t that. Thankfully the retailer accepted my return. Therefore my advice is to search for broken connections between the board and the motors. No doubt you’ve done that already, but I did it several times and yet managed to miss the broken one each time (I think it’s likely that I was temporarily remaking the connection when testing it!). If you don’t find one then go back and check again (plugs, sockets, cables). If you don’t find one after several attempts, it’s probably a board fault and you may need a new board, but before you buy one check the connections again!