Akademisk Radioklubb


Month: November 2017

Soldering course

From time to time we hold internal courses on technical topics in order to increase the general knowledge of our members. Recently,  Henrik – LB5DH, took great initiative in organizing an introductory course in soldering for our members. Soldering is an activity that we do a lot of in ARK, for example when building beacons, antennas or doing general maintenance. It is a very useful skill to have when doing work on projects for the club.

Henrik got in touch with experienced solderers Øystein – LB7IG and Snorre – LA8ITA, who were willing take responsibility for the academic content of the course.  The theory portion consisted of topics such as:

  • Getting optimal heat transfer between soldering iron and PCB/components.
  • How to solder components.
  • What does a good solder-joint look like.
  • Flux – what is it and why do you need it.
  • Solder alloys and their effect on performance and usability.
  • Care and maintenance of a soldering iron.
  • Health and safety hazards and procedures to avoid them.

Øystein – LB7IG demonstrates how to apply solder to a through-hole component.

For the practical portion of the course, the attendees each got a Pixie CW 40 m transceiver kit. The Pixie is a very simple fixed frequency CW radio that will output around 1 watt at 7.023 MHz. As an introduction to soldering for an amateur radio club, we could not have asked for a better kit!

Partially assembled Pixie kit.

Originally, the plan was to solder a through-hole component kit (the Pixie) first, and then move on to surface mounted device (SMD) kit afterwards. This part of the course was postponed due to delivery problems with the SMD-kit.

We are very grateful for being able to loan soldering equipment and a place to use it from Omega Verksted. This came in handy, as fitting all eight attendees into our workshop at the same time would have been very crowded. In addition, we got to loan portable fume extractors from the Elprolab at NTNU through Ingulf, LB1VF. They were indispensable for the continued health of the participants. Thanks to Omega Verksted and LB1VF at the Elprolab for making the course possible!

LA6XTA removing some excess solder.

LB5QG showing off a custom case he made for the Pixie transciever.

LA2QUA brought a display and microscope unit.

Jens – LB6RH placing a throughhole component on his Pixie.

LB6RH doing a test-powerup.

Back to consulting the schematic after the test-powerup failed.

Einar – LB7JH checking out the bill of materials and placement instructions.

Testing the Pixie on a spectrum analyzer.

Local oscillator leakage is quite bad!

TX mode gives approximately 24 dBm out, note that the carrier is a little offset from the receive leakage to produce a 600-800 Hz tone. It also turns out that the output power is roughly 0.25 W (24 dBm) for this specific Pixie (-6 dBm measured on the spectrum after a 30 dB attenuator).

LB6RH and LA6XTA tuning the Pixie to see if they are able to receive each other.

LB7JH inspecting his solder joints.


Overall, the course was a great success, and got a lot of ARKs members more interested in soldering. A big thanks to LB5DH for organizing the course, LB7IG and LA8ITA for sharing what they know, and LB1SH, LA3WUA, LB1MH and LB7RG for acting as teaching assistants during the practical portion. Hopefully, we will repeat this course several times during the upcoming semesters.

Telefonitest 2017 QTH NUTS

Telefonitesten (Norwegian: the Telephony Test) is a Norwegian-only Ham Radio competition occurring every fall. ARK has a tradition of participating in this event, and we find it to be a very good introduction to contesting for new hams.

This year, we decided to try to participate in the contest at a different location than Samfundet in order to avoid being hindered by e.g. sound checks. Thanks to intense lobbying from LA3WUA, we were able to borrow the venues belonging to the local student satellite group, NUTS (NTNU Test Satellite) , at the NTNU campus at Gløshaugen.

NUTS seen from the outside.

NUTS has convenient direct access to the roof of the Department of Electronic Systems at NTNU, including a lift from the ground floor and straight into their venues on the fifth floor. We got the go-ahead after lunch on Friday, started packing at 17.30 NT and had our dipoles and rigs (including a rig and PA borrowed from LA1BFA) ready on the roof by 22:30 NT. Since it gets dark around 16.00 in the afternoon at this time of the year, we could not get any good pictures of the assembly and teardown.

Spiderbeam 15 m aluminium mast used as anchor point for 40 m and 80 m dipoles.

LB5DH, LB6RH and LA6XTA replacing a broken balun at the 40 m dipole.

NUTS 2 m / 70 cm ground station.

Low hanging 80 m dipole for Near Vertical Incidence Skywave (NVIS).

In addition to running the contest at a different location, we had a couple of operators down at Samfundet listening to the 40m and 80m bands using our IC-9100 rig and the Flex 6500 rig, and reporting new calls to the main operators at Gløshaugen. The Samfundet shack and the NUTS shack are fortunately less than 500 m apart (CQ WW rules).

LB5QG and LA6XTA working the receive stations during the third period.

LB5DH and LB5QG listening to QST-LA in the break between the second and third periods.

The operators at Gløshaugen could then focus on calling CQ, and conveniently pounce calls on the other bands that were searched for and spotted by the operators down at the listening stations. This was achieved by creating a privately hosted DX cluster.  ARK’s IRC channel was also diligently used in the coordination effort.

LA1BFA working 80 m in the first period.

LB6RH working 40 m in the first period.

LB5DH working 80 m in period three.

In the end, we got a total of 132 QSOs. While this might not seem like such a high number, the number of participants in this contest is limited (45 unique calls in our log). Success in the contest depends on whether all the participants of the contest can be run at all periods, and on all bands, or whether we are limited by the propagation conditions. Being able to get that single contact becomes important, as the margins are very small. It is imperative to both call CQ and search and pounce at the same time. Being unable to run the last period on Saturday due to sound checks at Samfundet has, for example, normally led us to hit the bottom charts of this contest.

Distribution of QSOs in the two bands run in this contest. The 40m conditions were rather low during the first two periods. Period 1 was on Saturday 13.00-15.00 UTC, while period 2 and 3 were on Sunday 07.00-09.00 UTC and 13.00-15.00 UTC, respectively.

Typically, single operators will switch between the 40m and 80m band after the first hour of the period. We never remember the order of the two. After looking at the plots above, we still don’t know the order of the two :-).

These plots also reveal some interesting facts about the propagation conditions during the contest. The main mode of propagation for 40m and 80m in Norway is NVIS (Near vertical incidence skywave). We chose to employ low-hanging dipoles at the NUTS site to get a high take-off angle. To reach the northern-most parts of Norway, F-layer propagation with lower take-off angle would be desirable, but since the population density is much higher in southern Norway, this was not our main focus.

NVIS propagation is highly impacted by the latitude and the number of sunspots. Since our latitude is high, and the number of sunspots currently is low, the maximum NVIS frequency is likely below 7 MHz during the most of the day. Luckily, as seen in the plots above, we got a small opening at the end of period two that lasted to about the middle of period three.

Beyond this, our theory is that the maximum usable frequency was too low for good 40 m conditions during the main bulk of the contest. From a operator’s perspective, the 40 m conditions during period three were quite interesting. The period started with great conditions on 40 m and lots of contacts. After an hour, the Norwegian calls became faint as the noise floor increased, and by the end of the period, we were suddenly able to hear only European stations. The increase in noise floor and European stations indicate that the D-layer started disappearing, and longer propagation paths via the F-layer started to become possible.

In addition to the plots above, we also looked up address information of the contacts from the Norwegian ham database, found the corresponding coordinates using geopy and plotted these on maps using cartopy. Maps for each period are shown below.

Thanks a lot to NUTS for loaning us their QTH! It was a pure pleasure being able to avoid the interference problems at Samfundet, and enjoy the view and atmosphere of their convenient and airy rooms from the top of Gløshaugen. Thanks to all the operators, thanks to LA1BFA for lending us his PA, rig and hours of his time both during rigging and running the contest, and thanks to the other participants of the contest. We are looking forward to the results.

More photos can be viewed at bilder.la1k.no/telefonitest2017/. This also includes some photos from the initial phase of an attempt at overhauling our 160m dipole, and the photographer going wild with the nice autumn weather.

Quick analysis of the LM100UKA logs using Python and Pandas

UKA-17 is over, and LM100UKA is no more. As a part of the series, “LA3WUA and LA9SSA discover that Python is actually quite nice” ([1], [2]),  we used this opportunity to experiment with some plotting of the contacts from the logs generated by our logging program, N1MM, using Python, Pandas and pyplot.

Pandas is a data analysis library which can make it more convenient to do data wrangling in Python. It is built on top of numpy, with all the efficiency and ease of manipulation which that entails. In addition, it has convenient data structures, capabilities for metadata, easy slicing, merging and grouping, and a whole clusterfuck of various operations that can be applied efficiently to rows or columns.

N1MM saves its logs as sqlite files by default, which constitute complete, file-based SQL databases. Pandas has convenient facilities for reading various input data, including SQL queries, and we’ll start from there.

Given an N1MM log file, e.g. qsos.s3db, an SQL connection can be established to this file using

import sqlite3

sql_connection = sqlite3.connect('qsos.s3db')

If this SQLite file contains ham radio logs generated by N1MM, it will contain a table called DXLOG. All of its information can then be read into a Pandas dataframe using

import pandas as pd

qso_data = pd.read_sql_query("SELECT * FROM DXLOG", sql_connection)

qso_data will now contain all the QSO information in a large data matrix, with each row containing a contact, and each column corresponding to a field in the SQL database table. We can, for example, extract all unique operators in the log using qso_data["Operator"].unique(), or qso_data.operator.unique(), or even numpy.unique(qso_data["Operator"]). We could extract all calls and timestamps run by LA1BFA using qso_data[qso_data.Operator == "LA1BFA"].[['Call',
, or all contacts run against LA-callsigns using qso_data[qso_data.CountryPrefix == 'LA'].

Using basic functionality, we were able to generate a few plots from this data.

The number of QSOs distributed across the days since we started using the callsign. The general level of activity is more or less equal before and after the start of UKA, with the most activity occurring during CQWWRTTY and a burst of activity at the very beginning.

The number of QSOs as a function of hour during the day (UTC). This distribution follows more or less what is expected from the distribution of people at ARK, with a post-work/post-study day frenzy at around 16.00 NT and after 18.00 NT (UTC time had an offset of -2 hours from Norwegian time during UKA).

The same plot as above, but split on the used band. “Day” and “night” bands (14.0 MHz and 7.0 MHz, respectively) can clearly be seen, along with spurious use of e.g. 10.0 MHz during the afternoon.

The distribution of QSOs among the various operators.

The distribution of operators during the building period and UKA itself. A variety of operators participated during the building period, while the start of UKA itself posed some difficulties in both avoiding  interference and being able to get into Samfundet due to stricter access regimes. Mainly LB5QG and  LB1HH kept going during this last phase.

The distribution of operators during the hours of the day. LB5QG has done a considerable effort in producing QSOs at all hours of the day.

World map with filled countries corresponding to the countries we have run. This also involved reading of a HTML table from the ITU website into a Pandas dataframe in order to convert from callsign prefix to country, made easy by pandas.read_html(..) :-). Here, we could also technically have used the ClubLog API to look up country information from the callsigns, but would probably put a bit of a strain on the servers if we were to do that for all calls in the log. Instead, we hacked together a solution using the official ITU allocation tables.

The script used in generating the above plots can be found at github. This is made to analyze all .s3db-files in a folder, and differs a bit from the code snipped shown in the beginning of this post.

Only our most recent, still-in-use logs are in .s3db-format, however, as we strive to convert to ADIF format or similar during the archival process. We’ll also look into what we can extract from the larger bulk of older logs.

LM100UKA is over

The UKA festival is finally over, and we are back to normal here at the club. It has been a great time running LM100UKA for the 100 year anniversary, and in the two last months we have run a total of 1602 contacts! These are mostly on 20M and 40M. This includes the CQWW RTTY competition, but most contacts are otherwise regular QSOs.

This has been some wild weeks! The festival happens every two years, and it first involves the restoration and refurbishment of one of the locales at the Student Society, as well as building of all the necessary props. The theater group prepares the revue and some small plays, while other groups plan out big events and concerts. The chefs at the restaurant in the Student Society even prepare a specialized menu. We have mostly been able to run radio during local daytime since the Student Society usually has been closed off for us in the evening.

Once the festival starts, everything happens. There are shows, concerts, events, and parties running for 3 weeks straight, not to forget one of the most important parts of the festival: The student revue! Of course, this did not stop us from using the radio every now and then. We did however need to limit our output power when things were going on in other parts of the house.

We will be sending out QSL cards to everyone in about a month’s time. Logbook of the World upload is pending activation of the callsign, we will update this blogpost once the logs have been uploaded.

Parsing a DX-Cluster using python and Club Log

LA1K is always interested in working new DXCCs. To assist with this we wanted to see if we could make a piece of software that could alert us when these opportunities occur.

A DX-cluster is a telnet server where clients can report different callsigns that they have heard or worked. To listen to the DX-cluster we will use Python’s telnetlib library. We parse the cluster output with regular expressions using Python’s re library.

Sample output from DX-cluster at LA3WAA.DDNS.NET:8000

The code snippet below opens a connection to the DX-cluster running on LA3WAA.ddns.net, using telnetlib in Python.

import telnetlib
import re

# Open connection to telnet
tn = telnetlib.Telnet("la3waa.ddns.net",8000)
tn.read_until("login: ")

Once the telnet server replies with login:, a callsign can be sent as a reply:

tn.write("LA1K \n")

The output from the telnet server follows a regular structure, as seen in the image at the start of the post. For our DX-cluster, the structure is “DX de [CALLSIGN]:   [Frequency]  [SPOTTING_CALLSIGN]  [Comment] [Time]”. To parse this, we use some straightforward regular expressions. First is the callsign, which is simplified to any combination of the letters A-Z, numbers 0-9 and the “/ ” operator.  Similarly the frequency contains the numbers 0-9 and the “.” operator:

# Define regular expressions
callsign_pattern = "([a-z|0-9|/]+)"
frequency_pattern = "([0-9|.]+)"
pattern = re.compile("^DX de "+callsign_pattern+":\s+"+frequency_pattern+"\s+"+callsign_pattern+"\s+(.*)\s+(\d{4}Z)", re.IGNORECASE)

Once a new line is found in the DX cluster output, it is checked against the previously compiled pattern. Matches are grouped so that the 0th match contains the whole string, the 1st match contains the first regular expression match (if it exists), 2nd match contains the second regular expression match and so on. We sort these into named variables.

# Parse telnet
while (1):
    # Check new telnet info against regular expression
    telnet_output = tn.read_until("\n")
    match = pattern.match(telnet_output)

    # If there is a match, sort matches into variables
    if match:
        spotter = match.group(1)
        frequency = float(match.group(2))
        spotted = match.group(3)
        comment = match.group(4).strip()
        spot_time = match.group(5)
        band = frequency_to_band(frequency)

Processing DX-cluster information

We are going to further process this information using some features from ClubLog’s Application Programming Interface (API). ClubLog is an online tool to manage your amateur radio logs. To access this API, you need a couple of things:

After you have uploaded your logs, ClubLog provides a very neat DXCC-matrix that shows which entities you have worked across the various bands. By comparing the infomation from a DX-cluster with this matrix, we are able to alert the user of potential DXCC opportunities.

We start by retrieving the DXCC matrix from Clublog’s API. The DXCC matrix is fetched from a URL as a JSON structure. Our solution is to use a cron-job that fetches the JSON file at regular intervals, as the matrix might be updated once we upload more logs.


curl -s "https://secure.clublog.org/json_dxccchart.php?call=$callsign&api=$API_key&email=$email&password=$password&mode=0" > ./dxcc_matrix.json

Save the file and make it executable using

chmod +x

Finally register the file with cron by typing

crontab -e

This will open the crontab file in your favorite text editor. Next we will add a line that runs the script once every hour:

0 * * * * [YOUR_PATH]/get_clublog_dxcc_matrix.sh

Save the file and run the script once manually so that you have some data to work with for the next step.

The DXCC matrix sorts countries by DXCC number.   As an example, the entry for DXCC number 1 (Canada) may contain


This means that you have worked Canada on 10 m, 12 m, 15 m, 20 m, 40 m, 60 m and 80 m. The missing bands are 6 m, 17 m, 30 m and 160 m.  Conveniently, ClubLog also provides an API to get DXCC info for a given call. We retrieve this data for spotted callsigns and check it against the matrix. First we define functions to query a callsign for DXCC info, and to check whether the DXCC is contained in the logs for the specific frequency band.

def query_dxcc_info(callsign, api_key):
    return json.load(urllib2.urlopen("https://secure.clublog.org/dxcc?call=%s&api=%s&full=1" % (callsign,api_key)))

def dxcc_in_matrix(dxcc, band, matrix_filename):
        with open(matrix_filename) as dxcc_json_data:
            dxcc_data = json.load(dxcc_json_data)
            return True
    except KeyError:
        return False

We can check whether the spot is a new DXCC and print relevant information to the terminal using the following snippet:

# Get DXCC information from clublog API
spotter_data = query_dxcc_info(spotter, api_key)
spotted_data = query_dxcc_info(spotted, api_key)
spotted_dxcc_route = str(spotted_data["DXCC"])

# Compare DXCC number to DXCC matrix, if there is an error the band has not been worked before
if band and spotted_dxcc_route and not dxcc_in_matrix(spotted_dxcc_route, band, dxcc_matrix_filename):
        print "New DXCC! %s (%s, %s) at %s by %s (%s, %s) %s" % (spotted,spotted_dxcc_route,spotted_data["Name"],frequency,spotter,spotter_data["Name"], comment, spot_time)

The DXCC is new if there’s no data for the given band. Maybe you can work it!

After running the script for some time, we noticed that it would give a lot of unnecessary data. An example is Asian calls spotting other Asian calls, which is useless in Norway, as it is unlikely that we would be able to hear them. To make the software more functional, some filtering with respect to distances and locations should be employed. This is possible using information obtainable from the ClubLog API. We will come back to this in a later post.

The script currently prints all information to the command line. The information can be pushed further to notify remote users in real-time through e.g. IRC or email, and can serve as a building block for several nice applications.

For now you may find the code and usage instructions available on github.