Adding Luca-1 satellite

[e75ti]

Adding Luca-1 satellite (Creating Luca.yml)
Luca-1 is a satellite launched in late december and it marks
the first Montenegrin satellite ever launched. It's a 1U
cubesat. Also added to list of supported satellites.

Satyaml verified working on personal recording.

https://community.libre.space/t/soyuz-2-1b-fregat-vostochny-launch-2025-12-28-1305-utc/14152/109

[daniestevez]

Thank you. Can you share the recording that you used for testing or link to a SatNOGS observation whose OGG file produces decodes?

[e75ti]

Thank you. Can you share the recording that you used for testing or link to a SatNOGS observation whose OGG file produces decodes?

You're welcome! Thank you for the fantastic program. I can't seem to remote into my machine at the moment, but I gave the latest sat downlink from satnogs a try:

https://network-satnogs.freetls.fastly.net/media/data_obs/2026/1/12/21/13193431/satnogs_13193431_2026-01-12T21-05-02.ogg

It works great:

-> Packet from 2k4 FSK USP downlink
Container: 
    header = Container: 
        addresses = ListContainer: 
            Container: 
                callsign = u'R2ANF' (total 5)

Didn't copy whole reply to not spam, but yes, worry not, it's all there, works great :)

[e75ti]

Added RS90S as alt name as well, added proposed Norad ID, rebased

(btw I'm not 100% sure on convention here, do you mind to give advice going slightly off topic?

How do you or people in general prefer upon code change suggestion/requests to counter-offer / change myself?) I figured I could just stack commit upon commit, as you'd probably just squash it all into one or two commits anyway when you pull from pull request branch, so, is then rebasing bad (mostly focusing on squashing), as it throws everything off course, adds collisions and stops merging, so that I am forced to force push, which is very frowned upon as it removes history (which I'd imagine is quite important for e.g. discussion about code changes. Advice please?

Thank you.

[daniestevez]

How do you or people in general prefer upon code change suggestion/requests to counter-offer / change myself?)

This varies somewhat with each open source project. In particular whether a project follows a standard policy to merge PRs with a merge commit, or with a rebase, or with a squash, can make a difference in the recommendation for how the commits to a PR branch are expected to look like. gr-satellites follows more or less the same policy as GNU Radio, but more flexibly, since it is a smaller project with way fewer collaborators:

• PR branches are rebased and merged
• The expected state of a PR branch before merge is that everything is squashed down to one or a couple commits with clean and good descriptions
• During PR review, it is okay to push incrementally new commits to the branch addressing review feedback. The PR author should squash these when the PR is approved, and before it is merged
• It is also okay to force-push to address review feedback

Sometimes I will be more flexible than this. For instance with contributors who are not experience with git, I can squash myself on merge using the Github web UI.

I have seen some people frown on force-push, but to me using it in a PR branch is absolutely fine. Github even provides a convenient way to review the changes caused by the force-push. So far everything you've done in this PR branch looks reasonable and fairly standard to me.

[daniestevez]

This looks good except that the NORAD ID is 67287 rather than 98449.

[e75ti]

This looks good except that the NORAD ID is 67287 rather than 98449.

Yep, it's all 67287 at the moment after I force pushed. That should be it, thank you Daniel for the explanation as well. Much appreciated! \o/

Edit: I see review is still open, seems like after force push that Github doesn't close review, need to review the force push. Seems to be fine and intended like this to me, force push = new code = new review. Nice.