CMake Error at CMakeLists.txt:97 (find_package):
By not providing "FindGnuradio.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Gnuradio",
but CMake did not find one.
Could not find a package configuration file provided by "Gnuradio"
(requested version 3.8) with any of the following names:
GnuradioConfig.cmake
gnuradio-config.cmake
Add the installation prefix of "Gnuradio" to CMAKE_PREFIX_PATH or set
"Gnuradio_DIR" to a directory containing one of the above files. If
"Gnuradio" provides a separate development package or SDK, be sure it has
been installed.
-- Configuring incomplete, errors occurred!
I developed the IQ to UDP for external demodulators as a way of using other software that already exist but not necessarily in a flowgraph. The built in demods still run and there’s currently not a way of switching between internal or external. The claim is not to take over all the demodulation, rather to get the possibility of external programs to add quality or protocols etc. The BPSK is a good example which was not working in the flowgraphs, but gr-satellites had good support for it. How the future of the flowgraphs will look I don’t know, it can perhaps be split into hier blocks etc.
That line was only made as an example and not a exhaustive list of satellites that gr-satellites handles and satnogs does not. Perhaps a poor example with two of them deorbiting slightly before this sw was sritten (:
I thought of making a better list, but realized I would have to maintain that and did not want to.
If someone has a better example that is more up to date I can certainly add that.
The instructions are quite minimalistic and I make no claim they’re pedagogic nor exhaustive (:
It does not suggest to git clone anything twice, there’s gr-satellites and satnogs_gr-satellites for example.
I am all ears if you have any suggestions on the instructions.
My appologies - I did not notice that. I’ve gone back and installed satnogs_gr-satellites now, and hoping that it’s fixed the issues (my station 187 was completely broken after the install attempt - hopefully this fixes it). I don’t understand where the “makefile” tab/space changes need to be made, though…
Looks like it is working now! Question, does it upload a data file automatically for every observation, even if there are no decodes? I’ve only got one result so far, and the uploaded data is empty.
That was my mistake, somewhere in the creation of that file it got messed up, some make seems to accept this mistake and others don’t. I updated the makefile, so a git pull in the directory should fetch that.
Short answer; no. The results goes to a kiss-file that is split into satnogs json format and placed in the upload queue. If there’s no frames demodulated then nothing gets uploaded.
However, sometimes gr-satellites produces very short frames, and possibly other sporadic ‘bad’ frames.
This discussion if somewhat outside my expertise and belongs to gr-satellites, @EA4GPZ excellent work.
The 0-length could be filtered out in the kiss_satnogs.py, but it’s very hard to make more assumptions on what the shortest length should be.
Sounds a bit strange, satnogs-client is pretty resilient and always tries to push through is there’s small problems with the setup. Checking the log and seeing what is going on: journalctl -f -u satnogs-client.service -n 50
or on other systems than the official raspberry-pi client: tail -f /var/log/daemon.log -n 50
Hi, the reason for these short bad frames is that the AX.25 protocol uses only a CRC-16, which is rather short and vulnerable to false decodes. For satellites using other better protocols this doesn’t happen (or doesn’t happen so often).
I don’t know where the root cause for this is located, but the file names created when using this add on are not following the conventions! There’s sometimes a ‘_g0’ appended where an index should be!