Remco.org

Seductive serendipity / Verleidende serendipiteit

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.

Inleiding
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

Handelwijze
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).

Conclusie
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).


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

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

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

 

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)