propagateOrbit function fails on Epoch field format
显示 更早的评论
I am feeding the same tleStruct data to the propagateOrbit function twice, but in one case propagageOrbit is successful, and in the other case it fails with the following error message:
Error using propagateOrbit
An error was encountered when propagating the orbit of spacecraft at index 1 using sdp4 orbit propagator.
error in test_TLE (line 17)
[r1,v1] = propagateOrbit(epoch_date,tleStruct,PropModel="sdp4",OutputCoordinateFrame="fixed-frame");
Caused by:
Error using - (line 43)
Cannot combine or compare a datetime array within a time zone with one without a time zone.
The tleStruct data looks identical in both cases. In the first case, I use tleread() to input the data and feed it directly to propagateOrbit. In the second case, I write the tleStruct to an Excel .csv file, read it back in as a new tleStruct, and feed it to propagateOrbit. That is when I run into issues with the epoch_date and tleStruct.Epoch fields.
Here is a sample test script:
function test_TLE()
epoch_date = datetime('09-Mar-2025 07:26:58');
tleStruct = struct;
input_pathname = pwd;
[filename, filepath] = uigetfile(fullfile(input_pathname, '*.tle'));
fullpath = strcat(filepath,filename);
[~,name,~] = fileparts(filename);
csv_filepath = strcat(filepath, name, '.csv');
if isfile(csv_filepath)
csvtext = readtable(csv_filepath);
tleStruct = table2struct(csvText);
% script fails here:
[r1,v1] = propagateOrbit(epoch_date,tleStruct, PropModel="sdp4",OutputCoordinateFrame="fixed-frame");
disp(num2str(r1);
else
tleStruct = tleread(fullpath);
[r1,v1] = propagateOrbit(epoch_date,tleStruct, PropModel="sdp4",OutputCoordinateFrame="fixed-frame");
disp(num2str(r1);
% save struct to file so you can read it in faster the next time:
tleTable = struct2table(tleStruct);
tlePath = strrep(fullpath,'.tle','.csv');
writetable(tleTable, tlePath, 'Delimiter', ',', 'fileType', 'text');
end
end
input file "day_068.tle":
1 00011U 59001A 25067.89046599 +.00002526 +00000-0 +13240-2 0 9994
2 00011 32.8783 45.0235 1450212 290.5993 54.5192 11.89297186480028
Output file "day_068.csv":
Name SatelliteCatalogNumber Epoch Bstar RightAscensionOfAscendingNode Eccentricity Inclination ArgumentOfPeriapsis MeanAnomaly MeanMotion
UNKNOWN 11 3/8/2025 21:22 0.001324 45.0235 0.1450212 32.8783 290.5993 54.5192 0.049554049
The Epoch field appears as shown above in the Excel table. When you examine it in the edit field, it says "3/8/2025 9:22:16 PM
The first time you run the script, it will read the TLE file and create a tleStruct for propagateOrbit() to read. This call is successful. It then outputs a new "day_068.csv" file to save time on subsequent function calls.
The second time you run the script, it reads the "day_068.csv" file and converts it to a tleStruct. When you attempt to read this
tleStruct into propagateOrbit(), it throws an error.
Apparently propagateOrbit calls arithUtil(a,b) which checks for datetime compatibility and throws an exception.
The time fields appear identical to me in both cases, when I examine them in the tleStruct.Epoch field. Is Excel doing something funny to the datetime structure?
1 个评论
E.g., this is an example that may look the same on output with no time zone printed by default, but will throw an error when compared because one has a time zone and the other doesn't:
dt1 = datetime('10-Mar-2025 07:26:58') % No time zone
dt2 = datetime('09-Mar-2025 07:26:58','TimeZone','UTC') % With time zone, but doesn't print it
dt1 - dt1 % works with two unzoned datetimes
dt2 - dt2 % works with two zoned datetimes
dt1 - dt2 % fails when comparing unzoned vs zoned datetimes
采纳的回答
"Is Excel doing something funny to the datetime structure?"
Excel is notoriously bad in handling dates, particularly if it is interpreted as a date/time field. I'm not sure just where it's going wrong there, but I'd be pretty sure it's in that translation into/back out of Excel that is causing the problem.
Why not forego Excel altogether if the point is to save processing time on subsequent case and just save the desired variable(s) in native MATLAB .mat format? It/they will be read back in then identically as were in memory to the identical bit pattern besides being a much smaller file size and faster operation.
function test_TLE()
epoch_date = datetime('09-Mar-2025 07:26:58');
tleStruct = struct;
input_pathname = pwd;
[filename, filepath] = uigetfile(fullfile(input_pathname, '*.tle'));
fullpath = fullfile(filepath,filename); % more robust
[~,name,~] = fileparts(filename);
mat_filepath = fullfile(filepath, name, '.mat');
if isfile(mat_filepath)
load mat_filepath % retrieve saved tleStruct
[r1,v1] = propagateOrbit(epoch_date,tleStruct, PropModel="sdp4",OutputCoordinateFrame="fixed-frame");
disp(num2str(r1);
else
tleStruct = tleread(fullpath);
[r1,v1] = propagateOrbit(epoch_date,tleStruct, PropModel="sdp4",OutputCoordinateFrame="fixed-frame");
disp(num2str(r1);
% save struct to .mat file so you can read it in faster the next time:
save(mat_filepath,'tleStruct');
end
end
Although, there is really no point in the above code snippet as written unless it is only the test demo; one presumes at least something has been/is modified in the tleStruct struct variable in the real use case; otherwise the struct is already in memory.
11 个评论
Kurt
2026-7-21，13:38
That's what the above does; the point being, however, that unless there's something done to the time variable between the first and subsequent cases it is run, it won't be any different than the copy that is already in memory because your function as presently constructed doesn't have any way to update the tleStruct variable that was saved the first pass in order to rewrite a new version later; you'll have to restructure that code somehow for that to happen.
Kurt
2026-7-21，14:58
Kurt
2026-7-21，15:25
Kurt
2026-7-21，16:12
dpb
2026-7-21，16:49
Well, if it is fixed, then I don't see the point in saving it multiple times, simply the original is all that would be needed. But, if that were the case, it would seem more efficient to build a preprocessing tool that simply builds a .mat file for each .tle file and just use them instead from the start.
But, I don't have the TB and never done these, so I'm just trying to make sense of the presented code. If it does what you want/need correctly, that's good. <grin>
Kurt
2026-7-21，17:05
Good luck...although I still don't follow how the propagateOrbit() function is going to do anything different on subsequent calls unless it is the passed epoch_date value that matters and that the real top level code passes modifies it and it isn't as here overwritten by some local constant. But, as noted, I don't have the TB and haven't ever tried this; only that the original code illustrated saving the tleStruct, I thought it was also going to have to get updated with the last time.
With the continuing conversation, I think I now see there were two issues; the Q? really about having previously written the struct to Excel and that had thus changed the format of the internal date in the .tle file. So, I think I now understand that date being fixed; it's the other that is also called epoch_date in your code but that is the time for which it is desired to which to do the extrapolation from the base date; hence the difference showing up in the error.
So, in the end it is to save the base .tle file struct as a .mat so it retains TZ information as you can then generate new times to match easily enough. I may be slow, but I think I eventually caught on...<grin>
Kurt
2026-7-21，19:13
dpb
2026-7-21，19:22
Gotcha...thanks! Looks like a plan; it would from the outside looking in then appear that the conversion to the .mat file would be a worthwhile thing if these are, indeed, used multiple times and there is an observable overhead in the tleread() function.
更多回答（1 个）
Umar
2026-7-18，4:56
0 个投票
Hi @Kurt,
Wanted to close the loop on the Excel/datetime thing properly before saying anything definitive.
Ran a couple of tests on my end first: round-tripped a datetime through writetable/readtable in plain MATLAB, no Excel involved — came out clean, TimeZone empty both sides, values identical. Then did the same thing with a full struct shaped like your actual tleStruct (Name, SatelliteCatalogNumber, Epoch, all the fields) — also completely clean. So that rules out writetable, readtable, struct2table, and table2struct as the cause — none of them introduce the mismatch on their own.
That leaves Excel as the only part of your workflow we haven't directly tested, and by elimination it's the most likely explanation — dpb's instinct about Excel and dates lines up with that. If you get a chance and don't mind, one quick way to confirm it directly: take a fresh CSV, open it in real Excel, save it (even without changing anything), read it back into MATLAB, and check tleStruct.Epoch.TimeZone before and after. If that's what introduces the mismatch, it'll confirm it outright rather than just by process of elimination.
That said — since what you're actually trying to do is just cache the parsed struct so you're not reprocessing that huge file every time, the practical fix doesn't depend on nailing the exact mechanism. save()/load() with a .mat file sidesteps the whole thing, since it stores the datetime exactly as it exists in memory with no text step for anything to go wrong in. Probably the simplest path forward regardless of what Excel turns out to be doing.
6 个评论
Walter Roberson
2026-7-18，6:38
移动：Walter Roberson
2026-7-18，6:39
Excel does not store the timezone. It appears that writetable() strips out the timezone information and writes the localtime relative to the timezone (rather than writing a UTC timestamp.)
T1 = datetime(1980, 2, 29, 19, 00, 0)
T1.TimeZone
T2 = datetime(1980, 2, 29, 19, 00, 0, 'timezone', 'America/Chicago')
T2.TimeZone
D = table(T1, T2)
Filename = tempname() + ".xlsx";
writetable(D, Filename)
E = readtable(Filename)
E.T1.TimeZone
E.T2.TimeZone
OutFolder = tempdir();
filenames = unzip(Filename, OutFolder)
dbtype( filenames{7} )
T = datetime(1980, 2, 29, 19, 00, 0, 'timezone', 'America/Chicago')
T.TimeZone
D = table(T);
D.T.TimeZone
Filename = tempname();
save(Filename,'D')
clear D
load(Filename)
D.T.TimeZone
I figured it would be something of the sort...doesn't this indicate a bug or at least an implementation flaw in writetable, though? One would have to explicitly set an output format to include the time zone field to text output, but it seems that at least a warning should inform user that the table variable may not reflect the table value when read back in. The doc mentions the difference in Excel date/time types (although the present internal doc link is broken, returning a "Content is retired" error) but I can't find any mention of the time zone issue.
Kurt
2026-7-21，13:44
"I will try Walter's suggestion of saving the data as a .mat file..."
Not to nit pick, but that was my first suggestion and what the code I posted above modified your initial function does.
Just for clarity I'll repeat the comment above in that you misunderstood the point being made.
"That's what the above does; the point being, however, that unless there's something done to the time variable between the first and subsequent cases it is run, it won't be any different than the copy that is already in memory because your function as presently constructed doesn't have any way to update the tleStruct variable that was saved the first pass in order to rewrite a new version later; you'll have to restructure that code somehow for that to happen."
Kurt
2026-7-21，14:34
类别
在 帮助中心 和 File Exchange 中查找有关 Satellite Mission Analysis 的更多信息
Translated by 
