Remco.org

Seductive serendipity / Verleidende serendipiteit

August 9th, 2016

MSF60 time signal synchronisation

In 2008 I wrote a short article on how to add ‘MSF’ to your NTPd refid list.

On June 23rd this year the majority of UK citizens chose in favour of a Brexit.
For European timekeepers this is the opportunity to lock to a standard outside Europe ; -)

MSF is a British VLF time signal, formerly known as the ‘Rugby Clock’.
As of April 1st 2007 the 60 kHz time code transmitter is located in Anthorn, England
and its official name became ‘The Time from NPL’  (click here to read more).

The relocation from Rugby to Anthorn had a side effect: the effective radiated
power (ERP) reduced 6dB, from 60 kW to 15 kW. Significant . . .

MSF operates in a similar way like DCF, albeit that (of course ; -) its time code format
differs (significantly). It transmits UTC with +1 hour offset during summertime and
lacks leapsecond alerts.
Note: UTC differs very slightly from GMT. GMT is not the international standard anymore.

Last year Udo uploaded a development version of his DCF77 library to Github.
Besides severe recoding and restructuring he also added ‘experimental’ MSF60 support
and requests people to test his code before releasing the next ‘formal’ library.

In order to contribute to Udo’s library -by testing it- I modified a DCF77 receiver
for 60 kHz reception, just like I did in 2008 (see above). At that time I experienced
severe reception issues and therefore discarded MSF synchronisation.

However, around 8 years later, using the dcf77 noise resilient library may be more proof
of the pudding than only eating DCF frames from Mainflingen ; -)

Distances from my location to Anthorn and Mainflingen are ca. 625 and 360 km respectively.
Taking ERP’s (MSF 15 kW, DCF 35 kW) into account, MSF must have around 5 dB (~ 3x)
lower field strength than DCF.

After modifying the DCF receiver to 60 kHz and tuning the ferrite rod antenna I got clean
second beats in my shack. However, in my computer room LOTS of spikes appeared on the output signal.
To receive ‘optical’ proper LED time stamps I had to place the receiver near a window.

Some fiddling in my code was necessary to let it work with the experimental
library in MSF mode. The first successful MSF lock took around 12 minutes.

Perhaps the internal local oscillator frequency offset -stored in eeprom- had to redetermined,
although I can hardly believe this? Anyway, after this first lock the contraption syncs to
a clean MSF signal within ca. 5 minutes.

Of course MORE proof of the pudding is to check if my clock locks in severe conditions.

Below two extracts from the DCF Scope sketch are displayed. Top: worst case, below: ‘in front of window’ signal.

12, +-2XX8----+--1XX9---+6X7------+---------+---------+----2XXXXXXX5--2XX6+------1XXX2--------7------7XX
13, XXX2------+2XXXX4---+-----5XX5+---------+-----XX-3XXX2---3--+---------+----1X---+------6X5+-----7X2X
14, X13-------+--4X8----+--------2X---7XX1-2XX6---91--+-6X4-----+----X3-7X3----26---+-X2--XXXX+X364----8
15, 3---------89---X494-+-18---7X6+48---61--+X7-------+49----X8-+---73----42--8X6---4XX6------+---------
16, +-----8X2-97----1X3-8764------+--7XX----+--7X3----+--------6X474------2X9--8X3--+2XX1---54+----57---
17, +-------4X5--66-----+-8XX2-XX-+-----95-1XX292-----+--------33----27---+----8XX2-+--6---5X9+---------
18, +14-------+-----66--7548518X--+-----3X--+---------+--------X834--7XX1-+-84X4--44+17654----+----6----
19, +-87------+34-14----+------6XXX8--5825--+8XX2-----12--------58-----18-+---17-2X5+---------+-------2X
20, X--684----+4XX2-----27--36----+---------+---934---+----9XXX-+-668X8X192--------42XX2-----46-----6X95

Figure 1. DCF Scope result of very distorted MSF ticks. Receiver positioned near interfering equipment.

 

12, +----8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9-----+---------+---------+---------+---------
13, +-----5XXXXXXXX4----+---------+---------+---------+---------+---------+---------+---------+---------
14, +----6XXXXXXXXXX2---+---------+---------+---------+---------+---------+---------+---------+---------
15, +----8XXXXXXXXXX4---+---------+---------+---------+---------+---------+---------+---------+---------
16, +----8XXXXXXXXXX3---+---------+---------+---------+---------+---------+---------+---------+---------
17, +----9XXXXXXXXXX2---+---------+---------+---------+---------+---------+---------+---------+---------
18, +----9XXXXXXXXXX3---+---------+---------+---------+---------+---------+---------+---------+---------
19, +----9XXXXXXXXXX3---+---------+---------+---------+---------+---------+---------+---------+---------
20, +----9XXXXXXXXXX3---+---------+---------+---------+---------+---------+---------+---------+---------
21, +----9XXXXXXXXXX4---+----4XXXXXXXXXX----+---------+---------+---------+---------+---------+---------
22, +----7XXXXXXXXXX1---+----3XXXXXXXXX7----+---------+---------+---------+---------+---------+---------

Figure 2. Clean DCF Scope output of my MSF receiver, positioned near a window.

The signal from figure 2 results in a MSF lock after ca. 5 minutes.
Believe it or not, but the ‘signal’ from figure 1 resulted in a lock after around 40 minutes.
‘Normal’ MSF/DCF receivers would be useless in figure 1 conditions. However, Udo’s library does a magnificent job!

The MSF receiver now serves as NTPD reference clock for an experimental NTP  server.

Current running sketch is here.

 

August 2nd, 2016

Arduino Meinberg PZF5xx NTP time standard

Abstract
A Meinberg PZF5xx NTP time standard is simulated with an Arduino
in conjunction with a cheap DCF77 receiver module to produce surprisingly
accurate internet independent time stamps.

A priori
In this post I elaborated on Udo’s magnificent work concerning decoding
DCF77 time stamps in noisy/suboptimal environments. Please read this first.

Introduction
Last month I was in Germany /P at a camping site and decided for some JT65 on 40m.
Naively I started WSJT-X but soon discovered my laptop clock was way off time.

Believe it or not, I was in a situation with no internet access, nor 3G/4G. Now what?

Being in the process of building a DCF synced clock with large 7-segment displays
for the camper, my DCF clock had to be enriched with a reference clock option
for internet independent NTP time synchronisation. Yes, DCF not GPS.

Unfortunately most modern computers only have one type of hardware interface, USB.
This excludes e.g. connecting simple DCF77 receivers to a serial (RS232) port.
I remembered Udo published a Meinberg emulation sketch, so I digged further into this.

Reference clock
I added Udo’s Meinberg code to my sketch and after some fiddling I was able to
see the refclock in NTPD under Linux. Having experimented with DCF77 modules
a lot in the past, I was disappointed about the reported jitter.

Offset was/is not the issue, it can be tweaked with the fudge factor ‘time1′ in ntp.conf.
With DCF NTP refclocks this time1 fudge factor is normal because propagation delay
of the DCF transmitter in Mainflingen, Germany has to be compensated, as well as
latency of the hardware interface (RS232, USB).

Taking PLL options inside my clock sketch into account, I could hardly believe
the reported jitter. Did I overlook something?

Meinberg clocks output UTC epoch synced PPS with a datagram (‘describing string’).
The PPS creates NTP clock accuracy and the string clock Time (with a capital T).

Although my sketch -based on the dcf77.h library of Udo- has the option to output
a synced PPS, this PPS can’t be interfaced (directly/easily) with USB. Now what?

Reading more information on NTPD parse refclocks, it seems that Udo chose the
‘first’ option for his Meinberg emulator, i.e. ‘mode 2′.

In ‘mode 2′ there seems no relation between the (timing of the) datagram and UTC epochs.
When the datagram heeds the ‘University of Erlangen’ syntax, its burst
is assumed to be synchronised to UTC more precisely, i.e. ‘mode 0′ or ‘mode 1′ :

“The DCF77 PZF5xx variants provide higher accuracy and have a
pretty good relationship between RS232 time code and the PPS signal.”


Meinberg PZF511

Error/jitter relates to the datagram bitrate. For 9600 bits/s this amounts 1/9600 = 104 us.
This is also coded in the ntpd/refclock_parse.c source (download NTP source here) :

/*
* Meinberg DCF PZF535/TCXO (FM/PZF) receiver
*/
#define DCFPZF535_ROOTDELAY     0.0
#define DCFPZF535_BASEDELAY     0.001968  /* 1.968ms +- 104us (oscilloscope) – relative to start (end of STX) */
#define DCFPZF535_DESCRIPTION   “Meinberg DCF PZF 535/509 / TCXO”

In other words, fooling NTPD that my PLL locked Arduino is a Meinberg PZF5xx
should improve performance significantly?

Performance
I coded the ‘Uni Erlangen’ syntax in my sketch.
Despite lacking a ‘hard’ PPS, performance after convergence is suprisingly good.

Although I didn’t pay too much attention on timing issues inside the code,
it’s the best DCF NTP refclock I ever had!

Relevant ntp.conf entry for this refclock (Note: /dev/refclock-0 is linked to /dev/ttyUSB0) :

#PARSE clock for Meinberg , normal AM clock = mode 2, PZF5xx = mode 0 or 1
server 127.127.8.0 mode 0
fudge 127.127.8.0 time1 0.0277 stratum 0 refid DCFm

Note: fudge factor time1 here is 27.7 ms and I chose the TCXO version (mode 0)

[/home/user@li]> ntpq -p
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GENERIC(0)      .DCFm.      0 l    9   64  377    0.000    0.291   0.070
+aardbei         .GPS.       1 u   47   64  377    0.698   -0.211   0.183
+ntp.nmi.nl      .PPS.       1 u    7   64  377   19.924   -1.240   0.203

[/home/user]> ntpdc -nc kern
pll offset:           -1.128e-05 s
pll frequency:        21.402 ppm
maximum error:        0.000749 s
estimated error:      0.000133 s
status:               2001  pll nano
pll time constant:    6
precision:            1e-09 s
frequency tolerance:  500 ppm

Relying on the quality of the dcf77.h library there may be room for further improvement.

More experiments
From the original perspective the above information is somewhat ‘cheating’.
NTPD is configured as connected to the internet with several active remote NTP servers.

To simulate a real standalone situation, i.e. no internet connection, I rebooted my
computer and started ntpd with only one refclock entry in /etc/ntp.conf:

#PARSE clock for Arduino/fake Meinberg PZF5xx –> mode 0
server 127.127.8.0 mode 0
fudge 127.127.8.0 time1 0.0259  stratum 0 refid DCFp #DCFp because refclock is phase locked : -)

During the reboot process ntpd was started with ntpd -I lo -I eth0 to peek into this
‘standalone’ running ntpd from another machine to compare its performance with other NTP servers.
The ‘-I’ options are necessary because ntpd does not open e.g. the eth0 interface when no remote
(internet) time servers are configured in /etc/ntp.conf.

While (re)booting I fetched a cup of coffee, fed my cats, and returned after 15 minutes.

At my location the Arduino takes around six minutes for a DCF lock, after which it produces timestamps.

Ntpq -p delivered the following output:

[/home/user@li]> ntpq -p
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GENERIC(0)      .DCFp.      0 l   39   64  377    0.000    0.003   0.014

Although the above result may be considered Kafkaesque, it’s suspiciously good : -)

Subsequent queries gave often offsets in the usec range and jitters < 200 usec. Very good.

In order to peek into this Kafkaesque situation I queried this NTPD instance from a remote
machine on my LAN (remember, I started ntpd with the options -I lo and -I eth0):

[/home/user@he]> ntpq -p
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*lithium .DCFp.      1 u   64   64  377    0.309   -0.332   0.084
+aardbei .GPS.       1 u   41   64  377    0.615    2.048   0.199
+ntp.nmi.nl      .PPS.       1 u   29   64  377   19.643   -0.123  0.362
-ntp3.vniiftri.r .MRS.       1 u   17   64  377   70.189    3.363  0.652

Aardbei‘ is my very popular Motorola Oncore GPS disciplined NTP server ntp.remco.org and has
a local accuracy and jitter of a few micro seconds:

[/home/user@li]> ntpq -p aardbei
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_ONCORE(0)   .GPS.       0 l    5   16  377    0.000    0.000   0.002
+2001:610:1:80be .PPS.       1 u   12   64  377   18.528   -2.012   0.172
+ntp.nmi.nl      .PPS.       1 u   31   64  377   20.002   -2.147   0.357
*ntp1.nl.uu.net  .PPS.       1 u   93   64  376   18.475   -2.040   0.368

Lithium‘ is the ntpd instance running ‘standalone’ with the DCF disciplined Arduino/fake Meinberg PZF5xx.
Other entries are remote benchmarks.

After some monitoring I discovered that lithium (DCF locked) and aardbei (GPS locked) were
competitive stratum 1 servers (from heliums perspective) !

I reckon when the Arduino interfaced to a real RS232 interface (using DCD for the PPSAPI)
may outperform a real DCF based Meinberg !
Edit: I did some early experiments with PPS (atom driver 22) and indeed, this looks promising ; -)

Anyway, for the time being it’s fine for me. The fake Meinberg will not be used as a reference for a
NTP server but only to sync my laptop (which also has to run NTPD then) for weak signal usage.

The current active Meinberg refclock sketch can be downloaded here.

 

June 3rd, 2016

Es’hail2 dual band dish feed

A priori: click on images to enlarge in new tabs.

Introduction
In Q1 2017 the Qatar Es’hail Satellite 2 (Es’hail2) is scheduled for launch and
will carry a 2.4 GHz receiver for amateur usage. The geostationary position is 25.5E.

My concept will be a single dish with dual band feed. Actually it will be a
2.4 GHz LHCP feed together with an X/Ku-band PLL LNB.

Standard/cheap broadcast dishes own a f/D around 0.6, so popular patch
antennas will over illuminate the dish, resulting in less overall efficiency.

The -10 dB opening angle of the feed should be around 80 degrees.

I read somewhere (don’t know where) that the amount of turns (N) should be N * 0.1 f/D.
Since my dish f/D = 0.6 I built a 6 turn 2400 MHz helix (v0.1) according to information
from the web. This helix was made with enameled 2 mm diam copper wire.

For whatever reason I couldn’t get a proper match, i.e. a match with return loss >30 dB@2400 MHz.

Time to model the helix to estimate interdependancy and weighting factors of
design parameters relative to e.g. gain, radiation pattern and axial ratio.

Modelling
Information + pictures to be presented soon. For the time being: below a gif which Van Gogh should envy ; -)
It’s the calculated axial ratio of helix v0.2, i.e. the difference between RHCP and LHCP (click to enlarge).


Difference in RHCP and LHCP gain of modelled v0.2 helix.

Practical design
Below some pictures of two helices recently made for this project. The first one (v0.1) was made with
enameled 2 mm diam copper wire according to ‘helix calculators’.

Initially I attributed the non optimal match to the position of the feedpoint due to mechanical
restraints. E.g. the ‘extra’ wire (‘not part of the helix’) acts as impedance transformer.

No matter what 1/4λ stub (length, impedance) I tried, measured return loss around 2400 MHz remained
suboptimal. I.e.  in the 15 – 20 dB range, while dips occured around 2350 and 2500 MHz but not 2400 MHz.
(generally builders/designers are satisfied with 15 – 20 dB return loss . . . I’m not . . . )

Anyway, v0.1 served very well as a template for the feed mechanics.

Below some pictures of prototype v0.1 (right picture a 60cm diam test dish). (click to enlarge)

Today I made a new helix (v0.2) with ‘drilled’ 2mm diam plain copper wire according to my simulations.
I suspect the enamel around the wire of v0.1 might have significant influence on 2.4 GHz,
perhaps due to skin effects or whatever.

v0.2 diameter is somewhat larger compared to v0.1, viz. 46mm vs. 42mm, but has the same pitch (27mm).

The helix is matched to 50Ω with a delibarate too broad 1/4λ long copperfoil ‘transmission line’.
After some fiddling I obtained a perfect match (RL =48 dB !!) around 2400 MHz. That’s much better!

Radiation patterns of antennas are more predictable and ‘pure’ when they are terminated
with the proper/calculated impedance. It’s reciprocal.

Identical to a transmitter which has to be terminated with the proper impedance for maximum energy transfer,
an antenna must be terminated properly to convert inserted RF-current into the wanted radiation pattern.
In other words, life is much easier and predictable when both impedances ‘match’ ; -)

Inserting my LNB in the helix current maximum detoriorated the return loss with ca. 10 dB and
the sharp dip increased somewhat in frequency. Anyway, looks promising and it needs some
fiddling to get everything perfect on 2400 MHz in front of a dish : -)

Below some pictures of v0.2 (click to enlarge).

 

June 1st, 2016

First EU decode of VK9WI balloon!

Receiving really weak signals on shortwave remains a challenge and is far from trivial,
especially in noisy Europe.

This year I was one of the few -and sometimes the only- northern hemisphere
station able to receive some picospace.net balloons, floating above/on the southern hemisphere.

To my astonishment I decoded PS-65, aka VK9WI, this night !

2016-06-01 00:30 VK9WI 10.140257 -25 1 CD07 0.5 PA3FYM2 JO22nf 17608 76

Looking into the wsprnet.org database this is the first (and only) European decode since its launch!

Below a map of stations who received VK9WI in the last 24 hours (click to enlarge).

The receiver used is homebrew (description here) and antenna is a 100m long ‘bent’ open Beverage.

 

May 29th, 2016

Rescue the ZL1SIX floater!

A priori: click on images to enlarge in new tabs.

Introduction
A while ago I seemed to be one of the few, if not the only, Europeans able
to receive 30m WSPR traces of high altitude balloons (HABs) launched in Australia
while floating in/on the southern hemisphere.

One of the avid balloon hunters was -and still is- Bob ZL1RS. At the end of last year
Bob created his own project: the 30m ocean floater. <– please read this.

Bob’s ocean floater was released around May 15th into the Pacific ocean.
Estimated lifetime of this buoy is around 6 – 9 months. The first two weeks ZL1SIX
transmitted its information every hour with accurate timing.

WSPR traces were sent at XX:46:00, followed by two JT9 transmission at XX:48:00 and XX:49:00.
The first JT9 frame contains call (ZL1SIX) and the current six digit Maidenhead locator,
the second JT9 frame contains telemetry: battery voltage and (water) temperature.

However . . . despite extensive testing ashore, as of May 29th it seems that Bob’s PICAXE power saving
software inside the buoy contains a timing bug. ZL1SIX (now) transmits its packets around 10 seconds too early!

The result is ‘normal’ WSPR setups are not able to decode its WSPR & JT9 traces, leaving Bob ZL1RS
and Joe VK5EI the only ones able to receive the floater because they fiddled with their computer timings.

Challenge
To help Bob receiving his buoy (if succesfull) I built up my WSPR & JT9
30m receiving station with Beverage in the quiet nearby woods. The buoy has ca. 100 mW output and
floats in warm salt water, a perfect take off! I reckon it must be possible to receive it in Europe.

However . . . the issue is (read: was) the timing!
As WSPR time client I use rsNTP from Wolf DL4YHF, well known from his Spectrum Lab software.
His NTP client has a feature to deliberately add or substract a timing offset.

This afternoon I mailed Wolf with an unusual rsNTP software request because I also want to compete
in the WSPR Challenge. My request was: rsNTP adds 10 seconds to ‘time’ in the 45th minute of
the hour and eliminates this addition at the end of the 49th minute, to be able to get the ‘normal’ 50th
WSPR time frame properly.

Wolf responded quickly to my mail and was willing to add my weird feature.
Within a few hours Wolf mailed me to download his modified client.

Wolf rewarded my request with an ‘Options’ button and the latest version of his
rsNTP client can be downloaded here.

Before (re)installing this version of rsNTP, please read this first! (please do)

I was the first to download his amended client and it seems to work, see below.

My suggested time offset values are already entered in the defaults.

After the last (current) ZL1SIX JT9 cycle rsNTP corrects ‘time’, as can be seen below in the
time stamps in the WSPR waterfall.

Result
Everybody with a (Windows) WSPR setup now may be able
to receive ZL1SIX properly as far as timing is concerned.

Note: between XX:45:00 and XX:49:55 (-10 sec ; -) you won’t be able to
decode ‘normal’ WSPR / JT9 traces.

But what the heck, it’s for a good cause!

A big thank you to Wolf DL4YHF, true HAM spirit!

And for now . . . fingers crossed if more people are able to decode ZL1SIX . . .

Update (see below):
Bob ZL1RS managed to decode his floater with the modified rsNTP @2246 UTC : -)

April 26th, 2016

FYMAS, MAS QRP contest

A priori: click on images to enlarge in new tabs.

Introduction.
This month I arrived at the QRPcc website by accident.
FYM and QRP?? Well, QRP is not my main thing but this QRP club
organizes contests on Ascension Day since 2000.

Charm and challenge of this contest is to use self built QRP equipment with
minimal components. The less components you have, the more points per QSO you get.

In other words, less is more ; -)

Because I attend the Jutberg, enjoy home brewing and contesting this
MAS contest seems a nice exercise at the end of this years Ascension Day.

Plan is to participate in ‘Class B’, only 40m with a FCP vertical,
using N1MM with my Arduino keyer.

Note: nowhere is stated that ‘QRP’ has to be done with a straight key!

Equipment.
Here you can see some pictures and circuit diagrams of equipment from
participants over the last years.

The MAS contest seems ‘hauptsächlich eine Deutsche Sache’.

So, my aim is to change this a little bit ; -)

Googling on various circuit diagrams for QRP equipment I felt that my entry
had to deliver something new. So . . . I started drawing some circuit diagrams
of minimalistic 40m transmitters -made of junk parts- in my mind.

I excluded tubes, so my 40m transmitter had to be made of transistors and/or FETs.

Circuit diagram.
A Hartley oscillator is one of the most minimalistic designs, it reduces to two components.
I built a Hartley with a small FET. It works, but the frequency stability is horrible.
Peter PA3EXL was so kind to lend me a 7030 kHz crystal, which I used to discipline the Hartley.

My initial idea was to build a Hartley power oscillator with an IRF510 or something.
However, these FETs need biasing to oscillate, which means extra components.
I considered a Pierce oscillator as alternative. Also in this case the IRF needs biasing.

So, I went back to my original idea: crystal disciplined Hartley with amplifier.

After some fiddling, trying to minimize the amount of components, the following
circuit diagram crystallized, named FYMAS (see figure 1 below).

Figure 1. FYMAS, 40m QRP transmitter for 2016 MAS contest.

The oscillator coil (2) is wound around a wooden 28mm diam rod. A hole is drilled in the
centre of this rod to accomodate an adjustable ferrite rod to tweak the frequency a little.
According to the MAS rules such ferrite rod is part of the coil, so it eliminates a capacitor : -)

Unloaded output is a beautiful sine wave with 4Vpp, measured on my oscilloscope.

Unfortunately I got bad results interfacing the oscillator electrically to the gate of the IRF510 (7) .
It was my intention to ‘auto bias’ the FET. It worked a little but revealed low output.

Therefore two additional components (5 and 6) were inevitable to achieve around
2W output @13.8V after some tweaking with 4 and 6.
The IRF510 simply doesn’t receive enough drive to switch ‘firmly’.

More output is possible by raising the power voltage, but I’ll bring only one power supply
at the Jutberg. So, considering the circumstances 2W has to be enough.

Matching circuit.
MAS rules (2016) state (quote):

“Any selective network in the TX output stage will be assumed and counted as a
3 parts PI filter. For a better suppression of harmonics you are free to use
more components – they will not be counted.”

The key word here is ‘any’. Read on . . .

Below my matching circuit is depicted.
Match from RL = 15 + j0 Ω (assuming ca. 5W output) to 50 + j0 Ω @ 7 MHz.

Of course a good match can be obtained by halving the ‘last’ parallel capacitor.
Interpreting the MAS contest rules I deliberately chose NOT to do this.
The last capacitor is intentionally too big. By adding a parallel coil (ca 1.2 uH)
you go ‘back’ in the Smith chart, making this coil part of my selective network.

‘Cold’ side of the coil is connected to +13.8V, requiring a capacitor to make this side low Z.
The capacitor is not included in the above picture but . . .  is a mandatory part of the matching circuit !

So . . . my parts to power the IRF510 don’t count! If they will, the MAS rules have to be changed.

Note: the consequence of my reasoning is also losing a DC blocking capacitor at the output.
This capacitor is not part of a ‘selective network’. Because I will use an ‘open’ antenna, this isn’t an issue.

FYMAS keying.
Initially I wanted to key the transmitter by shortening the oscillator coil tap to ground
to (try to) prevent chirps.

This works with a screw driver, in a sense that the Hartley stops oscillating.
However, it seemed that the IRF510 (7) (see fig. 1 above) in my design was VERY willing to
oscillate around 1 MHz and on its turn was disciplined by the Hartley ; -)

Connecting the (open collector) key output of my keyer to the coil tap stopped the Hartley,
no matter if I keyed or not. Experiments using an ‘intermediate’ BS170 also failed.

Another method of keying the transmitter is to shortcut the IRF510 gate to ground.
This works, but doesn’t stop the Hartley from oscillating, which is unwanted during reception.

(Tip! For those who want to build a transceiver according to my design can benefit from
this by using the Hartley as local oscillator for e.g. a direct conversion receiver)

Also, keying has to be done in an inverted sense, i.e. ‘key open’ = TX.
Luckily my Arduino keyer owns an open collector inverted keying output : -)

Disconnecting the GND side of the coil (2, see fig. 1 above) with a relay (of course) stops the Hartley.
The other part of the DPDT relay is used as RX/TX antenna switch.
Btw, relays do NOT count as parts in the MAS contest.

How does it sound?
Pretty well, showing only a small ‘start up glitch’.

A recording of my signal received ca. 5km away can be heard in MP3 or OGG. Not bad eh ?

Finally, below a picture of the FYMAS, as used in MAS 2016, is depicted. (click to enlarge)

 

April 11th, 2016

Junkbox 10 and 27 MHz GPSDO for Es’hail2

A priori: Click on images to enlarge in new tabs.

Introduction.
Es’hailSat-2 launch is scheduled for 12 October this year. Look here.
It is planned to carry a first geostationary payload for amateur use in history!

However . . . the AMSAT contribution to this payload is (kept?) vague and
it’s a mystery to me what AMSAT hardware actually will be shot into space.

Es’hail2 is a commercial (broadcast) satellite. So . . . they have plenty of
Ku –> X band transponders and almost certainly also Ka –> K band transponders.

Uplinks for Ku –> X transponders are in the 12-14 GHz range, downlinks around 10 – 12 GHz.

So, it could be well that the AMSAT 3cm allocation (10.45 – 10.50 GHz) ‘bleeds through’
a lower transponder edge. This may suggest that the only ‘additional AMSAT payload’
may be a 2.4 GHz receiver with antenna. Baseband output (let’s say 10 MHz wide)  of the
2.4 GHz receiver may be upconverted to around 12 GHz, simulating a ‘normal’ earth uplink
which is linked down around 10.5 GHz. How to deal with AGC issues is not trivial.

The 10.5 GHz downlink is divided into two portions: 250 kHz narrow band and 8 MHz
‘wide’ band for DATV use or other amateur broadband application.

Anyway . . . the scheduled 250 kHz ‘narrow band’ transponder from grounds perspective is:

1. Uplink is centered around 2400.175 MHz. Polarisation RHCP and EIRP ca. 31 dBW.
2. Downlink is centered around 10489.675 MHz. Polarisation is LV and G/T ca. 13 dB/K

Thumbs up for the people who did the lobby, VERY fine job!

My quick & dirty idea for a 10.489 GHz downconverter involves a satellite PLL LNB.
These PLL LNB’s are cheap and own reasonable noise figures (NF) around 10.5 GHz,
which is somewhat below their target band around 10.7 – 11.7 GHz.

Although HDTV requires more stability, PLL’s inside these LNB’s are not stable enough
for narrow band (e.g. SSB) operation. However, there are solutions in order to significantly
improve LO-stability in these LNB’s to comply with narrow band usage.

One of these methods involves injection locking the PLL-reference signal into
the LNB. Most LNB’s use a 27 MHz (crystal) reference. So, the trick is to ‘overrule’
the built in oscillator with a more stable 27.000000 MHz signal.

Contrast to other AMSAT satellites, Es’hail2 will not contain doppler due to its
geostationary slot. Normally you would transmit a signal on the uplink frequency and
listen to the downlink with a separate receiver in order to determine doppler offsets
because the satellite is moving.

Now the satellite hangs at a given geostationary location (26° E) so it’s merely a
giant repeater with some delay and a gigantic repeater offset. ‘Shift’ is -8089.5 MHz (!)

This means when you’ve adequate frequency precision on earth, one transceiver suffices!

Because most uplink contraptions will be build with a block upconverter (aka BUC),
locking the upconverter LO to a frequency standard is pretty straight forward.

The downlink converter, i.e. the PLL LNB, has to be locked to the same frequency standard.

My idea is to build a ‘box’ with all necessary equipment inside, i.e.:

1. 432/144 MHz –> 2400 MHz upconverter (ca. 10 – 20W ‘at the feed’)
2. 10.489 GHz –> ? MHz downconverter
3. GPS disciplined oscillators (GPSDO) for 10 and 27 MHz.
4. Power supplies, switching stuff etc.

This box has to be placed near/under the (dual band, i.e. 2.4 GHz LHCP, 10.5 GHz VP) dish feed.
(Note: to achieve RHCP you need to build a LHCP dish feed!)

Approach.
10 MHz GPSDO’s have been extensively published (Google on it). The idea is to lock
the LNB 27 MHz reference oscillator to a 10 MHz GPSDO. Most LNB’s own LO’s at 9750 MHz.

This means that there is a 9750/27 = 361.1111 multiplication factor. Assuming the IF transceiver is
stable enough, to have e.g. 10 Hz frequency accuracy at 10.5 GHz, the LNB LO needs a precision
around 1E-9. This means the 27 MHz reference signal needs 1E-9 / 361 = ~ 1E-12 (!)

Whether I can reach 1E-12 precision with junkbox parts has to be found out.
The proof of the pudding is in the eating, so I scraped my junkbox and started building.

Below my initial circuit sketch is depicted.

The circuit above is a schoolbook PLL example. A GPS receiver provides a locked 10 kHz reference
to an XOR phase detector, followed by a loop filter controlling the 10 MHz TCXO phase/frequency.
TCXO output is levelled to TTL and divided by 100 (HC390) and 10 (4017) to deliver 10 kHz.

Of course two HC390′s could be used, but my junkbox revealed only one piece. The 4017 carry
output (pin12) is used to deliver a 50% duty cycle 10 kHz square wave.

Et voila . . . the loop is closed and (hopefully ; -) locked.

Next idea is to build a 27 MHz VCXO. Its output has to be levelled to TTL and subsequently
divided by 27 (= 16 + 8 + 2 + 1) to obtain 1 MHz. Division by 27 is done with a binary counter.
In the initial circuit sketch a 4024 was selected. However, I discovered my junkbox had more
4040′s than 4024′s. A 4020 or HC590 also works.

Although the resulting 1 MHz duty cycle will be (27-16)/27 = 40%, my initial approach
is to ‘stretch’ this to 50% by means of a D-flipflop which is clocked on the positive edge.

Side effect is that the 1 MHz signal is divided by 2 to deliver 500 kHz.
Therefore the 1 MHz signal point from the 10 MHz GPSDO passes through an identical D-flipflop.

Both 500 kHz signals are fed into an XOR phase detector, followed by a loop filter to provide
the necessary control voltage to discipline the 27 MHz crystal oscillator.

When 27 MHz VCXO lock yields nice results, discarding the two D-flipflops (74HC74)
adheres to a more minimalistic and junkbox approach ; -) Perhaps something to try later . . .

The PLL loop filter took quite some fiddling. The used TCXO can be slightly adjusted and its
VCO gain K (Hz/V) is relatively low. While experimenting, this meant l o o o ng locking times.
With patience I managed to get the loopfilter response and damping factor such that it seems ok.

I haven’t measured the 10 MHz signal on a spectrum analyser, so I haven’t the faintest clue on
phase noise and spurs. But.. what I certainly know, there is a spur around 10.140.000 Hz . . .
Very likely this spur is derived from the 10 kHz reference and super imposed on the 10 MHz signal.

From the left picture above it can be clearly seen that the 10 MHz TCXO is crying for discipline
after a cold start with no GPS fix. After the 10 kHz reference is locked to GPS the TCXO is disciplined.

The right picture above shows a cold start with a valid GPS almanac.

Next, build the 27 MHz oscillator and lock it to the GPSDO. More to come !

 

April 4th, 2016

Icom IC-402 repaired

A priori: Click on images in this post to enlarge in new tabs.

Introduction.
“Going back in time on the sound of the nation it’s a flash back back back … ”
Listen here to this popular jingle from the 70′s .

For whatever reason I’m in a repair mood lately. I got fed up looking at equipment
‘to be repaired’ but never did. Sometimes hobby is similar to work. You’ve to do
things which are dreadful. But these dreadful things have to be done by someone (me).

What is the issue. I own two IC-402′s of which one became defect around 7 years ago.

Say what? IC-402? Are you nuts? Well . . . yes and no. However, bear in mind these
old fashioned IC-402′s deliver our VHF/UHF/SHF contest team victories since >30 years.

First, let me post some pictures. Below left is a picture taken during the March 2008 contest.
IUD (Icom Under Discussion) is located on the right, at that time apparently working.
The left IC-402 is owned by my friend Ron PA3BPC / DL3BPC.

Below right is a picture I took around one hour ago, trying to win the RigPix contest ; -)


Left: 2x IC-402 active during a 70cm contest, right: IUD on my workbench.

Our contest team won innumerous 70cm contests with IC-402′s as driver and receivers.
This neat little rig sounds immaculate due to its remarkable low LO phase noise.
Yes, we tried other transceivers but everytime we went back to the good old IC-402′s.

And yes, these rigs are over 40 years of age. But . . . still outperform modern transceivers.
Our ‘last resort’ argument over the last 30 years towards sceptic persons is:

“If your transceiver is better than our IC-402, why don’t you win contests?”

100% of the time the sceptic remains silent (because he didn’t win nor does he own IC-402′s ; -).
Therefore, the proof of the pudding is in the eating. IC-402′s taste very well!

Oh yes, one secret is revealed now.
I modified the MF strip of my IC-402′s according to this document.

The issue.
I could hear noise, but that was all. Both RX and TX didn’t work.

Now . . . where to start. Look (and click!) on the images below.

Have you studied the enlarged pictures above? If yes . . . it’s a mess (which rhymes ; -)
But, this is ‘how it was done’ in the 70′s. At that time state of the art. In 2016 we frown our eyebrows.

Again, where to ‘start’? Well, first thing -after a ‘non power up failure’- is to
ascertain if all ‘frequencies’ inside a transceiver are present. After connecting a counter to CP2
it appeared the ‘band’ (crystal) LO worked fine (Google on the IC-402 manual to find out).

Next IUI (Item Under Investigation) was the VXO. My counter had some difficulties measuring the
VXO frequency. Tentative outcome was around 47 MHz, so it seemed to work fine.

Sometimes you need a little luck. My efforts to measure the VXO frequency caused suspicion.

Using an Ohm-meter the resistance across the VXO terminals appeared to be (close to) 0Ω.

Looking at the IC-402 circuit diagram this was weird. Could there be a shortcut? If yes, where?

Lets look at the relevant part of the circuit diagram below.

It appeared that the thin coax cable from the VXO to the 2nd mixer was shortcutted indeed.
However, in order to ascertain where, or to replace the cable would be a horrendous job!

With lots of fast movements I was able to dismount the thin coax from the mixer module.
Because the D1 and D2 cathodes connect AND face upwards it would be relatively simple to
connect a (new) VXO cable. Measuring these cathodes (D1, D2) revealed no shortcut towards GND.

I also disconnected the connector at the VXO side.
When I tried to pull out the small thin cable for inspection it was ‘firmly’ stuck.

Like I said, sometimes you need some luck when repairing equipment.
It seemed the VXO cable was squeezed between a nut washer and the chassis!
Now . . . what is this for a defect ? This fault must have been inside this IC-402 ever since !

Below a close up picture of the solved issue.

After releasing the cable from its nut washer I fiddled a little and the shortcut disappeared.
Inspecting the cable damage with a magnifying glass revealed the cable could be rescued.

Quickly the VXO cable was resoldered and a 432 MHz signal was applied to the antenna input. Presto!

I spent some time to trim the receiver. The result was a ‘non’ Minimum Discernible Signal (MDS).
In other words, I could easily hear the lowest signal generator level (-140 dBm) from the speaker
and didn’t bother to insert an attenuator in order to measure the full Monty.

Long story short, this IC-402 works flawlessly and is ready to be used in 70cm contests : -)

April 3rd, 2016

Yaesu FT-780R revitalisation

Work in progress… read on …

A priori: As always, click on images to enlarge in new tabs.

Introduction.
I worked at the Dutch Radio Communications Agency and periodically
administrative obsolete equipment was offered to staff members before it was destroyed.

Nowadays, due to governance issues this seems impossible … anyway …

The procedure was co-workers could subscribe to a list. After a while
you were informed whether you wanted to buy the item for a scrap price.

Around 1998 I got my Yaesu FT-780R for around 10 Hfl (ca. 5 Euro nowadays).

This FT-780R was used in our monitoring station (NERA) ‘to enforce amateur satellites’
(I was told). I was also told this FT-780R was ‘custom modified’ so that it was not able
to transmit, in order not to damage other sensitive monitoring/receiving equipment.

After all, NERA was a monitoring station, not a transmitter site ! ; -)

When I got this FT-780R the receiver worked okay, but when you pressed PTT
the processor crashed, resulting in ’8888888 88′ on the display.

For whatever reason I left this FT-780R in a box for more than 15 years . . . until recently.

Below the bottom cover of my FT-780R is depicted.
I think not many radio amateurs use equipment used and owned by their enforcement agencies ; -)


Rationale.

A few months ago some friends in my neighbourhood decided to build a linear transponder using
2320.7 MHz in and 432.7 MHz out, BW = 15 kHz. I own two IC-402′s but these lack crystals for 432.7 MHz.
Despite I have a FT-857 I thought it would be a nice idea to have a dedicated rig for this transponder
in conjunction with a 2320 <–> 432 MHz transverter.

So… I fetched the old FT-780R from my storage box and decided to ‘remodify’ it.

First I looked up the circuit diagrams on the internet in order to investigate these ‘secret
non transmit’ modifications. I found a ‘user manual’ PDF, but circuit diagrams were split.

I ‘reassembled’ the circuit diagrams into one piece with a pair of scissors and took
pictures of the results as depicted below.


‘Remodification = repairment’

My assumption this FT-780R was modified in order NOT to transmit seemed valid at first glance.
My connotation of the word ‘modification’ involves (some degree of) reversibility.

Along the PTT line an ‘extra wire’ was hooked up to the processor board.
Removing this wire eliminated crashing after PTT.

RF output was absent but . . .  I could hear myself on a nearby receiver.  Promising!

Optimistically I started to inspect the final stage, consisting of a Mitsubishi M57716 module.
The relevant part of the circuit diagram is depicted below.

In/nearby the final amplifier stage I noticed three ‘issues’ (refer to right picture above):

1. The antenna relay did not switch per PTT because the ‘RL’ wire was dismantled.
2. Power supply leads of the last amplifier stage were removed both inside and outside.
3. Q2 (2SD235Y) was missing (??) and bridged so PO CONT is forced to 13.8V (??)

Issues #1 and #2 were solved as depicted below.


Issues #1 (left) and                                  #2 (right) solved.

Issue #3 is not a real issue concerning output. It  eliminates the function of the LO/HI power
button on the front. Of course I hadn’t a 2SD325Y but inserted a BD139 in the small pertinax board
next to the 7808 (Q1).

Anyway,  issue #3 is a very queer ‘modification’ in order NOT to transmit . . . (?)

After solving these ‘issues’ I pressed PTT in FM mode . . . .  NO output.
Perhaps the RF module was damaged or received no drive?

Indeed, I measured no drive, so . . .  further investigation was necessary.

The driver for the M57716 resides inside the PLL unit.
Relevant part of the circuit diagram is depicted belowt.


.                                           FT-780R M57716 driver stage.

First inspection of the driver stage didn’t reveal something strange.
Relevant power supply voltages (13.8V and TX 8 Volt) were there, but no drive output.

After careful inspection I couldn’t believe my eyes . . . .  Q05 (2SC2026) was ‘missing’ !! ?

Remember my connotation for the word ‘modification’ ?
For me a ‘modification’ owns a certain degree of reversibility.
In my perspective one of my ex colleagues from the technical department stripped
Q05 from the PCB, and very likely landed in the waste bin !!

I know lots of ex colleagues read and enjoy this blog.
So. . . when you read this and it was you, or you know who it was, contact me?

Being ‘in full swing’ I dismounted the PLL unit for inspection and insert a new Q05.

Below pictures of the ‘missing’ Q05 and dismantling of the PLL unit are presented.

I could have soldered a new Q05 on the top side of the PCB but I wanted a ‘clean repair’.
Of course I hadn’t a 2SC2026 so I chose a good old BFR90 instead. And old it is, 41 years !
Below pictures of the bottom side of the PLL unit are presented. I reckon very few people have seen this side ; -)

After reassembling the PLL unit I measured 5.5Vpp RF @432 MHz over 46.4Ω with a decoupled OA91 germanium diode.
This means corrected around 5.8Vpp, resulting in (5.8/√2)² / 46.4 = 362 mW drive (which is too much btw).

I reconnected the drive cable to the M57716 unit and gave PTT in FM mode . . . . NO output : -(

Thus, very likely also the M57716 module is defect! See pictures below.

At this moment a decision had to be made to replace the M57716 module. In conjunction with
a 2320 MHz transverter replacement is not really necessary. I can route the drive signal from the
input (pin1, right) to the output (pin5, left) of the module with a small coax.

On the other hand, it is elegant to restore the FT-780R for standalone work. So, I ordered a M57716 from Ebay.

Awaiting its delivery . . . more to come, stay tuned!

 

 

March 20th, 2016

Bulgarian yoghurt on 23cm

In 1992 I built a 23cm transverter consisting of two units:

1. UEK3 clone (we had the PCB layouts then ; -), i.e. 1152 MHz LO with 1296 –> 144 MHz RX converter
using a MGF1302 GaAs fet preamp and CF300 mixer.

2. DJ9HO (sk) ‘UHF Unterlage’ or DD9DU style 144 –> 1296 MHz TX converter (output 500 mW @23cm).

Below pictures of my homebrew units are depicted (click on images to enlarge in new tabs)


UEK3 23cm RX converter (by PA3FYM)       23cm DD9DU ‘UHF Unterlage’ TX converter (by PA3FYM)

This transverter served and worked well for some years with a Mitsubishi M57762 module, delivering ca. 17W out on 23cm.

However, when I moved to Groningen in 1997 the transverter landed in a box and remained there for almost 20 years.

Recently I was philosophizing about a long term project: building a 23cm EME station.
I held the transverter in my hands and thought . . . isn’t there something more state of the art, after ca. 25 years passed by?

Let’s face it  . . . over the past 20 years the world changed. GSM, DCS1800, UMTS and now LTE/4G is common practice.
These applications introduced new lines of RF technologies ‘around 1 GHz’, and here I’m standing with old skool gear in my hands?

In December 2014 Arie PAoEZ (sk) told me he bought a ‘Bulgarian 23cm transverter’.
When he told me I didn’t took much notice because I was more concerned about his health.

Around two months ago my friend Hans PE1CKK confessed he bought the same Bulgarian 23cm transverter and told me:
“Remco, quit the old stuff we used to build long times ago. It’s a nuisance, just buy this Bulgarian transverter and focus your
efforts and attention on other stuff.” <– period.

Google led me to the 23cm transverter from LZ5HP. Just one box with everything in it!
RF output on 23cm is around 2W. LO is generated by a PLL locked oscillatorwith several LO frequencies
and . . .  repeater TX shift (-28 or -6 MHz) !

After pleasant emails with Hristiyan LZ5HP I payed 164€ via Paypal and
received the 23cm transverter after three days by mail (with track & trace).

Below a close up picture of the transverter is depicted (click on image to enlarge in a new tab <- worthwhile! ; -)


LZ5HP (sg-labs.com) 144 <–> 1296 MHz transverter.

The transverter is versatile and works fine. After five (5) minutes you’re QRV on 23 !

At this moment of writing the current transverter version is v2.3.
It has the possibility of injecting an external 10 MHz reference signal instead of the internal 26 MHz TCXO.
I have tested this with my 10 MHz Rubidium standard and it works flawlessly.