To use the rotor with satnogs GPredict is not required at all. Hope that answers your question.
Basic question for SatNOGS ground station [Help needed]
2 Likes
“To use the rotor with satnogs GPredict is not required at all.”
Thanks for been that clear! (I’m gonna stop making that question 
)
Now the question that remains is, what could be not working?
I got rotor enabled on satnogs-config
and parameters correctly configured (updated -s 19200 and )
I’ve make rotor move using
rotctl -m 204 -s 19200 -r /dev/ttyHOTSPOT -C timeout=200 -vvvvv
/dev/ttyHOTSPOT is symilink name for arduino’s port
sending for example:
P 180 90
and getting response for “p”
After this, I scheduled an observation, but when the time comes nothing moves…
Any suggestions?
Thanks for any tip or response.
You might be running another rotctld while the client tries to invoke it. Check with $ ps aux | grep rotctld and paste the output.
1 Like
Hello again!
Finally could did what you asked for
pi@TheNewHotSpot:~ $ ps aux | grep rotctld hamlib-+ 321 0.0 0.2 5152 2292 ? Ss 19:42 0:00 /usr/bin/rotctl -m 204 -s 19200 -r /dev/ttyHOTSPOT -C timeout=2000 pi 754 0.0 0.0 4372 544 pts/0 S+ 19:45 0:00 grep --color=auto rotctld
Here are our configurations (just for show)
We also tried that command while running an observation scheduled (nothing changed)
And finally just to show everything we can here are also the logs (journalctl output)
journalctl -f -u satnogs-client.service_.txt (13.4 KB)
Hopefully any of this could help
The result doesn’t match the grep command, maybe a c&p error!?
hello,
here are both command responses, before and while running
the only diference we see is the Ss and Ssl before May24
Just in case… have you hit “Apply” when you changed these parameters in satnogs-setup?
jaja yeah i’m sure, many times
Hi DL4PD, I jope you are doing great!
Why do you say that the “ps aux” did not match the grep command?
Also, If you have a SatNOGS GS running, may you run the command an paste us the output in order to compere ?
Thanks in advanced
Well… We got the rotor moving manually using
pi@TheNewHotSpot:~ $ rotctl -m 204 -r /dev/ttyHOTSPOT -s 19200 -vvvvv
But we are out of ideas trying to make it move in schedule observations…
Client configuration seems to be as it should be
Any tip will be highly appreciated!
Thank you very much in advance!
We are really close to make it work!
I’ve just noticed that in your manual command you pass first the -r parameter and then -s as it is also suggested in man rotctl. However in the screenshot, it is the other way, not sure if it plays any role (probably not) and unfortunately I’m not able to test it right now.
One more thing to check is if the device /dev/ttyHOTSPOT is accesible by satnogs user/group. Run sudo su - satnogs to login as satnogs user and then try to run again manually the command rotctl -m 204 -r /dev/ttyHOTSPOT -s 19200 -vvvvv.
You are grepping for rotctld and the result shows a process rotctl running - this does not match!
You need to fix the baudrate issue as well, although this is not the current problem (but it will lead to more problems for sure)!
We keep on fighting…
just in case we changed the configuration order
Also don’t know why now response to command $ ps aux | grep rotctld doesn’t show user hamlib-+
watching RP journal we saw an error we were not getting before, as shown in the image below in yellow, RP is trying to connect to 127.0.0.1:4533
Maybe satnogs client is expecting AZ and EL from that connection?
should we also configure “-T 127.0.0.1 -t 4533”?
https://www.systutorials.com/docs/linux/man/1-rotctl/
Also used to specify the host and port to connect to a listening rotctld daemon on POSIX:
-r localhost:4533
and on Win32:
-r 127.0.0.1:4533
Patrick,
don’t know why the “d” is missing but as shown in other replies hamlib-+ is running rotctld.
Baudrate is already fixed at 19200 seems to work fine.
well… something did the trick…
maybe it was the change in parameter’s order or maybe it was just turning everything ON with everything connected (sometimes we connected the arduino with RP already ON)
dont really know what was happening!
thank you all very much!
No, that’s wrong! As I told you before: if your code sets up a baudrate at 9600 baud and you need to change it to 19200 in the application connecting to that code there is something really wrong! Most probably the microcontroller is running at the wrong speed. This will cause more problems in the future as all the timing your code is using will be wrong.
sorry I could not follow you, now both the speed in the arduino’s code and in rotctl (RP) are set to 19200 baudios.
Or do you mean that it should have also worked with both at 9600?
Now is actually working, we would really prefer not to change more stuff just in case we go back to square one
This is the default socket address:port of rotctld, no need to set it in command line.
Glad to hear it! 
It would be great sometime in future to find out what happened… maybe by experimenting again with the parameters order and/or the other things you changed.
Ok, that was not as clear as now in your previous posts - I did not get it 
So if both baudrates are set correct (in the arduino C code and the connecting interface) you are free to choose whatever you prefer! Glad it works now!
Hi,
I think i actually have the same issue as you, the “P” command from the RP are perfectly working (rotctl -m204 -r /dev/ttyACM0 -s 19200 -vvvvv), Hamlib is well enabled , BUT, nothing move when i schedule an observation…
I’m using an arduino uno with a “CNC shield” and that was perfectly working standalone with grpredict on my pc but i wanted to upgrade it to “Satnogs”
I’m sure that this is well ttyACM0, I’ve done the ls /dev/tty* verification
And during the boot of the raspy i have this error : {FAILED} Failed to start rotctld server .
This error message comes after 4 time “Started rotctld server.
Stopped rotctld server .”
Did you had the same “error message” and or did you finally finded a clear solution that could maybe work too in my case ?
Thanks in advance for your answers