so ive been messing around with this idea for a few weeks now and i think its actually doable but wanted to see if anyone else has gone down this road before i sink too much time into it. basically i have an old yaesu G-450A rotator that works fine mechanically but the controller unit is pretty beat up and im thinking instead of hunting down a replacement controller i just build one around a raspberry pi.

the plan is to use a pi 4 and a couple of ADC chips to read the pot position from the rotator, then drive the motor direction relays through a relay hat or maybe just discrete transistors off the GPIO pins. i already have most of the parts lying around from other projects. the tricky part i think is going to be the feedback loop to get smooth stopping without overshooting the target bearing too much - anybody dealt with that? i know some people use a PID loop for this kind of thing but ive never actually implemented one and not sure if thats overkill for a rotator that moves like 3 degrees per second anyway.

also thinking about slapping a web interface on it so i can control it from inside the shack over the local network, maybe tie it into my logging software eventually. running hamlib on the pi might be the easiest path for the logging integration but not sure. anyway if youve done something similar or have thoughts on the relay driving side especially id love to hear it

yeah i did almost exactly this with a G-800 a couple years ago, used a pi 3B+ and it worked great. the ADC side is pretty straightforward, i used an MCP3008 over SPI and it was solid. for the relays i just went with a small relay module board, the GPIO current is enough to drive the optoisolated relay boards no problem, dont try to drive a real relay coil directly off the GPIO pins though, found that out the hard way with some weird brownout behavior before i figured out what was happening.

on the PID question - honestly for a rotator that slow you probably dont need a full PID implementation. i just did a simple deadband approach where if its within like 2 degrees of target it cuts the motor. works fine in practice. the overshooting really depends more on how much mechanical slop is in the gearbox than anything in the software. if you do want to get fancy though there are python PID libraries that are easy to drop in.

hamlib integration worked well for me, rotctld handles it and most logging software that supports rotator control will talk to it. thats definitely the way to go rather than rolling your own protocol

not done the rotator thing specifically but i've been running a pi-based station automation setup for about a year and a half and the web interface piece is where i'd spend the most time thinking up front. i started with a quick flask app and it worked fine but then i wanted to add more stuff - band switching, antenna selection, eventually a basic keyer interface - and the flask thing got messy fast. if you think there's any chance you'll expand it later maybe look at something a bit more structured from the start, or just keep it really simple and accept it'll be a bit of a hack. both are valid honestly.

one thing i will say is put some kind of watchdog or failsafe in the relay control logic. had a situation where a python script crashed mid-rotation and left the motor running. rotator hit the stops hard. nothing broke but it could have. just something to think about