Support Iridium ERA3 Re-Epoch

[ndoo]

It looks like the existing code only supports Iridium ERA2 re-epoch.

ERA3 re-epoch will come into effect soon, I could only find this bulletin about it:
https://metocean.com/important-technical-bulletin-from-metocean-iridium-re-epoch/

It may be worth considering using __DATE__ / __TIME__ to start preemptively supporting the switchover or at least tracking this for a future release.

[PaulZC]

Thanks for the heads-up Andrew (@ndoo ),

I'm checking with Ground Control (formerly Rock7) to see if they have had any official notification about the epoch change.

But, yes, the library will need to be updated...

All the best,
Paul

[ndoo]

Just in case anyone doesn’t click through, and to avoid unnecessary panic from my use of the word "soon", here is the relevant line from the linked bulletin:

Iridium has announced that a new epoch will be rolled out, targeting January 14, 2026. However, official dates/times and further details to be announced shortly.

And I should also call attention to the fact that the official cutover has not actually been announced, according to that source.

[PaulZC]

Here's my fix - tested on 9603N:

SparkFun_IridiumSBD_I2C_Arduino_Library/src/IridiumSBD.cpp

Lines 269 to 322 in 9fd48f0

	// From the AT Command Reference:
	// The system time as received through the Iridium Air
	// Interface, is a 32 bit integer count of the number of 90 millisecond
	// intervals that have elapsed since the epoch. The return value is
	// formatted as an ASCII hexadecimal number. The counter will rollover
	// approximately every 12 years or be changed to prevent a rollover and
	// as a result should not be used as a time source for user applications
	// Current epoch: May 11, 2014, at 14:23:55 UTC.
	struct tm epoch_start_current;
	epoch_start_current.tm_year = 2014 - 1900;
	epoch_start_current.tm_mon = 5 - 1;
	epoch_start_current.tm_mday = 11;
	epoch_start_current.tm_hour = 14;
	epoch_start_current.tm_min = 23;
	epoch_start_current.tm_sec = 55;
	epoch_start_current.tm_isdst = 0; // Resolves #16
	// Future epoch: February 14, 2025, at 18:14:17 UTC.
	struct tm epoch_start_future;
	epoch_start_future.tm_year = 2025 - 1900;
	epoch_start_future.tm_mon = 2 - 1;
	epoch_start_future.tm_mday = 14;
	epoch_start_future.tm_hour = 18;
	epoch_start_future.tm_min = 14;
	epoch_start_future.tm_sec = 17;
	epoch_start_future.tm_isdst = 0; // Resolves #16
	unsigned long ticks_since_epoch = strtoul(msstmResponseBuf, NULL, 16);
	/* Strategy: we'll convert to seconds by finding the largest number of integral
	seconds less than the equivalent ticks_since_epoch. Subtract that away and
	we'll be left with a small number that won't overflow when we scale by 90/1000.
	Many thanks to Scott Weldon for this suggestion.
	*/
	unsigned long secs_since_epoch = (ticks_since_epoch / 1000) * 90;
	unsigned long small_ticks = ticks_since_epoch - (secs_since_epoch / 90) * 1000;
	secs_since_epoch += small_ticks * 90 / 1000;
	time_t epoch_time = mktime(&epoch_start_current); // Try current epoch first
	time_t now = epoch_time + secs_since_epoch;
	struct tm * local_now = localtime(&now);
	// Extract the current year from __DATE__
	int build_year = (((int)(__DATE__[7] - 0x30) * 1000) + ((int)(__DATE__[8] - 0x30) * 100)
	+ ((int)(__DATE__[9] - 0x30) * 10) + ((int)(__DATE__[10] - 0x30) * 1));
	// Check if year is within bounds
	if ((local_now->tm_year + 1900) < build_year)
	{
	epoch_time = mktime(&epoch_start_future); // Use future epoch
	now = epoch_time + secs_since_epoch;
	}

[PaulZC]

@ndoo : I think testing on the year alone is safe. But if you think we should go further, let me know.

I'll hold off releasing these changes until I've heard back from Ground Control.

[ndoo]

Happy to test but like you mentioned I’d also like to hear what Ground Control says (we are a customer too).

Just starting this discussion now because it would be good to get ahead of this (though we aren't supposed to rely on Iridium for timekeeping…)

[PaulZC]

Hi Andrew (@ndoo ),

The response from Ground Control is:

"The ERA3 EPOCH will correspond to February 14, 2025, at 18:14:17.000Z and that a new epoch will be rolled out targeting January 14, 2026. As such you are correct that you'll need to update your code to reflect the change."

So, please test away!

If you want to download a complete copy of the release_candidate branch, please click this link.

Best wishes,
Paul

[PaulZC]

@ndoo : v3.1.0 is now public:

https://github.com/sparkfun/SparkFun_IridiumSBD_I2C_Arduino_Library/releases/tag/v3.1.0

I will leave this issue open until the fix has been fully tested - after the epoch change

[ndoo]

Sounds good, at least I may abuse Iridium time for the next 10 years 😉

[ndoo]

I couldn’t get confirmation if the re-epoch has taken place, but on the latest release, I am still getting correct date and time, so I suppose the fix must have worked (if the re-epoch has taken place).