Basic question for SatNOGS ground station [Help needed]

Hello folks,
my friends and I have been trying to implement satNOGS ground station using a Raspberry Pi 3 and an Arduino UNO.
At the moment we managed to get the hardware together, but we are still struggling to control the rotor.

We decided to communicate the Arduino to Pi via USB on PI to serial port in Arduino as quartapound did in this post (even used his easycomm.h):
Satnogs Rotator using an Arduino Uno and CNC Shield with A4988 drivers and Nema 17 steppers with Direct PC connection

So here are the main questions about How SatNOGS ground station it’s supposed to work:

  1. Raspberry Pi with SatNOGS-client installed needs GPredict to track satellites?

  2. If so, which configuration do we need to do in order for SatNOGS-client to control the rotor?

  3. We know GPredict can be used to send commands to the Arduino, but is there a way (configuration) in which just by scheduling an observation in SatNOGS network it also tracks the satellite? or this two things must be done separete ways?

  4. We’ve seen rotctld used with both -r and -T -t like in the example below:
    rotctld -m 202 -r COM3 -s 9600 -T -t 4533 -C timeout=500 -C retry=0 -vvvvvvvv
    should we also configure “-T -t 4533”? Is that our missing configuration that communicates GPredict to Arduino via rotctl through device “-r”?

  5. We’ve also tried sending commands directly to the Arduino by plugin the USB directly to our PC, via IDE’s serial monitor, sending something like “AZ45.0 EL45.0” but still motors are not moving, it would be helpfull to be sure that’s the correct format for what Arduino is expecting (so we can move forward into debbuging the problem of the lack of movement)

Some answers before going into details:

  • You don’t need gpredict to run a SatNOGS groundstation
  • You should ensure your rotator is working

A SatNOGS groundstation, exactly the same as gpredict does, uses hamlib to communicate with radios and rotators. This is done using the tools rigctl[d] and rotctl[d]. The ones with d at the end are daemons to be used in the background once you’re sure everything is working fine. In the meanwhile you can test you setup using the the tools without the d - they take the exact same commandline parameters. You need to check the user rights on serial communication devices like dev/ttyUSBx. Your current user needs to be member of the group dialout. The parameters to rotctl you provided are describe in the manpage (use $ man rotctl to read it) or the commandline help (use $ rotclt --help to read it). In short:

  • -m xxx selects the rotator model (or protocol)
  • -r $serial selects the serial device the rotator is attached to (COM3 seems to be wrong here!)
  • -s $speed selects the communication speed of your rotator
  • -T $ip configures a port where the daemonized tool will listen for connections on
  • -t $port configures the port for the connection above
  • -C $parameters are additional parameters for hamlib
  • -v[vvvv] enables verbosity, five should be the max it takes and it gets more and more verbose with each vadded

Try to find out on which serial device in /dev/ttyUSB* your rotator is attached to, then replace the COM3 above with this path, e.g. -r /dev/ttyUSB0!
After you found it, simply try:

$ rotctl -m 202 -r /dev/ttyUSB0 -s 9600 -vvvvv
rotctl, Hamlib 3.1
Report bugs to <>

rot:rot_init called 
dummy: _init called
rot_register (1)
rot_register (2)
dummy_rot_init called
rot:rot_open called 
dummy_rot_open called
Opened rot model 1, 'Dummy'
Backend version: 0.2, Status: Beta

Rotator command: p
rotctl_parse: input_line: p
dummy_rot_get_position called
Azimuth: 0.000000
Elevation: 0.000000

Rotator command: 

If there does not pop up any error you have a working rotator communication! Otherwise read the error description carefully and watch the debug output!
If it works you can try to move the rotator using the P $az $el command, where $az and $el are three digits parameters, like P 180 090 for 180 degrees azimuth and 90 degrees elevation.

As this answer is getting pretty large now: feel free to ask some more questions once you digged that out :wink:



Hello Patrick,
first of all thanks a lot for your response. We’ve been looking for basically anywhere, where anyone states clearly that GPredict is NOT needed in order to have a Groundstation that does tracking (sends commands to the rotor), and just with SatNOGS-Client it’s enough for this.

To sum up, I beleave we solved Raspberry’s issues, and now we must move forward to solve Arduino’s lack of communication. (At the bottom is the problem that we suspect is Arduino’s fault)

Here is our current configuration:

(We dealt with the problem of Raspberry Pi changing the device randomly when rebooting by editing a rule using symlink so our device will always appear as /dev/ttyHOTSPOT)

root@TheNewHotSpot:/etc/udev/rules.d# vi 99-com.rules

Going on through your suggestions. We verified if our user was part of dialout group to be sure that was not the problem using getent group dialout command.


Finally lets move on to rotctl, first of all I used the command with COM3 as an example I copied just to ask about the need of options -T -t 4533 I still don’t understand if I need this parameters and what for if so (we were not using COM3, we were using ttyACM0, and now use ttyHOTSPOT)

Secondly, we are having problems with rotctl command p as can be seen in images below.
It seems the problem is Raspberry Pi ain’t getting response from the Arduino, so now we are focusing in getting the Arduino to do it’s magic.


If it’s okay for you, in order not to make this thread longer we may discuss Arduino’s problem in this post:

Thank you very very much, we’ve been struggling with this questions/issues for a long time.

1 Like

You did good following this instructions! Now you know from the top end down where your problem sticks (not what it is, but where!).

One hint on groups: you can easily view the groups a user is member of using

  • $ groups $username

I’ll read the other topic and may give some more hints.

Regarding the random change of USB devices: that’s very common as you also found out. I did the same and a name like COM3 or rotator would also have worked fine :wink:

1 Like

Hey!! In Basic configuration setup of SatNOGS client, it has the option for HAMLIB_UTILS_ROT_OPTS, where you can put your options for rotator. :beers:


Azisi, yes I saw that, but as I still don’t know very much about how the client gets the AZ and EL, I wasn’t sure if I needed also to install GPredict and do some configuration over it for that.
Thank you both

You can always use gpredict to control your rotator, but it is not needed for a SatNOGS node!

1 Like

Houston we have a problem…
I got the rotor moving and communicating to RP successfully, but I thought that was enough to schedule an observation in satnogs network and get the rotor to track the satellite.
It seems is not…
I did schedule an observation but the rotor ain’t moving… (just to be clear the satnogs-setup has the rotor’s options correctly configured and turned ON).

So I’m starting to think I need to configure GPredict, I guess I didn’t make myself clear about that question? I know I don’t need a rotor for a satnog node, but If I want my node to work with a rotor then I do need GPredict?
also I don’t have access to visual interface, is there a way of getting that fix via command line? do I need to schedule every observation both in satnogs network and in GPredict to make te rotor work?

Thanks in advance, sorry if too noob :sweat_smile:

To use the rotor with satnogs GPredict is not required at all. Hope that answers your question.


“To use the rotor with satnogs GPredict is not required at all.”
Thanks for been that clear! (I’m gonna stop making that question :sweat_smile: )

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!?


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 :sweat_smile:

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

@DL4PD @fredy @KD9KCK @azisi

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)!