How to use tleread function on TLE file with alpha-5 satellite numbers

I am reading a TLE (Two-Line Element set) that uses extended satellite catalog numbers - not the new 9-digit format, but five digits where the first character may be an alpha, for example:

1 T0438U           25067.96451506  .00001976  00000-0  85471-3 0  9992
2 T0438  88.9364  325.5995 0219128 193.3691 166.1633 14.11995745 27841

The "T" in column 3 indicates an "Alpha-5" character, where the letter represents a digital value.

I know how to parse Alpha-5 fields, but that doesn't help when it comes time to read this TLE with tleread(), which requires fixed formats and 5-digit satellite numbers. What is the solution?

Answer 1

[Umar]

Hi @Kurt,

Short answer: tleread() doesn't support Alpha-5 catalog numbers right now — it's built to expect the old-style fixed-width, all-numeric 5-digit field, and there's nothing documented that extends it to letters like the T in your T0438. So it's not something you're doing wrong, the function itself just isn't there yet for this format.

I put together two ways around it, and attached a PDF that walks through both with full code and results — worth opening, since it explains what each one does and which situation it fits:

If you don't have the Aerospace Toolbox handy (or you're on MATLAB Mobile like I was testing on) — there's a standalone script that skips tleread() completely. It decodes the Alpha-5 letter back into the real catalog number (your T0438 is actually satellite 270438), checks that both lines' checksums are valid, and pulls out every orbital element tleread() would normally hand you — inclination, eccentricity, mean motion, epoch, all of it. I built this in both Python and MATLAB, ran both myself, and also ran the MATLAB version directly in MATLAB Mobile — that screenshot's in the PDF too, showing it executing live with no toolbox involved. Both runs came back with identical numbers, so this one's solid.

If you do have the Aerospace Toolbox and would rather just keep using tleread()/propagateOrbit() the normal way — there's a second script that preprocesses the file first: it swaps in a throwaway numeric placeholder for the catalog number field (which doesn't affect the orbit math at all), fixes up the checksum so the line is valid again, runs it through tleread() like normal, then puts the real Alpha-5 number back into the result afterward. I want to be upfront that I haven't been able to test this one against the actual toolbox myself — I don't have it installed here — so if you give it a try, let me know how it goes.

Open the attached PDF for the full code listings, explanations, and the verification output/screenshot — it's laid out so you can just copy the script that fits your setup straight into MATLAB.

[Kurt]

I used solution 2, since I have the Aerospace Toolbox. It works perfectly!

Thanks,

Kurt

[Umar]

Glad it worked, Kurt! Thanks for confirming

[Kurt]

I noticed something else here. If you feed a whole TLE file's worth of TLEs to tleread(), it weeds out the duplicate TLEs - that is, the ones with the same catalog number. I assume it keeps the last (most recent) one? You need to take this into account when you are inserting the updated catalog numbers back into the tleStruct.

[Umar]

Hi @Kurt,

You are right about the dedup thing — I checked it against the tleread() docs and confirmed it keeps whichever entry has the latest epoch when catalog numbers repeat. Turned out that mattered more than I expected, because the placeholder scheme in the original script could actually let two different satellites collide on the same number once you're running a whole file, not just one TLE.

I put together an updated script that fixes it, and a short writeup explaining exactly what was going wrong and how the fix works — attached below. I haven't been able to run it against the real toolbox myself, so if you get a chance to try it on a file with a couple of duplicate/updated TLEs in it, let me know how it goes.

[Kurt]

I had already come up with a slightly lazier solution that uses the unique() function on satellite numbers. However, it only saves the FIRST entry in the table, which may not be the latest. I will let you know how this new code performs.

As an aside, I have found that it can take over two hours to process one of these massive new TLE files (>130,000 lines, blame Elon Musk). Watching the Task Manager, my CPU is running at nearly 50%. It is apparent that the tleread() function is most likely using p-code and multithreading to speed the process up, but it still takes forever. I found a partial solution, which is to break the TLE file up into four chunks and process them sequentially, then stick the tleStruct results back together. I was able to reduce the run time to about 20 minutes. I also save the tleStruct in a file so I can reuse it later. That way, I only have to process the original TLE file once.

[Umar]

Hi @Kurt,

Makes sense on the unique() thing — yeah, that'll bite you if the file isn't sorted with the newest entries first, since it just grabs whatever it sees first. The script I sent sidesteps that by letting tleread() do the actual latest-epoch picking itself (that's built in, confirmed it in the docs), so there's nothing extra for us to get wrong there.

The chunking result is interesting though. You ran those 4 chunks one after another, not in parallel, and still cut it from 2 hours to 20 minutes — that's a bigger jump than you'd expect just from CPU/thread stuff, since it was sequential either way. Feels more like tleread() slows down disproportionately as the file gets huge, so breaking it into pieces avoids whatever's causing that. If you've got the Parallel Computing Toolbox, might be worth trying those same 4 chunks with parfor instead of a regular loop, just to see if it stacks on top of the chunking win or not.

One thing to watch for with the chunking approach: if a satellite has two TLE entries (old and updated) and they happen to land in different chunks, tleread() will only dedupe within each chunk — so both could survive and you'd end up with two entries for that satellite after you stitch everything back together. Easy fix if it comes up: sort the combined struct by Epoch descending, then run unique() on the catalog numbers keeping the first hit — same trick you tried, just fixed by sorting first.

Anyway, let me know how the updated script does on your end whenever you get a chance to run it — especially curious whether the placeholder/lookup approach holds up cleanly on one of those massive files.