{"id":978,"date":"2026-06-24T16:21:27","date_gmt":"2026-06-25T00:21:27","guid":{"rendered":"https:\/\/salemdata.net\/johnpress\/?p=978"},"modified":"2026-06-24T16:21:27","modified_gmt":"2026-06-25T00:21:27","slug":"testing-satellite-time-synchronization-across-seven-t-beams","status":"publish","type":"post","link":"https:\/\/salemdata.net\/johnpress\/?p=978","title":{"rendered":"Testing Satellite Time Synchronization Across Seven T-Beams"},"content":{"rendered":"
<p>The LilyGO T-Beam Supreme has a real time clock, aka “RTC”, circuit powered by a small hidden rechargeable battery that can hold a charge for 2-3 days.\u00a0 If your T-Beam is without power from A) its larger battery, a 18650 Li-Ion battery or B) a powered USB connector, then your stored date and time value will be lost after 2-3 days. <\/span>1<\/sup><\/a><\/span> The loss of current date and time can be easily fixed, if your firmware anticipates this condition, by fetching satellite time and synchronizing the RTC and maintaining a date-time register (memory storage). When you want to synchronize to satellite time, you do have to expose your T-Beam to several satellites by taking it outside or placing it near a window that can see several satellites. To establish its own full position-and-time solution, a GNSS receiver normally uses signals from at least four satellites. The receiver compares the transmitted timing information with when each signal arrives, solves for its own position and clock error, and then can provide an accurate timing reference.<\/p>\n<img class=" wp-image-980" src="https:\/\/salemdata.net\/johnpress\/wp-content\/uploads\/2026\/06\/20260623_045648_Tue.png" alt="circuit board with button battery" width="536" height="483" \/> Real Time Clock Circuit\n<p>The RTC precision is down to the second, not milliseconds. This precision should be adequate for everyday use where sub-second precision is not needed. But for testing and logging what happens within the T-Beam using Reticulum’s transport, millisecond precision of time along with synchronization of all units involved in the test is warranted. For example, if you log that AMY sends a message at 14:02:33.407 (the “407” represents milliseconds, or thousandths (407 of 1,000) of a second) and BOB logs receipt of the same transmission at 14:02:33.023, you want BOB to be in sync with AMY, otherwise a BOB log entry of 14:02:33.023 means BOB is on a different time scale. You want to see BOB receiving the message at 14:02:33.407 or later depending on how long it takes to actually transmit and then for the LoRa circuitry to demodulate the incoming message.<\/p>\n<p>Thus, the goal is to have the T-Beams share the same “wall clock”<\/span>2<\/sup><\/a><\/span> time so that their logs match the same time as close as possible. Using the RTC stored seconds-precision is not precise enough as units could be off synchronization by as much as 1 second or more. A lot can happen in radio land during one second.\u00a0 Without time synchronization, correlating logs files generated by several T-Beams becomes almost impossible — you would have to know how much each unit varies from another. Therefore, one cannot rely upon the RTC to provide commonality of time among several units.\u00a0 For precision analysis of logs, the date and time stamps must be as synchronized as possible.<\/p>\n<h2>Synchronizing Time<\/h2>\n<p>Back in the Age of Reason, i.e. the 1960s, if you wanted to know what the current time was, you could dial 853-1212 and the telephone company would have a recording answer with “At the tone, the time will be 3:45 and 20 seconds… BEEP”.\u00a0 <a href="https:\/\/salemdata.net\/public\/telephone_time.wav">Here<\/a>‘s a recreation of such a message<\/span>3<\/sup><\/a><\/span>.\u00a0 When you heard the BEEP, you would know that US time was 3:45:20.\u00a0 You could then set your clock accordingly and feel that your clock is now synchronized close to a second.\u00a0 Remember, though, clocks drift, and one month from now, your clock may be off, so you could call telephone time and reset your clock.\u00a0 When daylight savings time would start or end, calling time was a convenient moment in the year to reset clocks.\u00a0 Also, at New Year’s Eve parties when midnight approached, someone could call time so everyone would know precisely when the new year started and thus set off their firecrackers with joy.<\/p>\n<p>The critical component of calling telephone time is that your are fore-warned with the necessary information, e.g. “at the the tone…”, about an event which is about to occur: the BEEP, so you could have your electric clock set to the second and then when you heard the BEEP, you could power on your clock.<\/p>\n<p>In sporting events, such as track and horse racing, every contestant needs to start from the same time, so instead of beeps, you have a starting gun.\u00a0 When everyone hears the starting gun blast, they know they can begin the race and everybody is starting from the same event: the gun blast<\/p>\n<img class=" wp-image-982" src="https:\/\/salemdata.net\/johnpress\/wp-content\/uploads\/2026\/06\/track_race_with_dog.png" alt="1950s style cartoon of 440 track race with a dog as a contestant" width="513" height="385" \/> BANG! They’re off!\n<p>See the article “<a href="https:\/\/dev.to\/rezmoss\/monotonic-clocks-and-precise-time-measurement-210-2ah5">Monotonic Clocks and Precise Time Measurement<\/a> ” for a more complex analysis of time in computer networks.<\/p>\n<h2>Satellite Time<\/h2>\n<p>The same concept as the starter gun in a track race, or the telephone company BEEP, is used in satellite time.\u00a0 A constellation of satellites is in the sky, they are coordinated by atomic clocks to send time signals as pulses and the GPS units on the T-Beams collects several satellite’s signals and calculates its position to determine the loss of time it takes to send the signal to the current location.\u00a0 This is called getting a “fix”, you usually want to have 3 or more satellite signals.\u00a0 In my backyard, surrounded by tall trees, I can see 12 satellites.\u00a0 Here’s a simplified diagram showing 6 satellites sending time signals.\u00a0 The satellites continuously broadcast precisely timed radio signals. Because every satellite is at a different distance, each signal reaches the receiver after a different propagation delay. The GNSS receiver solves those delays, its position, and its own clock offset. Once it has a stable solution, the receiver produces a local electrical timing signal: one pulse per second, commonly called PPS [pulse per second].\u00a0 You will see in the documentation of time-related software “pps” or “PPS” commonly used.<\/p>\n<a href="https:\/\/salemdata.net\/johnpress\/wp-content\/uploads\/2026\/06\/constellation_of_satellites.svg"><img class=" wp-image-983" role="img" src="https:\/\/salemdata.net\/johnpress\/wp-content\/uploads\/2026\/06\/constellation_of_satellites.svg" alt="diagram of planet surrounded by six satellites" width="539" height="539" \/><\/a> A Few GPS\/Time Satellites\n<p>The ESP32 has a continuously running timer that can report elapsed time with microsecond resolution. By itself, that timer will drift relative to UTC. Exercise 28 repeatedly anchors it to the GNSS receiver\u2019s PPS edge, allowing the firmware to interpolate the microseconds between one precisely marked second and the next.<\/p>\n<h2>T-Beam pps Synchronized Software Clock<\/h2>\n<p>In a T-Beam exercise <\/span>4<\/sup><\/a><\/span> each T-Beam receives a very precise \u201ctick\u201d from the GPS receiver once per second, called PPS\u2014short for <em>pulse per second<\/em>. Think of it as seven runners all hearing the same starting pistol every second. The GPS messages tell the T-Beam which numbered UTC second that tick represents, while the ESP32\u2019s own continuously running timer fills in the tiny fractions of a second until the next tick arrives. By repeatedly lining up its internal timer with these GPS second marks, each T-Beam can assign an accurate time, down to microseconds<\/span>5<\/sup><\/a><\/span>, to events it sees or sends. The small battery-backed clock on the board is not being used as this precision clock in Exercise 28; it is only a separate, coarse clock that can retain ordinary date-and-time information when the unit is powered down.<\/p>\n<p>To visualize when the PPS arrive, I have the units display for 18 milliseconds on the OLED display a “flash”.\u00a0 Thus, when all 7 units have stabilized their time readings, they should all be flashing at the same time.\u00a0 I recorded the flashing sequences using a camera that can take 59.94 frames per second. <a href="https:\/\/salemdata.us\/videos\/tbeam_PPS_sync.mp4">Here<\/a>‘s a sample of the video.<\/p>\n<p>But we must not rely on the naked eye to witness <em>if<\/em> the units are all in sync.\u00a0 Instead, I inspected some select frames from the video.\u00a0 Here is some math: $$1\/59.94=16.68 ms$$<\/p>\n<p>The display time I arbitrarily set for 18 ms: $$kPpsFlashMs=18 ms$$<\/p>\n<p>Therefore: $$18\/16.68=1.08 frames$$ which should be a sufficient strobe. Because the 18 ms flash is only slightly longer than one 16.68 ms video frame, a PPS event may appear in one frame or be divided across two adjacent frames, depending on where the camera\u2019s frame boundary falls. The video therefore provides a useful visual check, but not a measurement at microsecond precision.<\/p>\n

Frame Captures (59.94 fps)<\/h2>\n\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t
Frame<\/th>Photo
\nLeft -> Right: AMY BOB CY DAN ED FLO GUY<\/th>		Comment<\/th>\n<\/tr>\n<\/thead>\n
37<\/td>
\"7
Frame 37<\/figcaption><\/figure><\/td>
No Strobe<\/td>\n<\/tr>\n
38<\/td>
\"\"
Frame 38<\/figcaption><\/figure><\/td>
Partial: BOB<\/td>\n<\/tr>\n
39<\/td>
\"\"
Frame 39<\/figcaption><\/figure><\/td>
Partial: BOB CY ED<\/td>\n<\/tr>\n
40<\/td>
\"\"
Frame 40<\/figcaption><\/figure><\/td>
Partials: AMY BOB CY DAN ED<\/td>\n<\/tr>\n
41<\/td>
\"\"
Frame 41<\/figcaption><\/figure><\/td>
Full: AMY BOB CY DAN ED, Partial FLO GUY<\/td>\n<\/tr>\n
42<\/td>
\"\"
Frame 42<\/figcaption><\/figure><\/td>
Full: AMY DAN ED FLO GUY<\/td>\n<\/tr>\n
43<\/td>
\"\"
Frame 43<\/figcaption><\/figure><\/td>
Full: FLO GUY, Partial: AMY DAN ED<\/td>\n<\/tr>\n
44<\/td>
\"\"
Frame 44<\/figcaption><\/figure><\/td>
Partial: DAN FLO GUY<\/td>\n<\/tr>\n
45<\/td>
\"\"
Frame 45<\/figcaption><\/figure><\/td>
No strobe<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nCaptures of video frames where the OLED display is flashing to indicdate a satellite pulse has been received.<\/span>\n\n<h3>Frame Capture Discussion<\/h3>\n<p>Ideally, I was hoping for 3 frames, 2 frames showing partials bounding a frame show all in full.\u00a0 Remember, each frame represents 16.68ms, so having 8 frames represents 133.44ms of time.\u00a0 ChatGPT cautioned that:<\/p>\n<h3 style="padding-left: 40px;" data-section-id="1ay6dd2" data-start="1742" data-end="1789">The practical complication: the OLED itself<\/h3>\n<p style="padding-left: 40px;" data-start="1791" data-end="1937">An <strong data-start="1794" data-end="1821">18 ms software interval<\/strong> may not yield an 18 ms optical pulse if your code redraws a substantial part of the 128\u00d764 SH1106 display over I\u00b2C.<\/p>\n<p style="padding-left: 40px;" data-start="1939" data-end="1979">A complete framebuffer is approximately:<\/p>\n<p style="padding-left: 80px;"><span class="katex-display"><span class="katex"><span class="katex-mathml">128\u00d764\/8=1024\u00a0bytes128 \\times 64 \/ 8 = 1024\\text{ bytes}<\/span><span class="katex-html" aria-hidden="true"><span class="base"><span class="mord">128<\/span><span class="mbin">\u00d7<\/span><\/span><span class="base"><span class="mord">64\/8<\/span><span class="mrel">=<\/span><\/span><span class="base"><span class="mord">1024<\/span><span class="mord text"><span class="mord">\u00a0bytes<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n<p style="padding-left: 40px;" data-start="2026" data-end="2349">At 400 kHz I\u00b2C, transferring a full framebuffer alone can take on the order of <strong data-start="2105" data-end="2122">23 ms or more<\/strong>, before controller commands and software overhead. Therefore, if your heartbeat implementation performs a full-display redraw for both the \u201con\u201d and \u201coff\u201d states, an 18 ms setting may be below the practical display-update time.<\/p>\n<p style="padding-left: 40px;" data-start="2351" data-end="2430">That does not invalidate the experiment, but it changes what you are measuring:<\/p>\n<blockquote style="padding-left: 40px;" data-start="2432" data-end="2595">\n<p style="padding-left: 40px;" data-start="2434" data-end="2595">You would be measuring PPS-to-visible-OLED timing, including firmware scheduling, display drawing, I\u00b2C transfer, and OLED refresh\u2014not PPS interrupt timing alone.<\/p>\n<\/blockquote>\n<p style="padding-left: 40px;" data-start="2597" data-end="2755">For the video experiment, that may actually be exactly what you want: it shows whether the seven units present their PPS indication coherently to an observer.<\/p>\n<p>I suspected all the logging activity, both via the UART and to the unit’s memory might be a factor affecting the OLED, so I built a firmware version without any logging and launched the 7 units and video recorded them.\u00a0 The number of frames between empty was 6; that’s an improvement, but I am still wondering why the seven T-Beams are not all appearing with full heart beats in one frame when reviewed in a video software platform where each frame can be viewed.<\/p>\n<h3>Conclusion re: video capture<\/h3>\n<p>Pretty, but not precise enough.\u00a0 We need more.<\/p>\n<h2>The Logs<\/h2>\n<p>In my run above where the screenshots of the frames are shown, I ran a 17-1\/2 minute run and logged both on the T-Beams SRAM and over the UART port to my laptop where I have a Perl script wrap each incoming message with a high precision time code.\u00a0 Yes, I had 7 consoles opened.\u00a0 I have built a Perl script that parses both types of logs and stuffs them into a SQLite database.\u00a0 Having both logs in the database allows me to ask questions about various relationships of the parsed data.<\/p>\n<p>With the seven T-Beams mechanically supported so that their USB-C connectors were no longer under load, all seven completed the planned 17-minute internal-PPS-flash capture capture without interruption or write errors. Each unit maintained an unbroken PPS count sequence. Comparing the PPS-disciplined microsecond clocks reported by the units through the live UART monitor showed that their central host-observed offsets occupied only<strong> a 0.166 ms<\/strong> span. When examined minute by minute, the seven-unit spread remained below 0.633 ms for the full run. This does not directly measure the electrical phase difference among the seven GNSS PPS outputs, but it demonstrates that the reconstructed clocks and their end-to-end reporting paths remained mutually consistent to substantially <em>better than one millisecond<\/em>.<\/p>\n<p>For further details, see\u00a0<a href="https:\/\/salemdata.net\/johnpress\/?p=1023">Achieving 166 \u00b5s Clock Synchronization Across 7 T-Beams<\/a><\/p>\n<h2>The Problem With RTC<\/h2>\n<p>The T-Beam uses an RTC circuit<\/span>6<\/sup><\/a><\/span> which has a quartz crystal that vibrates mechanically at approximately <strong data-start="963" data-end="991">32,768 cycles per second, <\/strong>or Herz (“Hz”).\u00a0 The selection of a crystal oscillating at 32,768 Hz was not by accident, but by design since 32,768 is $$2^{15}$$. Think of the crystal as a beating heart. So digital circuitry can divide by two, fifteen times to determine a second and then each one-second tick increments the RTC\u2019s calendar registers.<\/p>\n<pre>32,768 Hz\r\n16,384 Hz\r\n8,192 Hz\r\n...\r\n2 Hz\r\n1 Hz<\/pre>\n<p data-start="2263" data-end="2389">The unavoidable issue is that its crystal is not exactly 32,768.000000 Hz under real conditions. Its frequency changes due to:<\/p>\n<ul data-start="2391" data-end="2566">\n<li data-section-id="1k6h7ns" data-start="2391" data-end="2432">manufacturing tolerance of the crystal;<\/li>\n<li data-section-id="1tn7dr" data-start="2433" data-end="2447">temperature;<\/li>\n<li data-section-id="17u4gid" data-start="2448" data-end="2456">aging;<\/li>\n<li data-section-id="1phhelg" data-start="2457" data-end="2504">oscillator load capacitance and board layout;<\/li>\n<li data-section-id="100xbsi" data-start="2505" data-end="2566">supply conditions and electrical noise, to a lesser degree.<\/li>\n<\/ul>\n<p>So the RTC can drift in time and be off.\u00a0 Moreover, the RTC is not meant to be a high precision component.\u00a0 The RTC\u2019s calendar interface is second-resolution and is suitable for retaining ordinary date and time across a power interruption. Its quartz oscillator can drift with temperature, aging, and manufacturing tolerance, so it is not the timing source used for this sub-millisecond synchronization experiment.<\/p>\n<p>(I acknowledge that the footnotes have problems, that’s on WordPress and Easy Footnotes — standard edition.)<\/p>\n<\/div>

The LilyGO T-Beam Supreme has a real time clock, aka “RTC”, circuit powered by a small hidden rechargeable battery that can hold a charge for 2-3 days.\u00a0 If your T-Beam is without power from A) its larger battery, a 18650 Li-Ion battery or B) a powered USB connector, then your stored date and time value will be lost after 2-3 days. <\/span>7<\/sup><\/a><\/span> The loss of current date and time can be easily fixed, if your firmware anticipates this condition, by fetching satellite time and synchronizing the RTC and maintaining a date-time register (memory storage). When you want to synchronize to satellite time, you do have to expose your T-Beam to several satellites by taking it outside or placing it near a window that can see several satellites. To establish its own full position-and-time solution, a GNSS receiver normally uses signals from at least four satellites. The receiver compares the transmitted timing information with when each signal arrives, solves for its own position and clock error, and then can provide an accurate timing reference.<\/p>\n

\"circuit
Real Time Clock Circuit<\/figcaption><\/figure>\n

The RTC precision is down to the second, not milliseconds. This precision should be adequate for everyday use where sub-second precision is not needed. But for testing and logging what happens within the T-Beam using Reticulum’s transport, millisecond precision of time along with synchronization of all units involved in the test is warranted. For example, if you log that AMY sends a message at 14:02:33.407 (the “407” represents milliseconds, or thousandths (407 of 1,000) of a second) and BOB logs receipt of the same transmission at 14:02:33.023, you want BOB to be in sync with AMY, otherwise a BOB log entry of 14:02:33.023 means BOB is on a different time scale. You want to see BOB receiving the message at 14:02:33.407 or later depending on how long it takes to actually transmit and then for the LoRa circuitry to demodulate the incoming message.<\/p>\n

Thus, the goal is to have the T-Beams share the same “wall clock”<\/span>8<\/sup><\/a><\/span> time so that their logs match the same time as close as possible. Using the RTC stored seconds-precision is not precise enough as units could be off synchronization by as much as 1 second or more. A lot can happen in radio land during one second.\u00a0 Without time synchronization, correlating logs files generated by several T-Beams becomes almost impossible — you would have to know how much each unit varies from another. Therefore, one cannot rely upon the RTC to provide commonality of time among several units.\u00a0 For precision analysis of logs, the date and time stamps must be as synchronized as possible.<\/p>\n

Synchronizing Time<\/h2>\n

Back in the Age of Reason, i.e. the 1960s, if you wanted to know what the current time was, you could dial 853-1212 and the telephone company would have a recording answer with “At the tone, the time will be 3:45 and 20 seconds… BEEP”.\u00a0 Here<\/a>‘s a recreation of such a message<\/span>9<\/sup><\/a><\/span>.\u00a0 When you heard the BEEP, you would know that US time was 3:45:20.\u00a0 You could then set your clock accordingly and feel that your clock is now synchronized close to a second.\u00a0 Remember, though, clocks drift, and one month from now, your clock may be off, so you could call telephone time and reset your clock.\u00a0 When daylight savings time would start or end, calling time was a convenient moment in the year to reset clocks.\u00a0 Also, at New Year’s Eve parties when midnight approached, someone could call time so everyone would know precisely when the new year started and thus set off their firecrackers with joy.<\/p>\n

The critical component of calling telephone time is that your are fore-warned with the necessary information, e.g. “at the the tone…”, about an event which is about to occur: the BEEP, so you could have your electric clock set to the second and then when you heard the BEEP, you could power on your clock.<\/p>\n

In sporting events, such as track and horse racing, every contestant needs to start from the same time, so instead of beeps, you have a starting gun.\u00a0 When everyone hears the starting gun blast, they know they can begin the race and everybody is starting from the same event: the gun blast<\/p>\n

\"1950s
BANG! They’re off!<\/figcaption><\/figure>\n

See the article “Monotonic Clocks and Precise Time Measurement<\/a> ” for a more complex analysis of time in computer networks.<\/p>\n

Satellite Time<\/h2>\n

The same concept as the starter gun in a track race, or the telephone company BEEP, is used in satellite time.\u00a0 A constellation of satellites is in the sky, they are coordinated by atomic clocks to send time signals as pulses and the GPS units on the T-Beams collects several satellite’s signals and calculates its position to determine the loss of time it takes to send the signal to the current location.\u00a0 This is called getting a “fix”, you usually want to have 3 or more satellite signals.\u00a0 In my backyard, surrounded by tall trees, I can see 12 satellites.\u00a0 Here’s a simplified diagram showing 6 satellites sending time signals.\u00a0 The satellites continuously broadcast precisely timed radio signals. Because every satellite is at a different distance, each signal reaches the receiver after a different propagation delay. The GNSS receiver solves those delays, its position, and its own clock offset. Once it has a stable solution, the receiver produces a local electrical timing signal: one pulse per second, commonly called PPS [pulse per second].\u00a0 You will see in the documentation of time-related software “pps” or “PPS” commonly used.<\/p>\n

\"diagram<\/a>
A Few GPS\/Time Satellites<\/figcaption><\/figure>\n

The ESP32 has a continuously running timer that can report elapsed time with microsecond resolution. By itself, that timer will drift relative to UTC. Exercise 28 repeatedly anchors it to the GNSS receiver\u2019s PPS edge, allowing the firmware to interpolate the microseconds between one precisely marked second and the next.<\/p>\n

T-Beam pps Synchronized Software Clock<\/h2>\n

In a T-Beam exercise <\/span>10<\/sup><\/a><\/span> each T-Beam receives a very precise \u201ctick\u201d from the GPS receiver once per second, called PPS\u2014short for pulse per second<\/em>. Think of it as seven runners all hearing the same starting pistol every second. The GPS messages tell the T-Beam which numbered UTC second that tick represents, while the ESP32\u2019s own continuously running timer fills in the tiny fractions of a second until the next tick arrives. By repeatedly lining up its internal timer with these GPS second marks, each T-Beam can assign an accurate time, down to microseconds<\/span>11<\/sup><\/a><\/span>, to events it sees or sends. The small battery-backed clock on the board is not being used as this precision clock in Exercise 28; it is only a separate, coarse clock that can retain ordinary date-and-time information when the unit is powered down.<\/p>\n

To visualize when the PPS arrive, I have the units display for 18 milliseconds on the OLED display a “flash”.\u00a0 Thus, when all 7 units have stabilized their time readings, they should all be flashing at the same time.\u00a0 I recorded the flashing sequences using a camera that can take 59.94 frames per second. Here<\/a>‘s a sample of the video.<\/p>\n

But we must not rely on the naked eye to witness if<\/em> the units are all in sync.\u00a0 Instead, I inspected some select frames from the video.\u00a0 Here is some math: $$1\/59.94=16.68 ms$$<\/p>\n

The display time I arbitrarily set for 18 ms: $$kPpsFlashMs=18 ms$$<\/p>\n

Therefore: $$18\/16.68=1.08 frames$$ which should be a sufficient strobe. Because the 18 ms flash is only slightly longer than one 16.68 ms video frame, a PPS event may appear in one frame or be divided across two adjacent frames, depending on where the camera\u2019s frame boundary falls. The video therefore provides a useful visual check, but not a measurement at microsecond precision.<\/p>\n

Frame Captures (59.94 fps)<\/h2>\n\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t
Frame<\/th>Photo
\nLeft -> Right: AMY BOB CY DAN ED FLO GUY<\/th>		Comment<\/th>\n<\/tr>\n<\/thead>\n
37<\/td>
\"7
Frame 37<\/figcaption><\/figure><\/td>
No Strobe<\/td>\n<\/tr>\n
38<\/td>
\"\"
Frame 38<\/figcaption><\/figure><\/td>
Partial: BOB<\/td>\n<\/tr>\n
39<\/td>
\"\"
Frame 39<\/figcaption><\/figure><\/td>
Partial: BOB CY ED<\/td>\n<\/tr>\n
40<\/td>
\"\"
Frame 40<\/figcaption><\/figure><\/td>
Partials: AMY BOB CY DAN ED<\/td>\n<\/tr>\n
41<\/td>
\"\"
Frame 41<\/figcaption><\/figure><\/td>
Full: AMY BOB CY DAN ED, Partial FLO GUY<\/td>\n<\/tr>\n
42<\/td>
\"\"
Frame 42<\/figcaption><\/figure><\/td>
Full: AMY DAN ED FLO GUY<\/td>\n<\/tr>\n
43<\/td>
\"\"
Frame 43<\/figcaption><\/figure><\/td>
Full: FLO GUY, Partial: AMY DAN ED<\/td>\n<\/tr>\n
44<\/td>
\"\"
Frame 44<\/figcaption><\/figure><\/td>
Partial: DAN FLO GUY<\/td>\n<\/tr>\n
45<\/td>
\"\"
Frame 45<\/figcaption><\/figure><\/td>
No strobe<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nCaptures of video frames where the OLED display is flashing to indicdate a satellite pulse has been received.<\/span>\n\n

Frame Capture Discussion<\/h3>\n

Ideally, I was hoping for 3 frames, 2 frames showing partials bounding a frame show all in full.\u00a0 Remember, each frame represents 16.68ms, so having 8 frames represents 133.44ms of time.\u00a0 ChatGPT cautioned that:<\/p>\n

The practical complication: the OLED itself<\/h3>\n

An 18 ms software interval<\/strong> may not yield an 18 ms optical pulse if your code redraws a substantial part of the 128\u00d764 SH1106 display over I\u00b2C.<\/p>\n

A complete framebuffer is approximately:<\/p>\n

128\u00d764\/8=1024\u00a0bytes128 \\times 64 \/ 8 = 1024\\text{ bytes}<\/span>128<\/span>\u00d7<\/span><\/span>64\/8<\/span>=<\/span><\/span>1024<\/span>\u00a0bytes<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n

At 400 kHz I\u00b2C, transferring a full framebuffer alone can take on the order of 23 ms or more<\/strong>, before controller commands and software overhead. Therefore, if your heartbeat implementation performs a full-display redraw for both the \u201con\u201d and \u201coff\u201d states, an 18 ms setting may be below the practical display-update time.<\/p>\n

That does not invalidate the experiment, but it changes what you are measuring:<\/p>\n

\n

You would be measuring PPS-to-visible-OLED timing, including firmware scheduling, display drawing, I\u00b2C transfer, and OLED refresh\u2014not PPS interrupt timing alone.<\/p>\n<\/blockquote>\n

For the video experiment, that may actually be exactly what you want: it shows whether the seven units present their PPS indication coherently to an observer.<\/p>\n

I suspected all the logging activity, both via the UART and to the unit’s memory might be a factor affecting the OLED, so I built a firmware version without any logging and launched the 7 units and video recorded them.\u00a0 The number of frames between empty was 6; that’s an improvement, but I am still wondering why the seven T-Beams are not all appearing with full heart beats in one frame when reviewed in a video software platform where each frame can be viewed.<\/p>\n

Conclusion re: video capture<\/h3>\n

Pretty, but not precise enough.\u00a0 We need more.<\/p>\n

The Logs<\/h2>\n

In my run above where the screenshots of the frames are shown, I ran a 17-1\/2 minute run and logged both on the T-Beams SRAM and over the UART port to my laptop where I have a Perl script wrap each incoming message with a high precision time code.\u00a0 Yes, I had 7 consoles opened.\u00a0 I have built a Perl script that parses both types of logs and stuffs them into a SQLite database.\u00a0 Having both logs in the database allows me to ask questions about various relationships of the parsed data.<\/p>\n

With the seven T-Beams mechanically supported so that their USB-C connectors were no longer under load, all seven completed the planned 17-minute internal-PPS-flash capture capture without interruption or write errors. Each unit maintained an unbroken PPS count sequence. Comparing the PPS-disciplined microsecond clocks reported by the units through the live UART monitor showed that their central host-observed offsets occupied only a 0.166 ms<\/strong> span. When examined minute by minute, the seven-unit spread remained below 0.633 ms for the full run. This does not directly measure the electrical phase difference among the seven GNSS PPS outputs, but it demonstrates that the reconstructed clocks and their end-to-end reporting paths remained mutually consistent to substantially better than one millisecond<\/em>.<\/p>\n

For further details, see\u00a0Achieving 166 \u00b5s Clock Synchronization Across 7 T-Beams<\/a><\/p>\n

The Problem With RTC<\/h2>\n

The T-Beam uses an RTC circuit<\/span>12<\/sup><\/a><\/span> which has a quartz crystal that vibrates mechanically at approximately 32,768 cycles per second, <\/strong>or Herz (“Hz”).\u00a0 The selection of a crystal oscillating at 32,768 Hz was not by accident, but by design since 32,768 is $$2^{15}$$. Think of the crystal as a beating heart. So digital circuitry can divide by two, fifteen times to determine a second and then each one-second tick increments the RTC\u2019s calendar registers.<\/p>\n

32,768 Hz\r\n16,384 Hz\r\n8,192 Hz\r\n...\r\n2 Hz\r\n1 Hz<\/pre>\n
The unavoidable issue is that its crystal is not exactly 32,768.000000 Hz under real conditions. Its frequency changes due to:<\/p>\n
    \n
  • manufacturing tolerance of the crystal;<\/li>\n
  • temperature;<\/li>\n
  • aging;<\/li>\n
  • oscillator load capacitance and board layout;<\/li>\n
  • supply conditions and electrical noise, to a lesser degree.<\/li>\n<\/ul>\n
    So the RTC can drift in time and be off.\u00a0 Moreover, the RTC is not meant to be a high precision component.\u00a0 The RTC\u2019s calendar interface is second-resolution and is suitable for retaining ordinary date and time across a power interruption. Its quartz oscillator can drift with temperature, aging, and manufacturing tolerance, so it is not the timing source used for this sub-millisecond synchronization experiment.<\/p>\n
    (I acknowledge that the footnotes have problems, that’s on WordPress and Easy Footnotes — standard edition.)<\/p>\n<\/div><\/div>","protected":false},"excerpt":{"rendered":"
    <p>The LilyGO T-Beam Supreme has a real time clock, aka “RTC”, circuit powered by a small hidden rechargeable battery that can hold a charge for 2-3 days.\u00a0 If your T-Beam is without power from A) its larger battery, a 18650 Li-Ion battery or B) a powered USB connector, then your stored date and time value […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_gfmr_meta_descriptions":[],"_gfmr_multilingual_taxonomy_terms":[],"footnotes":""},"categories":[133,80,1],"tags":[],"class_list":["post-978","post","type-post","status-publish","format-standard","hentry","category-mesh-network","category-meshtastic","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/978","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=978"}],"version-history":[{"count":25,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/978\/revisions"}],"predecessor-version":[{"id":1039,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/978\/revisions\/1039"}],"wp:attachment":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=978"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=978"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=978"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}