Showing posts with label xlog. Show all posts

Friday, February 10, 2012

Part 5: Other Amateur Radio logging software, vkcl

This is probably a good time to have a look at some of the other Amateur Radio logging software that is around.The plan was to have made some modifications to xlog, so that it could be used the John Moyle Field Day (in 2011). Unfortunately this won't be the case, so I'll be using vkcl. This has the added advantage of getting some experience with other logging software, and seeing what features are particular useful.
vkcl is MS Windows based software and is available as a free download from the authors website. It is regularly updated with additional code as the rules for the Australian Amature Radio contests change over time. The author has also included some international contests, as he wants to use the same software with the contests that he is involved in.
One of good thing about vkcl is that the help (via Windows Help File) is complete and the software has features which make it a real pleasure to use during contests.

Friday, March 12, 2010

Part 3a: xlog - Preparing to hack, the aftermath.

The previously published parts of this series can be found here:

Some build issues...

After completing a build, it would be nice if we could return the code the state we started from. This is actually more than a 'nice to have' as it is a useful indicator of completeness. For example, if a particular compiled file isn't removed in a 'make clean', then maybe the associated source code hasn't been added to the source repository. There is not necessarily any logic in this, except that something is wrong, needs to be looked at and fixed.

I think of this as being a zero'th order test for any software that I compile from source, and git makes this issue very easy to describe and characterise.

With regards to 'xlog', after a build and a 'make clean', the 'git status' command reveils the following (where I've reformatted the output just a little.)

Changed but not updated:
  deleted:    po/xlog.pot
and
  modified:   CVS/Entries
  modified:   data/doc/CVS/Entries
  modified:   po/CVS/Entries
  modified:   src/CVS/Entries
and
Untracked files:
  AUTHORS
  CVSROOT/
  ChangeLog
  Makefile.in
  autom4te.cache/
  configure
  data/Makefile.in
  data/desktop/Makefile.in
  data/doc/Makefile.in
  data/dxcc/Makefile.in
  data/glabels/Makefile.in
  data/man/Makefile.in
  data/maps/3D2/Makefile.in
  data/maps/3Y/Makefile.in
  data/maps/E5/Makefile.in
  data/maps/FK/Makefile.in
  data/maps/FO/Makefile.in
  data/maps/FR/Makefile.in
  data/maps/HK0/Makefile.in
  data/maps/JD/Makefile.in
  data/maps/KH8/Makefile.in
  data/maps/Makefile.in
  data/maps/SV/Makefile.in
  data/maps/VP6/Makefile.in
  data/maps/VP8/Makefile.in
  data/mime/Makefile.in
  data/pixmaps/Makefile.in
  data/remote/Makefile.in
  data/utils/Makefile.in
  src/Makefile.in
  src/logfile/Makefile.in

The first issue is with po/xlog.pot, which has mysteriously disappeared. It can be restored with the following.

$ git checkout -- po/xlog.pot

I have seen glib errors when trying to run the application and haven't got to the bottom of this yet. I don't see the error occur if I make sure that the above file is present, but I haven't been able to reliably replicate to problem.

The '''CVS/Entries''' files can be committed to the git repository, but looking at the actual differences shows that this is only due to timestamp changes from upstream. It would probably be safe enough to ignore these files, and git has a file that allows these this to be set. (An exercise for the reader. Have a look at the man page for git.)

$ git diff CVS/Entries
diff --git a/CVS/Entries b/CVS/Entries
index 30be513..42e4863 100644
--- a/CVS/Entries
+++ b/CVS/Entries
@@ -36,4 +36,4 @@ D/xlog////
 /missing/1.3/Wed Jan 14 11:45:11 2009//
 /mkinstalldirs/1.3/Wed Jan 14 11:45:11 2009//
 /xlog-2.0.lsm/1.1/Tue Feb 10 09:33:11 2009//
-/aclocal.m4/1.8/Thu Mar 11 11:55:55 2010//
+/aclocal.m4/1.8/Thu Mar 11 12:54:52 2010//

Finally, other than '''AUTHORS''' and '''ChangeLog''' (which are symbolic links as specified in README.cvs) all of the other files have come into existence in the build process and should be able to be safely removed, as they didn't exist in the original source.

$ rm -rf autom4te.cache
$ rm configure
$ find . -name Makefile.in | xargs -n 1 rm

This leaves use with the following, which is where we want to be:

$ git status
# On branch master
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
# AUTHORS
# ChangeLog
nothing added to commit but untracked files present (use "git add" to track)

A git repository with the code that I will be working on in the next blog posts has been setup here: http://git.mawsonlakes.org/cgi-bin/gitweb.cgi?p=paul/xlog.

Monday, March 08, 2010

Appendix: References (links etc.) for xlog hacking.

Useful Webpages

xlog

Software Website - http://freshmeat.net/projects/xlog
CVS Download Page - http://savannah.nongnu.org/cvs/?group=xlog
Browse CVS Source- http://cvs.savannah.gnu.org/viewvc/xlog/xlog

git

git - The Fast Version Control System

Software website - http://git-scm.com
Wikipedia - http://en.wikipedia.org/wiki/Git_(software)

epkg

epkg is an encap package manager.

Software Website - http://www.encap.org/epkg

Software Repository

I'll be updating my code changes to xlog here.

Repository Browser - http://git.mawsonlakes.org/cgi-bin/gitweb.cgi?p=paul/xlog
GIT Clone URL - http://git.mawsonlakes.org/paul/xlog

Part 3: xlog - Preparing to hack

The previously published parts of this series can be found here:

So, we've downloaded the source code for xlog from the CVS repoistory:

  cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/xlog co xlog

Even before configuring, the first thing I do is put the whole thing into a Git repository. The main reason for doing this upfront is that it then becomes possible to see what files are created or altered during the software building process. When we get around to making changes we can then make use of branches and commits.

  cd xlog
  git init-db
  git add .
  git commit -m 'Initial commit'

Use 'git status' to see which files are different.

Lets now build the software, as per README.cvs.

  ln -s ...
  autoconf
  automake
  ./configure
  make
  make install

Now, 'make install' will fail unless you give yourself system (root) privileges as it will try to install the code into the system directories (eg. /usr/bin, /usr/lib etc.). For the developer, there are several methods to get around this requirement. I use a tool called 'epkg', which allows software to be installed

To update the repository from upstream:

  (commit any outstanding changes to another branch)
  git checkout master
  cvs update

These changes can then be pulled into a local working branch by using:

  git checkout (your-branch)
  git rebase master

Thursday, March 04, 2010

Part 2: Hacking on xlog

In the first part on "Hacking on xlog" I eluded to the fact that xlog was good, but that I wanted to made some changes to it. The following article discusses these changes. What changes do I want to make to xlog?

Be able to add additional rules for more contests - Currently xlog has some useful rules and checks (eg. duplicates) but they are either overly general (check for all the duplicates in a log file) or specific to a particular competition. It would be good able to support different contests rules by either an extension language or a plug-in or dynamic library architecture.
Make the User Interface (UI) layout configurable - It would be good to be able to modify the UI to suit the way that I setup and use my set radio. Gnome and Gtk+ applications can be written using libglade, where the UI is defined in an XML file along with the functions that they call. It is then possible to rearrange the interface via the XML code, without touching any of the underlying code. Currently, xlog has 'hardcoded' all of the widgets and their positions into the code of the application itself.
Add support for other forms of radio operation - Logging is necessary in on-air contests but there are other types of radio operation where a suitable logging application would also be very useful. Examples include: Running nets, Message Relaying and Emergency Operations.
Multiple Operator Support - Support for multi-user access and multiple user logs. This would be useful for multiple user stations and for collating logs for competition managers.

In order to make these changes and make any form of useful contribution, I'm going to have to download the code and spend some time poking around in it, just to understand how it works. More about this in my next post.

Tuesday, February 23, 2010

Logging Software for Amateur Radio contacts - xlog

Introduction

Something that I have recently been looking into is Amateur Radio logging software available on Linux, in particular Ubuntu and Gnome. One of the things that Ham (Amateur) Radio operators like to do is make contacts with other Hams, exchange details and sometimes, even exchange physical 'QSL Cards', which are postcards giving details of the contact made (Frequency, Equipment used etc.). In general, the more and varied these contacts are the greater the enjoyment found in the hobby. In addition to the adhoc 'CQ' contacts, there are regular contests, where operators try to make contacts in a particular period of time, on particular radio bands. Logs of the contacts make are submitted to the contest manager and points are awarded based on the contest rules. Rules include such things as a point for every contact made, multipliers for contacts made in particular bands and bonus points given for particular types of contacts. The software that I have found and I am most happy with is called 'xlog', which does most of what I want. I would like to be able to get it to do more (see below) and there are a couple of things which if they were done just a little bit differently would make if even more useful and easy to customise. The software is licensed under the GPL v2, so in the words of Jeremy Clarkson - 'How hard can it be?' The plan is to put together a series of posts about my experience with working on this software. Future posts will follow something like the following outline..

What do I want to change?
Getting the source - and using git.
Setting up the development environment - using epkg
Making changes.
Getting these changes back into xlog.

Watch this space.

MawsonLakes.Org