So I’m trying to bring back to life my old (c2019) SatNOGs station. At the moment, a simple configuration - RPI3 + NOOElec SDR (NESDR SMArT) + Vertical Antenna.
I following the instructions per Raspberry Pi - SatNOGS Wiki however appear to have run into all sorts of issues - primarily:
PLL Not locked on the SDR, and
Unable to import Axes3D error messages in the client log on startup.
That is after dealing with all the stuff (like pipx) that didn’t seem to get installed initially.
What is the recommended way forward? Persevere with the the ‘docker’ version or go back to a legacy version per Raspberry Pi Legacy - SatNOGS Wiki .
It would also appear that some of the instructions (e.g. reviewing client logs) in the Operation - SatNOGS Wiki (link not provided due to forum limit) may need updating - i.e. journalctl doesn’t work and there is no ‘/var/log/supervisor/satnogs.log’ to open using tail.
I had a similar problem with my SDR about PLL not locked, I was unable to receive any signal. What I did:
Update drivers
Change the dongle of USB port
This happened to me just before using rtl_tcp -a command and testing SW signals, maybe my dongle just got stucked. Have you tried?
For logs I use “docker logs -f satnogs_satnogs-client” command
And for Axes3D, this can be ignored as indicated by bali, since this error don’t affect the operation.
I have a RPI3 + RTL-SDR v4 + Yaggi Antena working good with docker version
Thanks. Yeah - I did some hunting and found the command but it doesn’t help that the primary source of info/guidance is misleading. I’m pretty sure the drivers are up to date (but will do so again) - and will give the USB port change a try. Might also see if it is a power supply issue (separately power the dongle via a powered hub). Haven’t used the rtl_tecp -a command (the software may have at some stage). I’ve done reboots etc but nothing seems to change. Get the same message everytime in the log:
rig_check_rig_caps: p1=0x7fa1b70640, p2=0x7fa1b76bc0, rig_model=0x7fa1b70640, macro_name=0x7fa1b76bc0
initrigs4_dummy: _init called
rig_init: rig_model=Hamlib NET rigctl
rig_init: rx_range_list1 is empty, using rx_range_list2
rig_init: rig does not have tx_range!!
netrigctl_init version 20230106.0
Found Rafael Micro R820T tuner
[INFO] Opening Generic RTL2832U OEM :: 00000001…
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[INFO] Using format CF32.
Allocating 15 zero-copy buffers
netrigctl_close: done
netrigctl_close: done
That netrigctl_close is occurring well before the pass is over - possibly prior to it actually commencing.
I’ll keep you all posted as I’m looking to build out a few more stations (but I need to get this one working first).
I did an install using Bali’s instructions. Same outcome.
I found a webpage discussing this issue. Followed some instructions on my ‘first’ station (standard Satnogs docker based install) which then got me getting no further [R82XX] PLL Not locked messages when running rtl_test (after a reboot). Unfortunately, in that process I’ve managed to entirely stuff that station (likely as there are now multiple instances of rtl_test and the drivers running around. Time for a reinstall.
What 2 did was have me suspect there is an issue with the rtl-sdr drivers bundled with SatNOGS when it comes to the R82XX based dongles.
Went to my ‘other station’ (from 1 above). Plugged in the E4000 based dongle - all good. Tested a pass and could see the tracking data going into the log. Fudged a pass (don’t ask…) to prove that the receiver is tracking and all is good. Based on that….
Went to my ‘other station’ (from 1 above). Plugged in the R82XX based dongle.Tested a pass and could see the tracking data going into the log. Fudged a pass (don’t ask…) to prove that the receiver is tracking and all is good. Note: before and after rtl_test says the PLL is not locked.
Based on the above, I think there may be an issue with the RTL drivers. I have also come to the conclusion that perhaps the PLL not locked message is misleading - either the drivers aren’t reporting properly or it simply doesn’t matter. Note: It is impossible to run rtl_test while the pass was underway (I was wondering if the PLL was getting lock once a frequency was set) as the satnogs-client has control of the USB device.
Next is to go back and do a reinstall of the first station, set the logging to DEBUG and watch the messages again. At this stage, I think I’m going to stop worrying about the message, repeat the pass fudge tests to prove it is actually tracking and move on.
Hoping this might help someone else in the future… I’ll update as and when I get things done.
Hopefully both stations will be on the air soon - given there are only 14 SatNOGS stations in Australia - it might be of assistance to the network to get a few more on the network.
I’m getting the PLL Not locked warning on any of my R82XX based dongles.
As for working on the RPi3 - yeah, I think so. I’ll likely do a reinstall to make sure at some stage (and will let you know if there is anything additional that needs to be done to make it work)…. actually - there is one thing. I run headless RPis. The OS no longer comes with a default username and password so there are a couple of extra steps. I’ll write to you about them in case you want to update (along with anything else I discover).
The docker installation as described on the wiki should work fine “out of the box”. It’s somewhat confusing that you mentioned that you had to do things with pipx. Why did you need to use pipx?
To follow the logs, run: sudo docker logs satnogs_satnogs-client -f as mentioned in the troubleshooting page. We don’t use supervisord in our containers.
Can you point me to the page where journalctl is mentioned? I’m unable to locate it and we will have to fix this ASAP.
P.S. I just realized that the issues is resolved? I was answering as I was reading and most of my answer has already been covered by other people.
P.S2 I think that the PLL not locked warning shows up when the drivers starts and the tuning frequency is unknown. I believe that it tries to tune it to an unsupported by the hardware frequency.
Operation - SatNOGS Wiki - First dot point under Ground Station makes reference to journalctll and tail to view logs.
As for rtl_test… I think the issue is that rtl_test ISN’T setting a frequency (I think it may if you use -t with a E4000 based receiver) and therefore the PLL is never locked. As previously stated, even after a pass where the frequencies were being set (and this was checked and validated by transmitting on the satellite frequency and verified by the recorded waterfall) once the pass was over and rtl_test was run - the PLL was not locked.
PIPX - To be honest, I can no longer remember. Actually - yes I can. I was trying to resolve the Axes3D issue that I could see coming up in the logs. I used pipx to be able to install the Mathplotlib into the virtual environment (after blowing away any system level (APT) Mathplotlib installation).
Thanks a lot! I fixed that temporarily. The operations sections needs some overhaul in general.
It’s very strange that it did anything. The containers should be running with a read-only filesystem so changes (like installing new packages) shouldn’t be allowed.
Thanks! I fixed the SoapySDRUtil invocations commands in SatNOGS Setup page but I didn’t on the Omni station how-to because the information there is very outdated and needs a complete rewrite.. I can either remove the reference to the Omni how-to completely or add a warning banner that says that this info is outdated until we rewrite it.
Your (LSF) call - not mine. I’m just relaying what where the mines are in the minefield for someone trying to get a station up and running - in particular if they aren’t fluent in the ‘docker’ space.
