RemBl.org

UPDATE: As I already felt, the idea below is already implemented by Poul-Henning Kamp in his own implementation of a NTP-server, NTPns. I am trying to figure it out and will report the results here as soon as I got it running.

———–
This post tries to describe an experiment using DCF77 pulses as PPS source. Although seemingly trivial, I could not find any information on the web dealing with this issue, therefore I publish it here. Presumably the following ‘discovery’ is already implemented in ntpd and/or its refclock-drivers. I am more into hardware.

Anyway. . . . enough disclaimers!

Today a friend of mine returned one of my DCF77 radio modules because ‘it didn’t work anymore’. Before he returned the module, he took a picture of it. Well… the ferrite antenna rod was missing, presumably ‘lost’ during a relocation of the server the module was connected to.

The module was interfaced to RS232 in conjunction with radioclkd2. I use(d) the PARSE/GENERIC driver on ntp.remco.org and for this driver the RS232 connector needs to be rewired.
Below the RS232 wiring is explained for a DB9 connector:

radioclkd2: Vcc-pin4/DTR, GND-pin5/GND, DCF-pin1/DCD
parse/generic: Vcc-pin7/RTS, GND-pin5/GND, DCF-pin2/RxD

While rewiring I thought it would be a nice idea to compare Frank’s parse driver with Jon’s SHM driver and fed the DCF77 signal to both pin1 (DCD) and pin2 RxD, using a drop of solder. +Vcc was connected to pin7 (RTS).

Using (sudo)  radioclkd2 -s iwait ttyS0:-dcd -d -v yielded DCF pulses and in ntp.conf I entered:

#PARSE Conrad RAW DCF77 (time1 0.2154)
server 127.127.8.0 mode 5
fudge 127.127.8.0 time1 0.2154 stratum 0 refid DCFa

#SHM driver (for use with radioclkd2)
server 127.127.28.0
fudge 127.127.28.0 time1 0.0285 stratum 0 refid DCFb

Putting radioclkd2 into daemon mode (discarding the -d -v options), I restarted ntpd subsequently.  After a while ntpd synchronized to DCFb.  I monitored the behaviour of both ‘DCFa’ and ‘DCFb’, and found out that, contrary to my earlier observations, DCFb (i.e. radioclkd2) revealed less jitter. However, these earlier observations were based on seperate experiments, not using the parse and radioclkd2 (SHM) driver simultaneously as (potential) peers. Perhaps further investigation is needed….

Anyway, for whatever reason I thought about the ‘PPS’ option in conjunction with the parse driver (add 128 to mode number, i.e. server 127.127.8.0 mode 5 -> server 127.127.8.0 mode 133 in ntp.conf) would also be interesting.

Because I use LinuxPPS on ntp.remco.org with an Oncore UT+ timing receiver *and* now had a second PPS-source, i.e. the ‘DCF77-PPS’-signal connected to pin1 (DCD). I was curious how ntpd dealt with this ‘new PPS-peer’.

NB: Yes, yes, yes…. I know that DCF77 does not transmit data in the 59th second of a minute!

I gave it a try and activated a second PPS interface with: setserial /dev/ttyS1 hardpps (cf. LinuxPPS wiki, please read!):

remco@helium [/home/remco]> cat /sys/class/pps/pps1/{assert,clear}
1212786628.000324988#43281
1212786628.118746763#43281

The rising (assert) edge of the pulses are synchronized to UTC epochs by the PTB (Germany), and the pulse length (100 vs. 200 ms) is used to transmit information (see PTB site for an explanation of the DCF77 protocol).

Initially I could not ascertain how to activate the PPS-option from the driver8 documentation, and made an erroneous symlink: ln -s /dev/ttyS1 /dev/refclockpps-1, subsequently followed by errors in my syslog (later I discovered that a symlink to pps1 is needed, i.e. ln -s /dev/pps1 /dev/refclockpps-1).
As I had no time at that moment to figure out why I obtained the errors, I switched to the ATOM driver (driver22) , and added in ntp.conf:

#ATOM (rising edge, flag2 0 )
server 127.127.22.1 minpoll 4 maxpoll 4
fudge 127.127.22.1 time1 0.0285 flag2 0 flag3 1 stratum 0 refid PPSa

I used the time1 fudge factor (28.5 ms) from my other DCF77-receivers as an initial guess.

And… yes! After a while I obtained a sync for PPS(1), and observed lower jitters of PPS(1) than the ‘original’ DCF77-signal (DCFa) using a polling time of 16 seconds (minpoll 4). This means that one second in every 4th sample is missing, generating additional jitter. I did not experiment nor determined whether changing polling times to e.g. 16 or 64 seconds, i.e. [3*16+1*15]/64, is better or worse than 63/64. Although arithmetically identical, perhaps some software loop filters within ntpd have different time constants when using different polling times.

Because the jitter of the ‘DCF77-PPS’ is increased by the missing 59th second, perhaps it would be a suggestion that the PARSE driver8 in mode 133 inserts a time stamp in the 59th second of every minute, in the case that the DCF signal is fed to RxD and DCD simultaneously (might this be mode 20 for example? ; -). The omitting 59th time stamp may be derived from the 58th second or, for example, or the average from the last 5 seconds or so. LinuxPPS then ’sees’  a time stamp every second, and my feeling says that the precision of the PARSE driver in RAWDCF mode (e.g. mode 5+128)  can be increased.

Feedback is highly appreciated.

Recently I bought a Motorola Oncore UT+ GPS timing receiver on Ebay. I run Debian Linux and it seems that the refclock_oncore driver is not included in ntpd because the LinuxPPSAPI from Rodolfo Giometti is not an official part of the linux kernel (yet? ; -)

I interfaced the module with three inverters (74HC14) to my RS232 port. The TX-line was leveled with two resistors and an universal diode (DUS). In my opinion complex interfaces like the TAC2 are not necessary.
(click on image to enlarge and see the details)

To get my UT+ to do work for ntpd, I needed to compile ntpd from source. Normally this is not an issue, but I did not manage to include the oncore refclock in the code and continuously obtained the error:

refclock_newpeer: clock type 30 invalid

in my ntpd logfiles.

With the help of the author of the Oncore driver, Reg Clemens, the following cookbook recipe crystallized, assuming that you have a working LinuxPPS system and a patched kernel(source):

1. in /usr/include ln -s /usr/src/<linux-source>/Documentation/pps/timepps.h . <- ‘.’ !
2. in /usr/include/sys ln -s /usr/src/<linux-source>/Documentation/pps/timepps.h . <- ‘.’ !
3. verify that you also have the links to asm, asm-generic and linux, according to Rodolfo’s wiki
4. in /dev ln -s pps0 oncore.pps.0 (or whatever ppsX you will use)
5. in /dev ln -s ttyS0 oncore.serial.0 (or whatever interface you’ll use, ln -s ttyS2 oncore.serial.1 is also allowed e.g.)
6. download the ntpd source from www.ntp.org and untar it. I use the development version of ntp.
7. configure with at least the options: ./configure –enable-ONCORE –enable-SHM
8. verify from the output that there are ‘yesses’ after timepps.h and Motorola Oncore
9. make
10. add the following entry in ntp.conf: server 127.127.30.0 (when you used oncore.pps.0 and oncore.serial.0)
11. edit /etc/ntp.oncore.0:
    #
    # Oncore UT+ configuration file
    #
    # —– mandatory lines —————-
    MODE 1
    LON 5 11.4548 #insert your own longitude here
    LAT 52 14.2342 #insert your own lattitude here
    HT 11.0 M #insert your own GPS height here
    # —– optional lines ——————
    DELAY 20 NS #delay is approx 5 ns/m cable (I have 4m cable between my antenna and UT+
    CLEAR #negative edge is synced to UTC epochs (due to HC14 inverter, see above)
    SHMEM /var/log/ntpstats/oncore.0
    MASK 0
    TRAIM YES
12. kill all ntpd processes, go to the ntpd directory and start ntpd with root privs as ./ntpd
13. verify in your ntpd logfile that ntpd picks up the Oncore driver:
    54571 82587.208 127.127.30.0 ONCORE DRIVER — CONFIGURING
    54571 82587.208 127.127.30.0 state = ONCORE_NO_IDEA
    54571 82587.225 127.127.30.0 Input mode = 1
    54571 82587.225 127.127.30.0 Initializing timeing to Clear..
    54571 82587.226 127.127.30.0 SHMEM (size = 3584) is CONFIGURED and available as /var/log/ntpstats/oncore.0
    54571 82587.226 127.127.30.0 state = ONCORE_CHECK_I
    *snip* and somewhat later…..
    54571 82588.542 127.127.30.0 This looks like an Oncore UT with version 3.1 firmware.
    54571 82588.542 127.127.30.0 Channels = 8, TRAIM = ON
    54571 82588.542 127.127.30.0 state = ONCORE_CHECK_CHAN
    54571 82593.151 127.127.30.0 Input says chan = -1
    54571 82593.151 127.127.30.0 Model # says chan = 8
    54571 82593.151 127.127.30.0 Testing says chan = 8
    54571 82593.151 127.127.30.0 Using chan = 8
    54571 82593.151 127.127.30.0 state = ONCORE_HAVE_CHAN
    54571 82594.641 127.127.30.0 state = ONCORE_TEST_SENT
    54571 82603.241 127.127.30.0 GPS antenna: OK
    54571 82603.241 127.127.30.0 state = ONCORE_INIT
    54571 82604.701 127.127.30.0 Setting Posn from input data
    54571 82604.701 127.127.30.0 state = ONCORE_ALMANAC
    *snip* and somewhat later……
    54571 82606.941 127.127.30.0 Cable delay is set to 20 ns
    54571 82609.291 127.127.30.0 Have now loaded an ALMANAC
    54571 82609.291 127.127.30.0 state = ONCORE_RUN
    54571 82609.291 127.127.30.0 SSstate = ONCORE_SS_DONE
    54571 82610.401 127.127.30.0 ONCORE: Detected TRAIM, TRAIM = ON
    54571 82610.401 127.127.30.0 Input says TRAIM = -1
    54571 82610.401 127.127.30.0 Model # says TRAIM = 1
    54571 82610.401 127.127.30.0 Testing says TRAIM = 1
    54571 82610.401 127.127.30.0 Using TRAIM = 1
    54571 82610.421 127.127.30.0 PPS Offset is set to 0 ns
    54571 82610.431 127.127.30.0 Satellite mask angle is 0 degrees
14. Enjoy and impress your friends with your timing receiver, just like I impressed you ; -)

Although DCF77 seems to be the ‘default’ time reference for the European continent, I want to have a backup because I run a stratum 0 NTP server.

MSF (60 kHz England, UK) is a good candidate. Compared to DCF receivers, MSF receivers are difficult to obtain and expensive on the continent.

So, I modified a Conrad DCF77 module for the reception of MSF, using a 60 kHz watch crystal as filter.
I tuned the antenna/ferrite coil from 77.5 to 60 kHz.

Click on the picture to enlarge v0.1 of the modified radio module.

The coil is from an old transistor radio but later I retuned the original ferrite coil as supplied with the Conrad radio module.

Most radio clock IC’s want to see a resonated loaded impedance between 50 - 100 kΩ. I simply multiplied the capacitance of my DCF77 ferrite antenna with 1.67 ( [77.5/60]²), i.e. for my Conrad radioclock module I added 4n7 parallel to the original 6n8 capacitor.

Using ntpd with the SHM refclock enabled and radioclkd2 as ‘atomic radio clock parser’ the MSF signal from Anthorn is decoded here:

pulse start: at 1206318120.024987
data(60):5,1,1,1,1,1,1,1,1,11,11,11,11,1,1,1,1,1,1,1,1,2,1,1,1,1,1,1,2,2,2,1,1,2,1,1,1,1,2,1,1,1,1,1,1,1,2,1,1,1,2,1,1,2,2,3,2,3,2,1,
MSF : |0 |5 |10 |15 |20 |25 |30 |35 |40 |45 |50 |55
MSF-A: …………………A……AAA..A….A…….A…A..AAAAAA.
MSF-B: ………BBBB……………………………………B.B..
MSF time: 2008-03-24 (day 1) 00:22 GMT
clock: radio time 1206318120.000000, average pctime 1206318120.024964, error +-0.004383
pulse end: length 0.494541 - 0: 5
pulse start: at 1206318121.039543
pulse end: length 0.089901 - 1: 1
pulse start: at 1206318122.025892

Update 1: it seems that there is some (propagation?) interference in the night which causes ntpd to loose lock sometimes. Perhaps I need a better antenna as the ERP of MSF was decreased after the relocation (April 1st 2007) from Rugby (ca. 50 kW ERP) to Anthorn (ca. 15 kW ERP).

Update 2: Today (18 april 2008) I received a Meinberg analogous DCF77 antenna module from a collegue. I tuned it to 60 kHz. First impression is that it works significantly better than the original antenna.

(click on the image to enlarge)

Yesterday I built a 10.000.000 divider with a small cascade of 74LS390’s to divide the rubidium 87 (Rb87) locked 10,000.000.00000(0) MHz from my Efratom FRS into 1 Pulse Per Second (PPS). I know that there is a another approach available. However, I managed to program a 16F648A PIC, but the contrapsion did not work. Perhaps the code needs a 16F84.
But… I am more into hardware anyway.

I built the divider on a small piece of epoxy bread board and combined my frequency standard with an “is locked, PPS works, and ready to use”-indicator. Thus, when the standard is switched on, several minutes later the PPS led starts to flicker.

The divider is depicted on the right (click to enlarge).

The PPS is shaped by a one shot generator (LS123) and the PPS width is approx. 75 ms.

A PDF of the -straight forward- schematic diagram can be downloaded here.

An advantage is that the PPS error is reduced by several orders.

This is a picture of the divider built into my Rubidium standard.

So, my Rb standard will now produce a ‘rock solid’ 1PPS for ntp.remco.org !

In my previous post I reported a succesfull try wih LinuxPPS in conjunction with ntpd’s NMEA, ATOM and SHMPPS drivers. However, as far as I could ascertain, the PPS signal from the CIROCOMM G100/300 (I still have not heard anything from them..) can not be locked to the GPS signal due to the relatively large offsets and jitters.
I borrowed a Rockwell Jupiter unit, which Bas PE1JPD bought on a HAM-radio flea market a few years ago, to use it with his PDA and TomTom Navigator.

It seems that the Jupiter PPS signal is locked onto the GPS signal and the datasheet mentions that the rising edge of the TMARK pulse (i.e. PPS) is synchronized with the UTC one second epochs to within ± 1 μs. Other information states that the TMARK output is 10 - 40 ns accurate.
I interfaced the Jupiter using a 74HC00 to invert the TxD (mandatory) and PPS (not mandatory ; -).

Click on the image right to enlarge.

I placed the Jupiter into ‘Zodiac Binary Protocol mode’ (pin 7 HIGH and pin 8 GND, 9600 bps mode) first, and when I connected the receiver I could not see a GPS fix at all. I suspected the small patch antenna from Bas and remembered that I had an ‘official’ GPS antenna somewhere. To minimise errors, I placed the Jupiter into 4800 bps NMEA mode (pin 7 GND and pin 8 HIGH), and connected the GPS antenna to the Jupiter. Within a few minutes I could read the UTC time from the NMEA output. A few minutes later the receiver had a fix.

The relevant lines in my ntp.conf are:

#NMEA 4800 bps on ttyS0 (falling edge PPS, flag2 1)
server 127.127.20.0 minpoll 4 prefer
fudge 127.127.20.0 stratum 0 flag2 1 flag3 1 refid GPPS

#ATOM (falling edge, flag2 1 )
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag2 1 flag3 1 stratum 0 refid PPS

After six hours:

remco@helium [/home/remco]> ntpq -p

remote            refid   st t when poll reach   delay   offset  jitter
=======================================================================
+GPS_NMEA(0)      .GPPS.   0 l   11   16  377    0.000    0.008   0.001

oPPS(0)           .PPS.    0 l   10   16  377    0.000    0.006   0.002

I could not run ntpd with the Jupiter in ‘Zodiac mode’ because I receive errors in clockstats:

54513 26640.110 127.127.31.0 unknown message id 1003
54513 26640.310 127.127.31.0 pulse: jupiter_parse_t: Unknown gweek
54513 26640.874 127.127.31.0 gpos: Navigation solution not valid
54513 26640.982 127.127.31.0 unknown message id 1002

However, driver31 is not patched for LinuxPPS yet. Unfortunately I am more into hardware and did not succeed patching refclock_jupiter.c without gcc errors ; -(

You can monitor ntp.remco.org (helium) if you like : -)

As many of you know, I run an ‘open access’ stratum 1 NTP server (ntp.remco.org) for almost four years now.
In fact, ntp6.remco.org is one of the few open access IPv6 NTP servers worldwide. During this period ntpd was disciplined with a DCF77 radio module, keeping the time within a few milliseconds of CET/UTC.

One of the problems I encountered was that Linux lacked a for me understandable PPSAPI, and still has no easy nano kernel implementation. Recently Rodolfo Giometti started writing a PPS implementation for the Linux kernel. He wants it to be inserted into the 2.6 kernel officially. For now patching existing kernels and software is the only way to go. His wiki tempted me to ‘try this at home’. Richard PA7FA, donated a few CIROCOMM G100/300 GPS-receivers and found out that besides 4800 bps NMEA, also a PPS signal was present. I mailed CIROCOMM for the datasheet of this OEM module, but I still heard nothing from them. Therefore I don’t know the accuracy and/or usability of the PPS signal.
The GPS module is fed by the USB port (+5V) and the 4800 bps NMEA data is inverted with a transistor and fed to pin2 of the DB9 of ttyS0 while the PPS signal (active positive) is fed directly into pin1 of the -same- serial port. Thus, no ‘level’ converters are required as both pin1 (DCD) and 2 (RxD) are inputs. The modern 16550A-chipsets have no problems detecting TTL input levels. This picture shows the first VERY experimental setup.
Traffic on the serial port can be monitored with minicom -s and/or cat /dev/ttyS0:

remco@helium [/home/remco]> cat /dev/ttyS0
$GPRMC,083057.198,A,5314.6975,N,00510.7342,E,0.00,,140208,,,A*71
$GPVTG,,T,,M,0.00,N,0.0,K,A*13
$GPGGA,083058.198,5314.6975,N,00510.7342,E,1,08,1.0,48.2,M,,,,0000*39
$GPRMC,083058.198,A,5314.6975,N,00510.7342,E,0.00,,140208,,,A*7E
remco@helium [/home/remco]>

I encountered some difficulties getting the LinuxPPS contrapsion to work. I will submit these difficulties to the LinuxPPS mailinglist soon.
Anyway, after some hacking I received the desired ‘o’ from ntpd:

remco@helium [/home/remco]> ntpq -p remco.org
remote refid st t when poll reach delay offset jitter
=======================================================
+GPS_NMEA(0) .GPS. 1 l 22 16 377 0.000 0.060 0.336
oPPS(0) .PPS. 0 l 5 16 377 0.000 -0.177 0.550
remco@helium [/home/remco]>

Initially I did not understand from Rodolfo’s wiki that the patched NMEA driver also handles PPS requests. Therefore I configured ntpd for the ATOM driver (driver 22) too. Below are some significant ntp.conf lines:

#NMEA 4800 bps on ttyS0
server 127.127.20.0 minpoll 4 prefer
fudge 127.127.20.0 stratum 1 flag2 0 flag3 0 refid GPS

#ATOM __| |___ (rising edge, flag2 0)
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag2 0 flag3 1 stratum 0 refid PPS

I learned from Philip that the (patched) NMEA driver handles PPS too (flag3 1).
I will experiment with these several setups, i.e. NMEA + seperate PPS, NMEA + PPS and DCF with separate PPS, e.g.:

#NMEA 4800 bps on ttyS0 and use PPS (flag3 1)
server 127.127.20.0 minpoll 4
fudge 127.127.20.0 stratum 15 flag2 0 flag3 1 refid GPPS

#ATOM __| |___ (rising edge, flag2 0 )
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag2 0 flag3 1 stratum 0 refid PPS+

#SHMPPS (falling edge) shm_splc2 -d /dev/ttyS0 -s -l DCD -u 0 -c
server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 flag3 1 refid PPS-

#PARSE Conrad RAW DCF77 (mode 5) no PPS
server 127.127.8.1 mode 5 minpoll 4
fudge 127.127.8.1 time1 0.0 flag2 0 flag3 0 stratum 14 refid DCF

You can track my experiments at ntp.remco.org.

OK, here is the picture: the CQWW 160m contest and my recent experiments with K9AY-loops, of which Gary K9AY (also active during the contest!!) himself wrote:

“The changes are good ideas. I also stopped using an autotransformer and do not use the +/-/AC control voltage. When I added a 3-relay termination adjustment, separate control wires were required, and I also put the direction control on that cable. This allows me to use a preamp that is powered via the coax. There will be a product review in QST soon, describing the Array Solutions product that uses my design. The information on RF chokes is very useful. I have seen the power supply problem before, but it is usually fixed with a good EMI filter on the AC input. However, in the past, I have needed a larger RFC as PG0A has discovered. With DC control voltage, this is not a problem, and I typically use a 220 uH RFC. 73, Gary K9AY”

Richard PA7FA and Remco PG0A wanted to test their 160m setup, strategy, and ideas during this contest. That is, not fully participate, but experiment, and see how we can learn. Our goal was to beat Dutch stations in pile-ups, and to ‘DX’, i.e. to work DXCC countries and experience the propagation during a fully saturated band. Nice aspect is that you can sleep during the day ; -)

We prepared the following (Google Maps overview here) setup (click on the picture to enlarge the shack ; -) :

- inverted L TX-antenna with a few radials, and 10000 sq. m. of aluminium greenhouses
- 250m US Beverage, made of welding wire, 4 bamboo sticks, a tree at the other end, and stretched with a bucket of stones.
- K9AY-loops
- ICOM PW-1 amplifier
- ICOM IC-756 pro 3 (I think .. ; -)
- N1MM logging software
- headphone (<- mandatory!!)

The setup functioned very well and we think we were the first Dutch station that evening to work into the US (VY2KM not included ; -) with K1LZ @ 22.21 UTC. Our ‘competitor’ PC5M logged their first US station for that evening (W2YE) @ 23.34 UTC, one hour later (!)

Experiencing this contest, I think it must be possible to work your 160m DXCC within one weekend.
Nice contacts were MD4K, UP0L, T77C, OH0Z, CU8A, CT9M, 4Z4DX, EA9EU, ER5GB, TF4M, 7X0RY, CN2R, C4M, VP9I, KP2M, TA3D, and XE2S.
Statesside we worked about 50 stations including K9AY himself. (Sorry Gary, you were louder on the Beverage ; -)
HK1X and C6ANM were actually the only two stations heard that couldn’t be worked before I fell asleep @ 02.30 UTC.
We did not hear Japanese stations that evening but worked JT1CO (!) easily.

The next evening we gathered a few new ones like 4L2M, JH4UYB (!), IS0OMH, a lot of EU and some new US stations.
Our score will not be high but N1MM showed 204/27/63, i.e. 204 contacts, 27 ?? and 63 mulitpliers??, resulting in a 116820 points claim.

We considered the experiments to be very promising and perhaps we will participate in the 160m SSB contest too.

9:1 transformer
During my preparations for the PACC contest I made some K9AY loops. It is generally recognized that galvanic separation of the loops and the receiving system is highly recommended to decrease interference, noise, and other strange phenomena. The original K9AY design used an 9:1 autotransformer, and voltages to switch the two relays are fed through the coax. Both on the internet and in ON4UN’s Low-band DXing book, usage of a galvanic separated 9:1 transformer seems to coincide with the loss of the initial, and elegant solution to switch the relays via the coax cable.

Noise/interference from the control box
Reported noise/interference when positioning the controlbox in the ‘NW’ position may be the reason for this. In this position an AC voltage is superimposed on the coax instead of a DC voltage. What actually occurs, is that the mains power supply (220V here), with a lot of ’superimposed’ interference from connected equipment, is almost directly ‘transformed’ into the receiver when the switch is in the NW position (!) In the SE (+V) and SW (-V) positions rectification with subsequent derippling shortcuts this mains power interference.

I also experienced an increase in noise/interference with the switch in NW position initially, but as far as I could ascertain it disappeared when using the ideas below.

AC/DC blocking choke in control box
I think that the inductance of the original choke (in the original K9AY-article 100 μH) is insufficient for the range 0.5 - 3.5 MHz. In my control box I use a 22 mH (Farnell) choke I had ‘in stock’. Its reactance @ 1.8 MHz (XL = 2*pi*1.8E6*22E-3 = 250 kΩ) is of insignificant influence compared to the original 100 μH choke (which reactance is -of course- 220 times lower).

PG0A’s Law: Listening is feeling
I think that a 1 mH choke will eliminate interference/noise most cases. However, I have not experimented with this. To assess the noise/interference, put your receiver into AM mode, dismount the coax towards the loops from the control box, and place the switch into the NW position. Compare it with the SE (+V), SW (-V), and NE (0V) positions. Besides some clicks (AGC effects due to the change of super imposed voltages which (dis)charge the DC-blocking capacitor in the control box) no (significant) increase of interference/noise may occur.
If you feel this is not the case (PG0A’s Law: listening is feeling ; -) increase the inductance of the choke significantly. With my 22 mH choke, all four positions (NE, NW, SE, and SW) sound equal. This was not the case when I used a 100 μH choke.

Another idea, which I haven’t tried yet, is to use a mains AC filter (e.g. from an old computer -switch mode- supply) in series with the power supply transformer.

LEDs on the switch box
Experiences from last year, while building and testing the loops, urged to have some kind of indication which of, and in what direction, the loops are pointing or to assess ‘remotely’ if anything switches at all. So, I replaced the (rectifying) diodes with LEDs, assuming that the relays draw between 15 - 25 mA of current (well.. they do and so do yours ; -).
By the way, I use DPDT 5V relays to compensate loss of voltage when using large lengths of coax as the loops have to be placed far away from the TX-antenna. And.. I have some ideas to create more than four states on a single coax to switch the Rterm value too in order to ‘optimise’ the nulls.

Pictures!
Below you’ll find the schematic diagram. I also made detailed pictures of the contrapsion, controlbox, switchbox-v1, and switchbox-v2. The difference between v1 and v2 of the switchbox, besides the Rterm switch, is the transformer used.
Switchbox v1 used a toroid and v2 uses a binocular version with teflon isolated wire.

Control box
I have been asked to publish the diagram of the control box. My implementation, depicted below, is identical to the original K9AY version except that the ‘AC/DC’ blocking choke is 22 mH, and I don’t like fuses.

Rocket science?
My initial feelings concerning the aforementioned were that it was not ‘rocket science’ but ‘handy’.
However, my ex-collegue, friend and 160m guru Kees PA0CLN was really surprised with my LED ‘invention’.
“You really should inform Gary about this”, he said. I told him about the galvanically separated transformer, the enormous loss of interference, the single coax solution, and that everything really worked well and so on.
“But how to you feed the relays via the coax cable then?”, he asked.
I promised him to mail him my contrapsion but I thought it would be a nice idea to publish it here : -)

Does it work for you?
Please find out if the above is reproducable, and leave your feedback here.

This week I upgraded my firewall and, inherently, this site Rembl.org. The old site was running on Wordpress 2.0 and an AMD K6-2/300 with 96 MB memory and 4 GB harddisk. I bought a surplus Compaq Evo D500 - P4 1.7 GHz with 512 MB memory and 20 GB harddisk from www.2dehands.nl for a nice price and upgraded to Wordpress 2.3.
For further details see phpsysinfo and below you see a picture of this machine.

Jurgen PE1LWT (see right, click on picture to enlarge), bought a second AM6154 for me in Friedrichshaven last June. It looked like a virgin and the first challenge was to power it up. The first result was that we did not experience a big bang with corresponding flashes, also not after powering up the 2.4 kV plate voltage. Because this amplifier was originally designed for aeronautical AM (amplitude modulation), the amplifier was immediately set in ‘idle’ mode.
While approaching the amplifier, we saw that the plate current was ‘ticking’ as well as the screen voltage. We first thought it was the electrolytic capacitor in the screen power supply. It turned out that the screen (G2) glass overvoltage protector was arcing. My philosophy is, remove as much protective devices as possible because they cause and create more damage than they protect!
So we did.The amplifier was left into idle mode during a coffee break and my cat jumped on it, almost got electrocuted because his tail was hanging in the high voltage power supply. Besides the activity of the cat, we did not hear strange noises, nor could we smell strange odours from the amplifier.

So, the next step would be to apply some drive. We applied a little drive to the amplifier, tuned it and soon measured 100W output.

After tweaking and tuning we reached 300W with almost 12W (!) of drive (see right, click on picture to enlarge). We expected a bit more output, but, we left the amplifier ‘key down’ at 300W during the evening. This resulted in a VERY HOT Spinner dummyload. But also it demonstrated that the amplifier was stable with this output and… it is a quick way to recondition a tube!

My other amplifier, with a GS-36B inserted, delivers almost 3 dB of output more. So, it was time to modify the amplifier and make it ‘contest ready’.

The input circuit was completely modified according to the FYM-tetrode match. Perhaps for reasons of (in)stability, but I cannot understand why the standard input circuit of the AM6154 is designed so inefficiently. After this and some other modifications, the amplifier delivered a stable 500W with 2.2W of drive power. A good backup amplifier for the contest!!