New Ground Station problems

I’ve setup my RPi3 using Fedora 26 Server as per instuctions.
It’s not showing online, ID 119.

Screen dump:
[satnogs@satnog-vhf ~]$ source .env
[satnogs@satnog-vhf ~]$ satnogs-client
2017-07-24 12:10:48,731 - satnogsclient - INFO - Starting status listener thread…
2017-07-24 12:10:48,736 - satnogsclient - INFO - Dir /tmp/.satnogs/data/files/
2017-07-24 12:10:48,739 - satnogsclient - INFO - Check dir /tmp/.satnogs/data/files/SU_LOG
2017-07-24 12:10:48,741 - satnogsclient - INFO - Check dir /tmp/.satnogs/data/files/WOD_LOG
2017-07-24 12:10:48,742 - satnogsclient - INFO - Check dir /tmp/.satnogs/data/files/EXT_WOD_LOG
2017-07-24 12:10:48,756 - satnogsclient - INFO - Press Ctrl+C to exit SatNOGS poller
WebSocket transport not available. Install eventlet or gevent and gevent-websocket for improved performance.
2017-07-24 12:10:48,838 - apscheduler.executors.default - WARNING - Run time of job “get_jobs (trigger: interval[0:01:00], next run at: 2017-07-24 04:11:08 UTC)” was missed by 0:00:39.918006

  • Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
    2017-07-24 12:10:50,317 - apscheduler.executors.default - WARNING - Run time of job “post_data (trigger: interval[0:02:00], next run at: 2017-07-24 01:41:09 UTC)” was missed by 0:01:41.280597
    2017-07-24 12:10:50,753 - satnogsclient - INFO - [LD] Downlink thread waiting for first downlink packet
    2017-07-24 12:11:50,547 - apscheduler.executors.default - INFO - Running job “get_jobs (trigger: interval[0:01:00], next run at: 2017-07-24 04:12:50 UTC)” (scheduled at 2017-07-24 04:11:50.519433+00:00)
    2017-07-24 12:11:53,318 - satnogsclient - DEBUG - Opening TCP socket: 127.0.0.1:5011
    2017-07-24 12:11:53,320 - satnogsclient - DEBUG - Sending message: []
    2017-07-24 12:11:53,323 - apscheduler.executors.default - INFO - Job “get_jobs (trigger: interval[0:01:00], next run at: 2017-07-24 04:12:50 UTC)” executed successfully

Also, with regards to Finding PPM, I have to use dnf instead of apt-get. This fails to find and install libfftw3-dev.
I presume that is why the ./config fails on package librtlsdr not found.
How can I fix this?

Cheers,

Hey, not sure if you managed to solve the issue you had, but now it seems that your station (119) is online.

Let us know if you need any help. For more quick feedback and chat you can always join our irc channel #satnogs on freenode server. If you are not familiar with irc, you can use riot.im which offers a bridge for irc and also logs the channel message when you are offline.

EDIT:
Did you use the Odroid U3 hardware or you used the RPi3 one?

Hi Fredy,

Thanks for replying :slight_smile:

First issue was that I didn’t select the ‘operational’ tickbox in the station setup. Once I had done that the station came online which means the RPi was talking to the server. Good start :wink:

Secondly, I can not get kalibrate going due to the library issue. Probably of no use anyway as there are no GSM signals in Australia.
Just want to know that the rtlsdr dongle is working. So not sure how to test it now. Is there an easy way to check that it’s receiving etc?

I decided to go the RPi3 route. Easier and I need to buy a few more anyway :wink:

hm… you weren’t the only one that had issue with ‘operational’ tickbox… Maybe we should make it on by default…

On kalibrate, unfortunately the docs doesn’t work right now… need to be updated, it is temporarily stalled as we need to move forward with some other issues that causes crashes or malfunction. For now I guess it’s ok to go without calibrating and if it causes a serious issue then we can see what we can do.

For testing rtlsdr, first run rtl_test, this will show you if the device is visible and works fine.

For testing client with rtlsdr you can run for some seconds something similar to:

satnogs_fm_demod.py --rx-sdr-device=rtlsdr --rx-freq=444000000 --file-path=./audio-out.ogg --waterfall-file-path=./waterfall.dat

This will create on current directory an .ogg audio file and a .dat file (this the one used to draw later with gnuplot the waterfall). If these files are there and non-zero (for 1min they should be some MB) then you are ready to go and schedule your first observation in dev-network by going to your station page and schedule an upcoming pass.

1 Like

Thanks for the info.

Had the Fedora image going but the satnogs_fm_demod.py test only produced 1/2 second of usable audio then just hash, when tuned to a FM radio station. I also found the Fedora very slow.

I’m trying Raspbian Jessie uprgaded to Stretch now. Did go well until trying to load the satnogs-client. Worked once, then I rebooted as the satnogs_fm_demod.py test produced 0 length files. Now I have to go into ./local/bin and manually run ./satnogs-client, that crashes.

Traceback (most recent call last):
File “./satnogs-client”, line 11, in
load_entry_point(‘satnogsclient’, ‘console_scripts’, ‘satnogs-client’)()
File “/home/satnogs/satnogs-client/satnogsclient/init.py”, line 35, in main
raise Exception(‘SATNOGS_STATION_ID not configured.’)
Exception: SATNOGS_STATION_ID not configured.

I do manually load the .env file before starting satnogs-client. I’ll get there…


I’d like to make a sugestion. Would be nice to have a ready-to-go image available for download, for Fedora and Raspbian. Then the user can edit the .env file and be online rather quick.

Hey,

Hm… that SATNOGS_STATION_ID error is strange, especially if you source the .env file before. Just to be sure after running source .env could you run echo $SATNOGS_STATION_ID and let us know the result?

A wild guess, maybe there is a space between ‘=’ and the value in .env file and that way the variable gets nothing as value.

About Fedora, I agree it is a little bit slow, this was a quick solution that had already gnuradio version we needed so we went with this. The last days there are people trying Rasbian on RPi or other OSes on x86 platforms, so we are still experimenting and the results seems to be good.

About images, we have discussed this and it is one of the next steps we move to. Actually there was a discussion about rasbian image yesterday on irc channel. We are going to wait until the stretch version is out, which has the updated version of gnuradio. According to the last paragraph on this post will be ready over the summer.

About Fedora images… it is in my plans when I find a little more free time, unless someone else get it done. :slight_smile:

Hi fredy,

I reinstalled a Fedora 25 minimal image. This took like 7 hours to update and install the required software in step 1.7. This is why downloadable images are so much easier and far quicker :slight_smile:

Ok, got it runningish. No more errors like last message. My issue is, I’ve tried a generic dongle and a rtl-sdr v3 and both give the same result. When I run the test, setting --rx-freq=94500000, being a local FM radio station:

satnogs_fm_demod.py --rx-sdr-device=rtlsdr --rx-freq=444000000 --file-path=./audio-out.ogg --waterfall-file-path=./waterfall.dat

then listen to the resultant .ogg file, I get 1 second of discernable audio then the rest of the file is hash. Is this correct??

Ok, after more testing, yes it’s working correctly. Audio and waterfalls are being uploaded to the server and accessable :slight_smile:
Now just have to wait for the new antennas, pre-amps and rtl-sdrs to arrive. Then I can go fully online :wink:

1 Like

Just so others understand what was going on here, all the satnogs demodulation flowgraphs poll a local rigctld server for the current frequency they should be listening on. satnogs-client is responsible for pushing the current downlink frequency into rigctld during a pass.

So, if you go run a manual demod flowgraph, and satnogs-client is running, as soon as the demod polls rigctld, it will move away from the manually specified frequency!

My solution to this when testing is to shutdown satnogs-testing, then fire up netcat on the rigctld port with: nc -l 4532
That way, there’s no way the demod flowgraph will end up tuning to an unknown frequency.

2 Likes

Nice! We are looking forward for your observations!!!

About running manually demod scripts, I think that @vk5qi has explained well what happens, just to add that I suggested this just for testing reasons and to see that both files (.ogg and .dat) are generated.

We are working on this but its probably going to be a while, and will likely be an annoying shift as we move from Fedora back to Raspbian (now that stretch and jessie-backports have our required gnuradio 3.7.10)

Built a Raspbian Stretch image today.
Not enough antennas to check it properly, lol. This one is for UHF.

How did you go about it? I’m behind the curve on raspbian stretch… Just watching pi-gen to see when they support it officially.

Update Raspbian to Stretch (Thanks to viktorgino - http://headunit.viktorgino.me/RPI-INSTRUCTIONS)

Update the firmware and kernel to the ‘next’ branch:

sudo apt-get install rpi-update
sudo BRANCH=next rpi-update

To update to stretch add the following line top the /etc/apt/sources.list file:

deb Index of /raspbian stretch main contrib non-free rpi

Run the update:

sudo apt-get update && sudo apt-get -y dist-upgrade

Autoremove all the uneeded packages:

sudo apt autoremove

Get the driver for the onboard WLAN adapter from the RPi-Distro repo:
(if required)

sudo wget -P /lib/firmware/brcm/ https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/master/brcm80211/brcm/brcmfmac43430-sdio.bin
sudo wget -P /lib/firmware/brcm/ https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/master/brcm80211/brcm/brcmfmac43430-sdio.txt

Reboot RPi:

sudo reboot

SATNOGS INSTALL (Thanks to Mark - Setting up SatNOGS under Raspbian Stretch · GitHub)

Install required packages:

sudo apt-get install -y git cmake libboost-all-dev libcppunit-dev libvorbis-dev gnuradio-dev doxygen libnova-dev swig redis-server libhamlib2 gr-osmosdr gnuplot libpng-dev sudo python-pip libssl-dev libhamlib-utils vim screen libffi-dev libffi6

Grab SatNOGS Git Repos:

git clone GitHub - satnogs/gr-satnogs: SatNOGS GNU Radio Out-Of-Tree Module

Build gr-satnogs:

cd gr-satnogs
mkdir build
cd build
cmake …
make -j4
sudo make install
sudo ldconfig -v
The gr-satnogs build script puts the waterfall processing script in the wrong place (well, satnogs-client looks in the wrong place anyway). Fix this with:
sudo ln -s /usr/local/share/satnogs /usr/share/satnogs

Install satnogs-client:

cd ~/satnogs-client
sudo pip install satnogsclient==0.3

Get rtlsdr.rules from github https://github.com/osmocom/rtl-sdr:

git clone git://git.osmocom.org/rtl-sdr.git
cd rtl-sdr/
sudo cp rtl-sdr.rules /etc/udev/rules.d/10-rtl-sdr.rules
You may need to fix the rtl-sdr udev rules at this point, else you will have permissions issues.

Follow other installation procedures from here:
https://docs.satnogs.org/en/stable/satnogs-client/doc/raspi-install.html#install-satnogs-client

1 Like

gr-satnogs provides the CMAKE_INSTALL_PREFIX CMake variable to change the OS default installation path. So for example:

cmake -DCMAKE_INSTALL_PREFIX=/usr .. will fix the problem with the client searching for the script in the wrong directory.

2 Likes