Sunday had less time to be at the radio for ISS passes but one pass was ok. It started with the end of one image, one full image and the start of the next image.

After hickups in recording audio from the radio on two previous passes I rebooted the whole system (it was nagging about a reboot anyway) and I received two more partial images.

Thanks to ARISS Russia team member Sergey Samburov, RV3DR for making this possible!

Second pass of the International space station gave me one partial picture and one complete (with some noise).

In this weekend there are extra slow scan tv (SSTV) transmissions from the international space station (ISS). The ISS moves across the sky when viewed from earth so I calculate beforehand when it will pass across the sky and what the trajectory will be.

I woke up in time to be outside for the first one. A low pass over the horizon and most of the pass matched a pause between transmissions, so not much image received.

Het blijft actueel: Verschillende afpersmails in omloop - Fraudehelpdesk.

Ik zie ze zelf ook op verschillende plekken. Trap hier niet in.

Dit keer een bitcoin adres waar nog geen transacties in zichtbaar zijn: 12PUa2SHjWAUEpZZUxQNvxa7epab7g2Ksb alleen is mij niet duidelijk of deze site het verschil tussen een echt aangemaakt adres zonder transacties of een willekeurig adres weet.

Toevoeging 2019-02-07: Een bedrag van 808 dollars in bitcoins staat nu in de wallet, in 2 transacties. Gegeven het bedrag in het originele mailtje zijn er dus 2 mensen ingetrapt.

Toevoeging 2019-02-11: Er is nu over de 3000 dollar in bitcoins binnen. Als ik zo naar de transacties kijk lijken er 7 mensen ingetrapt.

Nog meer informatie: Bitcoin Abuse Database for 12PUa2SHjWAUEpZZUxQNvxa7epab7g2Ksb (engelstalig).

I noticed something really weird in the kernel log of a virtual machine:

Feb  5 11:46:54 server kernel: [2936066.990621] Bluetooth: Core ver 2.22
Feb  5 11:46:54 server kernel: [2936067.005355] NET: Registered protocol family 31
Feb  5 11:46:54 server kernel: [2936067.005901] Bluetooth: HCI device and connection manager initialized
Feb  5 11:46:54 server kernel: [2936067.006404] Bluetooth: HCI socket layer initialized
Feb  5 11:46:54 server kernel: [2936067.006838] Bluetooth: L2CAP socket layer initialized
Feb  5 11:46:54 server kernel: [2936067.007280] Bluetooth: SCO socket layer initialized
Feb  5 11:46:54 server kernel: [2936067.009650] Netfilter messages via NETLINK v0.30.
Feb  5 11:46:54 server kernel: [2936067.056017] device eth0 entered promiscuous mode

The last two are the giveaway about what really happened: I started tcpdump to debug a problem. But I did not expect (and do not need) bluetooth drivers on a virtual machine, it will never have access to a bluetooth dongle.

After setting up /etc/modprobe.d/local-config.conf with

blacklist bluetooth

tcpdump still works fine and no bluetooth drivers are loaded.

Update: Most recommendations are to disable the bluetooth network family:

alias net-pf-31 off

After a month with three digimode radio contests I plotted the number of amateur radio contacts again. The number of contacts is clearly higher each January as a contest month, with this January a new peak.

The contests were the ARRL RTTY Roundup on 6 and 7 January, the UBA PSK63 prefix contest on 12 and 13 January and the BARTG RTTY Sprint Contest on 26 and 27 January.

Nicer looking font due to the upgrade of "radio workstation" thompson. I guess even gnuplot is coming along with the modern times.

before, before, before, before

I have "always" been running amanda for backups on linux. Or rather, I can't find any indication when I started doing that several homeserver versions ago, it's just still running.

Or it was running, but first I had to tackle a hardware problem: all SCSI controllers I have are PCI and the newest homeserver has no PCI slots. So I searched for a solution. The first solution was to try using the desktop system for the tapedrive, but the powersupply in that system has no 4-lead Molex connectors so I can't connect the tapedrive.

For now I use an old 'test' system with some software upgrades to run amanda and shut it down when all backups are done and flushed to tape. But amanda had a serious problem writing stuff to tape. With some debugging this turned out to be caused by the variable blocksize I used on the previous systems, with

# mt -f /dev/nst0 setblk 0

and I can't even find out why this seemed like a good idea years ago. But now amanda really wants to use 32768 byte blocks and filled a DDS-3 tape (12 Gb without compression) with about 1.8 Gb of data before reaching the end of the tape.

Why this default has changed isn't clear to me, but I found a way to re-initialize the tapes so the backups fit again. Based on block size mismatch - backup central I created a script to do this. I did not get the error about the blocksize, but I searched specifically for 'amanda 3.3.6 blocksize'.

#!/bin/sh

if [ "$1" = "" ]; then
        echo "Usage: $0 <tapename>"
fi

mt -f /dev/nst0 setblk 32768
mt -f /dev/nst0 compression 1
mt -f /dev/nst0 rewind
dd if=/dev/zero of=/dev/nst0 bs=32768 count=200
mt -f /dev/nst0 setblk 32768
mt -f /dev/nst0 compression 1
mt -f /dev/nst0 rewind
amlabel -f kzdoos $1

And now normal amounts of data fit on a tape again. I just have to initialize every tape before using it for the first time in this setup.

This weekend I participated in the BARTG (British Amateur Radio Teledata Group) RTTY Sprint Contest.

I went into this contest with the idea of maybe getting some contacts and things turned out somewhat better than that: I made 82 contacts. No new countries or anything else special. The one that got away was PJ4P, Bonaire. I saw that station calling and I kept answering but the contact did not happen.

I used the topendfed antenna outside and the amplifier. So I entered in the high power category.

As with other recent contests the propagation wasn't cooperating very well. When I started in HF at home (October 2014) I would switch from 10 to 20 meters after it got dark because of the changing propagation. Now I change from 20 to 40 meters as soon as it starts to get a bit dark.