Satellite names shown as "OBJECT XX" instead of their known amateur radio names

[F4HTB]

Hi,

Since updating to Look4Sat 4.4.5, I noticed that some satellites in my list are now displayed using generic TLE names such as OBJECT AY or OBJECT F, instead of their usual amateur radio names.

For example:

NORAD 61781 is displayed as OBJECT AY, but this satellite is ASRTU-1 / AO-123.
NORAD 63215 is displayed as OBJECT F, but this satellite is TEVEL2-6.

These satellites were previously much easier to identify by their actual amateur radio names.

Would it be possible for Look4Sat to prefer the known SatNOGS/AMSAT satellite name, or an alternate name, instead of the generic OBJECT XX name when the satellite has already been identified?

This seems related to issue #143 about alternate satellite names, but in this case the generic OBJECT XX names make it particularly difficult to identify satellites in an amateur radio list.

I am currently using Look4Sat version 4.4.5.

Thank you for your work on Look4Sat.

[rt-bishop]

I'm glad you like the app! And thanks so much for raising that.

The issue is that various data providers (Celestrak, AMSAT, SatNOGS, R4UAB) are using various naming conventions. As there is no perfect source of truth, the app fetches them in parallel and then overwrites the satellites with the same CatNum based on the internal priority as can be seen in Sources file. Custom data sources always have the highest priority, so a temporary fix would be to add https://r4uab.ru/satonline.txt as your custom data source. Of course, I'll lower the SatNOGS TLE priority in the next update and things will go back to normal.

I'm not sure how to overcome this issue once and for all though. It's impossible to get all the sources to agree, it seems that some users prefer one or the other naming convention, so it's hard to please everyone. However in the nearest future I'll try to expand the Import dialog to allow all the sources to be customizable, so everyone would be able to decide for themselves. Hope that adds some useful context and clarity!

[F4HTB]

Hello,

Yes, I really love your app, it’s extremely useful to me!
Thank you very much for your reply and for clarifying what is causing this issue. Your proposed solution sounds perfectly reasonable to me.
Like some other users, I also find it a bit unfortunate that the search is based on mode rather than type, but I understand that finding an approach that works well for everyone is not always easy.

In any case, thank you again for your efforts and for continuing to improve the app. It’s greatly appreciated!

[wty2019wty]

I would like to add some observations regarding this name‑overwriting issue. Many thanks to the developer for taking the time to investigate and explain the root cause!

In commit 7cdc2952dc8e40bc8063df32364a83b7eea97101 (tag v4.4.6), re‑ordering custom source URLs inside app settings will alter the final parsed satellite data and lead to garbled satellite display names.

The hard‑coded satelliteDataUrls list in file core/domain/src/main/java/com/rtbishop/look4sat/core/domain/source/Sources.kt (lines 20‑32) exhibits the same behaviour: the order of URLs within the list affects parsing results. That said, this order‑sensitivity is a secondary issue.

The vast majority of the "OBJECT XX" naming anomalies originate from the SatNOGS 3LE endpoint https://db.satnogs.org/api/tle/?format=3le. For v4.4.6, removing this data source serves as a temporary workaround to mitigate the problem.

Additionally, I wonder if we could raise the priority of the two sources listed below. They provide far more search‑friendly satellite names tailored for amateur‑radio users, such as SAKHACUBE‑CHOLBON (RS18S) and ASRTU‑1 (AO‑123):

• https://r4uab.ru/satonline.txt
• https://celestrak.org/NORAD/elements/gp.php?GROUP=active&FORMAT=csv

Here is another feature idea: would it be possible to add drag‑and‑drop priority reordering on the custom sources page, alongside a button to restore default data sources? This would give users greater flexibility to manage their TLE sources.

Thanks to all Look4Sat users and contributors!

[wty2019wty]

I would like to add some observations regarding this name‑overwriting issue. Many thanks to the developer for taking the time to investigate and explain the root cause!

In commit 7cdc2952dc8e40bc8063df32364a83b7eea97101 (tag v4.4.6), re‑ordering custom source URLs inside app settings will alter the final parsed satellite data and lead to garbled satellite display names.

The hard‑coded satelliteDataUrls list in file core/domain/src/main/java/com/rtbishop/look4sat/core/domain/source/Sources.kt (lines 20‑32) exhibits the same behaviour: the order of URLs within the list affects parsing results. That said, this order‑sensitivity is a secondary issue.

The vast majority of the "OBJECT XX" naming anomalies originate from the SatNOGS 3LE endpoint https://db.satnogs.org/api/tle/?format=3le. For v4.4.6, removing this data source serves as a temporary workaround to mitigate the problem.

Additionally, I wonder if we could raise the priority of the two sources listed below. They provide far more search‑friendly satellite names tailored for amateur‑radio users, such as SAKHACUBE‑CHOLBON (RS18S) and ASRTU‑1 (AO‑123):

• https://r4uab.ru/satonline.txt
• https://celestrak.org/NORAD/elements/gp.php?GROUP=active&FORMAT=csv

Here is another feature idea: would it be possible to add drag‑and‑drop priority reordering on the custom sources page, alongside a button to restore default data sources? This would give users greater flexibility to manage their TLE sources.

Thanks to all Look4Sat users and contributors!

I used AI to implement some of my own ideas, but they don’t seem to be perfect yet.

#242