Dominic Smith ⇓

Browsing / Searching my logs

How to browse my logs or search for QSOs by simply constructing a simple HTTP address.

You can browse results for a complex log-search (such as 'stations with the prefix F, contacted in February of any year by M0BLF') by constructing a simple page address on my site. You can try this below. Notice how '*' is added as a wildcard if needed, and that '/' in a callsign is converted to '-'. The order of the parts which make up the address is important but only my callsign is mandatory (leaving everything else blank will show you my full log).

http://www.domsmith.co.uk
 /amateur-radio/qsos
/
(required)
/

/

/

/

/


or
PFX-
or No filter

Retrieve QSO Information by QSO ID

At the heart of the service is a unique, permanent, ID given to each QSO. This ID is case-sensitive. If you know a QSO ID, you can retrieve my log entry for that QSO:

http://www.domsmith.co.uk
 /amateur-radio/qsos
/
(required)

About /qsos

The primary aim of this service is to put my log at the centre of my website by ensuring that every QSO that I make has its own permanent, linkable, page automatically generated from my log. The main features include:

  • Forms the basis of both general log-search and contest/dxpedition-specific log-searches on my site.
  • Browseable Contest Logs aid transparency.
  • Produces the DXCC and IOTA tables on this site.
  • Generates end-of-year reports of QSO activity.
  • Runs the back-end of Live-Log, a continuously-updating module that I can place on DXpedition and contest pages to show my log while I make QSOs.
  • Embeddable log-search as an Open Social widget.
  • I can log from anywhere via mobile internet.
  • Can display contacts as they are made during DXpeditions and contests, helping to reduce dupes.
  • Allows you to request a bureau QSL card for any QSO when viewing the QSO information.
  • If you blog about our QSO, you can link to the QSO record, thereby aiding in the development of the semantic web.
  • Information can be returned in XDIF with appropriate HTTP status, both aiding AJAX searches and allowing you to write scripts to search the log and extract data. (More technical information)
  • Potential for automatic logging when using digital modes.
  • Many other possibilities for the future, including adding QR-codes pointing to the QSO URL on QSL Cards (see example below), thereby aiding QSL Card validation.
Example of a QR-Code for a QSO URL

FAQs

  1. Where did you get the idea for this?
    The inspiration for this service comes from bbc.co.uk/programmes.
  2. When did you develop it?
    Development started in May 2008, and is ongoing.
  3. Where can I get the source code?
    I do not release it. I regard this service very much as a proof-of-concept, rather than an anything which others could use. It has been developed for my circumstances and the technology in use on this server. Since I cannot guarantee that it will work elsewhere, I would be unable to support the software if I did release the code. If you are a developer, feel free to email me to ask me questions, though!.
  4. Isn't releasing logs a bad idea?
    The ARRL have acknowledged that they cannot prevent logs from being made available on the internet and so the DXCC rule about this has been lifted. I believe that publishing logs aids transparency in awards and contests and that there are great possibilities if eveyone shared their logs in a standard format. That said, the code does automatically withhold frequencies of QSOs made in the last 30 minutes (to prevent 'self-spotting') and I can also choose to withhold callsigns in DXpedition logs to prevent 'trawling' for QSOs. I also use this for contest logs where the deadline for receiving logs has not yet been reached.

Technical Information

New features in v 3.0 (12-Feb-2011)

  • By default, HTML pages are returned. You can add .xml to the end of a URL to return details in xDIF
  • QTHs have their own pages and are linked from QSO information
  • Code substantially refactored using the linked data model.
  • Initial support for QSOs with multiple paths
    Why is it that we still consider a QSO to have one frequency and mode? How does that work if a QSO is made between two internet-linked repeaters on different bands? My answer is that a QSO consists of a path having one or more legs, each of which have a medium (RF, internet etc.) and which may have a frequency and/or mode. This version of the code adds initial support for such QSOs, although the underlying database does not yet provide this support.

Page requests

  • By default, HTML pages are returned. You can add .xml to the end of a URL to return details in xDIF (see below). Support for other formats (specifically RSS) is under development.
  • Appropriate HTTP status headers are returned (ie. 404 if the QSO is Not in the Log; 400 for a malformatted request, 300 if there are multiple results; 200 if one and only one QSO is found).
  • The xDIF returned is also used for the AJAX-based lookups on some DXpedition and contest pages on this site, for example IARU 2008 Log-Search.
  • If you are interested, you can view the XSLT pages applied to multiple QSOs (HTTP Status 300) and to individual QSOs (HTTP Status 200). Since February 2011, client-side XSL is no longer used, because results can be requested in HTML or XML formats
  • Where multiple QSOs are returned, the page contains a maximum of 50 QSOs. If there are more, you can add a GET request variable to the URL to display a specific page of results. eg. ?page=3 for QSOs 101-150. On pages with multiple QSOs, a <pageInfo> element is added, which contains the current page number <pageNum>, the total number of pages for the query <maxPages> and the total number of QSOs <totalQsos>.

QSO data

  • In the case of DXpedition logs and contest logs for which the deadline has not yet passed, callsigns and exchanges will not be displayed (unless, in the case of callsigns, you have searched on that callsign).
  • To avoid self-spotting, frequencies are withheld if the QSO has been made within the last thirty minutes.
  • On pages with multiple QSOs, results are returned in date ascending order, except when browsing a whole log for one of my callsigns, in which case date descending order is used. This behaviour can be overridden by supplying ?sort=ASC or ?sort=DESC (for ascending and descending respectively) as a GET request. The value of the <order> element (within <pageInfo>) is either ASC or DESC, confirming the sort direction applied.

XML format

If you append .xml to an address, this service returns data in XML. The particular variety of XML used is based on the 2006 draft specification of xDIF (XML Data Interchange Format, an implementation of ADIF in XML). Since then, initial work has started on ADIX. Once ADIX is better specified and in more common use, I will probably upgrade this service to return ADIX for XML requests instead.

The following are the main deviations from xDIF:

  • time is never returned
  • if multiple QSOs are found, my equipment and location are not returned
  • the <request_url> element element is used within the <confirm> element
    (This contains a URL at which a request for a QSL card can be made.)
  • The <events> element, containing one or more <event> elements may be used
    (This provides the name and URL of a contest or DXpedition during which the QSO was made.)

All of /qsos/ is blocked in robots.txt to prevent crawling.

[x] Me

I am Dominic Smith and this is my personal website.
I am a radio amateur, Agile project manager and website developer living in Cambridge.   More about me »