We now have TLE sets for all the objects from spacetrack, still some are in “0 TBA - TO BE ASSIGNED” status. Bellow are some identifications coming from strf tools using gps locked station (kudos to @pierros) and verified also by ikhnos on network observations. I’m going to keep the temporary NORAD IDs in DB until all the TLE sets are assigned to objects as they may be swapped or changed in spacetrack, until then satellite in DB and Network will follow the TLE sets of the object that was identified.
It looks as though the FSK1200 signals from CAPE-3 are not being decoded successfully by the SatNOGS FSK flow-graph, even with very high SNRs (e.g. this observation: https://network.satnogs.org/observations/3492784/ ). Why this is the case I’m not sure, the IQ of that high-SNR observation is available if anyone wants to have a try.
So - please schedule all future CAPE-3 observations in the AFSK1200 mode! I don’t know how the auto-scheduler picks what mode to use, but can we get it changed to use AFSK1200 for now please?
As spacetrack has assigned all the TLE sets to objects we can now be sure about our previous identifications so:
MiTEE is identified as OBJECT F(47314) CAPE-3 is identified as OBJECT A(47309) CP12(EXOCUBE-2) is identified as OBJECT L(47319)
I’ve changed the rest of the Satellites that haven’t been received until now to follow OBJECT C(47311) which covers better all the unidentified objects as being in the middle.
There is a report for FOX-1E transponder, that is alive. The radio amateur suggests OBJECT M(47320) as possible object, so I’ve changed to follow it in DB and Network.
We recently got some IQ data from a groundstation provider that appears to be Polarcube. I’m in the process of decoding it now. However we have not had any luck making contact with our ground station as of yet.
@dryerzinia do you have UTC timestamp of this observation? Also if you can share the ground station location this could be also useful as we may reject some of the NORAD objects.
I know they where targeting NORAD ID 47318 and it was on January 25th with a 32 Element Yagi tuned for 401MHz. I don’t have the exact timestamps/location. Given the high gain antenna and the relatively low SNR (Only about 2dB) I think its likely that the antenna has not deployed. We should have considerably more power on the ground than that.
After looking though the data some more I think it is likely that polarcube is not 2020-002K. The data shows a +/-6kHz doppler error and the data is only present in about 3/5ths of the pass. That suggests either 2020-002B or 2020-002J. Both of which would not have been in the main lobe of the antenna. I’m not sure which is more likely at this point. Hoping to get come confirmation on this is the coming days. Will let you know.
Now that it has been a few weeks, is there any way we could change the TLEs for PICs at least? I am fairly certain that they are OBJECT J (47317) and OBJECT K (47318) (not sure which ones yet) because they were in the dispenser with CAPE-3. All of the satellites have drifted far enough that OBJECT C passes at a very different time from J and K. I think this accounts for a lot of why so few observations have seen PIC A and PIC B.
We managed to capture the beacon with our own ground station antenna the other day and after looking at the doppler shift it is consistent with Object B.
Showing about a 700Hz center frequency error after correction:
cf_error_hz = [761, 704, 721, 708, 730, 694, 682, 726, 697, 751, 723]
Additionally looking back at the IQ from the ground station provider one of the beacons with an SNR of 5.7dB was able to be partially decoded. After noticing we got a sync detect I disabled the CRC filtering and we where able to confirm a match on the first the fixed data bytes of the packet [0x02, 0x69, 0x01]. The rest of data data appeared to be garbled however.
The pulse of energy at 400 seconds is the right bandwidth and size. But I don’t see anything +/- 15 seconds like I would expect. Could just be its too weak to make out in this waterfall.
Exactly! Here and here is more visible and with the 15s interval! Polarcube is alive and fits perfectly OBJECT B (47310) as when I tested it with ikhnos all the other objects were too off.
Which means Polarcube is identified as OBJECT B (47310).
