I have an automated tracking system consisting of Gpredict and a Yaesu G-5500DC, along with a 15x15-element 70 cm cross yagi antenna to track CubeSats. Hamlib and an Arduino Mega 2560 with k3gn rotator controller code controls the control box of the Yaesu G-5500DC.
However, the antenna is too large, and when Gpredict controls the rotator using Hamlib, an Arduino Mega with rotator controller code, it speeds up and suddenly stops every time the antenna reaches the threshold or tolerance of Gpredict (around 5°). This bumping creates a shaking effect in the antenna, which destabilizes the signal reception and affects other components.
I read that it is possible to regulate the speed of the rotor using an H-bridge PWM, but I don’t have any idea how to set up the H-bridge to the azimuth and elevation pins and the whole setup. Would the control box of the Yaesu be replaced and should the H-bridges be connected directly to the pins of the azimuth and elevation rotors? If so, which connections should be made to the H-bridges? I want to be careful not to ruin the Yaesu.
I have the older AC motor version and don’t have access to the DC variant, but. For a long time there are several of us that think there should be a speed-controlled controller for these rotators. AC motor speed control is not difficult these days, surely the DC variant is even easier to manage. As you well point out, the zero-to-full speed behavior can be a problem.
A student of mine made a controller that predicts the next commanded position and slowly moves there beforehand, smoothly correcting the mis-predictions and position as the commands arrive from Gpredict / satnogs-client / et al. That rotator used a stepper motor, but the idea seems easy to port to other motor drives.
Someone should do a market study and see how much of the installed user base would upgrade to such a control box. If I do so, the designs would be open-sourced as an LSF project. It’s been a 3rd-level priority thing for forever
You’re not the only one to cringe every time your G5500 moves…
In general for the DC version: an H-bridge with PWM would be attached to the two motor pins to control the speed and direction. You’d want to somehow keep an eye on potential motor overheating, as I think the motor is rated for a 3min on / 15min off duty cycle. Just a trapezoid speed profile to smoothly slew the 5deg would be a huge improvement.
If I do so, the designs would be open-sourced as an LSF project. It’s been a 3rd-level priority thing for forever 