Thanks for the update. We’ve just managed to receive and successfully decode a few beacons at the start of the pass using 66670’s TLE. Here’s the information:
We have a few more passes lined up with the same TLE so we’ll keep looking out as well.
@K4KDR The packet is based on AX.25 protocol. Thanks for helping us to track down and verify the satellite! We think it’s not 66670, but it works in the meantime until SpaceTrack issues a newer set of TLEs.
66778 Norad ID TLE is working well for us at the moment.
We are having contact with the satellite again after we discovered that the RaspberryPi Camera is creating a bit to much EMI for ur UHF onboard.
The Radio Repeater is now active. So for all of you who want to try bouncing a message to the satellite and get it back that is now possible. We did not yet have the time to test it fully as the payload providers have higher priority.
We are in regular contact with the satellite. At some point in the near future we will introduce a spin to the Y axis. This should be also visible in the RF.
Unfortunately, 66670 in the new set of 26007 Spacetrack TLEs is certainly not our satellite. Using ikhnos on observations 13144893 and 13144970, we found 66688 to be the only candidate. While it is close, it is still not a good fit yet. We are inclined to stick to 66670 26004 TLE, though we understand that the TLE is getting older.
Currently the satnogs observations for BlackKite-1 have 66670’s TLE 26007 loaded. Considering the continuous changing of TLE that must be difficult to maintain, we have setup a website link with a txt file to the TLE we would like to use for future observations here: https://nuspace.sg/black_kite-1.txt
I’ve removed the following of 66670 object for Black-Kite-1 in order to stay to a steady TLE that will allow us to receive the satellite.
Due to the epoch comparison, I’ve propagated the TLE you provided and changed the NORAD ID to the temporary one we use in DB and also added more expected value for the B*:
@hubert-nuspace please verify if this TLE is giving you good results, even if it is not accurate. If it does then let’s start generate our own TLEs until we find out which of the objects fits, as we’ll need TLE that will be close to the observation time to be sure.
Hi All,
Space-track published the list of satellites cataloged from Transponder-15. According to the deployment order, LUNA-1 must be 66682, Object-S. However, our satellite seems to be 66777, Object DR. We also wrote to Space-track and they assigned 66777 to LUNA-1.
Somehow, our satellite more drifted from initial position. @fredy. Can we assign NORAD ID of the LUNA-1 to 66777.
There is no meaning in checking the deployment order, especially in such a big number of deployed satellites, as the objects order is far from deployment order in most cases.
For now I’ve changed the LUNA-1 to follow 66777 objects and when I’m back from my time off, I’ll move forward and check for identification.
Sorry we couldn’t reply earlier due to the certificate issue.
Yes, the new TLE is giving us good results with a slight negative frequency shift in the middle (much better than other SpaceTrack TLEs). We can see the observation here : SatNOGS Network - Observation 13165787 that it has our expected blips.
Using observation 13165917 and 13165868, the only SpaceTrack TLE that might be worth a shot for BlackKite-1 would be 66673. It’s close but not a good fit either.
At this stage moving forward, I agree with fredy might be better to generate our own TLE based on the observations till the satellites spread out far enough for SpaceTrack to correctly distinguish or assign them.
Unfortunately running ikhnos on the full suite of existing spacetrack TLE from 66666 to 66778 shows no noradID coming close to it. There might a possibility we were mistaken to be another object part of another ‘cluster’/’launch’ perhaps.
On another note, so far our own attempts at generating our own TLE in the past few days were pretty off (bad doppler shift in the middle.)
Our process is waterfall_tabulation_helper → dat file → rffit → ikhnos to check.
When using rffit we only fit ascending node, mean anomaly and mean motion (and the default ‘frequency’) where possible. We noticed that the new TLE also has changes in inclination, eccentricity and argument of perigee. Is this a result of an SGP4 propagation step after rffit or a sequence to which parameter should be fit in order during the rffit process?
I didn’t fit inclination and argument of perigee but ascending node, mean anomaly and mean motion, B* and eccentricity. The last two after propagating (inside rffit) the TLE set and by choosing observations from 2 of the 3 stations.
Thanks for the update! We were still able to contact the satellite with an updated version of the old TLE that you helped us generate, but updated through an alternative method using the fft produced by the ground station provider we use instead of Satnogs. It’s still a work in progress so what we generate is still very much experimental, and we didn’t want to bother you too much. We will inform you again once we have a stable process and a website to easily pull our generated TLE from.
As with regards to the missing object, we will communicate with space-track and see what can be done about this loss of tracking in the catalog. Thanks again for all the help!
