Hello everyone. I just build my first station and scheduled a few observations last weekend and turns out it is really fun scheduling satellite observation with fully automated acquisition!
I repurposed my old Raspberry Pi 3B+ and RTL SDR V3 (I’ve experimenting with Airspy HF+ but unfortunately with no success) acquiring VHF signals as I only have VHF QFH antenna at the moment, but probably I would like to switch to UHF as its more crowded there.
In the future I might integrate my rotator with this system, I’ve seen the option on satnogs-setup to connect to a rotator and probably will try that, maybe any tips from anyone regarding this? Also, I might plan to split the UHF output from the Yagi to SDR and my radio (RX only) so I can have regular QSO with the audio recorded by SatNogs on that pass, I wonder if this is possible?
I think that’s it for now, we’ll see how long this station will be online up
By the way, I think there’s an upcoming Transporter 14 next month. Is there any way that my station can contribute to that launch observation?
I have an extremely tiny experience using pre-eliminary TLE with ASTRU/AO-123 launch back then, but that was mostly manual observation using a laptop and smartphone to see the pass schedule.
If your station is online and there is a satellite or more transmitting on your station’s supported frequency range then your station is going to be part of the usual operations we perform as Network.
This option isn’t related with the generic scheduling but only for those that don’t follow regulations, for example satellites that are not coordinated with IARU and transmit in amateur radio frequency. You can check more about it in this thread, which soon will be added in the satnogs wiki with some more details.
Hello, I have another question. How to connect the Satnogs computer (Pi) to the rotator (SatNogs rotator)? I followed the instructions on the wiki but the rotator isn’t moving on the scheduled observation. It works fine when using GPredict. Am I missing something maybe?
Not sure what you have running, guessing legacy (not docker) client as you have hamlib at the host.
I would recommend using rotctld and have -client connect to that instead of the client launching it’s own, byt ymmv. Let the default values like threshold and flip be unset to begin with.
Anyhow, if you have not set the min/max values I’m guessing it will have some odd defaults that the client isn’t happy with. I use -C min_az=0,max_az=360,min_el=0,max_el=180 but make sure the max_el is appropriate for your setup.
If using a separate rotctld, make sure to set the MODEL to ROT_MODEL_NETROTCTL, and PORT to ip:port (127.0.0.1:4533 or similar) of the rotctld.
Thanks for the response. Sorry, I’m quite a begginer about SatNogs but how do you know which version that I run?
For clarity, I’m using SatNogs rotator V3 with CNC shield as the motor/rotator controller that connected to Pi with USB connection. I manually tested the rotator/connection by inputing rotator command on terminal to make sure is working fine (which it is).
it depends, the legacy stack did, but the newer dockerized does currently not (out of the box).
looking at the rotctl prompt, it is using latest master from git ?!
do note that hamlib versions are not usually compatible with each other. if the client is running hamlib 4.0 in docker and you have 4.7 on the host, it will probably not work.
I still don’t know if you’re running the legacy or docker client. can you show the support info from satnogs-setup ?
if it’s the newer docker client, then this is how I run it.
And now that you’ve shared that link I will have something new to try. Will report back on how it goes.
Edit: I created a second SatNogs station for experimental and testing use so I wouldn’t have turned on/off or getting failed observation my main station (I’m going to use this for the rotator setup anyway).
I’ve done the homework, installed docker, your script, etc. and it finally end up into this. I’m not at home so I’ll tested it later when I can connected this Pi to the rotator.
by the looks of it, you did not configure the compose yml with the usbserial device you have.
devices:
- '/dev/ttyACM0:/dev/rotator'
Should be something like /dev/ttyUSB0:/dev/rotator in your case.
The main issue with this is that when you unplug the usbserial and reconnect it, it might be named ttyUSB2 or something else in the range of ~0-2. To make it predictable you can use the by-id symlinks instead.
example:
so setting it to this instead will make it predictable across reboots and replugging: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A10LLTAK-if00-port0:/dev/rotator
yes, you need to configure the -client to connect to the netrotctl model and it’s ip:port.
Okay, now can bring up the docker compose up -d and connect the rotator using the docker compose exec -it rotctld rotctl -m 2 and do a test run using the P command.
But when I scheduled an observation, the rotator still don’t move. Maybe I’m still missing something? I’m guessing there’s something with the port. Here’s the rotator settings in satnogs-setup and on docker-compose.yml file. I also tried localhost:4533 for the port setting.
localhost/127.0.0.1 makes no sense in docker, each container has it’s own loopback which isn’t shared with the hosts.
you need the lan/wifi ip, or the docker0 ip, look at command: ip a s docker0
Holy shoot, the rotator is moving. It’s almost at 1 A.M here and I’m about to call for the day so I entered 172.17.0.1:4533 on the satnogs-setup rotator port and turns out that was it .
Thank you so much @SA2KNG for patiently helping me troubleshooting this.
.