Regarding Observation 6563227 …
Seems that these signals could be from Genesis-J but unfortunately Genesis sats had been removed from the satellites list.
I could not order any more passes.
Could be added again?
73 de EA5WA Juan Carlos
Unfortunately this is not the Genesis-J satellite and here are some reasons:
- At that time, there is a great chance that the satellite had already re-entered and burnt.
- Even if not re-entered the observation was scheduled with too old TLE set and updated later with a newer TLE set. This is why there isn’t any pass drawn in the polar plot. That means that the station performed an observation outside the pass.
- Even in case that there was a pass at the time using the latest TLE set, again the odds of getting the satellite would be low because the latest TLE set was ~12h old. Given that the satellite was too low, ready to re-enter then 12h TLE set is too old and doesn’t describe the position of the satellite.
- One last point is that the satellite wasn’t heard the last two days over several locations/stations this probably means that it never transmitted. There could be multiple reasons behind that and without any data it is difficult to say which one was the case.
Hi,
We have successfully partially decoded the packet (header) and it belongs to GENESIS-J:
You can see that, apart from that:
Telemetry is at 50 bps (who transmits at that speed except our GENESIS satellites?)
The length and spacing of the telemetry packets is correct.
The modulation deviation also seems correct
The Doppler shift has the correct shape and amplitude.
Best of all, in the strongest packets you see the “signature” of our TX, which is that horizontal line to the left at the beginning of the packet
Reasons can be discussed. Telecommands to deploy antenna were sent several times. As part of the packet are missing or unable to decode, we will try to force-decode to match CRC.
On the other hand we can’t say the satellite has decayed until confirmed by United States 18th Space Defense Squadron.
Thanks a lot,
73,
Félix EA4GQS
1 Like
That’s awesome news and it changes everything… I’ll try to check against ikhnos and see if we can identify the object with the current TLE.
Hm… None of the space-track.org’s TLE sets fit that curve:
I was thinking that objects 53958 and 53956 were tracking the two lanes of pocketqubes that deployed from picobus. But now with that I’m not sure.
@ea4gqs I can revert the re-entered status of the satellite in DB, however in order to schedule it we will need another set of TLE to follow. Any suggestion?
1 Like
Hi @fredy,
No need to revert status. To be honest it is very likely that they have re-entered as TLEs show that they would be very low now.
Anyway thanks a lot,
Félix EA4GQS
2 Likes
Hi all,
I tried to analyze the observation’s data (with publicly available information) to see if this was GENESIS-J:
Using SigDigger for measurements:
-
We find an 2-FSK modulation with 1 KHz deviation between tones (see the lower left-hand side red circle). The frequency (436.666 MHz), the modulation, and its parameters are the expected ones.
-
Bits last 20 ms (50 bps transmission). The total packet duration is ~4.3 s (see central red circle).
-
All these parameters match Type 01 packets, according to [https://amsat-ea.org/app/download/13147988/AMSAT+EA+-+Descripción+de+transmisiones+de+GENESIS-ASTROLAND+v2.pdf]. These packets are 216 bits long. Therefore, the total duration shoud be 216 bits* 20 ms/bit = 4320 ms, which again matches the measurements.
-
Also, time between transmissions in the audio is exactly 60 seconds. This follows the transmission period of telemetry type 01 “Fast Telemetry”, as specified in the same document.
- Using a customized FSK demodulator, I tried to decode the packet from the audio recording. The expected Sync word can be found within the bitstream. The header is successfully decoded but the CRC check fails.
- However, note that “type” = 1 and “seq” = 0, as expected for this packet type. Also, the source address is 6, which corresponds to “GENESIS-J” (see Table below).
- About the CRC check failure, some periodic fading (~0.5 s) is present in the received signal, particularly towards the middle of the packet. It can be easily observed in the time domain. In the image, red lines try to give an idea of the noise amplitude. Note how the signal periodically hides under the noise floor, probably because the satellites were deployed just a few days ago and were still tumbling at the time of recording.
- With all the above in mind, I think we can say, with a good confidence level, that this was indeed GENESIS-J. Nevertheless, I will try to get a full packet decode.
Best,
Gabriel
4 Likes
Thanks a lot Gabriel,
Félix