pa0r

The WPX 2005 CW was a great experience this time. We made just short of 2500 qso's and a score ofalmost 4 Million points, embedded in a tlf testing orgy. Of course I used the event as a beta test for tlf... the last time we used it for the wpx was the 2004 SSB contest (version 0.9.16), and I expected version 0.9.23 to be more stable.

Some obeservations were quite interesting...

This was the first time this group of operators was confronted with tlf. Detlef, DK3QZ had experience with TRlog, the others (Marcus DL1EKC and Ralph, DL4YD) had used CT. Although nobody had had the time to look extensively at tlf before the contest, after a short run with the simulator we had no problems with operating.

The QTH

The fieldday site of DARC dept L03 is in Schermbeck on a 60 mtr high hill looking over corn fields. Antennas available ude a 3-el cubical quad for 10-15-20 and a TR33. Plus a dipole for 40-80 and a 160 wire antenna. We put up a vertical for 40 mtrs (a GFK pole with a piece of wire). With the exception of the 80 mtrs dipole all antennas worked well. The 80 mtrs dipole is too low for dx.

I envy the people who can use this qth regularly. I had NEVER, NOWHERE, heard 9+40 signals coming out of complete silence. On 160 mtrs!!!

Radio gear


This was an excellent opportunity to compare the K2 receiver to the TS 850. I always liked the 850 very much, I think it has one of the best receivers Kenwood ever produced. But in the harsh contest environment the K2 runs circles around it. Especially on 40, where you have a run frequency about every 100 Hz during the big contests. Only my ORION equals this. Next time I will bring the Timewave DSP filter.

Rig control

Hardware setup of the 2-node system was 2 old 166 MHz Dell desktops. I had put all the new software on at home and build the system up and tested it. Everything worked. I switched the 1 monitor available from 1 node to the other and everything appeared to work fine.
The plan was that one of the other crew members would provide the other monitor. When the system was built up in the contest shack I could choose between 3 monitors, all from the good old DOS days. They were not capable to run graphics. So I had to use one of the systems with a linux text console. No problem, only that somehow the text console started in some strange mode accepting only CAPITALS, and of course my root password was in non-capitals... After playing some (undocumented) tricks I got it running. Everything seemed o.k. Packet, rig control and CW output worked like a charm....

The contest

Marcus and Detlef had volunteered to take the first 6 hour shift starting at 2 o'clock in the morning local time, so we left the system running, waiting for the first qso. I went to bed, as I had the 8 AM shift.

At 01:45 somebody knocked on the door of the camper. "Houston, we have a problem...". So I dressed and went to the shack. And indeed, there was a LAN problem preventing the qso's from the run station to log on the multiplier station. I tried to fix it (ping worked) but I could not get into a root terminal. So I decided to quickly substitute my UBUNTU laptop for the faulty desktop. This took 45 minutes including configuration etc. The laptop communicated with the LAN through wifi, which was a bonus. Everything o.k., and the qso's came rolling in!!

At 02:30. "Knock knock" - "Sorry to wake you but unfortunately your laptop is switching itself off..". I decided to get out of bed and babysit the system for the rest of the shift...
Hardware error again. The laptop had overheated and switched itself off. I provided a small fan and made sure the machine could get enough air.... Mind you, the stuff going in was 35 degrees C, and the machine is missing 2 of its small feet.

Happiness prevails

The rest is history. Happiness 'till the break of dawn... Almost 2500 qso's and 3.880.000 points.
And when we looked at the condx values this morning it turned out the K value had risen to 6 during the last hours of the contest....

The lesson learned is that I have to provide a TEST PLAN for the next occasion. We took too much for granted. And start tlf in VERBOSE mode the first time. The debug messages were quite explicit in this case...

Other minor things I noticed:
- the 'needed' display is quite useless for the wpx, needs some work
- I had forgotten to set the SERIAL_EXCHANGE variable to lock the qso number (corrected during the contest)
- Tlf needs a better "this is a mult you should/can work" indication

A plea to the CQ Contest Comittee:
CAN WE PLEASE SHIFT THE STARTING TIME OF THE CONTESTS TO 8:00 UTC !!!
I think this would be fair after all these years...

We had hell of a time... Thank you L03 - We will be back!!

P.S.: On another foot: I wonder if there is a linux driver to send console data to BRAILLE output devices? Marvin, DL2VD, the 'white sticker' chairman of L03, uses TRlog with a BRAILLE device, and cannot use any non-DOS program. I am not aware of anything similar for LINUX. Any ideas?

We are preparing for the WPX contest next weekend. The contest location is the fieldday ground of the DARC L03 club, near Duisburg (see location on the APRS map). Crew are DL4YR,DL1EKC and DK3QZ. The latter two were ops of CT9L in 2002 and 2004 resp.

Equipment will be 2 Elecraft K2's, 2 linears, a cubical quad, a 3-band TH33 and some dipoles.
We are going to use TLF of course, and this morning I prepared the computers for the wpx.
They had not been updated since last year's wpx so it needed the latest versions of Ncurses (5.4), cwdaemon (0.9), hamlib (1.2.3) and tlf (0.9.23).

If you do the upgrade in this sequence you will be o.k. (don't forget ldconfig after installing the libraries, and make clean before making tlf!!). Under Morphix cwdaemon is copied to /usr/local/bin, which is not in the PATH. We will have a network (Wifi compatible) with 4 nodes, with cluster data, rig control for the K2's and cw via the cwdaemon.

The photo shows how you can use a pool table for contest preparation (notice how the K2 is dwarfed by the computers... is this radio?)

The weather forecast is fantastic, the CONDX forecast is MISERABLE!! So we will have plenty of time for the social aspects of this event....

A communications program works when it can send itself somewhere. Today I sent the source of arq.pm (30k) from the client to the server. To prove it works. This resulted in 2 more bugs found. I am now in the situation where I have to torture the system for at least an hour before it will fault. Not good enough for releasing it yet. I guess it needs at least 1 more week of on-air testing to make sure there are no more surprises.

On the other hand it gives me a lot of data regarding on-air behaviour. I have settled for a default block size of 8 x 32 characters. When conditions are marginal I switch back tp 8 x 16 characters, when conditions are good I can make 8 x 64 characters. The influence of overhead (8 bytes extra per block) is negligible at 8 x 64... Most important for maximum throughput is to minimize repeats. Also the fact that 1 repeat at 64 block size means repeating 72 bytes....

All in all, first measurements show a throughput at 8 x 32 and 8 x 64 of 4.7 cps, equalling about 60 Baud... error free.
The throuput/bandwidth rate is definitely good enough to continue the project.

As far as I am concerned the ham camping long weekend we attended was a success. It is held at a large camp site in the North of Holland (camping 't Vlintenholt in Odoorn), and there are some 400 hams with their families every year. From the Eindhoven region there were 5 caravans, 2 campers (including ours) and 12 tents, and there were a lot of people I know very well, so we had a lot of talking to do. The weather was nice enough to spend most of the day outside.

I had the time to read "Programming Python". After this I was not convinced why I should need it, maybe except to change scripts on UBUNTU (UBUNTU uses python all over the place). Sometimes you read the book on a programming language and you are hooked... I had that when I read "Programming Perl" and, come to think of it, when I read the book on Forth somewhere around 1967. Love at first sight... Python somehow fails to turn me on... And the name "Programming Python" is misleading. The back cover tells you that this is the most important reference for the language. Inside you are told that you first have to read "Learning Python". I will stick to Perl.

I did not make a lot of qso's, only some on 30 metres. But we had a lot of fun to build up and try out antennas. Most people don't appreciate how simple it is to put up a fishing rod with a piece of wire.

The camping has no facility for mobile homes to dump waste water. But there was fresh bread every day and a simple restaurant. We will be back...

Still debugging.The arq engine still refuses to transfer more than 62 blocks :(. This bug is not easy to kill, as it takes a full "mouthful" of quick brown foxes before the error occurs... So I have to teach it to wrap around the 64 blocks border. For the rest it is nice to observe the protocol doing the dirty work. During daytime, the signal from the server is S7, and there are few repeats of one or two blocks, only when qrm or qrn occurs. Sometimes the link is dead for 5 minutes because somebody is putting a carrier on frequency, but it picks up again after the qrm'er disappears. During night time the PSk63 link is hardly existant (skip problem on 30 meters). Interestingly, when I switch to PSK31 I have a 100% link again. Looks like information theory is working as advertized...
Of course this is a very slow link, but it works. And it does its job within a bandwitdth of 50 Hz!!
After 1 week of testing and debugging it becomes clear that the system needs to react on changing conditions by enlarging/decreasing the block length. The number of repeats per 64 block frame is a good measure for this.
Most of the tests were done using a data block length of 8 characters with marginal signals, and 64 characters with S7 signals. Compared to a hf packet link this really soars.... and within a 100 Hz bandwidth!!
The protocol as proposed by K9PS does not cover this, so I will have to do some thinking.

I am going to take a break from the software over the coming long weekend... but I can hardly wait to put this baby to bed!

The arq prototype is on air for pre-alpha debugging. This afternoon I have uploaded a test version of the server to the system at the TU Eindhoven. The program consists of a common function library module (arq.pm) and small programs for the server and for the client. I have made already one addition to Paul K9PS's specification: I added an abort block. When this is received the system closes the connection immediately without finishing the queues.

Testing is simplified by running the server under VNC (a remote desktop). I have started gmfsk under the VNC desktop, and I can connect to the server from home.

I did have to drive 20 km (one way) to the TU because somebody disconnected the 40/80 meter dipole from the system - and it does not work just with the coax cable connected ;)

I can now try the arq logic and look at the timing parameters... fortunately the forecast is rain/cold for the next days....