I passed my novice radio amateur exam in March 2013 and I registered the
PD4KH (pappa delta four kilo hotel!).
I passed my full radio amateur exam in March 2016 and I registered the callsign
PE4KH (pappa echo four kilo hotel!).
PE4KH on qrz.com
I am usually located around maidenhead locator: JO22NC
I upload logs to eQSL.cc and ARRL Logbook of the World, during and after being active on the radio. I upload logs to www.qrz.com and clublog on a regular basis. I like paper cards via the QSL bureau so I send those out when requested or when I think the other party will appriciate one and I will respond when I receive a card. You can also request a card via the Log Search on clublog for PE4KH using the OQRS service. Notifying me via e-mail that you would like a card is also possible.
I appreciate SWL reports for QSOs and will respond.
gallery of eQSL cards received by PD4KH, PE4KH, PE4KH/P, DL/PE4KH.
Antenna rotor project
D-Star digitale amateur radio (Nederlands)
Recent contact (QSO) map for PE4KH embedded using google maps
gcmwin for linux maps with gridsquares contacted (red) and confirmed (blue) :
Mapped HF contacts by PE4KH
Mapped 10M contacts by PE4KH
Mapped 15M contacts by PE4KH
Mapped 17M contacts by PE4KH
Mapped 20M contacts by PE4KH
Mapped 30M contacts by PE4KH
Mapped 40M contacts by PE4KH
Mapped 60M contacts by PE4KH
Mapped 80M contacts by PE4KH
Mapped 2M contacts by PE4KH
Mapped 70CM contacts by PE4KH
Mapped satellite contacts by PE4KH
This week had an opportunity to receive ISS SSTV pictures. The Russian on the ISS were transmitting SSTV images as part of the Inter-MAI-75 project. The pass had a partial first image, a nice decode of one full image and the start of a third image. Even the good receives are a bit noisy/unsharp, I'm not sure whether that's an artifact of the PD120 mode or some local noise ending up in the image. This is one of the rare occasions where living close to Russia is a good thing: the Russians time the passes to optimize reception in Russia.
I installed xcwcp from the unixcw packages on a different system and noticed it did not use PulseAudio. It said it could not find PulseAudio and skipped to ALSA. The downside of ALSA in xcwcp is that it pushes audio 10 characters ahead, with PulseAudio the buffer is smaller. Some searching using strace found that xcwcp tries to open libpulse-simple.so which wasn't found on that system. It is available on my laptop, as part of:$ dpkg -S /usr/lib/x86_64-linux-gnu/libpulse-simple.so libpulse-dev:amd64: /usr/lib/x86_64-linux-gnu/libpulse-simple.sowhile the files linked to a part of the runtime package:$ dpkg -S /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 libpulse0:amd64: /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 $ dpkg -S /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.1 libpulse0:amd64: /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.1But I don't have package libpulse-dev on that other system. Solution: make the symlink by hand in /usr/lib/x86_64-linux-gnu with:user@system:/usr/lib/x86_64-linux-gnu$ sudo ln -sf libpulse-simple.so.0 libpulse-simple.soAnd I reported it as a bug for ubuntu: Bug #1854630: xcwcp doesn't use pulseaudio but given the list of bugs in Ubuntu I reported or commented on before with a lot of 'undecided' and not a lot of progress I'm not sure anything will happen. Back to practising morse after this diversion!
The next thing I want to get working is morse with the remoterig and the Kenwood TS-480. The good thing is that the remoterig has a built-in morse keyer to overcome jitter problems. And that keyer has the option to make a winkeyer usb interface available. I did some minor testing with the winkeydaemon driver together with the paddle and it works. So I can use both the keyer from the computer and the paddle at the same time, just like with the nanokeyer and the FT-857 radio. There is one strange thing though: this keyer responds somewhat different from the nanokeyer when I do a fast dah-dit. I expect the dit to follow after the dah even when I already stopped touching the left paddle (dit) before the dah ends.
I dug into the "why isn't remote CAT control not working" on the Kenwood TS-480SAT with the remoterig setup and as the debugging session progressed I found out it wasn't even working locally. The Kenwood TS-480 radios have a male db9 connector just like the PC had, and the non-intuitive part is that it needs a straight-through cable with data lines and hardware flow control. I had a bunch of serial cables and adapters cobbled together to get from DB9 female to DB9 female with wires 2 and 3 coming out uncrossed, but it did not have hardware flow control and that had worked one evening before but now it decided to go on strike. Thanks to the visit to the "Dag van de radio amateur" (DvdRA) ham convention and the extra parts ordered on-line from Conrad I had enough parts to make my own serial cable with the right wiring, including covers for the connectors with the cable coming out on the side. So my skills in building right serial cables using a soldering iron, flexible wire and an amount of patience were recalled. I am very sure I haven't done that yet this century. Old CAT-5E cables are a good source of flexible cable with 8 wires. When I had a finished cable with hardware flow control I first did a local test before I started putting the covers on the connectors and when that did work fine I put the covers on, redid the test and switched to testing over the remoterig connection. That also worked. Update: And for the laptop which doesn't have serial ports I activated the COM port to USB translation on the control side. It took a bit of searching before I found that /dev/ttyACM0 was the active port, so now I can run CQRLOG on the laptop with full control of the radio.
I finished the setup of the remoterig system. The second part is with lots of wires, first setting jumper wires in the radio box and the control box and after that connecting lots of wires to radio, frontpanel, microphone and other parts. It took a bit of browsing the manual, checking my jumper wires under good light and redoing the checks but eventually it got all connected. After that it was setting the software parameters for the specific radio and the connection to the control panel. And the next step: pressing the power button on the frontpanel on the control box and seeing it become active and hearing audio from the radio. So it's now working. The bit that doesn't work yet is CAT control of the radio (Computer Assisted Tuning, where I can read the status and give commands over the serial port). The forwarding of the CAT port to a USB serial port on the other side did not give me any communication on the connected computer. I'm sure I'll get that fixed. Next step was to spin the dial and find someone searching for a contact. Not a lot of activity on the 40 meter band, but I heard a greek station calling, answered it and got into the log.
The remoterig set I ordered arrived. At first I found the box somewhat empty: no manuals. But the entire manual can be found on-line: User manuals - RemoteRig. The manual is about 200 pages so printing it would be a bad idea. The remoterig site is somewhat slow so I downloaded the PDF manual to my computer. Most of the setup is done via a webinterface, but the initial network setup needs either the right IP addresses hardcoded or a USB connection and the Microbit setup software which is only available for Windows. I did try to see whether one of the four com-ports via USB that showed up would allow me to do a minimal setup via a terminal program but that wasn't true. So I booted Windows to change the units to DHCP. For the radio-side I made an address allocation in the DHCP server, for the client side it is fine to have any usable address. And for my next minor issue: they only use IPv4. So my inner linux and networking geek is a bit dissapointed, but my inner radio geek will do just fine. After that bit I went back to Linux, the rest of the software setup is via a webbrowser. For the hardware setup, which is how it connects to the radio (which pin has audio, which pin has power) it needs a number of internal jumpers and jumper wires connected.
HF propagation has been really bad the last weeks. At least on the moments I had time to look at the radio. The maximum usable frequency was dropping below 14 MHz as soon as it started getting dark. This means that I can only make contacts on the lowest band (40 meters) with the endfed antenna set up outside and the experience from earlier weekends was that it was still a lot of work to get contacts on FT8. So this weekend I did some 2 meter FT8 and made contacts with some new call signs. I was lucky: the 2 meter interference stopped after dark. My computer decoded one Danish callsign but I wasn't near it at that moment. And I tried a pass of the SO-50 satellite. A pure southwest-northeast pas was coming up at the start of the evening, so I planned to be outside in the cold with antenna and handheld radio. I was hoping to get some country to the south of me in the log, but I ended up with a southeasterly contact: Croatia. I heard 9A2EY in a contact so I called him and made the contact.
I was tuning across the 70cm amateur band and heard lots of weird noises around 433.92 MHz. Which is logical: that's the ISM band (industrial, scientific and medical) so lots of unlicensed low-power signals there.
That triggered me to update rtl_433 and see what I could receive. The answer after some searching how to build a running version: a lot. Including tire pressure monitoring sensors (TPMS) on a nearby car:time : 2019-11-16 15:33:25 model : Toyota type : TPMS id : fb8c8bf9 status : 128 pressure_PSI: 38.500 temperature_C: 6.000 mic : CRCThere is indeed a Toyota parked across the street. I see three different values for 'id' suggesting that three wheels are 'awake' and reporting tire pressure data about every two minutes. According to eavesdropping the wheels, a close look at TPMS signals the sensors should only activate when the car is going faster than 40 km/h or when a special LF signal is active.
So the order for the remoterig duo to work on my remote HF operation plans is out the door. I ordered them with HamShop to get Dutch warranty rules. I also ordered some other stuff from Conrad to be able to get everything cabled correctly. I may have missed something but I hope to have enough to get going and be able to have frontpanel and main radio hardware separated by Internet.
I had time to do some soldering and I tested and wired the 12V server powersupply I bought last Saturday at the "Dag van de Radioamateur" ham convention. The powersupply that I bought is an HP DPS-800GB A and it already had two wires to make it start up when input voltage is applied. I just soldered thick wires to the output terminals so I can connect it to the HF amplifier. Unlike the previous HP DPS-700 powersupply this one has two builtin fans so it won't overheat. Time to test it with the HF amplifier is this weekend. I'll test the output power with the current output voltage left as-is. It's currently at 12.2 Volt when no load is applied. There are simple modifications to raise the voltage as described by Server supply DPS-800GB - PA0FRI. Update: After some testing it's clear there are two problems: the output voltage of this power supply does not get very high before it switches off. About 13 volts. At that voltage the output power of the HF amplifier is limited. And when using the external amplifier I had a lot of problem with the connection between the computer and the radio. As soon as I started transmitting the computer started giving error messages about the communication with the radio. So back to just the radio and its output power at the moment.
Powersupply with wires attached