Building xephem on Ubuntu from trunk (04/2015)

 

 

Xephem is a very nice and elaborate tool which has many different features such as complex orbital position determination of celestial bodies, tracking of satellites, but also many other features such as images from celestial bodies and Earth phase.

For building it however requires many libraries which are not installed by default. The attached commands should install the basic libraries you need to get started.

 

Xephem Screenshot from 2015-04-07 11_01_57

Xephem Screenshot from 2015-04-07 11_02_49

 

sudo apt-get install lesstif2-dev
sudo apt-get install libc6-dev
sudo apt-get install libxmu-dev
sudo apt-get install libmotif3 libmotif-dev
sudo apt-get install make
sudo apt-get install libx11-dev libxmu-dev libxp-dev libxt-dev x11proto-print-dev
cd xephem-3.7.2/GUI/xephem
make MOTIF=/usr/lib

[1] http://ubuntuforums.org/archive/index.php/t-329396.html
[2] http://forum.ubuntuusers.de/topic/so-gehts-bei-mir%3A-astronomie-programm-xephem-/

Building Gpredict on Ubuntu from trunk (04/2015)

This instruction is written on Ubuntu 14.10 x86_64.

Get the required tools for building:

sudo apt-get install automake build-essential make

sudo apt-get install intltool libgoocanvas-dev
sudo apt-get install libgtk2.0-dev libcurl4-openssl-dev
sudo apt-get install intltool libgoocanvas-dev
sudo apt-get install libgtk2.0-dev libcurl4-openssl-dev

Get files from git and build:

git clone https://github.com/csete/gpredict.git
cd gpredict
./autogen.sh
make
sudo make install

[1] Gpredict Source

Cool projects: Satellite tracking/scanner from hacked maritime mobile earth station for Ku/L band

Travis has written on his blog how he repurposed an satellite dish from a naval vessel and his progress to track all kinds of satellites, including LEO, in the Ku/L band around 1.5 GHz ever since.

He uses an impressive setup between Beaglebone Black and fully automated tracking of known and scanning of unknown projects.

The SASA satellite dish setup

Video of a computer chaos congress in 2013:  Hillbilly Tracking of Low Earth Orbit: Repurposing an Inmarsat Dish (45 min).

 

Bugs when using rtl_tcp / Memory usage of rtl_tcp

Memory usage and buffers of rtl_tcp

The way rtl_tcp acquires memory and and how much memory it needs, depending on the parameters is very cryptic.

According to the man page the options are:

-b number of buffers (default: 15, set by library)
-n max number of linked list buffers to keep (default: 500)

This leaves the questions: how big is a buffer and linked list buffer? In short:

The linked list buffer will overflow only if tcp transport is not fast enough.

The buffers will overflow when you receive usb data faster than you can process it.

A linked list is a special kind of buffer which is very efficient for hunks of data of different size. It contains information of the next element and is allocated when needed.

Linked List

The buffers have a statically allocated size of 32kByte when called from rtl_tcp. Therefore initially there will be b x 32kBytes of memory reserved for asynchronous callback from the USB port. When these data return, they are copied in a linked list buffer. The linked list buffer is dynamically allocated, based on the actual size of the received data (which can be smaller than one buffer size). The maximum size of one linked list buffer is therefore about the size of one buffer. The total memory usage can therefore be estimated by:

static: 32kB * ( b )
dynamic: 32kB * (n )

As you can see it is totally of none importance if these numbers are even or odd. With the default settings, the theoretical maximum memory usage should be:

32kB(15+500) = 16’480 kByte.

If there are problems with your linked list buffer, e.g. the linked list adds or removes elements (because the data is not transferred in time) you will get such  messages when running rtl_tcp in command line:

ll+, now 1
ll+, now 2
ll+, now 3
ll+, now 4
ll+, now 5
ll+, now 6
ll+, now 7
ll-, now 0

Which basically just show you that you could not handle to send out the tcp packages fast enough, but instead had to create a new linked list buffer. ll+ means a new element is added, ll- an element is removed from the buffered list. Ideally for “live” streaming you dont want such messages at all. However, as long as you dont hit your max number of linked list buffer (-n) you will not lose packages.

However the practical memory usage is way higher, because of the underlying libusb transport layer that also allocates memory. The minimum memory usage on MIPS32 (WR703N with OpenWRT) with -b 1 and -n 0 is around 5700 kBytes with one client

Further I have observed that on MIPS32 the asynchronous transport only used one of the offered buffers in rtl_tcp, possibly because the only operation after a callback is to copy the buffer into a linked list. I think therefore that it is safe to use a small number of buffers, and a number of linked-list as can be conveniently used on the given device.

Bugs using rtl_tcp with SDR#

A very nice tool for windows is SDR#, which is now developed in closed source. There is a nice article over at hamradioscience that describes how to set up rtl_tcp with SDR#.  It still is my favorite tool when using the rtl-sdr directly connected over USB. However there are many reports of problems with “ringing” and a garbage signal, which can be recognized by this characteristic signal spectrum, which is also described on reddit. I have had this problems with the latest SDR# rev. 1337 too.

SDR# failing with rtl_tcp

 

I have analyzed the packages with wireshark, transmitted test packages and taken a glance at old SDR# code. In conclusion, rtl_tcp works just fine without any package loss. SDR# is not fast enough to process the received data synchronously.

Solution? Since SDR# is closed source none yet. You can give other open-source software a try, such as  the very extensive GnuRadio.

 

Crash of rtl_tcp when disconnecting/connecting a client

This problem has been reported most significantly on Raspberry Pi. It is caused by an old version of libusb (1.0.11) shipped still with the latest Raspbian image (03/2015). The issue does not occur with a newer libusb1.0.19.

As a workaround, enable the testing sources and update the libusb1.0.0 package.

  1. Login as root Open file /etc/apt/sources.list in your favourite editor

    gedit /etc/apt/sources.list

  2. Adding the testing repo. Add the below line.

    deb http://http.us.debian.org/debian/ testing non-free contrib main

  3. sudo apt-get update
  4. sudo apt-get install libusb1.0.0

Compiling custom OpenWRT firmware / packages

OpenWRT is a nifty thing. However, if you want to test some custom or self written programs it can be tricky.

For most instances, e.g. on a Raspberry or other embedded device, you can install a compile toolchain to just configure and make your project. Due to space constraints this is often not necessary. Cross-compiling for these embedded devices (for instance WR703N is MIPS32) is quite tricky. The easiest way therefore is to use the OpenWRT build root to compile these packages (and complete OpenWrt firmares).

I will not go into detail how to get, configure and build OpenWRT, you can find detailled instructions at the OpenWRT Wiki, and in addition how you can compile only a single package.

Assuming you have configured your OpenWRT install, you can build and include custom packages by editing the corresponding Makefiles.
For instance rtl-sdr you can find in the feeds directory:
openwrt/package/feeds/packages/rtl-sdr
Or the hamlib
openwrt/package/feeds/packages/hamlib

Everytime you install and compile the package, the source files will be downloaded newly from the internet and compiled. Therefore the easiest way is to provide a repository and commit where is the newer version.

So for instance, replacing the rtl-sdr/Makefile with this content can receive my custom version of rtl-sdr.

#
# Copyright (C) 2013 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.

include $(TOPDIR)/rules.mk

PKG_NAME:=rtl-sdr
PKG_VERSION:=2014-10-21
PKG_RELEASE:=$(PKG_SOURCE_VERSION)

PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=git://github.com/satnogs/rtl-sdr.git
PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
PKG_SOURCE_VERSION:=b72ab8fc83efbc2ec112154b9d1cbe2d85b1e258
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
CMAKE_INSTALL:=1

Building hamlib on Ubuntu from trunk (04/2015)

This instruction is written on Ubuntu 14.10 x86_64.

Get the required tools for building:

sudo apt-get install automake libtool build-essential make texinfo

Get files from git

git clone https://github.com/N0NB/hamlib.git
cd hamlib
chmod +x autogen.sh
./autogen
./configure
make

This instruction is for hamlib-1.2.15.3. The readme and Install file specify to use ./configure, but in the latest official github that file is renamed to ./autogen.sh. If you instead use autogen.sh it will work just fine then.
This will take time for a cup of tea.

Then you can install (and uninstall) witht his command:

sudo make install

If you encounter this error:

libhamlib.so.2: cannot open shared object file: No such file or directory

This is what fixed it:

sudo apt-get install --reinstall libhamlib2