Svenska ElektronikForumet

Det var länge sedan jag skrev något intressant på det här forumet, så jag tänkte skriva några rader om vad jag pysslar med för tillfället.

Q: Vad är det?
A: En burk som leverera fyra olika ställbara klockfrekvenser mellan c:a 100kHz och 100MHz med ett löjligt litet fel på både kort och lång sikt.

Q: Varför?
A: För att det går.

Q: Vad kan man ha den till?
A: Klockreferens till frekvensräknare, funktionsgeneratorer, väldigt exakta väggklockor m.m.

Jag haft tanken att bygga något sådant här ett tag, med en kristall-osclliator av något slag, samt en GPS-mottagare.
Dock, när jag såg EEVBlog #235 så kände jag direkt att livet inte kunde vara komplett utan lite rubidium istället. Jag köpte en FE-5680A från ebay och började skissa lite mer ordentlig på konstruktionen i övrigt.

Det är standard med 10MHz som frekvens på de flesta (alla?) apparater som är gjorda för att ta en extern referens, vilket också är vad man får ut från burken. Dock så kan det vara rätt användbart även med andra frekvenser, exempelvis används tydligen 13MHz på många billiga frekvensräknare, eller så kanske man vill ha 27MHz eller 12.288MHz till något audio/video-system... Lyckligtvis finns det gott om kretsar som kan fixa det, valde en CDCE706 från texas instruments och för att styra det hela en PIC24FJ64GB004 som jag råkade ha några liggande + utvecklingskort m.m.

Tänkte först nöja mig med "bara" den precision och stabilitet som rubidium-referensen själv klarar av, men efter jag hittat lite information på nätet om hur det går att trimma den digitalt via serieporten i steg som är delar av mikro-Hz så bestämde jag mig för att slänga in en GPS i bygget trots allt, som kan kompensera för att frekvensen driver över långa perioder (dagar...).

Än så länge ser bygget ut som på bilderna nedan, men i slutändan är det tänkt bli ett ordentligt kort som byggs in i en låda tillsammans med Rb-standarden och en liten switchad nätdel. Har byggt upp det hela runt ett Explorer16 utvecklingskort, med GPS (Trimble Copernicus II) och CDCE706 på ett proto-kort som hör till. Har moddat själva CPU-modulen (eller PIM som Microchip kallar den) för att få in en extern klocka till processorn. GPS är inkopplad via UART och PPS-pulsen, och den andra UART:en skall användas för att prata med Rb-standarden men tills vidare används den till debug-utskrifter.

Antennen ligger utanför mitt sovrumsfönster och signalen går via 13 meter RG174 och ett par väldigt dåligt monterade SMA-kontakter (hade ej rätt verktyg) in till "labbet". Vid uppstart använder PIC:en den interna oscillatorn, men efter att Rb-standarden har låst och CDCE706 blivit initialiserad går den över till en extern klocka så att timers m.m. går synkront med Rb-standarden. Använder nu en capture-modul för att mäta avståndet mellan PPS-pulserna räknat i klockcykler, men har tänkt använda CTMU-modulen istället för att mäta offseten mellan PPS och en internt skapad motsvarighet, förhoppningsvis med en upplösning på c:a 1ns (upplösningen nu är 62.5ns).

Just nu mäter jag skillnaden mellan GPS-modulen och Rb-standarden "out of the box". Efter att ha gått i 6 timmar har PPS-pulsen skiftat 117 klockcykler, vilket motsvarar ungefär 3.4*10^-10 i skillnad (om jag räknat rätt...).

Spännande!
Har jag förstått dig rätt att du använder 1-puls-per-sekund från GPSen för att justera Rb-referensen? Vad har du för jitter i den processen, och vad blir fasbruset i slutändan? Hur hanterar du PIC-klockans stabilitet? En del GPS-moduler ger väl också en 10 MHz-signal ut. Vet du hur den genereras?
Många frågor från en som inte riktigt vet vad han talar om

Jag har förstått att en hel del mikrovågsamatörer använder GPS-låsta oscillatorer, men hur de gör frekvensstabiliseringen har jag aldrig satt mig in i.

"Q: Varför?"
A: För att det är väldigt kul när det dyker upp en forumveteran och startar ett spännande projekt!

Det här ska bli intressant att följa!

Vad är det för probar du har till scopet?
Kul och intressant projekt också!

Probarna har jag haft länge, inte säker på fabrikat osv. De ska vara specade till 300MHz, de är gröna och de är ganska smidiga och bra - det är allt jag vet

Har jag förstått dig rätt att du använder 1-puls-per-sekund från GPSen för att justera Rb-referensen?

Det är tanken ja, så långt har jag inte gjort någon styrning dock.

Rb-standarden använder ett DDS-chip internt, och utfrekvensen kan justeras via RS232. Signalen ut går till CDCE706, där en av tre PLL:er används för att skapa en 4MHz klocka till PIC:en där en intern PLL skapar 32MHz. Interna timers tickar på i halva den takten, så exakt 16000000 cykler för varje PPS-puls från GPS:en om allt var perfekt... Just nu räknar jag bara cykler, men tanken är alltså att använda en timer som räknar till 16000000, och att mäta tiden mellan när den räknar runt och PPS-pulsen från GPS:en. Med CTMU-enheten (Charge Time Measurement Unit), som jag aldrig använt tidigare som men ska kunna mäta med en upplösning på c:a 1ns. På så sätt får man ett mått på fasfelet som sen körs genom en lämplig beräkning (filter) och resulterar i en justering av styrvärdet till Rb-standarden.

Lätt som en plätt

Det där med "lämplig beräkning" har jag inte kommit till än, men jag har hittat information som säger att gränsen där tiden från en GPS-mottagare är mer stabil än från rubidium är nånstans i storleksordningen några timmar, så det är ungefär så lång "reaktionstid" jag tänkt mig. PPS-signalen verkar inte ha något större jitter att filtrera bort, har bara sett 16000000 och 16000001 (klockcykler) som mätvärden hittils tror jag.

Om vi kommer in på saker som fasbrus så är jag ute på djupt vatten, men jag tror inte den väldigt långsamma GPS-låsningen ska ha någon direkt påverkan där. Däremot är inte FE-5680A något vidare bra på den punkten från början enligt vad jag läst. Kanske är utsignalerna från CDCE706 (skapade via PLL:er) bättre än den råa Rb-klockan - de ser faktiskt "snyggare" ut på oscilloskopet, men det kanske är för att det blir mer stabil trig på fyrkantvåg.

kolla upp timenuts, dom har mycket info om detta, kul och nördigt på hög nivå

Har inte blivit mycket gjort på detta, eller något annat projekt. Har haft en del mindre roliga saker att ta hand om som tagit upp nästan varje ledig stund.

Nu i helgen tog jag iaf och började skriva lite firmware och testa några saker. Jag har börjat kommunicera med FE-5860A för att justera frekvensen och kalibrera den mot GPS-tid. Jag gör så att jag räknar klockcykler mellan varje PPS-puls och summerar felen (avvikelse från det förväntade värdet 16000000) samt totala mät-tiden. Om felsumman blir större än +/- 1 så räknar jag ut avvikelsen i frekvens och skickar en inställning till FE-5680A som halverar felet. Sen börjar mätningen om igen.

Tanken är att den metoden ska användas som en grov-justering vid uppstart, och om felet stannar inom +/- 1 efter en viss tid (t.ex. 1 timme) övergår processorn till att mäta fas istället för frekvens, med hjälp av CTMU-enheten. Inställningen ska också lagras i EEPROM så den finns kvar vid nästa start.

Har lite problem med att få det hela att fungera som avsett dock, det fungerar bra i några iterationer - tidsintervallet mellan varje justering blir ungefär det dubbla och därmed justeringen hälften så stor varje gång... Men sen när mät-tiden är uppe i närmare en timme och justeringen är i storleksordningen ett par hundra steg verkar det kunna spåra ur och börja självsvänga. Förhoppningsvis är det någon bug i min kod som räknar fel nånstans...

Sen kände jag mig tvingad att skaffa något som åtminstone nästan kan dra nytta av precisionen på den här prylen, så jag köpte en frekvensräknare med 10 siffror och GPIB... Den interna referensen visade sig vara rätt instabil, så jag slängde ihop en tillfällig extern referens av en OCXO jag hade liggande:
Konstruktionen är inte helt optimal, den är pillig att justera och spänningskoefficienten är inte lysande. Lyckades trimma in den ganska bra mot 5680:n iaf:
Om man mäter frekvensen från FE-5680A vid uppstart (med lite kortare gate-tid) kan man se hur den sveper frekvensen med några hundra Hz runt 10MHz när den letar efter "resonansfrekvensen" hos rubidiumet, lite kul att se...

Om man jämför dina 3.4*10^-10 i fel med andra källor så är det ett väldigt bra värde.

Vad väger din Rb setup?, effektförbrukning? (för att jämföra)
Blockdiagram på bygget?, hur ser din Rb källa ut?

Frekvensräknaren FE-5680A ser ut som en apparat som kräver djup manualdykning..

Toppenprojekt iaf!

Blockschema:
USB ska användas till firmware-uppdatering och konfiguration, och efterssom GPS-modulen ändå har två
serieportar tänkte jag dra ut den ena externt (kanske tillsammans med en PPS-puls). Kan t.ex. användas
till en NTP-server...

Själva referensen drar c:a 20-25W vid uppstart, när den nått arbetstemp så sjunker det till ungefär 10W.

Mått och en himla massa annan information om den hittar du lätt på nätet, bara googla på FE-5680A.
Hela bygget, med både referensen, nätdel och kretskort med resten av prylarna ska gå in i en hammond-låda
på 220x160x31mm.

Kort info om diverse saker i tråden..

EEVblog #235 - Rubidium Frequency Standard

CDCE706 - Programmable 3-PLL Clock Synthesizer / Multiplier / Divider

CDCE706]PIC24FJ64GB004 - 16-bit microcontroller, USB, 64 kB Flash memory, 8 kB RAM, 16 MIPS, 44-TQFP/QFN

Fe-5680A2 VK4XV - Rubidium Std. FE-5680A

Racal Dana 1998 10 Hz - 1300 MHz frequency counter

Har justerat koden en aning och nu verkar den fungera bättre, efter att ha snurrat ett dygn så har den svängt in mot en justering av rubidium-oscillatorn på +478 steg, vilket motsvarar 3.26 mHz eller en relativ justering på 3.26 * 10^-10 av frekvensen.

Lämplig styrning är en PI-regulator. Närmast trivialt, men skall bara se till att ha tillräcklig upplösning.

Tänk på att GPSens PPS jittar beroende på den interna klockan, och ibland får man "hängbroar" där man inte får den extra informationen som när klockorna slår vilt mot varandra. Som åtgärd brukar man behöva ta emot tids-information på seriesnöret för att veta "hur fel" PPSen var mot mottagarens position. Tror inte din GPS har den egenskapen.

Dock, med en rubidium så kan man vinna mycket genom att man har så oerhört stabil tid jämfört med slask-kristaller, så då kan man ha tidskonstanter på många timmar.

Läs PRS-10 manualen.

Kolla för övrigt vilken variant av 5680A du har, det finns två olika ute och de har bland annat lite olika upplösning.

/Magnus

ha, jag visste att du skulle gå igång på detta Magnus, kul att du reggade dig på forumet, välkommen!

Kul projekt, följer med intresse!

Vad är jittret på PPS-signalen, och hur säkerställer du en säker triggnivå på den?

Jag är förresten inte litet avundsjuk på frekvensräknaren

PPS signalen är typiskt CMOS 3,3V så att trigga bra på den är inget problem. Däremot är upplösningen hos den interna klockan problemet.

Trivialt att ha för hög upplösning på sin inmätning av PPSen.