UPDATE 8 aug 2008: 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.2374)
server 127.127.8.0 mode 5
fudge 127.127.8.0 time1 0.2374 stratum 0 refid DCFa

#SHM driver (for use with radioclkd2)
server 127.127.28.0
fudge 127.127.28.0 time1 0.0282 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 DCFb (i.e. radioclkd2) revealed less jitter.

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 or ppsldisc /dev/ttyS1 & (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).

The PPS-option for the GENERIC parse driver is activated by creating a /dev/refclockpps-* symlink to /dev/pps*, e.g.
(sudo) ln -s /dev/pps1 /dev/refclockpps-1.

In /etc/ntp.conf the following lines were inserted:

#ATOM driver22, rising edge, flag2 0
server 127.127.22.1 minpoll 4 maxpoll 4
fudge 127.127.22.1 flag2 0 flag3 1 stratum 0 refid PPSa

#PARSE driver8 Conrad RAW DCF77 (time1 0.2374)
server 127.127.8.1 mode 133 prefer
fudge 127.127.8.1 time1 0.2374 flag1 0 time2 0.0282 flag2 0 flag3 1 stratum 0 refid DCFa

I determined the time1 value empirically and took the time2 value from the empirically determined offset for radioclkd2. Perhaps some tweaking is necessary, but I consider it to be a good 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.

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 ; -)

Back stage there was tasty food. We were facilitated by Smokey, Joe’s personal assistant, and we reckon Smokey will find a way to transport the tube into The States : -)

Fltr: Dick, PA2DW, Joe WB6ACU and Remco PG0A/PA3FYM.

Oh yes, I almost forgot. The concert was great, the sound sublime and good old times revived!

73, Joe & Smokey!

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)

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 !

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 : -)

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.

“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.

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.

Playing guitar myself, I was impressed by the completeness of their sound and espcially their techniques. I bought a CD from them and found out that the guitarist Carlos Vamos really is a virtuoso!

A promotion video of them can be found at YouTube.