PROBLEM WITH INSTALL:
I’ve followed the installation notes religiously, updated the client, installed Python3 and installed gr-satellites.git but now, upon checking the install with gr_satellites --version I received:
Traceback (most recent call last):
File “/usr/local/bin/gr_satellites”, line 16, in
import satellites.core
ModuleNotFoundError: No module named ‘satellites’
And so added the suggested PYTHONPATH by editing ~/.bashrc but the same error message prevailed.
I have followed through this thread (some of it being above my pay grade), then re-installed python3-construct, which indicated all was up to date and satisfied (only one addition), but giving this message:
Failed to check for processor microcode upgrades.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
So I’m no further forward.
Would anyone, or in particular @SA2KNG, have any advice on how to rectify the problem(s) and get gr-satellites going, please.
And are UHF satellites yet included?
Thanks in advance.
This should still be the problem, you should try it in a shell you’re running first and then adding it to .bashrc or similar: installing - pythonpath
Make sure it’s actually installed there, pointing it in the wrong direction doesn’t help (:
There are no specific bands supported afaik, lots of UHF birds in the list
Many thanks @SA2KNG - suggested changes made and satnogs_gr-satellites now completed install and appears to be working well…
73
Could someone provide an example of a UHF satellite that ‘satnogs_gr_satellite’ can decode/produce data frames from where as the core ‘satnogs-client’ with advanced updates can not ?
The Funcube satellites with BPSK telemetry are very good example to test with.
Try FUNCUBE-1 “BPSK Telemetry” But, this is a VHF downlink. Is that OK for you to start with?
Good luck!
//Lars SM0TGU
Ok, thanks! I had installed this on my UHF station so was wondering about UHF satellites but will install/try on my VHF station (where I have had good observations but no data frames for funcube-1)
I was just trying confirm if ‘satnogs_gr-satellites’ really extends the number of satellites that can be decoded/produce frames over the satnogs-client by itself.
Yes it does extends the number of satellites that can be decoded.
I now have this running on my Az/El Station (#232 - SatNOGS Network - Observations ). It’s working nicely!
I’ve actually become a little concerned that there’s some inconsistency in what is being uploaded, when comparing the output of the SatNOGS decoder and this add-on (look for data obs ending in _gX for the gr-satellites output). Refer the following screenshot:
In this case these appear to be CSP frames ,and it looks like gr-satellites is reversing the byte order of the CSP header when producing its output. CSP headers are 4 bytes long (refer Cubesat Space Protocol - Wikipedia ) with the last byte being a ‘flags’ byte. A value of 0x83 in that flags field doesn’t really make sense according to the protocol, while a flags byte of 0x01 does (indicating a CRC is in use).
Maybe @SA2KNG can comment? I don’t want to be uploading garbage data into the DB. I guess a way of not running gr-satellites for satellites which we know gr-satnogs can decode already would be useful. At the moment there only appears to be an option to select specific NORAD IDs.
EDIT: It looks like gr-satellites is byte-swapping the CSP header here: gr-satellites/ax100_decode_impl.cc at master · daniestevez/gr-satellites · GitHub
… and this is translating to the outputted KISS frame. I’m not entirely sure this is the correct behaviour…
After chatting with Dani about this, he’s not sure if the bytes should be swapped as they are. He’s opened an issue here: CSP header swap for AX100 transceiver · Issue #295 · daniestevez/gr-satellites · GitHub
I’d like some input from those that have actually used CSP in practice (e.g. @Kevin ) and those that have written the decoders (@DL4PD ). The main questions are:
- What byte order is the CSP header sent over-the-air on Bobcat? (It looks to be send big-endian according to this obs: SatNOGS Network - Observation 4653429 )
- What byte order do the current decoders (satnogs-decoders) of CSP frames expect? How do they handle headers which are reversed (badly, I expect)
My experience with CSP has been limited to using it as an addressing system across an internal cube-sat bus. In this application (using libcsp), the header is sent big-endian, so the flags byte will be sent last.
For SatNOGS-decoders it is expected to be Big Endian. A raw data “frame” or packet (how ever you will call that) should not been parsed somehow before storing! It should just reflect what has been transmitted OTA.
I agree, but there’s a bit of subtlety there - it’s not necessarily what is transmitted over-the-air, but it is the ‘user’ data - the data the user wants to access as the output from their ground station. There may be additional framing added, FEC, scrambling, CRCs, etc used along the way, but we generally don’t want to see that in the resultant data packet that we send into satnogs-decoders.
That’s correct! This is one layer below CSP though.
The github issue seems closed. How can we best update? Did anyone try that yet and verified that it is OK now?
You should just be able to update and reinstall gr-satellites.
I managed to update. I issued:
cd gr-satellites
git pull
cd build
cmake ..
make
sudo make install
sudo ldconfig
I looked at a few observations and did not find any swapped bytes between the satnogs decoded and the gr-satellites decoded data.
Updated gr-satellites without any problem!
I need help with this point… I have same problem and I don’t know how to solve it.
I’m editing bash.rc file but I don’t know where to put that line, and also there is no subdirectory called satellites in dist-packages…
Where is normally located the subdirectory satellites
Thanks 73
After rebooting my rpi, it’s working
Thanks 73
After looking in to this at @ea5wa station 1589, I saw that the following packages were missing: gnuradio-dev libvolk2-dev
gr-satellites compiled and ran ok after that.