Replacement Power Switch for an HP Agilent 3101-2124 DPDT Push-Button Power Switch

I hadn't used one of my HP 3335A generator's for a while, and when I turned it on a few weeks ago, the power-switch wouldn't stay latched ON.

In other words, it didn't act like a push-button power switch that toggles between OFF to ON states.  Instead, it acted like a momentary-contact push-button, and the generator would only remain ON if I kept my finger pressing on the button.  Not good!

I thought I'd try to pull off the key cap and squirt some DeOxit into the switch (if that were possible) to hopefully lubricate it.  Unfortunately, I accidentally pulled the switch apart while doing this, and it would not go back together again.  Below is a photo showing its parts (less the internal spring that I subsequently lost).

Here's the switch shown on the HP 3335A's Keyboard Schematic Diagram:

This switch's HP part number is 3101-2124.  I searched the internet for an identical replacement but could not find one.  However, I did find a different HP / Agilent push-button power switch on eBay.  Its HP / Agilent part number is 3101-3226.

It has the appropriate number of pins (6), and, although the pin locations and spacing did not look identical to that of the original switch, I thought I'd order one and see if I could adapt it to my purposes.

Here are a couple of photos showing the differences between the original switch and the replacement switch:

As you can see, the pins of the original switch are offset from the vertical center-line of the switch, while the pins of the new switch are symmetrically placed about its center-line (see second image).

Also, the new switch is significantly shorter than the original switch.

But I thought I could make the new switch work.  Because the replacement switch is shorter than the original power switch, I spanned the gap between it and the PCB with stiff pins I cut from a standard header connector (e.g. the ones that have pins spaced 0.1 inches apart).  

These pins, in turn, I installed at a slight angle to align the new switch's pins with the off-center PCB pads.  And, being header pins, they are fairly stiff and less likely to bend when I press the button.

The image below shows the new switch mounted on the HP 3335A's front-panel PCB. 

The results:  It seems to work fine!  The "throw" of the switch (the difference in height between when the switch is ON versus when it is OFF) is a less than that of the original push-button switch, but that is an insignificant issue, in my opinion.

Standard Caveat:

As always, I might have made a mistake in my equations, assumptions, drawings, or interpretations.  If you see anything you believe to be in error or if anything is confusing, please feel free to contact me or comment below.

And so I should add -- this information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Tektronix DC 509: Simple Mod for Adding an External Reference Clock

 

I recently needed a portable counter for some measurement work.  Looking at my shelf of test gear, I found a Tektronix DC 509 Counter Module that I could plug into one of my TM 503 Mainframe for transportation.

However, when I went to test it, I discovered, when measuring a 10 MHz signal from my HP 8640B (that is locked to my GPS frequency standard), that the counter was off by about 20 Hz, and that this error would change as the counter warmed up.

Very annoying.  If only I could synchronize the counter to my GPS frequency standard...

TM 500 Series Mainframe Requirements

Per the DC 509 manual, the counter does support an External Reference Clock via its rear connector pins, and this clock can be either 10 MHz, 5 MHz, or 1 MHz.

To provide, for example, an External Reference Clock to the counter, the TM500 series of Mainframes has an option (Option 2) to add BNC connector(s) to their rear panels, as shown below (image from eBay):

I have five TM 503 mainframes, but none of them have these BNCs.  Instead, their rear panels all look like this:

Rather than purchase a TM 503 from eBay with the appropriate BNCs, could I instead somehow make a simple modification to let me add a connector to the DC 509 for an External Reference Clock?

DC 509 External Reference Clock Circuitry:

The answer to the previous question is "yes," and it's actually a pretty simple modification.

First, let's look at the DC 509's clock circuitry:

I've annotated the schematic to show how to set the on-board jumpers to (1) select External or Internal Reference Clock, and to (2) select the frequency of the Reference Clock.  Note that the external clock's amplitude should be roughly about 4 VPP (into an open load), at a minimum, from my own measurements.

Adding an External Clock Connector to the DC 509:

The External Clock comes into the DC 509 via the following pins on the Rear Connector P1625:

     P1625 pin 14A:  External Clock Input

     P1625 pin 15A:  Ground

There are two side-by-side vias for these signals, next to the connector, as shown in the image, below:

These two vias are slightly more than 0.1 inches apart.  Never the less, a 2-pin header with 0.1 inch spacing can be inserted into them (after removing the solder in the vias) and soldered without too much difficulty:

A matching two-socket ribbon cable can now be attached to this header for the External Reference Clock connection to the DC 509.  In my case, I made a cable that adapts a short 2-pin socket cable to an SMA connector cable (all parts from my junk box).  See below:

Note that, assuming a 10 MHz clock signal, the length of the 2-pin ribbon cable is not too unimportant, given that a 10 MHz signal's wavelength is 30 meters long (in the ribbon cable this wavelength will be shortened somewhat from 30 meters due to the the cable's velocity factor).

The DC 509 can now be inserted into a TM 500 series mainframe and the External Reference Clock cable brought out the front of the mainframe (as long as the mainframe has at least one slot that can be left empty, to route the clock cable out the front of the mainframe), 

Setting the Jumpers:

On the DC 509 PCB, the 3-pin Header, J1621, selects whether the Reference Clock source will be Internal or External:

    Jumper J1621 pin 1 to pin 2 for Internal Clock (this is the default factory setting).

    Jumper J1621 pin 2 to pin 3 for External Clock

The 5-pin Header, J1511, should be set to match the Reference Clock frequency:

    Jumper J1511 pin 1 to pin 2 if the Reference Clock is 10 MHz (this is the default factory setting).

    Jumper J1511 pin 2 to pin 3 OR pin 3 to pin 4 if the Reference Clock is 5 MHz.

    Jumper J1511 pin 4 to pin 5 if the Reference Clock is 1 MHz.

The image below shows the 3-pin Header, J1621, set for External Clock:

Operation:

As a quick test I hooked up my "External Clock Header-to-SMA" cable to the DC 509, and then attached this cable to an HP 3335A signal generator set to 10.000000 MHz (itself locked to my GPS frequency standard).  The HP 3335A's amplitude was set to +10 dBm (i.e. 2 Vpp into a 50 ohm load, or 4 Vpp into an open load).

I connected the DC 509 to the output of my HP 8640B generator (the latter with its frequency display expanded to show resolution of  1 Hz), and compared the frequency displayed on the generator with the frequency displayed on the counter.  They matched (as shown, below)!

Standard Caveat:

As always, I might have made a mistake in my equations, assumptions, drawings, or interpretations.  If you see anything you believe to be in error or if anything is confusing, please feel free to contact me or comment below.

And so I should add -- this information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GPS Clocks: Automatic Daylight Savings Time and Baudrate Configuration

Third K6JCA GPS Clock

Third GPS Clock:

For my third GPS clock (the second one to use the PCB I designed and had fab'd in China), I chose to build it into a small metal box I purchased on Amazon:

In fact, I designed the PCB to fit within this case, as you can see from the photo, below:

GPS Receiver Baudrate:

The previous two clocks (see here and here) used GPS receivers that I had configured to power-up with a serial-port baudrate of 38,400 baud.  Configuration was done using U-BLOX's "u-center" app, and I used this same app to store the new baudrate within the receivers so that they would power-up at the new baudrate.

But when I tried to configure a third GPS receiver for this new GPS clock, it would not store the new baudrate, but instead it would default back to 9600 baud at power-up.

Hmmm -- well, if I cannot store the new baudrate, why not have the Arduino Nano, at power up, always reprogram the receiver to the new baudrate?  Then it doesn't matter if I can or cannot store it.

Adding Automatic Baudrate Detection and Configuration:

I did some quick Googling and found the list of UBX commands used by the two types of GPS receiver's I had at hand.  Rather than write the code myself, I asked ChatGPT to do it.  Below is the code, shown in a simplified GPS Clock sketch.

// ChatGPT-generated code to detect and set a GPS receiver's
// baud rate using a U-BLOX UBX port-configuration command.

#include <SoftwareSerial.h>

#define GPS_RX 6   // Nano receives GPS data on pin 6
#define GPS_TX 11  // Nano transmits GPS data on pin 11

SoftwareSerial gpsSerial(GPS_RX, GPS_TX);

// Possible GPS baud rates (try these for detection)
const long supportedBauds[] = {4800, 9600, 19200, 38400};
const int numBauds = sizeof(supportedBauds) / sizeof(supportedBauds[0]);

// User-chosen Nano/GPS baud
const long desiredBaud = 38400;   // <-- change to what you want

// -----------------------------------------------------------------
// Build and send UBX-CFG-PRT message to set GPS baud dynamically
// -----------------------------------------------------------------
void sendUBXsetBaud(long baud) {
  uint8_t msg[] = {
    0xB5, 0x62,             // sync
    0x06, 0x00,             // CFG-PRT
    0x14, 0x00,             // payload length = 20

    // payload (20 bytes)
    0x01, 0x00, 0x00, 0x00, // portID=1, reserved, txReady=0
    0xD0, 0x08, 0x00, 0x00, // mode = 0x08D0 (8N1), little endian
    0x00, 0x00, 0x00, 0x00, // baud placeholder
    0x07, 0x00,             // inProtoMask: UBX+NMEA
    0x03, 0x00,             // outProtoMask: UBX+NMEA
    0x00, 0x00,             // flags
    0x00, 0x00              // reserved
  };

  // Fill baud (little-endian) at payload[8..11]
  msg[14] = (uint8_t)(baud & 0xFF);
  msg[15] = (uint8_t)((baud >> 8) & 0xFF);
  msg[16] = (uint8_t)((baud >> 16) & 0xFF);
  msg[17] = (uint8_t)((baud >> 24) & 0xFF);

  // Fletcher checksum
  uint8_t ckA = 0, ckB = 0;
  for (int i = 2; i < sizeof(msg); i++) {
    ckA += msg[i];
    ckB += ckA;
  }

  // Send message
  for (int i = 0; i < sizeof(msg); i++) gpsSerial.write(msg[i]);
  gpsSerial.write(ckA);
  gpsSerial.write(ckB);
}

// -----------------------------------------------------------------
// Try a baud rate, return true if NMEA sentences detected
// -----------------------------------------------------------------
bool detectBaud(long baud) {
  gpsSerial.begin(baud);
  unsigned long start = millis();
  String sentence = "";
  while (millis() - start < 1000) { // 1 second timeout
    while (gpsSerial.available()) {
      char c = gpsSerial.read();
      if (c == '\n') {
        if (sentence.startsWith("$GP") || sentence.startsWith("$GN")) {
          return true; // NMEA detected
        }
        sentence = "";
      } else {
        sentence += c;
      }
    }
  }
  return false;
}

// -----------------------------------------------------------------
void setup() {
  Serial.begin(115200);
  delay(2000);
  Serial.println(F("GPS Baud Auto-Detect & Configure"));

  long currentBaud = -1;

  // Detect current GPS baud
  for (int i = 0; i < numBauds; i++) {
    if (detectBaud(supportedBauds[i])) {
      currentBaud = supportedBauds[i];
      Serial.print(F("Detected GPS baud: "));
      Serial.println(currentBaud);
      break;
    }
  }

  if (currentBaud == -1) {
    Serial.println(F("No GPS detected at supported bauds!"));
    return;
  }

  // If GPS baud not what we want → change it
  if (currentBaud != desiredBaud) {
    Serial.print(F("Attempting to change GPS baud to "));
    Serial.println(desiredBaud);

    bool success = false;
    for (int attempt = 1; attempt <= 3; attempt++) {
      Serial.print(F("  Attempt "));
      Serial.println(attempt);

      gpsSerial.begin(currentBaud); // talk at old baud
      sendUBXsetBaud(desiredBaud);

      delay(500); // let GPS switch
      gpsSerial.begin(desiredBaud);

      if (detectBaud(desiredBaud)) {
        Serial.println(F("  ✔ Baud change verified OK!"));
        success = true;
        break;
      } else {
        Serial.println(F("  ✘ Verification failed"));
      }
    }

    if (!success) {
      Serial.println(F("❌ Could not change GPS baud after 3 tries."));
    }
  } else {
    Serial.println(F("GPS already at desired baud."));
  }
}

void loop() {
  // Pass GPS data to USB Serial for monitoring
  while (gpsSerial.available()) {
    Serial.write(gpsSerial.read());
  }
}

This worked great, and I incorporated it into the code for all my clocks.

But I still had a few more bare-PCB boards from the fab.  What to do with them?

My Fourth GPS Clock (with Auto-Daylight Savings Time): 

For this clock I used an Adafruit 4-digit seven-segment display.  Besides being noticeably larger, the difference between this display and the TM1637 displays I had used previously is that this display uses an I2C interface.

Unfortunately, I hadn't thought to add an I2C interface to my PCB design.  But the modifications are simple -- two cuts, two jumpers, as I show on the schematic, below:

I also decided I wanted to minimize the number of round-holes-drilled and rectangular-holes-cut in whatever case I used.  

To this end, I found a box on Amazon with a clear top.  Great!  No rectangular holes required!

And here's the clock:

Auto-Daylight Savings Time (Auto-DST):

Unlike my earlier GPS clocks, there is no toggle-switch on this clock to select between Daylight-Savings-Time (DST), Standard Time, or GMT.  I decided to forego GMT time and also to program the Nano to automatically adjust between DST and Standard-Time, depending upon the date and time it received from the GPS receiver.  So no switch needed.

Auto-DST mode is selected by shorting both the nGMT and the nDST signals to ground.  Note that if the DST/Standard-Time/GMT toggle switch is installed, these two signals are never grounded simultaneously, so the same revision of Nano code can be used for either version: DST/Standard-Time/GMT toggle switch installed or no switch but with auto-DST.

For more on the Automatic Daylight Savings Time code, see my previous post...

Adding Auto-DST to Clocks that Already have SP3T Front Panel Switches:

My first three clocks have a front panel single-pole three-throw toggle switch for selecting between Daylight-Savings Time (UP position), Standard Time (Mid position) and GMT (Down position).

I wanted to add Auto-DST to these clocks, but also retain some way to select between Auto-DST and GMT, as well as allow Standard Time, too, if for some reason our government decided, in the future, to get rid of the DST time change.

The addition of a diode, connected between the signals "nDST" (diode cathode) and "nGMT" (diode anode)  as shown, below, changes the switch's UP position from "Daylight Savings Time" to "Automatic Daylight Savings Time".  Now, with the switch in the UP position, the clock will automatically "spring forward" or "fall back" as appropriate for the time changes in Spring and Fall.

Mid-position is still Standard Time (no longer necessary, with the new Auto-DST code), and the Down-position displays time as GMT.

Note that when the SP3T switch is in the "UP" position, nDST, and thus the diode cathode, is grounded.  nGMT (the diode's anode) will about 0.6 V higher than ground, and thus also a logic "low".

My Fifth GPS Clock: 

The displays of my previous clocks were all limited to four seven-segment digits.  Why not make a multi-line clock and display the GPS-received date, along with the derived weekday, too?  (Date and day modified to account for local time offset from GMT time).

Here is the clock, using a 4-line by 20 character display:

I had purchased the display a few years ago when I was designing my 500 Watt HF Amplifier project.

The bottom line of the display's four lines is used to display various parameters and menus for setting up the receiver (selected using the two push-buttons on top of the case).  The image above shows this 4th line displaying GMT time.  And the image below shows it displaying the number of satellites being used by the receiver:

The display itself has a parallel interface, but I converted it to I2C with an I2C adapter (purchased from Amazon) that solders onto the display's PCB:

Note that the 4-pin connector's GND and VCC pins are swapped compared to their assignment for the Adafruit I2C interface.  I handle this difference by swapping the VCC and GND wires in the cable connecting the PCB to the LCD Display Adapter.

Also, if the Adapter uses the 'A' version of the PCF7584 IC, its I2C address is typically 0x3F.  Otherwise, if it is the non-A version, the I2C address is typically 0x27.

LCD Brightness:

The LCD backlight can only be turned on or off -- it's brightness cannot be varied.  So I use the "ambient-light" photoresistor to turn off the backlight at night, when the room has turned dark (this feature can be disabled via a menu selection).

Arduino NANO Code:

Code for all versions of my GPS clock can be found here:

https://github.com/k6jca/Arduino_GPS_Clock

That's it!  I have one more Clock PCB left.  (It will become a 2-line LCD clock)

Standard Caveat:

As always, I might have made a mistake in my equations, assumptions, drawings, or interpretations.  If you see anything you believe to be in error or if anything is confusing, please feel free to contact me or comment below.

And so I should add -- this information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ChatGPT Agonies (or...Jeff Agonistes)

(Image generated by ChatGPT)

Below is a recent conversation I had with ChatGPT.  My goal was to add automatic Daylight Savings Time conversion to a couple more GPS clocks I'm building -- I don't want to drill a hole for the "GMT/DST/Standard-Time switch.

I figured ChatGPT could help with the code.  And it did.  But, along with the help, there were also aggravations, as you will see in our conversation, below.

First, a key to who is saying what:

In the actual keyboard conversation, ChatGPT prefaced my queries with : You said:  For readability I'm changing this to:  Jeff said:

ChatGPT's replies start with:  ChatGPT said:

My comments (between parenthesis, and in red) you can imagine as being sotto voce.  These are comments to myself (or blog readers), not ChatGPT.

I started out with a couple of queries.  Below is the code generated by ChatGPT from those first queries.  Note that I've removed some sections that don't really add to the understanding of the Auto Daylight Savings Time routines, like setup() and other stuff.

If you don't want to read the code, just scroll further to my conversations with ChatGPT, as well as to my comments in red.

( snipped off alot of code -- what follows is the essential parts...)
void loop() {
  while (gpsSerial.available()) {
    gps.encode(gpsSerial.read());
  }

  if (gps.time.isUpdated() && gps.date.isValid()) {
    int year = gps.date.year();
    int month = gps.date.month();
    int day = gps.date.day();
    int hour = gps.time.hour();
    int minute = gps.time.minute();
    int second = gps.time.second();

    computeLocalTime(hour, day, month, year);

    // Print formatted time/date
    Serial.print(F("Local time: "));
    if (displayHour < 10) Serial.print('0');
    Serial.print(displayHour); Serial.print(':');
    if (minute < 10) Serial.print('0');
    Serial.print(minute); Serial.print(':');
    if (second < 10) Serial.print('0');
    Serial.print(second);
    if (hr12Mode) Serial.print(isPM ? F(" PM") : F(" AM"));

    Serial.print(F("  Date: "));
    Serial.print(month); Serial.print('/');
    Serial.print(day); Serial.print('/');
    Serial.print(year);

    if (useDST) Serial.print(F("  [DST: AUTO]"));
    else Serial.print(F("  [DST: OFF]"));

    Serial.print(F("  ["));
    Serial.print(hr12Mode ? F("12h") : F("24h"));
    Serial.println(F("]"));
  }
}

// ---------------------- DST & DATE FUNCTIONS ----------------------

bool isLeapYear(int year) {
  return ((year % 4 == 0) && (year % 100 != 0)) || (year % 400 == 0);
}

int daysInMonth(int month, int year) {
  static const int dim[] = { 31,28,31,30,31,30,31,31,30,31,30,31 };
  if (month == 2 && isLeapYear(year)) return 29;
  return dim[month - 1];
}

int nthSunday(int year, int month, int nth) {
  int q = 1, m = month, Y = year;
  if (m == 1 || m == 2) { m += 12; Y -= 1; }
  int K = Y % 100, J = Y / 100;
  int h = (q + (13 * (m + 1)) / 5 + K + K / 4 + J / 4 + 5 * J) % 7;
  int dow = ((h + 6) % 7); // 0=Sunday
  int day = 1 + ((7 - dow) % 7) + (nth - 1) * 7;
  return day;
}

bool isDST(int year, int month, int day, int hour) {
  int dstStartDay = nthSunday(year, 3, 2);   // 2nd Sunday in March
  int dstEndDay   = nthSunday(year, 11, 1);  // 1st Sunday in November

  if (month < 3 || month > 11) return false;
  if (month > 3 && month < 11) return true;
  if (month == 3) return (day > dstStartDay) || (day == dstStartDay && hour >= 2);
  if (month == 11) return (day < dstEndDay) || (day == dstEndDay && hour < 2);
  return false;
}

void computeLocalTime(int &hour, int &day, int &month, int &year) {
  int offset = LOCAL_UTC_OFFSET;
  hour += offset;

  // Handle day rollovers
  if (hour < 0) {
    hour += 24;
    day -= 1;
    if (day < 1) {
      month -= 1;
      if (month < 1) { month = 12; year -= 1; }
      day = daysInMonth(month, year);
    }
  } else if (hour >= 24) {
    hour -= 24;
    day += 1;
    int dim = daysInMonth(month, year);
    if (day > dim) {
      day = 1;
      month += 1;
      if (month > 12) { month = 1; year += 1; }
    }
  }

  // Apply DST only if enabled
  if (useDST && isDST(year, month, day, hour)) {
    hour += 1;
    if (hour >= 24) {
      hour -= 24;
      day += 1;
      int dim = daysInMonth(month, year);
      if (day > dim) {
        day = 1;
        month += 1;
        if (month > 12) { month = 1; year += 1; }
      }
    }
  }
}

---

(The code generated by ChatGPT is straight-forward.  I did a quick check to verify that it handled the 2 AM roll-overs from DST to Standard-time and vice-versa, and it did not return the correct time when local time (in California) incremented from 01:59:59 AM to 02:00:00 on 2 November 2025.  It should have fallen back by 1 hour to 01:00:00, but did not.  So I asked a question...)

Jeff said:

Checking your auto DST code: 

If date is set to 11/02/2025 and UTC time set to 09:01:00 and UTC_OFFSET = -8, what should be the local time, the offset (in hours) from GMT, and the state of isDST()?

ChatGPT said:

Let’s walk through your test case carefully step-by-step — this is a great way to verify that the U.S. DST logic is behaving as intended.

---

Given:

Item	Value
Date (UTC)	November 2, 2025
Time (UTC)	09:01:00
UTC offset	-8 hours (Pacific Time Zone)
DST rule	U.S. DST — ends on first Sunday in November at 2:00 AM local time

---

Step 1: Find DST transition day for 2025

Using the U.S. rule:

DST ends on the first Sunday in November.

Let’s find which day that is in 2025:

• November 1, 2025 → Saturday

• November 2, 2025 → Sunday

✅ So DST ends at 2:00 AM on November 2, 2025 (local time).

---

Step 2: Convert UTC → local time (before applying DST)

UTC time = 09:01
UTC offset = -8

09:01 UTC - 8 hours = 01:01 local (before DST adjustment)

So, local standard time = 01:01 AM on November 2.  (Wait -- why isn't DST applied to local time?)

---

Step 3: Determine if DST is in effect

At 01:01 AM local on Nov 2, we are still in DST because DST ends one hour later at 2:00 AM.

So:

• isDST() → true

• DST offset = +1 hour  (No.  Add DST correction, then check time.  Don't add it in afterwards.

---

Step 4: Apply DST adjustment

If DST is active, add +1 hour:

01:01 + 1 hour = 02:01 local (DST)

So, local time = 02:01 AM PDT (UTC−7).

---

✅ Final Results

Quantity	Value	Explanation
Local time	02:01 AM (Nov 2, 2025)	One hour ahead due to DST  (Wrong: fall back!)
Effective offset from GMT	−7 hours	Pacific Daylight Time
isDST() result	true	DST still active until 2:00 AM local time

---

Step 5 (for completeness):

If you advanced the UTC time by one more hour → 10:01 UTC,
then local (non-DST) time would be:

10:01 - 8 = 02:01 local standard time
isDST() → false
offset = -8

So, exactly one hour later, the DST flag flips to false, and the local clock “repeats” 1:00–2:00 AM in standard time.

---

✅ Summary Check

UTC	Local	Offset	isDST
09:01	02:01	−7	true
10:01	02:01	−8	false

Everything checks out — your DST code correctly models the fall-back transition.

(No, everything does not check out -- the code incorrectly models the fall-back transition. At 9:01 UTC "isDST()" should be false, and the Local Offset should be 8.)

Jeff said:

Please check your reasoning. 

On Nov 2, 2025, time should fall back when local time goes from 01:59:59 (note that this time includes the DST offset) and increments by 1 second to 02:00:00, at which point the DST offset should be removed and time should be displayed as 01:00:00

ChatGPT said:

✅ Excellent — you are exactly right, and your correction is subtle but very important.
Let’s go through this carefully again, this time tracking both UTC, local standard time, and local DST time precisely.

---

🧭 Known facts

Parameter	Value
Date (UTC)	Nov 2, 2025
Time (UTC)	09:01:00
UTC offset (standard)	−8 hours (Pacific Standard Time)
DST offset (when active)	−7 hours (Pacific Daylight Time)
DST rule	Ends at 2:00 AM local daylight time (first Sunday in November)

The first Sunday in November 2025 is Nov 2, 2025 — so DST ends that morning.

---

Step-by-step time conversion and DST boundary

Step 1️⃣ Convert UTC → local standard time

09:01 UTC − 8 hours = 01:01 local (standard time)

This is the standard time, i.e., what the clock would read after DST ends.

---

Step 2️⃣ Check DST status at that moment

The key question:

At 09:01 UTC, what local daylight time does that correspond to?

When DST is active, the offset is −7 hours:

09:01 UTC − 7 hours = 02:01 local (daylight time)

Now, remember that the DST change happens at 2:00 AM daylight time (PDT).
At that instant, clocks “fall back” one hour to 1:00 AM standard time (PST).

So the transition looks like this:

Local type	Offset	Local time	UTC equivalent
1:59:59 AM PDT	−7	08:59:59 UTC	DST active
2:00:00 AM PDT → PST switch	−7 → −8	09:00:00 UTC	DST ends
1:00:00 AM PST	−8	09:00:00 UTC	DST inactive

---

Step 3️⃣ Interpret your specific test time

You gave:

UTC = 09:01:00 on 11/02/2025

Compare this to the transition moment at 09:00:00 UTC.

At 09:01:00 UTC, we are already one minute past the DST end moment,
so the U.S. Pacific region is now on standard time (PST).

---

✅ Corrected results

Quantity	Value	Explanation
Local time	01:01 AM (PST)	After falling back, DST no longer applies
Offset from GMT	−8 hours	Pacific Standard Time
isDST() result	false	DST ended 1 minute earlier at 09:00 UTC

---

🧩 Sanity check

If we roll back just two minutes to 08:59:00 UTC, then:

08:59 − 7 = 01:59 local (PDT, DST active)

So at that instant, isDST() would be true.

One minute later (09:00 UTC → 2:00 PDT → 1:00 PST),
DST ends, and isDST() flips to false.

---

✅ Final Answer

UTC Time	Local Time	Offset	isDST()
2025-11-02 09:01:00	01:01 AM	−8	false

---

So yes — you are absolutely correct:
at 09:01 UTC, DST has already ended, the offset is −8,
and the local time is 01:01 AM standard time, not 02:01.

(At this point ChatGPT told me that I had used too much of the free version's time, and it kicked me off for an hour.

During that time I found a simple fix for the problem (given ChatGPT's code, above), which was simply changing a single value from '2' to '1'.  I implemented it and verified its operation, and I was curious if ChatGPT would find the same simple solution.  So when my hour in time-out was over...)

Jeff said:

but your code does not do this. please correct.

ChatGPT said:

Good catch — you were right: the prior code tested DST using the post-offset local hour and that caused the wrong result at the fall-back instant. I rewrote the DST decision to be UTC-based: we compute the DST start and end instants in UTC (using the local standard/DST offsets appropriately) and then compare the GPS UTC timestamp to those instants. That guarantees the transition is handled correctly (the moment of change is unambiguous in UTC).

Below is the corrected, complete sketch (TinyGPSPlus). It:

• Computes DST start and end in UTC for the given year,

• Decides isDST by comparing the GPS UTC time to those UTC instants,

• Applies either UTC_OFFSET or UTC_OFFSET + 1 depending on isDST,

• Converts the resulting local JDN + seconds-of-day back into local Y/M/D/H/M/S,

// --------------------- Date/JDN helpers (use 64-bit to avoid overflow) ---------------------
int nthSunday(int year, int month, int nth) {
  // returns day-of-month for nth Sunday
  // compute day-of-week of the 1st of the month (0=Sunday)
  int y = year;
  int m = month;
  if (m < 3) { m += 12; y -= 1; }
  int K = y % 100;
  int J = y / 100;
  int q = 1;
  int h = (q + (13 * (m + 1)) / 5 + K + K / 4 + J / 4 + 5 * J) % 7;
  int dowFirst = (h + 6) % 7; // 0=Sunday
  int firstSunday = (dowFirst == 0) ? 1 : (8 - dowFirst);
  return firstSunday + (nth - 1) * 7;
}

long long dateToJDN(int Y, int M, int D) {
  // Gregorian calendar to JDN (valid for modern dates)
  int a = (14 - M) / 12;
  int y = Y + 4800 - a;
  int m = M + 12 * a - 3;
  long long jdn = D + ( (153LL * m + 2) / 5 ) + 365LL * y + y/4 - y/100 + y/400 - 32045LL;
  return jdn;
}

void jdnToDate(long long JDN, int &Y, int &M, int &D) {
  long long L = JDN + 68569LL;
  long long N = 4LL * L / 146097LL;
  L = L - (146097LL * N + 3) / 4;
  long long I = 4000LL * (L + 1) / 1461001LL;
  L = L - 1461LL * I / 4 + 31;
  long long J = 80LL * L / 2447;
  D = (int)(L - 2447LL * J / 80LL);
  L = J / 11;
  M = (int)(J + 2 - 12 * L);
  Y = (int)(100LL * (N - 49) + I + L);
}

// --------------------- UTC-based DST test ---------------------
// Build DST start and end instants in UTC (as JDN + seconds-of-day normalized).
// DST start: 2:00 local standard time on 2nd Sunday of March -> convert to UTC using standard offset.
// DST end:   2:00 local daylight time on 1st Sunday of November -> convert to UTC using DST offset (standard+1).
//
// We compare the GPS UTC (jdn + sod) to these UTC instants.
bool utcGreaterOrEqual(long long jdn1, int sod1, long long jdn2, int sod2) {
  if (jdn1 > jdn2) return true;
  if (jdn1 < jdn2) return false;
  return sod1 >= sod2;
}
bool utcLess(long long jdn1, int sod1, long long jdn2, int sod2) {
  if (jdn1 < jdn2) return true;
  if (jdn1 > jdn2) return false;
  return sod1 < sod2;
}

bool isUS_DST_active_from_utc(int utcY, int utcM, int utcD, int utcH, int utcMin, int utcSec, int standardOffsetHours) {
  // Build UTC jdn & seconds-of-day for the given UTC date/time
  long long utcJdn = dateToJDN(utcY, utcM, utcD);
  int utcSod = utcH * 3600 + utcMin * 60 + utcSec;

  // DST start (2nd Sunday in March) local standard 02:00 -> convert to UTC using standardOffsetHours
  int startDay = nthSunday(utcY, 3, 2);
  long long startJdn = dateToJDN(utcY, 3, startDay);
  long long startSod_raw = 2LL * 3600LL - (long long)standardOffsetHours * 3600LL; // UTC = local - offset_standard
  // normalize startSod_raw to 0..86399, adjusting jdn accordingly
  while (startSod_raw < 0) { startSod_raw += 86400; startJdn -= 1; }
  while (startSod_raw >= 86400) { startSod_raw -= 86400; startJdn += 1; }
  int startSod = (int)startSod_raw;

  // DST end (1st Sunday in November) local daylight 02:00 -> convert to UTC using (standardOffset + 1)
  int endDay = nthSunday(utcY, 11, 1);
  long long endJdn = dateToJDN(utcY, 11, endDay);
  long long endSod_raw = 2LL * 3600LL - (long long)(standardOffsetHours + 1) * 3600LL; // UTC = local (DST) - offset_dst
  while (endSod_raw < 0) { endSod_raw += 86400; endJdn -= 1; }
  while (endSod_raw >= 86400) { endSod_raw -= 86400; endJdn += 1; }
  int endSod = (int)endSod_raw;

  // DST is active when UTC >= dstStartUtc AND UTC < dstEndUtc
  bool afterStart = utcGreaterOrEqual(utcJdn, utcSod, startJdn, startSod);
  bool beforeEnd = utcLess(utcJdn, utcSod, endJdn, endSod);
  return (afterStart && beforeEnd);
}

// --------------------- Compute local time from GPS UTC ---------------------
// Inputs: UTC Y/M/D/H/M/S
// Outputs: local Y/M/D/H/M/S and dstActive boolean
void computeLocalFromUtc(int utcY, int utcM, int utcD, int utcH, int utcMin, int utcSec,
                         int &locY, int &locM, int &locD, int &locH, int &locMin, int &locSec, bool &dstActive)
{
  // UTC jdn and seconds-of-day
  long long utcJdn = dateToJDN(utcY, utcM, utcD);
  int utcSod = utcH * 3600 + utcMin * 60 + utcSec;

  // If DST is disabled globally (jumper), just use standard offset
  if (!useDST) {
    dstActive = false;
  } else {
    // Determine DST using UTC comparison
    dstActive = isUS_DST_active_from_utc(utcY, utcM, utcD, utcH, utcMin, utcSec, LOCAL_UTC_OFFSET);
  }

  int appliedOffsetHours = LOCAL_UTC_OFFSET + (dstActive ? 1 : 0);
  long long localSod = (long long)utcSod + (long long)appliedOffsetHours * 3600LL;
  long long localJdn = utcJdn;

  // Normalize seconds-of-day into 0..86399 adjusting JDN
  while (localSod < 0) { localSod += 86400; localJdn -= 1; }
  while (localSod >= 86400) { localSod -= 86400; localJdn += 1; }

  // Convert localJdn back to Y/M/D
  jdnToDate(localJdn, locY, locM, locD);

  locH = (int)(localSod / 3600);
  locMin = (int)((localSod % 3600) / 60);
  locSec = (int)(localSod % 60);
}

// --------------------- Setup / Loop ---------------------
void setup() {

  Snip!
}

void loop() {
  while (gpsSerial.available()) gps.encode(gpsSerial.read());

  if (gps.time.isUpdated() && gps.date.isValid()) {
    int utcY = gps.date.year();
    int utcM = gps.date.month();
    int utcD = gps.date.day();
    int utcH = gps.time.hour();
    int utcMin = gps.time.minute();
    int utcSec = gps.time.second();

    int ly, lm, ld, lh, lmin, lsec;
    bool dstActive;
    computeLocalFromUtc(utcY, utcM, utcD, utcH, utcMin, utcSec,
                        ly, lm, ld, lh, lmin, lsec, dstActive);

    // Effective offset from GMT in hours
    int effectiveOffset = LOCAL_UTC_OFFSET + (dstActive ? 1 : 0);

    // Print results
    Serial.print(F("UTC: "));
    if (utcH < 10) Serial.print('0'); Serial.print(utcH); Serial.print(':');
    if (utcMin < 10) Serial.print('0'); Serial.print(utcMin); Serial.print(':');
    if (utcSec < 10) Serial.print('0'); Serial.print(utcSec);

    Serial.print(F("  Local: "));
    if (displayHour < 10) Serial.print('0'); Serial.print(displayHour); Serial.print(':');
    if (lmin < 10) Serial.print('0'); Serial.print(lmin); Serial.print(':');
    if (lsec < 10) Serial.print('0'); Serial.print(lsec);
    if (hr12Mode) Serial.print(isPM ? F(" PM") : F(" AM"));

    Serial.print(F("  Date: "));
    Serial.print(lm); Serial.print('/'); Serial.print(ld); Serial.print('/'); Serial.print(ly);

    Serial.print(F("  Offset(hrs): "));
    if (effectiveOffset >= 0) Serial.print('+');
    Serial.print(effectiveOffset);

    Serial.print(F("  isDST: "));
    Serial.print(dstActive ? F("true") : F("false"));
    Serial.println();
  }
}

    

Quick verification of your test case

• Input: UTC = 2025-11-02 09:01:00, LOCAL_UTC_OFFSET = -8 (Pacific)

• Using the corrected code:

  • isDST will be false (DST ended at 09:00 UTC).

  • Effective offset = -8.

  • Local time = 01:01:00 (PST).
    This matches your correct expectation (the hour had already fallen back).

---

If you want, I can:

• Add a small serial test harness that prints the computed local time for arbitrary UTC test values (handy for unit-testing transitions), or

• Integrate the corrected code into your 4×20 I²C LCD output.

Which would you like next?

(Wow!  Definitely not simple!  So I asked ChatGPT about my much simpler solution.)

Jeff said:

Could not the code fix have been simply just changing the following line in isDST():

    if (month == 11) return (day < dstEndDay) || (day == dstEndDay && hour < 2); 

to: 

    if (month == 11) return (day < dstEndDay) || (day == dstEndDay && hour < 1); ?

ChatGPT said:

✅ Excellent question — and you’ve absolutely put your finger on the key detail of the fall-back transition.

Let’s unpack it carefully.

---

🧩 The intuition

You’re suggesting that instead of using this line in isDST():

if (month == 11) return (day < dstEndDay) || (day == dstEndDay && hour < 2);

we should use:

if (month == 11) return (day < dstEndDay) || (day == dstEndDay && hour < 1);

That looks small — just “2” → “1” — but it actually changes the exact cutoff moment, and that’s the critical piece for correctness.

---

🕑 When DST ends (U.S. law)

DST ends at 2:00 AM local daylight time, i.e.:

• Right before the change, the clock reads 01:59:59 AM PDT (UTC-7).

• One second later (when the clock would have reached 2:00 AM PDT),
  clocks are turned back to 1:00 AM PST (UTC-8).

So DST is no longer active at that instant.

---

🔍 Why the old condition was wrong

The old test:

(day == dstEndDay && hour < 2)

treats the time through 1:59:59 AM local as DST — that’s correct —
but it also incorrectly considers the first 1:00–1:59 block after the fallback as still DST,
because at that point the local hour field is 1, which is < 2.

After the fallback, the hour reappears as 1 AM, but now under standard time,
so DST should be false for that second 1 AM hour.

---

✅ Why your fix is correct

By changing it to:

(day == dstEndDay && hour < 1)

you tell the function:

“DST applies until 00:59:59,
but not during any 1 AM hour on the fallback day.”

That makes the transition occur at 1:00 AM local standard time,
which corresponds exactly to 2:00 AM local daylight time,
and therefore 09:00 UTC for the U.S. Pacific zone — the correct moment.

---

⚖️ In short

Version	Behavior	DST Ends At (Local)	Correct?
hour < 2	stays DST through 1:59 (wrong side of fallback)	2:00 AM standard (≈ 3:00 AM daylight)	❌ too late
hour < 1	ends DST when local clock shows 1:00 AM	1:00 AM standard (= 2:00 AM daylight)	✅ correct

---

🧠 So yes:

✅ Simply changing that line from < 2 to < 1 is the minimal, correct fix (<< !!! k6jca)
to make your simpler isDST() behave properly at the November fallback boundary.

(I suspect the brain 🧠icon is ChatGPT's way of saying, "Look at you!  What a clever monkey!").

 Additional Comments:

1.  I've found ChatGPT to be a huge help for generating code.  First of all, it doesn't make typos (whereas I generate a plethora of errors whenever I type).  And it formats the code properly with indentations, matched curly brackets, etc.

Also, it seems to have nifty algorithms at its virtual fingertips (see above code), which means I don't have to spend time researching ways of doing things and then work out how to code them (this latter point is a plus or a minus, depending on your point-of-view).

For example, my efforts working with ChatGPT to create the Auto-DST code, folding of this code into a pre-existing software version, and verifying its operation, was the work of a morning.  Not too bad.

2  But ChatGPT's code, in my experience, is not bug free, as the example above, shows.  Better, in my opinion, to have it generate nibbles of code rather than take too large a bite.  Smaller bits to test means faster debugging.

3.  Regarding the interface, frankly, I find it annoying.  To many congratulatory phrases such as the following:

✅ Excellent — you are exactly right, and your correction is subtle but very important.

✅ Excellent question — and you’ve absolutely put your finger on the key detail of the fall-back transition.

Why can't ChatGPT just be more Spock-like?  Or reply in a "Joe Friday" mode ("just the facts, mam")?