Seductive serendipity / Verleidende serendipiteit

April 18th, 2017

IC-720A refurbishment (2)

My intention is to interface my IC-720A to common QSO-logging / contest programs like
N1MM or WinTest. I am not familiar with Ham Radio Deluxe (HRD) and honestly I didn’t miss it over
the last years. Goal is to enrich the IC-720A with an USB interface to allow remote control.
Recently I received the IC-720A bus protocol description (tnx KA6BFB!) so there is hope : -)

Sequencing / timing
When contesting with amplifiers or using seperate RX-antennas, timing is of major
importance to prevent e.g. ‘hot keying’ or detrimental damage due to RF-spikes etc.

Besides the PTT switch on a hand mike, many rigs lack a ‘/PTT input’.
That is, a low current input to switch the rig into TX-mode by making the PTT line low (<– /PTT).

/PTT in
Below the rear side of the IC-720A is depicted. The ‘MEMORY’ cinch connector under the power
supply molex connector looked very tempting to serve as /PTT in.

In my previous posting an internal /PTT point was already addressed. Seemingly the most
easiest way to implement /PTT on the ex-MEMORY cinch connector is to wire an internal /PTT point
to this connector? No . . . !

Nuisance with /PTT’s  (i.e. active low) is that this ‘low’ state is relative towards a ‘high’ state.
Depending on equipment used these ‘high’ states may vary significantly. Therefore ‘paralleled’
/PTT lines may result in detrimental damage! Perhaps the Heathkit SB-200 may serve as an example.
In ‘high’ state I measured around 120V on the /PTT input connector (!) Imagine what would happen
if you simply join the PTT of your rig with the PTT input of the SB-200 . . .

Mostly this nuisance is overcome using relays as isolation instrument. However, I am allergic
towards relays (perhaps besides the RX/TX (coax) relay) and prefer solid state solutions.

Grounding the PTT line I measured around 80 mA current, which is too much to be called ‘low current’.
My initial idea was to use an optocoupler where the switching transistor side had to serve as
/PTT switch. Well, that didn’t work. Despite having enough current through the
LED side of the optocoupler I heard the RX/TX-relay switching, the ‘TRANSMIT’ light weakly
burned but no RF output power was present in RTTY mode or ‘key down’ in CW.

Perhaps my /PTT wasn’t ‘low’ (or ‘strong’) enough?

I took another approach which works flawlessly, see picture below.

‘/PTT in’ is wired inside to the ex-’MEMORY’ cinch connector and ‘/PTT out’ wired to the
grey wire on the MAIN UNIT connector used for the relay accelerator (cf. previous posting).

April 9th, 2017

IC-720A refurbishment (1)

Around three weeks ago I won an IC-720A for almost nothing during a live sale
at our radioclub
(PI4RCG). It was presented defect, so I thought: “What the heck?”

Afbeeldingsresultaat voor ic-720a

The next day the rig was repaired within an hour. Main error was, guess what . . .
yes! . . . the rotary relay. After some fiddling, cleaning and lubrification of the
rotary switch everything worked as expected.

It appeared my IC-720A was enriched with a  FL-32 500Hz 9 MHz CW filter, so this good old
buddy may be a likely candidate for ‘permanent’ portable usage in our camper/motorhome.

(Note: I prefer 250 – 300 Hz bandwidth for CW with ~500 Hz pitch . . . )

Some googling revealed that this rig was a quantum jump in its time and (one of) the first rig(s)
able to be remote controlled by a predecessor of the current CI-V Icom (‘CAT’) bus/interface.

The IC-720A features a general coverage receiver in 1 MHz portions. Transmitting was limited to
HAM bands only. With nippers this limitation was ‘fixed’ within 20 msec ; -) (read on).

In order to ‘get the rig going’, N1MM+ and my Winkey compatible Arduino keyer forced the
IC-720A to give CQ in CW for around three hours with full power (100W).

After this endurance test everything worked well, but I noticed I had to enter around 50 msec
‘PTT preamble’ in N1MM+ . . . which is too slow for contest and/or pile up usage.

So, I decided to enrich the TX/RX relay in the FILTER unit with a relay accelerator.

After studying the IC-720A service manual (google on it) it appeared that the /PTT (‘SEND’)
signal towards the filter unit (containing the TX/RX relay) could be easily located and isolated.

The wire was cut and the relay accelerator was piggy bagged somewhere on the MAIN unit.

Below a picture ‘before’ is depicted, mods are marked with A, B and C.
(click on picture to enlarge in a new tab)

A. General coverage TX mod. Cut this wire. (period ; -)

B. /PTT (‘SEND’) wire to filter unit. Cut this wire.

C. μPC2002 (TDA2002) noise reduction mod: place 470n in series with 100 Ohm between legs 2 and 4

Ad. B
Cut the concerning grey wire around the arrow marked position (see picture above).
The piece connected to the connector on the MAIN board goes to the input of the relay accelerator.
The other side is connected to the relay accelerator output by lengthening the wire a little.

The results of B and C are marked B’ and C’ in the picture below (click on image to enlarge in a new tab)

To be continued . . .

April 3rd, 2017

FT-857 audio noise reduction mod

Being into weak signal work, either in contests or DXing, I fight against noise.

Europe is noisier than other parts of the world. In The Netherlands man-made noise
is becoming a significant issue, even a problem. However, with the right attention it is possible
to reduce noise/interference and become competitive on shortwave, even from The Netherlands.

Many people know me advocating the (vertically polarized) deltaloop on 40m. When properly fed
this antenna behaves like two stacked full size verticals but .  .  .  moreover, it reduces noise
during reception because it’s a closed loop/system. “If you can’t hear them, you can’t work them!”

In my quest reducing noise I was confronted with a kind of ‘nuisance after discovery’: audio noise.

My good old buddy, a FT-857 (yes . . . not a 857D), always assists me during holiday trips to
make contacts from exotic places. A few weeks ago I was in such an exotic place and was confronted
with a HUGE pile-up on 40m and tried to pull out weak JA’s and W’s out of the noise with my
simple setup: a (heavily modded) barefoot FT-857 (60 – 65W o/p) and 40m (vert. pol.) deltaloop in CW.

Blame my 70, 23, 13, 9, 6, 3cm, 2, 6, 40, 80 and 160m experience, but even on short wave you’ve weak signals!
Because I listened so much into the noise, my brains developed a kind of ‘weak signal filter’ in pile-ups.
During the last operation from this exotic place something became apparent to me which I (apparently)
didn’t notice before: unwanted audio noise in my (LoFi, NOT HiFi!) headphones.

Back in The Netherlands I decided to dig further into this issue.

Back home I inserted a weak signal (-140 dBm @7025.0 kHz) into my FT-857 and listened through my
headphones. While listening in CW-N (300 Hz BW) I was fighting against the perception ‘do I hear a tone or not?’.

In order to rule out some bias in myself I asked someone else to push the RF-on/off button of my
signal generator. My score was around 60% correctly detecting the tone or not.

With this applied weak signal I discovered I had problems in determining whether I could hear a tone
(or not) was related to the volume but increasing the volume also increased high(er) frequency noise
(more?) in the audio! Certainly a psycho acoustic issue is involved.

In other words, the high(er) frequency noise was interfering with my perception (whether there was
a tone . . . or not). In other other words, this high frequency noise was an extra load in filtering
the tone (in my brains?). The high frequency noise can be described as a ‘high pitched hiss’.

This led me to investigate the audio receive chain of the FT-857 and soon I focussed on the TDA2003
audio amplifier. Simply because this stage has an almost equivalent gain contribution in the whole
chain than it’s predecessing (RF and IF) stages. Assume that the -140 dBm signal has to be converted in
1W audio output (+30 dBm), the whole chain must have an amplication of 140 + 30 = 170 dB.

Knowing that generic audio amplifiers have (let’s say) 80 – 90 (if not 100) dB gain,
it’s relative contribution has might be significant (not for the overall noise figure (NF)
but more the timbre of the sound).

So . . . I decided to dig into the datasheet of the TDA2003 audio amplifier.

The TDA2003 is a standard audio amplifier. On the first page of the datasheet I found the standard application:

Immediately ‘Rx’ and ‘Cx’ drew my attention. Further in the datasheet it is explained that Rx and Cx
introduce a low pass behaviour in the above circuit.

In the FT-857 circuit diagram I noticed Cx and Rx were lacking (see below):

From the formulae given in the original datasheet, and assuming ‘B’ in the formula for Cx is
the cut off frequency, I calculated Rx = 100 Ohm, and Cx around 220 nF for B = 3000 Hz.
Because I hadn’t 220 nF and fiddling with  2x 100 nF parallel wasn’t my cup of tea, I chose 470 nF,
also to be on ‘the safe side’. Thus, 470 nF in series with 100 Ohm were connected between
legs 2 and 4 of the TDA2003.

My first impression by ear was that the mod works, in a sense that I was more able to detect the tone.
Again someone else was asked to randomly press the RF-on/off button of my signal generator and
my score was 100% correct in determining whether there was a tone, or not.

We did a second test where I had to leave my shack. After I was called I had to take place at the table,
put on my headphones and the above procedure was repeated. At first glance I didn’t hear anything
but noise, but suddenly I thought I heard something. However, this seemed weaker than the previous tests.

I turned up the volume somewhat and after my brains ‘locked’ into the situation I was able to score
around 70%. It seemed my assistant reduced the signal generator level to -146 dBm by inserting a calibrated
20 dB attenuator and adjusting the output of the signal generator to -126 dBm !

Of course I was curious if I could determine the yield of the mod in a more objective manner.
A few years ago I used the ‘Analyzer2000′ program to determine and optimise signal to noise ratios (SNR).
However, it seems that this program doesn’t run anymore on 64 bit Windows systems. As alternative I installed
Spectrum Lab from DL4YHF. Despite Spectrum Lab is advertised being able to determine SNR’s, I couldn’t
find a separate SNR option or button at first glance. This program is significantly more versatile and
complicated than Analyzer2000, so I reckon I have to dig further in the manual ; -).

Anyway, as alternative screenshots of the waterfalls were saved in order to see the difference in noise
performance. ‘Before and after mod’ screenshots are saved into the animated gif depicted below.
In this animated gif three filter responses are displayed from top to bottom:
CW (CFIL, i.e. original filter), CW (2300 Hz BW, ‘SSB-filter’), and CW-N (300 Hz BW).

The crispy yellow points are the FT-857 audio beeps when selecting another filter.

Conditions: signal of -140 dBm @7025.0 kHz inserted into the antenna connector of the FT-857.
Audio extracted from the front headphone connector with headphones as parallel/speaker load.

It can be seen that the screenshot taken at around 19.48 hrs (‘after mod’) is more dark/black in the
higher frequency region than the 19.36 one. Of course this method is very ‘wicky whacky’ but it gives
some visual information about the audio (power) distribution. There may be some slight volume differences
between the two screenshots, due to implementation of the mod . . .

Anyway, the mod works for my brains, may increase (perceived) SNR with around +6dB as determined with a
‘wicky whacky’ method, and . . . is easy to realize!  See picture below (click to enlarge in new tab).


January 16th, 2017

ADF4351 evaluation board microwave beacon

Building transverters for 23, 13 and e.g. 9 cm in the nineties was a tedious job.
First hurdle was building a local oscillator (LO). Typically a crystal oscillator
between 90 – 100 MHz was multiplied towards the desired LO-frequency.
After some fiddling and tuning lots of sky trimmers several milliwatts (mW)
of LO signal was obtained to inject into mixers.

Nowadays building LO’s is a piece of cake due to enormous developments in PLL technology.

Analog Devices released a PLL chip with an internal oscillator some years ago: the ADF4351.
Despite very interesting specifications, these kind of PLLs reside in very small (SMD) packages.

Fortunately some ‘evaluation boards’ exist, making experimenting much more easier.
A few weeks ago I found such an evaluation board on Ebay for around U$ 25.

Despite the fact that these boards may contain a ‘fake’ ADF4351 (an ADF4350 with ’4351′ on it)
I gave it a try (Google on ‘ADF4351 evaluation board’).

Alain F1CJF made a signal generator with a similar evaluation board and an Arduino.
However, for my purpose his approach was too complicated for me. I don’t need displays, buttons etc.
Therefore I consulted the ADF4351 datasheet and started programming myself.

As gadget I wrote a simple beacon keyer in conjunction with the PLL initialization code.
This code may be optimized/simplified when inserted into an ATTiny13a or similar microcontroller.

ADF4351 control pins LE, CLK and DATA are ‘onboard grounded’ with 10k resistors. Interfacing
a 5V Arduino is simply done with 5k6 series resistors because the ADF4351 operates at 3.3V.

When the code is entered into an ATTiny13a (or similar small 8 pin DIL microcontrollers) and
powered with 3.3V, interfacing the PLL board is simply a matter of connecting wires and we’re done!

Below a picture of my test setup with an Arduino NANO is presented (click on image to enlarge in a new tab).

Here is a short movie how it sounds on 2320.829 MHz (when programmed for 2320.850 MHz).
What you see is a FT-480R (old skool 2m allmode rig) with an old skool DC8UG 13cm transverter
in receive mode. Keying of the ADF4351 is done with bit5 in R4.

The onboard 25 MHz (TCXO?) evaluation board reference results in a ‘reasonable’ frequency
stability (doesn’t sound bad eh ?) but is a bit off (i.e. -21 kHz) frequency.
Goal is to use a GPSDO reference for ultimate precision and stability.

Here is my Arduino ‘sketch’. No libraries, just plain code. Have fun! : -)

December 17th, 2016

Es’hail2 dual band dish feed (2)

In this post I elaborated somewhat on the construction of an Es’hail2
amateur transponder feed.

Yesterday I (re)measured the 2.4 GHz feed a on a vector network analyser @work.
After some fiddling with the matching stub a truly fine 50Ω match was obtained!

I reckon the pictures below are self explanatory (click on them to enlarge in new tabs).

Fig.1 Test array in the laboratory                           Fig.2 Smith Chart between 2300 – 2500 MHz

Fig.3 Close up of matching stub                           Fig.4 Return loss response between 2300 – 2500 MHz


October 29th, 2016

FokzBox 2m fox hunt receiver

As active fox hunter Mischa PA1OKZ designed his own interpretation of
the ultimate 2m fox hunt receiver aka the FokzBox (Dutch only) in 2013.

The demand was big and around 250 receivers were succesfully built by
a large diversity of people, including me. Although Mischa ran out of
material and stated being fed up with the project, pressure on him led
to the mysterious discovery that his PCB manufacturer had 25 PCB’s left.

With some effort Mischa managed to collect all components to build
25 receivers and announced an order time frame to the community.
Within a few minutes all 25 receivers were sold.

In practice this means around 25 people are building their FokzBox now.
Sometimes they encounter problems and recently I heard somebody talking
about ‘the picture of PA3FYM’.

To facilitate builders, here it is (click on image to enlarge in a new tab):

FokzBox of PA3FYM (with some mods, but ignore them, PCB is v1.0).


September 23rd, 2016

Condor16 met gele stip!

A priori: because Condors are ‘hauptsächlich eine Holländische sache’
this posting will be in Dutch.

Naar aanleiding van mijn vorige post omtrent Condor-software en -ombouw doneerde
Jan PE1FWD mij op basis van deze oproep destijds afgelopen week een Condor16.

De geheime overdracht des Condors vond in de avond van 21 september jl. plaats op het
Gedempte Zuiderdiep te Groningen. Een biertje bij Cafe De Oude Wacht voldeed als betaling.

Het bleek een Condor16 met gele stip te zijn. Interessant is de gecultiveerde gedachte dat
Condor16′s met gele stippen ‘in principe niet geschikt zijn’ voor 144 – 146 MHz. <– ??

De mogelijke oorsprong van vorenstaand statement valt te duiden m.b.v. onderstaand
screenshot van een bekende Condor-informatiesite (klik om te openen in een nieuwe tab):

Ook andere Condor-experts deden mij jarenlang geloven dat ombouw van een ‘gele stip’
teveel werk was en om die reden dus oninteressant zou zijn.

Ondanks dat honderden Condor16′s met mijn software succesvol zijn omgebouwd (al dan niet met
FYM-ctcss), bezat ik zelf geen Condor16 (<– ‘PTT’ versie) maar wel een TMC82 (<– ‘PVD’ versie).

Dus de gift van de gele stip was voor mij kwa twee aspecten zinvol:

1) een ‘echte’ Condor16 te hebben voor de softwareontwikkeling
2) ondanks ‘horrorverhalen’ een gele stip ‘aan de praat’ krijgen

Zonder ‘aanziens des stips’ brandde ik een EPROM met mijn software en liet mij niet hinderen
door de gedachte dat ik een ‘niet geschikte’ Condor16 onder het mes had.

Met gevaar voor eigen leven verwijderde ik de behuizing en bereidde me op het ergste voor.
Immers, een bevriende Condor-expert had me afgelopen week nogmaals bevestigd dat er aan
gele stippen’ teveel moest gebeuren om ze geschikt te maken voor 144 – 146 MHz.

Onderstaande foto geeft weer hoe ik (na openmaken) het RF-deel van de gedoneerde Condor aantrof
(klik voor grotere foto in een nieuwe tab):

Niets bijzonders! Na aanzetten had ik wel een knipperend display, dus de PLL(s) lockte(n) niet.

Nadat de -in bijenwas gesealde- VCO-messingkernen waren ‘bevrijd’ en de kapjes ‘boven’ de VCO’s
waren verwijderd, lockten beide VCO’s ( i.e. geen knipperend display) nadat ik de messingkerntjes
‘door de onderkant’ draaide (zie foto onder, klik voor vergroting in nieuwe tab).

Hierboven: ‘doorgedraaide’ messingkernen voor VCO-locks @145 MHz (displayfrequentie).
De VCO-spanningen (MP RXvco en MP TXvco) bedroegen ca. 1V, hetgeen erg (te) laag is.

Op de print bij de VCO’s zitten ‘foezelpads’ waarmee een condensatortje parallel met de VCO-kring
geschakeld wordt. Gevolg is verlaging van de resonantiefrequentie en ‘mooier’ inregelen van het
betreffende VCO-kerntje. Besloten werd om voor beide VCO’s de foezelpads (rode pijltjes) te activeren.

Inderdaad, de VCO-spanningen konden mooi ingeregeld worden. De messing kerntjes zitten ongeveer
in het midden en resulteren in VCO-spanningen van ca. 2.5V bij 145 MHz (displayfreq).
Zo ingesteld locken de VCO’s tot ca. 160 MHz (displayfreq).

Hieronder een foto omtrent ‘voor’ en ‘na’ bij het RXvco, voor het TXvco geldt dito.

Afregelen ontvanger
Met een meetzender werd 145.000 MHz in de ontvanger geinjecteerd en na afregeling bedroeg
de gevoeligheid ca. -125 dBm bij ca. 10 dB SINAD. Dit is werkelijk prachtig! Niets padjes
solderen of allerhande griezelverhalen dat er ‘teveel’ aan moet gebeuren om de
RF-ingangstrappen geschikt te maken voor 144 – 146 MHz.

Afregelen zender
Het vermogen @145 MHz bedroeg in stand ‘HI’ ca. 7 Watt, gemeten met een HP-432A bolometer.
Dit is wat aan de lage kant. Ik vermoed dat er nog een paar extra Watten te halen zijn
wanneer de driver en eindtrap onder de loupe worden genomen.
Ik kon vanuit mijn QTH met een simpele rondstraler binnenshuis probleemloos over PI3UTR werken.

Hieronder een foto van het onderhavige exemplaar (klik voor vergroting in een nieuw tab).

De voorlopige conclusie lijkt gerechtvaardigd dat m.b.t. dit Condor16 gele stip-exemplaar geen
verrassingen zijn geconstateerd met mijn software (v3.05). Of dit toeval is, weet ik niet.

Maar . . . ! Ik heb inmiddels een tweede Condor16 met gele stip gekregen.

Toevoeging 26 september jl.:

Na openmaken van de tweede gele Condor16 bleek dat deze al gemodificeerd was.
Er zat een sticker in waarop stond: “145.650   111 – 112 dBm” (zie onder).

Met de meetzender @145.000 MHz kon ik bij ca. 10 dB SINAD de gevoeligheid wat
beter krijgen, nl. -118 dBm en heb het maar gelaten zoals het is.

Ook in dit exemplaar waren de ‘padjes’ waarmee extra condensatoren parallel aan
ingangskringen worden geschakeld ‘geactiveerd’, alsmede de padjes bij de VCO’s.
M.a.w., wanneer dit wordt gedaan, performt de zaak goed rond 145 MHz.
Dit exemplaar leverde trouwens max. 12 Watt RF output.

Omdat in deze Condor16 geen FX315 CTCSS chip zat, heb ik gelijk maar FYMctcss ingebouwd.
Hieronder een gedetailleerde foto van de inbouw (klik voor vergroting in een nieuwe tab).

Op basis van vorenstaande ervaringen hoop ik het fabeltje weggenomen te hebben dat
Condor16′s met gele stip ‘ongeschikt’ zijn voor ombouw naar 144 – 146 MHz !

September 8th, 2016

Last season 160m contest results

It’s September! This means preparations for next 160m contest season
are planned. Last season was (again!) a record breaking season for me.

Below certificates issued to me by CQ Magazine, considered as the ‘Formula 1′ in radio contesting
(click to enlarge in new tabs).

Last CQWW contest I broke the/my Dutch 160m CW record for the third time in a row.
I.e. the highest Dutch score ever, regardless of Category (e.g. single op or multi op).

I also broke my personal CQ160 CW record and obtained the highest Dutch overall score this year.

Of course these results were impossible without the help of my good friend
Richard PA7FA and his wife Marion from

August 28th, 2016

Knipperen display Condor / TMC

A priori: because Condors are ‘hauptsächlich eine Holländische sache’
this posting will be in Dutch.

Enige jaren geleden heb ik de VFOza firmware voor de (nog steeds) erg geliefde
Condors (16, 46) en TMCs (82, 84, 87) na 15 jaar opgeschoond en uitgebreid.

Dit gebeurt met programmeren in 8039 assembly. Hierna komt er een binary
(van precies 4096 bytes!) uit, geschikt voor een 2732 EPROM.

        mov     r1,a            ;save tellerwaarde

        mov     a,r0            ;in r0 staat toonnr in hex
        add     a,#240          ;check of toonnr niet groter is dan 15
        jc      noctc           ;zo ja, dan geen ctcss
        mov     a,r1            ;restore tellerwaarde
        jnz     setctc          ;als tellerwaarde <>0 setctc
noctc:  mov     a,#00h          ;als tellerwaarde = 0 dan geen ctcss en dan 00h op $30
setctc: mov     r0,#030h        ;store op $30 <- de isr timer waarde om ctcss te genereren
        mov     @r0,a
        mov     r1,#070h        ;wanneer een FX315 on board is, deze uitzetten, 70h = no ctcss
        jmp     setio1

Hierboven een voorbeeldje van 8039 assemblercode, in dit geval rondom FYMctcss.
De processor is erg oud (jaren ’70), dus programmeren moet redelijk ‘scooby doo’ ; -)

Naast FYMctcss, het genereren van CTCSS door de 8039 microprocessor zèlf
zodat de FX315 chip niet (meer) nodig is, zitten in mijn firmware meer toevoegingen.

Lees hiervoor ondermeer deze en deze posts.
De posts zijn weliswaar van een tijdje terug maar bevatten de essentie.

Alhoewel thans ca. 30 jaar oud, waren Condors destijds best hun tijd
vooruit. Volgens sommigen zaten er ook haken en ogen aan, zoals
aanblijven van het zend-VCO met modulatie (!)
Voor andere toepassingen was dit juíst gewenst, zoals in overvalsituaties
of gijzelingen.

Het modificeren van ‘good old’ Condors gaat in vlagen. Recent was ik getuige
van gesprekken omtrent ombouw en gebruik van mijn firmware.

Hierboven een Condor16 van iemand met mijn firmware. Hoe weet ik dat?
Heel simpel, de eerste hint: iemand die met ‘VFO-software’
op 145.575 MHz (PI3UTR) kan werken, gebruikt voor 99% zeker mijn firmware,
ongeacht hetgeen je op de displays ziet verschijnen na aanzetten ‘des Condors’.

Daarbij heb ik bovengenoemd iemand wat toetsencombinaties laten uitvoeren.
Hieruit bleek dat het inderdaad mijn firmware was, ondanks misleidende (opstart)informatie.
In dit geval is/was de opstartinformatie ’2013′, een code die in mijn images nooit voorkomt.

Heren fakers, peekers en/of pokers, ik heb u voldoende informatie gegeven omtrent hoe
default geheugeninstellingen te wijzigen, maar laat svp het versienummer ongemoeid.
Hierdoor schiet u zichzelf en uw (betalende?) ‘klanten’ alleen maar in de voet!

Anyway . . .

Uit de feedback die ik krijg, geeft het vervangen van de EPROM in de meeste
gevallen geen moeilijkheden. Oude EPROM eruit, nieuwe EPROM erin,
eventueel de RC-netwerkjes voor FYMctcss insolderen, coldstart
(dwz Condor aanzetten met luidsprekertoets ingedrukt) en . . . klaar.

Er zijn echter soms gevallen waarbij de boel in eerste instantie niet lijkt te werken.
Uit de feedback zijn de volgende hoofdcategorieën te onderscheiden:

1. Display met default VFOa-frequentie knippert na vervanging EPROM bij daarvoor werkende Condor.
1a. Display met default VFOa-frequentie knippert bij ‘verse’ Condor.
2. Display vertoont ’0000′* met ‘verse’ Condor (dwz Condor die (nog) niet afgeregeld/gemodificeerd is).
* Kan ook andere weergave zijn, zoals ’0 00′ of ’8888′ e.d.

Categorie 1 geldt eigenlijk alleen bij Condor16‘s (VHF versie met rode, blauwe of gele stip).
Categorieën 1a en 2 kunnen zich voordoen bij alle TMC-/Condor-versies.

De naam ‘Condor’ is verbonden aan de vroegere PTT, thans KPN, en kent twee modellen:

Condor16 : 140 – 175 MHz (‘VHF’, afhankelijk van ‘stipkleur’)
Condor46 : 440 – 470 MHz (‘UHF’)

Voor zover ik weet bestaan de volgende TMC-versies, dwz versies speciaal
ontwikkeld voor de vroegere PolitieVerbindingsDienst (PVD):

TMC82 : 140 – 160 MHz (VHF ‘hoog’)
TMC84 : 66 – 88 MHz (VHF ‘laag’)
TMC87 : 440 – 470 MHz (UHF)

Het belangrijkste verschil tussen een ‘Condor’ (PTT/KPN) en een TMC (PVD)
is de hoogte van de PLL-referentiefrequentie. In beide versies zitten
6.4 of 12.8 MHz kristallen. Echter, het uitgekoppelde deeltal van de referentieoscillator
om tot een voor de PLL werkbare referentiefrequentie te komen, verschilt.

De reden hierachter is mij informeel meegedeeld en zou te maken hebben met
het bewust willen scheiden van ‘burger-’ en ‘politie’apparatuur (om het maar even
zo politiek mogelijk te formuleren ; -)

Daarbij hadden sommige PVD-versies een speciale connector op de achterzijde van de
slede voor politie/opsporings specifieke toepassingen waar ik niet verder op kan ingaan.

Hoe het ook zij, intern zijn Condor- en TMC-versies (nagenoeg) identiek.

Het is mogelijk om een TMC-versie op ‘Condor-software’ te laten werken maar dan
moet het interne referentieoscillatorblikje worden geopend om daarna het juiste
deeltal aan de MC148158 PLL’s aan te bieden.

Ik heb dat zelf een aantal keren gedaan en het is een vervelend karwei. Om deze reden zit
er in mijn firmware een optie die bepaalt of er sprake is van een TMC of Condor.

Het werkt als volgt: zodra de Condor/TMC wordt opgestart, worden -na initialisatie
van wat zaken- de PLL’s geprogrammeerd en gecheckt op locks.

Het locksignaal wordt aangeboden aan de 8039-processor.
Wanneer dit signaal ongeldig is, verandert mijn firmware alternerend de
referentiedelers in de PLL om te kijken of er wel een lock mogelijk is.

Dus, afwezigheid van PLL-lock openbaart zich door knipperende displays met
de default geprogrammeerde VFOa-frequentie.

Ad. categorie 1:
Hoe kan het dat het display nu wel knippert, ‘terwijl dat daarvoor niet zo was’ ?

Zie hiervoor onderstaand figuur (klik om te openen in een nieuw tabblad).

Bovenstaand plaatje geeft het relevante deel van de zgn. ‘HF Stufe’ aan.
V17 (2N4416) is het TX-VCO dat door de PDout pin (5) van de MC145158
wordt geregeld. Echter, er is ook J2 (4094) die een bepaalde voorspanning
geeft. Deze voorspanning wordt door een softwarematige DAC gemaakt.

Omdat Condor16′s met de verschillende kleurstippen een andere voorspanning
nodig hebben, kan het zijn dat de voorspanning (offset) in mijn firmware niet
helemaal klopt met de oude situatie. Immers, ik heb een ‘gemiddelde’ genomen.

De remedie is simpel: draai aan het TX-VCO kerntje totdat er weer VCO-lock optreedt.
Daarna regelspanning nog tweaken op ca. 3-4V voor midden in de band.

Dezelfde procedure is van toepassing bij het RX-VCO.

In het schema is ook te zien dat er voor de RX-ingangskringen dezelfde offset wordt
gebruikt. Dit om -afhankelijk van het type Condor- de frequentiedoorlaat van de
ingangskringen een beetje ‘bij te trekken’ met behulp van de varicaps.

Het kan dus zijn dat je de Condor opnieuw moet afregelen voor maximale gevoeligheid.
Dit is sowieso geen slechte actie want in mijn software staan de verzwakkers
(-12 en -6 dB = max. -18 dB!) uit (en deze verzwakkers beinvloeden de ‘afstelling’).

Bij goede afregeling is ca. -123 dBm (ca. 0.15 uV) bij ca. 10 dB SINAD haalbaar bij VHF-versies.
Haal je met je huidige software b.v. -115 dBm (0.4 uV) dan is óf de zaak niet optimaal
afgeregeld óf uit ‘voorzorg’ de -12 dB verzwakker ingeschakeld. Dit laatste gebeurde
vaak ivm 10/12.5 kHz raster en vermeende ‘nabuurkanaalstoring’. Anders geformuleerd,
in sommige gevallen werden/worden deze mobilofoons bewust wat ongevoeliger gemaakt.

Mijn redenatie is simpel: het maximaal haalbare moet er uitgehaald worden en in het
frequentiebereik van de amateurdienst zijn nauwelijks meerdere sterkere signalen
op korte (frequentie)afstand aanwezig.

Vanaf mijn firmware v3.05 wordt de laagste SINAD-waarde (10 dB) als squelchdrempel
gebruikt. Daarvoor (v3.03 – 3.04) was dit 15 dB. Wanneer naar v3.05 wordt geupgraded
kan het zijn dat de squelchpotmeter iets ‘verder gedraaid’ (tegen de klok in) moet worden.

Ad. categorie 1a:
Ook hier lockt tenminste een van de PLL’s niet.  In het schema (zie boven) is te zien
dat de lockdetectorpinnen van de twee PLL’s als een AND-functie zijn geschakeld.
M.a.w. beide lockdetects (pin7 van het PLL IC) moeten ’1′ zijn anders blijft het display knipperen.

Afhankelijk van het Condor16-type (stipkleur) moet je bij een ‘vers’ exemplaar
wat doen. Dit kan varieren tot slechts aan de VCO-spoelen draaien tot beide
VCO’s locken, tot het plaatsen van extra C’tjes onder de VCO-blikjes.
Op Google zijn diverse links te vinden omtrent hoe en wat er moet gebeuren.

Ik begin altijd eerst met het RX-VCO en meet de VCO-spanning
op stabiliteit als functie van het draaien aan de RX-VCO-kern.
Daarna het TX-VCO. Waarneer deze lockt, verdwijnt het knipperen.
RX-gevoeligheid optimaliseren en . . . klaar!

Ad. categorie 2:
Het betreft meestal een issue met het opstarten van de processor.
Om een lang verhaal kort te maken, zie onderstaande figuur (klik voor vergroting).

Mij is gewaar geworden dat afhankelijk van de fabrikant en het type
8039 (b.v 80C39) dat pin26 (Vdd, programming voltage) tijdens
opstarten ‘hard’ hoog moet blijven. Na het doorknippen van D16
was het euvel verdwenen.


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.