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.
So here are the main questions about How SatNOGS ground station it’s supposed to work:
Raspberry Pi with SatNOGS-client installed needs GPredict to track satellites?
If so, which configuration do we need to do in order for SatNOGS-client to control the rotor?
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?
We’ve seen rotctld used with both -r and -T -t like in the example below:
rotctld -m 202 -r COM3 -s 9600 -T 127.0.0.1 -t 4533 -C timeout=500 -C retry=0 -vvvvvvvv
should we also configure “-T 127.0.0.1 -t 4533”? Is that our missing configuration that communicates GPredict to Arduino via rotctl through device “-r”?
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)
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 <hamlib-developer@lists.sourceforge.net>
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
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 127.0.0.1 -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.
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
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
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?
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.
)
