Yesterday I finally updated my station (488) to the latest software and re-entered the values I had previously used. Now there is no TCP/IP comms with the other PC with my homebrew rotor interface. Double checked the IP and port number and used the same Hamlib rotor model (-m 682) as before.
Any suggestions?
Ken
Since posting I re-read the Wiki and have entered "ROT_MODEL_GS232AROT_MODEL_GS232A instead of -m 602 in the “satnogs_rot_model” field, but still not working.
You also need to set SATNOGS_ROT_PORT to something like: 127.0.0.1:12345 when using ROT_MODEL_NETROTCTL for remote controlled rotctld instances. On the remote side you need to specify the desired rotator model when firing up the rotctld.
Still getting nowhere getting the rotor TCP interface to work after the update. Now trying the simple Easycomm interface. Here’s the current settings:
and the journal after a pass:
It’s trying to open a serial port which I haven’t set. I’m using TCP/IP. Really puzzled.
Ken
Yeah, you‘re using wrong assumptions!
Set SATNOGS_ROT_MODEL to ROT_MODEL_NETROTCTL and on the remote end set the corresponding rotator model.
Still no success. Changed the rotor model:
but still getting the error showing it’s trying to open a serial port. Nowhere do I have “/dev/ttyUSB0” entered.
Hehe, alright, you didn’t follow my suggestions completely: set the IP and Port in SATNOGS_ROT_PORT to 192.168.1.131:4355 and remove the SATNOGS_ROT_IP settings, as it is useless here.
Thanks again! Finally have the remote rotor working. For anyone else that may have a similar problem, here are my settings:
This was definitely not documented well, and I hit exactly the same issue when I went to upgrade station #232.
I’ve made some updates to the wiki page with this information: https://wiki.satnogs.org/SatNOGS_Client_Setup#Advanced_Setup
The rotor was now working fine and today I’m getting errors regarding the port value. SatNOGS starts sending az/el info to the PC but then stops after a few messages. All the passes are failures.
I did an update and re-entered my data shown in the previous posts. So am really puzzled.
What?
This can’t change on itself… This is (and probably always was) a wrong implementation of the _PORT setting, as it was always intended to specify the “serial” port where the rotator is connected to! Seems this has been misunderstood since ever! The hamlib docs (man rotctld) clearly states a file argument there - not int!
This needs to be fixed…
Based on the backtrace in your latest log output it’s clear that satnogs-client is installed in an outdated version (pre-version 1.1, compare satnogs-client@1.1:settings.py#L74 vs satnogs-client@1.0:settings.py#L70).
The current stable version of satnogs-client is 1.1.2 (source: [1]).
With satnogs-client 1.1 the meaning of SATNOGS_ROT_PORT was changed, thus a Configuration update for rotator stations with satnogs-client 1.1 is required.
Please update your station and keep your previous configuration from your post#7, this looks ok.
In case of further errors, please also post the output generated by Advanced->Support from satnogs-setup.
Sincerely,
kerel
After I did the update in March ROT_MODEL_NETROTCTL started sending data to my homebrew client, however it’s still has issues:
So, I suspect the client should be sending some type of setup info to satnogs regarding rotor type. Tried to find the source code for the NETROTCTL so see what it expects from the client besides the az/el response to “p” but couldn’t locate it. All I’m looking for from satnogs is an Az/El stream for the duration of the pass.
Thanks (yet again),
Ken
dump_state is optional. You do not need to implement it in your client. In Hamlib, it returns the rotator model attached to the network controlled rotctld and the minimum and maximum azimuth and elevation the rotator supports.
I don’t know why positioning stops after crossing 0° or 180°. Have you enabled antenna flipping option?
I don’t see anyway to enable any options with ROT_MODEL_NETROCTL.
Maybe I should try responding to \dump_state but I haven’t found any documentation in the hamlib files as to what I should send for my G5500 rotor.
I’m using the settings shown in my 14 March post above.
Which options do you want to set and where? AFAIK, ROT_MODEL_NETROCTL should work even with no support for \dump_state.
In Satnogs client configuration I like to set the rotor type to -m 601 for the Yaesu G5500 rotor. My rotor covers 0 to 450 degrees, so that should be set, as well as a switch for flipping.
Before NETROTCTL was implemented I believe the rotor type was set in HAMLIB_UTILS_ROT_OPTS but that doesn’t seem to work with NETROTCTL. I never found the settings for flipping or 0 to 450 degrees.
Update: Set
satnogs_rot_flip = true
hamlib_utils_tor_opts: -m 201 (for Easycomm 1)
but no change in behavior. Still won’t track past 180 or 0/360. An example is observation
https://network.satnogs.org/observations/2557529/
The sat AOS was at 176 degrees but the rotor commands stopped at 179.98 degrees. The satnogs_rot_flip had no effect even though this was a 77 deg elevation pass.
Another data point is pass https://network.satnogs.org/observations/2557530/
AOS az was 184 degrees but the rotor interface never sent any az/el commands, just the \dump_state at start followed by the “p” position queries.
And had a nice 83 max el pass with flip enabled but the ROTCTL wouldn’t let the elevation past 89 degrees, so it looks like ROTCTL doesn’t know it supposed to exceed 90 deg elevation, either. The pass was: https://network.satnogs.org/observations/2556528/
(good tracking since I was actually commanding the rotor from my tracking program while monitoring what ROTCTL was sending.
Ken
Hi I’m trying to set up a similar system and I’m having trouble finding documentation for how to configure the remote end. How do you set the rotator port on the server side?
I haven’t made any progress, nor found any documentation, since my original posts. Only get tracking data from NETROTCTL when the satellite’s azimuth is between 0 and 179.9.
Ken
