A second T31 Precision Frequency Standard

Status
Not open for further replies.

TelephoneBill

Well-known member
(https://forum.pjrc.com/threads/35397-Teensy3-1-as-a-precision-Frequency-Standard).

In the above post, I demonstrated a precision frequency standard based upon the 60 KHz time broadcast from the UK MSF transmitter. This new post is about a project similar to the previous one but uses a superior 100 KHz transmission from the UK LORAN (Long Range Navigation) transmitter situated on the same Anthorn site.

LORAN was developed post World War 2 from bomb aiming technology. It was active from the late 1940’s until fairly recent. Though many global stations have now closed down, there is a revival system called eLORAN (enhanced Loran) currently being tested. It aims to provide an alternative backup service to GPS. Trials are now taking place in the US, UK and South Korea.

The LORAN signal is superior to MSF because it is able to remove the unstable sky-wave reflection component from the more stable ground-wave. It does this by using a series of short fast rise-time pulses rather than a continuous carrier. These pulses are about 200 uSecs in length so each will carry at least 20 cycles of 100 KHz (10 uSec per cycle). A master LORAN station transmits a group of 8 consecutive pulses, spaced 1 milliSec apart (precisely), followed by a gap of 2 milliSecs and then a final ninth pulse. This sequence is repeated at a time period known as the GRI (Group Repetition Interval). For the UK Anthorn transmitter, the GRI is 67,310 uSecs. You can see a short video of this signal waveform here…

https://youtu.be/xws7mJvp3dQ.

To understand how this stability principle works, consider for example my own location which is 180 Km from the transmitter. This is the direct path that the ground-wave takes, and pulses will arrive some 600 uSecs after leaving the transmitter. The sky-wave, however, travels a little further because it needs to reach and reflect from the D-layer which is approximately 75 Km above ground. Trigonometry dictates that the corresponding sky-wave pulse will therefore travel a total of 234 Km before it reaches my location. This is 54 Km further in distance than the ground-wave, and will therefore arrive some 180 uSec later. So if my radio receiver can extract the first 10 or 15 cycles from any of the individual 100 KHz LORAN pulses, then this part of the signal will be free from any phase distortion caused by vector addition of the delayed sky-wave to the ground-wave component.

In this project, Teensy 3.1 operates in 120 MHz overclock mode, which gives a peripheral flextimer clock rate of 60 MHz. Flextimer FTM1 is used to generate a local 100 KHz square wave reference signal having its output on Channel 0. This reference is phase locked to some early 10 cycles of the LORAN signal. The radio signal is first received and amplified (in a similar way as for the previous MSF project) and then passed to a NOR gate biased to operate in its linear mode. The output of the NOR gate is a square wave whose transitions are then used as an edge trigger for Channel 1 of FTM1. The counter readings of Channel 1 will be directly proportional to the time difference between the LORAN signal cycle edges and the edges of the local Teensy 3.1 generated 100 KHz. This feature is used in the algorithm to obtain phase lock.

Precise phase lock is achieved by finely adjusting the Teensy 16 MHz crystal frequency using the on-chip digital load capacitors in register OSC_CR. By “dithering” between two specific (chosen) values, the crystal can be adjusted to be exactly 16 MHz. This will set the 100 KHz output of FTM1 to also be exactly 100 KHz and this can further be used to control the phase of the reference square wave in comparison with the LORAN cycles.

The phase locking algorithm only needs to make a comparison to those selected early 10 cycles of the LORAN signal when they are present. It needs to ignore the readings of Channel 1 at all other times. So to select the timing for those 10 LORAN cycles, a strobe signal is created on an output pin (digitalWriteFast) which is time referenced to the ISR routine that fires in response to the overflow signal (TOF) associated with FTM1 and the 100 KHz reference. The ISR will fire every time FTM1 makes an edge transition (positive or negative) so the ISR repeats its code every 5 uSecs (making 10 uSec for a complete cycle). There will - therefore - be 13,462 interrupts (and passes through the ISR routine) for one complete GRI interval of 67,310 uSecs – and then the procedure will repeat over again. By counting each ISR pass, it is fairly easy to create a strobe signal that can be time varied to pulse on/off repeatedly at any specific point in the GRI period. That same strobe time can be used internally in code to record the required readings from Channel 1.

The actual lock control code is outside the ISR in the program main loop. It is a very simple idea. All Channel 1 readings are measured for 10 LORAN square wave cycles. That makes 20 readings in total – one reading for each square edge (positive or negative). Then the average reading is calculated and compared to a value of “150”. If below this value, the 100 KHz reference is speeded up by increasing the dither ratio (of the digital load capacitors). If above this value, then it is slowed with a decrease in the ratio. It works delightfully and never fails to phase lock. In the aforementioned video, the second trace is the LORAN square wave, and the third trace is the Teensy 100 KHz generated reference. Notice how stable the Teensy signal is even though the LORAN signal is fairly wobbly.

At this moment in my project, I manually adjust the strobe signal (using a digital oscilloscope) in order to align it with the start of the selected 10 LORAN cycles. But I am currently working on an algorithm to identify the start of the LORAN master group of pulses, and thereby automatically adjust things to be self-aligning. The following picture shows a recording of the LORAN square wave as a series of binary digits for the period of the nine pulses. Each of the group pulses can be seen clearly in the pink highlighted portions. I record one digit of the signal on each pass of the ISR. Notice that pulse P1 and P2 are the same phase of ones and zeroes, but P3 and P4 are inverted phase. Then P5, P7 and P9 are non-inverted, whilst P6 and P8 are inverted. This is classic signal modulation for the first master LORAN pulse group. There are 200 bits between each pulse starting point (remember that each ISR pass is 5 uSecs), which reflect the 1 milliSec interval between each pulse. Naturally, some degree of signal noise can occasionally upset the sequences, but most pulses can be individually identified.

BitMap001.jpg

Here is a useful reference for the LORAN signal characteristics…

http://jproc.ca/hyperbolic/loran_c_sigchar.html

If readers of this project are interested in the code, and/or the design of the simple radio receiver, then I can add these on request. The radio uses a simple ferrite loopstick antenna so works well indoors without an external antenna.

Recently in the UK, the eLORAN transmission cycles have been adjusted to be synchronous with UTC. So when Teensy 3.1 is locked to them, then Teensy is phase locked to UTC. The 1 second BLINKY flashes seen in the video have to be some of the most accurate “Blinkies” produced  !!

These eLORAN transmissions also have a low bit rate data channel encoded within them. Further work should enable this data channel to be demodulated (for more info, search the web for EUROFIX). The data channel is used to provide differential corrections to the LORAN pulse timing, and thereby increase the accuracy of this timing/navigation system. A number of permanent receiver stations are monitoring the signals to make local corrections. This is not unlike the corrections made to GPS to improve its overall accuracy. One of the benefits of eLORAN compared to GPS is that the transmitters are working at high power levels so are much more difficult to spoof.
 
Tonight I took a photo of the LORAN radio receiver. The orange/white twisted pair in this photo is the feed to the NOR gate which can be seen in the aforementioned video. The scope probe here is picking up the yellow top trace in the video. The receiver is just a single JFET stage and a dual TL082 op-amp. This is then a.c. coupled to the NOR gate stage.

My biscuit tin and red wire to ground is an electrostatic shield to prevent a nearby AM 909 KHz transmitter (24 Km distance) from causing interference. This AM transmitter is in the direction along the line of the ferrite rod.

Dscf7823a.jpg
 
Further progress... today I have located the eLORAN data channel and taken the following interesting scope snapshot. I'm using a scope display persistence of 5 secs to show the extent of the trace phase movements.

Yellow trace 1 is the 100 KHz carrier. Purple trace 3 is the output of the NOR comparator (converts the carrier to a square wave) and contains the data. Blue trace 4 is the TEENSY generated 100 KHz reference which is phase locked to the carrier. Turquoise trace 2 is a GPS timed signal to locate the seventh cycle of the third slave pulse.

ThirdSlave7thCycle.jpg

Notice that the carrier appears to wobble back and forth (as shown by the background persistence) by a fair amount. There is noise on the carrier causing part of this wobble, but in addition, there is a 1 uSec phase advance, a zero phase advance, and a 1 uSec phase retard - all contained in that carrier wobble. These three states are used to encode the binary data (more of that in a moment). The zero crossings inherent in the purple trace shows this better. The picture is "snapped" at the instant of a zero phase advance, but you can clearly see that sometimes it moves 1 uSec to the left and sometimes 1 uSec to the right - and sometimes no phase movement.

The TEENSY phase locked blue square wave indicates how the peripheral clock in FTM1 is decrementing in time comparison. Each edge transition corresponds to an overflow of the FTM1 counter, counting down from 300 to zero. So by using the purple signal on CH1 (Channel 1), I can "freeze" the count value in code at the instant of the purple data edge (capture these readings in the ISR routine). If I do this for 10 cycles, that's 20 edges and therefore 20 readings. By taking the average value from those 20 readings, this cuts down the effect of noise considerably. The resulting count should be close to "150" for a zero phase shift, "210" for a 1 uSec advance of phase, and "90" for a 1 uSec retard. This is based on 60 MHz peripheral clock equates to 60 clocks for each microsecond.

The eLORAN pulses come in groups of 8 pulses spaced 1 milliSec apart. Pulse P1 and P2 have no data. But pulses P3, P4, P5, P6, P7 and P8 all have discrete pieces of data - these pieces are "three-state" symbols (in the true "baud" sense) and each symbol represents a specific 7 bit binary code. I watch and measure P1 (no data) in order to phase lock the TEENSY square wave to the carrier. I now can use the data symbols in P3 to P8 to reconstruct the binary data which is encoded. To make sure that the data does not upset the overall accuracy of the carrier timing, the data is encoded using "balanced symbols" meaning that within a group of pulses, there are even amounts of advance and retard - for example, the six symbols in P3 to P8 might look like "00+-+-" where "0" = no phase change, "+" = phase advance, and "-" = phase retard.

This means that not all combinations of symbols theoretically possible are actually used. In fact there are a total of 141 combinations of balanced symbols possible. This encodes 7 bits of data, which has 128 combinations. So 13 of the symbol combinations are not used. I have yet to obtain the spec for the mapping of symbols to binary data, so at the moment I can capture symbols, but I cannot yet decode this to see the data contained within them. The data takes the form of several message types (like GPS messages) and is found in the Eurofix spec.

Notice how well the blue TEENSY square wave has phase locked with very little jitter - even though the noise on the carrier is quite high. I guess about 150 nanoSecs of jitter. And the data within the purple trace falls neatly into the blue half cycles - even with noise and symbol data modulating it back and forth. It is claimed that eLORAN can deliver a 50 nanoSecond timing reference at its best performance. Mine is a very simple phase lock algorithm.

Within one specific pulse (say P3) the actual symbol encoded remains fixed throughout the pulse. So averaging any value measured is a good way to reduce the effects of noise. And there is a lot of noise in the 100 KHz radio band. To restrain the effects of this noise on data integrity, REED-SOLOMON forward error correcting bits are added into the eLORAN data stream. This makes it very robust. The LORAN scheme uses time domain multiplexing to permit many transmitters to use the same 100 KHz frequency allocation (20 KHz bandwidth), so there is going to be other interference as well as natural atmosperic noise.
 
Last edited:
Me too ;)
Is it possible to receive the LORAN signal in Germany with a simple antenna ?

I did not do the maths, but would be important to check if travel time difference to the sky-wave bounce is large enough to extract undisturbed ground wave.
 
A note of interest for those of us in North America: All US and Canadian Loran transmitters were turned off in 2010 since the US Coast Guard and the CCG, the last remaining users, deemed them redundant. They continue operation in the EU due to security concerns with GPS and EMP disruption.
 
Very nice project, although I have not yet understood the details of it, will have to read more.

LORAN transmitters are still operational here in Central Europe, you can hear them on the WEBSDR (tune to 100kHz): http://websdr.ewi.utwente.nl:8901/

The only German LORAN C transmitter on the island of Sylt is still active, since the renaissance of LORAN C as e (enhanced) LORAN.

https://www.elwis.de/BfS/bfs_start.php?target=3&source=2&db_id=1765

So a ferrite rod should be sufficient to receive LORAN in Central Europe, especially since the transmitter power is high (250kW !).

Are you sure that there are no operational LORAN transmitters in the USA right now, even in test mode? There is much outdated material in the www, I found very recent discussions on the topic "Backup Global Positioning System" from the US government, but I am not sure whether the e-LORAN system is already/again in operation in North America:

http://www.gps.gov/policy/legislation/loran-c/

Does anybody know more details?

Frank
 
Been a bit busy over the last few days. I have managed to get hold of a copy of the symbol table to 7 bit binary conversion, and I have coded an algorithm that does the conversion. But I have yet to decode the 7 bit binary into meaningful data (on with that now). The message structure is a little tricky being 7 bits rather than 8. Very pleased with the phase lock that TEENSY 3.1 produces, giving stable data reception.

Each EUROFIX message consists of 30 consecutive symbol patterns - you get one symbol pattern (6 symbols) in one group of 8 pulses (P3 to P8), which in the UK is not included in the master group but only in the slave group. Anthorn transmits both master and slave now, because the master is supposed to trigger the slave, so I guess that when the master was shut down at Lessay, France (31 DEC 2015) then Anthorn included it to give a complete master/slave relationship still "on air".

Of these 30 consecutive symbol patterns, the first 10 carry the actual data and the other 20 carry the REED-SOLOMON parity forward error correction. As each symbol pattern results in a 7-bit data block, then the data is 70 bits long (B1 to B70). Of those 70 bits, the first 4 bits (B1 to B4) are the "Message Type" and type "5" is a so called "Text Message". The last 14 bits (of the 70 = B57 - B70) are CRC. After Message Type, there are 3 bits of "Sequence Number" and an "End" bit (B5 - B8). This leaves 48 bits as actual text data (B9 - B56) formed into 6 bytes of 8-bit ASCII lower section (0x00 to 0x7F) with cyrillic chars in the upper section (0x80 to 0xFF).

As I said :p its a little tricky, and for real-time decoding I need to make it efficient to avoid data over-run. For those 30 symbol patterns, by the way, the Anthorn GRI (Group Repetition Interval) is every 67,310 uSecs = approx 15 per Second (15 Hz), so each complete EUROFIX message takes about 2 seconds.

The Anthorn transmitter is (as I write) "off the air" during daytime for maintenance, but comes back on around 16.15 hrs BST, so this is slowing me down a little. I think they are making some changes too to get it synch to UTC. I notice that the slave group keeps altering its timing with respect to my GPS module.

I am not yet sure which "endian" is in use for the data, but I'm working first on the premise that everything will be "little endian" including the symbol pattern. Time will tell...

In respect of US activity, there was a little bit here that confirms one of the recent comments...

http://gpsworld.com/eloran-and-lora...s_navigate_06062017&eid=377041690&bid=1776454

I think you might appreciate why South Korea might be interested in this technology.

When time permits, I'll post a circuit diagram of my hardware to show how easy it was to build this on prototype board without hardly any soldering.

Good source of info here... http://www.ursanav.com/wp-content/uploads/UrsaNav-ILA-40-eLoran-Signal-Specification-Tutorial.pdf

Somewhere on the web, I saw an Anthorn signal/noise map colour coded throughout Europe. Might be able to show if the signal is available in Germany. If I come across it again I will post a note.
 
Last edited:
Some recent pictures of interest...

This first picture shows the relationship of the Anthorn Master Group of pulses with those of the Slave Group. It also shows (purple) my TEENSY created "strobe signals" (using digitalWriteFast on an output pin).

AnthornMasterSlave.jpg

Trace1 (Top) = Signal from radio receiver. Trace 2 (Bottom) = GPS reference set to 67310 uSecs GRI period. Trace 3 (Second) = TEENSY created strobe pulses. Trace 4 (Third) = TEENSY 100 KHz generated reference (in phase lock with Trace1). I use the ISR from TEENSY's FTM1 (Modulus = 300) to create the Trace 3 strobes. The ISR happens exactly every 5 uSecs (as a result of 100 KHz exact from Trace 4) when the TOF (timer overflow) happens. I maintain a count of every pass of the ISR (67310 divided by 5 = 13,462 passes each GRI). By altering the zero timing of this counter (simply by manually adding a value to it with the serial monitor, and wrapping around on 13,462) I can nudge the strobes using the scope so that they co-incide in time with the carrier pulses. The phase lock means that onced nudged, then they stay put w.r.t. the carrier. Notice that I only use pulses P1 and P3,P4,P5,P6,P7,P8. P1 carries no data and gives me the phase lock reference. The others carry the 6 symbol modulation of plus, zero or minus 1uSec.

SlaveStrobePulses.jpg

The above picture shows more detail on an expanded timebase.

P3SlaveStrobe.jpg

And even more detail on this one above, which is centred on pulse P3 expanded (the first pulse carrying a data symbol). The strobe pulses merely indicate the exact ISR pass where I read the data gathered from channel CH1 of the FTM1 timer. This data is there for every ISR, but I only want to record it for the 20 instants that correspond to those cycles in the middle of the P3 pulse. Because FTM1 counts down from 300 to 0, CH1 will trap the clock reading somwhere in the middle of the cycle when the zero crossing happens on the carrier - remember my NOR gate is squaring this carrier sine wave, so has a rising or falling edge which is triggering CH1. (10 carrier cycles give 20 edges).

If the CH1 reading was in the exact centre of my TEENSY 100 KHz sq wave, then it would read "150". If it happens slightly earlier (due to the data modulation of -1 uSec) then it would be "210" (it is counting down from 300) and if later (due to modulation +1 uSec) then it would be "90" (60 MHz drives the FTM1, so 60 clocks for every 1 uSec). By measuring this 20 times and adding all the values together, then they will come to 20 times 210 = 4200 for a -1 uSec symbol, 20 times 150 = 3000 of a 0 uSec symbol, and 20 times 90 = 1800 for a +1 uSec symbol. My code can then set a threshold at values 3600 and 2400 to decide which of these three states the symbol is for that particular pulse P3. The shift is the same for all cycles within one pulse. I need to do this for all six pulses from P3 - P8. This means that the ISR routine is quite busy. I timed it and it took 2 uSecs (using FASTRUN for the ISR) so that still gives me 3 uSecs left for the main loop to do any more data processing. Once the P8 pulse has passed by, then I have 67,310 - 8 = 67,302 uSecs before the next Slave P1 will arrive.

P3Data.jpg

This last picture shows the data from the NOR gate on Trace 3, and it appears quite clean. It's much better than the previous picture I posted because I found that I could reduce the noise picked up by the ferrite antenna from my computer if I used a Tablet running on its own battery rather than a desktop (the Tablet has 2 USB2 ports, 1 for the TEENSY, and 1 for the UBlox GPS module). The wobbling you can see on the carrier is from another BBC AM transmitter on 909 KHz, which is not that far away. Moving the ferrite can help null this out, but its a balancing act with the maximum signal direction from Anthorn.
 
Last edited:
Hi Telephone Bill.
I too am interested in frequency standards, and Vlf.
I have made 3 frequency standards using Radio4, MSF and GPS.
A pic of my latest the MSF standard is attached, there are 3 Pll's, one stretches the 60kc tonebursts into a continuous 60kc, another is used to convert the 10mc ocxo down to 60kc, and the third compares these 2 and generates the control voltage for the ocxo, it works well, and is at least as accurate as Radio4's transmission, which is the most accurate thing I have to measure it with.
I used some ideas from one of andy smith's projects, he has a webpage for a msf synced frequency counter, we worked on improving his design for the Msf front end, you can it see on the end of the page:
http://g4oep.atspace.com/counter/counter.htm
The Radio4 standard is a cobble togther of magazine articles, webpages and my own designs, it too works well, the biggest issues with it were the modulation on the carrier.

I'm interested in your loran project, I've been thinking about making something like that for a while, only the pending doom of the service has kinda put me off.
You mentioned the code further up, I'd like to see this, and burn a chip and see if what I can do, I'm close to anthorn and get a good Msf signal on 60kc, however 100kc loran doesnt come through that well, however the omly thing I've tried to get it on is a sdr receiver with a miniwhip, a resonant magnetic antenna would probably be much better.
Is the rx for the loran project similar to your msf receiver?, 100kc crystals are easily available so the same circuit would probably work, allthough I might try a larger air core loop aerial, on sdr the bandwidth for loran is quite wide so I'm not sure if an xtal would be the way to go.


I dont spose I really need 4 frequency standards, I just like the idea of building them.
89022-0b685c4cadd14ce27498e34a4c7bca63.jpg
89024-1556d09750e446b91f7550816ae80a46.jpg
 
Last edited:
Done some more research.
I get loran a bit better now, although one thing not clear is the slave transmitters, surely there needs to be distance between them for accuracy, does everything come from anthorn?

An xtal in the rx would be pointless for loran, your going off the first pulse burst in the repeat group to sync the teeny's clock on each group, an xtal filter would mess this up.
So your rx is similar to the Msf one, only without what you refer to as the forced oscillator, thats simple enough.

I spose you could apply this technique to Msf too, using only the first few cycles of Rf on each second to sync the tenny's osc, only sync would only happen every second instead of about 10 per sec with loran, still something for me to bear in mind in receiving loran isnt an option.
I ought to get a really good signal, I'm the other side of the pennines to you, not too far off blackpool, Msf comes through fairly well.

I'm considering both digital and analogue control methods at the moment just for the interest, one analogue approach not amazingly accurate could be just to stuff the squared o/p from the rx into a Pll and compare the received 100kc to a divided down 100kc from a voltage controlled xtal osc, it would be interesting to see how accurate such a simple approach would be, if depends if the gaps in the pulses are 'joined up', in other words if there were no gaps the waveform would be contiguous, this being the case reception noise plus sky wave reflections would be the source of any errors, this would be a slight improvement on my Msf design.
Kinda makes the proposition of a micro controlled system appealing, or maybe a combination, ie use the first pulse burst sync signal from your design to control a 4046 Pll.
 
Greetings Dr Pepper. Now with "kc", you are showing your age :) It must be 1960 when "Hz" replaced it !! (Tip: When posting pictures, upload a reasonably sized jpg image. The forum software will reduce its size in the posting, but readers can then click on it to expand and see the full glory. I can't see the beauty of your work on these postage stamps).

I too have a love of methods to establish frequency standards, and in addition to MSF, I have locked to BBC Radio4 on 198 KHz. The problem with both Radio4 and MSF signals is that they suffer a small and very slow phase shift throughout the day due to the skywave getting stronger as the sun reaches zenith. Loran avoids this, as I described earlier. Much of what this current Loran project uncovers w.r.t data demodulation should be applicable to Radio4 as this signal too has carrier position modulation. There is a BBC "White Paper" on Radio4 data modulation (http://downloads.bbc.co.uk/rd/pubs/reports/1984-19.pdf), well worth the read.

Fine on G4OEP's work. Teensy's ARM processor is light years ahead of the 6803, as you will discover when you experiment with one. And the Teensyduino/Arduino environment makes it pure joy to work with. You can add "assembler code" too if you need to. I wrote an forum article on this sometime back.

To get the benefit of the Teensy Freescale chip, you need to study the FTM timers in detail. It's not difficult to program these and there is a lot of info in the forum to help you. The K20 chip reference guide is a good source but sometimes harder work. Key to understanding is the channels. They can be outputs as with CH0 in this Loran project, or inputs as per CH1.

Below are my two schematic diagrams for the analogue and digital circuitry. The receiver does not use a crystal in this project. It's a very simple tuned circuit with three stages of RC coupled amplification. The output is about 1 volt pk to pk for the peak of the Loran signal at my location. In "Note2" I use a 100pF cap to aid the slew gain of the last stage. This was a late idea, but sometimes large noise surges can throw the receiver into sustained oscillation, and then you need to power down and back up to get it stable once more. I also have a local MW 909 KHz transmitter only 18 Km away, so I point the ferrite "null" in this direction, and the RFC of "Note1" is an attempt to reduce interference. You could replace the RFC with a 10K resistor. I use both main LW and MW coils of the ferrite to get maximum Q, and I ignore the few turns "tickler" windings completely.

In the digital circuitry, the NOR gate is biased to be a sensitive "zero-crossing" sq wave detector. It will "rail to rail" on just noise, but its output becomes very regular sq wave when the pulses of Loran 100 KHz arrive. Ideally, this should be a 50/50 duty cycle waveform for the Loran signal, and the parallel 100K at the input adjusts this - a pot might work good. The output of the NOR gate drives CH1 internal to Teensy on pin 22. It operates on both rising and falling edges, so 10 cycles of Loran give me 20 readings, which I sum together like an average (no point in dividing by 20 as this just adds more cpu consumption).

I link the analogue and digital circuits using a length of 1.5 metre twisted pair wire (extracted from local area network cable).

I will upload my software shortly when I have tidied it up a little. I will also run through an explanation of how it works.

LoranReceiver.jpg

LoranPhaseLock2.jpg
 
Last edited:
You have beaten me to posting my response, so I'll let you digest it now it's up. Agreed, no crystal in this design other than that on board Teensy. My software has a manual frequency control to illustrate how good the Teensy signal is. You can get a very, very slow drift without using phase lock (parts per million). But temp changes etc will alter things, so a phase lock is the best.

Done a lot of work in this area over two years. My experience is 4046 designs are good. But gaps in carrier timing can introduce as many "bad effects" as they can "good ones". A surge from a skywave on MSF can throw the timing out by microSeconds and then revert some seconds later - hard to exclude these effects with an analogue PLL. The Teensy gives me the capability of "digital filtering" without all the hard maths. I'll illustrate how when the software is posted (its a bit like SDR techniques). Using the "best available cycles" from Loran is much preferable to "not so accurate cycles" from any source. If you want more stability, strobe these "best cycles" form one group to another over long periods, and "infer the gap in between". You can do this with digits. Not so easy with analogue values.

By the way, I'm looking for nanoSeconds accuracy. About 100 nanoSecs today with my best low noise Tablet control.
 
Last edited:
I'm not that old, I just had tutorship from an old hand and also got taught some thermionics, I grew up in the 70's.
I've been having lots of trouble with pics, new phone!

My R4 standard when multiplied to 10ghz has an audio tone similar to a theramine, the Msf one is a lot better, but that has an ocxo, and the loop filter is in the order of minutes, which is a pain for startup.

Yes the 6803 is a bit of a relic, I learned with 6502 & z80, but quickly progressed to pic & avr, I have been playing with some stm32 modules with a F103 chip, 'blue pill' clones, my first experience with 32 bits.
Noted on the timers, I'll look up the teeny's spec, maybe order a couple.

Thanks for the notes on the Rx, I'll try that this weekend I have some tube radio loopsticks knocking about, I've never tried shielded loops I found an interesting article online that uses multiway Idc cable to shield a loop without causing eddy currents.

I was going to lash up a 4046, however I'll wait for progress and see if I can suss out the teensy, gating the sync as you explained removes skywave reflection error making good or correct use of loran, I had no idea the teensy was that powerfull, thought it was a at328 or something.

I'd like a system ultimately with a 1x10-9 stability, accuracy is fine well below that.

Nanoseconds at 100kc is extremely accurate I didnt think the resonator at anthorn was that good.
 
Last edited:
I'd like a system ultimately with a 1x10-9 stability, accuracy is fine well below that. Nanoseconds at 100kc is extremely accurate I didnt think the resonator at anthorn was that good.

A Teensy on its own simple crystal would not approach this stability level. Without some form of temperature control it would be wishful thinking. N.I.S.T. has an excellent paper discussing "accuracy" and "stability".
 
My existing Msf standard has a xtal oven and to be honest is stable enough for my needs, I have 3 other off air standards and like the idea of loran, none of my existing ones use a processor, this makes things more interesting.
I spose I'm saying I'm not chasing a particular result, I'm just having fun.
I'm going to throw together the rx circuit today and see what kind of signal I can get, might just retune the Radio4 or Msf receiver as a trial.
 
I lashed up a loopstick & preamp tuned from my sig gen to 100kc.
But theres no transmission, or at least as far as I can tell, my sdr shows nothing at 100kc, Msf on 60kc came back at tea time.
Has Eloran shut down completely or just during the day like Msf, cant find anything on the net about it.

Edit: using this site I was able to attempt to receive loran from around the uk http://www.websdr.org/
I can get loran from Grimsby, Southampton and Peterborough, but not from Bedford.
If the only transmitter is anthorn then it must be my gear, I could pick it up last week loud & clear, now 3 receivers cant hear a thing.
 
Last edited:
Yep. The transmitter has been off-air during daylight hours recently for maintenance. It normally comes back on about 5pm (presumably when the riggers climb down again :)). I'm led to believe that this maintenance would be on-going up to Aug 24th. maybe their schedule has over-run a little.

I found that the best way to see the Loran pulses on a scope was to use a GPS reference pulse, set to a period of 67310 uSecs, and wind the scope timebase back to many milliSecs. You can then see the pulses frozen on screen - if they are present. Its useful also to be able to use the GPS reference as a precision delay (nanoSecs) to be able to pick out (strobe on to) individual cycles from the Master or Slave groups. This was the motivation behind the new post of "A UBlox GPS Module Primer for beginners" which I wrote up yesterday.

It could be argued that if you have a GPS signal generator, then why bother with either Loran or MSF. Fair point. One advantage of ferrite loopsticks is that they work almost anywhere indoors, whereas sometimes its difficult to get a good spot for a GPS antenna. This, of course, is the main argument for "eLoran". Its also a lot cheaper than rocket boosters and easier maintenance than a space walk.

I really enjoy the Teensy capability of picking up radio signals and processing them in real time. I'm looking forward to Teensy being a smart way to decode the data available from "eLoran". I think the sub-contract for this new service is about 15 years, so I'm expecting it to be around for some time.
 
That is another use of a stable timebase.
I have a ublox, I'd need to put it somewhere else other than my 'lab'.
I definitely have an issue receiving loran, I just tried some of those web Sdr's, nothing, last night they worked but my setup had nothing, a couple of times I thought i heard the ticking of loran so maybe I need a better antenna, might try a large air core loop, I have a few rolls of bell wire.
 
Just had a look for the signal myself, and it's down at 15:35 hrs BST on Bank Holiday Monday. The riggers will be on double (or even treble) time today !!

I think things are over-running the schedule and until things get back to normal - hard to predict availability. One other change is synchronisation with UTC. I noticed last night that the Slave pulse times are not the same (w.r.t UTC) that they were a few days ago. Both Master and Slave come from the same site, so you are correct when you infer that navigation won't work. I think this too is a temporary set-up.

If you get MSF alright, then Loran should be there too - if the transmitter is switched on. Unless you are in some shadow, your signal should be better than mine.
 
Another argument for Loran if you really want reliability: GPS jamming and even GPS spoofing, while possibly not widespread, is a real thing.
 
I turned down weekend rate this weekend too.
Using a websdr I've been monitoring the loran signal, graphically it looks different, it used to look much like noise but more uniform, now it has a wavy pattern, backing up what you say about the codes changing.
I'm kinda confused if this is sposed to be a navigation signal but cant be used for that why broadcast it, is there something we dont know I wonder.
I sussed picking up the signal at home, its my upconverter, not being in a box yet it picks up noise on the bench and blanks loran, I configured my sdr to direct sample and yes I can get the signal, but there is some noise so I might need the loopstock in a can too.
Yes I believe gps jamming was going on in korea recently, satellites being 50w and loran being 50kw makes a difference jamming wise.
I'm going to see if I can get the master and slave transmissions up on the 'scope later on today, the only working references I have are radio4 and msf ones, during daylight though I might be able to get good traces.

Loran.jpg

Loran is in the centre of the screen, the mess to the left is the wife watching telly (crt), and the green line to the right no idea, but its in the loran band.
 
Last edited:
Status
Not open for further replies.
Back
Top