Thanks to W7EJ, I have been able to extend the historical database of cleaned and augmented CQ WW data back one further year, to 2007. As far as I can tell, there is no source anywhere for CQ WW logs prior to 2007.
The new cleaned data are in a single compressed (xz) file downloadable from:
https://www.copy.com/s/t%3AjLcUe4NDu7BvPcfC%3Bp%3A%252Fpublic-logs/cq-ww/cq-ww-2007--2014-clean.xz%3Boid%3A148
The MD5 checksum of this file is:
1d96c696ae20a87f4de7a66e2a523519
Similarly, the augmented data are downloadable from:
https://www.copy.com/s/t%3AjLcUe4NDu7BvPcfC%3Bp%3A%252Fpublic-logs/cq-ww/cq-ww-2007--2014-augmented.xz%3Boid%3A149
The MD5 checksum of this file is:
a7674758f3a7c2878944be9f1b6dfd81
2015-11-21
2015-09-23
Unauthorised EPUB versions of books on iTunes and B&N
I have discovered that the company that produces my hardcopy books for Engine House Books (lulu.com) has also, unbeknownst to me, been auto-converting the PDF files into EPUB and making the results available for sale on iTunes and at the Barnes and Noble NOOK store.
I never explicitly authorised them to do this, and, as far as I know, my permission was never even sought. Presumably, there's some legalese in the Lulu Terms of Service that gave them the right to perform these (what I regard as underhanded) activities without explicit consent from me.
I have now explicitly removed the EPUB files from Lulu, and will check periodically to make sure that they don't return. As best I understand it, my having removed the files from Lulu will also result in their removal from iTunes and B&N in short order.
In case you wonder why I would not want the books available, there are several issues (apart from the obvious one of their doing this without seeking explicit permission):
Category Five is the latest to be converted, and should be appearing shortly in the iTunes and B&N Nook stores.
I never explicitly authorised them to do this, and, as far as I know, my permission was never even sought. Presumably, there's some legalese in the Lulu Terms of Service that gave them the right to perform these (what I regard as underhanded) activities without explicit consent from me.
I have now explicitly removed the EPUB files from Lulu, and will check periodically to make sure that they don't return. As best I understand it, my having removed the files from Lulu will also result in their removal from iTunes and B&N in short order.
In case you wonder why I would not want the books available, there are several issues (apart from the obvious one of their doing this without seeking explicit permission):
- As the EPUB files were auto-generated, they contained no manual corrections or interventions to improve the look on a reader.
- The PDF files contain some material that either will not autoconvert sensibly to EPUB (which is really a form of HTML) or material that should not sensibly be present in an electronic version of the book.
- The fonts and general style that Lulu chose were, frankly, embarrassingly bad.
- The prices set by Lulu were considerably higher than those I normally set for electronic books.
Category Five is the latest to be converted, and should be appearing shortly in the iTunes and B&N Nook stores.
2015-08-06
"Category Five"
My techno-thriller, Category Five, has been converted to Kindle format, and is now available from Amazon. The price is $3.50.
It takes a fair amount of work to convert a book to the various electronic formats (I should write a blog post about that sometime). I will make the book available in other formats and at other online stores as soon as I can.
It takes a fair amount of work to convert a book to the various electronic formats (I should write a blog post about that sometime). I will make the book available in other formats and at other online stores as soon as I can.
2015-07-21
Augmented QSO information from CQ WW contest files from 2008 to 2014
Earlier this month I made available cleaned versions of the QSOs from the CQ WW CW and SSB public logs from 2008 to 2014.
Now I have added an augmented version of these QSOs.
Each QSO line now includes an additional four columns, with the following meanings:
http://drevans.blog.enginehousebooks.com/2015/11/cleaned-and-augmented-qso-information.html
Now I have added an augmented version of these QSOs.
Each QSO line now includes an additional four columns, with the following meanings:
- The letter "A" or "U" indicating "assisted" or "unassisted"
- A four-digit number representing the time if the contact in minutes measured from the start of the contest. (I realise that this can be calculated from the other information on the line, but it saves a lot of time to have the number readily available in the file without having to calculate it each time.)
- Band
- A set of eight flags, each encoded as T/F:
- a. QSO is confirmed by a log from the second party
- b. QSO is a reverse bust (i.e., the second party appears to have bust the call of the first party)
- c. QSO is an ordinary bust (i.e., the first party appears to have bust the call of the second party)
- d. the call of the second party is unique
- e. QSO appears to be a NIL
- f. QSO is with a station that did not send in a log, but who did make 20 or more QSOs in the contest
- g. QSO appears to be a country mult
- h. QSO appears to be a zone mult
The resulting QSOs are in a single compressed (xz) file downloadable from:
https://copy.com/7OkPxBknZZi0UyQk
The MD5 checksum of this file is: 63dc4d8485132171741e04b306d3bf55
NB: See the updated post at:http://drevans.blog.enginehousebooks.com/2015/11/cleaned-and-augmented-qso-information.html
2015-07-16
Preventing DPMS operation in X in Debian 8 (jessie)
Since switching to Debian 8 on my shack computer, drlog has acquired an obnoxious behaviour.
In the past, when left unattended the screen would blank after a few minutes, and the normal screen could be restored simply by tapping a key on the keyboard. Although slightly annoying, I was never sufficiently motivated to go looking for the cause of the blanking, since once the screen was restored, drlog continued to function correctly.
This changed with the installation of Debian 8 (jessie). The screen would blank as before, but then once the screen was restored, drlog could no longer key the rig.
So now I had to find out what was going on.
It turns out that the blanking is caused by the operation of DPMS. By default, X enables DPMS, and further causes DPMS to enter sleep mode after 600 seconds.
Nothing I have seen suggests that DPMS should affect more than the display, but, apparently, in Debian 8 it also affects the parallel port -- and, further, when the computer emerges from the sleep state, operation of the parallel port is not properly restored.
In a contest one wants as little as possible happening on the computer other than the operation of the contest program (simply because every operation that is happening not under the control of the logging program is a fragility one doesn't want). So the obvious solution is to disable DPMS.
This turns out to be trickier than one would think.
Since the use of DPMS is controlled by X, it means that one has two reasonable choices: disable DPMS on a case by case basis, and ensure that it is disabled when the logging program is invoked; or configure the system so that by default DPMS is no longer enabled when the X server starts.
The first of these can be accomplished by issuing the commands:
xset -dpms
xset s off
prior to starting the logging program.
I prefer the second solution, but it is trickier, since it requires changing the configuration of the X server when it starts.
In Debian 8 there is no longer an X configuration file. In the absence of a configuration file, X automatically uses a reasonable default configuration. Unfortunately, it is this "reasonable default" that enables DPMS. So the first thing to do is to create an X configuration file.
To do this, at the Linux console (i.e., not in an X session) stop the desktop manager. Since I use kdm, the command (as root) is:
/etc/init.d/kdm stop
Now generate the X configuration file corresponding to the "reasonable default".
As root, type:
X org -configure
This creates the file /root/xorg.conf.new. Copy this file to /etc/X11/xorg.conf.
This will be the configuration file that X will use when the X server starts. It's a good idea to test this now, either by restarting X or rebooting.
Assuming that X starts as normal following the restart/reboot, then we need to make a couple of edits to the xorg.conf file we just created.
To the "Monitor" section add the line:
Option "DPMS" "false"
This should stop DPMS being enabled. But while we're at it, we can also stop the separate screen blanking that X by default also executes. (Confusingly, this also happens after 600 seconds: so in the default configuration there are actually two operations that occur after 600 seconds of inactivity, and both have the effect of blanking the screen. It is the use of DPMS that also causes the parallel port issue; but we might as well stop the screen from blanking while we are here.)
To the xorg.conf file add the following:
Section "ServerFlags"
Option "BlankTime" "0"
EndSection
Next time you start X, the screen (and parallel port) should no longer be affected in any way after a period of inactivity.
And, most importantly, you can now leave the computer during a contest, and drlog should operate correctly when you return.
In the past, when left unattended the screen would blank after a few minutes, and the normal screen could be restored simply by tapping a key on the keyboard. Although slightly annoying, I was never sufficiently motivated to go looking for the cause of the blanking, since once the screen was restored, drlog continued to function correctly.
This changed with the installation of Debian 8 (jessie). The screen would blank as before, but then once the screen was restored, drlog could no longer key the rig.
So now I had to find out what was going on.
It turns out that the blanking is caused by the operation of DPMS. By default, X enables DPMS, and further causes DPMS to enter sleep mode after 600 seconds.
Nothing I have seen suggests that DPMS should affect more than the display, but, apparently, in Debian 8 it also affects the parallel port -- and, further, when the computer emerges from the sleep state, operation of the parallel port is not properly restored.
In a contest one wants as little as possible happening on the computer other than the operation of the contest program (simply because every operation that is happening not under the control of the logging program is a fragility one doesn't want). So the obvious solution is to disable DPMS.
This turns out to be trickier than one would think.
Since the use of DPMS is controlled by X, it means that one has two reasonable choices: disable DPMS on a case by case basis, and ensure that it is disabled when the logging program is invoked; or configure the system so that by default DPMS is no longer enabled when the X server starts.
The first of these can be accomplished by issuing the commands:
xset -dpms
xset s off
prior to starting the logging program.
I prefer the second solution, but it is trickier, since it requires changing the configuration of the X server when it starts.
In Debian 8 there is no longer an X configuration file. In the absence of a configuration file, X automatically uses a reasonable default configuration. Unfortunately, it is this "reasonable default" that enables DPMS. So the first thing to do is to create an X configuration file.
To do this, at the Linux console (i.e., not in an X session) stop the desktop manager. Since I use kdm, the command (as root) is:
/etc/init.d/kdm stop
Now generate the X configuration file corresponding to the "reasonable default".
As root, type:
X org -configure
This creates the file /root/xorg.conf.new. Copy this file to /etc/X11/xorg.conf.
This will be the configuration file that X will use when the X server starts. It's a good idea to test this now, either by restarting X or rebooting.
Assuming that X starts as normal following the restart/reboot, then we need to make a couple of edits to the xorg.conf file we just created.
To the "Monitor" section add the line:
Option "DPMS" "false"
This should stop DPMS being enabled. But while we're at it, we can also stop the separate screen blanking that X by default also executes. (Confusingly, this also happens after 600 seconds: so in the default configuration there are actually two operations that occur after 600 seconds of inactivity, and both have the effect of blanking the screen. It is the use of DPMS that also causes the parallel port issue; but we might as well stop the screen from blanking while we are here.)
To the xorg.conf file add the following:
Section "ServerFlags"
Option "BlankTime" "0"
EndSection
Next time you start X, the screen (and parallel port) should no longer be affected in any way after a period of inactivity.
And, most importantly, you can now leave the computer during a contest, and drlog should operate correctly when you return.
2015-07-05
Cleaned QSO information from CQ WW contest files from 2008 to 2014
The CQ World Wide (CQWW) website cqww.com hosts and makes available public logs from 2008 to 2014. These public logs are more or less as submitted, except that certain private information has been removed. However, since the logs contain all the Cabrillo lines in the original log, they are not particularly suitable for direct analysis.
To try to aid with analyses based on public logs, I have made available the QSO information from the logs in a more convenient format.
The MD5 checksum of this file is:
2e8540de740de98de305166c19c2f0bf
NB: See the updated post at:
http://drevans.blog.enginehousebooks.com/2015/11/cleaned-and-augmented-qso-information.html
To try to aid with analyses based on public logs, I have made available the QSO information from the logs in a more convenient format.
I went through all the CQ WW public logs, cleaning them up and converting all the QSOs to the correct Cabrillo format (a surprising number of the raw logs provide examples of creative formatting and/or downright erroneous information
in the QSO lines).
The resulting QSOs for the CW and SSB contests from 2008 to 2014 are in a single compressed (xz) file downloadable from:
https://copy.com/XPz49aZmd4KqhRFpThe MD5 checksum of this file is:
2e8540de740de98de305166c19c2f0bf
NB: See the updated post at:
http://drevans.blog.enginehousebooks.com/2015/11/cleaned-and-augmented-qso-information.html
Subscribe to:
Posts (Atom)