*** STILL UPDATING THIS PAGE :) ***
*** STILL UPDATING THIS PAGE :) ***
The earliest electronics relied exclusively on crystal oscillators to keep time in their internal circuitry. These oscillators utilize the piezoelectric effect to generate a roughly uniform square wave. While this is sufficient for standalone devices, networked devices rely on highly synchronized clocks to ensure reliable and timely data transmission, enforce network security, and properly sequence events. Even a small drift in clocks between networked devices can cause major issues across the network. When only relying on piezoelectric crystals, small differences in clock frequency can arise from minor physical differences in crystals, electromagnetic interference, and changes in temperature. Their clocks will slowly drift over time, but this can be mitigated with frequent clock synchronization.
The vibration of an unperturbed Caesium-133 atom is one of the most regular phenomena known which is also readily available to be studied. Since 1968, the S.I. definition of a second has been the amount of time needed for a Caesium-133 atom to vibrate 9,192,631,770 times. An atomic clock is a piece of equipment which monitors these vibrations and updates the time accordingly. The National Institute of Standards and Technology ("NIST") oversees multiple atomic clocks in Fort Collins, Colorado. While any one of these is more accurate than a crystal oscillator, they are still susceptible to deviations caused by factors like temperature and gravitational fields. NIST uses multiple of these atomic clocks to establish a consensus between them, filtering out deviations in any single clock.
NIST oversees an atomic clock in Fort Collins, Colorado, which transmits a precise time signal via a radio station, WWVB. The signal is used by people and institutions all across the nation to sync their devices to the official time. WWVB encodes data as both an amplitude and phase modulated signal on a sixty-kilohertz carrier frequency. While phase modulation decoding is non-trivial to implement, amplitude modulation decoding is simple and provides plenty of information on the current time.
The purpose of this project is to create a radio receiver to receive, filter, and amplify the WWVB broadcast signal such that it can be fed into a microcontroller and decoded. From this, a time code can be established that is accurate to within one millisecond. This time code can be displayed, used for scientific data collection, or broadcast to devices on a network to synchronize their operation. In this particular case, we will be able to show time through an OLED display at the end of the process.
The applications of this device are not very apparent at first glance, but there are many. The main use of this device would be for extremely precise timing. The WWVB signal is run off of an atomic clock. Missiles, sensors, aircraft, and ships rely on atomic clocks normally broadcasted by GPS to function. Those same devices require very small timing error, or their calculations can become inaccurate. This could result in missiles missing targets or ships arriving at the wrong destination. The entire U.S. government and most U.S. based corporations rely on this clock to keep everything in check, and it truly is something that impacts our everyday lives.
The time code sent by WWVB follows a standard encoding scheme, and research was required to understand the format and how to decode it.
The timecode algorithm will involve two major steps, first the actual receiving and decoding of the timecode into a 60-bit code and next the interpretation of this time code into the respective time and various control signals needed for the proper display of the time. These will be outputted by the various pins on the Nucleo-32 microcontroller to a display to be designed. The Timecode will be received over the course of 1 minute with 1-bit being sent each second. This means that in the worst case scenario, the timecode will take approximately 2 minutes to complete to receive the accurate time. The end result will be a time output that will be an incredibly accurate timecode.
Once the program begins. it will start to poll the input for the radio signal once every 0.05 seconds and store is the value is low or high. This means that 20 polls will be taken each second. If 4 of these polls are low at the start of the second, a 0 will be interpreted. If 10 polls are received low, a 1 will be interpreted. If 16 polls are received low, a position marker will be noted. These position markers are simply easy to denote the perspective spot in the minute and are sent every 10 seconds. They can be decoded to either a 1 or 0 as they have no effect on the output time. Once the start of the minute is detected, each bit received will be appended to the end of a 60-bit code. Once the full code is received after 60 seconds, the time can now be found. This was the first solution thought of for the decoding, but it has its flaws. If we receive the full code will we be able to process it fast enough to give an accurate time.
The time code can be interpreted from the second image below. This table can be used after we have interpreted the signal into ones and zeros. The most important bits are the marker bits. These marker bits will be used to track the section being received. The first marker bit of a timecode is longer than the other markers this will give us a precise starting point. The first data section bits 1-8 contains the current minute. This is followed by another marker bit and two bits that are always 0 these will be known as null bits. Bits 12, 13, and 15-18 represent the hour. Bit 14 is skipped because it is a null bit. This is followed by another marker bit and two more null bits. The next data section gives us the year the bits that hold this data are 22-33 except for 24 which is another always null bit and 29 which is a marker bit. The rest of the information in the time code is gathered like this. The weights of the bits are not like normal bits, so this will be another technical aspect to be dealt with. The current way this is done is by hard-coded values. Using this table the weights can be assigned appropriately in the code.
There are a few easy ways to detect errors with no major changes to the code. The following methods can be combined to strengthen the individual detection components. The first key method is the reference markers. These will be decoded differently than the 0s or 1s. There are 7 reference markers for the entire message. The first section of the message (0s—10s) contains 2 reference markers, one at the beginning and one at the end. The other 5 sections, 10 to 60 seconds in sets of 10, contain one reference marker at the end. If one of these is missing while decoding we can detect an error. The second method is to use the always 0 bits. In total 10 bits of the message will always be 0. If any of these are missing then the message either is decoded incorrectly or the data is corrupt. The third method is to check if the data is even valid. Let us say for example the message decoded to 3:70, we would understand that something is very wrong naturally. In our code, we can put checks to detect an invalid code. Using these all together greatly enhances our ability to detect errors.
The output of the microcontroller has not been decided yet. This will change depending on whether it is driving a clock or acting as a time server for a computer.
The software decoding algorithm is currently complete but has not been tested yet. A problem we have thought of is the accuracy of the time after the entire process. The time code received has to travel from Colorado to wherever this device is located. This won't be very significant for the clock, but it is one delay in a process that has a few. The hardware takes time to convert the signal and the device to decode takes even more time. As of 11/6, we are still discussing the implications of this and different ways to overcome this hurdle.